Таблиці моделі даних реєстру та їх структури

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

Розробка регламенту передбачає розробку моделі даних реєстру. Кабінет адміністратора регламентів дозволяє працювати із таблицями бази даних реєстру у режимі перегляду (read-only).

Перегляд переліку таблиць та їх структури доступний для майстер- та кандидат-версії регламенту.

Детальніше про версійність регламенту ви можете переглянути за посиланням:

1. Загальний огляд

Адміністратор може виконати пошук таблиці за назвою (латиницею), сортувати таблиці за назвою, історичністю, суб’єктністю та описом, а також досліджувати їх структуру відповідно до моделі даних.

Переглянути повний перелік таблиць можна наступним чином:

  1. Увійдіть до Кабінету адміністратора регламентів.

  2. Оберіть майстер-версію змін, або версію-кандидат.

    Майстер-версія — це гілка регламенту за замовчуванням. При вході до Кабінету, адміністратор завжди потрапляє на ⌂ Домашню сторінку із майстер-версією змін.

  3. Перейдіть до розділу Таблиці.

    tables data structures 1

2. Пошук таблиць за назвою

Адміністратор регламенту може швидко та зручно знайти потрібну таблицю за допомогою поля Шукати за назвою. Просто введіть початкові літери.

tables data structures 2

3. Сортування таблиць

Адміністратор регламенту може сортувати таблиці за назвою, історичністю, суб’єктністю та описом, швидко знаходячи необхідні значення.

Підтримується 2 типи сортування:

  • ↓ — Низхідне сортування.

  • ↑ — Висхідне сортування.

Поля, до яких застосовується сортування:

  • Назва таблиці;

  • Історична;

  • Суб’єкт;

  • Опис

tables data structures 3

4. Перегляд структури таблиць

Адміністратор регламенту може переглядати структуру таблиць бази даних реєстру відповідно до передбаченої моделі.

Щоб переглянути структуру таблиць, у розділі Таблиці відкрийте будь-яку таблицю.

tables data structures 5

4.1. Вкладка "Загальна"

На вкладці Загальна доступна основна інформація про таблицю, що дозволяє поверхнево ознайомитися із призначенням цієї таблиці, а також деякими її атрибутами, а саме:

  • Поле Назва — містить назву таблиці із бази даних реєстру. Наприклад, diplomas.

  • Поле Опис — містить опис, тобто призначення таблиці у базі даних реєстру. Наприклад, Отримані дипломи.

  • Чекбокс Суб’єктність — дозволяє визначати суб’єктність таблиці.

    Чекбокс показує наявність зв’язку із суб’єктом. На рівні таблиці об’єктів можна задати атрибут isObject="true", який дозволяє додати колонку із посиланням до таблиці суб’єктів (tableName="subject"), тобто до певного власника даних.

    tables data structures 6

4.2. Вкладка "Індекси"

Вкладка Індекси дозволяє переглядати перелік індексів конкретної таблиці у базі даних, а також правил, за якими вони працюють.

Індекс (англ. index) — об’єкт бази даних, що створений з метою підвищення ефективності виконання запитів. Таблиці в базі даних можуть мати велику кількість рядків, які зберігаються у довільному порядку, і їх пошук за заданим значенням шляхом послідовного перегляду таблиці, рядок за рядком, може займати багато часу.

Індекс формується зі значень одного чи кількох стовпчиків таблиці й вказівників на відповідні рядки таблиці й, таким чином, дозволяє знаходити потрібний рядок за заданим значенням.

tables data structures 7

Вкладка містить 2 колонки:

  • Назва — назва індекса (об’єкта).

  • Правило — правило, що застосовуються до відповідного індекса при вибірці даних. Наприклад, як саме представити дані у відповіді на запит — висхідним списком (ASC), або низхідним (DESC) тощо.

Моделювальник може також відсортувати (висхідне та низхідне сортування) індекси за назвою, а також правилом, яке застосовується до індекса при пошуку даних.

Також доступна опція пагінації (розбивки на сторінки), якщо кількість записів з індексами перевищує 10 на сторінці.

4.3. Вкладка "Колонки"

Вкладка "Колонки" дозволяє переглядати структуру колонок у певній таблиці бази даних реєстру.

Наразі є можливість переглянути такі параметри:

  • Колонка — назва колонки у БД реєстру.

  • Тип — тип даних, який зберігається у полі.

  • Значення за замовчуванням — значення поля за замовчуванням, якщо не явно не вказане інше.

tables data structures 4

Також підтримується 2 типи сортування за усіма колонками:

  • ↓ — Низхідне сортування.

  • ↑ — Висхідне сортування.

5. Особливості роботи з таблицями в рамках версій-кандидатів

Розробка регламенту передбачає розробку моделі даних реєстру. Перегляд переліку таблиць та їх структури доступний у режимі читання (read-only) для версій-кандидатів (детальніше — див. Управління версіями регламенту).

Функціональні сценарії:

  • Перегляд поточного стану моделі даних регламенту реєстру (перелік таблиць), що розробляється (в рамках версії-кандидату).

  • Отримання результату перевірки можливості успішного розгортання моделі даних.

  • Перегляд значення атрибута "суб’єктність" у переліку таблиць.

  • Видалення тимчасових БД для версій-кандидатів

5.1. Особливості розгортання тимчасових реплік

При роботі з даними реєстру, для кожної версії-кандидата створюється та розгортається тимчасова репліка з еталонної бази даних (PostgreSQL). Еталонна БД містить лише структуру, без жодних даних реєстру.

Підсистема розгортання регламенту (регламентний jenkins) створює структуру БД шляхом розгортання liquibase-конфігурацій регламенту реєстру (див. детальніше — Створення фізичної моделі даних).

Приклад 1. Скрипт автоматичного розгортання тимчасової репліки з еталонної БД
CREATE DATABASE [registry-dev-<vcid>] WITH TEMPLATE registry-template OWNER [our owner user];

Цей скрипт створює нову тимчасову БД з іменем registry-dev-<vcid>, яка буде скопійована з еталонної БД registry-template. <vcid> — це унікальний ідентифікатор версії-кандидата.

  • registry-template — ім’я еталонної БД, отриманої після відпрацювання OKD run-db-script-job.

  • registry-dev-<vcid> — шаблон імені тимчасової БД для версії-кандидата.

Підсистема управління регламентом (registry-regulations-management) зчитує структуру дата-моделі тимчасової БД та зберігає її як знімок поточного стану моделі даних до файлу DataModelSnapshot у форматі JSON. Надалі ці дані передаються до Кабінету адміністратора регламентів, де для кожної окремої версії-кандидата відображається актуальний стан таблиць БД.

Після успішної генерації тимчасової БД для певної версії-кандидата, адміністратор матиме змогу працювати зі створеною реплікою та може переглядати усі таблиці та їх структуру у розділі Таблиці Кабінету адміністратора регламентів.

Загальний вигляд інтерфейсу Кабінету адміністратора регламентів для версій майстер та кандидат при роботі із таблицями однаковий (див. розділ Загальний огляд).

5.2. Перевірка працездатності наявної конфігурації розгортання тимчасової БД

Під час розгортання тимчасових БД проводиться також перевірка працездатності наявної конфігурації liquibase changelog регламенту реєстру. Під час цього процесу до Кабінету адміністратора регламентів передається інформація про стан виконання відповідного Jenkins-пайплайну.

До відповідного MR (запита на злиття змін до майстер-гілки) у Gerrit публікується статус розгортання тимчасової БД.

Підсистема управління регламентом зчитує стан розгортання регламенту реєстру (розгортання liquibase) з відповідного MR у Gerrit. Стан виконання відповідного пайплайну відображається в Gerrit MR для версії-кандидата за допомогою специфічних міток (specific labels):

  • SUCCESS: процес розгортання та перевірки успішний (Verified +1)

    tables data structures 8

  • FAILED: процес розгортання та перевірки не успішний (Verified -1)

    tables data structures 9

  • UNKNOWN: процес розгортання та перевірки відбувається/не відбувався (відсутня мітка Verified)

    tables data structures 10

5.3. Реконсиляція застарілих схем тимчасових БД

При роботі з даними реєстру, для кожної версії-кандидата створюється та розгортається тимчасова репліка з еталонної бази даних (PostgreSQL). Часто це призводить до того, що гілка-кандидат може бути вже видалена, а тимчасова БД продовжує існувати та використовувати ресурси реєстру.

Для розв’язання цієї проблеми впроваджено спеціальний процес реконсиляції (reconciliation process) для періодичного видалення застарілих схем БД по версіях-кандидатах (версії-кандидати, що були інтегровані/злиті до майстер-версії, або ж такі, що видалені без інтеграції).

Reconciliation process (пайплайн cleanup-of-version-candidate-db) — це Jenkins-процес, запланований до виконання у певний час. Параметр періодичності виклику налаштовується на рівні helm-файлу конфігурації реєстру та передається на рівень тригера Jenkins-пайплайну. Значення за замовчуванням: 1 раз на добу, 17:00 GMT+2 (Київ).

Налаштувати процес можна у сервісі Jenkins вашого реєстру. Для цього:

  1. Відкрийте Jenkins-консоль у проєкті вашого реєстру.

  2. Знайдіть пайплайн cleanup-of-version-candidate-db.

  3. Відкрийте налаштування (⚙ Configure).

    tables data structures 11

  4. Перейдіть до розділу Build Triggers та задайте бажану періодичність запуску процесу. Періодичність налаштовується у форматі unix-cron.

    tables data structures 12

При виклику процесу реконсиляції здійснюється:

  • Отримання переліку версій-кандидатів у Gerrit-репозиторії.

  • Отримання переліку тимчасових БД для версій-кандидатів у базі даних.

  • Видалення тимчасових схем БД версій-кандидатів, для яких не існує відкритих запитів на внесення змін (MR) у Gerrit.

Після запуску процесу cleanup-of-version-candidate-db, система видаляє усі тимчасові БД, які не є у статусі Open у Gerrit.