- одна или более таблиц источников и их связи;
- одна таблица приемник данных;
- шаблон(ы) преобразования данных из источников в целевую таблицу.
В документации рекомендуют создавать интерфейс согласно такому порядку:
- Создайте новый интерфейс.
- Добавьте целевую таблицу.
- Определите таблицы источники, соедините их и задайте фильтры.
- Задайте значения колонок целевой таблицы из колонок таблиц источников или констант.
- Задайте модули знаний, которые будут использованы для загрузки и преобразований.
- Определите модули знаний для проведения проверок.
- Запускайте интерфейс на тестирование
На самом деле, вместо слова таблица, необходимо использовать другое слово, которое бы полнее отражало термин datastore, используемый в документации. Так что когда я пишу таблица, я имею ввиду некий объект, с именем и колонками, описание которого хранится в модели данных ODI. А на самом деле это может быть, например, файл или некие JMS контейнеры сообщений.
Рассмотрим подробно, что из себя представляет окно редактирования интерфейса:
Вкладка Definition
Позволяет редактировать наименование интерфейса (1), определять контекст, согласно которому будет формироваться порядок преобразований (2), а также ввести описание интерфейса (4). По чек боксу Staging Area Different From Target хочу отдельно сказать несколько слов.
Во-первых, он используется при создании временных таблиц с помощью интерфейсов, а не процедур. Во-вторых, он используется когда область, в которой расположена целевая таблица, не может использоваться для построения временных таблиц (область стейджа).
Поясню на примере. Если мы загружаем данные в таблицу в БД, то область стейджа - это некая схема в этой БД. В таком случае, мы можем собрать данные из всех источников в одной временной таблице этой схемы, а затем преобразовать их в целевую таблицу.
В случае же, если мы хотим занести данные из источников в некоторый файл, например, то собирать данные в файловой системе (область стейджа) наверное, нет смысла. В таком случае необходимо использовать чек бокс Staging Area Different From Target и выбирать необходимую логическую схему.
Вкладка Diagram
На этой вкладке можно выделить три области. Первая - область для построения диаграммы связей между таблицами источниками. В данном случае используется только одна таблица источник, и у нее есть фильтр по одной колонке. Следующая область - целевая таблица. И третья область - окно свойств, в котором отображаются свойства выделенных объектов из первых двух областей:
Для фильтров таблиц источников или колонок целевой таблицы в окне свойств можно ввести значения. Например, так:
В данном примере выделена одна колонка целевой таблицы, при этом колонка таблицы источника, которая задействованна в маппинге тоже подсвечивается. О других опциях маппинга для целевых колонок я, возможно, расскажу отдельно.
Вкладка Flow
На этой вкладке определяется то, как будет происходить загрузка и интеграция данных. В зависимости от мапинга, источников и приемника данных, ODI определит несколько областей, данные из которых будут использоваться:
На картинке определены три группы (1, 2, 3). Для каждой группы определяется свой тип модуля знаний (LKM или IKM), а затем задаются значения для опций этого модуля знаний (4) позволяя, таким образом, настроить, при необходимости, некоторые параметры.
Разбиение на три группы произошло потому, что я установил опцию Staging Area Different From Target. Если ее убрать группа будет всего одна, так как и источник, и целевая таблица находятся в одной СУБД:
Вкладка Control
На этой вкладке можно задать модуль знаний, который будет осуществлять проверку данных перед их вставкой в целевую таблицу. Как и для модулей загрузки и интеграции (LKM, IKM), для модуля проверки (CKM) можно задавать значения опций:
Кроме этого, можно выбрать определенные для целевой таблицы ограничения из списка ограничений, чтобы CKM осуществлял их проверку. Также можно определить общее количество или процент ошибочных строк, по достижению которых интерфейс завершит свою работу с ошибкой.
Выбрать нужный CKM можно только из тех проверочных модулей знаний, которые есть в проекте, и которые работают с той технологией, в которой создана целевая таблица.
Вкладка Execution
Позволяет просматривать результат выполнения интерфейса или сценария, который из него сгенерирован, без необходимости запуска программы Оператор:
Вкладка Scenarios
На этой вкладке можно создавать сценарии интерфейса, а для уже созданных сценариев доступны те же команды, как и для сценариев, отображаемых в дереве проекта.
Вкладка Markers
На этой вкладке можно добавить или удалить маркеры. Маркеры отображаются в дереве проекта, рядом с интерфейсом.
Вкладка Memo
Полезная вкладка для занесения дополнительной информации. Если интерфейс живет достаточно долго, рекомендую заносить сюда изменения в интерфейсе, с датой, автором и описанием изменений.
Иногда такая история неоценима.
Вкладка Version
Очень полезная вкладка, если вам приходится работать в команде разработчиков ODI. Показывает кто и когда создал интерфейс, а также, кто и когда последний раз его менял. Поиск ошибок в данных часто начинался у меня с поиска интерфейсов, которые загружают эти данные, просмотре даты последнего изменения и его авторства, и, при необходимости, последующего просмотра вкладки Memo.
Также здесь находится возможность создания версий интерфейса. Если вам необходимо изменить интерфейс с десятком другим таблиц источников, неплохо было бы предварительно сдуплицировать данный интерфейс и потренироваться на копии, или, с другой стороны, можно создать версию интерфейса, а потом, при необходимости, откатиться к этой работающей версии.
Вкладка Priviledges
Отображает список пользователей и их права на данный объект. Зачем она нужна сказать не могу, возможно, для администраторов ODI, которые хотят увидеть кто и что мог бы сделать с данным интерфейсом.
Вкладка FlexFields
Отдельная закладка для дополнительных полей, которые можно привязать к интерфейсу. Попробую разобраться с этими полями отдельно и написать о них.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.