характерную для звездообразной схемы простоту этого запроса; здесь выполняются только простые односторонние эквисоединения таблиц измерений с таблицей фактов. Таблицы измерений не соединяются друг с другом - это признак хорошего проектирования хранилища.

SELECT SUM(sis.quantity)

, sis.month

, per.name

FROM sales sis

, salespeople per

WHERE sales.per id = per. id

AND sales.year = 1997

AND sales.month BETWEEN 6 AND 7

AND sales.prd id = 33

AND per.sales office id = 6 GROUP BY sis.month, per.name;

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

Развертывание измерений

Хотя приведенный выше запрос прост, он несколько похож на шифр. Например, не ясно, что представляет собой товар с идентификатором 33. Эту проблему можно решить, если выполнить соединение с измерением Products (товары) и указать вместо идентификатора наименование товара. Однако задать отдел сбыта по наименованию, а не по идентификатору нельзя, поскольку измерения Sales Office (отдел сбыта) нет. Существует несколько вариантов выхода из этой ситуации:

1. Включить в таблицу SALESPEOPLE и идентификатор, и наименование отдела сбыта.

2. Создать новое измерение и назвать его Sales Office.

3. Создать таблицу развертывания измерения.

Варианты 1 и 2 особых пояснен не требуют. Если запросы этого типа встречаются часто, то рекомендуется создать для отдела сбыта отдельное измерение. Давайте исследуем третий вариант - развертывание измерения. Этот метод заключается в том, что мы нарушаем классическую звездообразную структуру и создаем таблицу развертывания измерения, которая связана с данной таблицей измерения (рис. 13.7).

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

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

Salespeople

NAME

SALES OFFICEJD

PHONE WORK

PHONE HOIVIE

PHONE MOBILE

BONUS SHEME ID

BONUS SHEME TYPE

SalesOffices ID

NAME

TOWN

STATE

COUNTRY

PHONE

DISTRICT ID

Puc 13.7. Ввод таблицы развертывания измерения

Секционирование

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

Рис. 13.8. Горизонтальное и вертикальное секционирование

Большинство таблиц фактов в хранилище имеет источник данных, подверженный интенсивным транзакциям. В примере на рис. 13.5 и 13.6 таблицей фактов является таблица продаж. Надеемся, что каждый день через наши отделы сбыта будет идти мощный поток новых продаж! Эти новые продажи нужно периодически заносить в хранилище данных. (Ниже в этой главе мы рассмотрим механизмы занесения новых данных.) Предположим, что у нас

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

Очень скоро она станет очень большой, что затруднит ее администрирование и управление.

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

Если не создать специальную утилиту очистки и не запускать ее перио-дщ1ески, то отделить и выбросить данные, которые устарели и утратили свою актуальность, будет сложно.

Чтобы решить эти проблемы, мы можем секционировать таблицу фактов на более мелкие таблицы. В примере будет не одна таблица с именем SALES для всех данных о продажах, а по одной таблице для каждого дня - SALES 010]97, SALES 010297, SALES 010397 и т.д. Каждая таблица будет содержать сводные данные о продажах по семи региональным отделам сбыта за соответствующий день. Можно секционировать таблицу и по регионам (SALES NORTH, SALES MIDWEST и т.д.), но в данном случае это не имеет смысла, потому что такой подход не решит все описанные в нашем списке проблемы. В большинстве случаев очевидным кандидатом на роль ключа секции является временное измерение.

Выбирая отличительный столбец для секции, вы обнаружите, ггo лучше всего использовать ключ, который позволяет облегчить загрузку данных. По этой причине столбец Data Processed ( Дата обработки ) или столбец Data Created ( Дата создания ), как правило, лучше подходят на эту роль, чем столбец Data Applicable ( Дата применения ), потому что они более естественно вписываются в процесс циклической загрузки. В этом случае можно будет ввести в систему заказ, фактически принятый от покупателя на прошлой неделе, или же будущие либо повторяющиеся заказы. Когда дело доходит до извлечения данных для загрузки в хранилище, то нельзя гарантировать, что все данные для секции будут получены за один раз, если секция основана на дате заказа, однако это можно гарантировать, если секция основана на дате обработки заказа.

Мы продемонстрировали положительное влияние, которое секционирование оказывает на процесс загрузки. Теперь давайте посмотрим, как оно влияет на запросы данных. На первый взгляд, при этом должны существовать проблемы. Чтобы запросить или обобщить данные за январь 1997 года, нужно объединить 31 таблицу: SALES 010197, SALES 010297,... SALES 010397. Естественно, такое объединение будет трудным для программирования и неэффективным в работе. С его громоздкостью можно справиться, если определить представления, в которых и будут осуществляться большие объединения таблиц (при этом обязательно нужно применять операцию UNION ALL, а не UNION).