Еще раз о двунаправленных связях, неоднозначности модели и USERELATIONSHIP

TL;DR

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

Знание некоторых особенностей работы алгоритма позволяет получать предсказуемые результаты при помощи функций управления связями USERELATIONSHIP и CROSSFILTER.

В этой статье рассмотрю сразу два аспекта работы алгоритма, описание которых не встречалось мне ранее:

1. Одно из правил выбора пути фильтрации при наличии двунаправленных связей
2. Влияние этого правила на работу функции USERELATIONSHIP

Проблема двунаправленных связей

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

Лучше всего сложности, связанные с двунаправленными связями, описаны в статьях Альберто Феррари и Марко Руссо на сайте sqlbi.com, а также в их книге «Подробное руководство по DAX». Например, вот такая статья «Bidirectional relationships and ambiguity in DAX» и сопутствующее ей видео прекрасно показывают суть проблемы (рекомендую ее прочесть, хотя бы при помощи онлайн-переводчика, перед тем, как двигаться дальше).

Попробую вкратце сформулировать эту проблему так:

1. Когда связи между таблицами однонаправленные «Один-ко-Многим» (фильтрация всегда движется от стороны связи «Один» к стороне связи «Много»), то такие модели данных обычно не вызывают проблем.
2. Ситуацию осложняют двунаправленные связи: вполне возможна ситуация, когда фильтрация от одной таблицы к другой может пройти разными путями (неоднозначность связей).
3. За выбор пути фильтрации в случае неоднозначности отвечает движок DAX, который руководствуется сложной системой правил для определения приоритетного пути.
4. В некоторых случаях мы можем помочь движку определить необходимый путь фильтрации, используя функции USERELATIONSHIP и CROSSFILTER в мерах.
5. Если у движка не получается однозначно определить путь, то во время создания связи (или же во время выполнения расчетов) возникает ошибка.

В своей статье Феррари пишет, что алгоритм, который внутри движка DAX решает проблемы неоднозначности, слишком сложный, чтобы его можно было объяснить «на пальцах». Это действительно так, и мне пришлось недавно столкнуться с этим в рабочем проекте. Это «столкновение» подвигло меня на некоторые исследования, которые привели к удивительным выводам.

Два активных пути между таблицами

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

1. Учет транзакций ведется в разрезе счетов в таблице 'Transactions'.
2. Клиент (таблица 'Customers') может управлять несколькими счетами (таблица 'Accounts'), и у одного счёта может быть несколько владельцев.
3. Для связи клиентов со счетами в таком случае используется таблица-мост 'AccountsCustomers', которая содержит в себе пары значений AccountKey – CustomerKey

Чтобы мы могли в такой модели ответить на вопрос: «Какой оборот по счетам каждого клиента?», мы должны сделать двунаправленной связь между таблицей-мостом 'AccountsCustomers' и таблицей 'Accounts', таким образом, чтобы фильтр от таблицы 'Customers' мог добраться до таблицы 'Transactions'.

Мы можем включить двустороннюю фильтрацию двумя способами:

• Изменив направление кросс-фильтрации между 'AccountsCustomers' и 'Accounts' на двунаправленное в свойствах связи в модели (как на рисунке), и используя простую меру суммирования по столбцу:

SumOfAmt =
SUM ( Transactions[Amount] )

• Используя в мере функцию CROSSFILTER с третьим аргументом Both:

SumOfAmt CF =
CALCULATE (
    SUM ( Transactions[Amount] ),
    CROSSFILTER ( Accounts[AccountKey], AccountsCustomers[AccountKey], BOTH )
)

Оба способа дают нам ответ на поставленный выше вопрос:

Так, у клиента Mark суммарный оборот по его двум счетам составил 2800 (800 по личному счету «Mark» и по 1000 по совместно управляемым счетам «Mark-Paul» и «Mark-Robert»).

В этой модели нет видимой неоднозначности связей – единственный путь от 'Customers' до 'Transactions' не создает альтернатив.

Чтобы создать ситуацию неоднозначности, я немного модифицировал эту упрощенную модель, добавив еще две таблицы:

• 'Agreements' – справочник договоров, заключенных с клиентами. У одного клиента может быть несколько договоров.
• 'Addendums' – справочник дополнительных соглашений к договорам. У одного договора может быть несколько дополнительных соглашений.

Также я добавил в таблицу 'Transactions' еще один столбец Transactions[AddendumKey], который позволяет определить, в соответствии с каким из дополнительных соглашений была проведена транзакция. Теперь в этой таблице одна строка показывает операцию и в разрезе счёта Transactions[AccountKey], и в разрезе допсоглашения Transactions[AddendumKey].

В итоге модель приобрела вот такой вид:

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

Теперь между таблицами 'Customers' и 'Transactions' есть два активных пути – через 'Accounts' и через 'Addendums', и связи в модели очевидно неоднозначные. Попробуйте предположить, не заглядывая вперед, по какому же из путей пойдет фильтрация в данном случае?

Если мы теперь посмотрим на результаты расчетов нашей меры [SumOfAmt], то можем увидеть следующую картину:

Таблица справа создана в новой модели данных и уже не отвечает на вопрос, поставленный ранее: «Какой оборот по счетам клиента?» Сейчас данные в ней отвечают уже на другой вопрос, который, скорее всего, звучит так: «Какой оборот по счетам клиента с учетом допсоглашений к договорам?»

Очевидно, что в этом случае в действие вступила связь через таблицы 'Agreements' и 'Addendums': несмотря на то, что некоторыми счетами управляют сразу два клиента («Mark-Robert» и «Mark-Paul»), таблица теперь показывает суммы только по допсоглашениям конкретных клиентов. Так, у клиента Mark оборот теперь показывается только по счетам Mark и Mark-Robert, так как операция на 1000 по счету Mark-Paul была проведена по договору клиента Paul. Аналогичная история произошла с оборотами клиента Robert.

Как же понять, почему движком был выбран именно этот путь?

Мы можем увидеть, что эти два активных пути распространения фильтра от 'Customers' имеют одно очень важное отличие: в «верхнем» пути (через 'Accounts') у нас присутствует двунаправленная связь «Многие-к-Одному» между 'AccountsCustomers' и 'Accounts', в то время как в «нижнем» все связи однонаправленные. «Верхний» путь явно проиграл «нижнему» (через 'Addendums') в борьбе за приоритет.

Анализ этой модели и дополнительные изыскания позволили мне сделать вывод о существовании Правила, который подтвердил один из создателей DAX Джеффри Вэнг (Jeffrey Wang):

Путь, в котором фильтрация всегда распространяется только от стороны «Один», будет приоритетнее пути, в котором встречается распространение связи от стороны «Много»

При этом:

1. Важна именно кардинальность связи на той стороне, откуда распространяется фильтр. Например, двунаправленная связь «Один-ко-Многим» при распространении фильтра со стороны «Один» будут приоритетнее двунаправленной связи «Один-ко-Многим», в которой фильтр распространяется со стороны «Много».
2. Место, где встречается распространение фильтра от стороны «Много», может быть где угодно в цепочке связей, не обязательно первым на пути следования фильтра.

В нашей модели фильтр от таблицы 'Customers', проходя по связи между 'AccountsCustomers' и 'Accounts', как раз и сталкивается с такой ситуацией – он должен фильтровать таблицу 'Accounts' в направлении от «Много» к «Один». Анализатор связей в таком случае понижает «вес» такой связи, и движок выбирает тот путь, где такие ситуации не встречаются, т.е. путь через 'Addendums'.

Для того, чтобы наша модель и в этом случае позволила нам получить такой же результат, как и ранее (оборот по счетам клиента без учета допсоглашений), мы должны задействовать отключение одной из связей на «нижнем» пути (например, связи между 'Addendums' и 'Transactions‘) при помощи функции CROSSFILTER и ее 3-го аргумента :

SumSumOfAmt Old Path =
CALCULATE (
    [SumOfAmt],
    CROSSFILTER ( Transactions[AddendumKey], Addendums[AddendumKey], NONE )
)

Мы знаем, что фунцкия USERELATIONSHIP позволяет нам выбирать, по какой из связей между двумя таблицами должна идти фильтрация. Можем ли мы использовать эту функцию для получения нужного результата в нашей модели?

Давайте попробуем сделать неактивной одну из связей на «верхнем» пути (например, между таблицами 'AccountsCustomers' и 'Accounts'), и затем активируем ее при помощи функции USERELATIONSHIP:

SumOfAmtUR =
CALCULATE (
    [SumOfAmt],
    USERELATIONSHIP ( AccountsCustomers[AccountKey], Accounts[AccountKey] )
)

Как видите, активация связи при помощи USERELATIONSHIP не привела ни к каким изменениям в нашем расчете – фильтрация по-прежнему идет по «нижнему» пути:

В общем-то, трудно было ожидать изменения в данном случае:

• При неактивной связи фильтр шел по нижнему пути – другого выбора у него не было.
• USERELATIONSHIP просто активировала отключенную связь «верхнего» пути.
• Так как никаких изменений в отношении пути между 'Customers' и 'Transactions' через 'Addendums' сделано не было, второй («нижний») путь по-прежнему приоритетен для движка, в соответствии с выведенным нами Правилом.

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

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

Казалось бы – всё на этом, мы разобрались? Отнюдь.

USERELATIONSHIP и выбор единственной связи между таблицами

Следующий пример я сделал на основе реальной задачи анализа взаимосвязей между документами в Dynamics 365 Finance & Operations (AXAPTA). Как правило, в подобных ей ERP-системах существуют сложные системы отношений, которые не всегда (даже в рамках узконаправленного проекта) можно денормализовать до простой схемы «звезда» или «снежинка».

Пусть в нашей модели есть две таблицы:

• справочник 'Entries', содержащий в себе ссылки на два разных типа документов: на расходный документ в одном столбце и на приходный документ в другом. Столбец расходных документов Entries[Issue] всегда заполнен уникальными значениями кодов документов, а в столбце приходных документов Entries[Receipt] могут встречаться незаполненные значения.
• 'Documents', содержащий в себе уникальный список документов всех видов и дополнительную информацию, которую нам нужно проанализировать.

В модели также присутствуют и другие таблицы. Наша задача – построить связи таким образом, чтобы, приходя по связям из других таблиц, фильтрующих таблицу ‘Entries’, получить из таблицы 'Documents' значения, соответствующие либо расходному, либо приходному документу. Иными словами, фильтр должен распространяться от таблицы 'Entries' к таблице 'Documents' в двух вариантах:

1. от Entries[Issue] к Documents[DocumentID]
2. от Entries[Receipt] к Documents[DocumentID]

Когда мы будем создавать первую связь в Power BI, движок проанализирует кардинальность столбцов с обеих сторон и, убедившись, что все значения в столбцах связи уникальные, автоматически создаст связь «Один-к-Одному»:

Неизменяемая двунаправленность этой связи нас вполне устраивает – фильтр вполне может проходить от 'Entries' к 'Documents', и наша задача будет отчасти решена.

Вторую связь (от Entries[Receipt] к Documents[DocumentID]) мы не можем сделать такой же «Один-к-Одному», так как наличие пустых значений в столбце Entries[Receipt] уже свидетельствует о неуникальности значений в нем. Поэтому движок автоматически предложит нам неактивную однонаправленную связь «Многие-к-Одному». Направление кросс-фильтрации от 'Documents' к 'Entries' нас не устраивает – нам надо наоборот. Это легко поправимо – в свойствах связи мы можем установить двунаправленную кросс-фильтрацию:

Чтобы получить нужный нам результат, создадим две меры – одна для вычисления суммы по приходным документам, другая – по расходным:

SumOfIssues =
SUM ( Documents[Value] )

SumOfReceipts =
CALCULATE (
    SUM ( Documents[Value] ),
    USERELATIONSHIP ( Documents[DocumentID], Entries[Receipt] )
)

Мы ожидаем, что первая мера покажет нам суммы по расходным документам (связь по умолчанию), а вторая покажет суммы по приходным (за счет активации второй связи). Однако результат далёк от ожидаемого:

В таблице слева мы получили то, что и должны были – для каждого расходного документа посчитана его сумма, а те документы, которые не нашлись в таблице 'Entries', сгруппировались в пустое значение. Это стандартное поведение.

А вот в правой таблице произошло что-то странное. Если мы еще раз посмотрим на исходные данные, то заметим, что документу E должно соответствовать значение 16, а для F мы должны получить 32. Но мы по-прежнему получили значения для спаренных с E и F расходных документов В и С.

Несмотря на то, что мы активировали связь от столбца Entries[Receipt], движок проигнорировал наш запрос и по-прежнему считает по первой связи – от Entries[Issue]. Это очень странно, неправда ли?

Давайте вспомним, что мы (думаем что) знаем о связях в таком случае:

1. Между двумя таблицами может быть только одна активная прямая связь (что вполне логично).
2. Когда мы используем USERELATIONSHIP для активации отключенной связи между таблицами, другие прямые связи между этими двумя таблицами перестают действовать (тоже логично, иначе противоречило бы пункту 1).

Эти два пункта на самом деле работают в абсолютном большинстве случаев (а в Power Pivot на настоящий момент – наверное, в 100% случаев). Но здесь что-то пошло не так…

Чтобы не ходить вокруг да около, я просто еще раз приведу здесь то Правило, которое мы вывели ранее в этой статье:

Путь, в котором фильтрация всегда распространяется только от стороны «Один», будет приоритетнее пути, в котором встречается распространение связи от стороны «Много»

Но почему оно сработало здесь? Ведь у нас нет двух активных путей между таблицами, а активация второй связи при помощи USERELATIONSHIP должна была отключить активную связь «Один-к-Одному» по столбцу Entries[Issue] – ведь так всегда происходит?

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

Итак, приготовьтесь:

1. При использовании USERELATIONSHIP происходит не буквально «активация одной связи и деактивация другой», а, скорее, увеличение приоритета (веса) неактивной связи над активной на время расчета меры.
2. Таким образом, в обычной ситуации неактивная связь временно получает более высокий приоритет, чем активная, и распространение фильтрации идет уже по новому пути.
3. Однако, указанное выше правило в данном случае берет верх и расставляет приоритеты по-своему: так как неактивная связь использует фильтрацию от «Много» к «Один», ее приоритет ниже, чем приоритет связи от «Один» к «Много» (связь «Один-к-Одному» здесь трактуется так же).

Сдвиг парадигмы, неправда ли?

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

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

Джеффри назвал это поведение «непоследовательностью», и, по зрелому размышлению, я с ним скорее соглашусь: да, не так, как в других случаях, но это то самое «исключение из правил». Очень маловероятно, что это будет изменено, так как может затронуть большое количество работающих моделей. И, опять же, жаль, что это нигде не было описано до сих пор. Но теперь у вас это знание есть 😊

Что же делать в таком случае – как победить правило и получить требуемый результат?

На самом деле – довольно просто, и для этого есть даже не одно решение:

• Мы можем использовать в нашей мере в дополнение к USERELATIONSHIP функцию CROSSFILTER, отключающую связь «Один-к-Одному»:

SumOfReceipts CF =
CALCULATE (
    SUM ( Documents[Value] ),
    USERELATIONSHIP ( Documents[DocumentID], Entries[Receipt] ),
    CROSSFILTER ( Documents[DocumentID], Entries[Issue], NONE )
)

• Мы можем изменить кардинальность активной связи от Entries[Issue] к Documents[DocumentID] на двунаправленную «Многие-к-Одному». Тогда правило определения приоритета столкнется с двумя однотипными связями и ничего не будет делать, оставив право определения приоритета за USERELATIONSHIP

В обоих случаях мы получим нужный результат – фильтрация заработает так, как нам нужно:

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

В заключение хочу привести еще одну цитату из статьи Альберто Феррари:

The fun part is not in analyzing the numbers; the fun part lies in finding the path that DAX had to discover within the maze to find the exit.

Действительно, DAX нам всегда что-то посчитает (в крайнем случае, выдаст ошибку, если мы грубо ошибемся), но мы должны понимать, что же именно он посчитал. А знание – сила!

Вы можете скачать файл с примерами к данной статье здесь:

Сопроводительный файл для поста о USERELATIONSHIP и неоднозначности

1 файл(ы) 79kB

Скачать