Связи модели в Power BI Desktop

Эта статья предназначена для импорта моделей данных, работающих с Power BI Desktop. Это важный раздел проектирования моделей, необходимый для предоставления интуитивно понятных, точных и оптимальных моделей.

Более подробное обсуждение оптимальной структуры модели, включая роли таблиц и связи, см. в статье "Общие сведения о схеме звезды" и важности для Power BI.

Назначение связи

Связь модели распространяет фильтры, применяемые к столбцу одной таблицы модели, на другую таблицу моделей. Фильтры будут распространяться до тех пор, пока существует путь связи, который может включать распространение в несколько таблиц.

Пути связи детерминированы, то есть фильтры всегда распространяются одинаково и без случайного изменения. Однако связи могут быть отключены или изменены контекстом фильтра с помощью вычислений модели, использующих определенные функции DAX. Дополнительные сведения см . в разделе "Соответствующие функции DAX" далее в этой статье.

Внимание

Связи модели не применяют целостность данных. Дополнительные сведения см . в разделе об оценке связей далее в этой статье, в которой объясняется поведение связей модели при возникновении проблем целостности данных с данными.

Рассмотрим, как связи распространяют фильтры, на анимированном примере.

В этом примере модель состоит из четырех таблиц: "Категория", "Продукт", "Год" и "Продажи". Таблица "Категория" относится к таблице Product, а таблица Product относится к таблице Sales. Таблица Year также относится к таблице Sales . Все связи — это один ко многим (сведения о которых описаны далее в этой статье).

В запросе (возможно, созданном визуальным элементом карточки Power BI) требуется общее количество проданного по заказам на продажу, сделанным в одной категории (Cat-A) и в течение одного года (CY2018). Именно поэтому можно просмотреть фильтры, примененные к таблицам категории и года . Фильтр таблицы "Категория " распространяется на таблицу Product , чтобы изолировать два продукта, назначенных категории Cat-A. Затем фильтры таблицы Product распространяют в таблицу Sales, чтобы изолировать только две строки продаж для этих продуктов. Эти две строки продаж представляют продажи продуктов, назначенных категории Cat-A. Их объединенное количество составляет 14 единиц. В то же время фильтр таблицы Year распространяется для дальнейшего фильтрации таблицы Sales, что приводит только к одной строке продаж , которая предназначена для продуктов, назначенных категории Cat-A , и которая была заказана в году CY2018. Значение количества, возвращаемое запросом, равно 11 единицам. Обратите внимание, что при применении нескольких фильтров к таблице (например , таблице Sales в этом примере) это всегда операция AND, требующая, чтобы все условия были верными.

Применение принципов схемы типа "звезда"

Для создания модели, состоящей из таблиц измерений и фактов, рекомендуется применять принципы схемы типа "звезда". Обычно для настройки Power BI применяются правила фильтрации таблиц измерений, что позволяет связям модели эффективно распространять эти фильтры на таблицы фактов.

На следующем рисунке показана схема модели данных анализа продаж Adventure Works. На нем показана схема типа "звезда", состоящая из одной таблицы фактов с именем Sales. Остальные четыре таблицы — это таблицы измерений, которые поддерживают анализ измерений продаж по дате, состоянию, региону и продукту. Обратите внимание на связи модели, соединяющие все таблицы. Эти связи распространяют фильтры (прямо или косвенно) в таблицу Sales.

Отключенные таблицы

Необычно, что таблица моделей не связана с другой таблицей моделей. Такая таблица в допустимой модели описывается как отключенная таблица. Отключенная таблица не предназначена для распространения фильтров в другие таблицы моделей. Они принимают вводимые пользователем данные (возможно, с помощью визуального элемента среза), благодаря чему вычисления модели могут эффективно использовать входное значение. Например, рассмотрим отключенную таблицу, загруженную с диапазоном значений валютных курсов. Поскольку фильтр применяется по одному значению курса, это значение можно использовать в выражении меры для преобразования значений продаж.

Параметр Power BI Desktop what-if — это функция, которая создает отключенную таблицу. Дополнительные сведения см. в статье Создание и использование параметров What if для визуализации переменных в Power BI Desktop.

Свойства связи

Связь модели связывает один столбец таблицы с одним столбцом в другой таблице. (Существует один специализированный случай, когда это требование не соответствует действительности, и оно применяется только к связям с несколькими столбцами в моделях DirectQuery. Дополнительные сведения см. в статье о функции CO МБ INEVALUES DAX.)

Примечание.

Невозможно связать столбец с другим столбцом в одной таблице. Эта концепция иногда путается с возможностью определения ограничения внешнего ключа реляционной базы данных, ссылающегося на таблицу. Эту концепцию реляционной базы данных можно использовать для хранения отношений "родитель — потомок"(например, каждую запись сотрудника связать с руководителем). Однако нельзя использовать связи модели для создания иерархии моделей на основе этого типа отношений. Сведения о создании иерархии "родитель — потомок" см. в разделе Родительские и дочерние функции.

Типы данных столбцов

Тип данных для столбца "from" и "to" связи должен совпадать. Работа с связями, определенными в столбцах DateTime , может не вести себя должным образом. Подсистема, в которой хранятся данные Power BI, использует только типы данных DateTime ; Типы данных даты, времени и даты и часового пояса — это конструкции форматирования Power BI, реализованные поверх. Все объекты, зависящие от модели, по-прежнему будут отображаться как DateTime в обработчике (например, связи, группы и т. д.). Таким образом, если пользователь выбирает дату на вкладке "Моделирование" для таких столбцов, они по-прежнему не регистрируются в качестве той же даты, так как часть времени данных по-прежнему рассматривается подсистемой. Дополнительные сведения о том, как обрабатываются типы даты и времени. Чтобы исправить поведение, типы данных столбцов должны быть обновлены в Редактор Power Query, чтобы удалить часть времени из импортированных данных, поэтому при обработке данных подсистемой значения будут одинаковыми.

Кратность

Связь между моделями определяется типом кратности. Существует четыре параметра типа карта inality, представляющих характеристики данных связанных столбцов "from" и "to". Сторона "одна" означает, что столбец содержит уникальные значения; Сторона "многие" означает, что столбец может содержать повторяющиеся значения.

Примечание.

Если операция обновления данных пытается загрузить повторяющиеся значения в "один" боковой столбец, все обновление данных завершится ошибкой.

Четыре варианта типа вместе с их сокращениями:

• Один ко многим (1:*)
• Многие к одному (*:1)
• Один к одному (1:1)
• Многие ко многим (*:*)

При создании связи в Power BI Desktop конструктор автоматически обнаруживает и устанавливает тип кратности. Power BI Desktop запрашивает модель, чтобы узнать, какие столбцы содержат уникальные значения. Для моделей импорта используется внутренняя статистика хранилища; для моделей DirectQuery он отправляет запросы профилирования в источник данных. Однако иногда Power BI Desktop может неправильно определить кратность. Это происходит потому, что в таблицы еще не загружены данные или в столбцах, где должны содержаться повторяющиеся значения, сейчас содержатся уникальные значения. В любом случае можно обновить тип карта inality, если любые "один" побочные столбцы содержат уникальные значения (или таблица еще не загружена с строками данных).

Кратность "один ко многим" (и "многие к одному")

Варианты "один ко многим" и "многие ко многим" карта inality по сути одинаковы, и они также являются наиболее распространенными типами карта inality.

При настройке связи "один ко многим" или "многие к одному" можно выбрать ту, которая соответствует порядку, в котором связаны столбцы. Рассмотрим, как настроить связь из таблицы Product в таблицу Sales с помощью столбца ProductID, найденного в каждой таблице. Тип карта inality будет один ко многим, так как столбец ProductID в таблице Product содержит уникальные значения. Если вы связаны таблицы в обратном направлении, продажи к продукту, то карта inality будет много к одному.

Кратность "один к одному"

Связь один к одному означает, что оба столбца содержат уникальные значения. Этот тип карта inality не является общим и, скорее всего, представляет собой неоптимальную модель из-за хранения избыточных данных.

Дополнительные сведения об использовании этого типа карта inality см. в руководстве по отношениям "один к одному".

Кратность "многие ко многим"

Связь многие ко многим означает, что все столбцы содержат дублирующиеся значения. Этот тип карта inality редко используется. Обычно это полезно при разработке сложных требований к модели. Ее можно использовать для связи фактов "многие ко многим" или для связи с более фактами с более высокой степенью детализации. Например, когда целевые факты о продажах хранятся на уровне категории продуктов, а таблица измерения продукта хранится на уровне продукта.

Рекомендации по использованию этого типа карта inality см. в руководстве по связям "многие ко многим".

Примечание.

Тип карта типа "многие ко многим" поддерживается для моделей, разработанных для Сервер отчетов Power BI января 2024 года и более поздних версий.

Совет

В представлении модели Power BI Desktop можно выяснить тип кратности связи, просмотрев индикаторы (1 или *) с любой стороны линии связи. Чтобы определить, какие столбцы связаны, необходимо выбрать или навести курсор на курсор, чтобы выделить столбцы.

Направление перекрестной фильтрации

Каждая связь модели определяется направлением перекрестной фильтрации. Выбор определяет направления, в которых будут распространяться фильтры. Возможные параметры перекрестного фильтра зависят от типа карта inality.

Тип кратности	Параметры перекрестного фильтра
Один ко многим (или ко многим)	Одна Оба
Взаимно-однозначный	Оба
Многие ко многим	Single (Table1 to Table2) Single (Table2 to Table1) Оба

Направление единого перекрестного фильтра означает "одно направление", а оба — "оба направления". Связь, которая фильтрует в обоих направлениях, обычно описывается как двунаправленная.

Для связей типа "один ко многим" направление перекрестной фильтрации всегда исходит с одной стороны, а при необходимости — с нескольких сторон (двунаправленная). Для связей типа "один к одному" направление перекрестной фильтрации всегда исходит от всех таблиц. Наконец, для связей "многие ко многим" направление перекрестной фильтрации может исходить либо от одной из таблиц, либо от всех. Обратите внимание, что если тип карта inality включает "одну" сторону, то фильтры всегда будут распространяться с этой стороны.

Если для направления перекрестного фильтра задано значение "Оба", другое свойство становится доступным. используя которое вы сможете применять двунаправленную фильтрацию, когда Power BI задействует правила безопасности на уровне строк (RLS). Дополнительные сведения о RLS см. в разделе "Безопасность на уровне строк" (RLS) с помощью Power BI Desktop.

Вы можете изменить направление перекрестной фильтрации связи, включая отключение распространения фильтров, с помощью вычисления модели. Он достигается с помощью функции CROSSFILTER DAX.

Имейте в виду, что двунаправленные связи могут негативно сказаться на производительности. Кроме того, попытка настроить двунаправленную связь может привести к неоднозначным путям распространения фильтров. В этом случае Power BI Desktop может не зафиксировать изменение связи и предупредит вас об ошибке. Однако иногда Power BI Desktop позволяет определять неоднозначные пути связи между таблицами. Устранение неоднозначности пути связи описано далее в этой статье.

Рекомендуется использовать двунаправленную фильтрацию только по мере необходимости. Дополнительные сведения см . в руководстве по двунаправленным отношениям.

Совет

В представлении модели Power BI Desktop можно интерпретировать направление перекрестной фильтрации связи, замечая стрелки вдоль линии связи. Одна стрелка представляет фильтр с одним направлением в направлении стрелки; двойная стрелка представляет двунаправленную связь.

Активировать связь

Существует только один активный путь распространения фильтров между двумя таблицами моделей. Однако можно ввести дополнительные пути связи, хотя эти связи необходимо задать как неактивные. Неактивные связи могут быть активны только во время оценки вычисления модели. Он достигается с помощью функции USERELATIONSHIP DAX.

Как правило, мы рекомендуем определять активные связи всякий раз, когда это возможно. Они расширяют область применения и потенциальные возможности авторов отчетов по использованию вашей модели. Использование только активных связей означает, что таблицы ролевых измерений должны дублироваться в модели.

Однако в определенных обстоятельствах для таблицы ролевых измерений можно определить одну или несколько неактивных связей. Использование такой структуры можно рассматривать в следующих случаях.

• Визуальные элементы отчетов не обязательно должны одновременно выполнять фильтрацию по различным ролям.
• Вы используете функцию DAX USERELATIONSHIP, чтобы активировать определенную связь для соответствующих вычислений модели.

Дополнительные сведения см . в руководстве по активной и неактивной связи.

Совет

В представлении модели Power BI Desktop можно интерпретировать активное состояние связи и неактивное состояние. Активная связь представлена сплошной линией; Неактивная связь представлена в виде дефисной линии.

Предполагать целостность данных

Свойство Предполагать целостность данных доступно только для связей типа "одна ко многим" и "одна к одной" между двумя таблицами с режимом хранения DirectQuery, относящихся к одной и той же исходной группе. Это свойство можно включить только в том случае, если в боковом столбце "многие" нет NULLs.

Если это свойство включено, собственные запросы, отправляемые к источнику данных, объединят две таблицы с использованием семантики INNER JOIN, а не OUTER JOIN. Как правило, включение этого свойства повышает производительность запросов, хотя оно зависит от особенностей источника данных.

Всегда включите это свойство, если ограничение внешнего ключа базы данных существует между двумя таблицами. Даже если такого ограничения нет, все равно можно включить свойство при условии наличия определенной целостности данных.

Внимание

Если целостность данных должна стать скомпрометированной, внутреннее соединение устраняет несовпаденные строки между таблицами. Например, рассмотрим таблицу sales модели со значением столбца ProductID, который не существовал в связанной таблице Product. Фильтрация распространения из таблицы Product в таблицу Sales приведет к устранению строк продаж для неизвестных продуктов. Это приведет к недоумению результатов продаж.

Дополнительные сведения см. в разделе "Предположим, что параметры целостности данных" в Power BI Desktop.

Соответствующие функции DAX

Существует несколько функций DAX, относящихся к отношениям модели. Каждая функция описывается кратко в следующем маркированном списке:

• RELATED: извлекает значение из "одной" стороны связи. Это полезно при использовании вычислений из разных таблиц, которые вычисляются в контексте строки.
• RELATEDTABLE: получение таблицы строк из "многие" связи.
• USERELATIONSHIP: позволяет вычислению использовать неактивную связь. (Технически эта функция изменяет вес определенной неактивной модели, помогающей влиять на его использование.) Это полезно, если модель включает таблицу измерений с ролью, и вы решили создать неактивные связи из этой таблицы. Эту функцию также можно использовать для разрешения неоднозначности в путях фильтрации.
• CROSSFILTER: изменяет направление перекрестного фильтра связи (на одно или оба), или отключает распространение фильтра (нет). Это полезно, если необходимо изменить или игнорировать связи модели во время оценки определенного вычисления.
• CO МБ INEVALUES: объединяет две или несколько текстовых строк в одну текстовую строку. Эта функция предназначена для поддержки связей с несколькими столбцами в моделях DirectQuery, когда таблицы принадлежат одной исходной группе.
• TREATAS: применяет результат табличного выражения в качестве фильтров к столбцам из не связанной таблицы. Это полезно в сложных сценариях, когда вы хотите создать виртуальную связь во время оценки определенного вычисления.
• Родительские и дочерние функции: семейство связанных функций, которые можно использовать для создания вычисляемых столбцов для натурализации иерархии родительского-дочернего элемента. Затем эти столбцы можно использовать для создания иерархии фиксированного уровня.

Оценка связей

Отношения модели, с точки зрения оценки, классифицируются как обычные или ограниченные. Это не настраиваемое свойство связи. Фактически он выводится из типа карта inality и источника данных двух связанных таблиц. Важно понимать тип оценки, так как могут возникнуть последствия или последствия производительности, если целостность данных будет скомпрометирована. Эти последствия и последствия целостности описаны в этом разделе.

Во-первых, для полного понимания оценки связей требуется некоторая теория моделирования.

Модель импорта или DirectQuery источники всех своих данных из кэша Vertipaq или исходной базы данных. В обоих случаях Power BI может определить, что существует "одна" сторона связи.

Однако составная модель может содержать таблицы с помощью различных режимов хранения (импорт, DirectQuery или двойной) или нескольких источников DirectQuery. Каждый источник, включая кэш Vertipaq импортированных данных, считается исходной группой. Затем связи модели можно классифицировать как внутри исходной илимеж исходной группы. Связь внутри исходной группы связана с двумя таблицами в исходной группе, а связь между исходными группами связывает таблицы между двумя исходными группами. Обратите внимание, что связи в моделях импорта или DirectQuery всегда находятся внутри исходной группы.

Ниже приведен пример составной модели:

В этом примере составная модель состоит из двух исходных групп: исходной группы Vertipaq и исходной группы DirectQuery. Исходная группа Vertipaq содержит три таблицы, а исходная группа DirectQuery содержит две таблицы. Одна связь между исходными группами существует для связи таблицы в исходной группе Vertipaq с таблицей в исходной группе DirectQuery.

Регулярные связи

Связь модели является регулярной , когда обработчик запросов может определить "одну" сторону связи. Он подтверждает, что "один" боковой столбец содержит уникальные значения. Все отношения типа "одно ко многим" внутри исходной группы являются обычными.

В следующем примере есть две регулярные связи, которые помечены как R. Связи включают связь "один ко многим", содержащуюся в исходной группе Vertipaq, и связь "один ко многим", содержащаяся в источнике DirectQuery.

Для моделей импорта, где все данные хранятся в кэше Vertipaq, Power BI создает структуру данных для каждой регулярной связи во время обновления данных. Структуры данных состоят из индексированных сопоставлений всех значений столбцов и их назначение — ускорить присоединение таблиц во время запроса.

Во время запроса регулярные связи позволяют выполнять расширение таблицы. Расширение таблицы приводит к созданию виртуальной таблицы, включив собственные столбцы базовой таблицы, а затем расширяя связанные таблицы. Для импорта таблиц расширение таблицы выполняется в обработчике запросов; для таблиц DirectQuery он выполняется в собственном запросе, который отправляется в исходную базу данных (если свойство "Предположим, целостность ссылок" не включено). Затем обработчик запросов действует в развернутой таблице, применяя фильтры и группирование по значениям в развернутых столбцах таблицы.

Примечание.

Неактивные связи также расширяются, даже если связь не используется вычислением. Двунаправленные связи не влияют на расширение таблицы.

Для связей типа "один ко многим" расширение таблицы происходит с нескольких сторон к одной с использованием семантики LEFT OUTER JOIN. Если соответствующее значение от "многие" к "одной" стороне не существует, в боковую таблицу добавляется пустая виртуальная строка. Это поведение применяется только к обычным связям, а не к ограниченным связям.

Расширение таблицы также происходит для связей типа "одна к одной" внутри исходной группы, но с использованием семантики FULL OUTER JOIN. Такое соединение гарантирует, что при необходимости пустые виртуальные строки добавятся с необходимой стороны.

Пустые виртуальные строки фактически неизвестны. Неизвестные члены представляют нарушения целостности ссылок, в которых значение "многие" сторон не имеет соответствующего "одного" бокового значения. В идеале эти пустые не должны существовать. Их можно исключить путем очистки или исправления исходных данных.

Ниже показано, как расширение таблицы работает с анимированным примером.

В этом примере модель состоит из трех таблиц: "Категория", "Продукт" и "Продажи". Таблица "Категория" относится к таблице Product с отношением "Один ко многим", а таблица "Продукт" относится к таблице Sales с отношением "Один ко многим". Таблица "Категория " содержит две строки, таблица Product содержит три строки, а таблицы Sales содержат пять строк. На обеих сторонах всех связей имеются соответствующие значения, что означает отсутствие нарушений целостности ссылочной связи. Отображается развернутая таблица во время запроса. Таблица состоит из столбцов из всех трех таблиц. Фактически это денормализованная перспектива данных, содержащихся в трех таблицах. Новая строка добавляется в таблицу Sales и имеет значение производственного идентификатора (9), которое не имеет соответствующего значения в таблице Product . Это нарушение целостности ссылок. В развернутой таблице новая строка имеет значения (пустое) для столбцов таблицы "Категория " и "Продукт ".

Ограниченные связи

Связь модели ограничена , если нет гарантированной "одной" стороны. Ограниченная связь может произойти по двум причинам:

• Связь использует тип кратности "многие ко многим" (даже если в одном или всех столбцах содержатся уникальные значения).
• Связь является межэлементной (что может быть только в случае с составными моделями).

В следующем примере есть две ограниченные связи, которые помечены как L. Две связи включают связь "многие ко многим", содержащуюся в исходной группе Vertipaq, и связь "один ко многим" между исходными группами.

Для моделей импорта структуры данных никогда не создаются для ограниченных связей. В этом случае Power BI разрешает соединения таблиц во время запроса.

Расширение таблицы никогда не происходит для ограниченных связей. Соединения таблиц достигаются с помощью семантики INNER JOIN , и по этой причине пустые виртуальные строки не добавляются для компенсации нарушений целостности ссылок.

Существуют другие ограничения, связанные с ограниченными связями:

• Функцию DAX RELATED нельзя использовать для получения значений столбца одной стороны.
• Существуют ограничения топологии при принудительном применении RLS.

Совет

В представлении модели Power BI Desktop можно интерпретировать связь как ограниченную. Ограниченная связь представлена с круглыми знаками () после индикаторов карта inality.

Разрешение неоднозначности пути связи

Двунаправленные связи могут приводить к нескольким и, следовательно, неоднозначным путям распространения фильтров между таблицами модели. При оценке неоднозначности Power BI выбирает путь распространения фильтра в соответствии с приоритетом и весом.

Приоритет

Уровни приоритетов определяют последовательность правил, которые Power BI использует для разрешения неоднозначности пути связи. Первое соответствие правил определяет путь Power BI. Каждое правило, приведенное ниже, описывает поток фильтров из исходной таблицы в целевую таблицу.

1. Путь, состоящий из связей "один ко многим".
2. Путь, состоящий из связей "один ко многим" или "многие ко многим".
3. Путь, состоящий из связей "многие ко одному".
4. Путь, состоящий из связей "один ко многим" из исходной таблицы в промежуточную таблицу, за которой следует связи "многие ко одному" из промежуточной таблицы в целевую таблицу.
5. Путь, состоящий из связей "один ко многим" или "многие ко многим" из исходной таблицы в промежуточную таблицу, за которой следует связь "многие ко многим" или "ко многим" из промежуточной таблицы в целевую таблицу.
6. Любой другой путь.

Если связь включена во все доступные пути, она удаляется из рассмотрения из всех путей.

Вес

Каждая связь в пути имеет вес. По умолчанию каждый вес связи равен, если функция USERELATIONSHIP не используется. Вес пути — это максимальное количество всех весов связи вдоль пути. Power BI использует весы путей для разрешения неоднозначности между несколькими путями в одном и том же уровне приоритета. Он не выберет путь с более низким приоритетом, но он выберет путь с более высоким весом. Количество связей в пути не влияет на вес.

Вы можете повлиять на вес связи с помощью функции USERELATIONSHIP . Вес определяется уровнем вложенности вызова этой функции, где самый внутренний вызов получает самый высокий вес.

Рассмотрим следующий пример. Мера "Продажи продукта" назначает более высокий вес связи между Sales[ProductID] и Product[ProductID], а затем связью между Инвентаризацией[ProductID] и Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Примечание.

Если Power BI обнаруживает несколько путей с одинаковым приоритетом и одинаковым весом, он вернет неоднозначную ошибку пути. В этом случае необходимо устранить неоднозначность, влияя на весы связи с помощью функции USERELATIONSHIP , или путем удаления или изменения связей модели.

Предпочтения производительности

В следующем списке производительность фильтрации заказов выполняется от самых быстрых до самых медленных показателей производительности:

1. Связи одно ко многим внутри исходной группы
2. Связи модели "многие ко многим", полученные с использованием промежуточной таблицы, у которой есть хотя бы одна двунаправленная связь.
3. Связи "многие ко многим" карта inality
4. Связи между исходными группами

Связанный контент

Дополнительные сведения об этой статье проверка следующих ресурсов:

• Общие сведения о схеме звезд и важности Power BI
• Руководство по отношениям "один к одному"
• Руководство по связям "многие ко многим"
• Руководство по активной и неактивной связи
• Руководство по двунаправленным отношениям
• Руководство по устранению неполадок связи
• Видео: Do's и do's ts of Power BI Relationships
• Вопросы? Задайте их в сообществе Power BI.
• Есть предложения? Участие в разработке идей по улучшению Power BI