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

[Cardagant]

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

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

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

Спасибо!

[Cardagant]

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

[imir]

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

[Cardagant]

Цитата:

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

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

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

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

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

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

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

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

[Ivanhoe]

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

[Cardagant]

Цитата:

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

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

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

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

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

[imir]

Цитата:

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

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

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

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

[Cardagant]

Цитата:

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

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

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

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

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

[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 то рассматривать придется не разные компании, а разные партиции, так как код продукта в одной партиции единый.

[Raven Melancholic]

Опять же, если привязываться к конкретным реализациям (та же DAX2012) по номенклатуре, то все равно даже код номенклатуры не совсем определяет нужную позицию.
Например, если использовать в качестве системы планирования Hypirion, но нужно как-то определять систему НСИ. Часто используемая связка для Hypirion в качестве системы НСИ в России это "Норма" от Ланит. В Норме нет таких понятий, которые есть в DAX как "Конфигурация", "Размер", "Цвет", в итоге приходится комбинации номенклатура+конфигурация+что-то из DAX (в DAX2012 это вариант продукта) преобразовывать в один код Нормы. Ну и, наоборот, один код Нормы нужно преобразовать в вариант продукта.
В Вашем случае, один код в разных партициях это разные сущности для которых нужно каким-то образом обеспечить идентификацию в хранилище по данным Аксы и наоборот, из кода в хранилище, обеспечить соответствие объекта в DAX.
В DAX2012 R3 в подсистеме прогнозирования спроса такие соответствия предлагают определять через ключи распределения. Понятно, что при помощи ключей распределения можно определить только достаточно ограниченные концепции, но что-то в этом есть.

[Cardagant]

Цитата:

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

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

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

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

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

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

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

[Ivanhoe]

Цитата:

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

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

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

[Cardagant]

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

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

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

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

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

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

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

[Raven Melancholic]

Цитата:

работающих в текущий момент

А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.

[Cardagant]

Цитата:

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

А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.

Спасибо за ответ! Ваш тезис ясен: Хранилище - система для "анализа" и хранения информации в историческом контексте. Для отчётов "на данный момент" (на сейчас) как ничто лучше подойдёт OLTP транзакционная база. Абсолютно согласен.

Хочу лишь заметить, что я не искусен в искусстве построения хранилищ данных, все эти концепции для меня новы, поэтому и прощу помощи. Мне просто дали репорты и сказали хотим перенести их в кубы, построенные на хранилище данных. Вот теперь мучаюсь... Но хочется сделать всё правильно и эффективно...

Один из репортов привёл в предыдущем сообщении.

[Ivanhoe]

Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.

[Ivanhoe]

Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.