Этим постом мы открываем цикл материалов, посвященных модулю проверки корректности данных, входящему в состав ETL (или ELT – как его позиционирует ORACLE) продукта Oracle Data Integrator. На наш взгляд, функционал модуля незаслуженно игнорируется в угоду более изысканным и «интеллектуальным» продуктам класса Data Quality. В этой связи у нас есть желание взглянуть на CKM не как на некий атавизм, а как на целостное решение, позволяющее обеспечить базовый контроль над обрабатываемыми данными.

Для этого планируем:

  1. рассказать о типах проверок, включенных в стандартный оракловый модуль и о том, какие настройки необходимо выполнить, чтобы их активировать;
  2. коснуться особенностей выполнения, возможностей по расширению стандартного модуля, использования подстановочного (substitution) API, который используется для обеспечения универсальности дорабатываемого функционала;
  3. на конкретном примере рассмотреть возможности, предоставляемые Oracle Data Integrator Tools, и вариант переноса настроек DEV->PROD с использованием топологии;
  4. оценить рабочее место оператора, обрабатывающего ошибки, обнаруженные модулем CKM.

В качестве вступления стоит отметить, что все модули в ODI носят гордое название Knowledge Module, что, по-видимому, отражает следующие факты:

  1. в модуль заранее зашито определенное поведение;
  2. наименование модуля (Check, Loading, Integration и т.д) соответствует классу задач, решаемых модулем;
  3. в рамках одного класса могут быть выбраны или разработаны специфические модули для решения конкретных типов задач.

CKM-модуль относится к так называемому шаблонному типу модулей, т.е. предполагает (помимо влияния на собственное поведение модуля через установку опций) модификацию «тела» или создание с «нуля» собственных модулей данного класса.

В этой статье мы начнем рассказ со стандартных проверок, которые реализованы в поставляемом с ODI CKM модуле. Рассмотрим, как они задаются и какой функционал с помощью них можно реализовать.

Сразу же стоит отметить, что использовать модуль возможно в двух режимах (STATIC_CONTROL и FLOW_CONTROL): контроль исходных/конечных данных или проверка корректности данных, полученных в результате интеграционного маппинга, перед их размещением в целевой таблице, соответственно.

Итак, в «стандарт» входит пять типов «говорящих за себя» проверок:

  • Primary Key (PK) – уникальность первичного ключа
  • Alternate Key (AK) – уникальность ключа
  • Join (FK) – контроль наличия связанных записей
  • Condition Check (CK) – соблюдение условия
  • Mandatory (NN) – обязательность полей

Данные проверки задаются на уровне описания модели данных в ODI, но могут быть активированы/деактивированы в различных местах в зависимости от режима работы модуля.

Первые четыре типа проверки устанавливаются на уровне Constarints конкретного DataStore (DS — описание сущности – таблицы, файла и т.д. – в репозитории метаданных ODI) и используют отдельные записи для каждого задаваемого ограничения.


На иллюстрации мы видим набор проверок, заданных для двух Data Store: DIM_COUNTRY и REF_CALENDAR. Обратите внимание, что при создании под одним из DS обе проверки внешнего ключа становятся видны и под другим DS, связанным по условию FK.

Последний тип проверки – Mandatory, задается на уровне полей DS:


Давайте рассмотрим какие общие и частные параметры задаются для разных типов проверок.
1. Режимы, для которых может быть использован рассматриваемый контроль данных (Static/Flow), соответствуют режимам работы CKM — STATIC_CONTROL/FLOW_CONTROL соответственно. На рисунке ниже – красным.


Флаги в зеленом блоке (только для проверок PK/AK/CK) указывают на необходимость физического наличия и активности данного ограничения в конечной системе соответственно, если такая возможность подразумевается. Такой же смысл несут в себе значения параметров Type = Database reference и флага Activate on Database для ограничения типа FK.


Или значение Database Condition для ограничения CK.


По сути, параметры, отвечающие за физическое наличие и активность ограничения, призваны лишь отражать желаемое/имеющееся состояние конечной системы – их установка/снятие не влияет напрямую на конечную систему. Данные параметры проставляются при построении модели данных на основе метаданных конечной системы (реверс-инжиниринге). Либо соответствующее определение ограничения добавляется в скрипт генерации объекта в конечной системе, автоматически создаваемый на базе описания модели данных – при явном запросе на создание.

2. Атрибуты, участвующие в условии ограничения для PK/AK задаются поля, входящие в состав ключа:


для FK – ссылочные поля (слева) и соответствующие им поля ключа в родительской таблице (справа):


Если вид ограничения FK задан как Complex User Reference, то условие связи таблиц задается в поле Expression


Для CK задается условие, которое будет проверяться (оно может быть достаточно сложным).


Тут стоит сказать, что в выражении как для FK, так и для CK допускается использовать функции из подстановочного API (о них в следующей статье). Однако для CK (при условии Type = Oracle Data Integrator Condition) такое условие пройдет встроенную проверку (зеленая галка), а для FK – уже нет.

3. Индивидуальные настройки.
A. Для PK и AK.

Тип ограничения Primary Key или Alternate Key указывает на соответствующий тип проверки. Вариант Not Unique Index используется только в качестве указания на необходимость создания дополнительного индекса в целях увеличения производительности.


B. Для FK

При определении ограничения выбираются из доступных модель данных и родительская таблица (точнее DS) – на рисунке ниже красным.


В простом варианте (Type=User Reference / Database Reference) условие соединения задает ограничение по внешнему ключу, в «продвинутом» варианте (Type= Complex User Reference) допускается задание более сложного условия, как уже описывалось выше (на рисунке опция выделена зеленым).

C. Для CK и NN варианты имеющихся настроек уже были охвачены при разборе других пунктов

Итак, ограничения прописаны в модели данных – что дальше? Теперь они должны быть задействованы в проверке STATIC_CONTROL. Для FLOW_CONTROL существует дополнительный уровень контроля АКТИВАЦИИ ограничений, который при создании маппинга устанавливается в соответствие с настройками, имеющимися в модели, но может быть переопределен. Познакомимся с ним.

Для этого рассмотрим вкладку Logical, выбираемую при просмотре конкретного интеграционного маппинга.


На ней необходимо выделить результирующий DS и перейти к его свойствам. Здесь в указанных красным блоках можно активировать/деактивировать имеющиеся проверки.


Но есть ряд нюансов.

Проверки типа NN можно активировать/деактивировать вне зависимости от того, установлены ли флаги Mandatory и Flow в модели данных. Т.е. эти установки являются абсолютно независимыми от модели и полностью переопределяют их. Таким образом изменения, производимые на уровне модели, не повлияют на существующий маппинг и будут учтены только при создании нового.

Проверки типа PK/AK/FK/CK можно активировать/деактивировать, но если Flow-флаг снят в модели, то активация ограничения на уровне маппинга не поможет – данная проверка не будет производиться в режиме FLOW_CONTROL вне зависимости от значения, указанного на уровне маппинга. Обратное работает – проверка может быть отключена на уровне маппинга.

Есть особенность поведения ODI Studio 12c (version 12.1.3.0.0). При изменении флага Flow для ограничений PK/AK/FK/CK на уровне модели данный факт автоматически НЕ отражается в существующем маппинге (слово не появляется/не исчезает в окне Constarints напротив соответствующего ограничения). Это произойдет только при перевыборе значения флага в интерфейсе. Поэтому, во избежание недоразумений в поведении модуля с учетом предыдущего нюанса, при деактивации ограничения в модели необходимо вручную актуализировать все связанные с ним маппинги.

И последнее, о чем необходимо сказать в данной статье для полноты затронутой темы, – как задействовать CKM в проверках. Для режима STATIC_CONTROL модуль необходимо указать в настройках модели данных.


Это позволит анализировать «чистоту» данных в любом из имеющихся DS, например, выбрав соответствующий пункт контекстного меню на конкретном DS либо нажав кнопку Datastore Static Control на вкладке Definition при просмотре DS.


Для активации режима STATIC_CONTROL/FLOW_CONTROL на уровне маппинга потребуется указание соответствующей директивы CKM_STATIC/CKM_FLOW в коде модуля IKM, подключенного к маппингу.


А также на вкладке Physical в маппинге указать сам CKM модуль и убедиться, что при подключении IKM (выделено зеленым) активирована опция FLOW_CONTROL.


Статья подготовлена Алексеем Полевым, архитектором Департамента прикладных финансовых систем компании «Инфосистемы Джет».
Поделиться с друзьями
-->

Комментарии (0)