← Все курсы · Курс Power BI

Отношения «многие ко многим» в Power BI и почему итоговые значения становятся странными

Майкл Носито · Обновлено в августе 2026 г. · Все числа на этой странице были обработаны до их публикации.

Вы перетаскиваете две таблицы вместе, Power BI объявляет об отношении «многие ко многим», и вы щелкаете по ним. Визуализация работает. Затем кто-то замечает, что общие показатели региона превышают общие показатели компании.

Что вы делаете: добавляете таблицу-мост. Связь «многие-ко-многим» почти всегда является признаком отсутствия таблицы в модели, а не того, что вам нужна более продуманная настройка отношений.

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

Что происходит на самом деле

Предполагать Sales имеет product_code это повторяется, и ProductNotes также имеет product_code повторяется, поскольку на каждую ноту приходится одна строка. Ни одна из сторон не является уникальной, поэтому при применении фильтра Power BI не может определить, какие строки на дальней стороне он означает.

Последствий три, и это диагноз:

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

Стол для бриджа

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

Products = DISTINCT(UNION(
    SELECTCOLUMNS(Sales,        "product_code", Sales[product_code]),
    SELECTCOLUMNS(ProductNotes, "product_code", ProductNotes[product_code])
))

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

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

Законные случаи «многие ко многим»

Некоторые деловые отношения действительно основаны на принципах «многие ко многим», и мост по-прежнему является ответом:

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

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

Двунаправленная фильтрация

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

Отдавайте предпочтение односторонней модели и целенаправленным мерам там, где вам действительно необходимо обратное направление:

Customers with sales =
CALCULATE(
    DISTINCTCOUNT(Customers[customer_id]),
    CROSSFILTER(Sales[customer_id], Customers[customer_id], BOTH)
)

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

Как применить это в своей работе

1. Откройте представление модели и просмотрите каждую линию связи. Любой вариант, отмеченный звездочкой на обоих концах, представляет собой соединение «многие ко многим».
2. Для каждого спросите, какой таблице должен принадлежать список ключей. Эта таблица — ваш мост, и, возможно, она уже существует.
3. Проверьте каждый срез на наличие пустого элемента. Каждое из них представляет собой ключевое несоответствие, которое стоит изучить.
4. Проверьте итоги: поместите разбивку по категориям и общую сумму на одну страницу и подтвердите, что они согласны, или укажите, почему они не согласны.
5. Замените двунаправленные отношения на CROSSFILTER внутри мер, которые в этом нуждаются.

Единственная привычка, которую нужно сохранить

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

Соответствует ли общая сумма на вашей главной странице сумме строк над ней?