Связи Power BI: как проверить неоднозначный путь фильтрации в учебной модели

Неоднозначный путь фильтрации в Power BI удобнее ловить не на большой боевой модели, а на маленькой схеме из трех-четырех таблиц. Тогда видно не только то, что цифры «не сходятся», но и почему они расходятся: один и тот же фильтр доходит до таблицы фактов разными маршрутами. Для проверки не нужно заново разбирать гранулярность фактов. Гораздо полезнее построить учебную модель, где один маршрут активен, второй существует как кандидат, а результат сравнивается в контрольной таблице.

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

Что именно считается неоднозначным путем фильтрации

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

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

Такая проверка нужна не только для «красоты схемы». Если два маршрута дают разное распределение по категориям, общий итог может выглядеть нормальным, а ошибка проявится только в разрезе городов, магазинов или каналов. Поэтому смотреть надо не на сумму по всей модели, а на контрольную таблицу по конкретному измерению.

Схема учебных таблиц

Учебный пример. Среда: Power BI Desktop, import model. Возьмем три таблицы. Cities — справочник городов, Stores — магазины с привязкой к городу, Sales — продажи. В таблице продаж специально хранятся и идентификатор магазина, и идентификатор города. Это удобно для диагностики: один путь к продажам идет через магазин, второй — напрямую по городу.

Дальше настраиваем связи так: Cities[CityID] → Stores[CityID] — активная 1:*; Stores[StoreID] → Sales[StoreID] — активная 1:*; Cities[CityID] → Sales[CityID] — создаем как неактивную 1:*. Почему неактивную? Потому что она и есть кандидат на второй маршрут. Если пытаться держать оба пути активными, модель может стать неоднозначной уже на уровне связей.

В этом наборе данных одна строка намеренно спорная: продажа с SaleID = 2 относится к магазину A, который стоит в городе «Север», но в самой строке продаж записан CityID = 2, то есть «Юг». Нам не нужно доказывать, какой столбец «правильный». Наша задача скромнее: проверить, совпадают ли два пути фильтрации или они ведут к разным результатам.

Кардинальность: что проверить до сравнения маршрутов

Прежде чем сравнивать пути, надо убедиться, что проблема не в самой кардинальности. На стороне one значения должны быть уникальны: в Cities не должно быть двух строк с одинаковым CityID, а в Stores — двух строк с одинаковым StoreID. На стороне many повторы ожидаемы: в продажах один магазин встречается много раз, один город тоже может повторяться во многих строках.

Практически это означает простой список проверки. Сначала посмотрите, нет ли дублей в ключах справочников. Затем убедитесь, что каждая активная связь читается как «один город — много магазинов» и «один магазин — много продаж». После этого проверьте кандидатную связь Cities → Sales: она тоже должна быть 1:*, иначе вы будете диагностировать сразу две проблемы — альтернативный маршрут и неверную структуру ключей.

Есть еще один полезный вывод. Связь сама по себе не гарантирует целостность данных. В нашей модели продажа с SaleID = 2 не ломает создание связи: и магазин существует, и город существует. Но строка все равно распределяется по-разному в зависимости от выбранного маршрута. Именно поэтому одних «зеленых галочек» в модели мало; нужна сверка результата.

Направление фильтрации: как изолировать каждый маршрут

Теперь задача — не «включить все связи сразу», а по очереди проверить каждый маршрут. Активный путь у нас уже есть: Cities → Stores → Sales. Он покажет, как продажи распределяются по городам через принадлежность магазина. Альтернативный путь — Cities → Sales — оставляем неактивным и включаем только внутри контрольной меры.

Для этого достаточно трех мер. Первая считает сумму продаж. Вторая использует текущий активный маршрут. Третья временно включает прямую связь по городу и одновременно отключает участок Cities → Stores, чтобы фильтр не шел двумя дорогами сразу.

Sales Amount =
SUM ( Sales[Amount] )

Sales via store path =
[Sales Amount]

Sales via direct city path =
CALCULATE (
    [Sales Amount],
    USERELATIONSHIP ( Cities[CityID], Sales[CityID] ),
    CROSSFILTER ( Cities[CityID], Stores[CityID], None )
)

Path Difference =
[Sales via direct city path] - [Sales via store path]

Здесь важна логика, а не «магия DAX». USERELATIONSHIP временно активирует неактивную связь Cities → Sales. CROSSFILTER(..., None) на время расчета убирает влияние маршрута через магазины. В результате каждая мера считает один и тот же показатель на одном и том же наборе строк, но по разным путям фильтрации. Это и есть аккуратная диагностика без перестройки всей модели.

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

Контрольная таблица результата и что делать с расхождением

Теперь добавьте в отчет таблицу с полем Cities[CityName] и тремя мерами. На наших условных данных получится такой результат.

Это хороший учебный результат, потому что он показывает типичную ловушку. Общий итог одинаковый — 230. Если смотреть только на карточку с суммой, кажется, что все в порядке. Но распределение по городам разное: активный путь относит спорную продажу к городу магазина, а прямой путь — к городу из строки продаж. Значит, проблема не в мере суммы и не в визуале, а именно в выборе маршрута фильтрации.

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

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

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