Этот раздел мог бы быть отдельной книгой. Цель этого раздела - дать некоторые общие указания и подсказки по тому, как разрабатывать схему ХД с использованием ODI, а вовсе не предоставить полное руководство по хранилищам данных.
Всегда хорошо, при построении ХД, иметь некое место для хранения данных систем источников в их исходном виде. Это место - специальная БД, называемая ODS (Operational Data Store), содержит модели данных, которые очень похожи на модели данных систем источников, она содержит таблицы для хранения любых необходимых данных, и, практически, не содержит правил по качеству этих данных. Наличие ODS позволяет оперировать данными из всех систем источников за день.
В данном тексте ODS выступает в роли области стейджа, описанной вот здесь. Хотя, судя по описанию самого понятия Operational Data Store, ODS это немного более общее понятие, чем просто специализированная БД, куда копируются данные из систем источников, чтобы затем попадасть в ХД. Данные в ODS, после соответствующих преобразований по очистке, удалению дубликатов, проверке целостности и т.п., могут попадать назад в системы источники данных.
Временная БД для области стейджа, ниже по тексту, это просто место, где ODI хранит временные таблицы, используемые при выполнении ETL преобразований. Стейдж таблица ODI, в большинстве случаев, существует только в момент преобразования данных, и удаляется по их завершению.
Стейдж, как область, это выделенная БД для хранения копий таблиц из систем источников для их дальнейшей загрузки в ХД. Таким образом, стейдж, это более узкое понятие, чем ODS.
ODS, как область, это выделенная БД для хранения копий таблиц источников, их преобразования, очистки, и возврата данных назад в системы источники, и(или) вперед, в хранилище данных.
При разработке хранилища данных, следующие общие советы могут оказаться полезными:
- Где это возможно, вносите описания колонок и таблиц в словарь данных БД (используйте, например, sql операторы "COMMENT ON TABLE" и "COMMENT ON COLUMN"). Делая это, вы позволите ODI получить эту информацию и сохранить ее в своем репозитории.
- Создайте временную БД для области стейджа, где ODI будет создавать временные таблицы для загрузки данных или таблицы для хранения информации об ошибочных данных.
- Не используйте первичные ключи систем источников как первичные ключи целевых таблиц. Используйте автогенерируемые значения для столбцов идентификаторов везде, где это возможно. Это поможет сделать модель данных более гибкой и уменьшит вероятность необходимости в изменениях моделей данных с течением времени.
- Разработайте ограничения целостности и внешние ключи для моделей ODI. Не добавляйте эти ограничения целостности для целевых таблиц БД, так как это может привести к проблемам производительности. С автоматической проверкой качества данных, ODI может гарантировать согласованность данных согласно заданным ограничениям.
- Выработайте соглашения об именованиях объектов. Например, используйте три первые буквы для определения области хранения. Избегайте слишком длинных названий таблиц, так как ODI добавляет префиксы к этим именам при построении временных таблиц. Например E$_Customer будет таблицей хранения ошибок для целевой таблицы Customer.
- При использовании ODI совершенно не важно, будете ли вы использовать третью нормальную форму или другие варианты построения логической схемы таблиц ХД (схема зведы или снежинка). Выбор схемы оказывает влияние только на дальнейшее определение правил преобразования данных или принципы построения отчетов.
Как только ODS и ХД разработаны, вам необходимо создать соответствующие модели в Дизайнере, и сделать реверс-инжиниринг. ODI включает возможность работы с моделями, которая называется Common Format Designer. Этот механизм помогает разрабатывать структуры ODS и целевых таблиц ХД через структуры таблиц систем источников данных, просто путем перетаскивания колонок и констрейнтов из таблиц источников.
При генерации команд языка описания данных (DDL) ODI автоматически будет использовать специфические возможности целевой БД. Common Format Designer, основываясь на информации об источнике данных для колонки, может автоматически сгенерировать интерфейс загрузки целевой таблицы, что значительно экономит время.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.