1. Витрины данных, как обособленная (специализированная) часть хд

• Поскольку конструирование хранилища данных — сложный процесс, который может занять несколько лет, некоторые организации вместо этого строят витрины данных (data mart), содержащие информацию для конкретных подразделений.

• Например, маркетинговая витрина данных может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок.

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

• Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета полной бизнес-модели.

2. Витрины данных (вид хд) , как промежуточная часть хд.

• Витрина данных (data mart) — это набор данных за определенный период времени, хранящихся в электронном хранилище и не использующихся в повседневной деятельности организации.

• Вместо этого данные применяются для решения BI—задач, как промежуточное место хранения информации извлеченной из OLTP-систем. Данные, находящиеся в витрине, обычно относятся к конкретной области деятельности организации.

Особенности организации витрин данных

• Витрины данных нацелены на использование в качестве источников аналитической информации, а не на поддержку повседневной деятельности организации, и строятся они не так, как базы данных OLTP—систем.

• Вместо правил нормализации краеугольным камнем построения витрин данных является скорость доступа.

• Витрина данных — это такая же реляционная база данных, но спроектированная так, чтобы при выводе данных для анализа и формирования отчетов использовалось как можно меньше операций соединения (join) таблиц. С целью повышения скорости в витринах данных допускается дублирование данных (денормализация).

• Витрины данных обновляются в заданные интервалы времени. Данные периодически копируются из OLTP—систем и заносятся в витрины данных

• В витрине могут объединятся данные сразу нескольких систем.

Особенности организации витрин данных

• Консолидация и очистка. В витрине данных могут быть объединены данные сразу нескольких OLTP—систем. Это позволяет вычислять сложные аналитические меры, но, как уже отмечалось, может привести к ряду проблем.

• В разных OLTP—системах могут использоваться разные способы представления данных.

• Для представления одних и тех же данных могут применяться несовместимые типы данных; для представления одной и той же сущности — разные уникальные идентификаторы, а наличие различных временных и календарных схем может привести к сложностям при объединении данных из разнородных систем.

• Очистка данных (data cleansing) означает удаление несоответствий и ошибок в данных транзакций и делает их пригодными к переносу в витрину данных. В ходе очистки данные переводятся в формат, который не приведет к возникновению проблем в среде витрины данных, а несоответствующие типы данных приводятся к единому типу; различающиеся идентификаторы — к единому набору кодов, используемому в витрине данных. Помимо этого, при очистке производится исправление или удаление данных, не соответствующих бизнес—правилам, применяемым при вычислении мер, заданных для хранилища.

Модели структуры данных ХД

• Логическая модель

• «Многомерный куб» (гиперкуб) dimensional

• Физическая модель

• «Звезда»

• «Снежинка»

Особенности проектирования многомерной модели данных

• Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличаются целями.

• Реляционная модель акцентируется на целостности и эффективности ввода данных.

• Многомерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных аналитических запросов к БД.

Особенности физической модели ХД Денормализация структуры РБД

• Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. В результате, выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что существенно увеличивает время отклика.

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

• Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и ухудшает эффективность выполнения запроса.

Денормализованные, пространственные модели ХД на основе РБД

• Одним из направлений развития РБД для систем принятия решений является разработка таблиц с денормализованной структурой (схемы «звезда» и «снежинка»).

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

Схема данных «Звезда»

• В многмерном моделировании существует стандарт физической модели, называемый схемой звезда (star schema), которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных.

• Невозможно создать универсальную денормализованную структуру данных, обеспечивающую высокую производительность при выполнении любого аналитического запроса.

• Схема звезда строится так, чтобы обеспечить наивысшую производительность при выполнении одного самого важного запроса, либо для группы похожих запросов.

Основные составляющие схемы «звезда»

• Схема звезда обычно содержит одну большую таблицу, называемую таблицей фактов (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней.

• Схема звезда может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности - дочерними.

Схема данных «снежинка»

• Если хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema).

• Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table).

Связи консольных таблиц. «Снежинка»

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

• Консольная таблица не может быть связана таблицей факта. Она используется для нормализации данных в таблицах размерности.

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

• Схема снежинка обычно препятствует эффективности, потому что требует объединения многих таблиц для построения результирующего набора данных, что увеличивает время выполнения запроса. Поэтому при проектировании не следует злоупотреблять созданием множества консольных таблиц.

Таблица(ы) фактов

• Прежде чем создать ХД со схемой типа звезда или снежинка , необходимо проанализировать бизнес-правила предметной области с целью выяснения центрального вопроса, ответ на который наиболее важен.

• Все прочие вопросы должны быть объединены вокруг этого основного вопроса и моделирование должно начинаться с него.

• Данные, необходимые для ответа на этот вопрос, должны быть помещены в центральную таблицу модели - таблицу фактов

Таблица фактов

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

• Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных базах данных.

• Таблица фактов и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей.

Связь таблицы фактов с измерениями

• В многомерной модели направления связей явно не показываются – они определяются типом таблиц.

• Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений.

Таблица фактов

Многомерный куб с несколькими таблицами фактов

Разновидности фактов

• факты, связанные с транзакциями (Transaction facts). основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);

• факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;

• факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

• факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Степень детализации фактов

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

• В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством. Обобщенные данные будут вычислены.

Правила агрегации данных

• В таблице фактов нет никаких указаний о том, как группировать записи при вычислении агрегатных данных.

• Информация о агрегировании присутствует в таблицах измерений куба.

• Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент.

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

Иерархическая структура измерений

Иерархическая структура в ХД

Таблицы измерений

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

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

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

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

Медленно меняющиеся измерения (Slowly Changing Dimensions) в хранилище данных

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

Например, смена организационно-правовой формы собственника может привести к пересмотру стратегии кредитования клиента банка.

Отслеживание изменений значений аналитических измерений в хранилище данных решается путем применения механизма медленно меняющихся измерений (Slowly Changing Dimensions, SCD).

Общий принцип отслеживания изменений

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

Для всех типов медленно меняющихся измерений принцип работы с записями основывается на предварительном определении действия, производимого с записью (вставка, изменение, удаление), и последующей логике обработки записи в зависимости от производимого с ней действия.

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

ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка») — один из основных процессов в управлении хранилищами данных, который включает в себя: извлечение данных из внешних источников; их трансформация и очистка.

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

• На добавление - запись новая и её необходимо добавить в таблицу.

• На изменение – запись существует в таблице, но в каких-то полях изменились содержимое.

• На удаление - запись существует в таблице, но теперь её необходимо удалить из неё.

SCD Type 1

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

Действия, производимые с записями таблицы SCD Type 1 в зависимости от их статуса, представлены в таблице.

Пример отслеживания изменений для случая, когда изменяется содержимое одного из полей записи.

Таблица, в которой хранится информация по клиентским данным (CST), состоящая из 2х полей: ID – первичный ключ записи и NAME – наименование клиента.

В случае изменения существующего наименования «ИП Иванов» на «ООО "Иванов и Ко."» запись в таблице изменится следующим образом:

SCD Type 2

К медленно меняющимся измерениям второго типа относятся те измерения, в которых поддерживается отслеживание изменений данных во времени следующим образом: старая запись помечается как утратившая актуальность, и добавляется новая запись с тем же идентификатором, но уже с обновленными полями.

SCD Type 3

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