Частая ситуация: в таблице фактов несколько дат. У заказа есть дата заказа и дата отгрузки; у договора — дата подписания и дата оплаты. Обе хочется анализировать по одному календарю. Power BI разрешает только одну активную связь между двумя таблицами — но это решаемо.
Проблема: две даты, один календарь
Представим, что в Продажи кроме Дата (заказа) есть ещё ДатаОтгрузки. Обе ссылаются на Календарь[Дата]. Если провести две связи, Power BI оставит активной только одну (сплошная линия), а вторую сделает неактивной (пунктир). По умолчанию все меры считаются по активной связи — то есть по дате заказа.
Это называется role-playing dimension: один справочник дат играет две роли.
Две активные связи создали бы неоднозначность: Power BI не знал бы, по какой дате фильтровать. Поэтому активна одна, остальные — про запас, и включаются точечно в мере.
USERELATIONSHIP — включить неактивную связь
Чтобы посчитать меру по неактивной связи, оборачиваем её в CALCULATE с USERELATIONSHIP:
Выручка по дате отгрузки =
CALCULATE (
[Выручка],
USERELATIONSHIP ( Продажи[ДатаОтгрузки], Календарь[Дата] )
)Внутри этого CALCULATE активной временно становится связь «отгрузка → календарь». Рядом обычная [Выручка] по-прежнему считается по дате заказа. Положив обе меры в один визуал по месяцам, вы увидите две линии: когда заказали и когда отгрузили.
Лишние связи между фактом и измерением можно держать неактивными и включать по требованию через USERELATIONSHIP внутри CALCULATE. Активная связь — поведение по умолчанию; неактивная — по запросу в конкретной мере.
Когда это нужно
- Даты-роли: заказ / отгрузка / оплата по одному календарю.
- Несколько ключей: в факте
КодКлиентаиКодПлательщика, оба к справочнику клиентов — анализ и по тем, и по другим. - Альтернативная иерархия того же измерения.
Альтернатива — копия измерения
Иногда вместо неактивной связи делают вторую таблицу дат (КалендарьОтгрузки) с активной связью. Плюс: не нужно писать USERELATIONSHIP в каждой мере, можно просто положить поле из второго календаря в срез. Минус: вторая таблица дат в модели, её тоже надо пометить как date table.
Частое заблуждение — «в модели допустима только одна таблица дат». Это не так: «Mark as date table» — свойство отдельной таблицы, и пометить можно сколько нужно. Рекомендация «держите один календарь» — про простоту и единую ось времени, а не про техническое ограничение. Когда у дат разные роли (заказ / отгрузка) и по каждой нужны свои срезы — отдельная помеченная таблица дат полностью легальна. (Не путайте с авто-календарём Power BI — вот его как раз держат один и обычно отключают.)
Если вторая дата нужна изредка в паре мер — проще неактивная связь + USERELATIONSHIP. Если по второй дате строят полноценные срезы и много визуалов — оправдана отдельная таблица дат с активной связью. Не плодите календари без необходимости.
Что дальше
Мы научились включать запасные физические связи. Но бывает, что связи между таблицами нет вовсе — например, бюджет лежит на уровне месяца, а продажи по дням. Связать их помогают виртуальные связи. Следующий урок — TREATAS.