Модели данных, используемые для хранилищ
Существует два основных подхода к построению хранилищ данных: подход, основанный на многомерной модели баз данных, и подход, использующий реляционную модель баз данных.
При использовании многомерной модели данные хранятся не в виде плоских таблиц, как в реляционных базах данных, а в виде гиперкубов — упорядоченных многомерных массивов. Такое представление является наглядным и позволяет резко уменьшить время поиска в хранилище данных, поскольку отсутствует необходимость многократно соединять таблицы. Среднее время ответа на ложный аналитический запрос при использовании многомерных СУБД обычно в 10—100 раз меньше, чем в случае реляционной СУБД с нормализованной структурой.
Основные понятия многомерной модели — измерение и значение (ячейка). Измерение — это множество, образующее одну из граней гиперкуба (аналог домена в реляционной модели). Измерения играют роль индексов, используемых для идентификации конкретных значений в ячейках гиперкуба. Значения — это подвергаемые анализу количественные или качественные данные, которые находятся в ячейках гиперкуба (рис. 44).
В многомерной модели вводятся следующие основные операции манипулирования измерениями: 1) сечение; 2) вращение; 3) детализация; 4) свертка.
При выполнении операции сечения формируется подмножество гиперкуба, в котором значение одного или более измерений фиксировано. Например, если на рис. 43 зафиксировать значение измерения «Время» равным «январь 1993 года», то получится двухмерная таблица с информацией о значениях всех параметров для всех субъектов РФ в январе 1993 г.
Операция вращения изменяет порядок представления измерений. Она обычно применяется к двухмерным таблицам, обеспечивая представление их в более удобной для восприятия форме. Если в исходной таблице по горизонтали были расположены субъекты РФ, а по вертикали — параметры социально-экономической сферы, то после операции вращения параметры будут размещены по горизонтали, а названия субъектов РФ — по вертикали.
Рис. 44. Представление данных в виде гиперкуба: 1 — значение «Параметра М» для «Субъекта РФ 1» в январе 1993 г.
Для выполнения операций свертки и детализации должна существовать иерархия значений измерения, т. е. некоторая подчиненность одних значений другим. Например, 12 месяцев образуют год, субъекты РФ образуют регионы. При выполнении операции свертки одно из значений измерения заменяется значением более высокого уровня иерархии. Например, аналитик, узнав значения параметров для января 2004 г., желает получить их значения за весь 2004 г. Чтобы это сделать, необходимо выполнить операцию свертки. Операция детализации — это операция, обратная свертке. Она обеспечивает переход от обобщенных к детализированным данным.
Однако у многомерных баз данных имеются серьезные недостатки, сдерживающие их применение. Многомерные СУБД неэффективно по сравнению с реляционными используют память, поскольку заранее резервируется место для всех значений, даже если часть из них заведомо будет отсутствовать. Использование многомерной СУБД целесообразно только в том случае, когда объем базы данных невелик и гиперкуб использует стабильный во времени набор измерений.
Основой при построении хранилища данных может служить и традиционная реляционная модель данных. В этом случае гиперкуб эмулируется СУБД на логическом уровне. В отличие от многомерных реляционные СУБД способны хранить огромные объемы данных, однако они проигрывают по скорости выполнения аналитических запросов.
При использовании реляционных СУБД для организации хранилищ данных данные организуются специальным образом. Чаще всего используется так называемая радиальная схема. Другое ее название — «звезда». В этой схеме используются два типа таблиц: таблица фактов (фактологическая таблица) и несколько справочных таблиц (таблицы измерений).
В таблице фактов обычно содержатся данные, наиболее интенсивно используемые для анализа. Если проводить аналогию с многомерной моделью, то запись фактологической таблицы соответствует ячейке гиперкуба. В справочной таблице перечислены возможные значения одного из измерений гиперкуба. Каждое измерение описывается своей собственной справочной таблицей. Фактологическая таблица индексируется по сложному ключу, скомпонованному из индивидуальных ключей справочных таблиц. Это обеспечивает связь справочных таблиц с фактологической по ключевым атрибутам.
На базе реляционных СУБД строятся системы аналитической обработки данных ROLAP (Relation On-Line Analytical Processing), служащие для связи с системами принятия решений. В таких системах доставкой информации конечному пользователю занимаются системы аналитической обработки данных в реальном времени (On-Line Analytical Processing), которые обеспечивают исключительно простой доступ к данным за счет удобных средств генерации запросов и анализа результатов.
В OLAP-системах ценность информации увеличивается благодаря применению разнообразных методов анализа и статистической обработки. Кроме того, эти системы оптимизированы с точки зрения скорости извлечения данных, сбора обобщенной информации и ориентированы на рядовых пользователей, так как имеют интуитивно понятный интерфейс.
В настоящее время средства анализа данных используют базы данных, составляющие основу OLAP-систем, позволяющие обслуживать сотни и тысячи пользователей; современные программные средства для оперативной аналитической обработки позволяют осуществлять доступ к базе данных OLAP из системы Web или корпоративной сети Intranet.
Ситуация, когда для анализа необходима вся информация, находящаяся в хранилище, возникает довольно редко. Обычно каждый аналитик или аналитический отдел обслуживает одно из направлений деятельности организации, поэтому в первую очередь ему необходимы данные, характеризующие именно это направление. Реальный объем этих данных не превосходит ограничений, присущих многомерным СУБД. Возникает идея выделить данные, которые реально нужны конкретным аналитическим приложениям, в отдельный набор. Такой набор мог бы быть реализован в многомерной базе данных. Источником данных для него должно быть центральное хранилище организации.
Если проводить аналогии с производством и реализацией продукции, то многомерные базы данных играют роль мелких складов. В концепции хранилищ данных их принято именовать киосками данных. Киоск данных — это специализированное тематическое хранилище, обслуживающее одно из направлений деятельности организации. Логическая схема СППР, использующая центральное ХД организации и киоски данных аналитических отделов, представлена на рис. 45.
Такая схема позволяет эффективно использовать возможности реляционных СУБД по хранению огромных объемов информации и способность многомерных СУБД обеспечивать высокую скорость выполнения аналитических запросов.
Системы, использующие хранилище данных, как правило, строятся на основе архитектуры «клиент-сервер». Хранилище данных размещается на специальном сервере (сервере хранилища данных). Для его реализации используется мощные многопроцессорные вычислительные системы таких производителей, как IBM, Hewlett-Packard, DEC, NCR и др.
В качестве СУБД применяется одна из СУБД, поддерживающих параллельную обработку запросов: Teradata (фирма NCR), DB/2 (фирма IBM), Oracle, Informix и др. Киоски данных реализуются с использованием серверов многомерных БД: Essbase (Arbor Software), Oracle Express (Oracle), Gentium (Planning Sciences) и др.
Рис. 45. Логическая схема СППР, использующая ХД и киоски данных