Застосовуємо Check Knowledge Module (CKM) в проектах на базі Oracle Data Integrator

Цим постом ми відкриваємо цикл матеріалів, присвячених модулю перевірки коректності даних, що входить до складу 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, Інтеграції і т. д) відповідає класу задач, розв'язуваних модулем;
  3. в рамках одного класу можуть бути обрані або розроблені специфічні модулі для вирішення конкретних типів завдань.
CKM-модуль відноситься до так званого шаблонного типу модулів, тобто передбачає (крім впливу на власну поведінку модуля через встановлення опцій) модифікацію «тіла» або створення з «нуля» власних модулів даного класу.

У цій статті ми почнемо розповідь зі стандартних перевірок, які реалізовані в поставляється з ODI CKM модулі. Розглянемо, як вони визначаються та який функціонал за допомогою них можна реалізувати.

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

Отже, в «стандарт» входить п'ять типів «говорять за себе» перевірок:

  • Primary Key (PK) – унікальність первинного ключа
  • Alternate Key (AK) – унікальність ключа
  • Join (FK) – контроль наявності пов'язаних записів
  • Condition Check (CK) – дотримання умови
  • Mandatory (NN) – обов'язковість полів
Дані перевірки задаються на рівні опису моделі даних в ODI, але можуть бути активовані/деактивовані в різних місцях залежно від режиму роботи модуля.

Перші чотири типи перевірки встановлюються на рівні Constarints конкретного сховище даних (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 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.