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

      2.1.2 МСУБД

      Более просто и эффективно аналитические  системы реализуются средствами специализированных баз данных, основанных на многомерном представлении данных. В этих системах данные организованы не в виде плоских таблиц (как в реляционных системах), а в виде упорядоченных многомерных массивов - гиперкубов (или поликубов).

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

      Казалось  бы, все очевидно и выбор однозначен - многомерные БД. Однако не все так  просто. Многомерные базы, в силу чисто исторических причин, "не умеют" работать с большими объемами данных. На сегодняшний день их реальный предел - база объемом в 10-20 гигабайт. И хотя данное ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С чем нельзя не считаться.

      К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, в лучшем случае, эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда [3], для систем, основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. И здесь необходимо остановиться на основном недостатке многомерных БД - неэффективному, по сравнению с реляционными БД, использованию внешней памяти. И это уже объективный фактор.

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

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

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

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

      Таким образом, МСУБД однозначно хороши только при выполнении двух требований.

      Уровень агрегации данных в БД достаточно высок, и, соответственно, объем БД не очень велик (не более нескольких гигабайт).

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

      К сожалению, сегодня отсутствуют  официальные сравнительные результаты тестирования производительности систем, реализованных на основе многомерных и реляционных баз данных (некоторые дополнительные аргументы в пользу того и другого подхода приведены в таблице 7), но при этом общая оценка такова: "Производительность хорошо настроенных реляционных систем, при использовании схемы звезда, вполне сравнима с производительностью систем, реализованных на основе многомерных баз данных".

Таблица 7. Дополнительные аргументы в пользу МСУБД и РСУБД. 

      2.2 Витрины Данных

      Концепция Витрин Данных (Data Mart) была предложена Forrester Research еще в 1991 году. По мысли  авторов, Витрины Данных - множество  тематических БД, содержащих информацию, относящуюся к отдельным аспектам деятельности организации, должны были стать реальной альтернативой Информационным Хранилищам (Information Warehouse) фирмы IBM.

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

      Аналитики видят и работают только с теми данными, которые им реально нужны.

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

      Витрины Данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и  настраивать.

      Для реализации Витрин Данных не требуются высокомощная вычислительная техника.

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

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

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

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

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

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

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

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

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

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

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

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

2.3. Выбор  структуры Хранилища Данных 

      До  выбора структуры, необходимо определиться с моделью данных. В самом простом варианте для Хранилищ Данных используется та модель данных, которая лежит в основе транзакционной системы. Если, как это часто бывает, транзакционная система функционирует на реляционной СУБД (Oracle, Informix, Sybase и т. п.), самой сложной задачей становится выполнение запросов ad-hoc, поскольку невозможно заранее оптимизировать структуру БД так, чтобы все запросы работали эффективно.

      Однако  практика принятия решений показала, что существует зависимость между  частотой запросов и степенью агрегированности данных, с которыми запросы оперируют, а именно чем более агрегированными являются данные, тем чаще запрос выполняется. Другими словами, круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это наблюдение легло в основу подхода к поиску и выборке данных, называемого Оперативной Аналитической Обработкой (On-line Analytical Processing, OLAP).

      OLAP-системы  построены на двух базовых  принципах: 

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

      язык  манипулирования данными основан  на использовании бизнес-понятий.

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