Применение связей "многие ко многим" в Power BI Desktop

  • Статья

С помощью связей с карта карта inality в Power BI Desktop можно объединить таблицы, использующие карта инальностьмногих к многим. Вы можете легко и интуитивно создавать модели данных, содержащие два или более источников данных. Связи с много-многими карта inality являются частью более крупных составных моделей в Power BI Desktop. Дополнительные сведения о составных моделях см. в разделе "Использование составных моделей в Power BI Desktop"

Screenshot of a many-to-many relationship in the Edit relationship pane.

Что такое связь с карта-многие решения

Прежде чем отношения с карта-многие стали доступными, связь между двумя таблицами была определена в Power BI. По крайней мере один из столбцов таблицы, участвующих в связи, должен содержать уникальные значения. Зачастую столбцы не содержат уникальных значений.

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

Использование связей с карта инальностью "многие ко многим"

При определении связи между двумя таблицами в Power BI необходимо определить карта винальность связи. Например, связь между ProductSales и Product —с помощью столбцов ProductSales[ProductCode] и Product[ProductCode]— будет определена как Многие-1. Таким образом мы определяем связь, так как каждый продукт имеет много продаж, а столбец в таблице Product (ProductCode) является уникальным. При определении связи карта inality как многие, 1-Многие или 1-1 Power BI проверяет его, поэтому карта inality, который вы выбираете, соответствует фактическим данным.

Например, взгляните на простую модель на этом изображении:

Screenshot of ProductSales and Product table in Relationship view.

Теперь представьте, что таблица Product отображает только две строки, как показано ниже.

Screenshot of a Product table visual with two rows.

Кроме того, представьте, что в таблице Sales есть всего четыре строки, включая строку для продукта C. Из-за ошибки целостности ссылок строка C продукта не существует в таблице Product .

Screenshot of a Sales table visual with four rows.

Имя продукта и цена (из таблицы Product), а также общее количество Qty для каждого продукта (из таблицы ProductSales), будет отображаться, как показано ниже.

Screenshot of a Visual displaying the product name, price, and quantity.

Как видно на предыдущем рисунке, пустая строка ProductName связана с продажами для продукта C. Эта пустая строка учитывает следующие аспекты:

  • Все строки в таблице ProductSales, для которой в таблице ProductSales нет соответствующей строки. Существует проблема с целостностью ссылок, как мы видим для продукта C в этом примере.

  • Все строки в таблице ProductSales , для которой столбец внешнего ключа имеет значение NULL.

По этим причинам пустая строка в обоих случаях учитывает продажи, где имя продукта и цена неизвестны.

Иногда таблицы объединяются двумя столбцами, но ни столбец не является уникальным. Например, рассмотрим следующие две таблицы:

  • В таблице "Продажи" отображаются данные о продажах по состоянию, а каждая строка содержит сумму продаж для типа продажи в этом состоянии. К состояниям относятся ЦС, WA и TX.

    Screenshot of a Sales table displaying sales by state.

  • В таблице CityData отображаются данные о городах, включая население и состояние (например, CA, WA и Нью-йорк).

    Screenshot of a Sales table displaying city, state, and population.

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

Предыдущее решение

До выпуска Power BI Desktop за июль 2018 г. невозможно создать прямую связь между этими таблицами. Обычное решение заключается в том, чтобы:

  • Создайте третью таблицу, содержащую только уникальные идентификаторы состояния. Таблица может быть любой или любой из следующих:

    • Вычисляемая таблица (определяемая с помощью выражений анализа данных [DAX]).
    • Таблица на основе запроса, который определен в Редакторе Power Query; он может отображать уникальные идентификаторы, извлеченные из одной из таблиц.
    • Объединенный полный набор.

  • Затем соотносите две исходные таблицы с этой новой таблицей с помощью общих связей "Многие-1 ".

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

Screenshot of a hidden State table in Relationship view.

Визуальный элемент, отображающий состояние (из таблицы CityData), а также общее население и общее количество продаж, будет отображаться следующим образом:

Screenshot showing a table with State, Population, and Sales data.

Примечание.

Так как состояние из таблицы CityData используется в этом обходном пути, отображаются только состояния в этой таблице, поэтому TX исключается. Кроме того, в отличие от связей "Многие-1 ", в то время как общая строка включает все продажи (включая TX), сведения не содержат пустой строки, охватывающие такие несовпадения строк. Аналогичным образом, пустая строка не будет охватывать продажи , для которых имеется значение NULL для состояния.

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

Screenshot of a table showing State and city population and sales.

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

Screenshot of a visual showing State, population, and sales visual.

Как видно, TX с данными о продажах, но неизвестными данными о популяции ( и Нью-йорке) с известными данными о населении, но не будут включены данные о продажах. Это решение не является оптимальным, и у него есть много проблем. Для связей с карта-многие проблемы устраняются, как описано в следующем разделе.

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

Используйте связь с карта-многие вместо обходного решения

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

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

Например, при создании связи непосредственно между CityData и Sales ( где фильтры должны передаваться из CityData в Sales— Power BI Desktop отображает диалоговое окно "Изменить связь ":

Screenshot of the Edit relationship dialog box with Cardinality and Cross filter direction highlighted.

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

Screenshot of a State, Population, and Sales table.

Основные различия между отношениями с карта-многие карта inality и более типичными отношениями "Многие-1", как показано ниже.

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

  • Вы не можете использовать функцию RELATED() , так как может быть связана несколько строк.

  • ALL() Использование функции в таблице не удаляет фильтры, применяемые к другим связанным таблицам с помощью связи "многие ко многим". В предыдущем примере мера, определяемая здесь, не удаляет фильтры для столбцов в связанной таблице CityData:

    Screenshot of a script example. The example is, Sales total = Calculate(Sum('Sales'[Sales]), All('Sales')).

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

    Screenshot of a table visual showing State, Sales, and Sales total resulting from the formula.

Учитывая предыдущие различия, убедитесь, что используемые вычисления ALL(<Table>), такие как % общего объема, возвращают предполагаемые результаты.

Рекомендации и ограничения

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

Следующие источники live Подключение (многомерные) нельзя использовать с составными моделями:

  • SAP HANA
  • Хранилище SAP для бизнеса
  • SQL Server Analysis Services
  • Семантические модели Power BI
  • Azure Analysis Services

При подключении к этим многомерным источникам с помощью DirectQuery невозможно подключиться к другому источнику DirectQuery или объединить его с импортированными данными.

Существующие ограничения использования DirectQuery по-прежнему применяются при использовании связей с множеством ко многим карта inality. Теперь для каждой таблицы существует множество ограничений в зависимости от режима хранения таблицы. Например, вычисляемый столбец импортированной таблицы может ссылаться на другие таблицы, но вычисляемый столбец в таблице DirectQuery по-прежнему может ссылаться только на столбцы в той же таблице. Другие ограничения применяются ко всей модели, если какие-либо таблицы в модели являются DirectQuery. Например, функции Quick Аналитика и Q&A недоступны в модели, если в ней есть режим хранения DirectQuery.

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

Дополнительные сведения о составных моделях и DirectQuery см. в следующих статьях: