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

Объединение таблиц фактов

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

Извлечение и загрузка данных

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

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

Этап 1: Чтение данных

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

полезность этих данных;

сложность их получения - ПК выключаются и переносятся с монотонной регулярностью, а когда они подключаются к сети, то их IP-адреса таинственным образом исчезают;

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

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

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

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

set echo off termout off arraysize 100 pagesize 0 spool extract.lis

SELECT cust id, order no, order value, sales code, order date FROM orders

spool off exit

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

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

Этап 2: Фильтрация данных

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

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

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

Этап 3: Предотвращение потерь ретроспективных данных

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