Главная » SQL, Базы данных » ОПЕРАТИВНАЯ АНАЛИТИЧЕСКАЯ ОБРАБОТКА

0

Термин оперативная аналитическая обработка (On-Line Analytical Processing— OLAP) впервые был упомянут в докладе, подготовленном для корпорации Arbor Software Corp. в 1993 году [22.11], хотя определение этого термина, как и в случае с хранилищами данных, было сформулировано намного позже. Понятие,  обозначенное этим термином, может быть определено как "интерактивный  процесс создания, сопровождения, анализа данных и выдачи отчетов". Кроме  того, обычно добавляют, что рассматриваемые данные должны восприниматься и обрабатываться таким образом, как если бы они хранились в многомерном массиве. Но прежде чем приступить к обсуждению собственно многомерного представления, рассмотрим соответствующие идеи в терминах традиционных таблиц SQL.

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

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

9   Приведем совет из книги по хранилищам данных [22.24]: "[Откажитесь] от нормализации… По пытки нормализовать любую из таблиц в многомерной базе данных исключительно ради экономии дис кового пространства [именно так!] — напрасная трата времени… Таблицы размерности не должны быть нормализованы… Нормализованные таблицы размерности исключают возможность просмотра".

10   Если только эта таблица результатов не включает какие-либо неопределенные значения, или NULL-значения (см. главу 19, раздел 19.3, подраздел "Дополнительные сведения о предикатах"). На самом деле конструкции SQL: 1999, которые должны быть описаны в данном разделе, можно охаракте ризовать как "основанные на использовании" этого весьма не рекомендуемого средства SQL (?); в дей ствительности, они подчеркивают тот факт, что в своих различных проявлениях неопределенные значе ния могут иметь разный смысл, и поэтому позволяют представить в одной таблице много разных преди катов (как будет показано ниже).

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

1.  Определить общее количество поставок.

2.  Определить общее количество поставок по поставщикам.

3.  Определить общее количество поставок по деталям.

4.  Определить общее количество поставок по поставщикам и деталям.

(Безусловно, "общее" количество для данного поставщика и для данной детали — это просто фактическое количество для данного поставщика и данной детали. Пример был бы более реалистичным, если бы использовалась база данных по ставщиков, деталей и проектов. Но, чтобы не усложнять этот пример, мы все же остановились на обычной базе поставщиков и деталей.)

Теперь предположим, что есть только две детали, с номерами Р1 и Р2, а таблица поставок выглядит следующим образом.

Многомерные базы данных

До сих пор предполагалось, что данные OLAP хранятся в обычной базе данных, использующей язык SQL (не считая того, что иногда мы все же касались терминологии и концепции многомерных баз данных). Фактически мы, не указывая явно, описывали так называемую систему ROLAP (Relational OLAP—  реляционная OLAP). Однако многие считают, что использование системы MOLAP (Multi-dimensional OLAP — многомерная OLAP) — более перспективный путь. В  этом подразделе принципы построения систем MOLAP будут рассмотрены подробнее.

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

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

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

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

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

Примечание. Различие между значениями независимых, или размерных, переменных,

и значениями зависимых, или неразмерных, переменных, иногда характеризуют как различие между местонахождением и содержанием.

" Поэтому ячейки массива адресуются символически, а не с помощью числовых индексов, которые  обычно применяются для работы с массивами.

К сожалению, приведенная выше характеристика многомерных баз данных слишком упрощена, поскольку большинство совокупностей данных изначально остаются не изученными в полной мере. По этой причине мы обычно стремимся, в первую очередь, проанализировать данные, чтобы лучше их понять. Часто недостаточное понимание может быть настолько существенным, что заранее невозможно определить, какие переменные являются независимыми, а какие зависимыми. Тогда независимые переменные выбираются согласно текущему представлению о них (т.е. на основании некоторой гипотезы), после чего проверяется результирующий массив для определения того, насколько удачно выбраны независимые переменные (см. раздел 22.7). Подобный подход приводит к тому, что выполняется множество итераций по принципу проб и ошибок.  Поэтому система обычно допускает замену размерных и неразмерных переменных, и эту операцию называют  сменой  осей  координат  (pivoting).  Другие  поддерживаемые  операции  включают транспозицию массива и переупорядочение размерностей. Должен быть также предусмотрен способ добавления размерностей.

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

(см. главу 19).

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

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

композиции, связывающая детали с комплектом деталей, комплекты деталей с узлом, узлы с модулем, модули с изделием. Часто одни и те же данные могут агрегироваться многими разными способами, т.е. одна и та же независимая переменная может принадлежать ко многим различным иерархиям. Система предоставляет операторы для прохождения вверх (drill up) и прохождения вниз (drill down) по такой иерархии. Прохождение вверх означает переход от нижнего уровня агрегирования к верхнему, а прохождение вниз —

переход в противоположном направлении. Для работы с иерархиями имеются и другие операции, например операция для переупорядочения уровней иерархии.

Примечание. Между операциями прохождения вверх (drill up) и накопления итогов (roll

up) есть одно тонкое различие: операция накопления итогов — это операция реализации

12  Обратите внимание на отличие от реляционных систем. В настоящем реляционном аналоге этого примера в строке Ic, p, t) не было бы пустой "ячейки" количества, в связи с тем, что  строка (с,р, t) просто бы отсутствовала. Поэтому при использовании реляционной модели, в отличие от многомерных массивов, нет необходимости поддерживать "разреженные массивы",  или  скорее "разреженные таблицы", а значит, не требуются искусные методы сжатия для работы с такими таблицами.

требуемых способов группирования и агрегирования, а операция прохождения вверх—это операция доступа к результатам реализации этих способов. А  примером операции прохождения вниз может служить такой запрос: "Итоговое количество поставок известно; получить итоговые данные для каждого отдельного поставщика". Безусловно, для ответа на этот запрос должны быть доступными (или вычислимыми) данные более детализированных уровней.

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

Завершая этот раздел, отметим, что в некоторых продуктах сочетаются оба подхода — ROLAP и MOLAP. Такую гибридную систему OLAP называют HOLAP. Проводятся широкие дискуссии с целью выяснить, какой из этих трех подходов лучше, поэтому стоит и нам попытаться сказать по данному вопросу несколько слов13. В общем случае системы MOLAP обеспечивают более быстрое проведение расчетов, но поддерживают меньшие объемы данных по сравнению с системами ROLAP, т.е. становятся менее эффективными по мере возрастания объемов данных. А системы ROLAP предоставляют более развитые возможности масштабируемости, параллельности и управления по сравнению с аналогичными возможностями систем MOLAP. Кроме того, недавно был дополнен стандарт SQL и в него включены многие статистические и аналитические функции (см. раздел 22.8). Из этого следует, что в настоящее время продукты ROLAP способны к  тому  же предоставлять расширенные функциональные возможности.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии