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

Руководство по активной и неактивной связи

  • Статья

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

Примечание.

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

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

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

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

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

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

Diagram showing a model containing two tables: Flight and Airport. The relationship design is described in the following paragraph.

Между таблицами "Полет " и "Аэропорт " существуют две модели. В таблице "Рейс" столбцы "Вылетаэрпорт" и "Приезд" относятся к столбцу "Аэропорт" таблицы "Аэропорт". В схеме звездочки таблица "Аэропорт " описывается как измерение воспроизведения ролей. В этой модели две роли — аэропорт вылета и аэропорт прибытия.

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

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

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

Diagram showing a model containing four tables: Date, Flight, Departure Airport, and Arrival Airport.

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

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

Diagram showing a report page has two slicers and a table visual. The slicers are Month and Departure Airport.

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

Примечание.

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

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

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

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

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

  2. Рекомендуется переименовать таблицу типа измерения ролей, чтобы лучше описать ее роль. В примере таблица "Аэропорт" связана со столбцом "Прибытие" таблицы Flight, поэтому она переименована в аэропорт прибытия.

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

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

    Departure Airport = 'Arrival Airport'

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

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

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

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

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

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

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

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

Diagram showing a model containing two tables: Sales and Date. The Sales table includes six measures.

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

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

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

Orders = COUNTROWS(Sales)

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

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

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

Diagram showing a report page with one slicer and a table visual. The slicer is Quarter, and the table visual lists monthly sales statistics.

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

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

Примечание.

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

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

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

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

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

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

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