Введение в системы БД (542480), страница 219
Текст из файла (страница 219)
Как мы уже видели в главе 17, оптимизаторы запросов обычно пытаются избежать вычисления декартова произведения [17.541, [17.551. Однако в данном случае формирование, в первую очередь, декартова произведения таблиц значительно меньшей размерности, а затем использование результата для просмотра таблицы фактов очень больших размеров с помощью индексов почти всегда эффективнее любой другой стратегии. Поэтому для эффективной обработки запросов в схеме типа "звезда*' традиционные оптимизаторы нуждаются в переработке. 834 Часть р. дополнительные аспекты У читателя может возникнуть вопрос, в чем же отличие схемы типа "звезда" от схемы, которую можно было считать настоящим реляционным проектом. Действительно, простая схема типа "звезда", подобная рассмотренной выше, может показаться очень похожей на настоящий реляционный проект (и даже идентичной ему).
Однако, к сожалению, в общем случае при использовании схем типа "звезда" возникает целый ряд проблем. 1. Прежде всего, эта схема — произвольная, поскольку она основывается на интуиции, а не на принципах. Из-за недостатка строгости возникают сложности, когда схему требуется надлежащим образом изменить, например, чтобы добавить в базу новые типы данных или изменить зависимости. На практике схемы типа "звезда" часто конструируются посредством простого редактирования предыдущего проекта, а предыдущий проект, в свою очередь, конструировался методом проб и ошибок. 2. Схемы типа "звезда" в действительности физические, а не логические, хотя о них и говорят как о логических.
Проблема заключается в том, что при данном подходе отсутствует концепция логического проектирования, отдельного от физического. 3. Подход с использованием схем типа "звезда" не всегда позволяет получить в результате правильный физический проект (т.е. проект, который сохраняет всю информацию корректного реляционного логического проекта). Этот недостаток становится все более очевидным по мере усложнения схемы. 4. Поскольку отсутствует строгий подход, проектировщики часто включают в одну таблицу фактов несколько различных типов фактов. Вследствие этого строки и столбцы таблицы фактов обычно не имеют единой интерпретации. Более того, определенные столбцы часто применяются только к определенным типам фактов. При этом подразумевается, что рассматриваемые столбцы должны разрешать 1~ИЗ).).-значения.
По мере включения все большего количества типов фактов таблицу становится все сложнее обслуживать и понимать, а доступ становится все менее эффективным, Например, допустим, нужно модифицировать таблицу поставок для отслеживания закупок и поставок деталей. Тогда необходим некоторый столбец с "флажками", указывающими, какие строки относятся к закупкам, а какие к поставкам. В концептуально правильном проекте была бы создана отдельная таблица фактов для каждого типа фактов. 5. Опять же, из-за отсутствия строгости таблицы размерностей могут оказаться неоднородными.
Такая ошибка обычно возникает, когда таблица фактов используется для размещения данных из разных уровней обобщения. Например, мы могли бы (ошибочно) добавить в таблицу поставок строки, содержащие итоговые количества деталей, поставленных за каждый день, каждый месяц, каждый квартал, каждый год и даже сводный текущий итог. Прежде все~о, обратите внимание, что такое изменение приводит к тому, что столбцы идентификатора периода ($ТР) и количества (ОТТ) в таблице ЯР будут иметь не единообразные значения. Предположим теперь, что столбцы ТНОМ и ТО в таблице размерности ТР заменены комбинациями столбцов ТЕлй, МОИТН, Ойу и т.д. Тогда все эти столбцы ТЕАН, ИОИТН, ОАХ и др.
должны будут допускать Х(Ш.- значения. Кроме того, возможно, потребуется также столбец флажка, указывающего тип соответствующего периода времени. Глава 21. Поддержка принятия решений 835 б. Таблицы размерностей часто не полностью нормализованы''. Желание избежать использования операций соединения часто приводит проектировщиков к решению объединить разные данные в одной таблице, хотя лучше было бы сохранять их отдельно. В самом крайнем случае столбцы, к которым лишь иногда осуществляется совместное обращение, также содержатся все вместе в одной и той же таблице размерностей. Должно быть ясно, что следование таким крайностям и отсутствие реляционной строгости почти наверняка приведут к неконтролируемой [а может быть, даже к такой, которую невозможно контролировать) избыточности.
И наконец отметим, что одним из вариантов схемы типа "звезда'* является схема типа "снежинка", которая предусматривает нормализацию таблицы размерности. Название схемы также произошло от ее изображения в виде диаграммы "сущность!связь". Изредка можно услышать термины схема типа "созвездие" и скача типа "метель" с очевидным (?) смыслом. 21.6. Оперативная аналитическая обработка Термин оперативная аналитическая обработка (О).АР— оп1ше апа!уйса1 ргосезз!пя) впервые был упомянут в докладе для корпорации АгЬог Бойхцаге Согр, в 1993 году [21.10), хотя концепция, как и в случае с хранилищами данных, появилась значительно позже. Это понятие может быть определено как "интерактивный процесс создания, обслуживания и анализа ланных и выдачи отчетов'*.
Кроме того, обычно добавляют, что рассматриваемые данные должны восприниматься и обрабатываться так, как будто они сохранены в "многомерном массиве". Но, прежде чем приступить к обсуждению непосредственно многомерного представления, давайте рассмотрим соответствующие идеи в терминах традиционных Я~!.-таблиц. Первая особенность состоит в том, что при аналитической обработке непременно требуется некоторое обобщение данных, обычно выполняемое сразу по многим различным критериям группирования.
В сущности, одной из основных проблем аналитической обработки является то, что количество всевозможных группирований очень скоро становится слишком большим. Тем не менее пользователям необходимо рассмотреть все или почти все группирования. Конечно, сейчас реляционные языки поддерживают такие агрегации, но в результате выполнения каждого отдельного запроса на таком языке возвращается только одна таблица, в которой все строки имеют один и тот же формат и одну и ту же интерпретацию. Поэтому, чтобы получить л различных группирований, необходимо выполнить л отдельных запросов и создать в результате л отдельных таблиц.
Например, рассмотрим последовательность запросов, выполняемых в нашей базе данных поставщиков и деталей. 1. Определить общее количество поставок. 2. Определить общее количество поставок по поставщикам. 3. Определить общее количество поставок по деталям. Н Приведем совет из книги по «ранашига» данныв ТОтказкитесь~ от норхимизации .. Попытки нормализовать любую из таблиц в.»ногомерноя базе данных исключительно ради сохранения дискооого пространства — напраслин трата врвчени.
Табищы размерности не оолжны бьипь нормализованы... Вор чае изованные таблицы разчерноспш разрушают воз»ожноспш просмотра" (гй2зЗ 836 Часть !г дополнительные аспекты 4. Определить общее количество поставок по поставщикам и деталям. Замечание. "Общее" количество для данного поставщика и для данной детали— это, конечно, просто фактическое количество для данного поставщика и данной детали, Пример был бы более реалистичным, если бы использовалась база данных поставщиков, деталей и проектов. Но, чтобы не усложнять его, мы все же остановились на обычной базе поставщиков и деталей. Предположим, что есть только две детали, с номерами 'Р1' и 'Р2', а таблица поставок выглядит так.
БР Тогда формулировки на языке БО(.ы для четырех указанных выше запросов и соответствующие результаты их выполнения будут следующими. 1. ЯЕЕЕСТ Я()М(чеТУ) АЯ ТОТчвТУ 2. БЕЕЕСТ Б№ УКОМ ЯР Я()М(йТУ) АЯ ТОЩТУ ОКО()Р ВУ О: УКОМ БР ОКО()Р ВУ (Б№): 3. БЕЕЕСТ Р№ 4. ЯЕЕЕСТ Я№, Р№ Я()МЯТУ) АЯ ТОТЯТз( Б()МЯТУ) АБ ТОТЯТУ УКОМ БР УКОМ ЯР ОКО()Р ВУ (Р№) ' ОКО()Р Вч( (Б№,Р№) ' Возможно, следовало сказать "езормулировки на языке псевлоВД(.", поскольку по стаи- дарту ВД(.'92 не доп>икается, чтобы операнды предлоги ения ОВООР ВУ были заключены в скобки или чтобы предложение ОВООР ВУ было вовсе бвз операндов (хотя отсутствие предлолсения ОВООР ВУлогичвски равносильно предзожению ОВООР ВУбвз операндов). 837 Глава 21.
Поддержка принятия решений Недостатки этого подхода очевидны. Формулирование такого большого количества простых, но отдельных запросов утомительно для пользователя. Выполнение же всех необходимых запросов (их запуск по одним и тем же датам снова и снова), вероятно, будет слишком расточительным по времени. Поэтому стоит попытаться найти какой-то способ, чтобы в одном запросе можно было получить несколько уровней обобщения и таким образом попытаться реализовать возможность вычисления всех этих обобщенных данных более эффективно, т.е. за один проход.
Именно этими соображениями руководствовались разработчики, создавая опции СВОИХ)чС ЯЕТЯ, ВоййУР и СОВЕ предложения СЕООР ВУ. Замечание. Эти опции уже поддерживаются в нескольких коммерческих продуктах. Они также включены в новый стандарт Я >(.3 (см. приложение Б). Опция СЕООР1МС СЕТЯ позволяет пользователю точно указать, какое именно группирование должно быть выполнено. Например, приведенный ниже ЯО).-оператор представляет собой сочетание запросов 2 и 3. ЯЕЬЕОТ Я(), Р(), ЯОМ(ОТТ] )зЯ ТОТОТТ РВОМ ЯР СЕООР ВУ СВООР1МС СЕТЯ ( (Я()), (Р()) ) ) Здесь с помощью предложения СВООР ВУ фактически запрашивается выполнение двух запросов, для одного из которых осуществляется группирование по атрибуту Я(), а для другого — по атрибуту Р().
Замечание. Внутренние скобки в этом примере на самом деле не требуются, посколь- ку каждое "группируемое множество" включает просто один столбец. Мы показали их для наглядности. Идея объединения нескольких отдельных запросов в один простой оператор указанным способом сама по себе могла бы не вызывать возражений (хотя необходимо все же сказать, что мы бы предпочли, чтобы этот очень общий вопрос был решен более общим, семантическим и независимым способом).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
