В модели BI фильтр по клиенту неожиданно изменяет список товаров. Какой механизм модели следует проверить первым?
В первую очередь проверьте двунаправленное распространение фильтров по связям модели. Фильтр по клиенту может пройти через таблицу фактов и повлиять на таблицу товаров, хотя для отчёта требовалась только фильтрация продаж по клиенту.
Обычно безопаснее направлять фильтры от измерений к фактам. Двунаправленную фильтрацию следует включать только при понятной необходимости и проверять на неоднозначные пути распространения.
В аналитических моделях появились звёздные схемы, чтобы отделить измерения, такие как клиент, товар и дата, от таблицы фактов с операциями. Одной из исходных проблем была необходимость предсказуемо фильтровать факты по значениям измерений без неожиданных обратных зависимостей.
Поэтому однонаправленное распространение фильтров от измерения к факту стало распространённым базовым подходом. Двунаправленные связи применяют для отдельных сценариев, например при некоторых моделях соответствий или взаимодействии нескольких сущностей, но они повышают сложность анализа модели.
Предположим, модель содержит таблицы Клиенты, Продажи и Товары. При выборе клиента пользователь ожидает увидеть его покупки, однако список товаров начинает показывать только товары, встречавшиеся в отфильтрованных продажах.
Такое поведение может быть корректным для конкретного отчёта, но опасным для общего справочника или независимых визуализаций. Оно способно скрывать значения в фильтрах, менять количество категорий, создавать неоднозначные пути фильтрации и затруднять объяснение результатов пользователю.
Проверьте направление каждой связи и путь, по которому фильтр проходит между таблицами. При двунаправленной связи фильтр может двигаться не только от измерения к факту, но и обратно: от отфильтрованных строк факта к связанному измерению. Затем этот фильтр способен продолжить движение по другим связям.
В типичной звёздной схеме связи Клиенты—Продажи и Товары—Продажи чаще делают однонаправленными от измерений к факту. Тогда фильтр клиента ограничивает продажи, но не меняет независимый список товаров; мера продаж при этом рассчитывается только по выбранному клиенту.
Нужно также искать альтернативные пути между таблицами. Даже если отдельная двунаправленная связь кажется безобидной, вместе с другими связями она может создать цикл или несколько путей фильтрации. В разных BI-платформах правила разрешения таких ситуаций различаются, поэтому поведение следует проверять в конкретной модели и на тестовых срезах.
Отключать двунаправленность механически нельзя. Если она действительно нужна, зафиксируйте цель, область действия и ожидаемое поведение фильтров. Для сложных случаев лучше использовать отдельную таблицу соответствий, явную логику меры или другую структуру модели, чем делать множество связей двунаправленными.
В отчёте по программе лояльности выбор сегмента клиентов неожиданно сокращал справочник товаров. Анализ показал путь фильтрации «Клиенты → Продажи → Товары», возникший из-за двунаправленных связей.
Рассматривались два варианта. Первый — оставить двунаправленность и скрыть нежелательное поведение настройками отдельных визуализаций; это быстро, но сохраняет риск несогласованности в новых страницах отчёта. Второй — вернуть связи измерений с фактом к однонаправленному режиму и отдельно реализовать нужный анализ пересечений; это требует доработки, зато делает модель предсказуемой.
Выбрали второй вариант. После изменения при выборе клиента значения продаж продолжили фильтроваться, а полный справочник товаров перестал зависеть от клиентского фильтра. Для визуализаций, которым нужен только ассортимент фактически купленных товаров, добавили отдельную явно контролируемую логику.
Нет. Если визуализация должна показывать только товары, связанные с текущим клиентом, такое сокращение может быть ожидаемым. Ошибка возникает тогда, когда поведение не соответствует назначению визуализации или неочевидно для пользователя. Нужно отличать некорректную модель от корректной, но неправильно применённой логики взаимодействия.
Они могут приводить к неоднозначному распространению фильтра: один и тот же набор строк ограничивается разными маршрутами. В зависимости от платформы это вызывает ошибку модели, автоматический выбор одного пути или результат, который трудно интерпретировать. Даже без явной ошибки поддержка и проверка показателей становятся сложнее.
Настройка визуализации меняет её взаимодействия, но не устраняет источник фильтрации в семантической модели. Другой график, новая страница или будущая мера могут снова получить неожиданный контекст. Если причина находится в направлении связей, её следует исправлять на уровне модели либо явно документировать исключение.