 |
Информационные хранилища данных.
|
|
|
|
За последние годы предприятия накопили огромное количество информации с помощью приложений, которые заносят информацию о параметрах бизнес-процессов в базы данных и в корпоративных архивах документов. Если эту информацию никак не систематизировать, не представить в едином формате, ее невозможно использовать для анализа деятельности предприятия с целью принятия стратегических решений. Однако именно такие задачи возникают перед руководителями предприятий. Поэтому в начале 90-х годов Билл Инмон предложил концепцию Хранилищ данных. Он предложил разделить всю информацию корпорации на две категории [5]:
- оперативно меняющаяся информация, сосредоточенная в оперативных базах данных и ориентированная на бизнес-процессы;
- выверенная, неизменяемая информация, интегрированная из различных источников, предназначенная для анализа информации.
Было предложено следующее определение:
Информационное хранилище – это предметно-ориентированный, интегрированный, неизменяемый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.
Из этого определения следуют основные свойства, которыми должно обладать Информационное хранилище:
- Предметная ориентированность. Модель данных Хранилища ориентирована на предметную область. Все направления деятельности компании разбиваются на предметные области, которые подлежат анализу. В результате, информация из различных источников, связанная с определенной предметной областью, собирается в одном месте. При этом данные согласовываются, очищаются, агрегируются. Такая их предварительная обработка упрощает задачу анализа информации и позволяет использовать большое количество данных.
|
|
|
- Интегрированность. Данные поступают в хранилище из различных файловых систем и оперативных баз данных, которые используют разные форматы хранения информации. Одни и те же характеристики объекта в разных базах могут иметь разное наименование. Интеграция объектов позволяет при помещении данных в хранилище использовать единый формат хранения информации, одинаковые наименования характеристик, одинаковые единицы измерения.
- Неизменчивость. Предварительно обработанные и помещенные в Хранилище данные могут использоваться только для чтения. Внесение в них изменений запрещено. Администратор хранилища по расписанию (ежедневно, еженедельно, ежемесячно) добавляет новые данные в Хранилище, но ранее добавленные остаются неизменными. При этом, точно известны источники их получения. Это приводит к повышению достоверности данных.
- Поддержка хронологии. Важнейшее свойство, которое позволяет не только выполнять хронологический анализ данных, но и прогнозировать развитие бизнеса. Здесь важно хранение в хронологическом порядке именно агрегированных показателей (например, объемов продаж за квартал). В Хранилище помещаются «снимки» состояния предметной области на какой-то момент времени. Процедура повторяется в соответствии с расписанием добавления информации в Хранилище. В результате менеджеры соответствующих направлений могут видеть хронологию изменения интересующих их параметров.
Рассмотрим структуру хранения информации в Хранилище. В таких базах информация располагается как бы в многомерном кубе («куб памяти»). Результаты бизнес-процессов являются фактами, которые характеризуются параметрами – мерами.
Например, факт продажи характеризуется мерами: полученная от продажи сумма, объем проданного товара. Факты зависят от измерений: квартала, артикула товара, города (рис.7). Расположение информации в такой структуре напоминает расположение в электронной таблице (например, Excel). Если сделать, например, такие таблицы для каждого города (рис.7) и собрать их месте, тогда каждая такая таблица будет показывать динамику продаж в отдельно взятом городе в зависимости от квартала и артикула товара. Можно сделать «срезы» куба по кварталам или артикулам товара. Измерения могут быть организованы в иерархическую структуру [8] (рис.8). Это позволяет реализовывать более сложные запросы к базе. Информация об иерархии измерений хранится в области метаданных [5] (рис.6).
|
|
|
Рис.7 – Пример куба данных по мерам Квартал, Артикул, Город.
Такая структура хранения данных позволяет реализовать следующие типы запросов к базе:
- Средства реализации запросов для многомерных баз данных позволяют делать «срезы» информации для менеджеров разных направления.
Можно выбрать «срез» только для одного города, для одного артикула товара, для одного квартала. Возможен и одновременные показ трех и более размерностей, но это уже OLAP-технология.
- наличие иерархии измерения [4] (рис.8) позволяет реализовать запрос, указывая только одну из мер.
Например, можно указать страну или только год. При этом данные, соответствующие разным городам одной страны или разным кварталам одного года, агрегируются.
- Запросы из нескольких кубов, имеющих одинаковые измерения.
 | |||
| |||
 | |||||
| |||||
| |||||
Рис.8 – Иерархия измерений.
При увеличении объемов хранимой информации время реализации запроса становится недопустимо большим. Для устранения этого недостатка используются так называемые «предвычисления». Поскольку чаще всего в отчетах используются агрегированные данные, заранее создается куб таких данных. При дополнении куба детальных данных новой информацией куб агрегированных показателей автоматически пересчитывается.
Для нашего примера может быть создан куб, где объемы продаж суммируются для каждого года и каждой страны. К нему и будут обращены наиболее частные запросы.
Как видим, многомерная модель хранения информации позволяет быстро реализовывать запросы, однако большие трудности вызывает изменение параметров куба. Поэтому часто для организации хранения информации в Хранилище используется реляционный подход.
|
|
|
В этом случае информация о фактах и измерениях хранится в отдельных плоских таблицах, связанных с помощью ключевых полей. Простейшая схема организации связей называется «звезда» [4] (рис.9). Эта же схема часто используется для хранения информации в витринах данных. Схема проектируется с учетом построения будущих аналитических запросов.
 |
Рис.9 – Схема организации связи при реляционном подходе.
Для избежание дублирования информации и увеличения скорости реализации запросов используется иерархия размерностей, например, так как показано на рис.10.
|
|
 |
|
| |||||
 |
| ||||
Рис.10 – Иерархия размерности.
При использовании такой иерархии приходим к схеме типа «снежинка» (рис.11) [4], которая и помогает избежать дублирования информации. Характеристики повторяющихся данных хранятся в отдельных таблицах (например, регион) и связаны ключами с верхними уровнями иерархии размерностей.
Часто в Хранилищах используются все описанные выше технологии хранения информации. Схемы типа «звезда» и «снежинка» применяются для хранения детализированных данных, а многомерные базы применяются для хранения агрегированных данных (например, объемов продаж за месяц, реализованных в определенном регионе или стране).
 |
Рис.11 – Иерархия типа «снежинка».
|
|
|
