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

[Cardagant]

Добрый день всем!

Сначала хотел бы задать общий вопрос к общественности:

Строил ли кто-то хранилище данных (Кимбал / Инмон, не важно) на основе базы данных Аксапты,
чтобы понимать стоит ли продолжать эту тему здесь.

Спасибо!

[Cardagant]

Прошу изменить раздел форума, если нужно, так как не знаю куда лучше поместить такую тему. Спасибо!

[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(). Возможно в данном случае будет возможно обойтись пере таблиц-перекодировщиков?

[twilight]

Цитата:

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

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

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

Цитата:

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

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

[Cardagant]

Цитата:

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

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

2 twilight

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

[Ivanhoe]

Уточните, вы хотите только про DWH поговорить или и дальше про кубы? Стандартные кубы в пример не годятся?

[Cardagant]

Цитата:

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

Уточните, вы хотите только про DWH поговорить или и дальше про кубы? Стандартные кубы в пример не годятся?

На мой взгляд в данном контексте эти сущности находятся в единой цепочке и должны обсуждаться вместе. Неправ?

Стандартные кубы не являются примером, так как они не имеют под собой хранилища данных в классическом понимании. Также они не работают с SCD2 и сурогатными ключами.

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

[Ivanhoe]

Цитата:

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

На мой взгляд в данном контексте эти сущности находятся в единой цепочке и должны обсуждаться вместе. Неправ?

Мне кажется, что при существовании DWH, вопросов по построению кубов уже не будет Вопросы по ключам - это этап построения DWH. И если мы говорим про проблему с ключами (и то, что вы пишите - классический технический подход), то почему мы не говорим про MDM? При наличии такого процесса в компании, вопрос с ключами решается именно в рамках этой дисциплины.

[Cardagant]

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

Если я ищу продажи на количество работников (всех работающих в текущий момент), то я не могу просто подсчитать количество атрибутов измерения и разделить продажи на это количество. Так как согласно бест практис хранилищ, насколько я знаю, данные из измерений не удаляются (SCD1). А в случае просто подсчёта по измерению, мы будем учитывать также и тех работников, которые уже не работают на предприятии.

Соответственно, думаю, лучшим решением здесь будет выделить отдельную таблицу фактов Работники (и считать по ней count) наряду с таблицей измерения. В этом факте вставлять / удалять строки, согласно изменениям в таблице источника (Аксапте).

Но не будет ли это дублированием данных измерения? Или в данном случае без этого не обойтись?

Чувствую, что это нечто простое и концептуальное, но понять не могу.

Прошу помощи у форумчан, кто сталкивался

P.S. Да и любые мысли по этому поводу очень нужны. Спасибо заранее!

[Raven Melancholic]

Если уж строить хранилище данных, то, скорее всего, Акса будет не единственным источником для этого хранилища, поэтому подробности ключей в самой Аксе не так важны.
Первая по важности проблема это "очистка данных", то есть приведение их к тому виду, который нужен для дальнейшего анализа. В частности, по справочникам это объединение одинаковых по сущности позиций, но с какими-то различиями к одному.
По тем же клиентам, это не обязательно разные коды клиентов в разных компаниях, это может быть и в рамках одной компании. Например, по каким-то соображениям "оптимизации" или при реорганизации клиент перерегистрируется, в итоге у него другие ИНН, адрес и т.п. С юридической точки зрения это другой клиент и нужно заводить новую карточку, но для анализа продаж, назначения скидок и прочих коммерческих дел эти разные карточки нужно учитывать как одну сущность.
Возможно, в некоторых готовых системах существуют какие-то изощренные методы для этого, но, на мой взгляд, самое простое это иметь какие-то таблицы соответствия, в которых одна из карточек назначена "главной". При выгрузке хранилища все остальные карточки справочника (и, соответственно, операции) грузятся с ключом главной.

[Raven Melancholic]

О, пока писал, появилось уточнение, что дело в номенклатурах.
У нас тоже в разных компаниях разные наименования и одинаковый код (но не DAX2012).
У торговых домов свои зарегистрированные торговые марки, но производство и закупочная компания общие для всех торговых домов. В производственной и закупочной компании номенклатуры заводятся с каким-то наименованием, отражающим их сущность, а в торговых домах наименования с учетом торговой марки. В хранилище выгружаются именно производственные и закупочные наименования (так называемые внутренние наименования).
Это всех устраивает, так как для анализа не важно какие наименования используются в прайс-листах, в документах и т.п. Например, если внутреннее наименование "Деталь № 2 200х120 нержавейка", то наличие названия в одном торговом доме "AVZ 200/120 Н", в другом "FTG-Н 200:120" совсем не влияет на прогноз продаж.
В общем, главное определить что является "главным".

[Cardagant]

Цитата:

Сообщение от Raven Melancholic

О, пока писал, появилось уточнение, что дело в номенклатурах.
У нас тоже в разных компаниях разные наименования и одинаковый код (но не DAX2012).
У торговых домов свои зарегистрированные торговые марки, но производство и закупочная компания общие для всех торговых домов. В производственной и закупочной компании номенклатуры заводятся с каким-то наименованием, отражающим их сущность, а в торговых домах наименования с учетом торговой марки. В хранилище выгружаются именно производственные и закупочные наименования (так называемые внутренние наименования).
Это всех устраивает, так как для анализа не важно какие наименования используются в прайс-листах, в документах и т.п. Например, если внутреннее наименование "Деталь № 2 200х120 нержавейка", то наличие названия в одном торговом доме "AVZ 200/120 Н", в другом "FTG-Н 200:120" совсем не влияет на прогноз продаж.
В общем, главное определить что является "главным".

Вы безусловно, правы и это всё имеет место быть.

Однако, также имеют место ситуации, когда Аксапта ведётся и в двух "автономных" компаниях.

К примеру, одна торгует велосипедами ,а вторая вертолётами.

Вполне может быть ситуация, когда номенклатура "0001 в одном случае может содержать "обод" для компании 1 и тот же код в компании 2 будет описан как "Винтовая лопасть", которые не имеют ничего общего.

(Пример абстрактный)

[Raven Melancholic]

Да, возможен и такой вариант. Но, опять же, вступает в силу правило "очистки": одинаковые сущности должны сводиться в одну позицию хранилища, разные - в разные. То есть, в хранилище данных обод и пропеллер должны иметь разные сущности. Как это будет реализовано уже другой вопрос, но опять же, практически это реализация таблицы сопоставлений. Возможно, что в ней ключами для конкретной компании (если смотреть до DAX2012) будет компания+код, а значением - какой-то код. В DAX2012, компания уже не нужна, нужна патриция.
Кстати, если уж привязаться к DAX2012 то рассматривать придется не разные компании, а разные партиции, так как код продукта в одной партиции единый.

[Cardagant]

Цитата:

Сообщение от Raven Melancholic

Да, возможен и такой вариант. Но, опять же, вступает в силу правило "очистки": одинаковые сущности должны сводиться в одну позицию хранилища, разные - в разные. То есть, в хранилище данных обод и пропеллер должны иметь разные сущности. Как это будет реализовано уже другой вопрос, но опять же, практически это реализация таблицы сопоставлений. Возможно, что в ней ключами для конкретной компании (если смотреть до DAX2012) будет компания+код, а значением - какой-то код. В DAX2012, компания уже не нужна, нужна патриция.
Кстати, если уж привязаться к DAX2012 то рассматривать придется не разные компании, а разные партиции, так как код продукта в одной партиции единый.

Спасибо, что принимаете участие в обсуждении.

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

Из последнего, что нашёл, то можно склеивать строку Партиция+Компания+Код и применять СКЛ функцию HASHBYTES() Пишут, что она может обеспечить уникальность значений в данном случае.

То есть, тогда иметь в измерении номенклатур хранилища Этот код, поле с натуральным кодом и наименованием номенклатуры в качестве имён для измерения. В более сложных случаях ещё и суррогатный ключ в виде целого числа (Identity поля) для SCD2.

Что думаете об этом?