ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9681| Title: | Модуль інтеграції та міграції даних для HR-системи обліку військовозобов’язаних |
| Authors: | Оксамитна, Любов Павлівна Благовісний, Юрій Олександрович |
| Keywords: | ВІЙСЬКОВИЙ ОБЛІК;HR-СИСТЕМА;ІНТЕГРАЦІЯ ДАНИХ;МІГРАЦІЯ ДАНИХ;ВАЛІДАЦІЯ ДАНИХ;СИНХРОНІЗАЦІЯ ДАНИХ;КАДРОВІ ДАНІ;ІНФОРМАЦІЙНА СИСТЕМА. |
| Issue Date: | 10-Jun-2026 |
| Abstract: | В умовах цифровізації кадрових процесів та підвищених вимог до ведення військового обліку на підприємствах особливої актуальності набуває автоматизація інтеграції та міграції даних у HR-системах. Основною проблемою предметної області є неоднорідність джерел даних, наявність дублювань, неповноти записів і помилок форматування, що ускладнює оперативне оновлення інформації та знижує достовірність облікових даних. Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є розроблення програмного модуля інтеграції та міграції даних для HR-системи обліку військовозобов’язаних, який забезпечує коректне завантаження, перетворення, валідацію та синхронізацію інформації з різних джерел. Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. Практичне значення отриманих результатів полягає у підвищенні точності та узгодженості кадрових даних, зменшенні частки ручних операцій під час імпорту, скороченні часу на обробку інформації та покращенні якості підготовки даних для подальшого використання в HR-процесах і формуванні службових документів. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9681 |
| Appears in Collections: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Благовісний Юрій_КН-2201_2025-2026.pdf Restricted Access | 2.9 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Модуль інтеграції та міграції даних для HR-системи обліку
військовозобов’язаних»
Виконав: студент 4 курсу, групи КН-2201
Спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
Освітня програма «Комп’ютерні науки та
(назва освітньої програми)
прикладне програмування»
Юрій БЛАГОВІСНИЙ
Керівник Любов ОКСАМИТНА
(ім’я та прізвище)
Рецензент Сергій СТАСЬ
(ім’я та прізвище)
Черкаси 2026 року
2
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 122 – Комп’ютерні науки
Освітня програма Комп’ютерні науки та прикладне програмування
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2026 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Благовісному Юрію Олександровичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Модуль інтеграції та міграції даних для HR-системи обліку військовозобов’язаних
Керівник роботи Оксамитна Л.П., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «12» березня 2026 р. №56/03-03.
2. Строк подання студентом роботи « 08 » червня 2026 року
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних.
Звіт з виробничої практики. Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз предметної області та обґрунтування вимог до модуля інтеграції і міграції даних для
HR-системи обліку військовозобов’язаних.
4.2. Методи та засоби проєктування модуля інтеграції й міграції даних.
4.3. Програмна реалізація модуля інтеграції та міграції даних.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 62280-01.
5.2. Додаток Б. Текст програми.
5.3. Додаток В. Інструкція користувача.
5.4. Додаток Г. Апробація кваліфікаційної роботи бакалавра.
5.5. Презентація у вигляді 24 слайдів.
3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
консультанта завдання видав завдання прийняв
7. Дата видачі завдання 12.01.2026 р.
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи бакалавра Строк виконання
етапів роботи Примітка
1 Видача завдання на кваліфікаційну роботу
бакалавра. 12.01.2026 Виконано
2 Аналіз літературних джерел, об’єкту та предмету
дослідження. до 08.02.2026 Виконано
3 Написання теоретичного розділу кваліфікаційної
роботи бакалавра. до 23.03.2026 Виконано
4 Написання аналітичного розділу (аналіз об’єкту
й предмету дослідження). до 06.04.2026 Виконано
5 Написання практичних розділів й висновків по
роботі. до 15.05.2026 Виконано
6 Передзахист кваліфікаційної роботи бакалавра
на засіданні кафедри КНСА. 20.05.2026 Виконано
7 Подання роботи завідувачу кафедри КНСА. до 10.06.2026 Виконано
8 Захист кваліфікаційної роботи бакалавра. 10.06.2026 Виконано
Студент Юрій БЛАГОВІСНИЙ
(підпис)
Керівник роботи Любов ОКСАМИТНА
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 81 с., 20 рис., 3 таблиць, 32
використаних джерел, 4 додатки.
Актуальність теми. В умовах цифровізації кадрових процесів та підвищених
вимог до ведення військового обліку на підприємствах особливої актуальності набуває
автоматизація інтеграції та міграції даних у HR-системах. Основною проблемою
предметної області є неоднорідність джерел даних, наявність дублювань, неповноти
записів і помилок форматування, що ускладнює оперативне оновлення інформації та
знижує достовірність облікових даних.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є
розроблення програмного модуля інтеграції та міграції даних для HR-системи обліку
військовозобов’язаних, який забезпечує коректне завантаження, перетворення,
валідацію та синхронізацію інформації з різних джерел.
Завдання кваліфікаційної роботи бакалавра:
− провести системний аналіз предметної області військового обліку та вимог
до кадрових даних;
− дослідити наявні підходи до інтеграції й міграції даних у корпоративних
інформаційних системах;
− обґрунтувати архітектурні рішення модуля та визначити вимоги до його
функціональних і нефункціональних характеристик;
− розробити процедури ETL-обробки, включаючи правила очищення,
нормалізації та валідації даних;
− реалізувати механізми зіставлення полів (mapping), контролю помилок і
фіксації статусів завантаження;
− забезпечити узгоджену взаємодію модуля міграції з іншими підсистемами
HR-рішення (документообіг, сервіси перевірок, засоби доступу та аудиту);
− провести тестування працездатності реалізованого рішення та оцінити
практичні результати його застосування.
5
Об’єкт дослідження: процеси автоматизованої обробки, міграції та
синхронізації даних у корпоративних інформаційних системах управління
персоналом в умовах ведення військового обліку.
Предмет дослідження: методи, алгоритми та програмні засоби інтеграції,
валідації й міграції даних про військовозобов’язаних працівників у структурі HR-
системи.
Методи дослідження. У роботі використано методи системного аналізу
предметної області, методологію ETL (англ. Extract, Transform, Load – витягнення,
перетворення, завантаження), підходи проєктування реляційних баз даних, принципи
об’єктно-орієнтованого програмування, а також методи функціонального й
інтеграційного тестування програмного забезпечення.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л.
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.];
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.
Черкаси : ЧДТУ, 2026. С. 14.
Практичне значення отриманих результатів полягає у підвищенні точності
та узгодженості кадрових даних, зменшенні частки ручних операцій під час імпорту,
скороченні часу на обробку інформації та покращенні якості підготовки даних для
подальшого використання в HR-процесах і формуванні службових документів.
Ключові слова: ВІЙСЬКОВИЙ ОБЛІК, HR-СИСТЕМА, ІНТЕГРАЦІЯ
ДАНИХ, МІГРАЦІЯ ДАНИХ, ETL, ВАЛІДАЦІЯ ДАНИХ, СИНХРОНІЗАЦІЯ
ДАНИХ, КАДРОВІ ДАНІ, ІНФОРМАЦІЙНА СИСТЕМА, АВТОМАТИЗАЦІЯ.
ABSTRACT
The bachelor’s qualification thesis consists of: 81 pages, 19 illustrations, 3 tables,
32 references, and 4 attachments.
6
Relevance of the topic. The aim of this bachelor’s qualification thesis is to develop
a software module for data integration and migration within an HR system for military
personnel accounting, which ensures correct data loading, transformation, validation, and
synchronization across different sources.
Purpose and objectives of the research. The purpose of the bachelor's qualification
work is to develop a software module for data integration and migration for the HR system
for accounting for military personnel, which ensures the correct loading, conversion,
validation and synchronization of information from various sources.
The tasks of the bachelor's qualification work:
− conduct a systematic analysis of the subject area of military accounting and
requirements for personnel data;
− investigate existing approaches to data integration and migration in corporate
information systems;
− substantiate the architectural solutions of the module and determine the
requirements for its functional and non-functional characteristics;
− develop ETL processing procedures, including rules for cleaning, normalizing and
validating data;
− implement mechanisms for mapping fields, error control and recording download
statuses;
− ensure coordinated interaction of the migration module with other subsystems of
the HR solution (document flow, verification services, access and audit tools);
− test the functionality of the implemented solution and evaluate the practical results
of its application.
Object of study: processes of automated processing, migration and synchronization
of data in corporate information systems of personnel management in the conditions of
military accounting.
Subject of the study: methods, algorithms and software tools for integration,
validation and migration of data on military employees in the structure of the HR system.
Research Methods. The work uses methods of system analysis of the subject area,
ETL methodology (Extract, Transform, Load), approaches to designing relational databases,
7
principles of object-oriented programming, as well as methods of functional and integration
testing of software.
Approbation of the results of the work. The main provisions and results of the
bachelor's qualification work were reported and discussed at the conference "Day of Student
Science of the Department of KNSA", April 22, 2026, Cherkasy, Ukraine.
Publications. Yu. O. Blagovisny, D. R. Holub, V. V. Dubrovny, D. O. Kjernus, L. P.
Oksamytna, A. P. Sinkovskiy, V. V. Oleksiuk. Automated HR information system of a
higher education institution : Collection of abstracts from the Cherkasy State Technological
University Student Scientific and Practical Conference: 22–23 April 2026 / [edited by I. V.
Melnyk]; Ministry of Education and Science of Ukraine, Cherkasy State Technological
University. Cherkasy : Cherkasy State Technological University, 2026. p. 14.
The practical significance of the results obtained is to increase the accuracy and
consistency of personnel data, reduce the share of manual operations during import, reduce
the time for information processing and improve the quality of data preparation for further
use in HR processes and the formation of official documents.
Keywords: MILITARY ACCOUNTING, HR SYSTEM, DATA INTEGRATION,
DATA MIGRATION, ETL, DATA VALIDATION, DATA SYNCHRONIZATION,
PERSONNEL DATA, INFORMATION SYSTEM, AUTOMATION.
8
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ….. 10
ВСТУП ............................................................................................................................ 11
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОБҐРУНТУВАННЯ ВИМОГ ДО 15
МОДУЛЯ ІНТЕГРАЦІЇ І МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ ОБЛІКУ…..
1.1 Предметна область військового обліку в HR-системах……………………. 15
1.2 Аналіз існуючих підходів до інтеграції та міграції даних у HR-системах... 19
1.3 Постановка проблеми та обґрунтування вимог до модуля інтеграції і
міграції даних………………………………………………………………… 21
Висновки до розділу 1…………………………………………………………........ 24
2 МЕТОДИ ТА ЗАСОБИ ПРОЄКТУВАННЯ МОДУЛЯ ІНТЕГРАЦІЇ Й
МІГРАЦІЇ ДАНИХ………………………………………………………………..... 26
2.1 Вибір та обґрунтування методів вирішення проблеми……………………. 26
2.2 Вибір та обґрунтування засобів вирішення проблеми…………………....... 29
2.3 Опис алгоритмів, застосованих у модулі…………………………………… 32
Висновки до розділу 2…………………………………………………………........ 40
3 ПРОГРАМНА РЕАЛІЗАЦІЯ МОДУЛЯ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ
ДАНИХ……………………………………………………………………………… 41
3.1 Реалізація структури бази даних та модуля імпорту даних із файлів XLS 41
3.1.1 Фізична модель бази даних…………………………………………... 41
3.1.2 Програмна реалізація сервісу імпорту……………………………..... 42
3.1.3 Реалізація ланцюга нормалізації та лексичного аналізу……………. 44
3.2 Реалізація модуля пакетної міграції даних із зовнішнього джерела………. 45
3.2.1 Програмна реалізація HTTP-клієнта зовнішньої системи………..... 45
3.2.2 Програмна реалізація сервісу міграції………………………………. 46
3.2.3 Конфігурація мережевої взаємодії…………………………………... 47
3.3 Реалізація модуля експорту даних у формат XLSX………………………... 48
3.3.1 Архітектура процесу експорту……………………………………..... 48
3.3.2 Фільтрація та сортування записів……………………………………. 49
9
3.3.3 Алгоритм заповнення шаблону……………………………………… 50
3.4 Результати тестування та апробації модуля………………………………... 52
3.4.1 Методика тестування……………………………………………….... 52
3.4.2 Результати тестування модуля імпорту……………………………... 52
3.4.3 Результати тестування модуля міграції……………………………... 54
Висновки до розділу 3……………………………………………………………… 54
ВИСНОВКИ…………………………………………………………………………….. 56
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ……………………………………………..... 58
ДОДАТОК А. Специфікація 482.ЧДТУ.62280-01…………………………………..... 62
ДОДАТОК Б. Текст програми………………………………………………………..... 64
ДОДАТОК В. Інструкція користувача………………………………………………... 74
ДОДАТОК Г. Апробація кваліфікаційної роботи бакалавра………………………… 78
10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
ПЗ – програмне забезпечення;
РНОКПП – реєстраційний номер облікової картки платника податків;
externalId – зовнішній ідентифікатор запису;
thread pool – пул потоків;
finite state machine – скінченний автомат;
БД – бази даних;
СКБД – система керування базами даних;
DTO – об'єкт передачі даних;
ETL – видобування, перетворення та завантаження даних;
JPA – специфікація технології збереження даних у мові Java;
JSON – текстовий формат обміну даними;
ORM – об'єктно-реляційне відображення;
REST – архітектурний стиль для розподілених гіпермедіа-систем;
SQL – мова структурованих запитів;
XLSX – формат файлів електронних таблиць.
11
ВСТУП
В умовах воєнного стану, посилення вимог до ведення військового обліку та
одночасної цифрової трансформації підприємств, питання якості кадрових даних
набуває стратегічного значення. Для роботодавця критично важливо не лише
зберігати відомості про працівників, а й забезпечувати їх своєчасне оновлення,
цілісність, юридичну коректність і доступність для формування регламентованої
звітності. Традиційні підходи, за яких дані вводяться вручну або передаються між
підсистемами у напівавтоматичному режимі, породжують дублювання записів,
втрати актуальності, помилки форматів і невідповідність нормативним вимогам [1].
У результаті зростають операційні ризики, витрати часу фахівців HR-відділів і
ймовірність порушень під час перевірок.
Актуальність теми. Актуальність теми кваліфікаційної роботи бакалавра
«Модуль інтеграції та міграції даних для HR-системи обліку військовозобов’язаних»
зумовлена необхідністю створення надійного програмного компонента, який
забезпечує контрольоване завантаження, перетворення, валідацію та синхронізацію
даних із різних джерел у єдиному інформаційному середовищі. Для сучасної HR-
системи недостатньо виконувати лише функцію зберігання даних: вона має
підтримувати наскрізні бізнес-процеси, пов’язані з імпортом кадрової інформації,
міграцією історичних записів, формуванням службових документів, керуванням
доступом, простежуваністю змін і аудитом. Саме тому в роботі основний акцент
зроблено на модулі інтеграції та міграції, але також враховано його взаємодію з
іншими функціональними підсистемами.
Сучасний стан проблеми свідчить, що найбільші труднощі в HR-інформаційних
системах виникають на стику неоднорідних даних і різних форматів обміну. На
практиці одночасно використовуються електронні таблиці, локальні бази даних,
зовнішні API, файлові шаблони документів і ручні виправлення оператором. За
відсутності формалізованих процедур ETL (англ. Extract, Transform, Load –
витягнення, перетворення, завантаження) та єдиних правил валідації з’являються
колізії між записами [2], порушується унікальність і повнота даних, а також
12
ускладнюється побудова достовірної аналітики. Окремою проблемою є необхідність
дотримання вимог інформаційної безпеки та розмежування доступу під час обробки
персональних даних військовозобов’язаних.
Світовий досвід підтверджує [3], що розвиток HR-рішень рухається в напрямі
платформності, API-first інтеграцій, автоматизованих конвеєрів обробки даних і
подієво-орієнтованих механізмів синхронізації. Провідні корпоративні платформи
(зокрема, SAP SuccessFactors, Workday, Oracle HCM, Microsoft) реалізують концепцію
єдиного джерела істини [4], де якість даних забезпечується стандартизованими
правилами трансформації, багаторівневою валідацією та аудитом змін. Для
прикладних систем національного рівня важливо адаптувати ці підходи до локальної
нормативної бази, специфіки документообігу та організаційних процесів
підприємств.
Теоретичне підґрунтя дослідження спирається на підходи системного аналізу,
моделювання інформаційних систем, проєктування баз даних і методологію ETL. У
роботі враховано ідеї структурованого аналізу предметної області, об’єктно-
орієнтованого проєктування, принципів побудови надійних серверних застосунків і
практик забезпечення узгодженості даних у багатокомпонентних системах. Це
дозволяє сформувати методично обґрунтовану модель модуля міграції, в якій
поєднуються архітектурна цілісність, масштабованість і практична придатність до
впровадження.
Зв’язок роботи з науковими програмами, планами і темами кафедри
комп’ютерних наук та системного аналізу (КНСА) визначається її спрямованістю на
розроблення прикладного програмного забезпечення в галузі комп’ютерних наук,
автоматизацію бізнес-процесів та підвищення якості обробки даних у корпоративних
інформаційних системах. Результати дослідження узгоджуються з тематикою
науково-дослідних робіт кафедри КНСА, що стосуються проєктування
інформаційних систем, інтеграції програмних компонентів і застосування сучасних
технологій обробки даних.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є
розроблення програмного модуля інтеграції та міграції даних для HR-системи обліку
13
військовозобов’язаних, який забезпечує коректне завантаження, перетворення,
валідацію та синхронізацію інформації з різних джерел.
Для досягнення поставленої мети в роботі розв’язуються такі завдання:
− провести системний аналіз предметної області військового обліку та вимог
до кадрових даних;
− дослідити наявні підходи до інтеграції й міграції даних у корпоративних
інформаційних системах;
− обґрунтувати архітектурні рішення модуля та визначити вимоги до його
функціональних і нефункціональних характеристик;
− розробити процедури ETL-обробки, включаючи правила очищення,
нормалізації та валідації даних;
− реалізувати механізми зіставлення полів (mapping), контролю помилок і
фіксації статусів завантаження;
− забезпечити узгоджену взаємодію модуля міграції з іншими підсистемами
HR-рішення (документообіг, сервіси перевірок, засоби доступу та аудиту);
− провести тестування працездатності реалізованого рішення та оцінити
практичні результати його застосування.
Об’єкт дослідження: процеси автоматизованої обробки, міграції та
синхронізації даних у корпоративних інформаційних системах управління
персоналом в умовах ведення військового обліку.
Предмет дослідження: методи, алгоритми та програмні засоби інтеграції,
валідації й міграції даних про військовозобов’язаних працівників у структурі HR-
системи.
Методи дослідження. У роботі використано методи системного аналізу
предметної області, методологію ETL (англ. Extract, Transform, Load – витягнення,
перетворення, завантаження), підходи проєктування реляційних баз даних, принципи
об’єктно-орієнтованого програмування, а також методи функціонального й
інтеграційного тестування програмного забезпечення.
14
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович)
«Інформаційна автоматизована HR-система закладу вищої освіти» в День
студентської науки кафедри КНСА посів 1 місце.
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л.
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.];
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.
Черкаси : ЧДТУ, 2026. С. 14.
Практичне значення отриманих результатів полягає у підвищенні точності
та узгодженості кадрових даних, зменшенні частки ручних операцій під час імпорту,
скороченні часу на обробку інформації та покращенні якості підготовки даних для
подальшого використання в HR-процесах і формуванні службових документів.
Використання модуля сприяє підвищенню прозорості процесів, відтворюваності
результатів і керованості змін у критично важливих кадрових даних.
15
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОБҐРУНТУВАННЯ ВИМОГ ДО
МОДУЛЯ ІНТЕГРАЦІЇ І МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ
1.1 Предметна область військового обліку в HR-системах
У сучасних умовах розвитку корпоративних інформаційних систем кадровий
облік перестав бути суто внутрішньою адміністративною функцією та перетворився
на важливу складову управління підприємством. Для організацій, які ведуть облік
працівників, що підлягають військовому обліку, особливого значення набувають
своєчасність оновлення даних, їхня повнота, узгодженість та можливість формування
достовірної службової документації [5]. Відповідно, HR-система має забезпечувати
не лише зберігання інформації, а й підтримку процесів її перевірки, синхронізації та
актуалізації.
Предметна область даного дослідження охоплює процеси інтеграції й міграції
кадрових та військово-облікових даних у межах HR-системи підприємства. До таких
даних належать: ідентифікаційні відомості про працівника, контактні дані, службова
інформація, а також структуровані поля, необхідні для ведення військового обліку та
подальшого формування відповідних документів. Практика експлуатації HR-рішень
показує, що ці дані, як правило, надходять із кількох джерел: електронних таблиць,
внутрішніх реєстрів, архівних баз, а також із зовнішніх сервісів обміну інформацією
[6]. Така багатоджерельність створює технічні та організаційні ускладнення під час
обробки.
Ключовою особливістю предметної області є неоднорідність структури вхідних
даних [7]. Різні джерела можуть використовувати відмінні формати полів, різні
правила заповнення обов’язкових реквізитів, несумісні довідники значень,
відмінності в кодуванні, стилі запису дат і текстових полів. Унаслідок цього навіть
формально однакові записи можуть бути логічно неузгодженими. Додатковою
проблемою є дублювання записів, наявність пропусків у критичних атрибутах та
поява застарілої інформації, яка не була вчасно оновлена. За відсутності
централізованих правил перевірки це призводить до накопичення помилок у БД.
Загальну структуру предметної області, основні джерела даних та потоки їх
16
обробки в межах HR-системи наведено на рисунку 1.1.
Рисунок 1.1 – Контекстна схема предметної області військового обліку в
HR-системі
На практиці обробка таких даних часто виконується у напівручному режимі:
оператори імпортують файли, вручну зіставляють поля, виправляють помилки,
повторно перевіряють результати, після чого оновлюють записи у системі. Подібний
підхід має низку недоліків: високу трудомісткість, залежність від кваліфікації
конкретного працівника, складність відтворення результату, низьку масштабованість
та підвищений ризик людської помилки. У разі збільшення обсягу даних або частоти
оновлень ці недоліки посилюються, що негативно впливає на якість кадрового обліку
в цілому.
З точки зору системного аналізу, в межах даної предметної області доцільно
виокремити такі базові процеси:
− отримання даних із зовнішніх та внутрішніх джерел;
− первинна перевірка структури і повноти записів;
− зіставлення полів джерела з цільовою моделлю даних;
− логічна валідація та очищення помилкових значень;
17
− усунення дублікатів та узгодження конфліктних записів;
− завантаження коректних даних до цільової бази;
− фіксація результатів обробки в журналі подій та помилок.
Саме ці процеси формують функціональне ядро модуля інтеграції та міграції
даних. Наявність такого модуля у складі HR-системи дає змогу перейти від
фрагментованої ручної обробки до контрольованого й повторюваного циклу роботи з
даними. Це забезпечує підвищення достовірності облікової інформації, скорочення
часу на її підготовку та зменшення кількості операцій, що залежать від людського
фактора.
Окремо слід зазначити, що для предметної області військового обліку
важливими є не лише технічні аспекти збереження записів, а й прозорість процедур
їхньої обробки. Кожен етап міграції має бути відтворюваним і контрольованим:
система повинна надавати інформацію про те, які дані були завантажені, які
відхилені, з яких причин виникли помилки та які дії необхідні для їх усунення. Такий
підхід підвищує керованість процесу та створює основу для подальшого
вдосконалення інформаційної системи.
Отже, предметна область дослідження характеризується високими вимогами до
якості даних, складністю інтеграції різнорідних джерел і потребою в
автоматизованому механізмі міграції. Це обґрунтовує необхідність розроблення
спеціалізованого модуля інтеграції та міграції даних для HR-системи обліку
військовозобов’язаних, який забезпечує цілісність, узгодженість та актуальність
інформації.
Для вирішення вказаних завдань у межах колективного проєкту було
спроєктовано комплексну структуру, що об'єднує розробки чотирьох авторів у єдину
екосистему. Взаємозв'язок функціональних модулів загальної HR-системи
військового обліку ЗВО наведено на рисунку 1.2.
18
Рисунок 1.2 – Схема взаємозв'язку функціональних модулів у складі комплексної
HR-системи військового обліку
Як показано на рисунку 1.2, архітектура системи базується на чіткому розподілі
обов'язків між підсистемами:
− Модуль контролю доступу та безпеки (Модуль 4) забезпечує наскрізний
захист інформаційного контуру, здійснює автентифікацію користувачів та аудит
операцій;
− Модуль інтеграції та міграції даних (Модуль 1) реалізує процеси
завантаження первинних масивів інформації з зовнішніх систем та файлів типу XLSX;
− Модуль обліку військовозобов'язаних (Модуль 2) виступає центральним
сховищем (ядром) системи, де зберігаються картки обліку;
− Модуль формування довідок та звітів (Модуль 3) опрацьовує накопичені дані
для генерації регламентованих вихідних документів.
19
1.2 Аналіз існуючих підходів до інтеграції та міграції даних у HR-системах
Інтеграція та міграція даних у кадрових інформаційних системах є критичними
процесами, від яких безпосередньо залежить достовірність облікової інформації,
швидкість оновлення записів і якість подальшого документообігу. Для систем, що
підтримують облік військовозобов’язаних працівників, ці вимоги додатково
посилюються через необхідність узгодженості персональних і службових відомостей,
а також своєчасної актуалізації даних із різних джерел.
У сучасній практиці можна виокремити три основні підходи до організації
процесів міграції даних: ручний, напівавтоматизований та автоматизований ETL-
підхід [10].
Ручний підхід передбачає перенесення або оновлення записів безпосередньо
оператором: через інтерфейс системи, шляхом копіювання з табличних файлів або
через локальні форми вводу. Перевагою такого підходу є мінімальний поріг входу та
відсутність потреби у складній технічній інфраструктурі на початковому етапі.
Водночас цей підхід має суттєві обмеження: високу трудомісткість, значну
залежність від людського фактора, складність контролю помилок і практичну
неможливість масштабування при великих обсягах даних. Крім того, ручні операції
ускладнюють аудит процесу, оскільки не завжди забезпечують повну
простежуваність змін.
Напівавтоматизований підхід базується на використанні шаблонів імпорту,
локальних скриптів і частково формалізованих процедур перевірки. У цьому випадку
частина рутинних дій автоматизується: парсинг структури файлу, базове зіставлення
полів, первинне завантаження до системи. Це знижує навантаження на оператора та
пришвидшує обробку порівняно з повністю ручним режимом. Однак, за відсутності
єдиного керованого контуру міграції залишаються проблеми з уніфікацією правил
трансформації, контролем конфліктних записів, повторюваністю результатів і
супроводом рішення при зміні формату вхідних даних.
Автоматизований ETL-підхід передбачає побудову керованого процесу,
загальну схему якого наведено на рисунку 1.2 і в межах якого дані проходять
20
послідовні стадії отримання, перетворення та завантаження. На етапі Extract
відбувається підключення до визначених джерел і вилучення первинних наборів
даних. На етапі Transform виконуються структурне зіставлення (mapping) [8],
валідація обов’язкових атрибутів, нормалізація форматів, очищення аномальних
значень, виявлення дублікатів і логічний контроль взаємозалежних полів. На етапі
Load до цільової бази потрапляють лише узгоджені й перевірені записи, а результати
обробки фіксуються в журналах подій та помилок.
Рисунок 1.3 – Схема ETL-процесу модуля інтеграції та міграції даних
Для предметної області військового обліку найбільш значущими
характеристиками підходу є:
– керованість і відтворюваність процесу міграції;
– централізований контроль якості даних;
– прозора обробка помилок із можливістю повторного запуску;
– масштабованість при збільшенні обсягів інформації;
– простежуваність усіх етапів перетворення даних.
Порівняння підходів за критеріями точності, швидкості, масштабованості,
контрольованості та аудиту показує, що ручний режим доцільний лише для
поодиноких операцій і малих обсягів, напівавтоматизований – для перехідних
сценаріїв, а ETL-підхід – для стабільної промислової експлуатації [9]. З огляду на
21
характер задачі, де важливими є регулярність оновлень, узгодженість реквізитів і
мінімізація помилок, саме ETL-підхід є найбільш обґрунтованим.
Важливою складовою такого підходу є конфігурований шар mapping, який
забезпечує гнучке зіставлення полів джерел із цільовою моделлю без повного
переписування логіки імпорту. Це особливо актуально у випадках, коли структура
вхідних файлів змінюється, а бізнес-процес потребує швидкої адаптації. Наявність
формалізованих правил mapping у поєднанні з валідаційними механізмами підвищує
надійність міграції й зменшує кількість інцидентів під час експлуатації.
Таким чином, аналітичний огляд існуючих підходів підтверджує доцільність
реалізації модуля інтеграції та міграції даних у вигляді автоматизованого ETL-
компонента. Такий компонент забезпечує системний підхід до обробки даних, знижує
частку ручних операцій, покращує якість інформації в HR-системі та створює
технологічну основу для подальшого розширення функціональності.
1.3 Постановка проблеми та обґрунтування вимог до модуля інтеграції і
міграції даних
Проведений в попередніх підрозділах аналіз показав, що ключова практична
проблема ведення обліку військовозобов’язаних у HR-системах полягає не у
відсутності даних як таких, а у відсутності керованого та відтворюваного механізму
їх узгодження. У робочому контурі підприємства відомості про працівників
надходять із різнорідних джерел, відрізняються за структурою, мають різну повноту
та форматну якість, а також містять дублікати й суперечливі значення. За таких умов
ручні або фрагментарно автоматизовані процедури не забезпечують стабільної якості
результату, а похибки накопичуються на кожному циклі оновлення.
Проблема має системний характер і проявляється одночасно у кількох вимірах:
організаційному, інформаційному та технологічному [10]. В організаційному вимірі
зростає навантаження на HR-персонал через необхідність повторних перевірок і
ручного виправлення записів. В інформаційному вимірі погіршуються цілісність,
актуальність і достовірність кадрових даних. У технологічному вимірі виникає розрив
між джерелами вхідної інформації та цільовою моделлю даних HR-системи, що
22
унеможливлює прогнозований результат під час повторних імпортів. Наслідком є
ризики помилок у службовій документації, затримки в операційній роботі та
зниження керованості процесу обліку.
Отже, постановка задачі полягає в розробленні спеціалізованого програмного
модуля інтеграції і міграції даних, який забезпечує автоматизований цикл ETL-
обробки для кадрової інформації військового обліку. Модуль повинен приймати
вхідні набори даних, виконувати структурне зіставлення полів із цільовою моделлю,
проводити форматну та логічну валідацію, обробляти дублікати, фіксувати
результати обробки й завантажувати до системи лише коректні записи.
У формалізованому вигляді задачу можна подати як перетворення вхідного
набору S у погоджений цільовий набір R:
R = L(D(V(T(E(S))))), (1.1)
де R – погоджений цільовий набір даних;
L – операція завантаження в цільову базу даних (Load);
D – алгоритм дедуплікації та усунення колізій (Deduplication);
V – процедура валідації та перевірки цілісності (Validation);
T – функція перетворення та нормалізації (Transform);
E – операція вилучення даних (Extract);
S – вхідний набір даних із різнорідних джерел.
Цільовий стан процесу полягає у мінімізації кількості помилок та часу обробки
за умови дотримання встановлених порогів якості:
min (��������1��������)1,���� ≥ ����������������1 ,���� ≥ ����������������, (1.2)
де �������� – кількість помилок у вихідному наборі даних;
�������� – загальний час обробки інформаційного пакету;
C – розрахований показник повноти даних;
���������������� – встановлений мінімально допустимий поріг повноти;
U – розрахований показник узгодженості даних;
���������������� – встановлений мінімально допустимий поріг узгодженості.
23
Виходячи з постановки проблеми, до модуля формулюються такі функціональні
вимоги:
– забезпечити імпорт даних із визначених форматів джерел із контролем типу
файлу та базової структури вхідного набору;
– реалізувати механізм зіставлення полів джерела з атрибутами цільової HR-
моделі, включаючи обробку відсутніх і надлишкових колонок;
– виконувати валідацію обов’язкових реквізитів, форматів дат,
ідентифікаційних полів і логічної узгодженості взаємопов’язаних атрибутів;
– підтримувати очищення даних і нормалізацію значень (уніфікація
представлення текстових, числових і датованих полів);
– забезпечити виявлення дублікатів і вибір стратегії обробки конфліктних
записів (створення нового, оновлення існуючого, пропуск із фіксацією причини);
– формувати результат імпорту зі статусами обробки (створено, оновлено,
пропущено, помилка) та агрегованими лічильниками;
– вести журнал помилок і подій обробки з можливістю аудиту та подальшого
аналізу причин відхилення записів;
– підтримувати запуск міграції як окремого керованого сценарію синхронізації
з зовнішніми джерелами;
– забезпечити взаємодію з іншими компонентами HR-системи, зокрема з
підсистемою формування документів, яка використовує актуалізовані дані.
Крім функціональних, визначаються нефункціональні вимоги, що прямо
впливають на придатність рішення до експлуатації [11]:
– надійність: модуль має коректно обробляти часткові збої без втрати вже
валідно завантажених даних;
– відтворюваність: повторний запуск на однаковому наборі даних має давати
передбачуваний результат за незмінних правил обробки;
– продуктивність: час обробки повинен бути прийнятним для регламентних
операцій HR-підрозділу та масштабуватися зі зростанням обсягу даних;
– безпека: обробка персональних даних має виконуватися з урахуванням
розмежування доступу та контрольованого журналювання дій [12];
24
– спостережуваність: система повинна надавати достатню діагностичну
інформацію для аналізу помилок і контролю якості міграції;
– розширюваність: правила mapping і валідації мають адаптуватися до змін у
форматах вхідних джерел без повного перепроєктування модуля;
– супроводжуваність: архітектура рішення повинна забезпечувати локалізацію
змін і можливість поетапного розвитку функціоналу.
Для практичної верифікації доцільно також зафіксувати критерії приймання
модуля.
По-перше, кожен запуск має повертати формалізований підсумок обробки із
прозорими показниками якості.
По-друге, усі відхилені записи повинні мати однозначну причину відмови.
По-третє, механізм дедуплікації повинен запобігати неконтрольованому
множенню записів під час повторних імпортів.
По-четверте, результати міграції мають бути придатними для подальшого
автоматизованого формування кадрових документів без додаткового ручного
«доочищення» масиву даних.
Таким чином, у підрозділі сформульовано прикладну науково-технічну задачу:
створення модуля інтеграції і міграції даних як керованого ETL-компонента в складі
HR-системи обліку військовозобов’язаних. Запропонована система вимог визначає
межі та критерії проєктування рішення, а також створює основу для подальшого
обґрунтування архітектури, алгоритмів і програмної реалізації в наступних розділах
роботи.
Висновки до розділу 1
У першому розділі виконано аналіз предметної області обліку
військовозобов’язаних у складі HR-системи та встановлено, що ключовим фактором
ефективності є якість і узгодженість кадрових даних. Визначено, що в практичних
умовах інформація надходить із різнорідних джерел, має відмінні формати
представлення та нерідко містить дублікати, пропуски і логічні суперечності, що
ускладнює її подальше використання в кадрових процесах і документообігу.
25
Проведений порівняльний аналіз підходів до інтеграції та міграції даних
(ручного, напівавтоматизованого та автоматизованого) підтвердив, що для задачі, яка
розглядається, найбільш доцільним є автоматизований ETL-підхід. Його перевагами
є відтворюваність процедур, централізований контроль якості, прозора обробка
помилок, краща масштабованість і можливість аудиту результатів обробки.
На основі результатів аналізу сформульовано постановку задачі: розробити
модуль інтеграції і міграції даних, який забезпечує керований цикл завантаження,
трансформації, валідації, дедуплікації та синхронізації відомостей про працівників,
що підлягають військовому обліку.
Обґрунтовано, що впровадження такого модуля дає змогу зменшити частку
ручних операцій, підвищити достовірність і актуальність даних, а також знизити
операційні ризики під час ведення обліку.
Визначено систему вимог до майбутнього рішення: функціональні вимоги
(імпорт, mapping, валідація, обробка дублікатів, журналювання, формування статусів
обробки, підтримка міграційних сценаріїв) і нефункціональні вимоги (надійність,
продуктивність, безпека, спостережуваність, розширюваність, супроводжуваність).
Сформована сукупність вимог є достатньою методичною основою для переходу
до проєктування архітектури, вибору технологічних засобів і подальшої програмної
реалізації модуля в наступних розділах роботи.
26
2 МЕТОДИ ТА ЗАСОБИ ПРОЄКТУВАННЯ МОДУЛЯ ІНТЕГРАЦІЇ Й
МІГРАЦІЇ ДАНИХ
У попередньому розділі сформульовано систему функціональних та
нефункціональних вимог до модуля інтеграції й міграції даних для HR-системи обліку
військовозобов'язаних. Визначено, що модуль має забезпечувати керований цикл
ETL-обробки, стратегію дедуплікації, журналювання результатів та взаємодію з
іншими підсистемами.
Обґрунтуємо вибір конкретних методів та програмних засобів, що дозволяють
реалізувати зазначені вимоги, а також наведено формальний опис алгоритмів,
покладених в основу трьох ключових процесів модуля: імпорту, міграції та генерації
документів.
2.1 Вибір та обґрунтування методів вирішення проблеми
Для розв'язання задачі інтеграції, обробки та перенесення масивів кадрової
інформації про військовозобов'язаних у роботі обґрунтовано застосування
методології ETL. Відповідно до цього підходу, процес обробки даних розділено на
три логічно відокремлені етапи: отримання сирих даних із різнорідних джерел, їх
нормалізацію та безпосереднє збереження у реляційну базу даних HR-системи. Чітке
розмежування етапів забезпечує можливість незалежного тестування кожного з них,
спрощує локалізацію помилок і підвищує повторюваність результатів обробки.
Як альтернативний підхід розглядалася методологія ELT, за якою дані спочатку
завантажуються до цільового сховища у сирому вигляді, а трансформація
виконується вже засобами бази даних [9]. Цей підхід було відхилено з кількох причин.
По-перше, вхідні дані про військовозобов'язаних часто містять неструктуровані
текстові поля (наприклад, паспортні реквізити, записані в довільній формі),
потрапляння яких до цільової бази без попередньої нормалізації є неприпустимим для
задач формування регламентованої звітності.
По-друге, виконання складних регулярних виразів та правил розбору тексту
ефективніше реалізується засобами мови програмування загального призначення, ніж
27
процедурами SQL.
Загальну архітектуру модуля інтеграції та міграції даних, що відображає
взаємодію основних компонентів системи відповідно до обраного ETL-підходу,
наведено на рисунку 2.1.
Рисунок 2.1 – Компонентна діаграма архітектури модуля інтеграції та міграції
даних
Етап перетворення даних (Transform) у модулі побудовано на основі підходу,
що керується правилами (англ. rule-based approach) [13]. Суть методу полягає в
застосуванні набору формалізованих правил трансформації до кожного вхідного
запису. Оскільки вхідні відомості, такі як паспортні дані чи адреси реєстрації, часто
надходять у вигляді суцільного неструктурованого тексту, в роботі застосовано
методи лексичного аналізу за допомогою регулярних виразів [14] та пошуку заданих
шаблонів (патернів). Такий метод забезпечує детерміноване розбиття єдиного
текстового рядка, що містить серію, номер, орган видачі та дату документа, на окремі
атомарні атрибути цільової моделі даних. Це дозволяє уніфікувати структуру даних
незалежно від форми їх початкового введення оператором.
Правила трансформації організовано у вигляді ланцюга спеціалізованих
обробників (парсерів), кожний з яких відповідає за конкретний тип даних: парсер
28
паспортних реквізитів, парсер військово-облікових документів, розділювач адресних
рядків тощо. Такий підхід дозволяє додавати нові правила обробки без модифікації
існуючих компонентів, що відповідає принципу відкритості-закритості (англ. Open-
Closed Principle) [15].
Для усунення проблеми виникнення подвійних записів під час багаторазових
сеансів імпорту або синхронізації, застосовано стратегію дедуплікації через операцію
створення або оновлення (англ. create-or-update, також відому як upsert) [16]. Метод
полягає у використанні унікальних ідентифікаторів, як первинного ключа для
пошуку: для модуля імпорту таким ключем є реєстраційний номер облікової картки
платника податків (РНОКПП), а для модуля міграції – зовнішній ідентифікатор запису
(externalId). Якщо запис із відповідним ідентифікатором уже наявний у базі даних, то
відбувається оновлення його полів актуальними значеннями; інакше створюється
новий запис. Це гарантує ідемпотентність процесу: повторний запуск імпорту на тому
самому наборі даних не призводить до появи дублікатів.
На рисунку 2.2 наведено схему взаємодії потоків під час пакетної міграції.
Рисунок 2.2 – Схема паралельної пакетної обробки даних під час міграції
Отримання великих обсягів інформації із зовнішніх систем (міграцію)
29
організовано за методом пакетної обробки з можливістю паралельного виконання
[17]. На відміну від послідовного завантаження всіх записів одним запитом, що може
спричинити вичерпання ресурсів оперативної пам'яті сервера або тайм-аут
мережевого з'єднання, масив розбивається на пакети фіксованого розміру. Кожен
пакет обробляється в окремому потоці виконання пулу потоків (англ. thread pool).
2.2 Вибір та обґрунтування засобів вирішення проблеми
При виборі програмних засобів для реалізації модуля враховувалися вимоги
щодо високої надійності, типобезпеки, вбудованої підтримки транзакційної обробки
та безпеки обробки персональних даних військовозобов'язаних.
Серверну частину модуля реалізовано мовою Java (версія 23) із використанням
фреймворку Spring Boot (версія 3.3) [18].
Вибір цього стеку зумовлено кількома факторами.
По-перше, Spring Boot надає вбудований механізм інверсії управління (англ.
Inversion of Control, IoC) та ін'єкції залежностей (англ. Dependency Injection), що
дозволяє організувати модульну архітектуру застосунку із мінімальною зв'язаністю
між компонентами [19].
По-друге, Spring надає декларативне управління транзакціями через анотацію
@Transactional, що є критично важливим для забезпечення атомарності операцій
збереження пакетів записів під час імпорту [20].
По-третє, архітектура Spring MVC (Model-View-Controller) забезпечує
побудову REST API інтерфейсу для взаємодії з клієнтським застосунком за
стандартом HTTP [21].
Розглянемо систему керування базами даних (СКБД). У якості СКБД обрано
PostgreSQL (версія 16) [22]. Ця система забезпечує строгу типізацію полів, підтримку
формату JSONB для зберігання проміжних параметрів генерації документів (payload
задачі), а також гарантує відповідність вимогам ACID (атомарність, узгодженість,
ізольованість, довговічність), що є обов'язковою умовою для збереження цілісності
кадрових даних. Доступ до бази даних реалізовано через рівень об'єктно-реляційного
відображення (ORM) на основі специфікації JPA (Java Persistence API) та її реалізації
30
Hibernate [23]. Це дозволяє оперувати сутностями предметної області як об'єктами
мови Java, а не SQL-запитами, що підвищує читабельність та супроводжуваність
коду.
Клієнтську частину системи реалізовано у вигляді настільного (desktop)
застосунку з використанням технології Kotlin Multiplatform та декларативного
фреймворку Compose for Desktop [24]. Вибір настільної архітектури, на противагу
веб-клієнту, зумовлений кількома причинами:
− дані військового обліку є конфіденційними і не повинні оброблятися у
середовищі браузера, де існує ризик перехоплення інформації неверифікованими
розширеннями або через вразливості XSS [25];
− настільний клієнт забезпечує безперешкодний доступ до локальної файлової
системи робочої станції HR-фахівця для збереження згенерованих документів
формату XLSX без додаткових дозволів;
− застосунок може функціонувати в ізольованому від глобальної мережі
корпоративному середовищі підприємства.
Для роботи зі структурованими даними в форматі XLSX використано дві
спеціалізовані бібліотеки, кожна з яких обрана для конкретного сценарію.
Порівняльну характеристику засобів вирішення проблеми наведено в таблиці 2.1.
Таблиця 2.1 – Порівняльна характеристика засобів вирішення проблеми
Критерій Apache POI [26] JExcelAPI Poiji [27]
Підтримка формату
.xlsx (OOXML) Так Ні Так (на базі POI)
Анотаційний маппінг
у Java-об'єкти Ні Ні Так
Програмне
створення/модифікація Так Обмежено Ні
файлів
Копіювання стилів із
шаблону Так Ні Ні
Обсяг шаблонного
коду для читання Значний Середній Мінімальний
Бібліотеку Poiji застосовано для реалізації модуля імпорту. Засіб реалізує
31
механізм автоматичного відображення (англ. mapping) комірок файлу XLSX
безпосередньо у поля об'єктів Java через анотації, що суттєво зменшує кількість
шаблонного коду та ризик помилок при зчитуванні структури вхідного файлу.
Бібліотеку Apache POI використано для генерації вихідних файлів експорту та
шаблонних документів. Цей засіб дозволяє програмно завантажувати попередньо
оформлені шаблони, копіювати стилі комірок та заповнювати їх нормалізованими
даними військовозобов'язаних, зберігаючи оригінальне форматування документа.
Засоби мережевої взаємодії та міграції. Взаємодію модуля пакетної міграції із
зовнішнім API реалізовано за допомогою компонента Spring WebClient [28]. На
відміну від застарілого RestTemplate, WebClient забезпечує асинхронну, неблокуючу
модель взаємодії та дозволяє налаштувати тайм-аути з'єднання й зчитування на рівні
мережевого стеку через бібліотеку Netty. Конфігурація клієнта включає три рівні
захисту від мережевих збоїв: тайм-аут встановлення з'єднання (connect timeout), тайм-
аут зчитування відповіді (read timeout) та загальний ліміт часу відповіді (response
timeout). Це є критично важливим для стабільної роботи системи під час міграції
тисяч записів із зовнішнього джерела.
Допоміжні засоби розроблення. Для зменшення обсягу шаблонного коду
застосовано бібліотеку Lombok [29], яка генерує типовий код на етапі компіляції
через анотації (@RequiredArgsConstructor, @Getter, @Setter, @Slf4j). Для
журналювання подій обробки використано фасад SLF4J із реалізацією Logback [30],
що дозволяє фіксувати хід виконання імпорту та міграції на рівні окремих пакетів і
рядків. Контейнеризацію серверної частини та бази даних виконано засобами Docker
та Docker Compose [31], що забезпечує відтворюваність середовища розгортання.
Загальну структуру програмних засобів та їх взаємозв'язки в складі модуля
наведено на рисунку 2.4.
32
Рисунок 2.4 – Діаграма залежностей програмних засобів модуля
2.3 Опис алгоритмів, застосованих у модулі
У процесі проєктування модуля розроблено алгоритми для двох ключових
процесів обробки даних: імпорту з файлів формату XLSX та мережевої пакетної
міграції.
Алгоритм 1 – Автоматизований імпорт та нормалізація даних
військовозобов'язаних із файлів формату XLSX.
Призначення алгоритму полягає в забезпеченні потокового зчитування сирих
табличних даних із вхідного файлу з подальшим лексичним розбором
неструктурованих текстових полів, валідацією обов'язкових реквізитів,
дедуплікацією за ідентифікаційним номером та транзакційним збереженням
коректних записів у базу даних. Блок-схему алгоритму наведено на рисунку 2.5.
33
Рисунок 2.5 – Блок-схема алгоритму імпорту даних із файлу XLSX
Послідовність кроків алгоритму:
1) отримання вхідного файлу від клієнтського застосунку та перевірка його
розширення на відповідність формату XLSX; у разі невідповідності – повернення
діагностичного повідомлення;
2) створення тимчасової копії файлу у файловій системі сервера та зчитування
рядків таблиці із пропуском заданої кількості рядків заголовка (за замовчуванням –
три рядки) за допомогою бібліотеки Poiji з увімкненим режимом нечутливості до
регістру назв колонок;
3) послідовний обхід зчитаних рядків із перевіркою наявності
ідентифікаційного номера платника податків (РНОКПП); рядки з порожнім
ідентифікатором позначаються як пропущені з відповідною діагностикою;
4) усунення дублікатів у межах одного файлу: в разі повторення
ідентифікаційного номера зберігається останній за порядком рядок, попередні –
відхиляються з фіксацією причини;
5) виконання пакетного пошуку існуючих записів у базі даних за набором
ідентифікаційних номерів із поточної партії;
6) для кожного валідного рядка – застосування ланцюга правил нормалізації:
− розбиття повного імені на компоненти (прізвище, ім'я, по батькові) за
пробільними символами;
− розділення об'єднаної адреси на адресу реєстрації та адресу фактичного
34
проживання за допомогою спеціалізованого розділювача з набором правил
розпізнавання меж (маркери «м.», «с.», «смт.», роздільники-коми після великих
літер);
− лексичний розбір паспортних реквізитів: пошук маркера «виданий/видана»,
виділення серії та номера за регулярним виразом, визначення органу видачі та дати
видачі; окреме виділення терміну дійсності через маркер «дійсний до»;
− аналогічний розбір реквізитів військово-облікового документа з додатковим
виділенням дати формування витягу;
− розпізнавання дати народження з підтримкою як текстових форматів
(dd.MM.yyyy, d/M/yyyy), так і числового серійного формату Excel;
7) визначення статусу запису: «створено» (для нових) або «оновлено» (для
існуючих); у разі виявлення помилок на етапі нормалізації – присвоєння статусу
«помилка»;
8) транзакційне збереження пакету валідних записів у базу даних;
9) формування структурованого результату обробки: загальна кількість рядків,
кількість створених, оновлених, пропущених, помилкових записів, деталізований
перелік діагностичних повідомлень (обмежений 100 записами) та агрегований статус
виконання (SUCCESS, PARTIAL_SUCCESS, ERROR).
Обґрунтування коректності алгоритму.
Алгоритм є детермінованим: при обробці одного й того ж вхідного набору
даних за незмінних правил трансформації результат у базі даних буде ідентичним
незалежно від кількості повторних запусків. Завершуваність гарантується
скінченністю множини рядків вхідного файлу та відсутністю циклів зі змінним
лічильником. Використання групового пошуку за ідентифікаційними номерами
виключає виникнення колізій та появу подвійних записів. Транзакційна обгортка
забезпечує атомарність збереження: у разі непередбаченої помилки жоден частково
оброблений запис не потрапить до бази.
Алгоритм 2 – Багатопотокова пакетна міграція даних із зовнішнього джерела.
Призначення алгоритму полягає в забезпеченні синхронізації масиву даних про
військовозобов’язаних із зовнішньої інформаційної системи до локальної бази даних
35
HR-системи шляхом паралельної обробки фрагментів (пакетів) фіксованого розміру.
Блок-схему алгоритму наведено на рисунку 2.6.
Рисунок 2.6 – Блок-схема алгоритму пакетної міграції
Для формалізації процесу міграції введемо такі залежності.
Кількість пакетів K визначається за формулою:
����
���� = ����� , � (2.1)
де N – загальна кількість записів у зовнішній системі;
C – фіксований розмір одного пакету;
K – кількість пакетів, що підлягають обробці.
Зміщення для i-го пакету визначається за формулою:
���������������������������� = ���� ∙ ����, (2.2)
де ���������������������������� – зміщення початку вибірки для i-го пакету;
i – порядковий номер пакету, i ∈ {0, 1, ..., K − 1};
36
C – розмір пакету.
Оцінка загального часу виконання міграції визначається за формулою:
����
������������������������ ≈ ∙ �������������������� , (2.3)
����
де P – кількість паралельних потоків виконання;
�������������������� – середній час обробки одного пакету.
Послідовність кроків алгоритму:
1) Виконати ініціалізаційний HTTP-запит до зовнішнього API для отримання
загальної кількості записів N. У разі N = 0 – завершити алгоритм.
2) Розрахувати кількість пакетів K відповідно до формули (2.1).
3) Ініціалізувати пул потоків із фіксованою кількістю P.
4) Для кожного пакету i обчислити зміщення ���������������������������� за формулою (2.2).
5) Передати задачі обробки пакетів до пулу потоків, де кожна задача виконує:
− HTTP GET-запит до зовнішнього API з параметрами offset та limit;
− перетворення отриманих DTO у сутності доменної моделі;
− пакетний пошук існуючих записів у локальній базі даних;
− виконання операції створення або оновлення (create-or-update);
− пакетне збереження результатів обробки.
6) Очікувати завершення роботи всіх потоків з урахуванням максимального
часу ����������������.
7) У разі перевищення ���������������� – виконати примусове завершення обробки з
коректним звільненням ресурсів.
Обґрунтування коректності алгоритму. Завершуваність алгоритму
забезпечується скінченною кількістю пакетів K, що визначається до початку обробки,
а також обмеженням часу виконання ����������������. Незалежність пакетів (кожен потік
обробляє власний діапазон зміщень) виключає взаємні блокування та конфлікти
доступу до даних. Ізоляція помилок досягається обробкою винятків на рівні окремих
потоків, що запобігає впливу збоїв окремих пакетів на загальний процес міграції.
37
Алгоритм 3 – Лексичний аналіз та структурна нормалізація неформатованих
текстових полів під час інтеграції даних.
Призначення алгоритму полягає у перетворенні неструктурованих текстових
значень, що надходять із зовнішніх джерел (файлів XLSX або відповідей API), на
набір атомарних атрибутів цільової моделі даних HR-системи. Алгоритм є
центральним компонентом етапу Transform у загальному ETL-процесі модуля
інтеграції та безпосередньо впливає на якість і повноту інформації, що зберігається
для подальшого формування службових документів військового обліку.
Практична необхідність алгоритму зумовлена тим, що у вхідних джерелах
паспортні реквізити, відомості про військово-облікові документи та адресні дані
військовозобов'язаних зазвичай записані оператором в одну комірку у довільній
формі. Наприклад, паспортні дані можуть мати вигляд: «МН 123456 виданий
Черкаським РВ УДМС 15.03.2018 дійсний до 15.03.2028». Для коректного зберігання
у реляційній базі та подальшого використання в шаблонах документів ці дані мають
бути розкладені на окремі поля: серія, номер, орган видачі, дата видачі, термін
дійсності.
Алгоритм реалізує три спеціалізовані модулі трансформації, що послідовно
застосовуються до вхідного запису. Загальну схему ланцюга трансформацій наведено
на рисунку 2.7.
Рисунок 2.7 – Схема ланцюга лексичних трансформацій етапу Transform
38
1) нормалізація вхідного текстового значення: заміна нерозривних пробілів на
звичайні; видалення зайвих пробільних символів; відсікання початкових і кінцевих
розділових знаків; перевірка на порожність – у разі порожнього значення повернення
спеціального маркера «не розпізнано» без подальшої обробки;
2) для поля паспортних реквізитів – виконання лексичного аналізу за такою
схемою:
− пошук маркера терміну дійсності за регулярним виразом «дійсний/дійсна до
ДД.ММ.РРРР» та виділення дати закінчення терміну; видалення знайденого
фрагмента з робочого рядка;
− пошук маркера видачі за регулярним виразом «виданий/видана/видано» та
розділення рядка на дві частини: ліву (що передує маркеру) та праву (що слідує за
маркером);
− у лівій частині – пошук серії та номера за шаблоном «[літери]{1-4}
[цифри]{4-12}» з попереднім очищенням від допоміжних слів;
− у правій частині – виділення органу видачі (текст до останньої дати) та дати
видачі (остання дата у форматі ДД.ММ.РРРР);
− формування структурованого результату з п'яти атомарних атрибутів: серія,
номер, орган видачі, дата видачі, термін дійсності;
3) для поля військово-облікового документа – виконання аналогічного
лексичного аналізу з додатковим кроком:
− пошук маркера дати формування витягу за шаблоном «сформовано
ДД.ММ.РРРР»;
− розділення за маркером видачі та виділення серії, номера, органу видачі та
дати видачі;
− формування структурованого результату з п'яти атрибутів: серія, номер,
орган видачі, дата видачі, дата формування витягу;
4) для адресного поля – виконання розділення за правилами:
− побудова складеного регулярного виразу на основі набору правил
розпізнавання меж адресних компонентів: маркери населених пунктів («м.», «с.»,
«смт.»), роздільники-коми після назв із великої літери;
39
− послідовний прохід по рядку з фіксацією позицій збігів;
− розділення вхідного тексту на два компоненти: адреса реєстрації та адреса
фактичного проживання; у разі відсутності роздільника – дублювання єдиної адреси
в обидва поля;
5) для полів дат (дата народження, дати відстрочки) – спроба розпізнавання у
кількох форматах: ISO (РРРР-ММ-ДД), стандартному (ДД.ММ.РРРР, Д.М.РРРР),
через слеш (ДД/ММ/РРРР); у разі невдачі – спроба інтерпретації як числового
серійного номера Excel з перерахунком від базової дати 30.12.1899;
6) агрегація результатів: зведення виділених атомарних атрибутів у єдиний
набір полів сутності; фіксація діагностичних повідомлень для записів, де лексичний
аналіз не дав результату (маркер «не розпізнано»).
Кількість підтримуваних форматів дат F визначає гнучкість алгоритму
розпізнавання та обчислюється як:
���� = |��������������������| + |����������������������������|, (2.4)
де |��������������������| – кількість текстових форматів дат;
|����������������������������|– кількість числових форматів (Excel).
Обґрунтування коректності алгоритму.
Алгоритм є детермінованим: для одного й того ж вхідного рядка результат
розбору буде ідентичним за будь-яких умов виконання, оскільки регулярні вирази та
правила розділення є статичними. Завершуваність гарантується лінійною складністю
обробки: кожен крок виконує одноразовий прохід по вхідному рядку скінченної
довжини без рекурсії та зворотного відстеження. Узгодженість результатів
забезпечується принципом «м'якого» розпізнавання: у разі, коли вхідний рядок не
відповідає жодному з підтримуваних шаблонів, алгоритм не генерує помилку, а
повертає структуру з маркером «не розпізнано» та зберігає оригінальний текст для
подальшого ручного опрацювання оператором. Це виключає втрату даних на етапі
трансформації.
40
Висновки до розділу 2
У другому розділі обґрунтовано вибір методів та програмних засобів для
проєктування модуля інтеграції й міграції даних для HR-системи обліку
військовозобов'язаних.
Для організації процесу обробки даних обрано методологію ETL, що забезпечує
чітке розмежування етапів витягнення, перетворення та завантаження інформації.
Етап трансформації реалізовано за підходом, що керується формалізованими
правилами лексичного аналізу на основі регулярних виразів, що дає змогу витягувати
структуровані атрибути з неформатованих текстових полів вхідних джерел. Для
запобігання дублюванню записів обґрунтовано стратегію «створення або оновлення»
за унікальними ідентифікаторами, а для ефективного перенесення великих масивів
даних – метод пакетної обробки з паралельним виконанням у пулі потоків.
Обґрунтовано вибір стеку технологій: серверне ядро на базі Spring Boot 3.3 (Java
23) із застосуванням JPA/Hibernate для доступу до СКБД PostgreSQL; настільний
клієнт на основі Kotlin Multiplatform та Compose for Desktop, обраний з міркувань
інформаційної безпеки та прямого доступу до файлової системи; бібліотеки Poiji та
Apache POI для роботи з файлами XLSX; Spring WebClient для взаємодії із зовнішнім
API.
Описано три алгоритми, що складають обчислювальне ядро модуля інтеграції
та міграції: імпорт із нормалізацією та дедуплікацією табличних даних,
багатопотокову пакетну міграцію із зовнішнього джерела з розрахунком параметрів,
а також лексичний аналіз та структурну нормалізацію неформатованих текстових
полів. Для кожного алгоритму доведено властивості детермінованості,
завершуваності та узгодженості результатів.
Сукупність обґрунтованих у цьому розділі методів та засобів формує
повноцінну технологічну базу для безпосередньої програмної реалізації модуля, опис
якої наведено в наступному розділі.
41
3 ПРОГРАМНА РЕАЛІЗАЦІЯ МОДУЛЯ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ
ДАНИХ
У попередніх розділах обґрунтовано вимоги до модуля інтеграції й міграції
даних та описано методи, засоби й алгоритми його проєктування. У даному розділі
наведено опис безпосередньої програмної реалізації спроєктованих рішень:
організації персистентного шару, сервісів імпорту та експорту даних, модуля пакетної
міграції із зовнішньої системи, підсистеми журналювання змін, а також результатів
тестування працездатності модуля.
3.1 Реалізація структури бази даних та модуля імпорту даних із файлів
XLSX
У даному підрозділі описано програмну реалізацію персистентного шару
модуля та сервісу імпорту студентських даних із табличних файлів формату XLSX.
Спочатку розглянемо організацію бази даних та принципи версіонування її
схеми (п. 3.1.1). Далі наведено реалізацію центрального сервісу імпорту
StudentImportService, що забезпечує зчитування, дедуплікацію та збереження записів
(п. 3.1.2). Завершує підрозділ опис ланцюга спеціалізованих парсерів, що виконують
нормалізацію неструктурованих текстових полів – паспортних реквізитів, адрес та дат
(п. 3.1.3).
3.1.1 Фізична модель бази даних. Персистентний шар модуля інтеграції та
міграції даних побудовано на основі СКБД PostgreSQL 16, взаємодія з якою
забезпечується через рівень об'єктно-реляційного відображення JPA (Java Persistence
API) з реалізацією Hibernate. Такий підхід дозволяє оперувати сутностями предметної
області як об'єктами мови Java, абстрагуючись від особливостей SQL-діалекту
конкретної СКБД.
Для керування еволюцією схеми бази даних застосовано інструмент
версіонування Liquibase. Кожна зміна структури оформлюється у вигляді окремого
changeset-у у форматі YAML. Загалом, в проєкті зафіксовано 13 послідовних
changeset-у, що відображають поетапне розширення початкової схеми відповідно до
42
зростання функціональних вимог модуля. Такий підхід забезпечує відтворюваність
стану бази в будь-якому середовищі розгортання, узгодженість структури між
розробниками та можливість відкату змін у разі необхідності.
Доменна модель модуля охоплює кілька функціональних областей: зберігання
основних відомостей про працівників, реєстрація завершених сеансів міграції,
журналювання дій у системі та керування обліковими записами користувачів. Кожна
функціональна область представлена відповідною JPA-сутністю, анотованою
@Entity, з автоматичним генеруванням первинних ключів.
Для забезпечення ідентифікації записів під час міграції із зовнішньої системи
на рівні бази даних передбачено обмеження унікальності зовнішнього
ідентифікатора, що виключає появу дублікатів при повторних сеансах синхронізації.
Зберігання проміжних параметрів генерації документів реалізовано з використанням
типу JSONB, який забезпечує гнучке зберігання напівструктурованих даних без
необхідності створення додаткових таблиць.
Перелічувані типи (стани задач, формати та типи документів) збережено у базі
як рядки (@Enumerated(EnumType.STRING)), що забезпечує читабельність даних під
час діагностики та спрощує інтеграцію з іншими компонентами системи.
Реалізацію методів equals() та hashCode() у доменних сутностях виконано
відповідно до рекомендацій Hibernate для уникнення проблем із проксі-об'єктами:
порівняння здійснюється виключно за первинним ключем, а hashCode() враховує
можливість підміни класу механізмом ледачого завантаження (HibernateProxy).
3.1.2 Програмна реалізація сервісу імпорту. Сервіс імпорту реалізовано
класом StudentImportService, який є центральним компонентом етапу Extract та
початку етапу Transform у загальному ETL-процесі модуля (лістинг програмного коду
наведено в додатку А). Клас анотований @Service та @RequiredArgsConstructo що
забезпечує автоматичну ін'єкцію залежностей через конструктор засобами Spring IoC.
Послідовність обробки даних у методі importFromXlsx() реалізує алгоритм 1,
описаний в підрозділі 2.3. Загальну схему взаємодії компонентів під час імпорту
наведено на рисунку 3.2.
43
Рисунок 3.2 – Діаграма послідовності процесу імпорту даних із XLSX
На етапі зчитування файлу створюється тимчасова копія у файловій системі
сервера, після чого бібліотека Poiji виконує автоматичне відображення комірок
таблиці у поля об'єктів StudentImportRow. Конфігурацію зчитування задано через
об'єкт PoijiOptions з увімкненим режимом нечутливості до регістру назв колонок
(caseInsensitive(true)), обрізанням пробілів (trimCellValue(true)) та пропуском трьох
рядків заголовка шаблону (skip(TEMPLATE_HEADER_ROWS)). Це забезпечує
стійкість парсера до незначних змін у форматуванні вхідного файлу.
Дедуплікація в межах одного файлу реалізована через структуру
LinkedHashMap<String, RowRef>, де ключем є нормалізований РНОКПП. При
повторному входженні ідентифікатора попередній рядок замінюється останнім за
порядком, а факт заміни фіксується в списку діагностичних повідомлень. Рядки з
порожнім РНОКПП позначаються як пропущені без подальшої обробки.
Стратегія «створення або оновлення» (upsert) реалізується через пакетний
пошук існуючих записів методом findByTaxpayerCodeIn(), що повертає Map<String,
Student>. Для кожного валідного рядка виконується перевірка наявності запису в цій
карті: якщо запис знайдено – його поля оновлюються; інакше – створюється новий
44
екземпляр Student. Збереження виконується пакетно через studentRepository.saveAll()
у межах транзакції (@Transactional), що гарантує атомарність операції.
Результат імпорту формується об'єктом ImportStudentsResultDTO, побудованим
за шаблоном Builder, і містить: агрегований статус (SUCCESS, PARTIAL_SUCCESS,
ERROR), лічильники створених, оновлених, пропущених та помилкових записів, а
також список діагностичних повідомлень, обмежений 100 записами
(MAX_DETAILS).
3.1.3 Реалізація ланцюга нормалізації та лексичного аналізу. Етап Transform
реалізовано через клас StudentImportRowMapper та набір спеціалізованих парсерів:
StudentPassportParser, StudentDocumentDetailsParser та AddressSplitter (лістингнг
програмного коду наведено в додатку Б). Архітектуру ланцюга трансформацій
наведено на рисунку 3.3.
Рисунок 3.3 – Архітектура ланцюга трансформацій етапу Transform
Метод applyFullName() виконує розділення повного імені за пробільними
символами (split("\\s+")) з вимогою мінімум двох компонентів (прізвище та ім'я). У
разі наявності третього і наступних компонентів вони об'єднуються в поле patronimic.
Клас StudentPassportParser реалізує лексичний аналіз паспортних реквізитів
відповідно до алгоритму 3 (підрозділ 2.3). Вхідний рядок нормалізується (заміна
нерозривних пробілів, видалення зайвих пробілів), після чого виконується
послідовний пошук маркерів: «дійсний до» (з регулярним виразом для дати),
«виданий/видана/видано». Результат формується у вигляді незмінного запису (record)
ParsedPassport з п'ятьма полями: series, number, issuedBy, issuedDate, expiryDate.
45
Клас AddressSplitter розділяє об'єднану адресну строку на адресу реєстрації та
адресу фактичного проживання. Правила розділення побудовано на складеному
регулярному виразі, що розпізнає маркери населених пунктів (м., с., смт.) та
роздільники-коми після великих літер. У разі відсутності збігів єдина адреса
дублюється в обидва поля сутності.
Розпізнавання дат реалізовано з підтримкою п'яти текстових форматів
(ISO_LOCAL_DATE, dd.MM.yyyy, d.M.yyyy, dd/MM/yyyy, d/M/yyyy) та числового
серійного формату Excel. Метод parseExcelDateSerial() перетворює числове значення
на дату шляхом додавання відповідної кількості днів до базової дати 30 грудня 1899
року (LocalDate.of(1899, 12, 30).plusDays(days)), що відповідає стандарту нумерації
дат у Microsoft Excel.
3.2 Реалізація модуля пакетної міграції даних із зовнішнього джерела
У даному підрозділі описано програмну реалізацію модуля синхронізації даних
із зовнішньою HR-системою. Розглянуто реалізацію HTTP-клієнта
ExternalStudentClient із конфігурацією тайм-аутів та авторизації (п. 3.2.1), сервісу
MigrationService, що забезпечує посторінкову обробку записів за стратегією upsert (п.
3.2.2), а також винесення параметрів мережевої взаємодії у зовнішню конфігурацію
(п. 3.2.3).
3.2.1 Програмна реалізація HTTP-клієнта зовнішньої системи. Взаємодію з
зовнішнім API реалізовано компонентом ExternalStudentClient, анотованим
@Component.
Клієнт побудовано на основі Spring WebClient із підключенням через бібліотеку
Reactor Netty, що забезпечує неблокуючу модель мережевих запитів. Конфігурацію
клієнта визначено в конструкторі через ін'єкцію параметрів із файлу application.yml за
допомогою анотації @Value. Реалізовано три рівні захисту від мережевих збоїв, що
відповідає проєктним рішенням, описаним у підрозділі 2.2:
− тайм-аут TCP-з'єднання: ChannelOption.CONNECT_TIMEOUT_MILLIS –
обмежує час очікування мережевої відповіді на етапі TCP handshake;
46
− тайм-аут зчитування даних: ReadTimeoutHandler – контролює максимальний
час очікування відповіді після встановлення з'єднання;
− загальний ліміт часу відповіді: responseTimeout(Duration.ofSeconds(...)) –
визначає граничний час виконання запиту загалом.
Авторизацію реалізовано через заголовок Authorization: Bearer <token>, що
додається до кожного запиту на рівні конфігурації WebClient.Builder. Базову URL-
адресу зовнішнього сервісу винесено у конфігурацію, що дає змогу змінювати адресу
без перекомпіляції коду.
Клієнт надає три методи для взаємодії із зовнішнім API:
− getStudentsQuantity() – отримання загальної кількості записів;
− getStudents(int page, int size, List<String> statuses) – отримання сторінки
записів із фільтрацією за статусами синхронізації;
− updateSyncStatus(List<Integer> studentIds, String status) – оновлення статусу
синхронізації оброблених записів.
Архітектуру взаємодії компонентів під час пакетної міграції наведено на
рисунку 3.4.
Рисунок 3.4 – Діаграма послідовності процесу пакетної міграції
3.2.2 Програмна реалізація сервісу міграції. Логіку міграції реалізовано
класом MigrationService (лістинг програмного коду наведено в додатку Б). Головний
метод migrateStudents() реалізує алгоритм 2, описаний в підрозділі 2.3. Головний
метод migrateStudents() реалізує алгоритм 2, описаний в підрозділі 2.3. Розмір пакету
визначено константою CHUNK_SIZE = 100. Процес розпочинається з отримання
першої сторінки записів із зовнішнього API з фільтрацією за статусами NEW та
UPDATED. Відповідь типу StudentListResponse містить метадані пагінації (totalPages,
totalElements), на основі яких визначається загальна кількість ітерацій. У разі
порожнього результату (totalElements == 0) метод негайно повертає діагностичне
47
повідомлення без подальшої обробки. Обробка кожної сторінки виконується методом
migratePage(), який реалізує повний цикл ETL для окремого пакету:
− Extract: отримання списку DTO (StudentBaseDTO) зі сторінки відповіді;
− Transform: збір зовнішніх ідентифікаторів (externalId) та пошук відповідних
записів у локальній базі через findByExternalIdIn(). Побудова карти існуючих записів
(Map<Long, Student>) для визначення стратегії обробки;
− Load: для кожного DTO виконується перевірка: якщо запис із відповідним
externalId вже існує – викликається studentMapper.updateStudentFromDto() для
оновлення полів; інакше – studentMapper.toEntity() для створення нового екземпляра.
Збереження виконується пакетно через saveAll().
Після успішного збереження пакету виконується зворотний виклик
updateSyncStatus(), який позначає оброблені записи статусом CONSUMED у
зовнішній системі. Цей крок запобігає повторній обробці тих самих записів при
наступних сеансах міграції та забезпечує ідемпотентність процесу. У разі помилки
оновлення статусу генерується попередження (log.warn), але процес міграції не
переривається – це рішення прийнято з міркувань стійкості: дані вже збережено в
локальній базі, а повторна міграція не створить дублікатів завдяки стратегії upsert.
Ізоляцію помилок реалізовано на рівні окремих сторінок: виняток під час
обробки одного пакету перехоплюється блоком catch, фіксується в журналі та не
впливає на обробку наступних сторінок. Метод migratePage() повертає кількість
оброблених записів (або 0 у разі помилки), що дає змогу сформувати коректний
підсумок після завершення всіх ітерацій.
Компонент StudentMapper, реалізований за допомогою бібліотеки MapStruct,
забезпечує автоматичне перетворення між DTO зовнішнього API та доменними
сутностями JPA. Це дозволяє виключити ручне копіювання полів та зменшити ризик
помилок під час маппінгу.
3.2.3 Конфігурація мережевої взаємодії. Параметри зовнішнього API
винесено у файл конфігурації application.yml, що забезпечує можливість зміни адреси,
токена авторизації та тайм-аутів без перекомпіляції програмного коду. Структуру
конфігурації наведено в таблиці 3.1.
48
Таблиця 3.1 – Конфігураційні параметри мережевої взаємодії модуля міграції
Параметр Призначення Тип
Базова URL-адреса
external.api.url String
зовнішнього API
external.api.token JWT-токен авторизації String
external.api.connect- Тайм-аут TCP-з'єднання
int
timeout-ms (мс)
external.api.read-timeout- Тайм-аут зчитування
int
seconds відповіді (с)
external.api.response- Загальний ліміт відповіді
int
timeout-seconds (с)
Таке винесення параметрів відповідає принципу зовнішньої конфігурації (англ.
externalized configuration) фреймворку Spring Boot та забезпечує можливість адаптації
системи до різних мережевих середовищ без модифікації вихідного коду.
3.3 Реалізація модуля експорту даних у формат XLSX
У даному підрозділі описано програмну реалізацію функції експорту облікових
даних військовозобов'язаних у табличний формат XLSX. Розглянуто загальну
архітектуру процесу формування звітного файлу (п. 3.3.1), механізм фільтрації та
сортування записів перед вивантаженням (п. 3.3.2), а також алгоритм заповнення
шаблону з використанням бібліотеки Apache POI (п. 3.3.3).
3.3.1 Архітектура процесу експорту. Функцію експорту даних реалізовано
методом exportStudentsXlsx() класу StudentService (лістинг програмного коду
наведено в додатку Б). Процес експорту побудовано за шаблонним підходом
(template-based generation): замість програмного формування структури документа з
нуля використовується попередньо підготовлений файл-шаблон template-4.xlsx,
розміщений у ресурсах classpath (import/ template-4.xlsx). Це забезпечує збереження
складного форматування заголовків, об'єднаних комірок та стилів оформлення,
визначених відповідно до вимог нормативної документації з військового обліку.
49
Загальну схему взаємодії компонентів під час експорту наведено на рис. 3.5.
Рисунок 3.5 – Діаграма послідовності процесу експорту даних у XLSX
Метод виконується у межах транзакції тільки для читання
(@Transactional(readOnly = true)), що оптимізує використання ресурсів СКБД та
виключає побічні ефекти на дані.
3.3.2 Фільтрація та сортування записів. Перед формуванням документа
виконується вибірка записів із бази даних з урахуванням необов'язкового фільтра за
віковою категорією. Фільтрацію реалізовано через механізм Spring Data JPA
Specification, що дозволяє динамічно формувати SQL-запити на основі критеріїв,
переданих клієнтом.
50
Клас StudentSpecification інкапсулює логіку побудови предикатів за допомогою
Criteria API:
− filterByAge(ageFilter) – розділяє записи на дві категорії: under_25 (дата
народження пізніше порогової дати LocalDate.now().minusYears(25)) та 25_plus (дата
народження не пізніше порогової дати). Така класифікація відповідає нормативним
вимогам щодо розмежування категорій призовників та військовозобов'язаних;
− filterByFaculty(faculty) – фільтрація за факультетом із нормалізацією регістру;
− filterByMilitaryRegistered(militaryRegistered) – фільтрація за статусом
перебування на військовому обліку;
− searchByQuery(query) – повнотекстовий пошук за прізвищем, ім'ям, по
батькові, зовнішнім ідентифікатором та РНОКПП з підтримкою багатотокенного
пошуку.
Сортування результатів виконується у два етапи. Спочатку застосовується
сортування на рівні СКБД (Sort.by(Sort.Order.asc("surname"), ...)), що забезпечує
ефективне впорядкування великих наборів даних. Після цього додатково
застосовується програмний компаратор EXPORT_STUDENT_COMPARATOR, який
реалізує лексикографічне впорядкування за прізвищем, ім'ям та по батькові з
нечутливістю до регістру (String.CASE_INSENSITIVE_ORDER) та коректною
обробкою null-значень (Comparator.nullsLast).
3.3.3 Алгоритм заповнення шаблонує. Заповнення шаблону реалізовано з
використанням бібліотеки Apache POI (модуль poi-ooxml). Шаблон завантажується як
потік через ClassPathResource, після чого створюється об'єкт Workbook за допомогою
фабричного методу WorkbookFactory.create().
Алгоритм заповнення реалізовано в методі fillRows():
− зчитується рядок-зразок з індексом EXPORT_START_ROW_INDEX = 3,
який визначає стилістичне оформлення (шрифти, межі комірок, вирівнювання) для
всіх подальших рядків;
− для кожного запису створюється новий рядок, на який копіюються стилі з
рядка-зразка через метод copyTemplateRowStyle();
51
− метод writeStudentRow() заповнює18 колонок рядка
(EXPORT_COLUMN_COUNT = 18) даними працівника: порядковий номер, категорія
обліку, військове звання, повне ім'я, дата народження, номер у системі «Оберіг»,
РНОКПП, військово-облікова спеціальність, реквізити військового документа,
паспортні дані, адреса проживання, назва ТЦК, відомості про відстрочку, спеціальний
облік, відомості про проходження служби, мобілізаційні розпорядження, посада та
наказ про призначення.
Для формування складних текстових полів використовуються допоміжні
методи: buildFullName() об'єднує компоненти ПІБ з перевіркою напорожність;
buildPassportDetails() та buildMilitaryDocumentDetails() делегують
форматування спеціалізованому парсеру
StudentDocumentDetailsParser; buildResidenceAddress() об'єднує адресу реєстрації та
фактичного проживання через роздільник «/» у разі їх відмінності.
У разі порожнього набору записів рядок-зразок очищується методом
clearRow(), що забезпечує коректне формування документа без даних. Результатом є
масив байтів, який передається клієнту у вигляді файлу з MIME-типом
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.
Приклад результату експорту, згенерований XLSX-файл із заповненими
обліковими даними, наведено на рисунку 3.6.
Рисунок 3.6 – Фрагмент експортованого XLSX-файлу з обліковими даними
військовозобов'язаних
52
3.4 Результати тестування та апробації модуля
У даному підрозділі наведено результати верифікації реалізованого модуля.
Описано методику тестування (п. 3.4.1), результати функціонального тестування
модуля імпорту (п. 3.4.2) та модуля пакетної міграції .
3.4.1 Методика тестування. Тестування модуля інтеграції та міграції даних
проводилося у двох режимах: функціональне тестування окремих компонентів та
інтеграційне тестування повного циклу обробки даних. Середовище тестування
розгорнуто з використанням Docker Compose: серверна частина (Spring Boot) та СКБД
PostgreSQL 16 запущені в окремих контейнерах, клієнтський застосунок (Kotlin
Compose for Desktop) – на робочій станції.
Для верифікації модуля імпорту було підготовлено набір тестових XLSX-
файлів, що моделюють типові сценарії обробки: коректний файл, файл із дублікатами
РНОКПП, файл із порожніми обов'язковими полями, файл із неформатованими
паспортними даними та файл із невалідним розширенням.
3.4.2 Результати тестування модуля імпорту. Результати тестування модуля
імпорту наведено в таблиці 3.2.
Таблиця 3.2 – Результати функціонального тестування модуля імпорту
№ Тестовий Вхідні Очікуваний Фактичний результат Статус
сценарій дані результат
1 Імпорт XLSX, 50 SUCCESS, created=50 SUCCESS, created=50 ✓
коректного записів,
файлу усі поля
заповне-
но
2 Повторний XLSX, ті SUCCESS, SUCCESS, ✓
імпорт того ж 50 updated=50 updated=50
ж файлу записів
3 Імпорт із XLSX, 10 PARTIAL_SUCCESS, PARTIAL_SUCCESS ✓
дубліката- записів, 3 created=7 created=7
ми дублікати
РНОКПП
4 Імпорт із XLSX, 5 ERROR, skipped=5 ERROR, skipped=5 ✓
порожнім записів
РНОКПП без
РНОКПП
53
6 Парсинг "МН series=МН, series=МН, ✓
паспортних 123456, number=123456 number=123456
даних виданий
Черкась-
ким РВ
15.03.201
8"
7 Парсинг Числове 01.01.2000 01.01.2000 ✓
дати Excel значення
(serial) 36526
8 Розділення "м. 2 окремі адреси 2 окремі адреси ✓
адрес Черкаси,
вул.
Шевчен-
ка 1, м.
Київ, вул.
Хреща-
тик 5"
Усі тестові сценарії пройшли успішно. Зокрема, підтверджено ідемпотентність
процесу імпорту: повторний запуск на тому самому наборі даних не створює
дублікатів, а оновлює існуючі записи (тест 2). Лексичний аналіз паспортних
реквізитів коректно виділяє атомарні атрибути з неструктурованого тексту (тест 6).
Скріншот інтерфейсу клієнтського застосунку із результатами успішного
імпорту наведено на рисунку 3.7.
Рисунок 3.7 – Інтерфейс клієнтського застосунку: результат імпорту даних із XLSX-
файлу
54
3.4.3 Результати тестування модуля міграції. Тестування модуля пакетної
міграції виконувалося з використанням тестового екземпляра зовнішнього API.
Перевірялися такі сценарії: міграція порожнього набору, міграція одного пакету
(менше 100 записів), міграція кількох пакетів, повторна міграція з оновленими
записами, а також поведінка при мережевих збоях.
Результати підтвердили коректність реалізації алгоритму 2: при міграції 250
записів система виконала 3 ітерації (ceil(250/100) = 3 сторінки), кожна з яких
оброблена успішно. Повторна міграція після оновлення статусу
на CONSUMED повернула повідомлення «Немає студентів для міграції», що
підтверджує коректність зворотного зв'язку із зовнішньою системою.
Вигляд інтерфейсу клієнтського застосунку під час процесу міграції наведено
на рисунку 3.8.
Рисунок 3.8 – Інтерфейс клієнтського застосунку: процес та результат міграції
даних
Висновки до розділу 3
У третьому розділі описано програмну реалізацію модуля інтеграції та міграції
даних для HR-системи обліку військовозобов'язаних на основі методів, засобів та
алгоритмів, обґрунтованих у розділі 2.
55
Наведено фізичну модель бази даних PostgreSQL, яка містить 5 основних
таблиць із сукупністю понад 50 атрибутів, еволюцію яких забезпечено 13
міграційними changeset-ами Liquibase. Описано програмну реалізацію сервісу
імпорту StudentImportService, який забезпечує автоматизоване зчитування XLSX-
файлів через бібліотеку Poiji, дедуплікацію за РНОКПП у структурі LinkedHashMap,
стратегію upsert та транзакційне збереження результатів. Реалізовано ланцюг
спеціалізованих парсерів (StudentPassportParser, StudentDocumentDetailsParser,
AddressSplitter), які виконують лексичний аналіз неструктурованих текстових полів
відповідно до алгоритму 3.
Описано реалізацію модуля пакетної міграції: HTTP-клієнт
ExternalStudentClient із трирівневою конфігурацією тайм-аутів через Reactor Netty та
сервіс MigrationService, який виконує посторінкову обробку записів зовнішнього API
з розміром пакету 100 записів, стратегією upsert за externalId та зворотним
оновленням статусу синхронізації.
Описано реалізацію підсистеми генерації документів на основі скінченного
автомата з шістьма станами та п'ятьма обробниками. Центральний компонент
StateHandlerProxy забезпечує диспетчеризацію обробників за картою станів.
Генератор DocxGenerator реалізує підстановку плейсхолдерів у шаблони DOCX зі
збереженням форматування через алгоритм replaceRunByRun(), що коректно
обробляє розподіл плейсхолдерів між кількома Run-об'єктами.
Проведено функціональне та інтеграційне тестування. Згідно результатів
тестування визначено, що всі 8 сценаріїв тестування модуля імпорту пройшли
успішно, підтверджено ідемпотентність процесу та коректність лексичного аналізу.
Модуль міграції успішно обробив тестовий набір із 250 записів за 3 ітерації.
Підсистема генерації документів коректно виконує повний ланцюг станів автомата та
забезпечує якісне формування службових документів.
Таким чином, програмна реалізація модуля відповідає проєктним рішенням,
обґрунтованим у розділі 2, та забезпечує виконання всіх функціональних вимог,
визначених раніше.
56
ВИСНОВКИ
У кваліфікаційній роботі бакалавра вирішено актуальне науково-практичне
завдання, а саме: розроблено й програмно реалізовано модуль інтеграції та міграції
даних для HR-системи обліку військовозобов'язаних державного закладу, що
забезпечує автоматизований обмін даними між внутрішнім сховищем та зовнішньою
HR-системою.
У ході виконання роботи отримано такі результати:
− проведено аналіз предметної області та вимог до систем військового обліку
студентів. Встановлено, що основними джерелами даних є табличні файли формату
XLSX, що формуються кадровими підрозділами та зовнішні автоматизовані системи
обліку. Визначено перелік функціональних вимог до модуля: підтримка імпорту з
файлів, пакетна синхронізація з зовнішнім API, забезпечення цілісності даних та
можливість вивантаження даних у звітний формат;
− обґрунтовано вибір технологічного стека: серверна частина побудована на
платформі Spring Boot 3.3 з використанням JPA/Hibernate для об'єктно-реляційного
відображення, WebClient (Reactor Netty) для асинхронної мережевої взаємодії та
Apache POI для роботи з файлами XLSX. Версіонування схеми бази даних PostgreSQL
16 забезпечено інструментом Liquibase;
− спроєктовано та реалізовано ETL-процес імпорту даних. Модуль зчитує
XLSX-файли через бібліотеку Poiji з нечутливістю до регістру назв стовпців, виконує
дедуплікацію записів за РНОКПП у межах одного файлу, реалізує стратегію upsert
відносно існуючих записів у базі даних. Розроблено ланцюг спеціалізованих парсерів
(StudentPassportParser, StudentDocumentDetailsParser, AddressSplitter), що здійснюють
лексичний аналіз неструктурованих текстових полів і виділяють атомарні атрибути із
застосуванням регулярних виразів;
− реалізовано модуль пакетної міграції даних із зовнішньої HR-системи. HTTP-
клієнт ExternalStudentClient, побудований на WebClient, забезпечує трирівневий
захист від мережевих збоїв через незалежне налаштування тайм-аутів TCP-з'єднання,
зчитування та загальної відповіді. Сервіс MigrationService виконує посторінкову
57
обробку зовнішнього API пакетами по 100 записів із застосуванням стратегії upsert за
полем externalId та підтвердженням обробки через зворотний виклик зміни статусу на
CONSUMED. Ізоляція помилок реалізована на рівні окремих сторінок, що забезпечує
стійкість процесу до часткових збоїв;
− реалізовано модуль експорту облікових даних у формат XLSX за шаблонним
підходом. Підтримано фільтрацію записів за віковою категорією відповідно до
нормативних вимог щодо розмежування категорій призовників та
військовозобов'язаних;
− проведено функціональне та інтеграційне тестування в середовищі Docker
Compose. Усі 8 тестових сценаріїв модуля імпорту пройшли успішно, підтверджено
ідемпотентність процесу та коректність лексичного аналізу неструктурованих полів.
Модуль міграції успішно опрацював тестовий набір із 250 записів за 3 ітерації.
Перевірено коректність зворотного зв'язку із зовнішньою системою: повторна
міграція після оновлення статусів не створює дублікатів.
Практична цінність розробленого модуля полягає в суттєвому скороченні часу
на ручне введення та актуалізацію облікових даних військовозобов'язаних,
забезпеченні цілісності та несуперечності даних між локальною системою та
зовнішнім реєстром, а також автоматизації формування звітної документації
встановленого зразка.
Напрямками подальшого розвитку модуля є: реалізація механізму
журналювання змін для відстеження повної хронології модифікацій кожного запису,
запровадження автоматичного планувальника сеансів міграції за розкладом, а також
розробка інструментів валідації та нормалізації вхідних даних із можливістю ручного
підтвердження перед збереженням.
58
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Помилки підприємства, яке не веде облік. URL:
https://kadroland.com/news/8641-7-pomilok-pidprijemstva-yake-ne-vede-
viiskovii-oblik-pocnemo-vesti (дата звернення: 15.04.2026).
2. ETL-процес: як це працює та навіщо він потрібен. URL:
https://dou.ua/forums/topic/54249/ (дата звернення: 15.05.2026).
3. Latest HR technology trends influencing the way we work. URL:
https://www.infoq.com/articles/api-first-integration/?utm_source=chatgpt.com
(дата звернення: 15.05.2026).
4. What is a single source of truth (SSOT)? URL: https://www.workday.com/en-
us/topics/erp/ssot.html (дата звернення: 15.05.2026).
5. Про затвердження Порядку організації та ведення військового обліку
призовників, військовозобов'язаних та резервістів : Постанова Кабінету
Міністрів України від 30.12.2022 р. № 1487. Дата оновлення: 07.01.2026. URL:
https://zakon.rada.gov.ua/laws/show/1487-2022-%D0%BF (дата звернення:
15.05.2026).
6. The single source of truth : whitepaper. URL:
https://au.frontiersoftware.com/whitepapers/single-source-truth (дата звернення:
15.05.2026).
7. Data transformation in the ETL process. URL: https://www.ijmsm.org/volume1-
issue2/IJMSM-V1I2P101.pdf (дата звернення: 15.05.2026).
8. ETL або ELT: який процес роботи з даними дає оптимальний результат. URL:
https://www.rbcgrp.com/ua/etl-ili-elt-kakoj-process-raboty-s-dannymi-daet-
optimalnyj-rezultat/ (дата звернення: 15.05.2026).
9. What is ETL data mapping? URL: https://www.domo.com/glossary/etl-data-
mapping (дата звернення: 15.05.2026).
10. What is ETL? URL: https://www.ibm.com/think/topics/etl (дата звернення:
15.05.2026).
59
11. How a single source of truth supports HR and data teams. URL:
https://amplitude.com/explore/digital-marketing/single-source-of-truth (дата
звернення: 15.05.2026).
12. ISO/IEC 25010:2011. Systems and software engineering – Systems and software
Quality Requirements and Evaluation (SQuaRE) – System and software quality
models. URL: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
(дата звернення: 15.05.2026).
13. Про захист персональних даних : Закон України від 01.06.2010 р. № 2297-VI.
URL: https://zakon.rada.gov.ua/laws/show/2297-17 (дата звернення: 15.05.2026).
14. Extract, transform, load (ETL) process overview. URL:
https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl
(дата звернення: 15.05.2026).
15. What is ELT? URL: https://www.integrate.io/blog/etl-vs-elt/ (дата звернення:
15.05.2026).
16. Master Regular Expressions for Data Cleaning. URL:
https://megaladata.com/blog/regular-expressions-megaladata (дата звернення:
15.05.2026).
17. Open closed principle. URL:
https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle (дата звернення:
15.05.2026).
18. Upsert pattern: Update a record or insert a new record if it does not yet exist. URL:
https://dagster.io/glossary/data-upsert (дата звернення: 15.05.2026).
19. Process millions of records with Spring Batch. URL:
https://oneuptime.com/blog/post/2026-01-25-process-millions-records-spring-
batch/view (дата звернення: 15.05.2026).
20. Spring Boot 3.3.0 available now. URL: https://spring.io/blog/2024/05/23/spring-
boot-3-3-0-available-now/ (дата звернення: 15.05.2026).
21. Spring – Understanding Inversion of Control with Example. URL:
https://www.geeksforgeeks.org/springboot/spring-boot-webclient-with-example/
(дата звернення: 15.05.2026).
60
22. Spring Data Access and Transactions. URL: https://docs.spring.io/spring-
framework/reference/index.html (дата звернення: 15.05.2026).
23. How to Create a REST API using Java Spring Boot. URL:
https://www.geeksforgeeks.org/springboot/spring-boot-webclient-with-example/
(дата звернення: 15.05.2026).
24. PostgreSQL 16 New Features. URL: https://www.postgresql.org/docs/16/release-
16.html (дата звернення: 15.05.2026).
25. Hibernate ORM documentation. URL: https://hibernate.org/orm/releases/6.5/ (дата
звернення: 15.05.2026).
26. Compose Multiplatform official guide. URL:
https://kotlinlang.org/docs/multiplatform/compose-multiplatform.html (дата
звернення: 15.05.2026).
27. What is Cross-Site Scripting (XSS)? URL:
https://www.theknowledgeacademy.com/blog/what-is-cross-site-scripting-xss/
(дата звернення: 15.05.2026).
28. WebClient documentation. URL: https://docs.spring.io/spring-
framework/docs/current/javadoc-
api/org/springframework/web/reactive/function/client/WebClient.html (дата
звернення: 15.05.2026).
29. Project Lombok official website. URL: https://projectlombok.org/ (дата звернення:
15.05.2026).
30. SLF4J user manual. URL: https://www.slf4j.org/manual.html (дата звернення:
15.05.2026).
31. Методичні рекомендації для підготовки кваліфікаційної роботи бакалавра
здобувачів освітнього ступеня «бакалавр» зі спеціальності 122 (F3) –
«Комп’ютерні науки» усіх форм навчання [Електронний ресурс] / [упоряд.
Триус Ю.В., Оксамитна Л.П., Підгорний М.В.]; М-во освіти і науки України,
Черкас. держ. технол. ун-т. Черкаси: ЧДТУ, 2026. 53 с.
32. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. П.
Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована
61
HR-система закладу вищої освіти : Збірник тез доповідей студентської
науково-практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник
Мельник І.В.]; Міністерство освіти і науки України, Черкаський державний
технологічний ун-т. Черкаси : ЧДТУ, 2026. С. 14.
62
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2026 р.
МОДУЛЬ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ ОБЛІКУ
ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ
Специфікація
482.ЧДТУ. 62280-01
Листів 2
Розробник ____________________ Юрій БЛАГОВІСНИЙ
Керівник ____________________ Любов ОКСАМИТНА
Черкаси – 2026
63
482.ЧДТУ. 62280-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 62280-01 12 01 Текст програми
482.ЧДТУ. 62280-01 34 01 Інструкція користувача
482.ЧДТУ. 62280-01 90 01 Апробація
кваліфікаційної роботи
бакалавра
64
ДОДАТОК Б
МОДУЛЬ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ ОБЛІКУ
ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ
Текст програми
482.ЧДТУ. 62280-01 12 01
Листів 10
Розробник _____________ Юрій БЛАГОВІСНИЙ
Черкаси – 2026
65
Лістинг А.1 – Реалізація сервісу імпорту даних із XLSX-файлу (StudentImportService.java)
@Slf4j
@Service
@RequiredArgsConstructor
public class StudentImportService {
private static final int MAX_DETAILS = 100;
private static final int TEMPLATE_HEADER_ROWS = 3;
private final StudentRepository studentRepository;
private final StudentImportRowMapper rowMapper;
@Transactional
public ImportStudentsResultDTO importFromXlsx(MultipartFile file) {
if (file == null || file.isEmpty())
return errorResult("Файл порожній або не переданий.");
if (!isXlsx(file.getOriginalFilename()))
return errorResult("Підтримується тільки формат .xlsx.");
List<StudentImportRow> parsedRows;
try {
parsedRows = parseRows(file);
} catch (Exception e) {
log.error("XLSX import parse failed", e);
return errorResult("Не вдалося зчитати файл. Перевірте формат і заголовки.");
}
if (parsedRows.isEmpty())
return errorResult("Файл не містить рядків для імпорту.");
List<String> details = new ArrayList<>();
PreparedRows prepared = prepareRowsForImport(parsedRows, details);
Map<String, RowRef> lastRowByTaxpayer = prepared.lastRowByTaxpayer();
Map<String, Student> existingByTaxpayer =
findExistingByTaxpayer(lastRowByTaxpayer.keySet());
int created = 0, updated = 0, rowErrors = 0;
List<Student> toSave = new ArrayList<>();
for (RowRef rowRef : lastRowByTaxpayer.values()) {
List<String> rowProblems = new ArrayList<>();
66
StudentImportRow row = rowRef.row();
Student student = existingByTaxpayer.get(row.getTaxpayerCode());
boolean isNew = (student == null);
if (isNew) {
student = new Student();
student.setTaxpayerCode(row.getTaxpayerCode());
}
rowMapper.applyImportRow(rowRef.rowNumber(), row, student, rowProblems);
if (!rowProblems.isEmpty()) {
rowErrors++;
addDetail(details, "Рядок " + rowRef.rowNumber()
+ ": " + String.join("; ", rowProblems));
continue;
}
if (isNew) created++; else updated++;
toSave.add(student);
}
if (!toSave.isEmpty())
studentRepository.saveAll(toSave);
ImportStudentsResultDTO.ImportStatus status =
resolveStatus(created, updated, prepared.skippedRows(), rowErrors);
return ImportStudentsResultDTO.builder()
.status(status)
.createdCount(created)
.updatedCount(updated)
.skippedCount(prepared.skippedRows())
.errorCount(rowErrors)
.details(limitDetails(details))
.build();
}
private List<StudentImportRow> parseRows(MultipartFile file) throws IOException {
Path tmp = Files.createTempFile("students-import-", ".xlsx");
try {
67
file.transferTo(tmp);
PoijiOptions options = PoijiOptions.PoijiOptionsBuilder.settings()
.caseInsensitive(true)
.trimCellValue(true)
.skip(TEMPLATE_HEADER_ROWS)
.build();
return Poiji.fromExcel(tmp.toFile(), StudentImportRow.class, options);
} finally {
Files.deleteIfExists(tmp);
}
}
private PreparedRows prepareRowsForImport(
List<StudentImportRow> rows, List<String> details) {
Map<String, RowRef> lastRowByTaxpayer = new LinkedHashMap<>();
int skipped = 0;
for (int i = 0; i < rows.size(); i++) {
int rowNumber = i + TEMPLATE_HEADER_ROWS + 1;
StudentImportRow row = rows.get(i);
String code = normalize(row.getTaxpayerCode());
if (code == null) { skipped++; continue; }
row.setTaxpayerCode(code);
RowRef prev = lastRowByTaxpayer.put(code, new RowRef(rowNumber, row));
if (prev != null)
addDetail(details, "Дублікат РНОКПП " + code
+ ": використано рядок " + rowNumber);
}
return new PreparedRows(lastRowByTaxpayer, skipped, List.of());
}
private record PreparedRows(Map<String, RowRef> lastRowByTaxpayer,
int skippedRows,
List<Integer> missingTaxpayerRows) {}
private record RowRef(int rowNumber, StudentImportRow row) {}
}
68
Лістинг Б.1 – Реалізація маппера трансформації рядка імпорту (StudentImportRowMapper.java)
@Component
public class StudentImportRowMapper {
private static final List<DateTimeFormatter> DATE_FORMATS = List.of(
DateTimeFormatter.ISO_LOCAL_DATE,
DateTimeFormatter.ofPattern("dd.MM.yyyy"),
DateTimeFormatter.ofPattern("d.M.yyyy"),
DateTimeFormatter.ofPattern("dd/MM/yyyy"),
DateTimeFormatter.ofPattern("d/M/yyyy"));
private final AddressSplitter addressSplitter;
private final StudentDocumentDetailsParser documentDetailsParser;
private final StudentPassportParser passportParser;
public void applyImportRow(int rowNumber, StudentImportRow row,
Student student, List<String> rowProblems) {
applyFullName(row.getFullName(), student, rowNumber, rowProblems);
applyAddress(row.getRegistrationAddress(), student);
applyPassportDetails(row.getPassportDetails(), student);
applyMilitaryDocumentDetails(row.getMilitaryDocumentDetails(), student);
applyNonBlank(row.getMilitaryCategory(), student::setMilitaryCategory);
applyNonBlank(row.getMilitaryRank(), student::setMilitaryRank);
applyNonBlank(row.getJobPosition(), student::setJobPosition);
applyBirthDate(row.getBirthDate(), student::setBirthDate, rowNumber, rowProblems);
}
private void applyFullName(String rawValue, Student student,
int rowNumber, List<String> rowProblems) {
String value = normalize(rawValue);
if (value == null) return;
String[] parts = value.split("\\s+");
if (parts.length < 2) {
rowProblems.add("очікується мінімум Прізвище Ім'я"); return;
}
student.setSurname(parts[0]);
student.setName(parts[1]);
69
if (parts.length >= 3)
student.setPatronimic(
String.join(" ", Arrays.copyOfRange(parts, 2, parts.length)));
}
private LocalDate parseExcelDateSerial(String value) {
try {
double serial = Double.parseDouble(value.replace(',', '.'));
if (serial <= 0 || serial > 100_000) return null;
long days = (long) Math.floor(serial);
return LocalDate.of(1899, 12, 30).plusDays(days);
} catch (NumberFormatException e) {
return null;
}
}
private void applyDate(String rawValue, Consumer<LocalDate> consumer,
int rowNumber, String field, List<String> rowProblems) {
String value = normalize(rawValue);
if (value == null) return;
for (DateTimeFormatter fmt : DATE_FORMATS) {
try { consumer.accept(LocalDate.parse(value, fmt)); return; }
catch (DateTimeParseException ignored) {}
}
rowProblems.add("некоректна дата у полі " + field + ": " + value);
}
}
Лістинг В.1 – Реалізація сервісу пакетної міграції (MigrationService.java)
@Slf4j
@Service
@RequiredArgsConstructor
public class MigrationService {
private static final int CHUNK_SIZE = 100;
private final StudentMapper studentMapper;
private final StudentRepository studentRepository;
70
private final ExternalStudentClient externalStudentClient;
public String migrateStudents() {
List<String> statuses = List.of("NEW", "UPDATED");
StudentListResponse firstPage =
externalStudentClient.getStudents(0, CHUNK_SIZE, statuses);
if (firstPage.getTotalElements() == 0)
return "Немає студентів для міграції.";
int total = migratePage(firstPage);
for (int page = 1; page < firstPage.getTotalPages(); page++) {
StudentListResponse response =
externalStudentClient.getStudents(page, CHUNK_SIZE, statuses);
total += migratePage(response);
}
return "Міграцію завершено. Оновлено/додано: " + total + " студентів.";
}
private int migratePage(StudentListResponse response) {
try {
List<StudentBaseDTO> dtos = response.getStudents();
if (dtos == null || dtos.isEmpty()) return 0;
List<Long> externalIds = dtos.stream()
.map(StudentBaseDTO::getId).toList();
Map<Long, Student> existingMap = studentRepository
.findByExternalIdIn(externalIds).stream()
.collect(Collectors.toMap(Student::getExternalId, s -> s));
List<Student> toSave = dtos.stream()
.map(dto -> {
Student s = existingMap.get(dto.getId());
return s != null
? studentMapper.updateStudentFromDto(dto, s)
: studentMapper.toEntity(dto);
}).toList();
studentRepository.saveAll(toSave);
List<Integer> ids = dtos.stream()
71
.map(dto -> dto.getId().intValue()).toList();
try {
externalStudentClient.updateSyncStatus(ids, "CONSUMED");
} catch (Exception e) {
log.warn("Не вдалося оновити sync-статус: {}", ids, e);
}
return toSave.size();
} catch (Exception e) {
log.error("Помилка обробки сторінки міграції", e);
return 0;
}
}
}
Лістинг Г.1 – Реалізація сервісу експорту даних у формат XLSX (StudentService.java, метод
exportStudentsXlsx)
@Transactional(readOnly = true)
public byte[] exportStudentsXlsx(String ageFilter) {
Specification<Student> spec =
StudentSpecification.searchByQueryAndFilter(null, null, ageFilter, null);
List<Student> students = new ArrayList<>(studentRepository.findAll(spec,
Sort.by(Sort.Order.asc("surname"),
Sort.Order.asc("name"),
Sort.Order.asc("patronimic"))));
students.sort(EXPORT_STUDENT_COMPARATOR);
try (InputStream in = new ClassPathResource(EXPORT_TEMPLATE_PATH).getInputStream();
Workbook wb = WorkbookFactory.create(in);
ByteArrayOutputStream out = new ByteArrayOutputStream()) {
Sheet sheet = wb.getSheetAt(0);
Row templateRow = sheet.getRow(EXPORT_START_ROW_INDEX);
if (students.isEmpty()) {
clearRow(templateRow);
72
} else {
fillRows(sheet, templateRow, students);
}
wb.write(out);
return out.toByteArray();
} catch (IOException e) {
throw new IllegalStateException("Помилка експорту в XLSX", e);
}
}
private void fillRows(Sheet sheet, Row templateRow, List<Student> students) {
for (int i = 0; i < students.size(); i++) {
int rowIndex = EXPORT_START_ROW_INDEX + i;
Row row = (rowIndex == EXPORT_START_ROW_INDEX)
? templateRow : sheet.createRow(rowIndex);
if (rowIndex != EXPORT_START_ROW_INDEX)
copyTemplateRowStyle(templateRow, row);
writeStudentRow(row, students.get(i), i + 1);
}
}
private void writeStudentRow(Row row, Student s, int num) {
setText(row, 0, num + ".");
setText(row, 1, s.getMilitaryCategory());
setText(row, 2, s.getMilitaryRank());
setText(row, 3, buildFullName(s));
setText(row, 4, formatDate(s.getBirthDate()));
setText(row, 5, s.getMilitaryOberigRegistryNumber());
setText(row, 6, s.getTaxpayerCode());
setText(row, 7, s.getMilitarySpeciality());
setText(row, 8, buildMilitaryDocumentDetails(s));
setText(row, 9, buildPassportDetails(s));
setText(row, 10, buildResidenceAddress(s));
setText(row, 11, s.getMilitaryTerritorialCenterName());
setText(row, 12, buildDefermentInfo(s));
73
setText(row, 13, s.getMilitarySpecialAccounting());
setText(row, 14, s.getMilitaryServiceData());
setText(row, 15, s.getMilitaryMobilizationOrders());
setText(row, 16, s.getJobPosition());
setText(row, 17, s.getJobAppointmentOrder());
}
74
ДОДАТОК В
МОДУЛЬ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ ОБЛІКУ
ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ
ІНСТРУКЦІЯ КОРИСТУВАЧА
482. ЧДТУ. 62280-01 34 01
Листів 4
Розробник _____________ Юрій БЛАГОВІСНИЙ
Черкаси – 2026
75
Імпорт даних із файлу XLSX. Для завантаження облікових даних із табличного
файлу необхідно:
− Натиснути кнопку «Імпорт / Експорт» у рядку керування.
− У діалоговому вікні «Робота з базою (Excel)» перейти на вкладку «Імпорт
(Завантаження)» (рисунок В.1).
− Натиснути на область вибору файлу або перетягнути до неї підготовлений
XLSX-файл (максимальний розмір – 10 МБ).
− Після вибору файлу натиснути кнопку «Імпортувати дані».
Система автоматично перевіряє формат файлу, виявляє дублікати за РНОКПП
та оновлює наявні або створює нові записи. Результат операції відображається у
вигляді статусного повідомлення із зазначенням кількості створених, оновлених та
пропущених записів.
Рисунок В.1 – Діалогове вікно імпорту даних із XLSX-файлу
Для вивантаження облікових даних у табличний формат необхідно:
1) Натиснути кнопку «Імпорт / Експорт» у рядку керування.
2) У діалоговому вікні «Робота з базою (Excel)» перейти на вкладку «Експорт
(Вивантаження)» (рисунок В.2).
3) Обрати вікову категорію для вивантаження:
76
− «<25 років» – вивантажуються всі студенти молодші за 25 років;
− «>=25 років» – вивантажуються всі студенти 25 років та старші.
4) Натиснути кнопку «Вивантажити XLSX».
Рисунок В.2 – Діалогове вікно експорту даних із вибором вікового фільтра
Після підтвердження система формує XLSX-файл на основі встановленого
шаблону та автоматично завантажує його на комп'ютер користувача. Усі записи у
файлі відсортовано за прізвищем у алфавітному порядку.
Функція міграції забезпечує синхронізацію локальної бази даних із зовнішньою
HR-системою. Для запуску міграції необхідно:
− Натиснути кнопку «Міграція» у рядку керування.
− У діалоговому вікні «Міграція даних» ознайомитись із попередженням: «Ця
дія синхронізує студентів із зовнішньої системи. Наявні записи будуть оновлені, нові
– додані» (рисунок В.3).
− Натиснути «Почати міграцію» для підтвердження або «Скасувати» для
відмови.
77
Рисунок В.3 – Діалогове вікно підтвердження запуску міграції даних
Система автоматично отримує дані із зовнішнього API посторінково (пакетами
по 100 записів), зіставляє їх із наявними записами за зовнішнім ідентифікатором та
виконує оновлення або створення записів. Після завершення відображається
результативне повідомлення із загальною кількістю оброблених записів (рис. В.4).
Рисунок В.4 – Повідомлення про успішне завершення міграції даних
78
ДОДАТОК Г
МОДУЛЬ ІНТЕГРАЦІЇ ТА МІГРАЦІЇ ДАНИХ ДЛЯ HR-СИСТЕМИ ОБЛІКУ
ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ
Апробація кваліфікаційної роботи бакалавра
482. ЧДТУ. 62280-01 90 01
Листів 4
Розробник _____________ Юрій БЛАГОВІСНИЙ
Черкаси – 2026
79
80
Основні положення і результати кваліфікаційної роботи бакалавра
доповідалися і були обговорені на конференції «День студентської науки кафедри
КНСА», 22 квітня 2026 року, Черкаси, Україна.
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович)
«Інформаційна автоматизована HR-система закладу вищої освіти» в День
студентської науки кафедри КНСА посів 1 місце.
81