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

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

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

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

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

Звездообразная схема: пример

На рис. 13.5 показана звездообразная схема системы сбыта продукции. Таблица фактов (SALES) в данном случае обобщает данные по месяцу (MONTH, время), товару (PRODUCT, вещь), продавцу (SALESPERSON, лицо) и покупателю (CUSTOMER, лицо). Прежде всего рассчитаем количество строк в нащей таблице данных за год (12 месяцев). Предположим, что у нас 100 покупателей, пять продавцов и три товара. Максимально возможное количество строк будет равно произведению всех этих чисел (100 x5x3x 12 = 45000). Однако вряд ли все нащи продавцы каждый месяц продают все товары каждому покупателю, поэтому в действительности размер таблицы будет гораздо меньще. Таким образом, размер таблицы фактов в данном случае равен значению декартового произведения измерений минус число неприемлемых комбинаций. Если бы все строки были заполнены, то многие проектировщики выбрали бы вариант, при котором для всех маловероятных случаев хранилась бы запись с нулевым объемом продажи.

Таблица 1 . iiifli1T!?nfl , Таблица

Salespeople Г

Таблица Products

Рис. 13 5. Звездообразная схема системы сбыта продукции

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

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

позволяет анализировать данные по годам, не выполняя соединение с таблицей месяцев.

2. Некоторые таблицы измерений содержат элементы, которые в традиционной модели были бы реализованы при помощи внешних ключей к другим таблицам. К примеру, в таблице продавцов имеются поля ВО-NUS SCHEME ID и SALES OFFICE ID. Поскольку система премий и отдел сбыта не считаются измерениями таблицы фактов SALES (по крайней мере в этой интерпретации), как отдельные таблицы они не создаются. Все необходимые подробности можно включить в таблицу измерения, к которой они относятся. Так, таблица SALESPEOPLE в нашем случае содержит информацию о типе системы премий. Наличие избыточных и ненормализованных данньгх типично для таблиц измерений.

Customers

NAME

TELEPHONE CONTACT TEL CONTACT FAX ADDRESS

PARENT COMPANTJD PARENT COM PANT NAME

PrOi

Sales

12 I

NAME I

UNIT PRICE 1

TYPE I

Months

YEAR MONTH

REPORTING REF

nM YEAR TIM MONTH QUANTITY NET VALUE DISCOUNT

Salespeople

NAME

SALES OFFICE (D

PHONE WORK

PHONE HOME

PHONEMOBILE

BONUS SHEME ID

BONUS SHEME TYPE

Puc. 13.6. Определения таблиц для реализации звездообразной схемы сбыта продукции

В типичном запросе к звездообразной схеме указываются детальные сведения о точках этой схемы (измерение), а затем данные, соответствующие этим точкам, обобщаются. Как правило, производится несколько таких итераций с целью выявления тенденций изменения данных. Для этого можно несколько измерений держать постоянными, а другие изменять либо соединять таблицу фактов с другими таблицами, чтобы увидеть корреляцию между таблицей фактов и измерениями, не указанными в условии запроса. Этот прием, который часто называют детализацией данных (drill-down), поддерживается многими ОЕАР-средствами просмотра данных. Приведенное ниже предложение SELECT демонстрирует типичный запрос к звездообразной схеме. Изменяя данные о регионе, месяце или товаре, при помощи запроса этого типа можно выявить тенденции в данных. Обратите внимание на