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

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

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

Этап 4: Обработка данных

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

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

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

Этап 5: Перемещение данных

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

Этап 6: Загрузка данных в хранилище

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

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

Этап 7: Сортировка отклоненных записей

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

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

Неправильный порядок загрузки, например попытка загрузить строку фактов со значением измерения, которое еще предстоит загрузить. Это

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

Внутренние проблемы, например недостаток места в хранилище и недостаточный объем области сортировки для перестройки индексов.

Прерванная, остановленная или частично заверщенная загрузка.

Наличие дублированных данных, что также указывает на просчеты при проектировании или на ошибки в реализации проверки данных.

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

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

Этап 8: Создание агрегированных значений

Этот этап описан выше в разделе Правила агрегирования .

Этап 9: Верификация

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

если вы суммируете все продажи, используя одно измерение, то полученный результат должен совпадать с суммой, полученной при помощи другого измерения;

объем продаж за данный месяц должен равняться сумме объемов продаж по дням этого месяца;

сумма объемов продаж по всем регионам за данный месяц должна равняться сумме объемов продаж по всем продавцам за этот месяц;

и так далее.