AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.12.2014, 13:55   #1  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
DAX и хранилище данных
Добрый день всем!

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

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

Спасибо!

Последний раз редактировалось Cardagant; 05.12.2014 в 14:08.
Старый 05.12.2014, 13:56   #2  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Прошу изменить раздел форума, если нужно, так как не знаю куда лучше поместить такую тему. Спасибо!
Старый 05.12.2014, 17:49   #3  
imir is offline
imir
Участник
 
159 / 161 (6) ++++++
Регистрация: 28.05.2010
Строил когда-то. В кратце - выписываются таблицы и поля в них, и тянутся в DWH. Тянем только изменения, опираясь на дату модификации записи. Удаленные записи можно взять запросом, можно отслеживать триггером. Это первая часть. Вторая - строим из этих данных таблицы фактов и измерения. Третья - кубы.
Старый 05.12.2014, 18:46   #4  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от imir Посмотреть сообщение
Строил когда-то. В кратце - выписываются таблицы и поля в них, и тянутся в DWH. Тянем только изменения, опираясь на дату модификации записи. Удаленные записи можно взять запросом, можно отслеживать триггером. Это первая часть. Вторая - строим из этих данных таблицы фактов и измерения. Третья - кубы.
Спасибо, что откликнулись.

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

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

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

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

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

Последний раз редактировалось Cardagant; 05.12.2014 в 18:55.
Старый 05.12.2014, 21:28   #5  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Уточните, вы хотите только про DWH поговорить или и дальше про кубы? Стандартные кубы в пример не годятся?
__________________
Ivanhoe as is..
Старый 05.12.2014, 22:09   #6  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Уточните, вы хотите только про DWH поговорить или и дальше про кубы? Стандартные кубы в пример не годятся?
На мой взгляд в данном контексте эти сущности находятся в единой цепочке и должны обсуждаться вместе. Неправ?

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

На мой взгляд, кубы Аксапты - это на порядок упрощённая структура, которая позволяет производить анализ данных. При этом ограничиваясь только некоторыми возможностями классического хранилища. На мой вопрос они ответа не дают.
Старый 06.12.2014, 11:46   #7  
imir is offline
imir
Участник
 
159 / 161 (6) ++++++
Регистрация: 28.05.2010
Цитата:
Сообщение от Cardagant Посмотреть сообщение
В каждом измерении у нас есть ключ по трём полям (составной ключ), к примеру:
Partition + DataArea + CustAccount для кастомеров.

Как строили единый первичный ключ на основе составного?
В реальности Partition не используются, а при наличии нескольких компаний справочник клиентов обычно делается виртуальный, т.е. общий между компаниями. Т.е. в качестве ключа вполне можно использовать CustAccount.
Старый 06.12.2014, 12:42   #8  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от imir Посмотреть сообщение
В реальности Partition не используются, а при наличии нескольких компаний справочник клиентов обычно делается виртуальный, т.е. общий между компаниями. Т.е. в качестве ключа вполне можно использовать CustAccount.
Да, это имеет смысл.

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

А если бы решали этот вопрос, в каком направлении было бы решение?
Старый 06.12.2014, 12:53   #9  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Если уж строить хранилище данных, то, скорее всего, Акса будет не единственным источником для этого хранилища, поэтому подробности ключей в самой Аксе не так важны.
Первая по важности проблема это "очистка данных", то есть приведение их к тому виду, который нужен для дальнейшего анализа. В частности, по справочникам это объединение одинаковых по сущности позиций, но с какими-то различиями к одному.
По тем же клиентам, это не обязательно разные коды клиентов в разных компаниях, это может быть и в рамках одной компании. Например, по каким-то соображениям "оптимизации" или при реорганизации клиент перерегистрируется, в итоге у него другие ИНН, адрес и т.п. С юридической точки зрения это другой клиент и нужно заводить новую карточку, но для анализа продаж, назначения скидок и прочих коммерческих дел эти разные карточки нужно учитывать как одну сущность.
Возможно, в некоторых готовых системах существуют какие-то изощренные методы для этого, но, на мой взгляд, самое простое это иметь какие-то таблицы соответствия, в которых одна из карточек назначена "главной". При выгрузке хранилища все остальные карточки справочника (и, соответственно, операции) грузятся с ключом главной.
Старый 06.12.2014, 13:06   #10  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
О, пока писал, появилось уточнение, что дело в номенклатурах.
У нас тоже в разных компаниях разные наименования и одинаковый код (но не DAX2012).
У торговых домов свои зарегистрированные торговые марки, но производство и закупочная компания общие для всех торговых домов. В производственной и закупочной компании номенклатуры заводятся с каким-то наименованием, отражающим их сущность, а в торговых домах наименования с учетом торговой марки. В хранилище выгружаются именно производственные и закупочные наименования (так называемые внутренние наименования).
Это всех устраивает, так как для анализа не важно какие наименования используются в прайс-листах, в документах и т.п. Например, если внутреннее наименование "Деталь № 2 200х120 нержавейка", то наличие названия в одном торговом доме "AVZ 200/120 Н", в другом "FTG-Н 200:120" совсем не влияет на прогноз продаж.
В общем, главное определить что является "главным".
Старый 06.12.2014, 14:02   #11  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
О, пока писал, появилось уточнение, что дело в номенклатурах.
У нас тоже в разных компаниях разные наименования и одинаковый код (но не DAX2012).
У торговых домов свои зарегистрированные торговые марки, но производство и закупочная компания общие для всех торговых домов. В производственной и закупочной компании номенклатуры заводятся с каким-то наименованием, отражающим их сущность, а в торговых домах наименования с учетом торговой марки. В хранилище выгружаются именно производственные и закупочные наименования (так называемые внутренние наименования).
Это всех устраивает, так как для анализа не важно какие наименования используются в прайс-листах, в документах и т.п. Например, если внутреннее наименование "Деталь № 2 200х120 нержавейка", то наличие названия в одном торговом доме "AVZ 200/120 Н", в другом "FTG-Н 200:120" совсем не влияет на прогноз продаж.
В общем, главное определить что является "главным".
Вы безусловно, правы и это всё имеет место быть.

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

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

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

(Пример абстрактный)
Старый 06.12.2014, 15:10   #12  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Да, возможен и такой вариант. Но, опять же, вступает в силу правило "очистки": одинаковые сущности должны сводиться в одну позицию хранилища, разные - в разные. То есть, в хранилище данных обод и пропеллер должны иметь разные сущности. Как это будет реализовано уже другой вопрос, но опять же, практически это реализация таблицы сопоставлений. Возможно, что в ней ключами для конкретной компании (если смотреть до DAX2012) будет компания+код, а значением - какой-то код. В DAX2012, компания уже не нужна, нужна патриция.
Кстати, если уж привязаться к DAX2012 то рассматривать придется не разные компании, а разные партиции, так как код продукта в одной партиции единый.
Старый 06.12.2014, 15:29   #13  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Опять же, если привязываться к конкретным реализациям (та же DAX2012) по номенклатуре, то все равно даже код номенклатуры не совсем определяет нужную позицию.
Например, если использовать в качестве системы планирования Hypirion, но нужно как-то определять систему НСИ. Часто используемая связка для Hypirion в качестве системы НСИ в России это "Норма" от Ланит. В Норме нет таких понятий, которые есть в DAX как "Конфигурация", "Размер", "Цвет", в итоге приходится комбинации номенклатура+конфигурация+что-то из DAX (в DAX2012 это вариант продукта) преобразовывать в один код Нормы. Ну и, наоборот, один код Нормы нужно преобразовать в вариант продукта.
В Вашем случае, один код в разных партициях это разные сущности для которых нужно каким-то образом обеспечить идентификацию в хранилище по данным Аксы и наоборот, из кода в хранилище, обеспечить соответствие объекта в DAX.
В DAX2012 R3 в подсистеме прогнозирования спроса такие соответствия предлагают определять через ключи распределения. Понятно, что при помощи ключей распределения можно определить только достаточно ограниченные концепции, но что-то в этом есть.
Старый 06.12.2014, 15:55   #14  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Да, возможен и такой вариант. Но, опять же, вступает в силу правило "очистки": одинаковые сущности должны сводиться в одну позицию хранилища, разные - в разные. То есть, в хранилище данных обод и пропеллер должны иметь разные сущности. Как это будет реализовано уже другой вопрос, но опять же, практически это реализация таблицы сопоставлений. Возможно, что в ней ключами для конкретной компании (если смотреть до DAX2012) будет компания+код, а значением - какой-то код. В DAX2012, компания уже не нужна, нужна патриция.
Кстати, если уж привязаться к DAX2012 то рассматривать придется не разные компании, а разные партиции, так как код продукта в одной партиции единый.
Спасибо, что принимаете участие в обсуждении.

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

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

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

Что думаете об этом?
Старый 06.12.2014, 19:47   #15  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Cardagant Посмотреть сообщение
На мой взгляд в данном контексте эти сущности находятся в единой цепочке и должны обсуждаться вместе. Неправ?
Мне кажется, что при существовании DWH, вопросов по построению кубов уже не будет Вопросы по ключам - это этап построения DWH. И если мы говорим про проблему с ключами (и то, что вы пишите - классический технический подход), то почему мы не говорим про MDM? При наличии такого процесса в компании, вопрос с ключами решается именно в рамках этой дисциплины.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: Cardagant (1).
Старый 06.12.2014, 20:53   #16  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Вот только сейчас задумался глубже о расчёте требуемого показателя (продажи / количество работников, работающих в текущий момент) и поднятом вопросе о DistinctCount по измерению..

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

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

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

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

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

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

Последний раз редактировалось Cardagant; 06.12.2014 в 21:01.
Старый 07.12.2014, 16:50   #17  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
работающих в текущий момент
А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.
За это сообщение автора поблагодарили: Cardagant (1).
Старый 07.12.2014, 19:38   #18  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.
Спасибо за ответ! Ваш тезис ясен: Хранилище - система для "анализа" и хранения информации в историческом контексте. Для отчётов "на данный момент" (на сейчас) как ничто лучше подойдёт OLTP транзакционная база. Абсолютно согласен.

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

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

Последний раз редактировалось Cardagant; 07.12.2014 в 20:51.
Старый 08.12.2014, 09:33   #19  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.
__________________
Ivanhoe as is..
Старый 08.12.2014, 09:34   #20  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.
__________________
Ivanhoe as is..
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Проведите ликбез по DAX, плиз ) Andey DAX: Программирование 3 23.05.2012 12:27
Создание снимков изменений в базе данных Ace of Database DAX: Программирование 17 01.11.2011 12:34
aEremenko: Тестирование производительности в DAX 4.0 Blog bot DAX Blogs 0 12.03.2008 16:05
dax-lessons: Active directory in Axapta Blog bot DAX Blogs 0 27.08.2007 23:00
Как настроить репликацию таблиц Аксапта в хранилище данных для OLAP max_spbti DAX: Функционал 4 28.06.2004 10:32
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:32.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.