Многомерная модель данных, физическая и логическая реализация

Реляционная модель данных, которая была предложена Э.Ф. Коддом в 1970 году, и за которую десятилетие спустя он получил премию Тьюринга, служит основой современной многомиллиардной отрасли баз данных. За последние десять лет сложилась многомерная модель данных, которая используется, когда целью является именно анализ данных, а не выполнение транзакций. Технология многомерных баз данных — ключевой фактор интерактивного анализа больших массивов данных с целью поддержки принятия решения. Подобные базы данных трактуют данные как многомерные кубы, что очень удобно именно для их анализа.

Системы оперативной аналитической обработки (online analytical processing — OLAP) позволяют оперативно получить ответы на запросы, охватывающие большие объемы данных в поисках общих тенденций.

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

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

Многомерные базы данных рассматривают данные как кубы, которые являются обобщением электронных таблиц на любое число измерений. Кроме того, кубы поддерживают иерархию измерений и формул без дублирования их определений. Набор соответствующих кубов составляет многомерную базу данных (или хранилище данных).

Кубами легко управлять, добавляя новые значения измерений. В обычном обиходе этим термином обозначают фигуру с тремя измерениями, однако теоретически куб может иметь любое число измерений. На практике чаще всего кубы данных имеют от 4 до 12 измерений. Современный инструментарий часто сталкивается с нехваткой производительности, когда так называемый гиперкуб имеет свыше 10-15 измерений.

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

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

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

Факты представляют субъект — некий шаблон или событие, которые необходимо проанализировать. В большинстве многомерных моделей данных факты однозначно определяются комбинацией значений измерений; факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. Однако некоторые модели трактуют факты как «объекты первого класса» с особыми свойствами. Большинство многомерных моделей также требуют, чтобы каждому факту соответствовало одно значение на более низком уровне каждого измерения, но в некоторых моделях это не является обязательным требованием.

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

Серверы многомерных баз данных на основе OLAP могут выполнять перечисленные ниже основные аналитические операции.

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

Нисходящий анализ (drill-down). Операция, обратная консолидации, которая включает отображение подробных сведений для рассматриваемых консолидированных данных.

Разбиение с поворотом. Эта операция (которая также называется созданием сводной таблицы) позволяет получить представление данных с разных точек зрения. Например, один срез данных о доходах может отображать все сведения о доходах от продаж объектов недвижимости указанного типа по каждому городу. Другой срез может представлять все данные о доходах отделений компании в каждом из городов. Разбиение с поворотом часто выполняется вдоль оси времени – с целью анализа тенденций и поиска закономерностей.

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

Оптимизируя использование пространства, ОLАР-серверы до минимума сокращают требования, предъявляемые к устройствам физического хранения данных, что, в свою очередь, позволяет эффективно анализировать исключительно большой объем данных. Это также позволяет загружать больше данных непосредственно в оперативную память компьютера, что приводит к существенному повышению производительности за счет сокращения количества выполняемых операций ввода/вывода.

Правил Кодда

В 1993 году Э.Ф. Кодд сформулировал двенадцать основных правил, которым должны удовлетворять ОLAP-инструменты. Публикация этих правил была результатом исследования, проведенного в интересах фирмы Arbor Software (создателей пакета Essbase), и привела к появлению формального определения требований, предъявляемых к OLAP-инструментам. Ниже перечислены упомянутые правила Кодда (Codd et al., 1993).

1. Многомерное концептуальное представление данных.

2. Прозрачность.

3. Доступность.

4. Неизменная производительность подготовки отчетов.

5. Архитектура клиент/сервер.

6. Универсальность измерений.

7. Динамическое управление разреженностью матриц.

8. Многопользовательская поддержка.

9. Неограниченные перекрестные операции между размерностями.

10. Поддержка интуитивно понятного манипулирования данными.

11. Гибкость средств формирования отчетов.

12. Неограниченное число измерений и уровней обобщения.

Случайные записи:

4. Логическая и физическая структура данных СУБД Oracle


Похожие статьи:

  • Модели серверов баз данных

    Терминология УБД Пользователь БД — это программа или человек, обращающиеся к БД на языке манипулирования данными. Запрос — это процесс обращения…

  • Модели представления данных

    Основные типы данных, основные определения. Модели представления данных. Данные Данные- некоторые упорядоченные сведения о знаниях. В ИС знания хранятся…

  • Введите понятие растровой модели пространственных данных

    Определение. Растровая модель данных – это цифровое представление пространственных объектов в виде совокупности ячеек растра (пикселов) с присвоенными им…

Добавьте постоянную ссылку в закладки. Вы можете следить за комментариями через RSS-ленту этой статьи.
Комментарии и трекбеки сейчас закрыты.