ferzmikk,

1) в Power Query есть M-Code (M-Language), и в нём Table.RenameColumns
или "Edit Queries" -> и там в Power Query Editor выбрав нужную Таблицу/Запрос кликнув на поле - можно выбрать "Rename" в контекстном меню (на заднем плане он сам сгенерирует тот-же M-Code по переименованию)

2) Либо в живом подключении (тогда с права можно будет так-же как с Excel на Pivot Table выбирать и бросать нужные поля в отчёт/фильтры) - и Power BI сам сгенерирует запрос (который будет DAX, т.е. не MDX)
а при импорте (через запрос) - есть параметры где можно выбрать из (не Multi-Select) списка (введённого в ручную или на основе другого запроса преобразованного в список),
так что по идее можно было-бы на основе параметров реализовать, но проблема с Power BI в том что параметры выбираются до выполнения всех запросов и не являются каскадными
(и следовательно не динамически контекстные), т.е. сначала вводятся все параметры - а потом (параллельно - Enable parallel loading of tables) выполняются все запросы
По идее если элементы списка практически не обновляемы - то запрос можно сконструировать на основе (разных, т.к. MultiSelect не поддерживается)
параметров (импорт данных в модель, т.е. запрос с ТТ, потом из него список, на основе списка List-of-Values параметр)
а если точки в измерении довольно динамичны то пока за один проход никак не решить, либо тащить большой набор данных (всех точек для выбора) и из него уже фильтровать (динамично) в отчёте.
Можно за 2 прохода конечно, сначала обновляются все запросы/таблицы (в том числе список точек), потом снова в параметры и выбор
В общем по простому - только при живом подключении (а не свой MDX), или большим (полным, свой MDX) набором данных, иначе никак.

п.с.
2) - набор данных грузи по другому, не колонны оставь только с мерами, всё где динамичные названия - строками пиши, дальше Power BI уже Pivot сделает.
ещё если наименования динамичны - то можно к колоннам обращаться по индексу через тот-же M-Code, напр: Table.ColumnNames(моя_таблица){индекс_колонны}

ferzmikkВот атрибут Дата сортирует как текст.
Как быть? Отдельно создавать меру Дата и по нему сортировать?
если тип правильный (Дата) - то и Power BI сортировку сделает верно.
ознакомься с преобразованиями.

ferzmikkВ самом кубе, MDX-запросе или Power BI?при Live Connection - он из имени (метаданные куба) подхватывает (а не ключа), если в имени тип данных верный то и PowerBI будет распозновать его как Date
при импорте (MDX) - есть преобразование типов (если самим запросом верный тип данных не вытащил), можно преобразованиями создать дополнительную колонну с нужным типом через то-же преобразование), так что тут 2 варианта: и MDX и Power BI - как удобней

Andy_OLAP,

ты сам то пробовал?

StarikNavy,

руководство знало риски и (заочно) приняло ответственность за результат.
наше дело базу поднять, OLAP вернуть, т.е. борьба с последствиями, ну и обычно принятие мер (технических-ли, воспитательно-убедительных-ли) чтобы такого не произошло (хотя тут опять отсыл в первую строчку) - т.е. предупреждение.

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

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

тут кстати всплывают две древние и не очень-то решенные проблемы:
ограничение ресурсов на сессию/пользователя в SQL Server и в SSAS (т.е. в каждом сервисе).
что-то там не особо в разработке платформы чешутся чтобы это решить

StarikNavy,

да, там (задал т.к. здесь навеяло, сам часто сталкивался с такой проблемой) по первым ответам с Resource Governor (а так-же гуглу) на то и похоже что только косвенно (и то с натяжкой)..