Управління структурами таблиць моделі даних реєстру

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

1. Опис проблеми

Частиною процесу створення/редагування регламенту реєстру є опис моделі даних реєстру. Поточний підхід передбачає використання лише файлів конфігурації для створення моделі даних реєстру. Користувач повинен використовувати liquibase changelog формат опису моделі даних, що де-факто є описом структури БД.

Частиною web-based адмін порталу редагування версії регламенту реєстру є редагування структури БД. Необхідно розробити технічний дизайн підсистеми створення моделі даних реєстру.

1.1. Ключові пункти проблеми

  • Одночасна робота декількох користувачів з однією версією-кандидатом регламенту

  • Збереження механізму забезпечення існуючого життєвого циклу регламенту версій (gerrit, jenkins)

  • Збереження технічного інструменту відтворення структури БД (liquibase)

  • Збереження механізму зміни регламенту шляхом зміни конфігураційних файлів в git

  • Забезпечення синхронізації між змінами з адмін порталу і змінами внесеними через Gerrit

  • Створення GUI based механізму зміни регламенту реєстру

2. Базові сценарії використання

  • Створення нової версії регламенту реєстру

  • Виконання дозволені CRUD like операцій з моделлю данних, що описані нижче

  • Перегляд всієї історії змін моделі даних регламенту реєстру

  • Перегляд історії змін моделі даних регламенту реєстру всередині версії-кандидату

  • Збереження змін в моделі даних до версії-кандидату

  • Інспекція версії-кандидату регламенту реєстру

3. Out of scope

  • Робота з типами даних

  • Робота з аналітичними представленнями

  • Вирішення конфліктів з використанням адмінпорталу менеджменту регламенту реєстру

4. Принципи роботи зі змінами в БД

4.1. Існуючий механізм роботи зі змінами в БД

Існуючий механізм роботи зі змінами в БД базуєтсья на двух принципах:

  • Cтворення liquibase changeset

  • Збереження liquibase changeset в git

tables management luqibase current flow

4.2. Розширений механізм роботи зі змінами в БД

Пропонується розширити існуючий механізм роботи зі змінами БД шляхом додавання DataModelSnapshot документу в git репозиторій, котрий буде відображати стан моделі даних.

tables management luqibase extended flow

4.3. Основні концепції

  • DataModelSnapshot model - JSON документи, що відображають стан моделі даних регламенту реєстру

  • Diff Document - документ, що відображає різницю між двома станами моделі даних регламенту реєстру

  • History Document - документ, що відображає історію змін мастер версії або версії- кандидату регламенту реєстру

4.4. Описання структури DataModelSnapshot

Вищенаведена модель даних була отримана в результаті аналізу існуючого стану lqiuibase changelogs (включно з аналізом функціональності custom liquibase тегів)
db-tables-management-er

4.5. Опис структури файлів на файловій системі

DataModelSnapshot model має наступну структуру файлів на файловій системі

tables management datamodel filestructure

  • Перелік таблиць визначається переліком файлів на файловій системі

  • Ім’я файлу таблиць відповідає назві таблиці та має наступний вигляд: <table-name>.json

  • Ім’я файлу role permission відповідає назві id role permission та має наступний вигляд: <role-id>.json

4.5.1. Тимчасова структура файлів на файловій системі (first iteration)

tables management datamodel filestructure simple

4.6. Опис DataModelSnapshot формату даних

В якості технічного інструменту опису структури даних DataModelSnapshot використовується Json формат. В якості опису контракту документу використовується JsonSchema

DataModelSnapshotSchema

5. Допустимі операції з об’єктами доменної моделі

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

Допустимі операції відносно моделі даних регламенту реєстру діляться на 2 групи:

  • Обмежена можливість змін моделі даних

  • Повна можливість змін моделі даних

Об’єкти моделі даних, що не були інтегровані в мастер-версію регламенту реєстру, можуть бути змінені будь-яким чином не зважаючи на нижче вказані обмеження.

Об’єкти моделі даних, що ввійшли до master версії snapshot data model мають обмежені можливості для редагування. Таблиці, що були створені в CandidateSnapshot не мають ніяких обмежень відносно можливостей редагування.

5.1. Допустимі операції з об’єктами доменної моделі, що ввійшли в попередній реліз

Назва entity Create Update Delete

Table

Y

Y

N

Column

Y

Y

N

Index

Y

Y

Y

Constraint

Y

Y

Y

ForeignKey

Y

Y

Y

AccessRule

Y

Y

Y

6. Описання атрибутів доменної моделі

6.1. Table

Назва Тип Read only Описання

Name

string

true

HistoricalFlag

boolean

true

ObjectReference

true

Description

String

false

6.2. Column

Назва

Тип

Read only

Описання

Name

string

true

Description

string

false

Type

enum[clarify types]

true

DefaultValue

object

false

NotNull

boolean

true

Unique

boolean

true

PrimaryKey

boolean

true

6.3. Index

Назва

Тип

Read only

Описання

Name

string

true

Columns

[{ name string sorting: enum[ASC, DESC, NONE] }]

false

6.4. Constraint

Назва

Тип

Read only

Описання

Name

string

true

Columns

array[columnName]

true

6.5. ForeignKey

Назва

Тип

Read only

Описання

Name

string

true

SourceColumnName

string

true

TargetTable

string

true

TargetColumnName

string

true

6.6. AccessRule

Назва

Тип

Read only

Описання

ColumnName

string

true

Actions

enum[CREATE, READ, UPDATE, DELETE]

false

RoleNames

[roleName: string]

false

7. Загальні принципи реалізації

  • Механізм дозволяє проводити CRUD операції відносно об’єктів доменної моделі

  • Одночасне редагування регламенту реєстру як з використанням адмін порталу, так і шляхом зміни конфігураційних файлів в репозиторії регламенту

  • Стан структури БД і метаданих повністю відображений DataModelSnapshot документами

  • Структура DataModelSnapshot json документів описана за допомогою JSONSchema

  • DataModelSnapshot документи (з JSONSchema) мають бути використані як структура обміну даними на рівні RestAPI між Front-End додатком та Backend сервісами

  • Вирішення конфліктів при редагуванні регламенту реєстру з використанням адмінпорталу необхідний лише на рівні DataModelSnapshot документів

  • Підтримання консистентними DataModelSnapshot моделі та liquibase changelog

  • Процес синхронізації DataModelSnapshot моделі по liquibase changelog є ідемпотентним

  • Зміни внесені через адміністративний портал знаходяться в окремому liquibase changeset. Ідентифікатор версії-кандидату є частиною liquibase changeset id атрибуту.

8. Опис технічного рішення

8.1. Container

tables management c4 container

8.2. Admin portal API container

tables management c4 apiContainer

8.3. CICD container

tables management c4 cicd container

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

db-tables-management-sequence

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

tables management component structure