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

Руководство по активным и неактивным отношениям

  • Статья

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

Заметка

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

Важно также понимать схему звездочки. Дополнительные сведения см. в статье О понимании схемы звезды и ее важности для Power BI.

Активные связи

Как правило, мы рекомендуем по возможности определять активные связи. Они расширяют область и потенциал использования модели авторами отчетов и пользователями, работающими с Q&A.

Рассмотрим пример модели импорта , предназначенной для анализа показателей своевременности выполнения рейсов авиакомпаний (OTP). Модель имеет таблицу Flight, которая представляет собой таблицу фактов , в которой хранится одна строка для каждого полета. Каждая строка записывает дату полета, номер рейса, аэропорты вылета и прибытия, а также любое время задержки (в минутах). Существует также таблица Airport, которая представляет собой таблицу измерений , которая хранит одну строку для каждого аэропорта. Каждая строка описывает код аэропорта, имя аэропорта и страну или регион.

Ниже приведена частичная схема модели двух таблиц.

диаграмме с моделью, содержащей две таблицы:

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

Хотя эта конструкция хорошо подходит для проектов схем реляционной звезды, она не работает хорошо для моделей Power BI. Это связано с тем, что отношения модели являются путями для распространения фильтров, и эти пути должны быть детерминированными. Дополнительные сведения об обеспечении того, чтобы пути распространения фильтров были детерминированными, см. в про разрешение неоднозначности пути отношений. Таким образом, как показано в этом примере, одно отношение активно, а другое неактивно (представлено пунктирной линией). В частности, это связь с активным столбцом ArrivalAirport, что означает, что фильтры, примененные к таблице Airport, автоматически распространяются в столбец ArrivalAirport таблицы Flight.

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

Ниже приведен улучшенный дизайн модели.

Диаграмма, показывающая модель, содержащую четыре таблицы:

Модель теперь имеет две таблицы аэропортов: Departure Airport и Arrival Airport. Каждая связь модели между этими таблицами и таблицей Flight активна. Обратите внимание также, что имена столбцов в таблицах Departure Airport и Arrival Airport префиксируются словом "Отъезд" или "Прибытие".

Улучшенная модель поддерживает создание следующего проекта отчета.

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

Страница отчета фильтруется по Мельбурну как аэропорту вылета, а таблица группируется по аэропортам прибытия.

Заметка

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

Кроме того, обычно таблицы измерений хранят низкие числа строк относительно количества строк таблицы фактов. Таким образом, увеличение размера модели и время обновления, скорее всего, не будет слишком большим.

Методология рефакторинга

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

  1. Удалите все неактивные связи.

  2. Рекомендуется переименовать таблицу для ролевой игры, чтобы лучше описать её функцию. В примере в этой статье таблица Airport связана с столбцом ArrivalAirport таблицы Flight, поэтому она переименована как Arrival Airport.

  3. Создайте копию ролевой таблицы, предоставив ей имя, отражающее ее назначение. Если это таблица импорта, рекомендуется создать вычисляемую таблицу. Если это таблица DirectQuery, можно дублировать запрос Power Query.

    В примере таблица Departure Airport была создана с помощью следующего вычисляемого определения таблицы.

    Departure Airport = 'Arrival Airport'

  4. Создайте активную связь, чтобы связать новую таблицу.

  5. Рекомендуется переименовать столбцы в таблицах, чтобы они точно отражали свою роль. В примере в этой статье все столбцы префиксируются словом "Отъезд" или"Прибытие". Эти имена гарантируют, что визуальные элементы отчета по умолчанию будут иметь самописные и не неоднозначные метки. Он также улучшает интерфейс Q&A, позволяя пользователям легко писать точные вопросы.

  6. Рассмотрите возможность добавления описаний в таблицы для ролевых игр. (В области данных описание отображается в подсказке, когда автор отчета наводит указатель мыши на таблицу.) Этим способом можно сообщить авторам отчетов другие сведения о распространении фильтров.

Неактивные связи

В определенных обстоятельствах неактивные отношения могут решать конкретные потребности в отчетности.

Рассмотрите различные требования к модели и отчетам:

  • Модель продаж содержит таблицу Sales с двумя столбцами дат: OrderDate и ShipDate.
  • Каждая строка в таблице Sales записывает один порядок.
  • Фильтры дат почти всегда применяются к столбцу OrderDate, который всегда хранит допустимую дату.
  • Только одна мера требует распространения фильтра дат на столбец ShipDate, который может содержать пустые значения (пока заказ не будет отправлен).
  • Нет необходимости одновременно фильтровать (или группировать) по периодам дат отправки заказы и.

Ниже приведена частичная схема модели двух таблиц.

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

Между таблицами Sales и Date существуют две модели связи. В таблице Sales столбцы OrderDate и ShipDate относятся к столбцу Date таблицы Date. В этой модели две роли таблицы Dateдате заказа и дате доставки. Это связано с активным столбцом OrderDate.

Все шесть мер, кроме одного, должны фильтроваться по столбцу OrderDate. Однако мера Orders Shipped должна фильтроваться по столбцу ShipDate.

Ниже приведено определение меры Orders. Он просто подсчитывает строки таблицы Sales в контексте фильтра. Все фильтры, примененные к таблице Date, распространяются на столбец OrderDate.

Orders = COUNTROWS(Sales)

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

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Эта модель поддерживает создание следующего макета отчета.

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

Страница отчета фильтруется по кварталу 2019 Q4. Таблица визуально группирует по месяцам и отображает различные статистики продаж. Меры Orders и Orders Shipped дают различные результаты. Каждый из них использует одну и ту же сводную логику (подсчет строк таблицы Sales), но разное распространение фильтра по таблице Date.

Обратите внимание, что срез квартала включает параметр BLANK. Этот параметр среза появляется в результате расширения таблицы . Хотя каждая строка таблицы Sales имеет допустимую дату заказа, некоторые строки имеют пустую дату доставки— эти заказы пока не отправляются. Расширение таблицы также учитывает неактивные связи, поэтому BLANK могут появляться из-за многосторонности связи (или из-за проблем целостности данных).

Заметка

Фильтры безопасности на уровне строк (RLS) распространяются только через активные отношения. Фильтры RLS никогда не распространяются на неактивные связи, даже если в определении меры используется функция DAX USERELATIONSHIP .

Рекомендации

Рекомендуется по возможности определять активные связи, особенно если роли RLS определены для модели данных. Они расширяют область и потенциал использования модели авторами отчетов и пользователями, работающими с Q&A. Это означает, что таблицы измерений, используемые как ролевые, должны дублироваться в вашей модели.

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

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

Связанное содержимое

Дополнительные сведения, связанные с этой статьей, см. в следующих ресурсах: