Лекция 6

Жизненный цикл ХД – слайд со схемой в презентации.

Характерная черта – нет утилизации, вывода из эксплуатации.

1. Инициация проекта

2. Сбор бизнес-требований (business requirements definition). Тут у нас консалтинг, приоритезация требований и вся фигня.

3. Результатом этого сбора является некоторая таблица, в которой перечислены измерения и фактические области данных. Смысл в том, что по строкам пишутся факты, по столбцам – измерения, а на их пересечении ставится отметка, если факт относится к измерению.

4. Проектирование и разработка. Архитектура:

   1. Техническая – программно-аппаратная часть внедрения.

   2. Безопасность, архивирование, прочие нетехнические требования.

5. Развертывание, интеграция в предприятие.

Ну в общем это все не совсем так, правильно – на картинке со слайдов.

Успех создания ХД во многом зависит от качества ETL, которое очень сильно зависит от качества исходных данных. В общем. ETL – это очень важно. =)

Профилирование данных – это выяснение возможных значений, это делается перед созданием ETL.

Этапы проектирование DWH:

1. Определение фактов – это есть результат бизнес-анализа.

2. Добавление временнЫх ключей. Каждый факт должен иметь привязанность к времени. Можно добавить время в бизнес-ключ каждого факта и измерения, но это фигово, потому что ключ получится составным. Поэтому связку – бизнес-ключ, время – делают альтернативным ключом и вводят суррогатный ключ.

3. Добавление производных данных. Это то, что нету в оперативной БД, но обычно нужно при анализе.

4. Определение гранулярности данных – в смысле насколько мы можем сделать drillиться в эти данные вглубь.

5. Объединение измерений. Некоторые измерения, если вариантов атрибутов у них немного (до 5-и), можно объединить в одну табличку-измерение.

6. Создание массивов. Если нам не нужны точные, гранулированные данные, можно объединить их в группы по некоторому признаку. Если попадает у факта значение в диапазон, то он относится к группе. Пример – уровень дохода.

7. Агрегирование и разделение данных. Агрегаты могут храниться и в одной таблице с детальными данными, но чаще – в отдельной таблице.

Зачем делать время отдельным измерением – чтобы хранить доп. атрибуты, связанные с конретными днями.

Иерархии:

1. По отдельной таблице для каждого уровня иерархии

2. Parent-child (в одной таблице)

3. Отделение связи между parent и child ом в отдельную таблицу, обеспечивающую связь. Это круче всего, можно поддержать хранение истории изменения иерархии без изменения самого товара. Плюс возможность задать альтернативные иерархии – более одного родителя можно задать. Ну и еще много всякого стафа можно сделать. Получается 2 таблицы – смысловая и вспомогательная, обеспечивающая иерархию.

Что должно быть атрибутом, что должно быть отдельным измерением?

Есть несколько наборов атрибутов. Если между атрибутами отношение «многие-ко-многим», то они должны быть в разных измерениях. Если связь между атрибутами «один-ко-многим», то это одно измерение.

PowerDesigner – аналог ERWin’а, более мощное средство.