среда, 29 декабря 2010 г.

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 скриптов из Дизайнера.
  • Проверяйте ограничения, которые вы определили для моделей, чтобы провести анализ качества данных:
    • Запускайте вручную или по расписанию статическую проверку моделей или таблиц.
    • Просматривайте содержимое таблиц с ошибочными данными.
    • Планируйте альтернативные варианты обработки расхождений в данных.
    • Задавайте допустимый уровень расхождений в данных ХД.

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

См. также: Типология интерфейсов.

Комментариев нет:

Отправить комментарий