DAX и хранилище данных

[Владимир Максимов]

Цитата:

Сообщение от Cardagant

Спасибо большое за содержательный ответ. Вариант красивый. Этот способ подразумевает, таблицу-перекодировщик для каждого измерения?

Если это необходимо по логике отчета. Например, необходимость объединения сущностей, периодичность данных (обновление справочника целиком раз в год) и т.п. Если ничего этого нет (например Base Enum в виде измерения), то, разумеется, таблица-перекодировщик не нужна.

Но! Создать собственный суррогатный ключ для хранилища необходимо в любом случае, вне зависимости от необходимости перекодировки.

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

Тот идентификатор, который приходит из-вне (в данном случае из Axapta) может служить максимум альтернативным ключом. Но ни в коем случае не Primary Key!

Цитата:

Сообщение от Cardagant

Как это выглядит сложно.

Тут одно из двух. Либо относительно сложный алгоритм наполнения хранилища, либо сложный алгоритм формирования измерений и мер внутри куба.

Лично я предпочитаю относительно сложный алгоритм наполнения, но предельно простой алгоритм формирования куба. Код наполнения я могу контролировать. А как оно внутри куба "тикает" - не очень понятно... Да и сложный алгоритм формирования измерений приводит к замедлению работы с кубом, что обесценивает сам факт его использования...

Цитата:

Сообщение от Cardagant

не подойдёт ли в качестве алгоритма перекодировки нечто предлагаемое выше типа HASBYTES(). Возможно в данном случае будет возможно обойтись пере таблиц-перекодировщиков?

Здесь проблема в уникальности PrimaryKey для таблицы-справочника в хранилище данных

Предположим, пользователь хочет чтобы в отчете вместо двух разных номенклатур отображалась одна. Без таблицы перекодировки Вы этого сделать не сможете. У Вас ведь HASBYTES() для разных значений ItemId сформирует разное значение хеша. Значит, это так и останутся две разных записи справочника. Не будет объединения. А с таблицей перекодировщиком Вы имеет примерно следующее

Перекодировка

ItemId_1 --> ItemId_10
ItemId_2 --> ItemId_10

Справочник хранилища

ItemId_10 -> 10


Разумеется, если задачи объединения разных сущностей не стоит, то можно и без таблицы-перекодировщика обойтись. Однако собственный суррогатный ключ все-равно нужен. Почему, описал выше. Кроме того, факт наличия суррогатного ключа позволит безболезненно добавить таблицу-перекодировщик, если в будущем в этом возникнет необходимость

Ну, а каким именно образом формировать этот суррогатный ключ: Identity, HASBYTES() , GUID() - это уже вопрос личных предпочтений и особенностей постановки задачи