Связи, кардинальность и направление фильтра
Разбираем три свойства связи: кардинальность, направление фильтра и активность.
Связь (relationship) соединяет столбец одной таблицы со столбцом другой, позволяя фильтрам и расчётам перетекать между ними.
Как создаётся связь
В представлении «Модель» вы тянете линию от ключа одной таблицы к ключу другой — например, Sales[product_id] к Product[id]. Power BI часто угадывает связи автоматически по совпадающим именам, но проверять их обязательно: неверная связь молча искажает все числа.
Кардинальность
Кардинальность описывает, сколько строк с одной стороны соответствует строкам с другой.
| Тип | Смысл | Пример |
| Один-ко-многим (1:*) | одна строка справочника — много фактов | один товар — много продаж |
| Многие-к-одному (*:1) | то же, с другой стороны | много продаж — один товар |
| Один-к-одному (1:1) | строго по одной с каждой стороны | сотрудник — его профиль |
| Многие-ко-многим (*:*) | повторы с обеих сторон | опасный случай, требует осторожности |
Правильная звезда почти всегда даёт связи один-ко-многим: «одна» сторона — измерение, «много» — факты. Если Power BI ставит «многие-ко-многим», это сигнал: ключ в измерении не уникален, и модель нужно чинить.
Направление фильтра
Это самое тонкое свойство. Связь имеет направление фильтрации — куда «течёт» фильтр.
Одно-направленное (по умолчанию, правильно): Product ──фильтр──> Sales выбрал товар → отфильтровались продажи (фильтр от измерения к фактам, обратно — нет) Дву-направленное (осторожно!): Product <──фильтр──> Sales фильтр течёт в обе стороны (нужно редко, легко создать неоднозначность)
По умолчанию фильтр идёт от измерения к фактам — этого достаточно в 95% случаев. Двунаправленную фильтрацию включают только в особых сценариях (например, фильтр одного среза по наличию фактов), и она часто порождает неоднозначность и ошибки. Правило профессионала: не включай двунаправленность без явной необходимости.
Активные и неактивные связи
Между двумя таблицами может быть несколько связей, но активной (по которой фильтры текут по умолчанию) может быть только одна — она рисуется сплошной линией. Пример: у заказа есть «дата заказа» и «дата отгрузки», обе ссылаются на таблицу Date. Активной делают одну, вторую — неактивной (пунктир), и обращаются к ней в DAX через функцию USERELATIONSHIP при необходимости.
Как работает под капотом
Связь — это не физическое соединение строк, а правило для движка: при расчёте меры фильтры с «одной» стороны автоматически сужают «многую» сторону. Внутри VertiPaq хранит для связи отображение ключей, чтобы мгновенно понимать, какие строки фактов соответствуют выбранным строкам измерения. Неоднозначные пути (несколько связей между таблицами) движок разрешать не умеет — отсюда требование одной активной связи.
Частые ошибки
- Связь по неуникальному ключу. Даёт «многие-ко-многим» и неверные агрегаты — измерение должно иметь уникальный ключ.
- Включать двунаправленность «на всякий случай». Создаёт неоднозначность и трудноуловимые ошибки в мерах.
- Забыть про активную связь при двух датах. Расчёт пойдёт по «дате заказа», хотя нужна «дата отгрузки».
Итог
- Кардинальность правильной звезды — один-ко-многим (измерение → факты).
- Направление фильтра по умолчанию одностороннее; двунаправленность — только осознанно.
- Активная связь одна; вторую используют через
USERELATIONSHIP.