Этим постом мы открываем цикл материалов, посвященных модулю проверки корректности данных, входящему в состав ETL (или ELT – как его позиционирует ORACLE) продукта Oracle Data Integrator. На наш взгляд, функционал модуля незаслуженно игнорируется в угоду более изысканным и «интеллектуальным» продуктам класса Data Quality. В этой связи у нас есть желание взглянуть на CKM не как на некий атавизм, а как на целостное решение, позволяющее обеспечить базовый контроль над обрабатываемыми данными.
Для этого планируем:
В качестве вступления стоит отметить, что все модули в ODI носят гордое название Knowledge Module, что, по-видимому, отражает следующие факты:
CKM-модуль относится к так называемому шаблонному типу модулей, т.е. предполагает (помимо влияния на собственное поведение модуля через установку опций) модификацию «тела» или создание с «нуля» собственных модулей данного класса.
В этой статье мы начнем рассказ со стандартных проверок, которые реализованы в поставляемом с ODI CKM модуле. Рассмотрим, как они задаются и какой функционал с помощью них можно реализовать.
Сразу же стоит отметить, что использовать модуль возможно в двух режимах (STATIC_CONTROL и FLOW_CONTROL): контроль исходных/конечных данных или проверка корректности данных, полученных в результате интеграционного маппинга, перед их размещением в целевой таблице, соответственно.
Итак, в «стандарт» входит пять типов «говорящих за себя» проверок:
Данные проверки задаются на уровне описания модели данных в 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. Индивидуальные настройки.
Тип ограничения Primary Key или Alternate Key указывает на соответствующий тип проверки. Вариант Not Unique Index используется только в качестве указания на необходимость создания дополнительного индекса в целях увеличения производительности.
При определении ограничения выбираются из доступных модель данных и родительская таблица (точнее DS) – на рисунке ниже красным.
В простом варианте (Type=User Reference / Database Reference) условие соединения задает ограничение по внешнему ключу, в «продвинутом» варианте (Type= Complex User Reference) допускается задание более сложного условия, как уже описывалось выше (на рисунке опция выделена зеленым).
Итак, ограничения прописаны в модели данных – что дальше? Теперь они должны быть задействованы в проверке 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.
Статья подготовлена Алексеем Полевым, архитектором Департамента прикладных финансовых систем компании «Инфосистемы Джет».
Для этого планируем:
- рассказать о типах проверок, включенных в стандартный оракловый модуль и о том, какие настройки необходимо выполнить, чтобы их активировать;
- коснуться особенностей выполнения, возможностей по расширению стандартного модуля, использования подстановочного (substitution) API, который используется для обеспечения универсальности дорабатываемого функционала;
- на конкретном примере рассмотреть возможности, предоставляемые Oracle Data Integrator Tools, и вариант переноса настроек DEV->PROD с использованием топологии;
- оценить рабочее место оператора, обрабатывающего ошибки, обнаруженные модулем CKM.
В качестве вступления стоит отметить, что все модули в ODI носят гордое название Knowledge Module, что, по-видимому, отражает следующие факты:
- в модуль заранее зашито определенное поведение;
- наименование модуля (Check, Loading, Integration и т.д) соответствует классу задач, решаемых модулем;
- в рамках одного класса могут быть выбраны или разработаны специфические модули для решения конкретных типов задач.
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.
Статья подготовлена Алексеем Полевым, архитектором Департамента прикладных финансовых систем компании «Инфосистемы Джет».
Поделиться с друзьями