Глава 13. Проектирование для хранилищ данных

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

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

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

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

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

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

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

Отсутствие интегрированных и непротиворечивых данных — не единственная проблема, стоящая перед пользователями и руководителями. Многие системы, которые проектировались с использованием традиционных методов и приемов, недостаточно хорошо оптимизированы для выполнения запросов к данным. В частности, нерегламентированные запросы, возможность появления которых не учтена при проектировании, могут выполняться плохо или не выполняться вовсе. Так, на обработку предложений 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.)

Условие

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). Эти системы традиционно работали с данными, которые были идентичны данным, в той операционной системе, где сопровождались эти данные; такие системы обращались либо к "живым" данным, либо к их последней неизменяемой копии. Хранилища данных не обязательно берут непосредственные копии рабочих данных из ООТ-систем. Их таблицы строятся на рабочих данных, но, как правило, включают только те детали, которые касаются процесса принятия решений. Принадлежащие вашей организации данные, конечно, представляют интерес, но если их объединить с общими данными о рынке, в том числе о ваших конкурентах, то такая информация приобретает совершенно новое значение. Источниками данных для хранилища могут являться маркетинговые агентства, а также различного рода сервисные системы, например система агентства Рейтер.

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

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

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

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

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

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 наконец-то реализованы гистограммы распределения значений. Это позволяет оптимизатору запросов вычислять избирательность при индексировании данных, в распределении значений которых наблюдается перекос.

В Огас1е7 есть еще ряд возможностей, которые не предназначены специально для хранилищ данных, но которые мы можем использовать в этой области. Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Термин "секционирование" очень широко используется специалистами по базам данных и в общем случае означает формирование подмножеств данных. Различают горизонтальные секции, состоящие из подмножества строк, и вертикальные секции, представляющие собой подмножество столбцов (рис. 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). Если мы будем формировать все возможные сочетания агрегированных значений, то создадим в таблице фактов огромное число новых фактов. Естественно, мы должны выбрать из них важные, а остальные удалить.

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

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

Может случиться, что ни одну из категорий, показанных в табл. 13.1, полностью удалить нельзя из-за их важности для различных аспектов бизнеса. Тем не менее, весьма вероятно, что можно будет удалить определенные комбинации. Например, данные о том, сколько продаж произведено непосредственно, а сколько — через дистрибьютора, могут потребоваться только за квартал и только по некоторым сериям товаров, потому что, скорее всего, не все товары продаются через оба канала. Анализ управленческих отчетов, получаемых из ООТ-систем, может дать информацию, которая поможет принять решение о том, какие сочетания агрегированных значений важны.

Теперь посмотрим, как выполнять агрегирование. Под этим мы подразумеваем следующее: где физически хранить агрегированные данные. Есть три возможных варианта:

Как и следовало ожидать, у каждого из них есть достоинства и недостатки.

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

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

Процесс извлечения и загрузки данных состоит из нескольких этапов. Одни из них выполняются подающей системой, а другие — системой хранилища данных.

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

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

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

Определившись с тем, какие данные нужны, необходимо решить, как и в каком формате мы будем их "вытягивать". Наиболее распространенным форматом до сих пор является двумерный файл. Двумерные файлы бывают двух типов: с записями фиксированной длины и с записями переменной длины (см. главу 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). Метаданные могут также содержать преобразующий уровень для средства создания нерегламентированных запросов или отчетов, используемого для исследования данных. Они могут описывать данные терминами, понятными конечному пользователю, и скрывают все сложности в основных структурах базы данных. Метаданные содержат подробные сведения о том, как пользователь секционировал свои таблицы фактов и какие агрегированные данные имеются для каждой из этих таблиц. С помощью этой информации интеллектуальный инструмент запроса или процессор промежуточного ПО может принимать осмысленные решения о том, как лучше построить эффективный запрос на основании критериев поиска, заданных пользователем. Качественно сопровождаемая метамодель — неоценимый инструмент, даже если не используется промежуточное ПО, которое требует ее наличия.

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

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

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

где:

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

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

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

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

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

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

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

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

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

OLAP-средства можно разделить на две категории:

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

Выбор OLAP-средства — важный этап процесса разработки хранилищ данных. Рекомендуем сделать этот выбор как можно раньше, потому что от него могут зависеть некоторые проектные решения. Например, может встать вопрос о том, сколько атомарных данных хранить и сколько агрегированных значений сопровождать. Некоторые OLAP-средства могут выдавать агрегированные значения "на лету" в процессе выполнения. Если в хранилище данных содержатся сведения о продажах по месяцам (но не по кварталам), то цифры за месяц можно получить простым суммированием по группам. Более вероятный сценарий — когда обеспечивается необходимое агрегирование, но нужно показать конкретный экземпляр измерения в процентах к общему итогу или в совокупности с другим измерением. Например:

Мораль: чем более сведуще ваше OLAP-средство в получении этих данных, тем меньше вероятность того, что возникнут вопросы такого типа.

НОВОСТИ ФОРУМА Рыцари теории эфира

10.11.2021 - 12:37: ПЕРСОНАЛИИ - Personalias -> WHO IS WHO - КТО ЕСТЬ КТО - Карим_Хайдаров. 10.11.2021 - 12:36: СОВЕСТЬ - Conscience -> РАСЧЕЛОВЕЧИВАНИЕ ЧЕЛОВЕКА. КОМУ ЭТО НАДО? - Карим_Хайдаров. 10.11.2021 - 12:36: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от д.м.н. Александра Алексеевича Редько - Карим_Хайдаров. 10.11.2021 - 12:35: ЭКОЛОГИЯ - Ecology -> Биологическая безопасность населения - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> ПРАВОСУДИЯ.НЕТ - Карим_Хайдаров. 10.11.2021 - 12:34: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вадима Глогера, США - Карим_Хайдаров. 10.11.2021 - 09:18: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> Волновая генетика Петра Гаряева, 5G-контроль и управление - Карим_Хайдаров. 10.11.2021 - 09:18: ЭКОЛОГИЯ - Ecology -> ЭКОЛОГИЯ ДЛЯ ВСЕХ - Карим_Хайдаров. 10.11.2021 - 09:16: ЭКОЛОГИЯ - Ecology -> ПРОБЛЕМЫ МЕДИЦИНЫ - Карим_Хайдаров. 10.11.2021 - 09:15: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Екатерины Коваленко - Карим_Хайдаров. 10.11.2021 - 09:13: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вильгельма Варкентина - Карим_Хайдаров.