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

[imir]

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

[Cardagant]

Цитата:

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

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

Спасибо, что откликнулись.

У меня конкретный вопрос. (DAX 2012)

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

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

Мне нужно считать DistinctCount по измерению, при этом в разных компаниях коды кастомеров могут повторяться.

P.S. Имеется сурроганый ключ с поддержкой SCD2 измерения. (но это уже дело второе, сейчас актуален вопрос о составном / первичном ключе)

[imir]

Цитата:

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

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

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

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

[Cardagant]

Цитата:

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

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

Да, это имеет смысл.

Могу сказать, что в моей ситуации имеются не клиенты, но номенклатуры в разных компаниях с одинаковыми кодами, но разными наименованиями.

А если бы решали этот вопрос, в каком направлении было бы решение?

[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]

Цитата:

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

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

2 twilight

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