• Почему хранилища данных?
• Что такое хранилище данных?
• Многомерные и пространственные модели
• Что отличает хранилище данных?
• Проблемы проектирования
• Достижения Oracle в технологии хранилищ данных
• Не забывайте об осторожности
• Вопросы проектирования для хранилищ данных
• Многомерное моделирование и звездообразные схемы
• Факты и измерения
• Звездообразная схема: пример
• Развертывание измерений
• Секционирование
• Правила агрегирования
• Объединение таблиц фактов
• Извлечение и загрузка данных
• Этап 1: Чтение данных
• Этап 2: Фильтрация данных
• Этап 3: Предотвращение потерь ретроспективных данных
• Этап 4: Обработка данных
• Этап 5: Перемещение данных
• Этап 6: Загрузка данных в хранилище
• Этап 7: Сортировка отклоненных записей
• Этап 8: Создание агрегированных значений
• Этап 9: Верификация
• Метаданные
• Типы и методы трансформации данных
• Закодированные значения
• Флаги в многоязычных системах
• Манипулирование числовыми данными
• Манипулирование датами
• Преобразование и слияние ключей
• Выборка данных путем исследования и с помощью OLAP-инструментов

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

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

Отсутствие интегрированных и непротиворечивых данных — не единственная проблема, стоящая перед пользователями и руководителями. Многие системы, которые проектировались с использованием традиционных методов и приемов, недостаточно хорошо оптимизированы для выполнения запросов к данным. В частности, нерегламентированные запросы, возможность появления которых не учтена при проектировании, могут выполняться плохо или не выполняться вовсе. Так, на обработку предложений GROUP BY, обобщающих данные, может потребоваться масса процессорного времени и большое число обращений к дискам. Современным руководителям необходимы системы, которые помогут им принимать стратегические решения. Им нужна возможность просмотра данных под самыми разными углами и во множестве измерений. Для достижения этой цели требуется не просто умный инструмент для запросов — нужны данные в формате, который оптимизирован под конкретную задачу.

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

Хранилище данных — прекрасный способ решения проблем, описанных в предыдущем разделе. Можно считать, что хранилище данных расположено в центре всех ориентированных на приложения систем организации. Хранилище регулярно получает данные из этих систем и формирует сводное представление. Данные могут быть простой копией транзакционных данных (в этом случае их называют атомарными) или же подвергаться на пути от источника к пункту назначения (хранилищу) трансформации либо агрегированию. При этом в хранилище может помещаться только какое-то их подмножество, или же данные могут подвергаться конвертированию для того, чтобы обеспечить их совместимость с данными из других источников. Для обозначения процесса отсечения и извлечения данных обычно используются термины расслоение (slicing) и расщепление (dicing). Внутренняя структура хранилища данных построена так, чтобы запросы можно было легко создавать и эффективно выполнять. О том, как это достигается, мы поговорим ниже.

Выше мы говорили о необходимости наличия мощных инструментальных средств, при помощи которых пользователи, не сведущие в языке SQL, смогут создавать запросы и выполнять многомерный анализ данных (главным образом анализ возможных ситуаций). Должна быть обеспечена возможность постановки таких, например, запросов: "Как изменится объем продаж, если наш главный конкурент уйдет с рынка?" Для формирования таких прогнозов и содействия пользователям в поиске в базе данных с последующей детализацией разработано новое поколение инструментальных средств, ориентированных на конечных пользователей и известных как средства оперативной аналитической обработки данных (OLAP-средства). Однако следует знать, что OLAP-средства Oracle, входящие в версии 7.3 в состав Universal Server, не используют механизм реляционной базы данных Oracle напрямую. (См. дополнительную информацию в заключительном разделе этой главы.)

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

Загрузочная секция на рис. 13.1 представляет собой логический объект, при помощи которого обозначено место, где входящие данные содержатся в необработанном формате до передачи их в хранилище. Данные загрузочной секции физически могут храниться отдельно как двумерные ASCII-файлы или в базе данных в виде временных промежуточных таблиц, которые могут быть снимками или реплицированными из других источников таблицами. Данные загрузочной секции могут храниться даже во внутреннем формате системы, обеспечивающей пересылку данных. Пока данные находятся в загрузочной секции, для анализа они не доступны, поскольку еще не попали в хранилище.

Рис. 13.1. Типичная конфигурация хранилища данных

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

В версии 7.3 Oracle успешно реализовала ряд расширений своей реляционной базы данных с тем, чтобы при использовании Oracle Spatial Data Option система непосредственно поддерживала пространственные запросы. К сожалению, многие сотрудники Oracle (включая даже некоторых специалистов по маркетингу!), кажется, не могут разобраться в различиях между многомерной поддержкой (обращением к данным по нескольким внешним ключам) и пространственной поддержкой (обращением к данным по координатам). В этой главе рассматривается проблема многомерных данных; данные, конечно, могут иметь и пространственные свойства, но это уже другая тема.

Единственный эффективный путь решения этой задачи состоит в следующем. Необходимо разделить двумерное пространство на некоторое (большое) число блоков, имеющих размер, например, 500 на 500 метров. Для каждой нефтяной скважины придется хранить данные о блоке, в котором она расположена. Условие запроса можно преобразовать в список уточняющих блоков, который будет служить основой индексного доступа. Каждая нефтяная скважина, находящаяся в уточняющем блоке, проверяется на предмет того, располагается ли она в пространстве, описанном в условии запроса. (Эта схема изображена на рис. 13.2.)

Риc. 13.2. Переход от двух измерений к одному

Условие

WHERE x BETWEEN 3.8 AND 5.3 AND у BETWEEN 2.2 AND 5.3;

К сожалению, список уточняющих блоков для некоторых запросов может быть очень длинным, поэтому в Oracle Spatial Data Option используется иерархический подход. Oracle Spatial Data Option — умная штуковина, и вам почти наверняка придется ее купить, если вы столкнулись с проблемой пространственных данных. (Но к теме нашей главы это не относится).

Хранилища данных не возникли за один день, а развились из систем поддержки принятия решений (СППР — DSS) и информационных систем руководителей (ИСР— EIS). Эти системы традиционно работали с данными, которые были идентичны данным, в той операционной системе, где сопровождались эти данные; такие системы обращались либо к "живым" данным, либо к их последней неизменяемой копии. Хранилища данных не обязательно берут непосредственные копии рабочих данных из ООТ-систем. Их таблицы строятся на рабочих данных, но, как правило, включают только те детали, которые касаются процесса принятия решений. Принадлежащие вашей организации данные, конечно, представляют интерес, но если их объединить с общими данными о рынке, в том числе о ваших конкурентах, то такая информация приобретает совершенно новое значение. Источниками данных для хранилища могут являться маркетинговые агентства, а также различного рода сервисные системы, например система агентства Рейтер.

Почему же хранилища данных приобрели такую популярность, какую выгоду они дают и как оправдать расходы на их создание и поддержку? Для принятия стратегических решений обязательно нужно иметь доступ к представлению рабочих данных корпорации, а в некоторых случаях — и к данным всего рынка. Чтобы составить, полную картину состояния бизнеса, пользователи должны иметь возможность "пересекать" границы подразделений, а также иметь в своем распоряжении внешние данные, например сведения о конкурентах. В такой среде архивные данные так же важны, как и текущие, следовательно, сопровождать нужно и те, и другие. Сводная информация о бизнесе вместе с интеллектуальными средствами анализа данных, позволяющими выполнять нерегламентированные запросы, дает нам в руки мощный инструмент для принятия решений. Например, по данным, находящимся в хранилище, специалист по маркетингу может выполнить анализ тенденций и выявить на рынке потенциальный дефицит, который можно будет затем устранить.

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

Итак, вы, должно быть, уже поняли, что реализовать хранилище данных — это не значит просто пойти и купить какие-то инструменты для запросов. Необходима серьезная работа по определению объема и проектированию хранилища, без проведения которой даже нельзя думать о том, какие инструменты лучше всего подходят для запросов к данным. Если рассматриваемый проект хранилища данных — первый для вас или вашей организации, рекомендуем сначала ограничиться небольшим объемом. Если вы при первой попытке будете нацелены на разработку общекорпоративного решения, то ситуация сложится явно не в вашу пользу. Поэтому лучше сконцентрироваться на узкой, четко ограниченной области бизнеса, для которой можно выполнить поставленную задачу в разумные сроки и которая характеризуется небольшим объемом данных, поддающихся управлению. Решив эту задачу, можно начинать завоевывать мир!

Oracle осваивала технологию хранилищ данных на удивление медленно. В начале 90-х годов, когда покупатели ее СУБД уже начали реализовывать у себя хранилища данных, Oracle несколько запаздывала с обеспечением прямой поддержки этой технологии. Когда стало ясно, что компания отстает от таких поставщиков, как Redbrick, она выступила с рядом инициатив, целью которых было догнать и перегнать конкурентов. Среди этих мероприятий было приобретение у фирмы IRI Software OLAP-продукта PC Express (который сейчас известен как Oracle Express). Кроме того, Oracle призвала третьи фирмы к объединению усилий и создала организацию Warehouse Technology Initiative (WITI). Сейчас у компании свыше 30 партнеров в данной области.

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

В версии 7.1 появились дополнения, обеспечивающие как обработку запросов данных, так и прием данных в хранилищах. Использование Parallel Query Option в многопроцессорной среде позволяет задействовать при больших и сложных запросах несколько процессоров. В этой версии также имеются средства параллельной загрузки данных и параллельного построения индексов. SQL*Loader допускает ускоренный прием данных. Несколько сеансов SQL*Loader могут одновременно загружать данные в одну таблицу с помощью механизма прямой загрузки, что позволяет сэкономить много времени.

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

Появление версии 7.2 сопровождалось заявлениями о двукратном повышении производительности при создании индексов и при выполнении сложных запросов некоторых типов. Создание индексов происходит лучше за счет того, что система обходит буферный пул, т.е. по команде CREATE INDEX запись осуществляется непосредственно в блоки базы данных. Усовершенствования в методе выполнения предложения CREATE TABLE...AS SELECT... также позволяют параллельно выполнять операции вставки и запроса. Это выгодно при создании таблиц итоговых данных.

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

Звездообразная модель состоит из центральной таблицы фактов (fact table), которая окружена несколькими таблицами измерений (dimension table) (рис. 13.3). Физически таблица фактов часто представляет собой несколько секционированных таблиц. (О секционировании мы поговорим ниже.)

Рис. 13.3. Звездообразная схема

Отношения между таблицей фактов и таблицами измерений должны быть простыми, чтобы существовал только один возможный путь соединения любых двух таблиц и чтобы смысл этого соединения был очевиден и хорошо понятен. Всегда необходимо помнить о том, что мы разрабатываем эту систему для того, чтобы пользователи могли определять свои собственные запросы. Ориентированные на конечного пользователя средства нерегламентированных запросов не прижились в традиционной реляционной базе данных. Даже если столбцам этой базы дать информативные имена, проблема не исчезнет: отношения внутри модели данных останутся сложными, а число этих отношений — большим. Здесь мы имеем в виду, что, как правило, существует более одного способа соединения двух таблиц. Иногда в запросе должны быть использованы таблицы, не имеющие отношения к данному бизнесу, потому что они содержат ссылки на другие нужные для запроса таблицы. (Некоторые программные продукты, например HP Intelligent Warehouse и Business Objects, решают эту проблему с помощью преобразующего слоя.) Еще одно преимущество простоты отношений состоит в том, что это помогает повысить производительность.

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

Что можно сказать о таблицах измерений? В широком смысле слова — это элементы, которые могут оказывать определенное влияние или порождать различные тенденции в развитии наших фактов. Исходя из этого измерения можно разбить на следующие категории: люди, места, вещи и время (рис. 13.4).

Рис. 13.4. Классификация измерений: люди, места, вещи и время

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

1. Для соединения с таблицей измерения с целью выбрать описательную информацию об этом измерении.

2. Как правило, они являются основой для выполнения обобщений в таблице фактов. Например, мы можем суммировать содержащиеся в таблице фактов количественные показатели, которые относятся к конкретному покупателю. Если имя покупателя является частью утверждения о факте, то такое суммирование можно выполнить без последующего соединения с какой-либо другой таблицей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы решить эти проблемы, мы можем секционировать таблицу фактов на более мелкие таблицы. В примере будет не одна таблица с именем SALES для всех данных о продажах, а по одной таблице для каждого дня — SALES_010197, SALES_010297, SALES_010397 и т.д. Каждая таблица будет содержать сводные данные о продажах по семи региональным отделам сбыта за соответствующий день. Можно секционировать таблицу и по регионам (SALES_NORTH, SALES_MIDWEST и т.д.), но в данном случае это не имеет смысла, потому что такой подход не решит все описанные в нашем списке проблемы. В большинстве случаев очевидным кандидатом на роль ключа секции является временное измерение.

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

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

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

Помимо этого, версия 7.3 может с помощью гистограмм значений столбцов определять, в каких секциях производить поиск по индексу, а в каких — путем полного сканирования таблицы. Это позволяет устранить упомянутый выше серьезный недостаток, связанный с включением "лишних" секций, и вынуждает генераторы запросов предыдущего поколения выполнять эту оптимизацию в процессе генерации запросов, а не перекладывать ее на плечи оптимизатора запросов. В версиях до 7.2 секционирование все равно дает те преимущества, которые мы обсуждали в главе 10, посвященной архивации. Тем не менее, мы не советуем пытаться выполнять соединение с представлением, содержащим UNION ALL; лучше взять генератор запросов, который создает полный запрос по каждой секции и формирует объединение UNION ALL полученных результатов.

Возможно секционирование и более чем по одному атрибуту (SALES_NORTH_0197, SALES_NORTH_0297, SALES_SOUTH_0197 и т.д.) Однако этот метод уводит нас в сторону от идеи упрощения структуры и порождает сложности при комбинировании таблиц.

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

Давайте сначала посмотрим, когда следует агрегировать данные, потому чтo это относительно простой вопрос. Лучше всего это делать на этапе перехода из загрузочной секции в хранилище. Следующий удобный (и более привычный) метод — загрузить данные в таблицу фактов и выполнять агрегирование там. Существует и другой вариант — одновременно с созданием загрузочного файла атомарных данных создать загрузочный файл обобщенных данных. Однако он имеет ряд недостатков:

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

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

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

Определившись с тем, какие данные нужны, необходимо решить, как и в каком формате мы будем их "вытягивать". Наиболее распространенным форматом до сих пор является двумерный файл. Двумерные файлы бывают двух типов: с записями фиксированной длины и с записями переменной длины (см. главу 8). Как правило, есть большой выбор инструментов для создания таких файлов. Например, если данные находятся в ООТ-системе Огас1е7, то можно использовать SQL*Plus, 3GL с прекомпилятором или Oracle Reports. Существует и целый ряд средств для создания двумерных файлов от третьих фирм. Наш опыт показывает, что самый лучший вариант — 3GL, но это и самый дорогостоящий путь. Конечно, можно попробовать написать программу извлечения на PL/SQL, но может случиться, что по ряду причин (в первую очередь из-за производительности) об этом придется пожалеть. Во многих простых ситуациях — особенно при отсутствии длинных текстовых полей — для извлечения столбцов трудно придумать что-нибудь лучшее, чем следующий подход с использованием SQL*Plus:

Если требуется выравнивать и ограничивать потенциально длинные поля, мы не рекомендуем использовать для этих операций SQL — 3GL-средства делают эту работу гораздо лучше.

Существует ряд альтернатив двумерным файлам, которые заслуживают внимания. Например, используя средства работы с распределенными базами данных, имеющиеся в SQL*Net и некоторых продуктах Oracle категории Gateway, можно читать данные из системы промышленного уровня и осуществлять их запись непосредственно в таблицы другой системы. В большинстве случаев помещать данные прямо в хранилище данных нельзя, потому что при этом будут пропущены некоторые описанные ниже этапы. Вставлять данные следует в загрузочную секцию.

Необходимо определить, какие данные изменились с момента последнего извлечения. Если вам очень повезет, то в исходной базе данных будут столбцы DATE_CHANGED и DATE_CREATED и, извлекая данные, вы сможете построить фильтр на базе этих столбцов. Однако даже это не поможет выявить записи, удаленные с момента последней загрузки, если только вам не исключительно повезет и в системе не будет выполняться логическое удаление, при котором создается столбец DATE_DELETED.

Если такой роскоши, как этот столбец, у вас нет, единственный способ определить, что изменилось, — сравнить полный дамп данных с предыдущим. Это можно осуществить путем сортировки файлов по ключам и построчного сравнения. Есть инструменты, которые специально рассчитаны на выполнение этой задачи. Если же вы предпочитаете работать по принципу "сделай сам", то неоценимую помощь вам окажет Unix-команда diff.

Как мы уже говорили, одно из различий между хранилищем данных и традиционной прикладной системой состоит в том, что в хранилище данных, как правило, важно обеспечить поддержку полной ретроспективной картины. Тот факт, что наименование товара когда-то изменилось с Marathon на Snickers, для систем сбыта и ввода заказов практически незаметен. Однако для хранилища данных он имеет колоссальное значение, поскольку изменение фабричной марки может оказать существенное влияние на сбыт и долю рынка — а это как раз то, что мы надеемся узнать при помощи хранилища данных. Давайте предположим, что наименование — просто атрибут в приложениях, обслуживающих сбыт и ввод заказов, а ключом товара является числовой код. При внесении изменения в значение важного атрибута рабочих данных важно не просто переписать эту запись в таблице измерения хранилища данных, а создать ее производную.

Формат данных, поступающих из механизмов подачи действующих систем, наверняка будет не тем, который необходим для хранилища, где структуры данных очень денормализованы. Таблицы фактов могут быть довольно близки к требуемой форме, но таблицы измерений, вероятно, потребуют дополнительной обработки и, возможно, объединения. Например, в нашем примере с таблицей продаж (SALES) атрибут Sales Office не создается как отдельное измерение, а содержится в измерении Sales Person. На этом этапе также может выполняться обобщение и агрегирование данных. Тем не менее, как мы уже упоминали, это лучше оставить до момента появления в хранилище новых данных.

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

Наконец, данные переходят из загрузочной секции непосредственно в хранилище и становятся доступными. Если данные не подлежат "загрузке вразброс" (т.е. когда данные из одной исходной записи направляются в несколько таблиц), то SQL*Loader — почти наверняка самый лучший вариант. Как мы уже говорили, новые возможности параллельной работы SQL*Loader должны обеспечить достаточно эффективную загрузку, особенно когда используется прямая загрузка, позволяющая практически обойтись без дополнительных расходов, связанных с вставкой данных в таблицу Oracle. (Возможности SQL*Loader рассматриваются в главе 8.)

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

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

Если в хранилище данных используется промежуточное программное обеспечение (middleware), то вам обязательно потребуются метаданные, или метамодель. Метаданные — это данные, описывающие другие данные. Если говорить о проектировании хранилища данных, то это — набор структур данных, которые описывают данные, находящиеся в хранилище, и идентифицируют их источники. Они содержат логику преобразования и трансформации и могут описывать или именовать процессы, выполняющие эту трансформацию и интеграцию (см. рис. 13.9). Метаданные могут также содержать преобразующий уровень для средства создания нерегламентированных запросов или отчетов, используемого для исследования данных. Они могут описывать данные терминами, понятными конечному пользователю, и скрывают все сложности в основных структурах базы данных. Метаданные содержат подробные сведения о том, как пользователь секционировал свои таблицы фактов и какие агрегированные данные имеются для каждой из этих таблиц. С помощью этой информации интеллектуальный инструмент запроса или процессор промежуточного ПО может принимать осмысленные решения о том, как лучше построить эффективный запрос на основании критериев поиска, заданных пользователем. Качественно сопровождаемая метамодель — неоценимый инструмент, даже если не используется промежуточное ПО, которое требует ее наличия.

Рис. 13.9. Важная роль метаданных

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

В этом ключе скрыта очень полезная информация. Мы называем эту информацию скрытой, потому что по ней трудно построить условие запроса. Конечно, можно использовать стандартные метасимволы Oracle и искать все строки, совпадающие с последовательностью "_SW%", чтобы найти все полисы на Юго-Западе, но это очень мудреный и крайне неэффективный способ. Тем не менее, в некоторых старых унаследованных системах, из которых вы будете брать данные, вам может встретиться очень много таких структур и с ними придется что-то делать.

Многие хранилища данных обеспечивают глобальное представление рынка. В организациях, которые действуют в разных странах, при этом объединяют данные, полученные из многих стран, в том числе и неанглоязычных. Сам по себе факт присутствия описательных данных на иностранном языке может не представлять проблемы, но с кодированными значениями могут быть сложности. Каким бы странным это ни казалось англо-говорящим пользователям, многие их франкоязычные коллеги, кажется, предпочитают использовать "О" и "N" там, где первые используют "Y" и "N", приводя в качестве оправдания тот неоспоримый факт, что oui по-французски — это yes по-английски. Поэтому при помощи метаданных необходимо идентифицировать все столбцы, значения которых берутся из определенного списка, и определить эквивалентные значения для каждого поддерживаемого языка. На этапе трансформации нужно будет перевести все эти значения на один язык.

Числовые данные могут поступать в самых разнообразных форматах. Возможно, понадобится конвертировать вещественные числа в целые, избавиться от избыточной точности представления и включить экспоненциальный формат (например, 6.2е17). Мэйнфреймовые системы, выдающие двоичные файлы, могут включать в них упакованные десятичные поля, и их символьные строки более чем вероятно будут в формате EBCDIC. Если для обеспечения необходимой конверсии нельзя будет развернуть FTP или SQL*Net, то придется написать для этой цели специальную утилиту.

Oracle справляется с большинством внешних форматов дат, но не со всеми. Есть ряд очень туманных представлений, например количество дней, прошедших с фиксированного момента времени (к примеру, с 1 января 1970 года), которые, возможно, придется преобразовывать в формат, подходящий для Oracle.

Более неприятная проблема связана с внешними данными, например с данными о покупателях. Самый худший сценарий здесь — когда приходится объединять несколько несравнимых таблиц покупателей из нескольких механизмов подачи данных в одну сводную таблицу измерения. Прежде всего нужно согласовать структуру этой сводной таблицы и первичного ключа. Таблица будет содержать все общие столбцы и ряд столбцов, поступающих только из некоторых механизмов подачи. Ключ, как правило, будет суррогатным. В метамодели должна присутствовать информация, позволяющая преобразовать каждое поле из всех механизмов подачи данных в столбец сводной таблицы измерения. Самое трудное — автоматизировать процесс преобразования так, чтобы Abс Inc. из одной системы соответствовало А. В. С. Inc. из другой. Очевидно, если нельзя выполнить преобразование автоматически, то потребуется вручную преобразовывать записи из механизмов подачи друг в друга. Обязательно сохраняйте все детали этого преобразования в справочных целях для последующих загрузок. Держите все эти детали в метамодели.