Научить сотрудника заполнять иначе - не вариант?:)

Непосредственно PowerBI - нет. Но что мешает этому сотруднику сохранять файл с именем "файл_20200518.xlsx"

Это самый простой вариант, но природная любознательность и пытливость заставляет интересоваться возможностями PBI))

Для любознательных: PowerBI система визуализации и анализа данных, а не хранения. А ваш вопрос именно про хранение

Нет так нет)

👍

Есть таблица фактов и три таблицы измерений. В таблице фактов через related и символы разделители собирается новое поле ColumnR: = related(DimTable1[column1]) & "-" & related(DimTable2[column2]) & "-" & related(DimTable3[column3])

Как собрать это составное поле в промежуточной таблице-справочнике, чтобы привязать ее как измерение к таблице фактов, не отвязывая при это исходные таблицы измерений?

постановка задачи подсказывает, что вы неправильно поняли, что такое измерение. и join по такому полю убьёт вам производительность

Навскидку - SUMMARIZE по Вашим трём полям в таблице фактов, ADDCOLUMNS с созданием нового поля (ColumnR) из полей с предыдущего шага, и после этого делаем SELECTCOLUMNS - выбираем только поле ColumnR. Всё это в одной формуле, само собой :)
В итоге должна получится табличка из одного поля со всеми комбинациями Ваших исходных 3 полей из таблицы фактов

А вообще да - лучше объясните, зачем вам этот огород нужен)

в нормальном ETL я бы сделал отдельную табличку, куда скидывал три поля, получал бы на них GUID и вязал бы факт по нему

👍

загуглите термин DWH и принципы его построения

я такое видел из двух измерений, когда человек в какой-то момент времени занимался конкретным продуктом на конкретной территории, а потом всё менялось, но надо было смотреть его сквозной перфоманс. Но как оказалось с точки зрения бизнеса это всё равно не очень прозрачно и непонятно как считается. Поэтому забили и приказали так не делать.

Я уже пару дней назад спрашивал про решение задачи TopN+Others. Так вот в отчёте есть stacked column chart, где на оси Х даты, в легенде то самое составное поле, собранное через related на таблице фактов (связка 3х имён из справочников через таблицу фактов), в значениях на графике одна из мер от табл фактов. Вариаций этого составного поля слишком много. Powebi выводит уведомление i,  где сообщает, что из-за большого количества значений в легенде он порезал их. Возникла идея, согласованная с пользователями, что в легенду выводить TOP20 отсортированных по мере из графика, остальные значения легенды запихивать в Others

Решение TopN отсюда

посчитать оконной функцией топ-N

потом if rank > 10 then other else description

Для наглядности примера: Факты - продажи ноутов, на оси Х даты продаж,   в легенде (ось Y) составной параметр установленная ось - процессор. График продажи ноутов в разрезе дней с разбивкой по парам ось-процессор