Связи, кардинальность и направление фильтра

Разбираем три свойства связи: кардинальность, направление фильтра и активность.

Связь (relationship) соединяет столбец одной таблицы со столбцом другой, позволяя фильтрам и расчётам перетекать между ними.

Как создаётся связь

В представлении «Модель» вы тянете линию от ключа одной таблицы к ключу другой — например, Sales[product_id] к Product[id]. Power BI часто угадывает связи автоматически по совпадающим именам, но проверять их обязательно: неверная связь молча искажает все числа.

Кардинальность

Кардинальность описывает, сколько строк с одной стороны соответствует строкам с другой.

ТипСмыслПример
Один-ко-многим (1:*)одна строка справочника — много фактоводин товар — много продаж
Многие-к-одному (*:1)то же, с другой сторонымного продаж — один товар
Один-к-одному (1:1)строго по одной с каждой сторонысотрудник — его профиль
Многие-ко-многим (*:*)повторы с обеих сторонопасный случай, требует осторожности

Правильная звезда почти всегда даёт связи один-ко-многим: «одна» сторона — измерение, «много» — факты. Если Power BI ставит «многие-ко-многим», это сигнал: ключ в измерении не уникален, и модель нужно чинить.

Направление фильтра

Это самое тонкое свойство. Связь имеет направление фильтрации — куда «течёт» фильтр.

Одно-направленное (по умолчанию, правильно):
   Product ──фильтр──> Sales       выбрал товар → отфильтровались продажи
   (фильтр от измерения к фактам, обратно — нет)

Дву-направленное (осторожно!):
   Product <──фильтр──> Sales       фильтр течёт в обе стороны
   (нужно редко, легко создать неоднозначность)

По умолчанию фильтр идёт от измерения к фактам — этого достаточно в 95% случаев. Двунаправленную фильтрацию включают только в особых сценариях (например, фильтр одного среза по наличию фактов), и она часто порождает неоднозначность и ошибки. Правило профессионала: не включай двунаправленность без явной необходимости.

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

Между двумя таблицами может быть несколько связей, но активной (по которой фильтры текут по умолчанию) может быть только одна — она рисуется сплошной линией. Пример: у заказа есть «дата заказа» и «дата отгрузки», обе ссылаются на таблицу Date. Активной делают одну, вторую — неактивной (пунктир), и обращаются к ней в DAX через функцию USERELATIONSHIP при необходимости.

Как работает под капотом

Связь — это не физическое соединение строк, а правило для движка: при расчёте меры фильтры с «одной» стороны автоматически сужают «многую» сторону. Внутри VertiPaq хранит для связи отображение ключей, чтобы мгновенно понимать, какие строки фактов соответствуют выбранным строкам измерения. Неоднозначные пути (несколько связей между таблицами) движок разрешать не умеет — отсюда требование одной активной связи.

Частые ошибки

  • Связь по неуникальному ключу. Даёт «многие-ко-многим» и неверные агрегаты — измерение должно иметь уникальный ключ.
  • Включать двунаправленность «на всякий случай». Создаёт неоднозначность и трудноуловимые ошибки в мерах.
  • Забыть про активную связь при двух датах. Расчёт пойдёт по «дате заказа», хотя нужна «дата отгрузки».

Итог

  • Кардинальность правильной звезды — один-ко-многим (измерение → факты).
  • Направление фильтра по умолчанию одностороннее; двунаправленность — только осознанно.
  • Активная связь одна; вторую используют через USERELATIONSHIP.
Проверьте себя
1. Какая кардинальность типична для правильной звезды (измерение → факты)?
AМногие-ко-многим
BОдин-ко-многим
CОдин-к-одному
DНет связи
2. Почему не стоит включать двунаправленную фильтрацию без необходимости?
AОна ускоряет отчёт
BОна часто создаёт неоднозначность и ошибки в мерах
CPower BI её не поддерживает
DОна удаляет связи