ODI 11g. Реверс-инжиниринг, изучение и профилирование источников данных (Reverse-engineering, Auditing and Profiling Source Applications).
Продолжаю публикацию перевода некоторых частей документа Oracle Data Integrator Best Practices for a Data Warehouse.
Хорошей отправной точкой для проекта является изучение данных и их структуры. Даже при наличии документации на системы источники данных, хорошей практикой будет подключиться к этим источникам через ODI и получить метаданные для них.
Подключение источников поможет вам создать в моделях ODI бизнес правила, связанные с качеством данных. А определение этих правил поможет проверить полноту и непротиворечивость данных в системах источниках, а также, будет способствовать более глубокому пониманию моделей данных.
На этом этапе необходимо начинать искать ответы на примерно такой перечень вопросов:
Присутствуют ли в системах источниках данные, которые потребуются для наших расчетов?
Сколько различных систем источников мы должны обработать, чтобы получить необходимые нам показатели?
Какие задачи по качеству данных предстоит решить, чтобы обеспечить достаточное качество данных в целевом ХД?
Какие системы источники данных будут базовыми для создания размерностей (Dimensions) для показателей в ХД?
Какими объемами данных мы будем манипулировать?
И т.п.
В некоторых случаях, системы источники данных недоступны напрямую. Возможно, доступ к данным обеспечивается только через тесктовые или бинарные файлы. Рекомендуется начинать работать с этими файлами до того, как модель данных ХД будет готова, так как данные в этих файлах показывают ситуацию такой, какая она есть на самом деле.
Структура этих файлов, в большинстве случаев, должна быть описана в репозитории ODI. Образцы данных из этих файлов обычно загружаются во временные таблицы для проверки их структуры и содержимого.
Описанное выше может быть реализовано в Oracle Data Integrator следующим образом:
Подключение систем источников или файлов в Топологии.
Определение логической архитектуре в Топологии.
Создание модели данных для каждой логической схемы данных в Дизайнере.
Реверс моделей данных или ручное создание моделей таблиц источников:
Использование стандартных JDBC драйверов для реверса данных из СУБД.
Использование настраиваемых стратегий реверса (модули знаний реверса) когда стандартный способ не работает, или работает не совсем аккуратно.
Использование процедуры импорта Cobol Copy Book для текстовых или бинарных файлов.
Использование процедуры реверса для текстовых файлов с разделителями.
Добавление к моделям данных дополнительной информации:
Заголовки и описания для таблиц и колонок.
Признак уникального ключа (первичный или альтернативный ключ) для колонок.
Связывание нескольких таблиц внешним ключом.
Задание списка ограничений (констрейнты) для таблиц или колонок.
Если данные находятся в файлах, разработайте простой интерфейс для загрузки данных во временную таблицу целевой БД для проведения анализа качества этих данных.
Определите ключевые аспекты источника данных, и используйте следующие возможности ODI для анализа этих аспектов:
Просмотр данных таблицы.
Просмотр разброса данных для колонки таблицы.
Подсчет количества записей.
Запуск sql скриптов из Дизайнера.
Проверяйте ограничения, которые вы определили для моделей, чтобы провести анализ качества данных:
Запускайте вручную или по расписанию статическую проверку моделей или таблиц.
Просматривайте содержимое таблиц с ошибочными данными.
Планируйте альтернативные варианты обработки расхождений в данных.
Задавайте допустимый уровень расхождений в данных ХД.
Конечно, эти виды задач должны выполняться вместе с бизнес-аналитиками. Обычно, задачи анализа и профилирования данных систем источников выполняются одновременно с разработкой модели данных целевого хранилища данных.
