Лекция 2.

Литература по хранилищам данных BI, бизнес-аналитики и т. д.:

1. Infology.ru

2. Olap.ru

3. Sql.ru

4. Книги Ральфа Кимбалла

5. Туманов В. Е. Проектирование ХД для систем бизнес-аналитики

6. Теорию можно почитать на Интуите

Подходы к моделированию ХД.

1. Модель ER (сущность-свзяь)

2. Многомерное моделирование (Dimensions model, DM)

3. Свод данных (Data Vault)

В основном используются первые 2 подхода.

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

Понятия в реляционных БД:

1. Первичный ключ – однозначный идентификатор объекта, состоит из минимального набора атрибута (может быть составным, состоять из нескольких атрибутов)

2. Внешний ключ

3. Бизнес ключ (альтернативный ключ, естественный ключ) – ключ, который имеет смысл в предметной области, например, паспорт, фамилия и так далее, но этот ключ неудобен обычно

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

Третий и четвертый ключ используются вместе.

Пример. Сформировать ХД для хранения информации для обеспечения анализа состояния на рынке недвижимости. Нужны данные о предложении и о покупках (анализ договоров купли-продажи).

Решение.

Проанализировать предметную область и понять что нам нужно. Для этого надо ответить на вопросы:

1. Когда

2. Где

3. Кто

4. Что

5. Почему

6. Как

Выделить необходимые объекты предметной области.

В примере возникают следующие сущности:

1. Квартира

2. Дом

3. Адрес

4. Владелец

5. Застройщик

6. Покупатель

Что анализируем:

1. Предложение

2. Продажи

После этого рисуется ER-диаграммка.

Адрес – это как бы территория, где находится несколько домов.

Гранулярность – детализированность данных. Она может относиться к каждой сущности.

При запросе соединяем несколько таблиц, группируем и ставим условия.

В этой схеме нет поддержки хранения истории и изменений. Поэтому это не хранилище данных, а обычная оперативная БД. =)

Для поддержки времени:

Есть два способа:

1. Поддержка моментальных снимков (копия таблиц на определенный момент времени)

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

Например:

Введены поля:

1. Время начала действия атрибутов

2. Время окончания действия атрибутов

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

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

Slow-change dimension (SCD).

Это относится к многомерной модели. Тут атрибуты, такие как объект, дом и так далее, называются измерениями (dimensions).

Так как они меняются редко, они называются более узко – slow change dimension. Этот термин ввел Кимбалл.

Существуют три типа поддержки:

1. Нет поддержки вообще (первая версия нашей модельки, так как всегда хранится только текущее состояние дел). Изменения вообще не хранятся.

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

3. Добавление нескольких атрибутов вместо того атрибута, который может меняться. Это ограничивает срок хранения истории количеством добавленных атрибутов. Пример ниже:

Тогда мы будет хранить историю с точностью до предыдущего владельца.

Многомерное моделирование.

Основные понятия:

1. Меры (показатели) – measure – всегда числовое значение

2. Факт – fact

3. Измерение – dimension – может состоять из нескольких атрибутов (текстовых, числовых, каких угодно)

Факты содержат набор мер (значений) по определенным измерениям.

Измерения показывают детализацию или изменение того или иного факта.

Факты бывают исходные и производные (предпосчитанные, так сказать).

Измерение может быть вырожденным если оно находится в самой таблице фактов (например, часто таким измерением бывает время).

Сделаем модельку типа «звезда» в многомерной модели:

Это круто, так как можно не хранить конкретные объекты, это более соответствует тому, что есть на самом деле. Эта схема более общая, тут можно хранить не только объекты и их детализацию, а обобщенные характеристики. То есть типы объектов. Если нам не нужны конкретные объекты, а только типы объектов. То есть вместо измерений Дом, Объект, Адрес можно сделать другие измерения – однокомнатные квартиры или же дома на улице такой-то. Это более похоже на то, что требуется для витрин данных.

Так вот Инман – это 3НФ, так как тут все логично.

Кимбалл – за многомерность, тут тоже можно в принципе хранить детализацию, но можно и хранить обобщенную информацию.

Факты делятся на:

1. Транзакционные данные

2. Данные моментальных снимков (на определенный момент времени)

   1. Периодические – например, остаток товара на складе на какой-то момент

   2. Кумулятивные (накопительный) – это например сумма продаж сначала года, это фиксация определенного факта

Еще факты бывают:

1. Аддитивным – когда его можно складывать по любым измерениям (например, объем продаж)

2. Полуаддтитивный – когда по некоторым измерениям операция сложения возможна, а по некоторым нет (например, количество товаров, их нельзя складывать по измерению «товары», так как нельзя сложить тонну воды с количеством батонов, но можно складывать, например, по регионам)

3. Совсем неаддитивный – вообще нельзя складывать. Например, температура, давление.

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

Если между сущностями связь типа «один ко многим или наоборот», то одна сущность скорее всего является атрибутом другой.

Иерархии – бывают двух типов:

1. Сбалансированные – когда все элементы последнего уровня находятся на одном уровне. То есть количество предыдущих уровней для всех элементов одного уровня равно. Обычно реализуется таблицей из столбцов, каждый из которых отвечает за уровень иерархии, причем пропусков нигде нет.

2. Несбалансированные – соответственно, наоборот. Обычно это подчиненность – одному уровню могут быть подчинены разные уровни.

Это поддерживается путем создания «технических уровней» между напрямую подчиненными разными уровнями. Или же возможно создание связи таблицы с самой собой (структура parent_child), где каждому отдельному уровню (строчке) присваивается значение одного из столбцов, где указывается родитель (то есть то, кому данный уровень починяется). Такая структура позволяет создавать любые иерархии, в том числе несбалансированные. Но тут есть проблема с развертыванием-свертыванием, это будет довольно затратная операция. Хотя так все делают. =)

Data Vault.

Это попытка совместить многомерный подход и нормальные формы.

Ее предложил Ден Листред. Она вообще в 3НФ.

Понятия:

1. Hub -- сущности

2. Satellite – аттрибуты

3. Link – связь между сущностями

Hub содержит только идентификатор, дату загрузки значения и источник данных. Модель сделана специально для ХД.

Суть сателлитов в том, что можно добавлять атрибуты, создавая новые таблицы, не переформатируя имеющиеся. Это круто для ХД.

Пример:

Тут тоже есть 3НФ, но тут проконтралирован процесс загрузки данных (прозрачность данных есть), а также существенно упрощено добавление новых атрибутов.

Это с одной стороны многомерный подход, с другой стороны, тут есть 3НФ. Несмотря на то, что связей тоже дофига получается, но крупные хранилища строятся.

Вообще просто 3НФ для ХД почти не используется. Обычно используется многомерное моделирование.