DHW-вопросикУважаемые практики!

Поделитесь, пожалуйста, рекомендациями по вопросу как спроектировать ХД, чтобы учесть изменения в фактах и измерениях?

Для простоты возьмём лишь следующие сущности:
-- измерения (первые три – это parent-child)
1. компании (key_company, companyName, …)
2. договора (key_treaty, key_company, treatyNumber, acceptDate, status, ….)
3. условия договора (позиции) (key_position, key_treaty, currency, startDate, endDate, positionType,…)
4. отчётные периоды (key_date, date,…)


-- факты
начисления (key_position, key_date, premium, premiumRub,…)

Многоточие означает, что в таблице есть другие атрибуты и меры.



Начнём с измерений:
(1). Компании могут:
- просто изменять своё название
- закрываться (переставать существовать)
- две объединяться в одну (по каким-то причинам в OLTP-системе введены дважды или
действительно юридически объединяться)
В OLTP-системе ведётся учёт того, когда, что произошло с компанией – есть подчинённая таблица в которой (key_company, oldCompanyName-прежнее наимнование, dateChange дата актуальности по, cause - причина)
(3). В условиях договора могут изменяться валюта (currency) и/или период действия позиции (startDate, endDate)


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

При анализе, при формировании отчётности необходимо получать такую картину, которая была по состоянию на тот момент. Так,
-- по состоянию на 01.01.2005 компания «Альфа» именовалась «Альфа» и по ней начислено премии 10К USD (30 000руб)
-- по состоянию на 01.04.2005 она стала именоваться «Бета» и премии по ней начислено 10К EUR (35 000руб)
-- по состоянию на 01.07.2005 премии начислено 5К EUR (17 000руб) (поскольку было сторнирование начисления)

Как должны выглядеть хранилище данных – добавлены ли доп. таблицы или добавлены поля?

1. Для реализации хранилища Вам не надо так переживать за OLTP.
2. Главное реализация основных объектов в DWH:
а.Механизм измерний
б. Механизм фактов
3. Чётко сформулирывать требования о том что может произойти с измереним, его иерархией. Чем они будут проще в ОЛТП, тем Вам будет легче.

4. Выделив все типы измерений, которые Вы планируете реализовать, приготовится к их реализации. Вероятнее всего у Вас будет SCD Type 2 - как основа ( что означает следующее: при изменении каких либо реквизитов измерения - вы это отразите в введённых Вами полях DATE_BEGIN & DATE_END и конечноже новго SID, что послужит Вам как пометкой на диаграмме Ганта в изменяющихся свойствах измерения).

Из этой основы в последсвии будет не сложно выделить "младшего брата" вашего измерения, которое будет содержать лишь информации о состоянии измерения "на сейчас" - для оператвных отчётов.

Используя SCD 2 вы будете иметь возможность охарактеризовать элемент измерения, на любой момент времени.

5. На счёт иерархии - наверно самое сложное. Если она у Вас сбаланисрована, то вы её можете привести от "parent-child" к отношению таблиц 3NF. и хорошо, когда у Вас изменятся\мигрирует только нижний уровень - задача сводится от обслуживания иерархии к свойствам SID ( сурогатного идентификатора элемента измерения ).

Если рассматривать случай изменения всех уровней иерархии, то ВЫ столкнётесь высоким уровнем роста кл-ва SID в измерении.
( представлете : Москва вдруг числится не в России, а Беларуссии - а значит надо перегистрирывать всех москвичей, с новой пропиской :)

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


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

Не соглашайтесь в поставленном ТЗ на возможность изменения элемента измерения ( элемента его иерархии) задним числом - это усложняет реализацию.


P.S. когда вы на практике реализуете Ваши измерения, то факты - для Вас будут как семечьки.

P.P.S. Постарайтесь переубедить Ваших заказчиков не идти этим путём, а вместо первички хранить отчёты.

DHW-вопросикПрочитав статьи Кибалла, понял так что SCD реализуется так:
......


Задача Кимбала - раскомплексовать ваше воображение, берите от него лучшее и придумывайте свои особенности

DHW-вопросик
==============================================
to Parkhomets Andrey:

по поводу п.5 хотелось бы уточнить - как будут физически выглядеть
-- вариант "версий" измерения
-- новая "инкарнация" измерения - действующая в определённое время
-- динамический модуль для крупного и несбалансированного древовидного
измерения


-- вариант "версий" измерения и инкарнаций - это, наверно, мой личный жаргон.
Имеется в виду что вы в ROLAP схеме куба можете сделать дополнительное измерение - а то и больше, которое будет отражать одну сущность в разное время. Но я бы не пошёл таким путём, это того не стоит. Прощё перейти на витрины данных : ( например в 2006 году у вас измерение "сотрудники" было одного состава, а в 2007 абсолютного другого. Отсюда можно сделать два куба. Даже если содержание кубов перекрывается и будет избыток данных на магнитных носителях- так проще.) Если рассматривать промышленные решения то в SAP BW реализованно так, что вы можете в отчёте выбрать то состояние имерархии - которое Вам более необходимо. ЗА счёт того, что в SAP BW измерение и его иерархия отделены друг от друга через связующую таблицу, на которой может висеть сколь угодно иерархий. Все эти подходы упираются в функционал клиентского приложения.

-- на счёт последнего: идея в то, чтобы приводить self-jouin (parent-chield) измерение в правильный вид. Я говрю про ROLAP. В такой вид, в которм у Вас каждая колонка отражает уровень ииерархии - именно такой вид требуется для Oracle Discoverer. Несбалансированность решается путём "дублирования" - заполнения верхних уровней такими же как и нижние.
Имея исходное измерение - вы отслеживаите момент изменения кл-ва уровней, и пересчитываете его в вашу целевую таблицу, как правило при этом ломаются отчёты.


Если отказатся от построения большей отчётности в ROLAP то хранилище лучше заточить не под клиентсое приложение, а под способность хранить всю нужную Вам информаци, и быстрое её получение. Это наверно самый главный вывод, к которому я пришёл, после попытки реализовать хранилище, под Discovrer.

Данные нуждающиеся во вращении переливайте в MOLAP ( например от Microsoft-а, а хватит ума то и в Oracle зальёш).