4.3.2. Хранилища данных (DataWarehouse)

4.3.2.1. Причины появления концепции ХД

Для реализации задач ПР, данные в информационном фонде СППР должны быть организованы способом, отличным от принятого в OLTP-системах. Это связано со следующими причинами:

1. Выполнение аналитических запросов всегда сопряжено с обработкой больших информационных массивов. Чем выше степень нормализации таблиц, тем медленнее выполняется анализ в связи с увеличением числа операций соединения таблиц. В OLTP-системах нормализация таблиц позволяет устранить избыточность данных и уменьшить объем действий, выполняемых при обновлении данных. В OLAP-системах обновление данных производится крайне редко, превалируют операции дополнения и чтения, поэтому необходимость нормализации значительно меньше.

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

4.3.2.2. Определение ХД

Определение ХД принадлежит Биллу Инмону, техническому директору компании "Prism Solutions":

ХД – предметно-ориентированная, интегрированная, некорректируемая, зависимая от времени коллекция данных, предназначенная для ПР. Согласно Инмону, ХД должна выступать в роли «единого и единственного источника истины». Детализация свойств, указанных в этом определении Инмоном, приведена в таблице 8.

Таблица 8 – Основные свойства ХД
Предметная ориентированность	В ХД должна быть заложена модель предметной области, соответствующая модели оператора (аналитика, менеджера) и удобная для выполнения его задач (бизнес-анализа).
Интегрированность	Все данные о некотором предмете (бизнес-объекте): Собираются из множества различных источников (различных БД и разнородных приложений). Очищаются и дополняются. Согласовываются: синтаксически – приводятся к единому формату; семантически – осуществляется контроль целостности. Агрегируются (группируются, в первую очередь, хронологически – при бизнес-анализе, как правило, оперируют данными за месяц, квартал, год). Сохраняются в едином, удобном для OLAP формате.
Неизменчивость (неизменяемость)	После внесения в хранилище данные остаются неизменными.
Поддержка хронологии	В большинстве случаев наличие атрибута "Дата/Время" обязательно. Желательно физическое упорядочивание данных по хронологии. Использование СППР ориентированно на отражение в ХД истории, достаточной для выполнения задач бизнес-анализа и прогнозирования.

4.3.2.3. Реализация ХД. Метаданные

Основными вопросами (проблемами) реализации ХД, определяющими требования к ней, являются:

• неоднородность программной среды;

• распределенность;

• защита данных от несанкционированного доступа (НСД);

• построение и ведение многоуровневых справочников метаданных;

• эффективное хранение и обработка очень больших объемов данных.

Неоднородность

Основа ХД – не внутренние, как в большинстве традиционных СОД, а внешние источники данных: различные информационные системы, электронные архивы, справочники и каталоги. Типичной является ситуация функционирования множество несвязанных или слабо связанных СОД, созданных в различное время, различными коллективами разработчиков на основе различных программных и аппаратных средств. И все эти СОД являются источниками данных для одной ХД. Практически всегда задача построения ХД – это задача построения единой, согласованно функционирующей, информационной системы на основе неоднородных программных средств и решений.

Распределенность

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

Метаданные

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

Метаданные – высокоуровневые средства отражения информационной модели СППР.

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

1. Описания не только целевых структур данных в БД Хранилища, но и структур данных в источниках их получения.

2. Правила, процедуры и периодичность их выборки и выгрузки.

3. Процедуры и места согласования и агрегации.

4. Периодичности обновления данных.

5. Статистические оценки продолжительности выполнения запроса.

Наличие многоуровневого всестороннего описания данных позволяет реализовать требование нерегламентированности запросов к ХД.

Таблица 9 – Уровни метаданных в ХД
Уровень приложения (внешних источников данных)	Описывает структуру данных в операционных БД и других источниках данных. Обычно, этот уровень достаточно сложен для понимания неподготовленного пользователя и является приложение-ориентированным
Уровень ядра ХД	Описывает логическую и физическую структуру и взаимосвязи данных в ХД.
Уровень конечного пользователя	Описывает структуры данных в ХД в терминах предметной области конечного пользователя.

Разработка системы управления метаданными включает в себя:

• анализ процессов возникновения, изменения и использования метаданных;

• проектирование структуры хранения метаданных;

• организация прав доступа к метаданным;

• блокировка и разрешение конфликтов при совместном использовании метаданных;

• разделение метаданных между Витринами Данных;

• согласование метаданных ХД с Репозиториями CASE-средств, применяемых при проектировании и разработке Хранилищ;

• реализация пользовательского интерфейса с Репозитарием.

Причины традиционной недооценки роли словаря метаданных вытекают из преобладающего опыта работы всех категорий специалистов с СОД, а не с СППР:

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

2. Администраторов БД, как правило, интересует не семантика данных, а способы их физического представления и организации.

3. Наличие метаданных является необходимым условием успешной реализации любой СОД, и потому разработчики являются наиболее нуждающейся в наличии метаданных категорией специалистов. И именно при разработке (модернизации) СОД эта информация формируется и активно используется. Препятствиями дальнейшего использования этой информации являются:

   1. ориентация ее на процессы разработки, а не использования системы;

   2. незаинтересованность разработчиков традиционных СОД в предоставлении пользователю словаря метаданных;

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

Наиболее известны Репозитарии, входящие в состав CASE-средств, систем разработки и поддержки информационных систем: Sybase Power Designer / Power Builder, Oracle Designer / Developer и др.

Существует ряд стандартов обмена метаданными, обеспечивающих возможность интеграции средств разных производителей. Абсолютное большинство из них основано на XML. Например: MDIS, ISO 19115, SDMX, XMI, RDF.

Защита данных

Для защиты используются, в первую очередь, стандартные средства и методы:

• идентификация пользователей;

• шифрование передаваемых данных и паролей и т.д.

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

Большие объемы данных

Для ХД принята следующая классификация объемов хранимых данных (таблица 10). При этом необходимо учитывать, что объем хранимых данных требует в 5-10 раз больше дискового пространства, за счет его затрат на индексы, буферы и т.д. (таблица 11).

Таблица 10 – Классификация объемов хранимых данных
Маленькое Хранилище Данных	До 3 Гбайт	До нескольких миллионов строк в одной таблице
Среднее Хранилище Данных	До 25 Гбайт	До ста миллионов строк в одной таблице
Большое Хранилище Данных	До 200 Гбайт	До нескольких сотен миллионов строк в одной таблице
Очень Большое Хранилище Данных	Свыше 200 Гбайт	Сотни миллионов или миллиарды строк в одной таблице

Таблица 11 – Соотношение между реальным объемом исходных данных и размером дискового массива
СУБД	Аппаратная платформа	Объем исходных данных (Гбайт)	Объем дискового массива (Гбайт)	Коэффициент
DB2	RS/6000 System 403	300	2,815.1	9.4
DB2	RS/6000 SP2 302	100	492.4	4.93
Teradata	NCR 5100M 5 Node System	100	420.0	4.2
NonStop SQL/MP	Tandem NonStop Himalaya K20000-16	100	285.2	2.86
Oracle7	HP 9000 Enterprise Parallel Server Model EPS30	100	643.6	6.44
Oracle7	Sun Ultra Enterprise 6000	100	594.0	5.94
DB2 for NT	IBM PS 360 S200	1	8.8	8.8

Наиболее популярными являются следующие РСУБД: Teradata (NCR), DB2 (IBM), Oracle, Informix; и МСУБД: Essbase (Arbor Software), Oracle Express (Oracle), Gentium (Planning Sciences).

4.3.2.4. Модели данных в ХД

Основным параметром эффективности и для OLTP-, и для OLAP-систем является производительность. Для OLTP она определяется максимальной интенсивностью транзакций, для OLAP – скоростью выполнения операций выборки. Как правило, наиболее естественным для СППР является многомерное представление данных. Например, описание социально-экономической ситуации в стране может быть представлено в виде куба, на одном из ребер которого будут откладываться моменты времени, на другом – регионы (штаты, федеральные субъекты), на третьем – наименования параметров. Значения в ячейках куба будут представлять собой значения параметров ситуации в определенные моменты времени в определенных регионах.

Термины "агрегирование" ("агрегация"), "консолидация" и "детализация" имеют непосредственное отношение ко всей тематике СППР и впрямую связаны с многомерным представлением и анализом данных. Термины "консолидация" и "агрегация" практически эквивалентны. Термин "консолидация" является более общим, термин "агрегация" употребляется преимущественно по отношению к уровням обобщения. Каждое измерение может включать направления консолидации данных, например, измерение "исполнитель" может иметь одно направление консолидации и четыре уровня: предприятие - подразделение - отдел - служащий. Высшим является уровень, характеризующийся большей степенью агрегации данных, т.е. "предприятие". Измерение "время" может иметь два независимых направления консолидации: год - квартал - месяц - день и неделя - день. Движение от высших уровней агрегации к низшим называется спуском (drilling down), от низших уровней к высшим – подъем (rolling up).

Операции манипуляции измерениями:

1. Сечение. Результатом является подмножество гиперкуба, в котором значение одного или более измерений фиксировано.

2. Вращение. Результатом является гиперкуб с измененным порядком представления измерений.

3. Свертка. Соответствует подъему по направлению консолидации.

4. Детализация. Операция, обратная свертке.

5. Проекция. Суммирование по некоторому закону значений в ячейках, лежащих на оси проекции гиперкуба.

ХД строиться на базе РСУБД и МСУБД. При этом в рамках каждой из этих моделей данных реализуется гиперкуб.

4.3.2.5. МСУБД

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

Недостатки МСУБД:

1. Высокие требования к дисковому пространству. Коэффициент отношения используемого пространства к его полезному объему – 2.5-100 (для сравнения: для РСУБД – 5-10).

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

Достоинства МСУБД:

1. (Основное). Среднее время ответа на запрос меньше в 10-100 раз, чем у РСУБД.

2. Невысокие (по сравнению с РСУБД) требования к качеству разработки структуры БД с целью достижения высокой производительности.

3. Отсутствие ограничений языка SQL.

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

4.3.2.6. РСУБД

Недостатки РСУБД:

1. Громоздкость аналитических запросов.

2. Необходимость заранее знать все возможные типы запросов для оптимизации структуры таблиц и минимизации времени ответа. Требование, противоречащее общим требованиям к OLAP-системам.

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

Основные направления преодоления недостатков РСУБД:

1) Денормализация таблиц.

Вместо нескольких реляционно связанных нормализованных таблиц создают одну денормализованную, называемую фактологической. Кроме нее создают несколько связанных с ней справочных таблиц (таблиц измерений), как правило, небольших. Запись фактологической таблицы соответствует ячейке гиперкуба. Каждое измерение гиперкуба описывается своей справочной таблицей, каждая запись которой соответствует одному значению измерения. Такая организация данных называется радиальной (или схемой "звезда" – "star").

Модификацией схемы "звезда" является схема "снежинка" ("snowflake"). В ней атрибуты справочных таблиц могут быть детализированы в дополнительных справочных таблицах. Таким образом, от схемы «звезда» «снежинку» отличает большая степень нормализации.

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

Один из наиболее широко распространенных способов оптимизации запросов к схеме "звезда" предполагает построение промежуточной таблицы, являющейся декартовым произведением используемых в запросе справочных таблиц. И только затем выполняется последовательный просмотр двух таблиц (фактологической и промежуточной). В случае большого количества справочных таблиц такое решение может только, наоборот, увеличить время обработки или вообще сделать выполнение запроса невозможным. Число записей промежуточной таблицы равно , т.е. произведению длин таблиц измерений. Практический эффект получается только в случае, если промежуточная таблица может быть размещена в ОЗУ.

2) Реализация новых способов индексации. Например, Bitmap-индексы позволяют производить считывание блоками записей. Теряют эффективность при малом (единицы) и при большом (более нескольких сотен) числе различных значений в индексируемом поле. Снижают производительность системы при выполнении операций обновления данных.

3) Горизонтальное разбиение. Одна большая фактологическая таблица может быть представлена совокупностью нескольких небольших идентичной структуры. Разбиение может быть произведено, например, по временным интервалам. Подтаблицы могут обрабатываться отдельно, в селектирующих запросах - объединяться.

При применении этого метода необходимо учитывать, что он эффективен только для некоторого фиксированного класса запросов, зависящего от выбранного критерия разбиения (поля, в соответствии со значением которого производится разбиение).

4) Вертикальная фрагментация. Метод основан на допущении, подтверждаемом опытом, что в СППР часто анализу подвергаются не все сразу поля фактологической таблицы, а по отдельности. Если разбить фактологическую таблицу на совокупность таблиц аналогичной (одинаковой) длины, каждая из которых представляет собой один столбец исходной, то сервер для обработки запроса должен будет перекачать существенно меньше информации.

Недостатки:

• эффективность прямо пропорциональна отношению числа колонок в таблице к числу запрашиваемых колонок;

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

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

Достоинства РСУБД:

1. Высокий уровень защиты и разграничений доступа.

2. Развитые средства администрирования и апробированность для работы с большими БД.

3. Наличие (в отличие от МСУБД) единых стандартов.

4. Поддержка механизмов репликации.

4.3.2.7. Витрины данных (киоски данных)

Витрины данных (Data Mart) – тематические БД, содержащие информацию, относящуюся к различным аспектам деятельности предприятия.

Основные три этапа развития концепции:

1. Концепция была предложена компанией Forrester Research в 1991 г. Основная ее идея: витрины данных содержат тематические подмножества агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное ХД, и, следовательно, требующие менее производительной техники для поддержания.

2. В 1994 году М. Демарест предложил объединить две концепции и использовать ХД в качестве единого интегрированного источника для многочисленных витрин данных. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру:

   1. общекорпоративное централизованное ХД;

   2. тематические витрины данных на уровне подразделений;

   3. рабочие места конечных пользователей.

3. Наличие двух уровней корпоративного хранения данных позволяет основывать их на различных моделях данных. Весьма эффективным считается сейчас использование РСУБД для реализации ХД и использование МСУБД для витрин данных, т.к. небольшой объем витрин данных позволяет снизить отрицательный эффект от недостатков МСУБД и обеспечить высокую скорость обработки аналитических запросов.

Преимущества использования витрин данных:

1. Физическое разделение данных между группами аналитиков.

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

   1. изученность (как правило) и простота бизнес-процессов в пределах одного подразделения;

   2. небольшое количество пользователей (не более 10-15 человек).

Несколько фирм предлагает системы построения Витрин Данных: Informatica (PowerMart Suite), Sagent Technology (Data Mart Solution) и Oracle (DataMart Suite). Для иллюстрации процесса разработки Витрины Данных можно рассмотреть вкратце состав и функциональность пакета DataMart Suite.

Пакет включает пять основных компонентов: Data Mart Designer, Data Mart Builder, Oracle7 Enterprise Server, Web Server и Discoverer 3.0. Data Mart Designer позволяет описывать структуру Витрины и запоминать ее в Репозитарии. На выходе Data Mart Designer порождает описание на языке DDL SQL, которое затем подается на вход Oracle7 Enterprise Server. В результате создается структура базы данных, реализующая Витрину Данных. В ходе построения Витрины пользователь может применять существующие описания структур или строить Витрину "с нуля". Кроме того, Data Mart Designer позволяет строить приложения для Oracle Web Server на базе PL/SQL.

Data Mart Builder извлекает данные из внешних источников и заполняет Витрину. Он обладает наглядным специализированным интерфейсом, отображающим потоки данных при заполнении Хранилища. Data Mart Builder способен извлекать данные из реляционных СУБД и CSV-файлов. Web Server предоставляет открытую платформу для разработки Web-приложений. Он включает Web Request Broker (WRB), реализованный на основе технологии картриджей и позволяющий разрабатывать Web-приложения, встраиваемые в Web Server. В качестве средств разработки могут использоваться Java, PL/SQL, LiveHTML, C и C++. Discoverer 3.0 - это средство конечного пользователя, позволяющее генерировать отчеты, а также выполнять некоторые OLAP-операции с Витриной Данных. Отчеты, построенные с помощью Discoverer 3.0, можно экспортировать в формате HTML, делая их доступными для Web-браузеров. Discoverer 3.0 также позволяет создавать и поддерживать таблицы агрегированных данных. Помимо этого, DataMart Suite включает готовое приложение, называемое Sales Analyzer.

4.3.2.8. Этапы разработки и внедрения ХД

1. Бизнес-анализ процессов и данных предприятия, построение их модели. Разработчики ХД обязаны представлять:

   1. цели бизнеса,

   2. способы их достижения,

   3. проблемы их достижения,

   4. методы их решения.

Основное назначение модели предприятия – определение и формализация данных, необходимых в процессе принятия решения. Два подхода к бизнес-анализу:

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

• анализ бизнес-событий.

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

• позволяет гибко модифицировать бизнес-процессы, ставя их в зависимость от бизнес-событий;

• интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных;

• объединяет управляющие и информационные потоки;

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

Иными словами, бизнес-событие является более устойчивым и более тесно связанным с информационными и управляющими потоками понятием, чем бизнес-процесс.

2. Анализ данных, используемых предприятием:

   1. внешние данные и их источники;

   2. форматы данных, периодичность и форма их поступления;

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

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

Модель представления данных является организационно-функциональным срезом модели системы, а при ее разработке последовательно изучаются:

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

• доступ к данным: объем данных, необходимый для анализа, уровень агрегированности данных, источники данных (внешние или внутренние), описание информации, совместно используемой различными функциональными группами предприятия;

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

В случае СППР на основе ХД нормальным считается итерационный, а иногда и параллельный, характер моделирования.

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

4.3.2.9. Этапы заполнения (загрузки) ХД

I. Сбор данных (Data Acquisition).

Сбор Данных – процесс, который состоит в передаче данных из внешних источников в Хранилище. Лишь некоторые аспекты этого процесса полностью или частично автоматизированы в имеющихся продуктах. Первый из них – использование интерфейсов с существующими СУБД:

1. Интерфейсы серверов баз данных (Oracle, Informix, ADABAS и т. д.).

2. ODBC-интерфейс.

3. Средства обработки текстовых файлов в формате CSV (comma separated values).

4. Средства обработки структурированных файлов, например файлов dBase.

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

II. Очистка данных (Data Cleansing).

Очистка данных – процесс модификации данных по ходу заполнения ХД:

• исключение нежелательных дубликатов,

• восстановление пропущенных данных,

• приведение данных к единому формату,

• удаление нежелательных символов (например, управляющих),

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

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

III. Агрегирование Данных (Data Consolidation).

1. Выборка данных производится в соответствии с метаданными, т.к. агрегирование производится в терминах бизнес-понятий.

2. Агрегирование производится в соответствии с правилами агрегирования – правилами вычисления составных бизнес-понятий, исходя из простых.