Поймёте, когда использовать RELATED и RELATEDTABLE, проверите направление связи и не станете чинить формулой проблему модели данных.
В таблице продаж хранится ProductID, а название категории лежит в справочнике товаров. Нужно показать категорию рядом с продажей. Самый устойчивый путь — создать связь и использовать RELATED. Обратная задача: для одной категории получить связанные строки продаж. Здесь помогает RELATEDTABLE. Функции короткие, но они не заменяют модель. Если ключи грязные или связь неоднозначна, DAX не обязан угадывать, что автор имел в виду.
Что это значит простыми словами
RELATED идёт по существующей связи со стороны «много» к стороне «один» и возвращает одно значение. RELATEDTABLE идёт к связанным строкам и возвращает таблицу, которую можно передать COUNTROWS, SUMX или другой функции. LOOKUPVALUE ищет значение по условиям и бывает полезна без подходящей связи, но в нормальной звёздной модели связь обычно понятнее и быстрее для поддержки.
Формула и логика расчёта
Пример вычисляемого столбца: RELATED(Товары[Категория]). Пример количества продаж для товара: COUNTROWS(RELATEDTABLE(Продажи)). Чтобы функция работала предсказуемо, в справочнике должен быть уникальный ключ, типы ключей должны совпадать, а связь — быть активной. RELATED не является аналогом объединения таблиц в Power Query: она использует модель после загрузки.
Подробный пример с числами
В справочнике три товара: 101, 102 и 103. В продажах 1 000 строк, каждая содержит ProductID. Для товара 101 есть 420 строк продаж, для 102 — 350, для 103 — 230. RELATED добавит каждой строке продаж категорию из справочника. COUNTROWS(RELATEDTABLE(Продажи)) вернёт для товаров 420, 350 и 230. Если ProductID 103 случайно дважды присутствует в справочнике, сторона «один» перестаёт быть уникальной — сначала исправляем ключ, а не подбираем более хитрую формулу.
Сверьте количество уникальных ключей со строками справочника. Затем найдите строки факта без соответствия и пустые ключи. После этого добавьте простую таблицу «ключ — связанное значение — число строк». Такая проверка быстрее показывает проблему, чем чтение большой меры.
Как использовать в бизнесе
Качественные связи нужны не только ради DAX. Они закрепляют, что такое товар, клиент, договор и подразделение. В проектах я сначала договариваюсь о владельце справочника и правилах уникальности. Только потом добавляем вычисления. Иначе категория сегодня подтянулась, завтра задублировалась, а в отчёте неожиданно выросла выручка — очень бодрый график, но бизнесу от него не легче.
Когда применять этот подход
RELATED подходит, когда в строковом контексте нужно одно поле со стороны справочника: категорию товара, регион клиента или группу договора. RELATEDTABLE нужна, когда для текущей строки справочника надо получить связанные операции и затем их посчитать. Если связи нет и создавать её нельзя по объективной причине, LOOKUPVALUE может быть уместна, но это должно быть осознанное исключение.
Как проверить результат
Для проверки возьмите пять ключей: обычный, с большим числом операций, без операций, отсутствующий в справочнике и потенциальный дубль. Посмотрите возвращённое значение и число связанных строк. Итоги по всем ключам должны объяснять число строк факта; необъяснённый остаток оформите отдельным показателем качества данных.
Как собрать расчёт по шагам
1. Проверьте ключ справочника
На стороне «один» не должно быть дублей и пустых значений.
2. Сверьте типы данных
Число и текст с одинаковым видом всё равно являются разными ключами.
3. Проверьте активную связь
Посмотрите кардинальность и направление фильтрации в модели.
4. Выберите функцию
RELATED — одно значение, RELATEDTABLE — набор связанных строк.
5. Сверьте контрольные записи
Возьмите несколько ключей и сравните результат с исходной системой.
Ограничения и типичные ошибки
- Использовать RELATED при отсутствии активной связи.
- Оставлять дубли на стороне «один».
- Подменять модель множеством LOOKUPVALUE без объяснения.
- Путать вычисление в модели с физическим Merge в Power Query.
После изменения модели проверьте контрольный набор вручную и запишите дату проверки. Если источник, связь или определение показателя изменились, старый результат уже нельзя молча сравнивать с новым.
Как я делаю это в проектах
Я держу отдельную страницу контроля модели: число строк без справочника, дубли ключей и несколько контрольных карточек по связям. При обновлении данных она показывает проблему раньше пользователей. Если новый товар ещё не попал в справочник, мы видим это как исключение и назначаем владельца. Так RELATED остаётся простой функцией, а не лотереей после каждого обновления.
Что сделать прямо сейчас
Выберите одну связь и посчитайте три числа: строки факта, уникальные ключи справочника и строки без соответствия.
Если хотите собрать расчёт вместе с моделью и нормальной проверкой данных, можно обсудить задачу с ФАНалитикой. Начнём с одного показателя и доведём его до решения, а не до ещё одной формулы в коллекции.
