Физическое преобразование данных приложений источников

Важным моментом в системах складирования данных является физическое преобразование данных. Эти процедуры в складировании данных известны как процессы очистки данных (" data scrubbing ", "data staging" или "data purge "). Процесс очистки данных является наиболее интенсивным и трудоемким в любом проекте создания ХД. Физическое преобразование включает использование стандартных терминов предметной области ХД и стандартов данных. В течение процесса физического преобразования данные находятся в некотором промежуточном файле до того, как будут занесены в ХД. Когда данные собираются из многих приложений, их целостность может быть проверена в течение процесса формирования преобразованных данных до загрузки в ХД.

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

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

Различные подсистемы OLTP-систем и внешних источников данных могут использовать различное определение доменов атрибутов на физическом уровне представления данных. Так, атрибут типа "идентификатор продукта" в одной системе имеет длину от 12 символов, а в другой — 18 символов. С другой стороны, ПО одних существующих систем может иметь ограничения на определение длин имен атрибутов и бедный набор типов для определения доменов, а в других такие ограничения могут отсутствовать и может предоставляться широкий выбор типов атрибутов.

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

Все атрибуты в ХД должны согласованно использовать предопределенные значения. В различных приложениях могут быть приняты различные соглашения по предопределенным значениям атрибутов. К таким предопределенным значениям относятся значения по умолчанию, значения, заменяющие null-значения, и т. п. Например, признак пола в различных системах может иметь различные значения: в одних это символьные значения "М" и "Ж", в других — цифровые значения 0 и 1. Более неприятным примером является случай, когда одно значение данных используется в приложении в нескольких целях, т.е. атрибут на самом деле представляет множественное значение. Например, когда в атрибуте "тип метода измерения" две первые цифры означают метод измерения, а две вторые — метод физического контроля измерения. Такие различные значения перед загрузкой в ХД должны быть преобразованы к принятому в ХД предопределенному значению.

В некоторых системах — источниках данных могут отсутствовать значения (проблема пропущенных значений, "missing data") или преобразование для них не может быть выполнено (" corrupt data " — данные, для которых преобразование не может быть выполнено). Важно, чтобы в процессе преобразования такие данные принимали в ХД значения, которые позволяли бы пользователям интерпретировать их правильно. Одним атрибутам можно просто назначить разумное значение по умолчанию в случае отсутствия значения или конфликтов при преобразовании, а другим атрибутам — определить значения из значений прочих атрибутов. Например, пусть в сущности "Заказ" значение атрибута единицы измерения товара пропущено. Это значение может быть получено из соответствующего атрибута сущности "Товар" этой системы-источника. Для некоторых атрибутов не существует подходящих значений по умолчанию в случае, когда их значения отсутствуют. Для таких пропущенных значений в ХД следует также определять значение по умолчанию, например, как null-значение.

Таким образом, в процессе преобразования данных проектировщик ХД должен привести данные систем-источников к определенным стандартам (рис. 1.6), а именно:

• стандартизовать наименования атрибутов в ХД;
• определить одинаковые домены для одних и тех же атрибутов различных систем-источников;
• принять соглашения о значениях по умолчанию для пропущенных данных;
• принять соглашения о предопределенных значениях атрибутов.

Рис. 1.6. Стандарты физического представления данных

В табл. 1.1 приведены основные отличия использования данных в системах операционной обработки данных и системах анализа данных.