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

Метаданные

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

Рабочие ► 1ногомерные

данные i данные

Метаданные

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

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

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

Типы и методы трансформации данных

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

Закодированные значения

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

Policy Number = 92SWMV092,

где:

92 = год;

SW = регион или территория;

MV = тип полиса;

092 = порядковый номер.

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

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

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

Флаги в многоязычных системах

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

Манипулирование числовыми данными

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

Манипулирование датами

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

Преобразование и слияние ключей

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

Более неприятная проблема связана с внещними данными, например с данными о покупателях. Самый худщий сценарий здесь - когда приходится объединять несколько несравнимых таблиц покупателей из нескольких