второй уровень - БД уровня подразделения (или конечного пользователя), реализуемые на основе МСУБД (агрегированные данные);

третий уровень - рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;

Именно оно постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:

- компактного хранения детализированных данных и поддержки очень больших БД, обеспечиваемых РСУБД;

- простота настройки и хорошие времена отклика при работе с агрегированными данными, обеспечиваемыми МСУБД.

Далее рассматривается выбор модели и структуры Хранилища Данных. Дается понятие подхода к поиску и выборке данных, называемого Оперативной Аналитической Обработкой (On-line Analytical Processing, OLAP). В зависимости от того в каком виде данные хранятся на физическом уровне описываются системы ROLAP, HOLAP, MOLAP.

В третьей главе рассматриваются вопросы проектирования ХД. Здесь предложена технология проектирования Хранилищ Данных. Описана технологическая цепочка создания ХД. Разработана модель ХД для страховой компании с распределенной внутренней структурой. На основе данных

САО «Росгосстрах-Татарстан» построена витрина данных для получения информации о поступлении взносов. С помощью клиентского приложения продемонстрированы возможности использования данных при такой их организации. Результаты тестов приведены в приложении.

1 глава. Обзор технологии Хранилищ Данных, подходов и имеющихся решений.

1.1 Информационные системы.

В области информационных технологий всегда существовали два взаимодополняющих друг друга направления развития (рис.1):

- системы, ориентированные на операционную обработку данных - системы обработки данных (СОД);

системы, ориентированные на анализ данных - системы поддержки принятия решений (СППР).

Рисунок 1. Направления развития информационных систем

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

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

Рассмотрим причины кризиса оперативного анализа. Ниже представлены лишь основные из них.

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

Информация рассредоточена между несколькими системами. Указанный факт имеет несколько аспектов:

- Разные источники данных

- Разные форматы данных

- Разные механизмы доступа к данным

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

- Несколько независимых средств генерации отчетов.

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

Существует несколько путей преодоления кризиса. Один из них –создание шлюзов между отдельными системами. Это, однако, приводит лишь к объединению нескольких OLTP систем в одну и никак не решает проблему высокой детализации данных.

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

Для удовлетворения этим требованиям в начале 90-х годов и возникла концепция Хранилищ Данных.

Рисунок 2. Архитектура СППР на основе Хранилища Данных.

1.2 Концепция Хранилищ Данных.

Хранилище Данных (Data Warehouse) – предпредметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки управления.

1.2.1 Основные идеи концепции ХД

В основе концепции Хранилищ Данных лежат две основополагающие идеи:

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

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

Цель концепции ХД – прояснить отличия в характеристиках данных в операционных и аналитических системах (таблица 1), определить требования к данным (таблица 2), помещаемым в целевую БД Хранилища Данных, определить общие принципы и этапы ее построения.

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

Характеристика	Операционные	Аналитические
Частота обновления	Высокая частота, маленькими порциями	Малая частота, большими порциями
Источники данных	В основном, внутренние	В основном, внешние
Объемы хранимых данных	Сотни мегабайт, гигабайты	Гигабайты и терабайты
Возраст данных	Текущие (за период от нескольких месяцев до одного года)	Текущие и исторические (за период в несколько лет, десятки лет)
Назначение	Фиксация, оперативный поиск и преобразование данных	Хранение детализированных и агрегированных исторических данных, аналитическая обработка, прогнозирование и моделирование

Таблица 1. Сравнение характеристик данных в информационных системах,

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

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

Таблица 2. Основные требования к данным в Хранилище Данных.

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

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

Концепция Хранилищ Данных - это не концепция анализа данных, скорее, это концепция подготовки данных для анализа.

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

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

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

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

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

Технология хранилищ данных (стр. 2 из 11)