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

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

Примечание.

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

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

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

Существует три сценария, когда двунаправленная фильтрация может решить определенные требования:

• Специальные связи модели
• Элементы среза "с данными"
• Анализ измерения к измерению

Специальные связи модели

Двунаправленные связи играют важную роль при создании следующих двух специальных типов отношений модели:

• Один к одному: все связи "один к одному" должны быть двунаправленными— невозможно настроить в противном случае. Как правило, мы не рекомендуем создавать эти типы связей. Полные обсуждения и альтернативные проекты см . в руководстве по отношениям "один к одному".
• Многие ко многим: при связывании двух таблиц типов измерений требуется бриджинговая таблица. Требуется двунаправленный фильтр, чтобы обеспечить распространение фильтров по всей таблице бриджинга. Дополнительные сведения см. в руководстве по связям "многие ко многим" (отношение "многие ко многим")

Элементы среза "с данными"

Двунаправленные связи могут доставлять срезы, ограничивающие элементы, в которых существуют данные. (Если вы знакомы с сводными таблицами Excel и срезами, это поведение по умолчанию при выборе данных из семантической модели Power BI или модели служб Analysis Services.) Чтобы объяснить, что это означает, сначала рассмотрим следующую схему модели.

Первая таблица называется Customer и содержит три столбца: Country-Region, Customer и CustomerCode. Вторая таблица называется Product, и она содержит три столбца: Color, Product и SKU. Третья таблица называется Sales, и она содержит четыре столбца: CustomerCode, OrderDate, Quantity и SKU. Таблицы "Клиент" и "Продукт" — это таблицы типов измерений, и каждая из них имеет отношение "один ко многим" к таблице Sales. Каждый фильтр связей выполняется в одном направлении.

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

Примечание.

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

Сведения о строке для трех таблиц описаны в следующем маркированном списке:

• В таблице Customer есть две строки:
  • CustomerCode CUST-01, Customer-1, Country-Region США
  • CustomerCode CUST-02, Customer-2 , Country-Region Australia
• Таблица Product содержит три строки:
  • SKU CL-01, футболка продукта , цвет зеленый
  • SKU CL-02, Product Jeans, Color Blue
  • SKU AC-01, Product Hat, Color Blue
• Таблица Sales содержит три строки:
  • OrderDate 1 января 2019 г., CustomerCode CUST-01, SKU CL-01, Количество 10
  • OrderDate 2 февраля 2019 года, CustomerCode CUST-01, SKU CL-02, Количество 20
  • OrderDate 3 марта 2019 г., CustomerCode CUST-02, SKU CL-01, Количество 30

Теперь рассмотрим следующую страницу отчета.

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

Когда пользователи отчетов срезают Австралию, может потребоваться ограничить срез продукта , чтобы отобразить элементы, в которых данные относятся к австралийским продажам. Это то, что означает отображение элементов среза "с данными". Это поведение можно достичь, настроив связь между таблицей Product и Sales для фильтрации в обоих направлениях.

Срез продукта теперь содержит один элемент: футболку. Этот элемент представляет единственный продукт, проданный австралийским клиентам.

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

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

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

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

Total Quantity = SUM(Sales[Quantity])

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

Анализ измерения к измерению

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

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

• Сколько цветов было продано австралийским клиентам?
• Сколько стран или регионов приобрели джинсы?

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

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

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

Рассмотрим следующее определение меры, добавленное в таблицу Sales . В этом примере связь модели между таблицами Customer и Sales настроена для фильтрации в одном направлении.

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

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

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

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

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

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