- •Хранение информации
- •Системы оперативной обработки информации
- •Обобщенная структура системы oltp
- •Системы поддержки принятия решений
- •Хранилища данных
- •Обобщенная концептуальная схема хд детализированные и агрегированные данные
- •Метаданные
- •Управление жизненным циклом информации
- •Фиксированный контент
- •Извлечение данных (etl)
- •Обобщенная структура процесса etl Архитектуры хранилищ данных
- •Шесть уровней архитектуры хранилища данных
- •Консолидация с использованием витрин данных
- •Реляционные хранилища данных
- •Многомерные хранилища данных
- •Гибридные хранилища данных
- •Гибридное хд
- •Анализ данных введение в olap
- •Эволюция понимания места olap в архитектуре
- •Принцип организации многомерного куба
- •Измерения и факты в многомерном кубе
- •Сечения гиперкуба
- •Двумерный срез куба для одного факта
- •Двумерный срез куба для нескольких фактов
- •Двумерный срез куба с несколькими измерениями на одной оси
Многомерные хранилища данных
Основное назначение многомерных хранилищ данных (МХД) — поддержка систем, ориентированных на аналитическую обработку данных, поскольку такие хранилища лучше справляются с выполнением сложных нерегламентированных запросов.
Сущность многомерного представления данных состоит в следующем. Большинство реальных бизнес-процессов описывается множеством показателей, свойств, атрибутов и т.д. Например, для описания процесса продаж могут понадобиться сведения о наименованиях товаров или их групп, о поставщике и покупателе, о городе, где производились продажи, а также о ценах, количествах проданных товаров и общих суммах. Кроме того, для отслеживания процесса во времени должен быть введен в рассмотрение такой атрибут, как дата. Если собрать всю эту информацию в таблицу, то она окажется сложной для визуального анализа и осмысления. Более того, она может оказаться избыточной (аномалии РБД). Все это способно окончательно запутать любого, кто попытается извлечь из такой таблицы полезную информацию с целью анализа текущего состояния продаж и поиска путей оптимизации процесса торговли. Указанные проблемы возникают по одной простой причине: в плоской таблице хранятся многомерные данные.
Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например Дата, Товар, Покупатель. По осям будут откладываться значения измерений — даты, наименования товаров, названия фирм-покупателей, ФИО физических лиц и т.д.
В такой системе каждому набору значений измерений (например, «дата — товар — покупатель») будет соответствовать ячейка, в которой можно разместить числовые показатели (то есть факты), связанные с данным набором. Таким образом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь.
Преимущества многомерного подхода.
Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД.
Возможности построения аналитических запросов к системе более широки.
В некоторых случаях использование многомерной модели позволяет значительно уменьшить продолжительность поиска, обеспечивая выполнение аналитических запросов практически в режиме реального времени. Это связано с тем, что агрегированные данные вычисляются предварительно и хранятся в многомерных кубах вместе с детализированными, поэтому тратить время на вычисление агрегатов при выполнении запроса уже не нужно.
Недостатки.
Для ее реализации требуется больший объем памяти. (объем данных, который может поддерживаться МХД, обычно не превышает нескольких десятков гигабайт).
Многомерная структура труднее поддается модификации; при необходимости встроить еще одно измерение требуется выполнить физическую перестройку всего многомерного куба.
Таким образом, применение МХД целесообразно только в тех случаях, когда объем используемых данных сравнительно невелик, а сама многомерная модель имеет стабильный набор измерений.
Достаточно очевидно, что даже при небольших объемах данных отчет, представленный в виде двухмерной таблицы (Модели компьютеров по оси Y и Время по оси X), нагляднее и информативнее отчета с реляционной построчной формой организации.
Реляционная модель представления данных |
Многомерная модель представления данных | ||||||
Модель |
Месяц |
Объем |
|
Июнь |
Июль |
Август | |
Celeron |
Июнь |
12 |
"Celeron" |
12 |
24 |
5 | |
Celeron |
Июль |
24 |
"Pentium" |
2 |
18 |
- | |
Celeron |
Август |
5 |
"Athlon" |
- |
19 |
- | |
Pentium |
Июнь |
2 |
|
|
|
| |
Pentium |
Июль |
18 |
|
|
|
| |
Athlon |
Июль |
19 |
|
|
|
|
Но в любом магазине имеется не три модели товара, а значительно больше (например, 30), и анализ проводится не за три, а за 12 месяцев. В случае построчного (реляционного) представления будет получен отчет в 360 строк (30х12).