Концепции построения и реализации информационных систем

Концепция Витрин Данных имеет ряд несомненных  достоинств:

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

И именно Витрины  Данных (или что то очень близкое  к ним), имел в виду Э.Кодд, когда  использовал термин “OLAP Server”.

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

Идея соединить  две концепции - Хранилищ Данных и  Витрин Данных, по видимому, принадлежит  М.Демаресту (M.Demarest), который, в 1994 году, в работе “Построение Витрин Данных” /6/, предложил объединить две концепции  и использовать Хранилище Данных в качестве единого интегрированного источника данных для Витрин Данных.

И сегодня именно такое многоуровневое решение:

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

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

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

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

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

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

Заключение

В заключение хотелось бы остановиться на двух моментах. Во первых, не следует искать в концепции Хранилищ Данных что-то совершенно принципиально новое, о чём не говорилось и не писалось ранее и чему нельзя найти аналогий в прошлом. Её реальное значение состоит в том, что Концепция Хранилищ Данных, составляет: “часть ответа со стороны информационных технологий на вопрос: “Что мы делаем дальше?”. И подобно многим новациям в технологиях, этот термин используется для того, чтобы описать обезоруживающую по своей простоте концепцию, которая имеет потенциал развиться со временем во что-то более сложное и значительное ” /7/. И как было показано выше, уже сегодня можно говорить о том, что появление этой концепции послужило серьёзным стимулом для развития внутренней архитектуры современных СУБД, их программного окружения, инструментальных средств конечного пользователя, различных межкорпоративных стандартов.

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

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

Литература

1. “What is Data Warehouse” W.H. Inmon

2. “Data Warehouse Issues”  Butler Group Co., UK

3. “Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate” E.F.Codd, S.B.Codd, C.T. Salley, E.F.Codd & Associates, 1993

4. “Принципы  проектирования и использования  многомерных баз данных (на примере Oracle Express Server) ” А.А.Сахаров, СУБД, №3, 1996

5. “Битовые массивы ускоряют  обработку запросов к информационным  хранилищам” Herb Edelstein, Компьютеруик, 28 (234) 1996

6. “Building The Data Mart” Marc Demarest, DBMS July 1994 v7 n8 p44(7)

7. “Data Warehousing” Butler Group Co., UK