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

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

21.6. Оперативная аналитическая обработка

Термин оперативная аналитическая обработка (OLAP- online analytical processing) впервые был упомянут в докладе для корпорации Arbor Software Соф. в 1993 году [21.10], хотя концепция, как и в случае с хранилищами данных, появилась значительно позже. Это понятие может быть определено как интерактивный процесс создания, обслуживания и анализа данных и выдачи отчетов . Кроме того, обычно добавляют, что рассматриваемые данные должны восприниматься и обрабатываться так, как будто они сохранены в многомерном массиве . Но, прежде чем приступить к обсуждению непосредственно многомерного представления, давайте рассмотрим соответствующие идеи в терминах традиционных SQL-таблиц.

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

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

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

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

Приведем совет из книги по хранилищам данных: [Откажитесь] от нормализации... Попытки нормализовать любую из таблиц в .многомерной базе данных исключительно ради сохранения дискового пространства - напрасная трата времени.. Таблицы размерности не должны быть нормалюованы... Иормалгаованные таблицы размерности разрушают возможности просмотра [21.21].

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

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

Предположим, что есть только две детали, с номерами Pl и Р2, а таблица поставок выглядит так.

Тогда формулировки на языке SQL для четырех указанных выще запросов и соответствующие результаты их выполнения будут следующими.

Возможно, следовало сказать формулировки на языке nccujxoSQL , поскольку по стандарту SQL/92 не допускается, чтобы операнды предложения GROUP BY были заключены в скобки или чтобы предложение GROUP BY было вовсе без операндов (хотя отсутствие предло.жения GROUP BY логически равносильно предложению GROUP BY без операндов).

Недостатки этого подхода очевидны. Формулирование такого большого количества простых, но отдельных запросов утомительно для пользователя. Выполнение же всех необходимых запросов (их запуск по одним и тем же датам снова и снова), вероятно, будет слишком расточительным по времени. Поэтому стоит попытаться найти какой-то способ, чтобы в одном запросе можно было получить несколько уровней обобщения и таким образом попытаться реализовать возможность вычисления всех этих обобщенных данных более эффективно, т.е. за один проход. Именно этими соображениями руководствовались разработчики, создавая опции GROUPING SETS, ROLLUP и CUBE предложения GROUP BY.

Замечание. Эти опции уже поддерживаются в нескольких коммерческих продуктах. Они также включены в новый стандарт SQL3 (см. приложение Б).

Опция GROUPING SETS позволяет пользователю точно указать, какое именно группирование должно быть выполнено. Например, приведенный ниже SQL-оператор представляет собой сочетание запросов 2 и 3.

SELECT SI, PI, SUM(QTY) AS TOTQTY FROM SP

GROUP BY GROUPING SETS ( (SI), (Pi) ) ;

Здесь с помошью предложения GROUP BY фактически запрашивается выполнение двух запросов, для одного из которых осуществляется группирование по атрибуту SI, а для другого - по атрибуту Р.

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

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

Этот результат действительно можно считать таблицей (во всяком случае, SQL-таблицей), но вряд ли каким-то отношением. Обратите внимание, что строки по поставщикам (они содержат NULL-значения в столбце Pi) и строки по деталям (они содержат

Эта отдельная таблица могла бы рассматриваться как внешнее объединение (следует отметить, крайне странная форма внешнего объединения!) результатов. Должно быть ясно (см. главу 18), что даже в ее наименее странной форме операция внешнего объединения не является приемлемой реляционной операцией.