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

[twilight]

Цитата:

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

В каждом измерении у нас есть ключ по трём полям (составной ключ), к примеру:
Partition + DataArea + CustAccount для кастомеров.

Как строили единый первичный ключ на основе составного?

А чем не устраивает составной ключ в хранилище данных? Например, кубы от MS SQL вполне хорошо работают с составными ключами.

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

Цитата:

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

А чем не устраивает составной ключ в хранилище данных? Например, кубы от MS SQL вполне хорошо работают с составными ключами.

Отсутствием атомарности. Например, как Вы получите разрез по компаниям? В смысле, сумма по всем клиентам в каждой компании? По фрагменту ключа разрез не получится...

Не надо придумывать себе проблемы, чтобы потом их героически преодолевать. С составными ключами слишком сложно работать. По любому будет "перекодировка" справочников при заливке из транзакционной базы Axapta в базу хранилища. Ну, и не надо "мудрить". Стандартный автоинкремент в качестве суррогатного ключа. Можно то же Idetntity или SequenceName, если речь идет о MS SQL.

Если несколько клиентов Axapta должны рассматриваться как один клиент в отчете, то обязательно таблица перекодировки. Не надо пытаться как-то "разрулить" это в рамках одной таблицы. Отдельная таблица-справочник для хранилища и отдельная таблица-перекодировщик с кодами соответствия Axapta-хранилища. Вот в этой таблице-перекодировщике можно "изгаляться" как угодно...

Примерно это выглядит так

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

Id - identity - идентификатор записи для связи с другими таблицами хранилища
AccountCode - код, под которым должна отображаться нужная сущность в отчете
AccountName - название, которое должно отображаться в отчете
(...) - прочие реквизиты справочника для формирования разрезов

Ограничения

Id - PrimaryKey
AccountCode - альтернативный ключ. Дублирование запрещено!


Таблица-перекодировщик

AccountCode_DWH - код, под которым должна отображаться нужная сущность в отчете. Поле AccountCode в справочнике хранилища (DWH - Data Warehouse)
DataAreaId - код компании в Axapta
AccountCode - код Axapta
(...) - прочие поля для однозначной идентификации записи в Axapta

в таблице-перекодировщике никаких ограничений! Может дублироваться что угодно и как угодно!


Соответственно, логика загрузки

1. По набору идентификаторов Axapta ищем нужный код в таблице-перекодировщике
2. По найденному альтернативному ключу ищем нужный код в справочнике хранилища

[Cardagant]

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

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

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

Цитата:

Сообщение от 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() - это уже вопрос личных предпочтений и особенностей постановки задачи

[twilight]

Цитата:

Сообщение от Владимир Максимов

Отсутствием атомарности. Например, как Вы получите разрез по компаниям? В смысле, сумма по всем клиентам в каждой компании? По фрагменту ключа разрез не получится...

Компания - это отдельное измерение и поэтому получить данные в ее разрезе нет проблем.

Цитата:

Если несколько клиентов Axapta должны рассматриваться как один клиент в отчете, то обязательно таблица перекодировки.

В такой постановке да. Но если компании полностью независимы, и у них разные (непересекающиеся) клиенты и номенклатура и прочие справочники, то можно не заморачиваться.

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

Цитата:

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

Компания - это отдельное измерение и поэтому получить данные в ее разрезе нет проблем.

Да. Забыл, что компании обычно делают отдельным измерением...

Цитата:

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

Но если компании полностью независимы, и у них разные (непересекающиеся) клиенты и номенклатура и прочие справочники, то можно не заморачиваться.

Ну, это вариант, близкий к фантастическому Чтобы наши люди да не "извратились"! Не может такого быть

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

Да. Забыл, что компании обычно делают отдельным измерением...

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

[Cardagant]

Цитата:

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

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

То есть, исходя из Вашей точки зрения, можно складывать абсолютно несовместимые номенклатуры с одним и тем же кодом при просмотре кросс-компаний?

И если у номенклатуры с кодом "0001" я хочу установить отображаемое имя как Наименование номенклатуры для иерархии кодов номенклатур, какое имя будет выбрано, если, к примеру номенклатур с кодом "0001" штук 5 или даже 10 в разрезе компаний?

Или Вы считаете, что должны быть 2 отдельных иерархии по кодам и по имени? Тогда это возвращает к вопросу о суммировании абсолютно несовместимых номенклатур при кросс-компаниях.

[Cardagant]

Цитата:

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

А чем не устраивает составной ключ в хранилище данных? Например, кубы от MS SQL вполне хорошо работают с составными ключами.

2 twilight

Спасибо Владимир Максимов, описал проблему будто мысли прочёл. Правда, всё связано с атомарностью. Составные ключи сложны при работе с измерениями в хранилище.