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

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

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

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

Примечание

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

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

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

Что такое хранилище данных?

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

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

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

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

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

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

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