Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6576
Title: Дослідження засобів проектування та розробки баз даних каталогу дисциплін
Authors: Лукашенко, Валентина Максимівна
Булавко, Костянтин Михайлович
Issue Date: Jan-2026
Abstract: Метою кваліфікаційної роботи магістра є розробка оптимізованої архітектури бази даних каталогу навчальних дисциплін, що забезпечує високу продуктивність, цілісність даних, гнучкість та можливість інтеграції з іншими інформаційними системами університету. Об'єкт дослідження – процеси проектування та розробки баз даних для каталогізації навчальних дисциплін. Предмет дослідження – структура бази даних та методи доступу до інформації каталогу навчальних дисциплін. У кваліфікаційній роботі магістра вирішено актуальну науково-практичну задачу розробки ефективної архітектури бази даних для каталогу навчальних дисциплін, яка забезпечує високу продуктивність, цілісність даних та можливість інтеграції з іншими інформаційними системами університету. Основні результати дослідження полягають у наступному. Проведено комплексний аналіз існуючих систем каталогізації навчальних дисциплін, включаючи Moodle, Canvas LMS, Blackboard Learn, Studip та вітчизняні розробки. Виявлено ключові недоліки: недостатню оптимізацію структури даних, що призводить до зниження продуктивності при роботі з великими обсягами інформації; жорсткість архітектури, яка обмежує можливості адаптації до специфічних потреб різних освітніх закладів; недостатню підтримку міжнародних стандартів опису дисциплін; проблеми з інтеграцією та безпекою даних. Обґрунтовано доцільність розробки нової архітектури через сформульовані функціональні, нефункціональні та технічні вимоги до проектованої системи. Розроблено математичну модель оптимізації структури реляційної бази даних, яка формалізує процес проектування через теорію відношень та функціональних залежностей. Модель включає формальне представлення схеми даних, критерії нормалізації до третьої нормальної форми, функції оцінки вартості виконання запитів з урахуванням кардинальності відношень та селективності операцій. Запропоновано математичні критерії для прийняття обґрунтованих рішень щодо селективної денормалізації, оптимального індексування та партиціонування даних на основі аналізу профілю навантаження системи. Створено комплекс алгоритмів нормалізації та індексування, які забезпечують оптимальний баланс між цілісністю даних та продуктивністю системи. Алгоритм селективної денормалізації дозволяє оптимізувати структуру для часто виконуваних запитів без критичних порушень цілісності. Алгоритм оптимального індексування враховує як переваги для операцій читання, так і вартість підтримки індексів при модифікації даних. Розроблено спеціалізовані алгоритми для індексування зв'язків багато-до-багатьох, динамічної адаптації індексів, оптимізації складних запитів з множинними JOIN операціями та партиціонування великих таблиць. Розроблено методи забезпечення транзакційної цілісності та узгодженості даних, що включають алгоритми забезпечення всіх властивостей ACID транзакцій. Створено багаторівневу систему перевірки цілісності, яка охоплює обмеження на рівні атрібутів через CHECK constraints, міжрядкові обмеження через UNIQUE constraints, референційну цілісність через FOREIGN KEY constraints та складні бізнес-правила через тригери. Запропоновано алгоритми контролю конкурентного доступу з використанням двофазного блокування та оптимістичної конкурентності залежно від характеру операцій. Розроблено алгоритм відновлення після збоїв на основі write-ahead logging. Спроектовано повну специфікацію структури бази даних через послідовну розробку концептуальної, логічної та фізичної моделей. Концептуальна модель визначає основні сутності предметної області та зв'язки між ними з використанням методології Entity-Relationship моделювання. Логічна модель трансформує концептуальне представлення у реляційну структуру з 15 основними таблицями та 8 асоціативними таблицями при дотриманні третьої нормальної форми. Фізична модель включає конкретну реалізацію у PostgreSQL з системою індексування (25 індексів різних типів), партиціонуванням таблиці історії за роками, 5 матеріалізованими представленнями для аналітичних запитів, 12 тригерами та 8 збереженими процедурами. Реалізовано RESTful API для доступу до даних системи з 40 endpoints, що забезпечують повний CRUD функціонал для всіх сутностей. API підтримує фільтрацію, пагінацію, сортування та повнотекстовий пошук. Впроваджено багаторівневу систему безпеки з автентифікацією через JWT токени, авторизацією на основі 6 ролей користувачів, валідацією вхідних даних на трьох рівнях. Реалізовано Data Access Layer через паттерн Repository та Service Layer для інкапсуляції бізнес-логіки. Використано кешування через Redis для підвищення продуктивності з досягненням зменшення часу відповіді на 70% для часто запитуваних даних. Розроблено комплексну методику тестування, яка охоплює юніт-тестування з покриттям коду 82% для критичних компонентів, інтеграційне тестування з 150 тестовими сценаріями, функціональне тестування через 25 наскрізних use cases. Проведено тестування продуктивності на наборі даних з 10000 дисциплін, 200 освітніх програм та 1000 викладачів. Результати показали середній час відповіді 145 мс для простих запитів, 420 мс для складних запитів з множинними JOIN, пропускну здатність 180 запитів/секунду на одному інстансі API. Навантажувальне тестування підтвердило стабільну роботу системи при 500 одночасних користувачах з частотою помилок менше 0.05%. Розроблена архітектура бази даних та програмний інтерфейс забезпечують ефективне управління каталогом навчальних дисциплін з дотриманням сучасних стандартів проектування інформаційних систем. Результати тестування підтверджують відповідність системи встановленим вимогам щодо продуктивності, надійності та безпеки, що свідчить про готовність до практичного впровадження у закладах вищої освіти. Перспективи подальших досліджень включають розробку механізмів інтелектуального аналізу даних каталогу для автоматичного виявлення проблем у навчальних планах, створення рекомендаційної системи для формування індивідуальних освітніх траєкторій студентів, інтеграцію з системами машинного навчання для прогнозування попиту на дисципліни та оптимізації ресурсів університету.
URI: https://er.chdtu.edu.ua/handle/ChSTU/6576
Appears in Collections:174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

Files in This Item:
File Description SizeFormat 
М_174_2025_Булавко.pdf
  Restricted Access
1.99 MBAdobe PDFView/Open Request a copy


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ  
КОМП’ЮТЕРНИХ СИСТЕМ 
 
 
 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
освітнього ступеню «магістр» 
 
на тему: ДОСЛІДЖЕННЯ ЗАСОБІВ ПРОЕКТУВАННЯ 
ТА РОЗРОБКИ БАЗ ДАНИХ КАТАЛОГУ ДИСЦИПЛІН 
 
 
 
 
Виконав:  здобувач вищої освіти 2 курсу, 
групи МАКІТ-2409 
спеціальності 174 Автоматизація, 
комп’ютерно-інтегровані технології та 
робототехніка  
(освітня програма «Автоматизація та 
комп’ютерно-інтегровані системи та 
компоненти») 
  Булавко Костянтин Михайлович  
(Прізвище ім’я по-батькові)   
 
Керівник   Лукашенко Валентина Максимівна  
(Прізвище ім’я по-батькові)    
 
Рецензент         
   (Прізвище ім’я по-батькові)   
 
 
 
Черкаси 2025 року  
 
 
ЗМІСТ 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ .............................................. 3 
РОЗДІЛ 1 АНАЛІЗ СТАНУ ПРЕДМЕТНОЇ ОБЛАСТІ  ТА 
ОБҐРУНТУВАННЯ ЗАДАЧІ ДОСЛІДЖЕННЯ ......................................... 7 
1.1. Дослідження існуючих систем каталогізації навчальних дисциплін, 
сучасних засобів проектування та їх недоліків ................................................ 7 
1.2. Обґрунтування доцільності розробки нової архітектури бази даних для 
каталогу дисциплін ........................................................................................... 13 
1.3. Формування вимог до системи та постановка задачі дослідження ...... 20 
Висновки до першого розділу .......................................................................... 26 
РОЗДІЛ 2 РОЗРОБКА МАТЕМАТИЧНИХ МОДЕЛЕЙ  ТА 
АЛГОРИТМІВ ДЛЯ ПРОЕКТУВАННЯ БАЗИ ДАНИХ ........................ 29 
2.1. Математична модель оптимізації структури реляційної бази даних .... 29 
2.2. Алгоритми нормалізації та індексування для забезпечення 
продуктивності .................................................................................................. 36 
2.3. Методи забезпечення транзакційної цілісності та узгодженості даних 49 
Висновки до другого розділу ........................................................................... 62 
РОЗДІЛ 3 ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ............................................................................................ 65 
3.1. Вибір технологічного стеку та обґрунтування архітектурних рішень . 65 
3.2. Розробка концептуальної, логічної та фізичної моделей бази даних ... 73 
3.3. Реалізація API та методів доступу до даних ........................................... 77 
3.4. Методика тестування та оцінка ефективності розробленої системи .... 84 
Висновки до третього розділу .......................................................................... 90 
ВИСНОВКИ ..................................................................................................... 93 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................... 97 
 
  
2 
 
 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ 
Актуальність дослідження сучасні заклади вищої освіти 
функціонують в умовах стрімкої цифровізації освітніх процесів та 
зростаючих вимог до якості управління навчальною інформацією. 
Ефективне управління каталогом навчальних дисциплін є критично 
важливим для забезпечення прозорості освітнього процесу, формування 
індивідуальних траєкторій навчання студентів та відповідності освітніх 
програм національним і міжнародним стандартам. 
Однак аналіз існуючих інформаційних систем управління навчальним 
процесом виявляє наявність суттєвих недоліків у архітектурі баз даних, що 
використовуються для каталогізації дисциплін. Зокрема, спостерігаються 
проблеми з продуктивністю при роботі з великими обсягами даних, 
недостатня гнучкість для адаптації до специфічних потреб різних 
університетів, обмежена підтримка складних залежностей між 
дисциплінами та компетентнісного підходу, слабка інтеграція з іншими 
системами університету. 
Ці недоліки призводять до зниження ефективності управління 
навчальним процесом, ускладнюють процедури акредитації освітніх 
програм, обмежують можливості впровадження інноваційних педагогічних 
підходів. У зв'язку з цим розробка нової архітектури бази даних для каталогу 
навчальних дисциплін, яка враховуватиме виявлені проблеми та 
забезпечить відповідність сучасним вимогам до освітніх інформаційних 
систем, є актуальною науково-практичною задачею. 
Зв'язок роботи з науковими програмами, планами, темами  
Основні дослідження представленні в магістерській роботі 
проводилося відповідно до державних планів науково дослідних робіт, 
програм і договорів що виконувалися в Черкаському державному 
технологічному університеті які пов’язані з напрямком дисертаційного 
3 
 
 
дослідження: Моделі локальних підсистем, керування лазерним 
випромінюванням, для рішення траєкторних задач на базі таблично-
алгоритмічно методів апаратурної реалізації в проблемно-орієнтованих 
системах. 
Мета і завдання дослідження. Метою магістерської роботи є 
розробка оптимізованої архітектури бази даних каталогу навчальних 
дисциплін, що забезпечує високу продуктивність, цілісність даних, 
гнучкість та можливість інтеграції з іншими інформаційними системами 
університету. 
Для досягнення поставленої мети визначено такі задачі: 
1. провести аналіз існуючих систем каталогізації навчальних 
дисциплін, виявити їх недоліки та сформулювати вимоги до нової 
архітектури бази даних; 
2. розробити математичні моделі оптимізації структури реляційної 
бази даних з урахуванням специфіки предметної області каталогу 
дисциплін; 
3. створити алгоритми нормалізації та індексування, що забезпечують 
оптимальний баланс між цілісністю даних та продуктивністю системи; 
4. розробити методи забезпечення транзакційної цілісності та 
узгодженості даних при конкурентному доступі множини користувачів; 
5. спроектувати концептуальну, логічну та фізичну моделі бази даних 
з детальною специфікацією всіх сутностей, атрибутів та зв'язків; 
6. реалізувати програмний інтерфейс доступу до даних на основі 
REST архітектури з необхідними механізмами безпеки та оптимізації; 
7. розробити методику тестування та провести оцінку ефективності 
розробленої системи на реалістичних наборах даних. 
Об'єкт дослідження – процеси проектування та розробки баз даних 
для каталогізації навчальних дисциплін. 
4 
 
 
Предмет дослідження – структура бази даних та методи доступу до 
інформації каталогу навчальних дисциплін. 
Методи дослідження Для досягнення поставленої мети використано 
такі методи: методи теорії реляційних баз даних – для проектування 
структури даних та обґрунтування рівня нормалізації; математичне 
моделювання – для оптимізації організації інформації та оцінки доцільності 
денормалізації; методи теорії алгоритмів – для розробки ефективних 
процедур індексування та обробки даних; методи теорії транзакцій – для 
забезпечення узгодженості даних при конкурентному доступі та реалізації 
протоколів блокування; методи об'єктно-орієнтованого проектування – для 
реалізації програмного інтерфейсу на основі патернів Repository та Service 
Layer; експериментальні методи – для оцінки продуктивності розробленої 
системи через навантажувальне тестування. 
Наукова новизна одержаних результатів. 
1. Вперше запропоновано математичну модель оптимізації структури 
реляційної бази даних для каталогу навчальних дисциплін, яка, на відміну 
від існуючих підходів, враховує профіль навантаження системи та дозволяє 
кількісно обґрунтовувати рішення щодо нормалізації, денормалізації та 
індексування через коефіцієнти частоти операцій читання/запису. 
2. Удосконалено алгоритми селективної денормалізації шляхом 
введення критеріїв оцінки доцільності денормалізації, що, на відміну від 
існуючих евристичних підходів, враховують як переваги для 
продуктивності читання, так і вартість підтримки надмірності даних при 
операціях модифікації. 
3. Запропоновано архітектуру API для доступу до даних каталогу 
дисциплін, яка забезпечує оптимальний баланс між гнучкістю інтерфейсу та 
продуктивністю через багаторівневе кешування з використанням Redis та 
асинхронну обробку ресурсоємних операцій. 
5 
 
 
Практичне значення одержаних результатів. Розроблена 
архітектура бази даних та програмний інтерфейс можуть бути використані 
закладами вищої освіти для створення або модернізації систем управління 
навчальним процесом. Практична цінність роботи полягає у наданні 
детальної специфікації структури даних (15 основних та 8 асоціативних 
таблиць, 25 індексів, 12 тригерів, 8 збережених процедур), яка може 
служити основою для впровадження системи каталогізації дисциплін. 
Впровадження результатів забезпечить покращення якості управління 
освітньою інформацією, зменшення часу на адміністративні процедури, 
підвищення прозорості освітнього процесу для всіх зацікавлених сторін. 
Результати дослідження можуть застосовуватися як у державних, так 
і приватних університетах, а також в організаціях, що займаються 
розробкою програмного забезпечення для освітньої галузі. Модульна 
архітектура системи дозволяє поетапне впровадження з можливістю 
адаптації до специфічних потреб конкретного навчального закладу. 
Структура та обсяг роботи. Магістерська робота складається із 
загальної характеристики роботи, трьох розділів, висновків та списку 
використаних джерел. Обсяг роботи складає 98 сторінок. Робота містить 12 
рисунків та 11 таблиць. Список використаних джерел включає 44 
найменування. 
 
  
6 
 
 
РОЗДІЛ 1 
АНАЛІЗ СТАНУ ПРЕДМЕТНОЇ ОБЛАСТІ  
ТА ОБҐРУНТУВАННЯ ЗАДАЧІ ДОСЛІДЖЕННЯ 
1.1. Дослідження існуючих систем каталогізації навчальних 
дисциплін, сучасних засобів проектування та їх недоліків 
Аналіз сучасного стану інструментарію для проектування баз даних 
освітніх систем виявляє парадоксальну ситуацію: попри стрімкий розвиток 
технологій штучного інтелекту та появу принципово нових підходів до 
моделювання даних, переважна більшість діючих систем управління 
навчанням продовжує функціонувати на архітектурних рішеннях 
десятирічної давності. Це створює розрив між можливостями сучасних 
СУБД та їх фактичним використанням в освітній сфері. 
Традиційні LMS-платформи: накопичений технічний борг 
Платформа Moodle, що обслуговує понад 418 мільйонів користувачів 
у світі, демонструє типові проблеми «органічно вирощених» систем. Її база 
даних налічує понад 470 таблиць — результат двадцятирічної еволюції без 
радикального рефакторингу [1]. Практичні виміри на інсталяціях 
середнього розміру засвідчують: запити до підсистеми повідомлень можуть 
генерувати складні JOIN-операції через 12-15 таблиць, що при навантаженні 
понад 500 одночасних користувачів призводить до деградації часу відгуку з 
189 мс до 3-4 секунд [2]. 
Характерно, що офіційна документація Moodle містить 
попередження: «будьте вкрай обережні, якщо бачите код бази даних 
всередині циклу» [3] — це свідчить про усвідомлення проблеми на рівні 
спільноти розробників, проте системне її вирішення потребувало б 
переписування значної частини кодової бази. 
Canvas LMS, що позиціонується як сучасніша альтернатива та 
контролює 41% ринку LMS у Північній Америці [4], успадкувала філософію 
7 
 
 
жорсткої ієрархічної класифікації контенту. Такий підхід входить у 
конфлікт із сучасними освітніми практиками, де одна дисципліна може 
одночасно належати до кількох освітніх програм різних рівнів, формувати 
компетентності з різних галузей знань та мати варіативні пререквізити 
залежно від траєкторії студента. Реалізація такої гнучкості в Canvas 
потребує або дублювання записів, або створення складної системи 
«віртуальних» курсів — обидва варіанти генерують проблеми 
консистентності. 
Blackboard Learn, що займає 17% північноамериканського освітнього 
ринку [4], несе тягар архітектурних рішень ери монолітних enterprise-
систем. Аналіз структури даних виявляє порушення базових принципів 
нормалізації: атрибути курсу зберігаються у множині таблиць без 
механізмів референційної синхронізації. За оцінками незалежних аудитів, 
коефіцієнт дублювання даних сягає 20-25%, що не лише неефективно з 
точки зору зберігання, але й створює ризики неузгодженості при 
паралельних модифікаціях. 
Вітчизняні системи класу «АСУ ВНЗ» переважно базуються на 
архітектурних патернах попередніх десятиліть. Типовими ознаками є: 
денормалізовані структури з транзитивними залежностями, відсутність 
композитних індексів для типових сценаріїв використання, ігнорування 
механізмів партиціонування для історичних даних. Практичним наслідком 
стає неприйнятна латентність формування звітності — консолідовані запити 
за навчальний рік можуть виконуватися від кількох хвилин до десятків 
хвилин. 
Нова парадигма: AI-асистовані засоби проектування баз даних 
Принципово новим явищем 2024-2025 років стала поява інструментів, 
що використовують великі мовні моделі для автоматизації проектування 
схем баз даних. Gartner прогнозує, що до 2025 року системи управління 
8 
 
 
базами даних з вбудованим штучним інтелектом стануть нормою [5]. Цей 
клас засобів радикально змінює сам процес моделювання — від ручного 
креслення ER-діаграм до діалогу з AI-асистентом природною мовою. 
ChartDB Agent реалізує концепцію «pair programming з експертом-
архітектором баз даних» [6]. Інструмент трансформує текстові описи у 
production-ready DDL-оператори з урахуванням контексту предметної 
області. Промпт «мені потрібна таблиця користувачів з email, хешем пароля 
та часовими мітками» генерує повний SQL з відповідними типами даних, 
обмеженнями та індексами. Важливо, що система розуміє доменну 
специфіку: згадка «e-commerce orders» автоматично призводить до 
створення полів order_id, customer_id, total_amount, order_status без явної 
специфікації. 
Xano AI пропонує no-code підхід до створення backend-архітектури з 
вбудованою PostgreSQL базою даних [7]. AI Database Assistant цієї 
платформи здатен побудувати повну схему бази даних з одного промпта, 
критикувати існуючі проектні рішення та динамічно оновлювати схеми з 
дотриманням best practices моделювання даних. Для освітніх проєктів це 
означає можливість швидкого прототипування — від концепції до 
працюючої бази даних за години замість тижнів. 
DB Designer з функцією «Generate with AI» дозволяє описувати 
структуру бази даних будь-якою мовою, включаючи українську [8]. Система 
автоматично будує таблиці та зв'язки, підтримує live-валідацію для 
виявлення помилок у реальному часі, експортує результат у SQL-скрипти 
або візуальні діаграми. Проєкти автоматично зберігаються з повною 
історією версій, що особливо цінно для ітеративного вдосконалення схеми. 
AI2SQL спеціалізується на генерації схем з природномовних описів з 
акцентом на автоматичний вивід типів даних та створення індексів для часто 
запитуваних полів [9]. Приклад промпта: «Create a blog system with users, 
9 
 
 
posts, and comments. Users can write multiple posts and comments. Each post 
can have many comments» — результатом є повна нормалізована схема з 
відповідними зовнішніми ключами та каскадними правилами. 
Критичний аналіз AI-засобів виявляє як переваги, так і обмеження. До 
переваг належать: драматичне скорочення часу первинного проектування, 
автоматичне застосування best practices, зниження бар'єру входу для 
фахівців без глибокої експертизи в моделюванні даних. Водночас 
спостерігаються обмеження: генеровані схеми потребують ручної 
верифікації експертом предметної області, складні бізнес-правила часто 
вимагають ітеративного уточнення промптів, оптимізація під специфічне 
навантаження залишається задачею людини-архітектора. 
Еволюція стандартів: SQL:2023 та графові можливості 
реляційних СУБД 
Публікація у червні 2023 року нової редакції стандарту SQL 
ознаменувала включення Part 16: Property Graph Queries (SQL/PGQ) — 
можливості виконувати графові запити безпосередньо в реляційних базах 
даних [10]. Для предметної області каталогу навчальних дисциплін це має 
безпосереднє практичне значення: мережа пререквізитів, корреквізитів та 
еквівалентних курсів природно моделюється як граф, а SQL/PGQ дозволяє 
запитувати такі структури без міграції на спеціалізовані графові СУБД. 
Приклад практичного застосування: задача «знайти всі дисципліни, 
які є транзитивними пререквізитами для курсу X» традиційно вимагає 
написання рекурсивних CTE з обережною обробкою циклів. SQL/PGQ 
дозволяє виразити це декларативно через синтаксис pattern matching: 
sql 
SELECT DISTINCT prereq.name 
FROM GRAPH_TABLE (curriculum_graph 
  MATCH (target:Course WHERE target.code = 'CS401') 
10 
 
 
        <-[:PREREQUISITE]-{1,10}(prereq:Course) 
  COLUMNS (prereq.name) 
) AS result; 
Oracle Database 23ai став першою комерційною СУБД з повною 
підтримкою SQL/PGQ [11]. PostgreSQL має експериментальну реалізацію у 
версії 18 (очікується стабілізація у 2025 році) [12]. DuckDB через 
розширення DuckPGQ пропонує SQL/PGQ для аналітичних сценаріїв [13]. 
Ця конвергенція реляційної та графової парадигм є одним з найзначиміших 
трендів у розвитку баз даних поточного десятиліття. 
PostgreSQL 17: нові можливості для освітніх систем 
Реліз PostgreSQL 17 у вересні 2024 року приніс низку вдосконалень, 
релевантних для систем каталогізації навчальних дисциплін [14]. 
PostgreSQL став найпопулярнішою базою даних серед розробників, 
випередивши MySQL з показником 55% використання у 2025 році [15]. 
Перероблена система управління пам'яттю для VACUUM суттєво покращує 
продуктивність обслуговування великих таблиць — критично важливо для 
систем з інтенсивним оновленням даних у періоди реєстрації на курси. 
Функція JSON_TABLE() дозволяє трансформувати JSON-дані у 
табличне представлення [14], що відкриває можливості для гібридного 
зберігання структурованих та напівструктурованих метаданих дисциплін. 
Наприклад, специфічні атрибути дисциплін різних типів (лекційні курси, 
лабораторні практикуми, курсові проєкти) можуть зберігатися у JSONB-
полі, залишаючись при цьому доступними для SQL-запитів через 
JSON_TABLE. 
Інкрементальні бекапи — feature, на яку спільнота чекала роками — 
радикально змінює стратегію резервного копіювання для великих освітніх 
баз даних [16]. Замість повного копіювання десятків гігабайт щоночі, 
11 
 
 
система фіксує лише зміни, що скорочує час бекапу та відновлення на 
порядок. 
Покращення логічної реплікації з підтримкою failover slots спрощує 
побудову відмовостійких конфігурацій [14] — університетські системи 
отримують enterprise-рівень доступності без enterprise-вартості комерційних 
СУБД. 
Векторні бази даних та AI-готовність освітніх систем 
Тренд 2024-2025 років, що не можна ігнорувати — інтеграція 
векторного пошуку у традиційні реляційні СУБД [17]. PostgreSQL через 
розширення pgvector, Oracle Database 23ai з вбудованою підтримкою AI 
Vector Search, MySQL 9.0 з vector data type — всі провідні СУБД рухаються 
у цьому напрямку. 
За даними Deloitte, близько 47% організацій прискорюють 
впровадження AI [5], що стимулює попит на векторні можливості баз даних. 
Для каталогу навчальних дисциплін це відкриває перспективу семантичного 
пошуку та AI-рекомендацій. Замість точного збігу ключових слів студент 
може описати, що хоче вивчити, природною мовою — система знайде 
семантично близькі дисципліни. Персоналізовані рекомендації на основі 
embedding-векторів профілю студента та контенту курсів — технологія, що 
переходить зі стадії експериментів до production-впроваджень. 
Проблематика та виклики 
Узагальнюючи аналіз, можна констатувати такі ключові проблеми 
існуючих систем каталогізації навчальних дисциплін: 
1. Технічний борг legacy-архітектур: переважна більшість діючих 
LMS несе тягар архітектурних рішень минулих десятиліть, що обмежує 
продуктивність та масштабованість. 
2. Розрив між можливостями СУБД та їх використанням: сучасні 
PostgreSQL, MySQL, Oracle пропонують потужний інструментарій (JSON-
12 
 
 
підтримка, партиціонування, повнотекстовий пошук, векторні операції), 
який залишається незадіяним у більшості освітніх систем. 
3. Відсутність підтримки графових залежностей: мережа 
пререквізитів та корреквізитів природно моделюється як граф, проте 
існуючі системи переважно ігнорують цей аспект або реалізують його 
неефективно. 
4. Недостатня інтероперабельність: слабка підтримка стандартів 
ECTS, відсутність уніфікованих API для обміну даними між системами 
різних університетів. 
5. Ігнорування AI-трендів: жодна з масових LMS-платформ поки 
не інтегрувала можливості генеративного AI для асистування у формуванні 
навчальних планів чи рекомендації дисциплін. 
Ці виклики формують об'єктивну потребу у розробці нової 
архітектури бази даних, яка б враховувала як накопичений досвід 
експлуатації існуючих систем, так і можливості сучасного технологічного 
стеку. 
 
1.2. Обґрунтування доцільності розробки нової архітектури бази 
даних для каталогу дисциплін 
Виявлені у попередньому підрозділі недоліки існуючих систем 
каталогізації навчальних дисциплін створюють об'єктивну потребу у 
розробці нової архітектури бази даних, яка забезпечить комплексне 
вирішення наявних проблем. Доцільність такої розробки обґрунтовується 
кількома ключовими факторами, що мають як теоретичне, так і практичне 
значення для розвитку інформаційних систем у сфері вищої освіти. 
Першим аргументом на користь розробки нової архітектури є 
необхідність підвищення продуктивності систем при роботі з великими 
обсягами даних. Сучасні університети пропонують сотні та тисячі 
13 
 
 
навчальних курсів, кожен з яких характеризується множиною атрибутів та 
зв'язків. Традиційні підходи до проектування баз даних не завжди 
забезпечують оптимальну швидкість виконання складних запитів у таких 
умовах [17]. Нова архітектура має грунтуватися на сучасних методах 
оптимізації, включаючи правильну нормалізацію, ефективну індексацію та 
використання матеріалізованих представлень для часто використовуваних 
запитів. 
Дослідження показують, що правильно спроектована структура бази 
даних може забезпечити підвищення швидкості виконання типових запитів 
у декілька разів порівняно з неоптимізованими рішеннями. Це має критичне 
значення для забезпечення позитивного користувацького досвіду, особливо 
в періоди пікового навантаження, такі як реєстрація на курси або 
формування розкладу [18]. 
Другим важливим фактором є необхідність забезпечення гнучкості та 
адаптивності системи до змінних вимог освітнього процесу. Вища освіта 
характеризується постійними змінами у навчальних програмах, появою 
нових форм навчання та еволюцією педагогічних підходів. Архітектура бази 
даних повинна бути достатньо гнучкою, щоб дозволяти додавання нових 
типів даних та модифікацію існуючих структур без необхідності 
масштабних переробок системи [19]. 
Застосування принципів об'єктно-орієнтованого проектування та 
патернів enterprise application architecture дозволяє створити модульну та 
розширювану систему. Це забезпечує можливість поетапного впровадження 
нової функціональності та легкої адаптації до специфічних потреб 
конкретного навчального закладу. 
Третім аргументом є необхідність забезпечення цілісності та 
консистентності даних на всіх рівнях системи. Інформація про навчальні 
дисципліни тісно пов'язана з множиною інших даних університету, 
14 
 
 
включаючи відомості про студентів, викладачів, аудиторний фонд та 
фінансові ресурси. Нова архітектура повинна реалізувати комплексну 
систему обмежень цілісності, тригерів та процедур валідації, що 
гарантуватиме несуперечливість даних навіть при складних транзакціях, які 
охоплюють множину таблиць [20]. 
Дослідження випадків порушення цілісності даних в існуючих 
системах показують, що значна частина помилок у навчальних планах є 
наслідком недостатнього контролю на рівні бази даних. Це призводить до 
серйозних проблем у організації навчального процесу та може негативно 
впливати на академічну репутацію закладу освіти. 
Четвертим фактором є необхідність забезпечення безпеки та 
конфіденційності даних відповідно до сучасних вимог законодавства про 
захист персональних даних, зокрема GDPR. Нова архітектура має включати 
багаторівневу систему контролю доступу, шифрування чутливих даних та 
механізми аудиту всіх операцій з базою даних [21]. Це особливо важливо з 
огляду на те, що інформація про навчальні дисципліни часто містить 
персональні дані студентів та викладачів. 
Впровадження концепції security-by-design на етапі проектування бази 
даних дозволяє створити систему, яка за замовчуванням захищена від 
найпоширеніших типів атак. Це включає захист від SQL-ін'єкцій, 
несанкціонованого доступу та витоку даних. 
П'ятим аргументом є потреба у забезпеченні інтероперабельності з 
іншими системами та відповідності міжнародним стандартам. Сучасні 
університети використовують множину різних інформаційних систем, які 
повинні ефективно взаємодіяти між собою [22]. Нова архітектура бази 
даних має передбачати стандартизовані інтерфейси для обміну даними та 
підтримку загальноприйнятих форматів опису навчальних дисциплін. 
15 
 
 
Відповідність стандартам, таким як IMS Common Cartridge або IEEE 
Learning Object Metadata, забезпечує можливість інтеграції з широким 
спектром освітніх платформ та репозиторіїв. Це особливо важливо в 
контексті розвитку відкритої освіти та академічної мобільності. 
Шостим фактором є необхідність підтримки аналітичних 
можливостей та формування звітності. Сучасні заклади освіти все більше 
орієнтуються на підходи до управління, засновані на аналізі даних. 
Правильно спроектована структура бази даних повинна забезпечувати 
ефективне виконання аналітичних запитів, формування звітності та 
можливість реалізації алгоритмів для прогнозування попиту на дисципліни, 
оптимізації навчальних планів та персоналізації рекомендацій [23]. 
Дослідження показують, що університети, які використовують аналіз 
даних для управління навчальним процесом, демонструють вищу 
ефективність використання ресурсів. Це включає оптимізацію 
завантаженості викладачів, планування аудиторного фонду та формування 
більш збалансованих навчальних планів. 
Сьомим аргументом є необхідність забезпечення масштабованості 
системи. Зростання кількості студентів, розширення переліку освітніх 
програм та впровадження нових форматів навчання вимагає наявності 
архітектури, здатної ефективно масштабуватися [24]. Нова архітектура має 
враховувати можливість розподіленого зберігання даних, реплікації та 
забезпечення високої доступності системи. 
Особливої уваги заслуговує підтримка різних моделей розгортання, 
які стають все більш популярними у сфері освітніх технологій. Архітектура 
бази даних повинна бути придатною для розгортання як у традиційній 
локальній інфраструктурі, так і в хмарних середовищах, що забезпечує 
гнучкість у виборі оптимального рішення для конкретного навчального 
закладу [25]. Восьмим фактором є необхідність оптимізації витрат на 
16 
 
 
підтримку та експлуатацію системи. Правильно спроектована архітектура 
бази даних знижує складність адміністрування, зменшує потребу у 
висококваліфікованому персоналі та скорочує витрати на апаратне 
забезпечення. Це досягається через оптимізацію структури даних, 
зменшення надмірності інформації та впровадження автоматизованих 
механізмів управління [26]. 
Дев'ятим аргументом є потреба у забезпеченні підтримки сучасних 
парадигм освіти, таких як компетентнісний підхід, персоналізоване 
навчання та концепція навчання впродовж життя. Нова архітектура повинна 
відображати не просто формальні характеристики дисциплін, а й глибші 
семантичні зв'язки між курсами, компетентностями та результатами 
навчання. Це вимагає використання розширених методів моделювання, 
включаючи представлення складних зв'язків та ієрархій [27]. 
Впровадження таких підходів дозволяє створити інтелектуальну 
освітню екосистему, здатну автоматично рекомендувати оптимальні 
навчальні траєкторії студентам на основі їх цілей, попередніх досягнень та 
індивідуальних особливостей. Це відповідає сучасним трендам 
персоналізації освіти та підвищує ефективність навчального процесу. 
Десятим фактором є необхідність забезпечення підтримки 
багатомовності та мультикультурності. Сучасні університети залучають 
студентів з різних країн та пропонують програми різними мовами. 
Архітектура бази даних повинна ефективно підтримувати зберігання та 
обробку багатомовного контенту, забезпечувати коректну роботу з різними 
алфавітами та враховувати культурні особливості організації навчального 
процесу в різних країнах [28]. 
Важливим є також забезпечення правильної локалізації не тільки 
контенту, але й структури даних, оскільки різні освітні системи можуть мати 
суттєві відмінності у підходах до організації навчального процесу. Це 
17 
 
 
включає підтримку різних систем оцінювання, кредитних систем та 
форматів опису навчальних досягнень. Одинадцятим аргументом є 
необхідність забезпечення підтримки версійності та історичності даних. 
Навчальні програми та дисципліни постійно еволюціонують, і важливо мати 
можливість відстежувати всі зміни для цілей аудиту, акредитації та аналізу 
трендів [29]. Нова архітектура повинна реалізувати ефективні механізми 
зберігання історії змін без значного збільшення обсягу даних. 
Такий підхід також дозволяє адміністраторам переглядати стан 
каталогу дисциплін на будь-який момент у минулому. Це особливо корисно 
для розслідування інцидентів, пов'язаних з помилками у навчальних планах, 
та для проведення історичного аналізу еволюції освітніх програм. 
Дванадцятим фактором є потреба у забезпеченні підтримки 
колективного редагування та управління робочими процесами. Процес 
формування та оновлення інформації про навчальні дисципліни зазвичай 
включає участь багатьох зацікавлених сторін, включаючи викладачів, 
завідувачів кафедр, методистів та адміністраторів. Архітектура повинна 
підтримувати складні робочі процеси з різними етапами узгодження, 
можливістю коментування та механізмами вирішення конфліктів [30]. 
Впровадження таких механізмів на рівні бази даних забезпечує більшу 
надійність та консистентність порівняно з реалізацією робочих процесів 
виключно на рівні додатку. Це включає підтримку транзакцій та механізмів 
компенсаційних дій при відкаті складних операцій. 
Тринадцятим аргументом є необхідність забезпечення моніторингу 
продуктивності системи. Нова архітектура повинна включати вбудовані 
механізми збору метрик продуктивності, логування запитів та автоматичної 
оптимізації. Це дозволяє адміністраторам системи своєчасно виявляти 
проблеми з продуктивністю та приймати обґрунтовані рішення щодо 
оптимізації [31]. Впровадження принципів спостережуваності на рівні бази 
18 
 
 
даних забезпечує глибоке розуміння поведінки системи під навантаженням 
та дозволяє проактивно запобігати проблемам. Це особливо важливо для 
критичних періодів, таких як початок навчального року або реєстрація на 
курси. Чотирнадцятим фактором є потреба у забезпеченні підтримки різних 
сценаріїв розгортання та архітектурних патернів. Сучасні організації 
можуть мати різні вимоги щодо розгортання інформаційних систем. Нова 
архітектура повинна бути достатньо гнучкою для підтримки як традиційних 
монолітних розгортань, так і сучасних мікросервісних архітектур, де різні 
компоненти системи можуть використовувати окремі бази даних або навіть 
різні типи СУБД [32]. 
П'ятнадцятим аргументом є необхідність забезпечення підтримки 
подієво-орієнтованої архітектури. Сучасні освітні платформи все частіше 
потребують можливостей реагування на події у реальному часі. Це включає 
миттєві оновлення при внесенні змін до дисциплін, сповіщення про важливі 
події та синхронізацію даних між різними компонентами системи [33]. 
Архітектура бази даних повинна підтримувати механізми відстеження 
змін та їх трансляцію у подієво-орієнтовану інфраструктуру. Це забезпечує 
слабку зв'язаність між компонентами системи та підвищує її загальну 
стійкість до відмов. Шістнадцятим фактором є потреба у забезпеченні 
екологічної стійкості та енергоефективності. В умовах зростаючої уваги до 
екологічних питань, оптимізація інформаційних систем з точки зору 
енергоспоживання стає важливим фактором. Правильно спроектована 
архітектура бази даних може суттєво знизити потребу у обчислювальних 
ресурсах та, відповідно, енергоспоживання серверів [34]. 
Дослідження показують, що оптимізація структури даних та запитів 
може значно знизити енергоспоживання порівняно з неоптимізованими 
рішеннями. Це не лише зменшує операційні витрати, але й сприяє 
досягненню цілей сталого розвитку університету. 
19 
 
 
Таким чином, наведені аргументи переконливо обґрунтовують 
доцільність розробки нової архітектури бази даних для каталогу навчальних 
дисциплін. Така розробка дозволить комплексно вирішити виявлені 
проблеми існуючих систем та створити сучасну, продуктивну, безпечну та 
гнучку інформаційну систему, здатну ефективно підтримувати управління 
навчальним процесом у закладі вищої освіти. Практична реалізація 
запропонованої архітектури принесе відчутні переваги як для адміністрації 
університету, так і для викладачів та студентів. 
 
1.3. Формування вимог до системи та постановка задачі 
дослідження 
На основі проведеного аналізу існуючих систем каталогізації 
навчальних дисциплін та обґрунтування доцільності розробки нової 
архітектури бази даних необхідно сформулювати комплекс вимог до 
проектованої системи та чітко визначити задачі дослідження. Ці вимоги 
мають охоплювати функціональні, нефункціональні та технічні аспекти, 
забезпечуючи створення системи, яка відповідатиме сучасним потребам 
закладів вищої освіти. 
Функціональні вимоги до системи визначають базовий перелік 
можливостей, які повинна забезпечувати база даних каталогу навчальних 
дисциплін. По-перше, система має підтримувати повний життєвий цикл 
навчальної дисципліни від планування до архівування. Це включає 
можливість створення нових дисциплін, редагування існуючих, формування 
різних версій робочих програм та зберігання історичних даних для цілей 
аудиту та акредитації [6]. 
Система повинна забезпечувати збереження детальної інформації про 
кожну дисципліну, включаючи назву українською та англійською мовами, 
код дисципліни, обсяг у кредитах ECTS та годинах, розподіл годин за 
20 
 
 
видами занять, форми проміжного та підсумкового контролю, пререквізити 
та корреквізити. Окрім базових атрибутів, необхідна підтримка зберігання 
розширених метаданих відповідно до міжнародних стандартів, що 
забезпечить інтероперабельність з іншими освітніми системами. 
Важливою функціональною вимогою є підтримка компетентнісного 
підходу. База даних має зберігати інформацію про компетентності, які 
формує кожна дисципліна, їх рівні досягнення та зв'язки з результатами 
навчання. Це дозволить автоматизувати процес контролю відповідності 
освітніх програм вимогам стандартів та забезпечити прозорість у 
формуванні компетентностей випускників [5] . 
Система повинна підтримувати гнучку систему категоризації 
дисциплін за різними критеріями: за циклами підготовки, компонентами 
освітньої програми, кафедрами, галузями знань. При цьому необхідна 
можливість віднесення однієї дисципліни до декількох категорій одночасно, 
що відображає реальну міждисциплінарну природу сучасних навчальних 
курсів. 
Критичною функціональною вимогою є підтримка складних 
залежностей між дисциплінами. Система має дозволяти визначення різних 
типів зв'язків: обов'язкові пререквізити, рекомендовані пререквізити, 
корреквізити, взаємовиключні дисципліни, еквівалентні курси. Ці зв'язки 
мають автоматично враховуватися при формуванні індивідуальних 
навчальних планів студентів та перевірці можливості реєстрації на курси 
[37]. 
База даних повинна забезпечувати зберігання інформації про 
викладачів, які ведуть дисципліну, з можливістю вказання кількох 
викладачів для однієї дисципліни та розподілом між ними академічних 
годин. Необхідна також підтримка зберігання даних про навчально-
21 
 
 
методичне забезпечення дисципліни, включаючи силабуси, робочі 
програми, методичні вказівки, навчальні посібники та інші матеріали. 
Система має підтримувати різні типи дисциплін: нормативні, 
вибіркові, факультативні, а також різні форми проведення занять: 
традиційні аудиторні, дистанційні, змішані. Для кожного типу та форми 
повинні бути передбачені специфічні атрибути, що адекватно описують 
особливості організації навчального процесу [38]. 
Функціональна вимога щодо підтримки планування передбачає 
можливість формування перспективних та робочих навчальних планів, 
автоматичного розрахунку навчального навантаження викладачів, 
контролю збалансованості навчальних планів за семестрами та роками 
навчання. Система повинна виявляти конфлікти у плануванні та 
попереджати користувачів про потенційні проблеми. 
Важливою є вимога щодо підтримки багатомовності інтерфейсу та 
даних. Усі назви, описи та інші текстові поля повинні мати можливість 
зберігання принаймні двома мовами: українською та англійською, з 
можливістю розширення на інші мови за потреби. Це забезпечить підтримку 
міжнародних освітніх програм та академічної мобільності [39]. 
Нефункціональні вимоги визначають якісні характеристики системи, 
які не стосуються безпосередньо її функціональності, але мають критичне 
значення для успішної експлуатації. Першою з таких вимог є 
продуктивність системи. База даних повинна забезпечувати час відповіді не 
більше 2 секунд для типових запитів при одночасній роботі до 500 
користувачів. Складні аналітичні запити, що включають агрегацію даних по 
множині дисциплін, повинні виконуватися не довше 10 секунд [14]. 
Вимога масштабованості передбачає, що система повинна зберігати 
прийнятну продуктивність при зростанні кількості дисциплін до 50000 
записів, кількості освітніх програм до 1000 та кількості користувачів до 
22 
 
 
5000. Архітектура має дозволяти горизонтальне масштабування при 
необхідності обслуговування більших обсягів даних [27]. 
Надійність системи повинна забезпечувати коефіцієнт готовності не 
менше 99.5%, що означає допустимий час простою не більше 43 годин на 
рік. Система повинна включати механізми автоматичного резервного 
копіювання з можливістю відновлення даних з точністю до останньої 
транзакції. Час відновлення системи після відмови не повинен 
перевищувати 4 години [16]. 
Вимоги безпеки включають реалізацію багаторівневої системи 
автентифікації та авторизації, підтримку рольової моделі доступу з 
можливістю гнучкого налаштування прав для різних категорій 
користувачів. Усі операції з критичними даними повинні логуватися для 
можливості аудиту. Конфіденційні дані повинні зберігатися у 
зашифрованому вигляді відповідно до вимог стандарту AES-256 [43]. 
Вимога щодо зручності використання передбачає інтуїтивно 
зрозумілий інтерфейс доступу до даних через API, детальну документацію 
структури бази даних та наявність готових прикладів найбільш поширених 
запитів. Система повинна підтримувати стандартні протоколи та формати 
обміну даними для забезпечення легкої інтеграції з іншими системами 
університету. 
Вимога сумісності означає, що система повинна забезпечувати 
сумісність з основними реляційними СУБД, такими як PostgreSQL, MySQL, 
Oracle Database та Microsoft SQL Server. Структура бази даних повинна 
використовувати стандартні SQL конструкції та уникати специфічних для 
конкретної СУБД розширень там, де це можливо [44]. 
Технічні вимоги визначають конкретні технологічні рішення та 
підходи, які мають бути використані при проектуванні та реалізації бази 
даних. Структура бази даних повинна відповідати третій нормальній формі 
23 
 
 
з обґрунтованими винятками для підвищення продуктивності у випадках, 
коли денормалізація дає значний виграш у швидкості виконання запитів без 
суттєвого ризику порушення цілісності даних [45]. 
Усі таблиці повинні мати первинні ключі, переважно суррогатні, для 
забезпечення стабільності ідентифікації записів. Зовнішні ключі повинні 
бути визначені для всіх зв'язків між таблицями з відповідними правилами 
каскадного оновлення та видалення. Індекси повинні бути створені для всіх 
полів, що використовуються у WHERE клаузах, JOIN операціях та для 
сортування результатів [46]. 
Система повинна використовувати тригери для автоматичного 
виконання складної бізнес-логіки, що не може бути ефективно реалізована 
на рівні додатку. Це включає підтримку аудиту змін, автоматичне 
обчислення похідних значень та контроль складних бізнес-правил. 
Збережені процедури повинні використовуватися для інкапсуляції складних 
операцій, що включають множинні запити та потребують транзакційної 
узгодженості [47]. 
Вимога щодо підтримки версійності передбачає реалізацію механізмів 
temporal tables або аналогічних підходів для зберігання повної історії змін у 
критичних таблицях. Це дозволить відновлювати стан даних на будь-який 
момент часу та проводити історичний аналіз еволюції навчальних програм 
[48]. 
Система повинна включати механізми валідації даних на рівні бази 
даних через CHECK constraints, що забезпечують перевірку коректності 
значень атрибутів. Наприклад, кількість кредитів повинна бути додатним 
числом у визначеному діапазоні, розподіл годин за видами занять повинен 
відповідати загальному обсягу дисципліни тощо. 
На основі сформульованих вимог можна визначити конкретні задачі 
дослідження, вирішення яких необхідне для досягнення мети роботи. 
24 
 
 
Першою задачею є розробка концептуальної моделі даних для каталогу 
навчальних дисциплін, яка адекватно відображає предметну область з 
урахуванням специфіки організації навчального процесу у вітчизняних та 
зарубіжних закладах вищої освіти [49]. 
Другою задачею є розробка логічної моделі бази даних з детальним 
описом усіх сутностей, атрибутів та зв'язків, з обов'язковим доведенням 
відповідності моделі принципам нормалізації та обґрунтуванням прийнятих 
рішень щодо денормалізації у випадках, коли це доцільно для підвищення 
продуктивності. 
Третьою задачею є розробка фізичної моделі бази даних з 
визначенням типів даних для всіх атрибутів, стратегії індексування, правил 
цілісності та оптимізаційних рішень для забезпечення необхідної 
продуктивності системи при роботі з великими обсягами даних [50]. 
Четвертою задачею є розробка набору типових запитів до бази даних, 
що покривають основні сценарії використання системи, включаючи пошук 
дисциплін за різними критеріями, формування навчальних планів, 
розрахунок навантаження викладачів, генерацію звітності та аналітичних 
даних. 
П'ятою задачею є розробка алгоритмів забезпечення цілісності та 
консистентності даних, включаючи механізми валідації складних бізнес-
правил, контролю залежностей між дисциплінами та автоматичного 
виявлення конфліктів у навчальних планах. 
Шостою задачею є проектування системи безпеки з визначенням 
ролей користувачів, їх прав доступу до різних об'єктів бази даних та 
механізмів аудиту операцій для забезпечення відповідності вимогам захисту 
персональних даних. 
Сьомою задачею є розробка стратегії міграції даних з існуючих систем 
до нової бази даних, включаючи методи трансформації даних, валідації 
25 
 
 
після міграції та забезпечення мінімального часу простою системи під час 
переходу. 
Восьмою задачею є експериментальна оцінка продуктивності 
розробленої архітектури бази даних на тестових наборах даних різного 
обсягу з метою підтвердження відповідності системи встановленим 
вимогам та виявлення можливих вузьких місць. 
Дев'ятою задачею є розробка рекомендацій щодо підтримки та 
супроводу бази даних, включаючи процедури резервного копіювання, 
моніторингу продуктивності, планового обслуговування та оптимізації у 
міру зростання обсягів даних. 
Таким чином, сформульовані вимоги та задачі дослідження 
створюють чітку основу для подальшої роботи з проектування та реалізації 
ефективної архітектури бази даних для каталогу навчальних дисциплін, яка 
задовольнятиме потреби сучасних закладів вищої освіти та забезпечуватиме 
надійне, продуктивне та безпечне управління інформацією про навчальний 
процес. 
 
Висновки до першого розділу 
Отже, проведено комплексний аналіз стану предметної області, що 
дозволило виявити ключові проблеми існуючих систем каталогізації 
навчальних дисциплін та обґрунтувати необхідність розробки нової 
архітектури бази даних. 
Аналіз найпоширеніших систем управління навчальним процесом, 
таких як Moodle, Canvas LMS, Blackboard Learn, Studip та вітчизняних 
розробок, виявив ряд суттєвих недоліків. Серед основних проблем виділено 
недостатню оптимізацію структури даних, що призводить до зниження 
продуктивності при роботі з великими обсягами інформації, жорсткість 
архітектури, яка обмежує можливості адаптації до специфічних потреб 
26 
 
 
різних освітніх закладів, та недостатню підтримку міжнародних стандартів 
опису навчальних дисциплін. 
Встановлено, що більшість існуючих систем не забезпечують 
належної підтримки складних залежностей між дисциплінами, 
компетентнісного підходу та версійності навчальних програм. Виявлено 
також проблеми з інтеграцією з іншими інформаційними системами 
університету та недостатню увагу до питань безпеки даних на рівні бази 
даних. 
Обґрунтовано доцільність розробки нової архітектури бази даних, яка 
має вирішити виявлені проблеми через застосування сучасних підходів до 
проектування інформаційних систем. Визначено, що нова архітектура 
повинна забезпечувати високу продуктивність, гнучкість, масштабованість, 
надійність та безпеку при збереженні інтероперабельності з іншими 
системами та відповідності міжнародним стандартам. 
Сформульовано комплекс функціональних, нефункціональних та 
технічних вимог до проектованої системи. Функціональні вимоги 
охоплюють підтримку повного життєвого циклу дисциплін, 
компетентнісного підходу, складних залежностей, багатомовності та різних 
типів навчальних курсів. Нефункціональні вимоги визначають необхідні 
показники продуктивності, надійності, безпеки та зручності використання. 
Технічні вимоги специфікують підходи до нормалізації, індексування, 
забезпечення цілісності та версійності даних. 
На основі проведеного аналізу сформульовано дев'ять конкретних 
задач дослідження, які охоплюють весь цикл проектування бази даних від 
концептуальної моделі до експериментальної оцінки продуктивності та 
розробки рекомендацій щодо супроводу системи. 
Результати першого розділу створюють міцну теоретичну та 
методологічну основу для подальших етапів дослідження, спрямованих на 
27 
 
 
розробку ефективної архітектури бази даних для каталогу навчальних 
дисциплін, яка відповідатиме сучасним вимогам цифрової трансформації 
вищої освіти. 
 
 
 
 
  
28 
 
 
РОЗДІЛ 2 
РОЗРОБКА МАТЕМАТИЧНИХ МОДЕЛЕЙ  
ТА АЛГОРИТМІВ ДЛЯ ПРОЕКТУВАННЯ БАЗИ ДАНИХ 
2.1. Математична модель оптимізації структури реляційної бази 
даних 
Проектування бази даних для каталогу навчальних дисциплін вимагає 
системного підходу до балансування між теоретично обґрунтованою 
структурою та практичною продуктивністю системи. Класичний підхід 
базується на теорії нормалізації, проте механічне застосування нормальних 
форм часто призводить до субоптимальних результатів з точки зору 
швидкодії. 
У контексті розробленої системи база даних включає кілька основних 
відношень: дисципліни, освітні програми, викладачі, компетентності та 
зв'язки між ними. Формально, реляційну структуру можна представити як 
кінцеву множину відношень  
R = {R₁, R₂, ..., Rₙ}, де кожне відношення Rᵢ є підмножиною 
декартового добутку доменів відповідних атрибутів. 
Для відношення "Дисципліна" схема визначається як: схему 
зображено на рисунку 2.1 
 
Рис. 2.1 – Оптимізована реляційна структура каталогу навчальних 
дисциплін 
29 
 
 
S(Дисципліна) = {ID_дисципліни, Код, Назва_UA, Назва_EN, 
Кредити_ECTS, Загальні_години, Лекції, Практичні, Лабораторні, 
Самостійна_робота, Форма_контролю, Семестр, ID_кафедри},  
Функціональні залежності та нормалізація 
Фундаментом структурної оптимізації слугує виявлення та 
формалізація функціональних залежностей — інваріантних співвідношень 
між атрибутами, що відображають семантику предметної області. У 
термінах реляційної алгебри залежність X → Y фіксує детермінованість 
значень атрибутів Y значеннями атрибутів X для довільної пари кортежів 
відношення. Для сутності "Дисципліна" каталогу навчальних курсів 
ідентифіковано такі залежності: сурогатний ідентифікатор однозначно 
визначає всю сукупність описових характеристик курсу, водночас 
природний ключ у формі кодифікатора дисципліни також володіє 
властивістю унікальної ідентифікації, зображено на табл. 2.1 
Таблиця 2.1 
Схема функціональних залежностей для сутності “Дисципліна” 
 
30 
 
 
Наявність альтернативних ключів потребує обґрунтованого вибору 
первинного ідентифікатора з урахуванням стабільності значень та 
ефективності індексування 
Критерієм достатньої нормалізації для систем операційної обробки 
транзакцій традиційно вважається третя нормальна форма. Її досягнення 
гарантує елімінацію транзитивних залежностей неключових атрибутів, що є 
джерелом аномалій модифікації даних.  
Формально відношення відповідає 3НФ за умови, що кожна 
нетривіальна залежність або породжується суперключем, або її права 
частина є підмножиною деякого кандидатного ключа.  
Приведення до цільової форми реалізується ітеративною 
декомпозицією вихідного відношення із застосуванням операції проекції, 
причому коректність процедури верифікується збереженням властивості 
з'єднання без втрат та покриття множини залежностей. 
Однак досвід проектування показує, що строга нормалізація має свою 
ціну у вигляді збільшення кількості операцій з'єднання (JOIN), які є 
найбільш ресурсомісткими в реляційних СУБД. 
Модель оцінки продуктивності 
Для обґрунтованого прийняття рішень щодо структури розроблено 
модель оцінки вартості виконання запитів. Нехай Q = {q₁, q₂, ..., qₖ} 
представляє множину типових запитів до системи, а f(qᵢ) визначає частоту 
виконання запиту qᵢ. Загальна вартість обробки описується функцією: 
C_total = Σᵢ₌₁ᵏ f(qᵢ) · c(qᵢ, D) 
де c(qᵢ, D) відображає вартість виконання запиту qᵢ при конкретній 
структурі D бази даних. 
На основі аналізу реальних запитів системи виявлено, що найчастіше 
виконуються операції перегляду списків дисциплін та інформації про 
конкретні дисципліни, тоді як статистичні звіти формуються значно рідше. 
31 
 
 
Кількісна оцінка обчислювальної складності операції з'єднання базується на 
моделі, що враховує потужності операндів та характеристики предиката 
еквіз'єднання.  
Для відношень R₁ та R₂ вартість визначається добутком їх 
кардинальностей, скоригованим на фактор селективності з'єднувального 
предиката.  
Останній параметр відображає частку кортежів декартового добутку, 
що задовольняють умову з'єднання, і обчислюється на основі статистики 
розподілу значень ключових атрибутів. Для з'єднань за зовнішнім ключем 
фактор селективності апроксимується оберненою величиною до кількості 
унікальних значень референційного атрибута, що дозволяє прогнозувати 
розмір результуючого відношення без матеріалізації проміжних даних. 
Задача оптимізації формулюється як мінімізація загальної вартості 
при дотриманні обмежень цілісності та підтримки необхідного рівня 
нормалізації. 
Селективна денормалізація 
Практичний досвід експлуатації системи показав доцільність 
застосування селективної денормалізації для часто виконуваних запитів. 
Критерій прийняття рішення про денормалізацію відношень R₁ та R₂ 
визначається нерівністю: 
Σᵢ f(qᵢ) · [c_join(R₁, R₂) - c_scan(R₁⋈R₂)] > c_redundancy(R₁⋈R₂) 
де c_redundancy характеризує вартість підтримки надмірності даних, 
включаючи додатковий простір та витрати на забезпечення узгодженості 
при оновленнях, критерії зображено в таблиці 2.2 
 
 
 
 
32 
 
 
Таблиця 2.2 
Критерії прийняття рішень щодо денормалізації та індексування 
 
У розробленій системі, наприклад, назва кафедри дублюється в 
таблиці дисциплін, що усуває необхідність виконання з'єднання при 
кожному запиті інформації про дисципліну. Хоча це створює певну 
надмірність, аналіз показав виграш у продуктивності для типових операцій. 
Стратегія індексування 
Ефективність індексування визначається балансом між прискоренням 
читання та уповільненням операцій модифікації даних. Аналіз патернів 
доступу виявив атрибути, що найчастіше використовуються у WHERE-
клаузах та умовах з'єднання. Для атрибута Aⱼ рішення про створення індексу 
приймається на основі співвідношення: 
w(Aⱼ) · b_scan(Rᵢ) > c_index(Aⱼ) + w(Aⱼ) · b_index(Aⱼ) 
де w(Aⱼ) — сумарна частота використання атрибута, b_scan(Rᵢ) та 
b_index(Aⱼ) — середній час сканування та пошуку за індексом відповідно. 
Важливим фактором є селективність атрибута, що визначається як 
відношення кількості унікальних значень до загальної кількості записів: 
sel(Aⱼ) = |πₐⱼ(Rᵢ)| / |Rᵢ| 
Для складених індексів порядок атрибутів має критичне значення: 
атрибути з більшою селективністю розміщуються на початку для 
33 
 
 
максимальної ефективності фільтрації. У системі створено складені індекси 
на поєднання ID_освітньої_програми та Семестр, оскільки ці атрибути часто 
використовуються разом у запитах вибірки дисциплін за програмою та 
семестром. 
Таблиці зв'язків та партиціонування 
Для відношень типу "багато до багатьох", зокрема зв'язку між 
дисциплінами та компетентностями, створено індекси на обидва зовнішні 
ключі. Це забезпечує ефективний пошук як у напрямку "компетентності 
дисципліни", так і "дисципліни компетентності". 
Партиціонування великих таблиць здійснюється з метою обробки 
лише релевантних фрагментів даних. Для множини партицій P = {P₁, P₂, ..., 
Pₘ} відношення R, де R = ⋃ᵢ₌₁ᵐ Pᵢ та Pᵢ ∩ Pⱼ = ∅ для i ≠ j, оптимізація 
спрямована на мінімізацію міжпартиційних запитів: 
min Σᵢ₌₁ᵏ f(qᵢ) · cross_partition(qᵢ, P) 
У контексті каталогу дисциплін природним підходом є розділення за 
освітніми програмами або навчальними роками, що відповідає типовим 
патернам доступу до даних. 
Забезпечення цілісності даних 
Референційна цілісність формалізується через обмеження на зовнішні 
ключі. Для зовнішнього ключа F у відношенні R₁, що посилається на 
первинний ключ K у відношенні R₂, виконується умова: 
∀t₁ ∈ R₁: (t₁[F] ≠ NULL) ⇒ (∃t₂ ∈ R₂: t₁[F] = t₂[K]) 
Система автоматично контролює ці обмеження та визначає стратегії 
каскадних операцій при видаленні або оновленні батьківських записів. 
Для підтримки історичності даних запроваджено темпоральний підхід 
з розширенням схеми атрибутами Valid_From та Valid_To. Запит до 
актуальної версії даних формується як селекція з умовою перетину часових 
інтервалів з поточним моментом T_current: 
34 
 
 
RT_current = σ_{Valid_From ≤ T_current ∧ Valid_To > T_current}(RT) 
Це дозволяє відстежувати зміни характеристик дисциплін протягом 
часу без втрати історичної інформації. 
Оцінка обсягу даних 
Планування апаратних ресурсів базується на оцінці обсягу даних з 
урахуванням розміру як самих відношень, так і індексних структур. Для 
відношення Rᵢ обсяг визначається як: 
Size(Rᵢ) = |Rᵢ| · (Σⱼ₌₁ᵐ size(Aⱼ) + overhead) 
Загальний обсяг системи включає індекси: 
Size_total = Σᵢ₌₁ⁿ Size(Rᵢ) + Σᵢ₌₁ⁿ Σⱼ∈Indexed(Rᵢ) Size_index(Rᵢ, Aⱼ) 
Практичні розрахунки показали, що індекси займають приблизно 40-
60% від обсягу базових таблиць, що важливо враховувати при плануванні 
дискового простору. 
Оптимізація запитів 
Оптимізація виконання запитів грунтується на алгебрі відношень та 
застосуванні еквівалентних перетворень. Основні правила включають 
проштовхування селекції через операції з'єднання, що дозволяє зменшити 
обсяг проміжних даних: 
σₚ(R ⋈ S) = σₚ(R) ⋈ S, якщо предикат p стосується лише атрібутів R 
Досвід роботи з реальними запитами системи підтвердив, що 
застосування фільтрації перед операціями з'єднання суттєво покращує 
продуктивність, особливо для великих відношень. Застосування 
математичних методів оптимізації структури реляційної бази даних 
дозволило знайти практичний компроміс між теоретичною коректністю 
нормалізації та реальною продуктивністю системи каталогу навчальних 
дисциплін. Розроблені моделі оцінки вартості запитів, критерії селективної 
денормалізації та стратегії індексування забезпечили обґрунтоване 
прийняття проектних рішень. Подальший моніторинг експлуатаційних 
35 
 
 
характеристик підтверджує адекватність обраних підходів для специфіки 
предметної області. 
 
2.2. Алгоритми нормалізації та індексування для забезпечення 
продуктивності 
Процес нормалізації структури бази даних становить критично 
важливий елемент забезпечення цілісності даних та мінімізації 
інформаційної надмірності. Водночас механістичне застосування принципів 
нормалізації без урахування аспектів продуктивності може призвести до 
формування неефективної архітектури системи. У даному підрозділі 
представлено систематичний підхід до алгоритмізації процесів нормалізації 
з урахуванням компромісів між нормалізацією та продуктивністю, а також 
методи оптимального індексування реляційних структур. 
Формалізація процесу нормалізації до третьої нормальної форми 
Алгоритм приведення реляційного відношення до третьої нормальної 
форми формалізується наступною послідовністю операцій. 
Алгоритм 2.1. Нормалізація до третьої нормальної форми (3НФ) 
Вхідні дані: Відношення R зі схемою S(R) та множиною 
функціональних залежностей F Вихідні дані: Множина відношень R' у 3НФ 
1. Перевірка відповідності першій нормальній формі (1НФ) 
шляхом верифікації атомарності всіх атрибутів відношення. У разі 
виявлення складених атрибутів здійснюється їх декомпозиція на атомарні 
компоненти. 
2. Ідентифікація ключових структур відношення через обчислення 
замикань атрибутів для всіх підмножин S(R) та визначення мінімальних 
множин атрибутів, замикання яких покриває повну множину атрибутів 
схеми. 
36 
 
 
3. Верифікація відповідності другій нормальній формі (2НФ): для 
кожного неключового атрибута A та кожного ключа K перевіряється 
відсутність часткової функціональної залежності. У разі виявлення X ⊂ K 
такого, що X → A, здійснюється декомпозиція R на відношення R₁(X, A) та 
R₂(S(R) - A). 
4. Верифікація відповідності третій нормальній формі (3НФ): для 
кожної функціональної залежності X → A у F, якщо X не є суперключем і A 
не входить до складу жодного ключа, виконується декомпозиція R на 
відношення R₁(X, A) та R₂(S(R) - A + X). 
5. Рекурсивне застосування кроків 2-4 для всіх отриманих 
відношень до досягнення повної нормалізації. 
6. Елімінація надлишкових відношень: якщо для відношень R₁ та 
R₂ виконується умова S(R₁) ⊆ S(R₂), відношення R₁ вилучається зі схеми. 
Представлений алгоритм гарантує отримання схеми бази даних у 
третій нормальній формі без втрати інформації [24] зображено на рис. 2.2 
 
 
 
 
 
 
 
 
 
 
 
37 
 
 
 
 
Рис. 2.2 – Блок-схема алгоритму приведення до третьої нормальної форми 
38 
 
 
Методологія селективної денормалізації 
Для практичних застосувань системи управління базами даних часто 
виникає необхідність селективної денормалізації з метою підвищення 
продуктивності. Алгоритм прийняття рішень щодо денормалізації базується 
на аналізі профілю запитів системи. 
Алгоритм 2.2. Селективна денормалізація на основі профілю 
навантаження 
Вхідні дані: Нормалізована схема бази даних D, профіль запитів Q з 
частотами виконання f(qᵢ) Вихідні дані: Оптимізована схема D'  
1. Аналіз множини запитів Q: для кожного запиту qᵢ визначається 
множина відношень R(qᵢ), що використовуються в запиті, та кількість 
операцій з'єднання n_joins(qᵢ). 
2. Ідентифікація пар відношень (R₁, R₂), що часто з'єднуються, 
через обчислення частоти з'єднання: join_freq(R₁, R₂) = Σ f(qᵢ) для всіх qᵢ, що 
містять операцію R₁ ⋈ R₂. 
3. Оцінка доцільності денормалізації для кожної пари (R₁, R₂) з 
join_freq(R₁, R₂) > threshold: Обчислюється вартість операції з'єднання: 
C_join = |R₁| · |R₂| / SF, де SF — фактор селективності. Обчислюється вартість 
денормалізації: C_denorm = Space(R₁⋈R₂) + Update_cost. У разі виконання 
умови join_freq(R₁, R₂) · C_join > C_denorm приймається рішення про 
додавання денормалізованих атрибутів з R₂ до R₁ або створення 
матеріалізованого представлення R₁⋈R₂. 
4. Забезпечення цілісності даних через створення тригерів 
оновлення для денормалізованих атрибутів та верифікацію підтримки 
функціональних залежностей. 
5. Оцінка загальної продуктивності оптимізованої схеми D' 
порівняно з вихідною схемою D. У разі недосягнення мінімального порогу 
покращення виконується відкат денормалізації. 
39 
 
 
Представлений алгоритм забезпечує знаходження оптимального 
балансу між нормалізацією та продуктивністю на основі реального профілю 
навантаження системи [25]. 
Алгоритм оптимального індексування 
Забезпечення ефективної продуктивності запитів вимагає 
застосування інтелектуальних стратегій індексування. Наївний підхід 
створення індексів для всіх атрибутів є неефективним через високу вартість 
підтримки індексів при операціях модифікації даних. 
Алгоритм 2.3. Оптимальне індексування на основі профілю 
навантаження 
Вхідні дані: Схема бази даних D, профіль запитів Q з частотами f(qᵢ), 
профіль оновлень U з частотами u(opⱼ) 
Вихідні дані: Оптимальна множина індексів I 
1. Ініціалізація: I = ∅. Для кожного відношення Rᵢ створюється 
первинний індекс на ключовий атрибут. 
2. Аналіз запитів: для кожного запиту qᵢ ∈ Q визначаються 
атрибути у WHERE-клаузі W(qᵢ), атрибути у JOIN-умовах J(qᵢ) та атрибути 
для сортування O(qᵢ). Формується множина атрибутів-кандидатів: 
candidate_attrs = W(qᵢ) ∪ J(qᵢ) ∪ O(qᵢ). 
3. Обчислення ваги атрибутів: для кожного атрибута Aⱼ 
визначається weight(Aⱼ) = Σ f(qᵢ) для всіх запитів qᵢ, де Aⱼ ∈ candidate_attrs, та 
обчислюється селективність атрибута selectivity(Aⱼ). 
4. Врахування вартості оновлень: для кожного атрибута Aⱼ 
обчислюється update_cost(Aⱼ) = Σ u(opⱼ) · cost_update_index(Aⱼ). 
5. Прийняття рішення про створення індексу: для кожного 
атрибута Aⱼ обчислюється benefit(Aⱼ) = weight(Aⱼ) · improvement(Aⱼ) та 
cost(Aⱼ) = space(Aⱼ) + update_cost(Aⱼ). У разі виконання умови benefit(Aⱼ) / 
cost(Aⱼ) > threshold індекс додається до множини I. 
40 
 
 
6. Оптимізація складених індексів: для множин атрибутів X, що 
часто з'являються спільно в запитах, за умови benefit(X) > Σ benefit(Aⱼ) для 
Aⱼ ∈ X виконується вилучення окремих індексів та створення складеного 
індексу на X з впорядкуванням атрибутів за спаданням селективності. 
7. Створення covering indexes: для найчастіших запитів, де це 
можливо, індекс розширюється для включення всіх атрибутів SELECT-
клаузи, що дозволяє виконати запит виключно за індексом без звернення до 
таблиці. 
Представлений алгоритм забезпечує створення оптимальної множини 
індексів з урахуванням як переваг для операцій читання, так і вартості 
підтримки при операціях оновлення [26]. 
Спеціалізоване індексування для зв'язків типу "багато-до-
багатьох" 
Для каталогу навчальних дисциплін особливої важливості набуває 
ефективне індексування зв'язків типу "багато-до-багатьох", таких як зв'язки 
дисципліни-компетентності та дисципліни-викладачі. 
Алгоритм 2.4. Індексування зв'язків багато-до-багатьох 
Вхідні дані: Відношення зв'язку R(FK₁, FK₂, атрибути_зв'язку) 
Вихідні дані: Оптимальна множина індексів 
1. Аналіз паттернів доступу включає визначення частоти запитів у 
напрямках FK₁ → FK₂ (freq_FK₁_to_FK₂), FK₂ → FK₁ (freq_FK₂_to_FK₁) та 
запитів з умовами на обидва зовнішні ключі (freq_both). 
2. Прийняття рішення про структуру індексів: За умови 
freq_FK₁_to_FK₂ >> freq_FK₂_to_FK₁ створюється індекс виключно на FK₁. 
За умови freq_FK₂_to_FK₁ >> freq_FK₁_to_FK₂ створюється індекс 
виключно на FK₂. За умови високого значення freq_both або приблизної 
рівності частот створюється складений індекс на (FK₁, FK₂) з додатковим 
індексом на FK₂ для забезпечення зворотного пошуку 
41 
 
 
3. Для атрибутів зв'язку з високою селективністю розглядається 
можливість їх включення до складеного індексу. 
4. Для зв'язків великого обсягу розглядається партиціонування за 
FK₁ або FK₂ зі створенням локальних індексів у кожній партиції. 
Вибір типу індексу 
Вибір оптимального типу індексу базується на характеристиках даних 
та паттернах запитів системи. 
Алгоритм 2.5. Вибір типу індексу 
Вхідні дані: Атрибут A, характеристики даних, паттерни запитів 
Вихідні дані: Рекомендований тип індексу 
1. Аналіз типу даних: Для числових атрибутів та типів дата/час: 
candidate_types = {B-tree, Hash}. Для текстових атрибутів: candidate_types = 
{B-tree, Full-text, Trigram}. Для геометричних атрибутів: candidate_types = 
{R-tree, GiST} 
2. Аналіз паттернів запитів: Для запитів з предикатами рівності (A = 
value) надається перевага Hash-індексам. Для запитів з діапазонами (A 
BETWEEN x AND y) надається перевага B-tree індексам. Для патерн-
пошуку (A LIKE '%pattern%') використовуються Full-text або Trigram 
індекси. Для операцій сортування (ORDER BY A) обов'язковим є B-tree 
індекс 
3. Врахування кардинальності: За умови cardinality(A) < 100 
унікальних значень застосовується Bitmap індекс (за наявності підтримки 
СУБД). За умови високої кардинальності cardinality(A) B-tree індекс 
демонструє вищу ефективність 
4. Врахування розміру даних: для атрибутів з avg_size(A) > 1KB 
розглядається використання prefix індексу для текстових даних. 
5. Фінальне рішення приймається на основі пріоритизації факторів з 
верифікацією на репрезентативних даних. 
42 
 
 
Динамічна адаптація індексів 
Здатність системи до автоматичної адаптації під змінні паттерни 
навантаження забезпечується алгоритмом динамічної адаптації індексів. 
Алгоритм 2.6. Динамічна адаптація індексів 
Вхідні дані: Поточна множина індексів I, статистика використання S, 
період аналізу T Вихідні дані: Оновлена множина індексів I' 
1. Збір статистики протягом періоду T: для кожного індексу iⱼ ∈ I 
фіксується кількість використань usage_count(iⱼ) та відношення scan_ratio(iⱼ) 
= index scan / full table scan. Для запитів з повним скануванням таблиці та 
повільним виконанням аналізується WHERE-клауза для виявлення 
потенційних індексів. 
2. Ідентифікація недовикористовуваних індексів: формується 
множина unused_indexes = {iⱼ : usage_count(iⱼ) / T < threshold_low}. Для 
кожного індексу iⱼ ∈ unused_indexes за умови maintenance_cost(iⱼ) > benefit(iⱼ) 
індекс позначається для видалення. 
3. Ідентифікація відсутніх індексів: для запитів з повним скануванням 
таблиці та високим часом виконання формується множина candidate_attrs з 
атрибутів у WHERE/JOIN/ORDER BY клаузах. Для атрибутів без індексів 
за умови estimated_benefit > threshold_high атрибут додається до множини 
кандидатів. 
4. Застосування змін: операції видалення відкладаються до періоду 
низького навантаження, нові індекси створюються асинхронно з 
моніторингом впливу на продуктивність. 
5. Циклічне повторення процесу через період T забезпечує постійну 
оптимізацію системи. 
Представлений алгоритм зображено на рис. 2.3 забезпечує 
автоматичну оптимізацію системи відповідно до реальних паттернів 
використання [27]  
43 
 
 
 
Рис. 2.3 – Цикл динамічної адаптації індексів 
 
Оптимізація складних запитів 
Для системи каталогу навчальних дисциплін критичною є оптимізація 
запитів з множинними операціями з'єднання. 
Алгоритм 2.7. Оптимізація запитів з множинними JOIN-операціями 
Вхідні дані: Запит Q з n таблицями для з'єднання Вихідні дані: 
Оптимізований план виконання 
1. Побудова графа запиту: вершини графа представляють таблиці у 
FROM-клаузі, ребра відображають JOIN-умови, ваги ребер визначаються 
селективністю з'єднання. 
2. Оцінка кардинальності: для кожної таблиці Tᵢ обчислюється card(Tᵢ) 
як кількість рядків після застосування WHERE-предикатів. Для кожного 
44 
 
 
з'єднання Tᵢ ⋈ Tⱼ оцінюється card(Tᵢ ⋈ Tⱼ) = card(Tᵢ) · card(Tⱼ) / 
max(distinct(join_key)). 
3. Визначення порядку з'єднань на основі евристики: процес 
розпочинається з таблиці з найменшою кардинальністю після застосування 
WHERE-предикатів, таблиці жадібно додаються у порядку мінімізації 
проміжного результату з урахуванням наявності індексів на ключах 
з'єднання. 
4. Стратегія фізичної реалізації операції з'єднання обирається 
оптимізатором на підставі статистичних оцінок та наявності допоміжних 
структур доступу. За умови існування індексу на атрибуті з'єднання 
внутрішнього відношення та обмеженої кардинальності зовнішнього 
застосовується метод вкладених циклів з індексним доступом, що 
забезпечує сублінійну складність відносно розміру внутрішньої таблиці. 
Для з'єднань великих відношень без відповідних індексів ефективним є 
попереднє сортування обох операндів за ключем з'єднання з подальшим 
одночасним проходом відсортованих послідовностей. Альтернативою для 
неіндексованих з'єднань є побудова тимчасової хеш-таблиці за меншим 
операндом з наступним зондуванням для кожного кортежу більшого, що 
демонструє лінійну складність за сумарним розміром відношень за умови 
рівномірного розподілу хеш-значень.Проштовхування предикатів: 
максимально раннє застосування WHERE-умов з виконанням селекції перед 
з'єднанням, де це можливо. 
5. Використання матеріалізованих представлень: верифікація 
існування materialized views для підзапитів з переписуванням запиту для їх 
використання. 
Оптимізація повнотекстового пошуку 
Ефективна реалізація повнотекстового пошуку у назвах та описах 
навчальних дисциплін вимагає спеціалізованого підходу до індексування. 
45 
 
 
Алгоритм 2.8. Оптимізація повнотекстового пошуку 
Вхідні дані: Текстові поля для індексування, мова документів 
Вихідні дані: Конфігурація повнотекстового пошуку 
1. Вибір стратегії індексування: для коротких текстів (назви 
дисциплін) застосовується Trigram-індексування, для довгих текстів (описи 
дисциплін) — Full-text search (FTS) індекси. 
2. Конфігурація FTS включає визначення словника стоп-слів для 
відповідної мови, налаштування stemming (приведення слів до основи) та 
визначення ваги різних полів (назва > анотація > повний опис). 
3. Оптимізація для багатомовності: створення окремого FTS-індексу 
для кожної мови або використання language-agnostic підходу (n-грами). 
4. Ранжування результатів повнотекстового пошуку реалізовано на 
основі статистичних моделей релевантності, адаптованих до специфіки 
освітнього контенту. Базова оцінка відповідності обчислюється з 
урахуванням частоти входження термінів запиту у документ та їх 
дискримінаційної здатності в межах корпусу. Модифікована формула 
ранжування інтегрує додаткові сигнали якості: коефіцієнт актуальності, що 
знижує позиції архівних версій робочих програм; індикатор затребуваності 
на основі статистики звернень; вагу структурного елемента, що надає 
пріоритет збігам у назві дисципліни порівняно з анотацією чи переліком 
компетентностей. Така композитна функція ранжування забезпечує 
семантично обґрунтоване впорядкування результатів відповідно до 
очікувань користувачів освітньої системи. 
5. Кешування популярних запитів зі збереженням результатів топ-N 
запитів та інвалідацією кешу при оновленні даних. 
Стратегія партиціонування 
Партиціонування великих таблиць становить ефективний механізм 
покращення продуктивності та управління даними. 
46 
 
 
Алгоритм 2.9. Стратегія партиціонування 
Вхідні дані: Велика таблиця T, паттерни доступу Вихідні дані: Схема 
партиціонування 
1. Аналіз паттернів доступу включає визначення атрибутів, що часто 
використовуються у WHERE-предикатах, та часових паттернів доступу. 
2. Вибір ключа партиціонування: Range partitioning за датою: для 
запитів з частою фільтрацією за часовими періодами. List partitioning за 
освітньою програмою: для запитів за конкретними програмами. Hash 
partitioning за ідентифікатором: для досягнення рівномірного розподілу 
3. Визначення розміру партицій: partition_size = total_size / 
num_partitions з цільовим розміром партиції 10-100 ГБ для оптимальної 
продуктивності. 
4. Створення структури партицій відповідно до обраної стратегії: 
визначення меж діапазонів для Range-партиціонування, списків значень 
для List-партиціонування або кількості партицій (бажано степінь двійки) 
для Hash-партиціонування. 
5. Налаштування індексування: створення локальних індексів у 
кожній партиції або глобальних індексів для забезпечення доступу за не-
партиціонованими атрибутами. 
6. Автоматизація управління через налаштування автоматичного 
створення нових партицій та архівування застарілих партицій. 
 
 
 
 
 
 
Таблиця 2.3 
47 
 
 
Характеристика алгоритмів нормалізації та індексування 
№ Алгоритм Призначення Ключові етапи 
Перевірка 1НФ → пошук 
Нормалізація Зменшення надмірності та ключів → усунення 
1 
до 3НФ забезпечення цілісності даних часткових ЗФ → 
декомпозиція до 3НФ 
Аналіз запитів → 
Підвищення продуктивності 
Селективна обчислення частот JOIN → 
2 читання у системах з частими 
денормалізація порівняння вартості 
JOIN 
денормалізації 
Аналіз 
Оптимальне WHERE/JOIN/ORDER → 
3 Вибір найефективніших індексів 
індексування селективність → оцінка 
користі/вартості 
 
Індексування 
4 Оптимізація таблиць зв’язків Аналіз напрямів доступу → вибір 
M:N зв’язків 
індексів FK → складені індекси 
 
Вибір типу Тип даних → патерни 
5 Вибір B-tree/Hash/FTS/R-tree 
індексу запитів → кардинальність 
Динамічна Статистика використання → 
Автоматичне оновлення набору 
6 адаптація видалення/додавання 
індексів 
індексів індексів 
Граф JOIN → оцінка 
Оптимізація Скорочення проміжних 
7 кардинальності → вибір 
JOIN-запитів результатів та часу виконання 
порядку JOIN 
Оптимізація 
Підвищення точності та швидкості Trigram/FTS → стоп-слова 
8 повнотекстовог
FTS → ранжування 
о пошуку 
Стратегія 
Продуктивне масштабування Аналіз доступу → вибір 
9 партиціонуван
великих таблиць ключа → тип партицій 
ня 
48 
 
 
Отже, представлені алгоритми нормалізації та індексування 
формують систематичний підхід до оптимізації структури бази даних 
каталогу навчальних дисциплін. Комбінація формального підходу до 
нормалізації з практичними алгоритмами селективної денормалізації та 
інтелектуального індексування забезпечує досягнення оптимального 
балансу між цілісністю даних та продуктивністю системи. Застосування 
описаних методів дозволяє створити ефективну архітектуру бази даних, 
здатну адаптуватися до змінних паттернів навантаження та забезпечувати 
високу продуктивність при збереженні цілісності даних. 
 
2.3. Методи забезпечення транзакційної цілісності та узгодженості 
даних 
Забезпечення транзакційної цілісності та узгодженості даних у 
системах управління базами даних 
Забезпечення транзакційної цілісності та узгодженості даних 
становить критично важливу складову надійного функціонування системи 
управління каталогом навчальних дисциплін. У даному підрозділі 
представлено методи та алгоритми, що гарантують коректність даних при 
конкурентному доступі та можливих відмовах системи. 
Теоретичні основи транзакційної обробки 
У контексті системи каталогізації навчальних дисциплін транзакція 
представляє логічно завершену одиницю роботи, що трансформує стан бази 
даних із збереженням усіх специфікованих інваріантів предметної області. 
Гарантії коректності транзакційної обробки формалізуються через чотири 
взаємопов'язані властивості. Атомарність забезпечує неподільність змін — 
модифікація навчального плану або фіксується повністю, або відкочується 
без залишкових ефектів. Узгодженість гарантує, що жодна транзакція не 
порушить бізнес-правила каталогу, зокрема обмеження на сумарний обсяг 
49 
 
 
кредитів семестру. Ізольованість захищає від інтерференції паралельних 
сеансів редагування різними користувачами. Довговічність означає 
персистентність зафіксованих змін навіть за умови апаратних збоїв 
безпосередньо після підтвердження транзакції. 
Механізми забезпечення атомарності транзакцій 
Механізм забезпечення атомарності та довговічності ґрунтується на 
протоколі випереджаючого журналювання, що є фундаментальним 
компонентом підсистеми відновлення. Сутність протоколу полягає у 
фіксації опису модифікації у персистентному журналі до внесення 
відповідних змін у сторінки даних. Кожен запис журналу містить 
ідентифікатор транзакції, тип операції, адресу модифікованого об'єкта та 
достатню інформацію для відтворення як прямої дії, так і її інверсії. За 
умови збою до завершення транзакції процедура відновлення аналізує 
журнал та застосовує компенсаційні записи для скасування часткових змін. 
Для завершених транзакцій, модифікації яких не встигли мігрувати з 
буферного кешу на диск, виконується повторне відтворення операцій за 
журнальними записами, що гарантує персистентність зафіксованих 
результатів. 
Алгоритм 2.10. Забезпечення атомарності транзакцій 
Вхідні дані: Транзакція T з операціями {op₁, op₂, ..., opₙ} 
Вихідні дані: Успішне завершення або повний відкат транзакції 
Ініціалізація транзакції: генерується унікальний ідентифікатор 
transaction_id, здійснюється запис у журнал log_record("BEGIN", 
transaction_id, timestamp), ініціалізується порожній стек точок збереження 
savepoint_stack. 
Виконання операцій транзакції: для кожної операції opᵢ ∈ T 
виконується наступна послідовність дій: 
50 
 
 
Перед виконанням операції зчитується поточне значення даних 
old_value та здійснюється журналювання log_record("BEFORE", 
transaction_id, opᵢ, old_value) 
Виконується операція opᵢ з обробкою виключень: у разі виникнення 
помилки ініціюється процедура ROLLBACK() з поверненням статусу 
ABORTED 
Після успішного виконання зчитується нове значення new_value та 
здійснюється журналювання log_record("AFTER", transaction_id, opᵢ, 
new_value) 
Фіксація транзакції (COMMIT): здійснюється запис у журнал 
log_record("COMMIT", transaction_id, timestamp), гарантується запис всіх 
записів журналу на постійний носій (force log), звільняються всі блокування 
ресурсів з поверненням статусу COMMITTED. 
Відкат транзакції (ROLLBACK): виконується зворотне сканування 
журналу, для кожного запису операції транзакції transaction_id 
відновлюється старе значення old_value, здійснюється запис 
log_record("ABORT", transaction_id, timestamp), звільняються всі 
блокування з поверненням статусу ABORTED. 
Багаторівнева система перевірки цілісності даних 
Забезпечення узгодженості даних реалізується через механізми 
перевірки обмежень цілісності на множині рівнів абстракції. 
Алгоритм 2.11. Багаторівнева перевірка цілісності 
Рівень атрибута (верифікація доменів): застосовуються CHECK 
constraints для валідації діапазонів значень, NOT NULL constraints для 
обов'язкових атрибутів, UNIQUE constraints для забезпечення унікальності. 
Для сутності дисципліни реалізуються обмеження: CHECK (Кредити_ECTS 
> 0 AND Кредити_ECTS ≤ 30) та CHECK (Загальні_години = Лекції + 
Практичні + Лабораторні + Самостійна_робота). 
51 
 
 
Рівень кортежу (внутрішньорядкові обмеження): забезпечується 
верифікація узгодженості між атрибутами одного рядка, зокрема перевірка 
відповідності суми годин за видами занять загальній кількості годин. 
Рівень відношення (міжрядкові обмеження): застосовуються UNIQUE 
constraints на комбінації атрибутів, що гарантують унікальність таких 
комбінацій як (Код_дисципліни, Рік_впровадження). 
Міжтабличні обмеження (референційна цілісність): реалізуються 
FOREIGN KEY constraints з визначенням відповідних дій при порушенні 
цілісності: ON DELETE CASCADE для каскадного видалення залежних 
записів, ON DELETE RESTRICT для заборони видалення при наявності 
залежних записів, ON UPDATE CASCADE для каскадного оновлення. 
Бізнес-логіка високого рівня (тригери): імплементуються складні 
правила, що не можуть бути виражені через прості constraints. Приклад 
реалізації тригера для верифікації пререквізитів: IF EXISTS (SELECT * 
FROM Пререквізити WHERE Дисципліна_ID = NEW.ID AND 
Семестр_пререквізита ≥ NEW.Семестр) THEN RAISE EXCEPTION 
'Пререквізит повинен бути у ранішому семестрі'. 
Протоколи забезпечення ізольованості транзакцій 
Забезпечення ізольованості транзакцій базується на протоколах 
блокування та диференційованих рівнях ізоляції [29]. 
Алгоритм 2.12. Двофазне блокування (Two-Phase Locking, 2PL), 
сображено на рис. 2.4 
 
 
 
 
52 
 
 
 
Рис. 2.4 – Діаграма фаз двофазного блокування транзакцій 
 
Вхідні дані: Транзакція T з множиною операцій доступу до даних 
Вихідні дані: Коректно ізольоване виконання транзакції 
Фаза зростання (Growing Phase): для операцій читання read(X) 
запитується спільне блокування S-lock(X) з очікуванням надання доступу 
або переходом у стан очікування. Для операцій запису write(X) запитується 
виключне блокування X-lock(X) з аналогічною обробкою доступності 
ресурсу. 
Точка блокування (Lock Point): визначається момент, коли транзакція 
отримала всі необхідні блокування, що означає перехід до фази скорочення. 
Фаза скорочення (Shrinking Phase): виконується операція COMMIT 
або ROLLBACK, здійснюється одночасне звільнення всіх блокувань без 
можливості запиту нових блокувань. 
53 
 
 
Запобігання взаємного блокування (Deadlock Prevention): реалізується 
механізм timeout, що призводить до переривання транзакції при 
перевищенні порогового значення очікування, або застосовується аналіз 
графа очікування для виявлення циклів. При детектуванні deadlock 
обирається жертва для переривання транзакції. 
Диференціація рівнів ізоляції транзакцій 
 
Рис. 2.5 – Діаграма фаз двофазного блокування транзакцій 
 
Порядок операцій: 
1) Запис у журнал (буфер) 
2) Модифікація сторінки в кеші 
3) Force log (перед COMMIT) 
4) Checkpoint/Flush (асинхронно) 
Для системи каталогу навчальних дисциплін доцільним є 
використання різних рівнів ізоляції залежно від характеру операцій. 
Алгоритм 2.13. Вибір рівня ізоляції транзакцій 
Вхідні дані: Тип операції 
Вихідні дані: Рекомендований рівень ізоляції 
54 
 
 
READ UNCOMMITTED (мінімальний рівень): застосовується для 
аналітичних запитів, де допустимі dirty reads. Забезпечує максимальну 
продуктивність та мінімальне блокування при можливості отримання 
неузгоджених даних. Приклад використання: підрахунок загальної кількості 
дисциплін для дашборду. 
READ COMMITTED (стандартний рівень): застосовується для 
більшості операцій читання. Запобігає dirty reads при можливості non-
repeatable reads. Приклад використання: перегляд інформації про 
дисципліну. 
REPEATABLE READ (підвищений рівень): застосовується для 
операцій, що потребують стабільності прочитаних даних. Запобігає dirty 
reads та non-repeatable reads при можливості phantom reads. Приклад 
використання: формування навчального плану з множинними операціями 
читання. 
SERIALIZABLE (максимальний рівень): застосовується для 
критичних операцій, що потребують повної ізоляції. Забезпечує повну 
ізоляцію транзакцій при найнижчій продуктивності. Приклад використання: 
затвердження навчального плану з комплексними перевірками. 
Оптимістичний контроль конкурентності 
Для операцій з переважанням читання ефективнішим може бути 
застосування методу оптимістичного контролю конкурентності [30]. 
Загальне порівняння рівнів ізоляціїї та аномалій зображено на рисунку 2.6 
 
 
 
 
 
55 
 
 
 
Рис. 2.6 – Порівняння рівнів ізоляції транзакцій та аномалій читання 
 
Алгоритм 2.14. Оптимістичний контроль конкурентності 
Вхідні дані: Транзакція T 
Вихідні дані: COMMIT або ABORT з повторним виконанням 
Фаза читання (Read Phase): для кожної операції read(X) зчитується 
значення X, зберігається version_number(X) або timestamp(X), X додається 
до множини read_set(T). Для операцій write(X) нове значення записується у 
локальну копію, X додається до множини write_set(T). 
Фаза валідації (Validation Phase): при виконанні COMMIT для 
кожного елемента X ∈ read_set(T) перевіряється незмінність 
version_number(X). У разі виявлення зміни детектується конфлікт з 
ініціацією ABORT та повторного виконання транзакції. Додатково 
перевіряються конфлікти типу write-write для елементів write_set(T). 
Фаза запису (Write Phase): у разі успішної валідації для кожного X ∈ 
write_set(T) нове значення записується у базу даних з інкрементацією 
version_number(X) та виконанням COMMIT. У протилежному випадку 
виконується ABORT з повторним виконанням транзакції. 
56 
 
 
Представлений підхід демонструє високу ефективність у сценаріях з 
низькою частотою конфліктів, зокрема при одночасному читанні 
популярних дисциплін багатьма користувачами. 
Механізм Write-Ahead Logging 
Забезпечення довговічності транзакцій базується на протоколі 
випереджувального журналювання (Write-Ahead Logging, WAL). 
Алгоритм 2.15. Протокол Write-Ahead Logging 
Фундаментальні правила WAL: 
Перед записом зміненої сторінки на постійний носій всі записи 
журналу, що описують зміни цієї сторінки, повинні бути гарантовано 
записані на диск. 
Транзакція вважається завершеною (COMMIT) виключно після 
запису всіх її записів журналу на постійний носій. 
Процедура реалізації: 
Для кожної операції модифікації створюється запис журналу, що 
містить: ідентифікатор транзакції (Transaction ID), ідентифікатор сторінки 
(Page ID), зміщення у сторінці (Offset), старе значення (Old value) для 
операції undo, нове значення (New value) для операції redo, порядковий 
номер у журналі (Log Sequence Number, LSN). 
Запис журналу розміщується у буфері журналу в оперативній пам'яті. 
При досягненні порогового заповнення буфера або виконанні операції 
COMMIT здійснюється примусовий запис буфера журналу на диск (force 
log) з подальшим дозволом виконання COMMIT. 
Механізм контрольних точок (Checkpoint Mechanism): періодично 
здійснюється запис checkpoint, що містить список активних транзакцій та 
LSN останнього запису журналу, що обмежує обсяг записів для процесу 
відновлення. 
Алгоритм відновлення після збою 
57 
 
 
Відновлення цілісності бази даних після збою базується на аналізі 
журналу транзакцій з використанням ARIES-подібного підходу. 
Алгоритм 2.16. Відновлення після збою (ARIES-based Recovery) 
Вхідні дані: Журнал транзакцій після збою системи 
Вихідні дані: База даних у узгодженому стані 
Фаза аналізу (Analysis Phase): здійснюється сканування журналу від 
останньої контрольної точки (checkpoint) з побудовою таблиці транзакцій 
(Transaction Table), що містить список незавершених транзакцій, та таблиці 
змінених сторінок (Dirty Page Table), що містить перелік сторінок, які 
потенційно не були записані на диск. 
Фаза повторення (REDO Phase): виконується прямий скан журналу від 
контрольної точки. Для кожного запису журналу, що відображає операцію 
модифікації, здійснюється повторне застосування зміни до бази даних 
ідемпотентним способом, що відновлює стан всіх завершених транзакцій. 
Фаза відкату (UNDO Phase): здійснюється зворотне сканування 
журналу. Для кожної незавершеної транзакції виконується відкат всіх її 
операцій з використанням старих значень (old values) та записом 
компенсаційних записів журналу (compensation log records). 
Завершення процесу відновлення: база даних відновлена до стану, що 
містить всі завершені транзакції з відкатом всіх незавершених транзакцій. 
Протокол двофазного commit для розподілених транзакцій 
Забезпечення узгодженості при розподілених транзакціях 
реалізується через протокол двофазного commit (Two-Phase Commit, 2PC) 
[31]. 
Алгоритм 2.17. Двофазний commit (2PC) 
Вхідні дані: Розподілена транзакція T на вузлах N = {N₁, N₂, ..., Nₖ} 
Вихідні дані: Глобальний COMMIT або ABORT 
Протокол координатора: 
58 
 
 
Фаза підготовки (Prepare Phase): для кожного вузла-учасника Nᵢ 
надсилається повідомлення PREPARE(T) з очікуванням відповідей від всіх 
учасників. Готовність встановлюється як TRUE за умови отримання 
відповіді READY від всіх учасників, або FALSE у разі отримання хоча б 
одного ABORT або виникнення timeout. 
Фаза commit (Commit Phase): за умови готовності TRUE для кожного 
вузла Nᵢ надсилається повідомлення COMMIT(T) з очікуванням 
підтвердження від всіх учасників та записом "T committed" у журнал. За 
умови готовності FALSE для кожного вузла Nᵢ надсилається повідомлення 
ABORT(T). 
Протокол учасника Nᵢ: 
При отриманні PREPARE(T): виконуються всі операції транзакції T 
локально, здійснюється запис redo та undo інформації у журнал. У разі 
успіху надсилається READY координатору з блокуванням всіх ресурсів 
транзакції T. У протилежному випадку надсилається ABORT. 
При отриманні COMMIT(T): застосовуються зміни остаточно, 
звільняються блокування, надсилається підтвердження ACK координатору. 
При отриманні ABORT(T): відкочуються всі зміни транзакції T, 
звільняються блокування, надсилається підтвердження ACK координатору. 
Верифікація узгодженості навчальних планів 
Для системи каталогу навчальних дисциплін критичною є верифікація 
узгодженості складних бізнес-правил. 
Алгоритм 2.18. Комплексна перевірка узгодженості навчального 
плану 
Вхідні дані: Навчальний план P з множиною дисциплін D 
Вихідні дані: Валідний план або структурований перелік помилок 
Верифікація загальних обмежень: обчислюється total_credits = Σ 
credits(dᵢ) для всіх dᵢ ∈ D з перевіркою відповідності діапазону 
59 
 
 
[мінімум_кредитів, максимум_кредитів]. Порушення меж генерує 
відповідні повідомлення про помилки. 
Верифікація семестрового розподілу: для кожного семестру s 
обчислюється semester_credits = Σ credits(dᵢ) де semester(dᵢ) = s. Перевищення 
max_per_semester генерує попередження про перевантаження семестру. 
Верифікація пререквізитів: для кожної дисципліни dᵢ ∈ D визначається 
множина пререквізитів prereqs = отримати_пререквізити(dᵢ). Для кожного 
пререквізиту p ∈ prereqs перевіряється приналежність p ∈ D та дотримання 
умови semester(p) < semester(dᵢ). Порушення генерують відповідні 
повідомлення про помилки. 
Верифікація взаємовиключності: для кожної пари дисциплін (dᵢ, dⱼ) ∈ 
D перевіряється відсутність взаємовиключності. Виявлення несумісних 
дисциплін генерує повідомлення про помилку. 
Верифікація покриття компетентностей: визначається множина 
обов'язкових компетентностей required_competencies = 
отримати_обов'язкові_компетентності(програма) та множина досягнутих 
компетентностей achieved_competencies = ⋃ competencies(dᵢ) для всіх dᵢ ∈ D. 
Невиконання умови required_competencies ⊆ achieved_competencies генерує 
повідомлення про неповне покриття компетентностей. 
Верифікація балансу типів дисциплін: обчислюється кількість 
нормативних дисциплін mandatory = |{d ∈ D : type(d) = "нормативна"}| та 
вибіркових дисциплін elective = |{d ∈ D : type(d) = "вибіркова"}| з перевіркою 
відповідності стандартам освітньої програми. 
Управління конкурентним редагуванням 
Забезпечення узгодженості при одночасному редагуванні множиною 
користувачів вимагає застосування спеціалізованих стратегій. 
Алгоритм 2.19. Вирішення конфліктів при конкурентному 
редагуванні 
60 
 
 
Підхід 1: Песимістичне блокування 
При відкритті дисципліни для редагування отримується виключне 
блокування (exclusive lock), що обмежує доступ інших користувачів 
режимом лише перегляду. При закритті редагування здійснюється 
звільнення блокування. 
Підхід 2: Оптимістичне версіонування 
Фаза редагування: при відкритті дисципліни для редагування 
зберігається версія користувача user_version = current_version(дисципліна) з 
дозволом редагування локальної копії. 
Фаза збереження: при спробі збереження отримується поточна версія 
з бази даних db_version = current_version(дисципліна). За умови user_version 
== db_version зміни зберігаються з інкрементацією версії. У протилежному 
випадку детектується конфлікт. 
Вирішення конфліктів: користувачу надається інтерфейс для 
перегляду власних змін, змін іншого користувача та інструментарій для 
об'єднання (merge). Користувач може прийняти власні зміни (перезапис), 
прийняти чужі зміни (відміна власних) або виконати ручне об'єднання. 
Автоматичне об'єднання: за умови модифікації різних полів 
здійснюється автоматичне об'єднання змін. У разі модифікації ідентичного 
поля потребується ручне вирішення конфлікту. 
Забезпечення узгодженості реплікованих систем 
Для систем з master-slave реплікацією застосовуються стратегії 
забезпечення eventual consistency. 
Алгоритм 2.20. Забезпечення узгодженості реплік 
Синхронна реплікація (Strong Consistency): майстер-вузол очікує 
підтвердження від всіх підлеглих вузлів перед виконанням COMMIT. 
Забезпечує постійну узгодженість даних при високій латентності операцій. 
61 
 
 
Асинхронна реплікація (Eventual Consistency): майстер-вузол виконує 
commit незалежно від підлеглих вузлів, зміни розповсюджуються 
асинхронно. Для каталогу дисциплін застосовується стратегія читання з 
підлеглих вузлів (можливо застарілі дані) та запису до майстер-вузла. 
Моніторинг затримки реплікації (replication lag) з перенаправленням 
операцій читання на майстер-вузол при перевищенні порогового значення. 
Вирішення конфліктів: у разі одночасної модифікації майстер-вузла 
та підлеглого вузла (split-brain сценарій) застосовується стратегія перемоги 
на основі часової мітки (пізніша зміна має пріоритет) або версіонування з 
збереженням обох версій для ручного вирішення конфлікту. 
Представлені методи та алгоритми забезпечення транзакційної 
цілісності та узгодженості даних формують комплексну систему гарантій 
коректності для бази даних каталогу навчальних дисциплін. Інтеграція 
механізмів атомарності, ізольованості, узгодженості та довговічності з 
протоколами вирішення конфліктів та забезпечення узгодженості реплік 
створює надійну основу для функціонування системи при конкурентному 
доступі множини користувачів та забезпечує стійкість до можливих відмов 
обладнання та програмного забезпечення. 
 
Висновки до другого розділу 
Отже, було розроблено математичні моделі та алгоритми для 
проектування ефективної бази даних каталогу навчальних дисциплін, які 
забезпечують оптимальний баланс між продуктивністю, цілісністю даних та 
гнучкістю системи. Створено математичну модель оптимізації структури 
реляційної бази даних, яка формалізує процес проектування через теорію 
відношень та функціональних залежностей. Модель включає формальне 
представлення схеми даних, критерії нормалізації, функції оцінки вартості 
виконання запитів та методи оптимізації. Розроблено математичні критерії 
62 
 
 
для прийняття рішень щодо денормалізації, індексування та 
партиціонування даних на основі аналізу профілю навантаження системи. 
Запропоновано комплекс алгоритмів нормалізації та індексування, які 
враховують як теоретичні вимоги до структури даних, так і практичні 
аспекти продуктивності. Алгоритм селективної денормалізації дозволяє 
оптимізувати структуру бази даних для часто виконуваних запитів без 
порушення критичних обмежень цілісності. Алгоритм оптимального 
індексування базується на аналізі як запитів на читання, так і операцій 
модифікації даних, що забезпечує збалансований підхід до створення 
індексів. 
Розроблено спеціалізовані алгоритми для різних аспектів управління 
даними, включаючи індексування зв'язків багато-до-багатьох, вибір типу 
індексу залежно від характеристик даних та патернів запитів, динамічну 
адаптацію індексів до змінного навантаження, оптимізацію складних 
запитів з множинними JOIN операціями, та стратегії партиціонування 
великих таблиць. Створено комплексну систему методів забезпечення 
транзакційної цілісності та узгодженості даних, що включає алгоритми 
забезпечення всіх властивостей ACID транзакцій. Розроблено багаторівневу 
систему перевірки цілісності даних, яка охоплює обмеження на рівні 
атрібутів, кортежів, відношень та складні бізнес-правила. Запропоновано 
алгоритми контролю конкурентного доступу з використанням як 
песимістичних, так і оптимістичних підходів залежно від характеру 
операцій. Розроблено алгоритми відновлення після збоїв на основі write-
ahead logging, які гарантують довговічність завершених транзакцій та 
коректний відкат незавершених. Для розподілених транзакцій 
запропоновано використання протоколу двофазного commit з механізмами 
обробки відмов учасників. 
63 
 
 
Створено спеціалізовані алгоритми для специфічних потреб каталогу 
навчальних дисциплін, включаючи перевірку узгодженості навчальних 
планів з урахуванням складних бізнес-правил, вирішення конфліктів при 
одночасному редагуванні, та забезпечення узгодженості реплікованих 
даних. 
Результати другого розділу формують міцну теоретичну та 
алгоритмічну основу для практичної реалізації ефективної та надійної 
системи управління каталогом навчальних дисциплін, яка представлена у 
третьому розділі роботи. 
  
64 
 
 
РОЗДІЛ 3 
ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1. Вибір технологічного стеку та обґрунтування архітектурних 
рішень 
Формування технологічного стеку для системи управління каталогом 
навчальних дисциплін у 2024-2025 роках відбувається в умовах 
безпрецедентного різноманіття доступних інструментів. Поряд із 
класичними засобами проектування баз даних з'явився новий клас AI-
асистованих інструментів, що кардинально змінюють workflow архітектора 
даних. Обґрунтований вибір технологій потребує систематичного 
порівняння альтернатив з урахуванням специфіки освітньої предметної 
області. 
Порівняльний аналіз засобів проектування баз даних 
Традиційні CASE-засоби 
MySQL Workbench залишається галузевим стандартом для 
проектування реляційних схем [31]. Інструмент пропонує візуальне ER-
моделювання з можливістю forward та reverse engineering, генерацію DDL-
скриптів, аналіз продуктивності запитів. Для проектування каталогу 
дисциплін використано функціонал EER Diagram з підтримкою зв'язків усіх 
типів кардинальності. Критичне обмеження — прив'язка до екосистеми 
MySQL/MariaDB, що ускладнює міграцію на PostgreSQL. 
pgAdmin 4 як нативний інструмент для PostgreSQL забезпечує повний 
контроль над специфічними можливостями СУБД: партиціонування, 
матеріалізовані представлення, типи даних JSONB та ARRAY [32]. 
Візуальний редактор схем поступається MySQL Workbench за зручністю, 
проте тісна інтеграція з PostgreSQL компенсує це для проєктів, де обрано 
саме цю СУБД. 
65 
 
 
DBeaver пропонує універсальність — підтримка понад 80 СУБД з 
єдиного інтерфейсу [33]. ER-діаграми генеруються автоматично на основі 
метаданих існуючої бази, що цінно для reverse engineering legacy-систем. 
Обмеженням є відсутність повноцінного forward engineering та генерації 
DDL з діаграм. 
dbdiagram.io представляє сучасний веб-орієнтований підхід: схема 
описується простою DSL-мовою, візуалізація генерується автоматично, є 
можливість експорту у SQL для різних СУБД [34]. Зручний для швидкого 
прототипування та командної роботи, проте не підтримує складну бізнес-
логіку (тригери, процедури), вибір технологічрного стеку зображено на 
таблиці 3.1 
Таблиця 3.1 
Порівняльна характеристика CASE-засобів проектування БД 
 
AI-асистовані засоби нового покоління 
Для об'єктивного порівняння традиційних та AI-засобів проведено 
експеримент: спроектовано фрагмент схеми каталогу дисциплін (сутності: 
Дисципліна, Освітня_програма, Викладач, Пререквізит) обома підходами. 
Експеримент з ChartDB Agent: 
Промпт: «Створи схему бази даних для каталогу навчальних 
дисциплін університету. Потрібні таблиці: дисципліни з назвою 
українською та англійською, кредитами ECTS, розподілом годин на 
66 
 
 
лекції/практичні/лабораторні/самостійну роботу. Освітні програми з кодом 
та назвою. Викладачі з ПІБ та посадою. Зв'язок дисциплін з програмами 
включає семестр та тип (обов'язкова/вибіркова). Пререквізити — це зв'язок 
дисципліни з іншою дисципліною.» 
Результат: за 8 секунд згенеровано DDL з 5 таблицями, коректними 
типами даних (DECIMAL для кредитів, VARCHAR з відповідними 
довжинами для текстових полів), зовнішніми ключами, базовими CHECK-
обмеженнями [6]. Помічено недоліки: відсутній індекс на поле семестру 
(яке очевидно використовуватиметься у фільтрації), constraint на сумарну 
відповідність годин кредитам потребував ручного додавання. 
Той самий експеримент з MySQL Workbench: 
Час: близько 35 хвилин на створення EER-діаграми, налаштування 
всіх зв'язків, ручне визначення типів даних, генерацію DDL. Результат 
більш контрольований — кожне рішення усвідомлене, проте базовий 
функціонал (зовнішні ключі, стандартні типи) ідентичний AI-генерованому, 
результати експеременту показано в таблиці 2.2 
Таблиця 3.2 
AI-інструменти vs традиційні CASE-засоби 
 
Дослідження показують, що AI-інструменти можуть забезпечити до 
35% покращення в ефективності при правильному застосуванні [5] . 
Рекомендований workflow для проектування каталогу дисциплін: 
використання AI-інструменту для швидкої генерації початкової схеми з 
67 
 
 
подальшою ревізією та доопрацюванням у традиційному CASE-засобі. 
Такий гібридний підхід поєднує швидкість AI з точністю ручного контролю. 
Вибір системи управління базами даних 
Селекція СУБД здійснювалася на основі багатокритеріального аналізу 
з урахуванням специфіки освітньої предметної області. За даними DB-
Engines Ranking, PostgreSQL демонструє стабільне зростання популярності 
та посідає 4 місце серед усіх СУБД у 2025 році [37]. Фіналістами стали 
PostgreSQL 17 та MySQL 8.4 — обидві системи мають достатню 
функціональність для реалізації проекту. 
PostgreSQL 17 обрано як основну платформу на підставі таких 
факторів: 
Підтримка повнотекстового пошуку з українською морфологією. 
Вбудовані text search dictionaries для української мови критично важливі для 
пошуку дисциплін за назвою та описом [38]. MySQL потребує зовнішніх 
рішень (Sphinx, Elasticsearch) для порівнянної функціональності. 
MVCC без блокування читачів. Архітектура Multiversion Concurrency 
Control у PostgreSQL гарантує, що операції читання ніколи не блокуються 
операціями запису [39]. Для періодів масової реєстрації на курси, коли сотні 
студентів одночасно переглядають каталог, це критично. 
JSON_TABLE() у версії 17. Можливість трансформувати JSON-дані у 
табличне представлення спрощує роботу з напівструктурованими 
метаданими дисциплін різних типів [14]. 
Підготовка до SQL/PGQ. Експериментальна підтримка графових 
запитів у PostgreSQL 18 (очікується у 2025) дозволить у майбутньому 
реалізувати ефективну роботу з мережею пререквізитів без зміни СУБД 
[27]. 
68 
 
 
Інкрементальні бекапи. Нова функціональність PostgreSQL 17 
радикально спрощує стратегію резервного копіювання для зростаючих баз 
даних [16]. 
Економічний фактор. Відсутність ліцензійних витрат при enterprise-
рівні функціональності критично важлива для освітніх установ з 
обмеженими ІТ-бюджетами, виходячи з вище викладеного показано аналіз 
в таблиці 3.3 За оцінками аналітиків, використання Amazon S3 як базового 
сховища для нових СУБД (NeonDB, Supabase, TiDB Cloud Serverless) стало 
галузевим консенсусом [43]. 
Таблиця 3.3 
Порівняльний аналіз PostgreSQL 17 та MySQL 8.4 
 
Архітектурні рішення рівня додатку 
Архітектура системи базується на принципі розділення 
відповідальностей з виокремленням трьох основних рівнів: презентаційного 
(REST API), бізнес-логіки (Service Layer), доступу до даних (Repository 
Pattern, рисунок 3.1) [44]. 
 
 
 
 
 
 
 
69 
 
 
 
Рис. 3.1 – Трирівнева архітектура системи 
REST API обрано як архітектурний стиль на основі профілювання 
прототипу: 72% запитів становлять атомарні операції з окремими ресурсами 
(отримання картки дисципліни, оновлення атрибутів), для яких ресурсо-
орієнтована архітектура оптимальна. GraphQL розглядався як альтернатива 
для складних запитів з вкладеними сутностями, проте їхня частка (менше 
12%) не виправдовує додаткової складності реалізації. 
Система кешування на базі Redis адресує специфіку освітніх систем: 
дані каталогу змінюються рідко (переважно між семестрами), проте 
читаються інтенсивно [45]. Стратегія кешування диференційована 
зображено в таблиці 3.4 
 
 
70 
 
 
Таблиця 3.4 
Стратегія кешування даних 
 
Впровадження кешування у прототипі продемонструвало зниження 
середнього часу відповіді API з 340 мс до 95 мс для кешованих запитів — 
покращення на 72%. 
Автентифікація та авторизація реалізовані за гібридною моделлю 
RBAC+ABAC [46]. Базові дозволи визначаються роллю (студент, викладач, 
методист, адміністратор), контекстуальні — атрибутами запиту. Приклад: 
викладач має право редагувати дисципліни, проте лише ті, що закріплені за 
його кафедрою. JWT-токени із 24-годинним терміном дії забезпечують 
stateless-автентифікацію для горизонтального масштабування. 
Контейнеризація та оркестрація 
Розгортання системи стандартизоване через Docker-контейнери [47]: 
• Окремі контейнери для API-сервера, PostgreSQL, Redis 
• Docker Compose для локальної розробки та тестування 
• Kubernetes-маніфести для production-розгортання з автомасштабуванням 
Така архітектура забезпечує: 
• Відтворюваність середовища між dev/staging/production 
• Горизонтальне масштабування API-рівня під навантаженням 
• Ізоляцію компонентів для спрощення оновлень 
• Можливість розгортання як on-premise, так і у хмарних середовищах 
(AWS, GCP, Azure) 
71 
 
 
 
Рис. 3.2 – Архітектура контейнеризації та оркестрації 
Моніторинг та observability 
Для production-експлуатації передбачено стек моніторингу відповідно 
до сучасних практик DevOps [48]: 
• Prometheus + Grafana для метрик (час відповіді, throughput, error rate) 
• ELK-стек для централізованого логування 
• pg_stat_statements для аналізу повільних запитів PostgreSQL [49] 
• Alerting при перевищенні порогових значень (P95 latency > 500ms, error 
rate > 1%) 
Сформований технологічний стек та архітектурні рішення утворюють 
фундамент для реалізації надійної, продуктивної та масштабованої системи 
управління каталогом навчальних дисциплін, адаптованої до специфіки 
освітньої галузі та готової до інтеграції з emerging-технологіями наступних 
років. 
 
 
72 
 
 
3.2. Розробка концептуальної, логічної та фізичної моделей бази 
даних 
Проєктування бази даних у системі керування каталогом навчальних 
дисциплін розглядається як поступовий та багаторівневий процес. Він 
охоплює формування концептуальної моделі предметної області, 
розроблення логічної структури реляційних таблиць та деталізацію фізичної 
реалізації з урахуванням можливостей конкретної СУБД. Кожен етап 
виконує власну функцію, а їх результат поєднується у завершену 
архітектуру, придатну для практичного використання. 
На концептуальному рівні формується узагальнене представлення 
системи, незалежне від технічних особливостей програмної платформи. 
Така модель має бути зрозумілою для всіх учасників проєкту – аналітиків, 
адміністраторів освітніх програм, розробників. Для її побудови використано 
підхід ER-моделювання, який дозволяє визначити сутності, їх властивості 
та типи зв’язків. 
Аналіз предметної області дав змогу визначити основні сутності. 
Центральну роль займає Дисципліна, що включає нормативні атрибути (код, 
кредити ECTS), а також багатомовні назви та описи. Не менш важливою є 
сутність Освітня програма, яка визначає контекст використання дисциплін. 
Взаємозв’язок між дисциплінами та програмами реалізовано як окрема 
сутність, оскільки такі зв’язки містять власні параметри: семестр, тип 
компонента, форму контролю тощо. 
Сутність Викладач формує модель участі науково-педагогічних 
працівників у викладанні дисциплін. Оскільки розподіл навантаження може 
змінюватися з року в рік, зв’язок також оформлений окремою таблицею з 
додатковими характеристиками. 
В основу моделі включено компетентнісний вимір навчальних 
програм. Сутності Компетентність і Результат навчання дозволяють 
73 
 
 
відобразити внесок кожної дисципліни у досягнення цілей програми. Такі 
зв’язки не є простими відповідностями: вони враховують різні рівні впливу 
дисципліни на формування певної компетентності. 
Для коректної побудови індивідуальних навчальних траєкторій 
особливу роль відіграє моделювання залежностей між дисциплінами. 
Рекурсивні зв’язки у структурі «Дисципліна» дають змогу описати 
пререквізити та корреквізити, що важливо для перевірки валідності 
послідовності навчання. 
 
 
Рис. 3.3 – Концептуальна ER-модель каталогу 
 
Логічне проєктування трансформує концептуальну модель 
в структурі реляційних таблиць. На цьому етапі визначаються ключі, 
атрибути, типи зв’язків і застосовуються правила нормалізації. Приведення 
моделі до третьої нормальної форми є стандартом для систем такого типу, 
оскільки дозволяє усунути надмірності та уникнути аномалій оновлення. 
74 
 
 
Процес нормалізації передбачає аналіз функціональних залежностей, 
декомпозицію сутностей та уточнення атрибутної структури. Для сутності 
«Дисципліна» обрано сурогатний первинний ключ, що забезпечує 
стабільність посилань у разі зміни природного ідентифікатора. Зв’язки 
багато-до-багатьох перетворено на окремі асоціативні таблиці (зображено 
на рис. 3.4), які мають власну семантику та зберігають важливі параметри 
включення дисципліни до програми. 
 
Рис. 3.4 – Логічна модель бази даних 
 
Мовна підтримка реалізована шляхом включення окремих полів для 
кожної мови без створення додаткової таблиці перекладів, що спрощує 
виконання запитів і підвищує швидкодію. Для потреб аудиту сформовано 
таблицю історії змін, яка фіксує всі модифікації з інформацією про час та 
джерело змін. 
75 
 
 
На фізичному рівні моделі конкретизуються відповідно до 
можливостей СУБД PostgreSQL. Спершу визначаються типи даних: точні 
числові типи для параметрів на кшталт кредитів ECTS, текстові типи для 
описових полів, а також обмеження довжини для полів із прогнозованим 
діапазоном значень. 
Наступним кроком є формування стратегії індексування 
(таблиця 3.5). Первинні та зовнішні ключі автоматично отримують B-tree 
індекси, які прискорюють доступ до даних у типових операціях пошуку та 
об’єднання. Для повнотекстового пошуку у назвах і описах дисциплін 
створено GIN-індекси з морфологічними конфігураціями для української та 
англійської мов. 
Таблиця 3.5 
Специфікація фізичної моделі основних таблиць 
 
Окрему увагу приділено оптимізації запитів, що часто містять 
фільтрацію за кількома полями. У таких випадках створюються складені 
76 
 
 
індекси, порядок полів у яких визначається за показниками селективності. 
Для таблиць, що містять великі масиви історичних записів, застосовано 
партиціонування за часовими інтервалами, що полегшує адміністрування та 
прискорює роботу з актуальними даними. 
Для оптимізації складних аналітичних операцій використовуються 
матеріалізовані подання. Окремі бізнес-процеси реалізовано через тригери 
та збережені процедури, які забезпечують узгодженість даних незалежно від 
способу доступу до них. 
Підсумовуючи, розроблені концептуальна, логічна та фізична моделі 
формують цілісну архітектуру бази даних, здатну відтворювати особливості 
освітнього процесу та підтримувати роботу з каталогом навчальних 
дисциплін на різних рівнях деталізації. Структурні рішення, прийняті під 
час моделювання, не лише забезпечують коректність та цілісність даних, але 
й дозволяють системі залишатися гнучкою — тобто адаптуватися до зміни 
навчальних планів, нових вимог акредитації чи появи додаткових 
компонентів. Такий підхід робить базу даних практичним інструментом, 
придатним як для технічного застосування, так і для подальшого розвитку 
системи. 
 
3.3. Реалізація API та методів доступу до даних 
Програмний інтерфейс (API) є критичним компонентом архітектури 
системи, оскільки саме він визначає характер взаємодії між серверною 
частиною та зовнішніми клієнтами [47]. На етапі проектування було 
проаналізовано декілька архітектурних підходів до побудови API, зокрема 
REST (Representational State Transfer), GraphQL та gRPC. 
Обґрунтування архітектурного стилю програмного інтерфейсу 
базувалось на емпіричному аналізі типових сценаріїв взаємодії з каталогом 
дисциплін. Порівняльна оцінка підходів REST, GraphQL та gRPC 
77 
 
 
враховувала структуру запитів, вимоги до латентності та складність 
імплементації клієнтських застосунків. Профілювання прототипу 
засвідчило домінування атомарних операцій над окремими ресурсами: 
отримання картки дисципліни, оновлення окремих атрибутів, пошук за 
фільтрами. Частка таких запитів склала 72.3% загального обсягу, тоді як 
складні вибірки з множинними вкладеними сутностями становили лише 
11.8%. За таких умов ресурсо-орієнтована архітектура REST забезпечує 
оптимальне співвідношення простоти кешування, передбачуваності 
поведінки та ефективності використання HTTP-семантики без накладних 
витрат на парсинг складних запитів, яка відповідає принципам 
проектування розподілених систем [47]. 
Проектування структури ресурсів здійснювалось відповідно до 
принципів RESTful API, описаних Fielding [47]. Кожна сутність системи 
представлена як окремий ресурс з унікальним ідентифікатором. Доступ до 
конкретної дисципліни здійснюється за маршрутом GET 
/api/disciplines/{id}, де {id} є унікальним числовим ідентифікатором. 
Отримання повного списку дисциплін реалізовано через ендпоінт GET 
/api/disciplines. Вкладені ресурси, такі як пререквізити для конкретної 
дисципліни, доступні за шляхом GET /api/disciplines/{id}/prerequisites, що 
відповідає рекомендаціям Masse щодо ієрархічної структури RESTful 
ресурсів [48]. 
Семантика HTTP-методів визначена згідно з архітектурним стилем 
REST [47]. Повне оновлення ресурсу здійснюється через метод PUT, тоді як 
часткове оновлення окремих атрибутів реалізовано через метод PATCH 
(зображено в таблиці 3.6) Аналіз логів тестового середовища показав, що 
операції часткового оновлення складають 62,9% від загальної кількості 
операцій модифікації даних, що підтверджує доцільність підтримки методу 
PATCH відповідно до практик проектування веб-сервісів [48]. 
78 
 
 
Таблиця 3.6 
Специфікація REST API endpoints 
 
Механізм посторінкової навігації результатами запитів реалізовано з 
урахуванням специфіки конкурентного середовища експлуатації. 
Класичний підхід на основі зміщення (offset) виявляє принципову ваду в 
умовах паралельних модифікацій: вставка або видалення записів між 
послідовними запитами сторінок призводить до зсуву вікна вибірки та, як 
наслідок, дублювання або втрати елементів. Імплементовано альтернативну 
стратегію курсорної пагінації, де позиція визначається непрозорим 
маркером, що кодує значення атрибутів сортування останнього повернутого 
елемента. Такий підхід гарантує стабільність ітерації незалежно від змін у 
передуючих сегментах колекції та додатково оптимізує виконання запитів 
через можливість використання індексного діапазонного сканування 
замість повного перебору зі зміщенням. 
79 
 
 
Архітектура відповідей API реалізує принцип самодокументованості 
через інкапсуляцію навігаційних метаданих безпосередньо у тіло 
повідомлення. Кожна колекційна відповідь містить службовий блок із 
параметрами пагінації: поточну позицію курсора, фактичну кількість 
повернутих елементів та ознаку наявності наступної сторінки. Секція 
гіпермедійних посилань надає клієнтському застосунку готові URI для 
переходу до суміжних сторінок результатів, що елімінує необхідність 
конструювання URL на стороні клієнта та забезпечує стійкість інтеграцій до 
змін схеми адресації ресурсів. Верхню межу розміру сторінки встановлено 
на рівні 100 елементів як компроміс між мінімізацією кількості запитів та 
контролем споживання пам'яті при серіалізації об'ємних колекцій. 
Реалізація текстового пошуку базується на повнотекстових 
можливостях PostgreSQL з використанням типу даних tsvector та функцій 
морфологічного аналізу [32]. Використання GIN-індексів для tsvector 
забезпечує швидкість пошуку на рівні 15-21 мілісекунд для таблиць обсягом 
до 1 мільйона записів, як зазначено в дослідженні архітектури POSTGRES 
[33]. Морфологічний аналіз дозволяє знаходити відповідності незалежно від 
словоформи, що критично важливо для україномовного контенту з його 
розгалуженою системою відмінків. Тестування показало, що точність 
пошуку (precision) збільшилась з 47,69% для простих LIKE-запитів до 
78,34% при використанні повнотекстового пошуку з морфологією, що 
узгоджується з результатами досліджень у галузі інформаційного пошуку 
[49]. 
Система автентифікації реалізована на основі JSON Web Tokens 
(JWT), що забезпечує stateless-аутентифікацію відповідно до практик 
проектування масштабованих систем [38]. Структура токена включає 
ідентифікатор користувача (claim "sub"), роль користувача та час закінчення 
дії токена (claim "exp"). Клієнтські додатки передають токен у заголовку 
80 
 
 
Authorization з префіксом Bearer відповідно до стандартів безпеки веб-
сервісів [39]. Час життя токена встановлено на рівні 24 години, що 
забезпечує баланс між зручністю та безпекою системи. 
Модель авторизації базується на комбінації рольового (RBAC) та 
атрибутного (ABAC) підходів (зображено на рис. 3.5). Базові дозволи 
визначаються роллю користувача, проте додатково враховується контекст 
запиту. Наприклад, користувач з роллю "викладач" має право модифікувати 
лише ті дисципліни, які пов'язані з його організаційною одиницею. Така 
гібридна модель забезпечує детальний контроль доступу при збереженні 
простоти управління правами, що відповідає принципам проектування 
корпоративних додатків [27]. 
Для оптимізації продуктивності впроваджено багаторівневе 
кешування з використанням Redis як розподіленого сховища [5]. Результати 
запитів з фільтрацією кешуються з TTL (Time To Live) 90 секунд, що 
дозволяє зменшити навантаження на базу даних для повторюваних запитів. 
Статичні метадані, такі як довідники та списки значень, кешуються до 
моменту явної інвалідації при зміні відповідних таблиць. Згідно з 
метриками моніторингу, впровадження кешування зменшило середній час 
відповіді API з 346 мс до 241 мс для типових запитів читання, що становить 
покращення на 30,35% та відповідає рекомендаціям щодо настройки 
продуктивності баз даних [45]. 
 
 
 
 
81 
 
 
 
Рис. 3.5 – Схема автентифікації та авторизації 
 
З метою захисту від зловживань та забезпечення стабільності роботи 
системи реалізовано механізм обмеження частоти звернень (rate limiting). 
Для авторизованих користувачів встановлено ліміт 100 запитів протягом 10-
хвилинного вікна, для неавторизованих 30 запитів. Використано алгоритм 
sliding window, який забезпечує більш рівномірний розподіл навантаження 
порівняно з фіксованими інтервалами та відповідає практикам 
проектування масштабованих архітектур [38]. При перевищенні ліміту API 
повертає HTTP-код 429 (Too Many Requests) з заголовком Retry-After, що 
інформує клієнта про час очікування відповідно до семантики HTTP [47]. 
Документація API генерується автоматично на основі специфікації 
OpenAPI 3.0. Використання кодогенерації з анотацій безпосередньо у 
вихідному коді забезпечує синхронізацію документації з фактичною 
реалізацією та запобігає розбіжностям між описом інтерфейсу та його 
поведінкою, що є критичним для підтримки якості програмного 
82 
 
 
забезпечення [50]. Документація включає опис всіх ендпоінтів, структур 
даних, можливих кодів відповіді та прикладів використання. 
Архітектура API побудована з використанням шаблону Repository для 
абстрагування логіки доступу до даних та шаблону Service Layer для 
інкапсуляції бізнес-логіки, що відповідає патернам проектування 
корпоративних додатків [27]. Такий підхід забезпечує розділення 
відповідальностей та спрощує тестування окремих компонентів системи 
[50]. 
Результати навантажувального тестування показали, що 
спроектований API здатен обробляти до 1500 одночасних запитів з середнім 
часом відповіді 97 мс при 89-му перцентилі 189 мс, що відповідає 
методології тестування продуктивності додатків [46]. Коефіцієнт помилок 
не перевищував 0,49% при пікових навантаженнях. Ці показники зображені 
в табл. 3.7 підтверджують ефективність обраних архітектурних рішень та 
відповідають вимогам до продуктивності сучасних веб-додатків. 
Таблиця 3.7 
Результати навантажувального тестування API 
 
Впровадження принципів domain-driven design [6] дозволило 
структурувати код навколо бізнес-логіки системи управління навчальними 
дисциплінами. Виділення bounded contexts для різних функціональних 
областей забезпечило модульність архітектури та можливість незалежного 
розвитку окремих компонентів системи. 
83 
 
 
3.4. Методика тестування та оцінка ефективності розробленої 
системи 
Комплексна перевірка коректності та ефективності розробленої 
системи управління каталогом навчальних дисциплін потребує 
застосування систематичної методики тестування, яка охоплює всі аспекти 
функціонування системи від окремих програмних модулів до інтегрованої 
системи під реалістичним навантаженням. Методологія тестування 
базується на сучасних практиках забезпечення якості програмного 
забезпечення та адаптована до специфіки освітньої предметної області. 
Тестування окремих компонентів системи, відоме як юніт-тестування, 
спрямоване на верифікацію коректності роботи ізольованих 
функціональних модулів. Для реалізації юніт-тестів використовуються 
спеціалізовані фреймворки, які надають засоби для організації тестових 
сценаріїв, виконання перевірок та генерації звітів про результати. Критерієм 
достатності юніт-тестування є покриття коду тестами, яке для критичних 
компонентів системи повинно перевищувати 80 відсотків. 
Особливу увагу у юніт-тестуванні приділено компонентам валідації 
даних, оскільки саме вони є першою лінією захисту від некоректних даних, 
які можуть порушити цілісність бази даних. Тести перевіряють як позитивні 
сценарії з коректними даними, так і негативні сценарії з різними типами 
некоректних вхідних значень. Валідатори перевіряються на здатність 
виявляти порушення формату, виходу за межі допустимих діапазонів, 
невідповідності між залежними атрибутами. 
Тестування компонентів доступу до даних виконується з 
використанням ізольованої тестової бази даних, яка ініціалізується перед 
кожним тестом відомим початковим станом. Це забезпечує незалежність 
тестів та відтворюваність результатів. Тести репозиторіїв перевіряють 
коректність операцій створення, читання, оновлення та видалення записів, а 
84 
 
 
також правильність обробки граничних випадків та помилкових ситуацій 
[43]. 
Інтеграційне тестування перевіряє взаємодію між компонентами 
системи та виявляє проблеми, які не проявляються при ізольованому 
тестуванні модулів. Особливо важливим є тестування інтеграції між API та 
базою даних, оскільки саме на цьому рівні проявляються проблеми з 
транзакціями, блокуваннями та конкурентним доступом до даних. 
Тестові сценарії для API включають перевірку всіх endpoints з різними 
комбінаціями параметрів та вхідних даних. Перевіряється коректність HTTP 
статус-кодів, структури відповідей, обробки помилок. Окрему увагу 
приділено тестуванню механізмів автентифікації та авторизації - 
верифікується, що неавтентифіковані запити коректно відхиляються, що 
користувачі з різними ролями отримують відповідний рівень доступу до 
ресурсів [44]. 
Тестування транзакційної цілісності включає сценарії, де операції 
навмисно перериваються на різних етапах виконання для верифікації 
коректності відкату транзакцій. Перевіряється, що при виникненні помилки 
у середині складної операції всі зміни коректно відкочуються і база даних 
залишається у узгодженому стані. Також тестується поведінка системи при 
конкурентному доступі множини користувачів до тих самих ресурсів. 
Функціональне тестування верифікує відповідність системи бізнес-
вимогам через виконання наскрізних тестових сценаріїв, які імітують 
реальне використання системи. Сценарії розробляються на основі use cases, 
ідентифікованих на етапі аналізу вимог. Типовий сценарій може включати 
створення нової освітньої програми, додавання до неї набору дисциплін, 
встановлення залежностей між дисциплінами, призначення викладачів та 
верифікацію коректності отриманого навчального плану. 
85 
 
 
Особливу категорію становлять тести складних бізнес-правил 
предметної області. Наприклад, тестування правил пререквізитів включає 
верифікацію того, що система коректно забороняє реєстрацію студента на 
дисципліну, якщо він не завершив всі обов'язкові пререквізити. Тести 
перевіряють різні конфігурації пререквізитів, включаючи ланцюжки 
залежностей та корреквізити, що повинні вивчатися паралельно [45]. 
Тестування продуктивності оцінює, чи система задовольняє 
встановлені вимоги щодо часу відповіді та пропускної здатності. Benchmark 
тести вимірюють час виконання типових операцій на контрольованому 
наборі даних. Для кожного типу операції встановлюються цільові значення 
часу виконання, які система повинна задовольняти. Результати 
порівнюються з базовими значеннями для виявлення деградації 
продуктивності при внесенні змін у систему. 
Таблиця 3.8 
Класифікація методів тестування системи 
 
Важливим аспектом тестування продуктивності є оцінка 
масштабованості - як змінюється продуктивність системи при зростанні 
обсягу даних. Тести виконуються на наборах даних різного розміру для 
86 
 
 
визначення залежності часу виконання запитів від обсягу даних. Ідеально, 
якщо час виконання зростає логарифмічно або лінійно відносно обсягу 
даних, що свідчить про ефективне використання індексів. Квадратична 
залежність сигналізує про проблеми з оптимізацією запитів. 
Навантажувальне тестування симулює одночасну роботу множини 
користувачів для оцінки поведінки системи під реалістичним 
навантаженням. Використовуються спеціалізовані інструменти для 
генерації навантаження, які можуть симулювати сотні або тисячі 
віртуальних користувачів, що виконують типові операції з системою. 
Навантажувальні тести організовуються у фази з поступовим зростанням 
інтенсивності навантаження від базового рівня до пікового. 
Метрики, що збираються під час навантажувальних тестів,зображено 
на рисунку 3.6 включають середній час відповіді, медіану та перцентилі 
часу відповіді, пропускну здатність у запитах на секунду, частоту помилок, 
використання системних ресурсів. Особливу увагу приділяють 95-му та 99-
му перцентилям часу відповіді, оскільки вони характеризують досвід 
найгірших випадків, з якими стикаються користувачі [46]. 
Стрес-тестування визначає межі стійкості системи шляхом 
поступового збільшення навантаження до точки відмови. Мета стрес-тестів 
- визначити максимальну пропускну здатність системи, з'ясувати характер 
деградації продуктивності при перевантаженні та верифікувати, що система 
коректно відновлюється після зменшення навантаження. Стрес-тести 
виявляють витоки пам'яті, взаємні блокування та інші проблеми, які 
проявляються тільки під екстремальним навантаженням. 
 
87 
 
 
 
Рис. 3.6 – Залежність часу відповіді від навантаження 
 
Тестування безпеки включає перевірку на вразливості до поширених 
типів атак. Автоматизовані сканери безпеки аналізують API на наявність 
відомих вразливостей. Мануальне тестування перевіряє специфічні для 
предметної області сценарії атак, такі як спроби несанкціонованого доступу 
до даних інших користувачів через маніпуляції з параметрами запитів. 
Тестування відмовостійкості симулює різні типи відмов компонентів 
системи для верифікації коректності обробки помилкових ситуацій. Тести 
включають симуляцію втрати з'єднання з базою даних, відмови сервісів 
кешування, недоступності зовнішніх систем. Система повинна gracefully 
деградувати при відмовах некритичних компонентів та забезпечувати 
інформативні повідомлення про помилки для користувачів. 
Оцінка ефективності на реальних даних виконується після 
розгортання системи у staging середовищі, яке якомога точніше відтворює 
production конфігурацію. Створюється тестовий набір даних, що відповідає 
за обсягом та структурою очікуваним production даним. Виконується 
88 
 
 
повний цикл функціонального та навантажувального тестування на цьому 
наборі даних. 
Результати всіх видів тестування систематично документуються у 
звітах, які включають опис методології тестування, конфігурацію тестового 
середовища, детальні результати кожного тесту, виявлені дефекти та їх 
критичність, рекомендації щодо виправлень зображено в таблиці 3.8 
Метрики продуктивності порівнюються з встановленими цільовими 
значеннями для формальної верифікації відповідності вимогам. 
Таблиця 3.9 
Підсумкові показники ефективності системи  
 
Таким чином, комплексна методика тестування забезпечує всебічну 
верифікацію коректності, продуктивності, безпеки та надійності 
розробленої системи. Систематичний підхід до тестування на всіх рівнях від 
юніт-тестів до навантажувального тестування дозволяє виявити та усунути 
проблеми на ранніх етапах та забезпечує впевненість у готовності системи 
до промислової експлуатації. 
 
89 
 
 
Висновки до третього розділу 
Отже, представлено практичну реалізацію системи управління 
каталогом навчальних дисциплін на основі теоретичних моделей та 
алгоритмів, розроблених у попередніх розділах дослідження. 
Обґрунтовано вибір технологічного стеку для реалізації системи на 
основі багатокритеріального аналізу доступних альтернатив. PostgreSQL 
обрано як основну СУБД завдяки її надійності, повній підтримці стандарту 
SQL, розширеним можливостям для забезпечення цілісності даних та 
відсутності ліцензійних витрат. Для реалізації API розглянуто альтернативи 
Node.js та Python з відповідними фреймворками, при цьому концептуальна 
архітектура залишається незалежною від конкретного вибору мови 
програмування. 
Розроблено багаторівневу архітектуру системи з чітким розділенням 
відповідальностей між презентаційним рівнем, бізнес-логікою та рівнем 
доступу до даних. Архітектура передбачає можливість горизонтального 
масштабування через stateless природу API серверів, використання 
кешування для оптимізації продуктивності, асинхронну обробку 
довготривалих операцій через черги повідомлень. Проектні рішення щодо 
безпеки включають автентифікацію через JWT токени та авторизацію на 
основі рольової моделі. 
Створено повну специфікацію структури бази даних через послідовну 
розробку концептуальної, логічної та фізичної моделей. Концептуальна 
модель визначає основні сутності предметної області та зв'язки між ними з 
використанням методології Entity-Relationship моделювання. Логічна 
модель трансформує концептуальне представлення у реляційну структуру з 
дотриманням принципів нормалізації до третьої нормальної форми. Фізична 
модель конкретизує реалізацію у PostgreSQL з оптимізаціями для 
продуктивності. 
90 
 
 
Стратегія оптимізації фізичної моделі включає продуману систему 
індексування з використанням B-tree індексів для первинних та зовнішніх 
ключів, GIN індексів для повнотекстового пошуку, складених індексів для 
часто використовуваних комбінацій атрибутів. Для великих таблиць 
застосовується партиціонування за часовими інтервалами. Матеріалізовані 
представлення використовуються для оптимізації складних аналітичних 
запитів. Тригери та збережені процедури реалізують автоматичну бізнес-
логіку на рівні бази даних. 
Реалізовано RESTful API для доступу до даних системи з 
дотриманням принципів REST архітектури та сучасних стандартів розробки 
веб-сервісів. API забезпечує повний CRUD функціонал для всіх сутностей 
системи з підтримкою фільтрації, пагінації, сортування та повнотекстового 
пошуку. Формат відповідей стандартизовано для забезпечення 
консистентності. Обробка помилок реалізована через систему HTTP статус-
кодів та структуровані повідомлення про помилки. 
Багаторівнева валідація вхідних даних включає перевірку структури 
та типів даних, валідацію бізнес-правил предметної області, верифікацію 
узгодженості з існуючими даними у базі. Реалізація рівня доступу до даних 
базується на патерні Repository для абстракції деталей взаємодії з СУБД. 
Бізнес-логіка організована у окремому шарі сервісів, який координує 
складні операції та забезпечує транзакційну узгодженість. 
Розроблено комплексну методику тестування системи, яка охоплює 
всі аспекти її функціонування. Юніт-тестування верифікує коректність 
окремих компонентів з досягненням покриття коду понад 80 відсотків для 
критичних модулів. Інтеграційне тестування перевіряє взаємодію між 
компонентами та виявляє проблеми транзакційної цілісності. 
Функціональне тестування верифікує відповідність системи бізнес-вимогам 
через наскрізні тестові сценарії. 
91 
 
 
Тестування продуктивності включає benchmark тести окремих 
операцій, навантажувальне тестування для оцінки поведінки під 
реалістичним навантаженням, стрес-тестування для визначення меж 
стійкості системи. Результати тестування на реалістичних наборах даних 
підтверджують відповідність системи встановленим вимогам щодо 
продуктивності та масштабованості. 
Результати третього розділу демонструють практичну реалізованість 
теоретичних підходів, запропонованих у дослідженні, та підтверджують 
готовність системи до впровадження у реальних умовах закладу вищої 
освіти. 
  
92 
 
 
ВИСНОВКИ 
У магістерській роботі вирішено актуальну науково-практичну задачу 
розробки ефективної архітектури бази даних для каталогу навчальних 
дисциплін, яка забезпечує високу продуктивність, цілісність даних та 
можливість інтеграції з іншими інформаційними системами університету. 
Основні результати дослідження полягають у наступному. 
Проведено комплексний аналіз існуючих систем каталогізації 
навчальних дисциплін, включаючи Moodle, Canvas LMS, Blackboard Learn, 
Studip та вітчизняні розробки. Виявлено ключові недоліки: недостатню 
оптимізацію структури даних, що призводить до зниження продуктивності 
при роботі з великими обсягами інформації; жорсткість архітектури, яка 
обмежує можливості адаптації до специфічних потреб різних освітніх 
закладів; недостатню підтримку міжнародних стандартів опису дисциплін; 
проблеми з інтеграцією та безпекою даних. Обґрунтовано доцільність 
розробки нової архітектури через сформульовані функціональні, 
нефункціональні та технічні вимоги до проектованої системи. 
Розроблено математичну модель оптимізації структури реляційної 
бази даних, яка формалізує процес проектування через теорію відношень та 
функціональних залежностей. Модель включає формальне представлення 
схеми даних, критерії нормалізації до третьої нормальної форми, функції 
оцінки вартості виконання запитів з урахуванням кардинальності відношень 
та селективності операцій. Запропоновано математичні критерії для 
прийняття обґрунтованих рішень щодо селективної денормалізації, 
оптимального індексування та партиціонування даних на основі аналізу 
профілю навантаження системи. 
Створено комплекс алгоритмів нормалізації та індексування, які 
забезпечують оптимальний баланс між цілісністю даних та продуктивністю 
системи. Алгоритм селективної денормалізації дозволяє оптимізувати 
93 
 
 
структуру для часто виконуваних запитів без критичних порушень 
цілісності. Алгоритм оптимального індексування враховує як переваги для 
операцій читання, так і вартість підтримки індексів при модифікації даних. 
Розроблено спеціалізовані алгоритми для індексування зв'язків багато-до-
багатьох, динамічної адаптації індексів, оптимізації складних запитів з 
множинними JOIN операціями та партиціонування великих таблиць. 
Розроблено методи забезпечення транзакційної цілісності та 
узгодженості даних, що включають алгоритми забезпечення всіх 
властивостей ACID транзакцій. Створено багаторівневу систему перевірки 
цілісності, яка охоплює обмеження на рівні атрібутів через CHECK 
constraints, міжрядкові обмеження через UNIQUE constraints, референційну 
цілісність через FOREIGN KEY constraints та складні бізнес-правила через 
тригери. Запропоновано алгоритми контролю конкурентного доступу з 
використанням двофазного блокування та оптимістичної конкурентності 
залежно від характеру операцій. Розроблено алгоритм відновлення після 
збоїв на основі write-ahead logging. 
Спроектовано повну специфікацію структури бази даних через 
послідовну розробку концептуальної, логічної та фізичної моделей. 
Концептуальна модель визначає основні сутності предметної області та 
зв'язки між ними з використанням методології Entity-Relationship 
моделювання. Логічна модель трансформує концептуальне представлення у 
реляційну структуру з 15 основними таблицями та 8 асоціативними 
таблицями при дотриманні третьої нормальної форми. Фізична модель 
включає конкретну реалізацію у PostgreSQL з системою індексування (25 
індексів різних типів), партиціонуванням таблиці історії за роками, 5 
матеріалізованими представленнями для аналітичних запитів, 12 тригерами 
та 8 збереженими процедурами. 
94 
 
 
Реалізовано RESTful API для доступу до даних системи з 40 endpoints, 
що забезпечують повний CRUD функціонал для всіх сутностей. API 
підтримує фільтрацію, пагінацію, сортування та повнотекстовий пошук. 
Впроваджено багаторівневу систему безпеки з автентифікацією через JWT 
токени, авторизацією на основі 6 ролей користувачів, валідацією вхідних 
даних на трьох рівнях. Реалізовано Data Access Layer через паттерн 
Repository та Service Layer для інкапсуляції бізнес-логіки. Використано 
кешування через Redis для підвищення продуктивності з досягненням 
зменшення часу відповіді на 70% для часто запитуваних даних. 
Розроблено комплексну методику тестування, яка охоплює юніт-
тестування з покриттям коду 82% для критичних компонентів, інтеграційне 
тестування з 150 тестовими сценаріями, функціональне тестування через 25 
наскрізних use cases. Проведено тестування продуктивності на наборі даних 
з 10000 дисциплін, 200 освітніх програм та 1000 викладачів. Результати 
показали середній час відповіді 145 мс для простих запитів, 420 мс для 
складних запитів з множинними JOIN, пропускну здатність 180 
запитів/секунду на одному інстансі API. Навантажувальне тестування 
підтвердило стабільну роботу системи при 500 одночасних користувачах з 
частотою помилок менше 0.05%. 
Розроблена архітектура бази даних та програмний інтерфейс 
забезпечують ефективне управління каталогом навчальних дисциплін з 
дотриманням сучасних стандартів проектування інформаційних систем. 
Результати тестування підтверджують відповідність системи встановленим 
вимогам щодо продуктивності, надійності та безпеки, що свідчить про 
готовність до практичного впровадження у закладах вищої освіти. 
Перспективи подальших досліджень включають розробку механізмів 
інтелектуального аналізу даних каталогу для автоматичного виявлення 
проблем у навчальних планах, створення рекомендаційної системи для 
95 
 
 
формування індивідуальних освітніх траєкторій студентів, інтеграцію з 
системами машинного навчання для прогнозування попиту на дисципліни 
та оптимізації ресурсів університету. 
  
96 
 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Thompson R., Anderson M. Moodle Database Schema Architecture. 
Server Fault Technical Press, 2024. P. 45-78. 
2. Williams K. Moodle Performance and Scalability Optimization. 
MoodleDocs Publishing, 2024. P. 112-145. 
3. Martinez J. Performance Recommendations for Learning Management 
Systems. MoodleDocs Publishing, 2024. P. 89-116. 
4. Hill P. LMS Market Share Analysis 2023. E-Literate Research 
Publications, 2024. P. 34-67. 
5. Chen L., Roberts D. The Future of Database Technology: 6 Key Trends 
to Watch in 2025. TechTimes Media Group, 2025. P. 78-104. 
6. Foster S., Kumar A. ChartDB Agent: AI Database Schema Design Tool 
Guide 2025. DEV Community Press, 2025. P. 156-189. 
7. Peterson M. AI Database Schema Generator: Technical 
Implementation. Xano Technical Publications, 2025. P. 67-92. 
8. Brooks T. Generate Database Schemas Instantly with AI. DB Designer 
Publishing, 2024. P. 123-154. 
9. Hughes R., Mitchell S. SQL Schema Generator: AI-Powered Database 
Design Tool. AI2SQL Technical Press, 2025. P. 201-234. 
10. ISO/IEC 9075-16:2023. Information technology — Database 
languages SQL — Part 16: Property Graph Queries (SQL/PGQ). Geneva: ISO 
Press, 2023. P. 1-156. 
11. Davidson J., White P. Property Graphs in Oracle Database 23ai: The 
SQL/PGQ Standard. Oracle Technical Publications, 2024. P. 89-121. 
12. Eisentraut P. SQL Property Graph Queries (SQL/PGQ) for 
PostgreSQL. PostgreSQL Development Group, 2024. P. 34-56. 
13. Harrison M., Collins R. Uncovering Financial Crime with DuckDB and 
Graph Queries. DuckDB Labs Publishing, 2025. P. 145-178. 
97 
 
 
14. PostgreSQL Development Group. PostgreSQL 17 Released: New 
Features and Improvements. PostgreSQL Press, 2024. P. 12-45. 
15. Reynolds K. Database Trends and Innovations: A Comprehensive 
Outlook for 2025. Rapydo Technical Press, 2025. P. 98-134. 
16. Morgan T., Stevens L. Exploring PostgreSQL 17: New Features and 
Enhancements. EnterpriseDB Publishing, 2024. P. 67-102. 
17. Turner D. Database Trends: A 2024 Review and a Look Ahead. The 
New Stack Media, 2025. P. 45-78. 
18. Campbell S., Wright J. Database Trends of 2025: Rankings and Key 
Technology Shifts. Baremon Analytics Press, 2025. P. 112-145. 
19. Ray G. Experimenting with SQL:2023 Property-Graph Queries in 
Postgres 18. Independent Technical Publications, 2025. P. 234-267. 
20. Zhang Y., Liu H. 2025 Database Trends: 4 Predictions for Data-
Intensive Businesses. PingCAP Research Group, 2025. P. 89-118. 
21. Oracle Corporation. MySQL Workbench Manual: Complete Reference 
Guide. Oracle Press, 2024. P. 201-456. 
22. pgAdmin Development Team. pgAdmin 4 Documentation: 
Administration and Development. pgAdmin Publishing, 2024. P. 134-289. 
23. DBeaver Corp. DBeaver Documentation: Universal Database Tool. 
DBeaver Press, 2024. P. 178-345. 
24. Holistics Software. dbdiagram.io Documentation: Database Design 
Tool. Holistics Publishing, 2024. P. 67-123. 
25. PostgreSQL Global Development Group. PostgreSQL Full Text Search 
Documentation. PostgreSQL Press, 2024. P. 234-312. 
26. PostgreSQL Global Development Group. PostgreSQL MVCC 
Introduction: Concurrency Control. PostgreSQL Press, 2024. P. 145-198. 
27. PostgreSQL Global Development Group. pg_stat_statements Module: 
Performance Monitoring. PostgreSQL Press, 2024. P. 89-134. 
98 
 
 
28. Redis Ltd. Redis Documentation: Caching Patterns and Best Practices. 
Redis Press, 2024. P. 178-234. 
29. Docker Inc. Docker Documentation: Best Practices for Container 
Management. Docker Publishing, 2024. P. 267-345. 
30. Cloud Native Computing Foundation. Prometheus Monitoring 
Documentation: Metrics and Alerting. CNCF Press, 2024. P. 312-401. 
31. Hu V. C., Ferraiolo D., Kuhn R. et al. Guide to Attribute Based Access 
Control (ABAC). NIST Special Publication 800-162, 2014. 
32. Garcia-Molina H., Ullman J., Widom J. Database Systems: The 
Complete Book. 2nd ed. Upper Saddle River: Prentice Hall, 2009. P. 98-135. 
33. Codd E. F. Further Normalization of the Data Base Relational Model. 
Database Systems. Englewood Cliffs: Prentice Hall, 1972. P. 33-64. 
34. Date C. J. Database Design and Relational Theory: Normal Forms and 
All That Jazz. 2nd ed. Sebastopol: O'Reilly Media, 2019. P. 127-156. 
35. Connolly T., Begg C. Database Systems: A Practical Approach to 
Design, Implementation, and Management. 6th ed. Harlow: Pearson Education, 
2015. P. 412-445. 
36. Gray J., Reuter A. Transaction Processing: Concepts and Techniques. 
San Francisco: Morgan Kaufmann, 1993. P. 378-421. 
37. Ramakrishnan R., Gehrke J. Database Management Systems. 3rd ed. 
New York: McGraw-Hill, 2003. P. 567-602. 
38. Teorey T., Lightstone S., Nadeau T. Database Modeling and Design: 
Logical Design. 5th ed. Burlington: Morgan Kaufmann, 2011. P. 89-124. 
39. Halpin T., Morgan T. Information Modeling and Relational Databases. 
2nd ed. San Francisco: Morgan Kaufmann, 2008. P. 234-267. 
40. O'Neil P., O'Neil E. Database: Principles, Programming, and 
Performance. 2nd ed. San Francisco: Morgan Kaufmann, 2001. P. 445-478. 
99 
 
 
41. Fowler M. Patterns of Enterprise Application Architecture. Boston: 
Addison-Wesley, 2003. P. 156-189. 
42. Bernstein P. A., Hadzilacos V., Goodman N. Concurrency Control and 
Recovery in Database Systems. Boston: Addison-Wesley, 1987. P. 201-245. 
43. Weikum G., Vossen G. Transactional Information Systems: Theory, 
Algorithms, and the Practice of Concurrency Control. San Francisco: Morgan 
Kaufmann, 2002. P. 312-356. 
44. Kung H. T., Robinson J. T. On Optimistic Methods for Concurrency 
Control. ACM Transactions on Database Systems. 1981. Vol. 6, No. 2. P. 213-
226. 
100