Вдосконалення методу застосування не реляційних баз даних

Турченко, Андрій Сергійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9035
Title:	Вдосконалення методу застосування не реляційних баз даних
Authors:	Метелап, Володимир Володимирович Турченко, Андрій Сергійович
Keywords:	БАЗА ДАНИХ;РЕЛЯЦІЙНА БАЗА ДАНИХ;ТЕКСТОВИЙ ФАЙЛ;ТЕКСТОВА БАЗА ДАНИХ;НЕ РЕЛЯЦІЙНА БАЗА ДАНИХ;БАЗА ДАНИХ У ВИГЛЯДІ ТЕКСТОВОГО ФАЙЛУ;DATABASE;RELATIONAL DATABASE;TEXT FILE;TEXT DATABASE;NON-RELATIONAL DATABASE;TEXT FILE DATABASE
Issue Date:	13-Dec-2023
Abstract:	Турченко Андрій Сергійович Вдосконалення методу застосування не реляційних баз даних 121 «Інженерія програмного забезпечення» Черкаський державний технологічний університет Черкаси 2023 Вдосконалення методу побудови та застосування не реляційних баз даних за рахунок використання текстових файлів для зберігання масиву даних, що дозволяє зменшити час та знизити витрати коштів на розробку проекту ABSTRACT Turchenko Andrii Improving the method of using non-relational databases 121 «Software engineering» Cherkasy State Technological University Cherkasy 2023 Improvement of the method of construction and application of non-relational databases due to the use of text files for storing data arrays, which allows to reduce time and cost of project development
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9035
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота магістра Турченко Андрій Сергійович.pdf Restricted Access		1.85 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
(освітній рівень) 
на тему: Вдосконалення методу застосування не реляційних баз 
даних 
 
 
 
 Виконав: студент 2 курсу, групи МПЗ-2204 
 Напряму підготовки 
 121 «Інженерія програмного забезпечення» 
 (шифр і назва напряму підготовки) 
 
 
 
 Студент Турченко А.С.  
 (прізвище та ініціали) 
 Керівник Метелап В.В.  
 (прізвище та ініціали) 
 Рецензент Корпань Є.О.  
 (прізвище та ініціали) 
 
Черкаси 2023
 
 
 Черкаський державний технологічний університет  
(повне найменування вищого навчального закладу) 
Факультет інформаційних технологій і систем  
Кафедра програмного забезпечення автоматизованих систем  
Освітній рівень магістр  
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
 ЗАТВЕРДЖУЮ 
 Зав. кафедри ПЗАС, професор 
 ________________ Голуб С.М. 
 «___» ____________ 2023 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
 Турченко Андрій Сергійович  
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи): Вдосконалення методу застосування не реляційних баз даних  
Керівник проекту (роботи): Метелап Володимир Володимирович, доцент  
 (прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «06» жовтня 
2023 року №267/04  
2. Строк подання студентом проекту (роботи): 12 грудня 2023 року  
3. Вхідні дані до проекту (роботи): стандарти програмного забезпечення; моделювання 
системи; вимоги до проекту; система управління базами даних; реляційна база даних; не 
реляційна база даних  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити):   
Вступ;  
Існуючі методи і засоби розв’язання поставлених задач;  
Теоретичні та експериментальні дослідження;  
Проектування програмного комплексу;  
Розробка та тестування програмного комплексу;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):   
Титульний слайд; слайд 2 «Назва»; слайд 3 «Назва»; … ; останній слайд.   
  
  
  
  
  
 
 
6. Консультанти розділів проекту (роботи): 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
7. Дата видачі завдання: 04 вересня 2023 року  
КАЛЕНДАРНИЙ ПЛАН 
Строк 
виконання 
№ 
Назва етапів випускної роботи етапів Примітки 
п/п 
випускної 
роботи 
1 Постановка задачі 06.09.2023 виконано 
2 Підготовка завдання 13.09.2023 виконано 
3 Погодження завдання 20.09.2023 виконано 
4 Затвердження завдання 27.09.2023 виконано 
 Основна стадія   
1 Підбір матеріалів 04.10.2023 виконано 
2 Аналіз шляхів вирішення поставленої задачі 11.10.2023 виконано 
3 Розрахунок основних параметрів роботи 18.10.2023 виконано 
4 Вибір кінцевого варіанту проектного рішення 25.10.2023 виконано 
5 Оформлення первісної редакції роботи 01.11.2023 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з керівником 08.11.2023 виконано 
2 Оформлення пояснювальної записки роботи в кінцевій редакції 15.11.2023 виконано 
3 Попередній захист роботи 22.11.2023 виконано 
4 Затвердження роботи 29.11.2023 виконано 
5 Рецензування роботи 06.12.2023 виконано 
6 Захист роботи 12.12.2023 виконано 
 
Студент:    Турченко А.С.  
 (підпис) (прізвище та ініціали) 
 
Керівник проекту (роботи):    Метелап В.В.  
 (підпис) (прізвище та ініціали)
 
 
АНОТАЦЯ 
Турченко Андрій Сергійович 
Вдосконалення методу застосування не реляційних баз даних 
121 «Інженерія програмного забезпечення» 
Черкаський державний технологічний університет 
Черкаси 2023 
Вдосконалення методу побудови та застосування не реляційних баз даних за 
рахунок використання текстових файлів для зберігання масиву даних, що 
дозволяє зменшити час та знизити витрати коштів на розробку проекту 
БАЗА ДАНИХ, РЕЛЯЦІЙНА БАЗА ДАНИХ, ТЕКСТОВИЙ ФАЙЛ, 
ТЕКСТОВА БАЗА ДАНИХ, НЕ РЕЛЯЦІЙНА БАЗА ДАНИХ, БАЗА ДАНИХ У 
ВИГЛЯДІ ТЕКСТОВОГО ФАЙЛУ 
 
 
 
ABSTRACT 
Turchenko Andrii 
Improving the method of using non-relational databases 
121 «Software engineering» 
Cherkasy State Technological University 
Cherkasy 2023 
Improvement of the method of construction and application of non-relational 
databases due to the use of text files for storing data arrays, which allows to reduce time 
and cost of project development 
DATABASE, RELATIONAL DATABASE, TEXT FILE, TEXT DATABASE, 
NON-RELATIONAL DATABASE, TEXT FILE DATABASE 
 
ЧДТУ.232223.026 ПЗ 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ............................................................................ 6 
ВСТУП .............................................................................................................................. 7 
1 ІСНУЮЧІ МЕТОДИ І ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАДАЧ ....... 9 
1.1. Реляційні бази даних ............................................................................................ 9 
1.1.1. Історія виникнення .................................................................................... 9 
1.1.2. Структура ................................................................................................. 11 
1.1.3. Види .......................................................................................................... 11 
1.1.4. Застосування в реальних сценаріях....................................................... 12 
1.1.5. Переваги та недоліки .............................................................................. 14 
1.1.6. Сучасні тенденції та розширення .......................................................... 16 
1.1.7. Методи вдосконалення ........................................................................... 17 
1.2. Нереляційні бази даних ..................................................................................... 18 
1.2.1. Історія виникнення .................................................................................. 19 
1.1.2. Структура ................................................................................................. 20 
1.2.3. Види .......................................................................................................... 21 
1.2.4. Застосування в реальних сценаріях....................................................... 22 
1.2.5. Переваги та недоліки .............................................................................. 24 
1.2.6. Сучасні тенденції та розширення .......................................................... 25 
1.2.7. Методи вдосконалення ........................................................................... 27 
1.3. Бази даних у вигляді текстових файлів ............................................................ 29 
1.3.1. Історія виникнення .................................................................................. 29 
1.3.2. Структура ................................................................................................. 30 
1.3.3. Види .......................................................................................................... 31 
1.3.4. Застосування в реальних сценаріях....................................................... 32 
1.3.5. Переваги та недоліки .............................................................................. 33 
1.3.6. Сучасні тенденції та розширення .......................................................... 34 
1.3.7. Методи вдосконалення ........................................................................... 36 
Висновки до розділу ................................................................................................. 38 
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ............................. 39 
3 
 
ЧДТУ.232223.026 ПЗ 
2.1. Теоретичні дослідження .................................................................................... 39 
2.1.1. Постановка задачі структурної ідентифікації ...................................... 40 
2.1.2. Теорія та гіпотеза .................................................................................... 42 
2.1.3. Створення баз даних ............................................................................... 43 
2.1.4. Робота з базами даних ............................................................................ 44 
2.1.5. Імпорт/експорт даних до/з електронної таблиці Microsoft Excel ....... 44 
2.1.6. Редагування інформація у хостинг-панелі web-сайту ......................... 47 
2.1.7. Зміна web-хостингу ................................................................................. 47 
2.2. Експериментальні дослідження ........................................................................ 48 
2.2.1. Створення баз даних ............................................................................... 48 
2.2.2. Робота з базами даних ............................................................................ 49 
2.2.3. Імпорт/експорт даних до/з електронної таблиці Microsoft Excel ....... 52 
2.2.4. Редагування інформація у хостинг-панелі web-сайту ......................... 55 
2.2.5. Зміна web-хостингу ................................................................................. 55 
Висновки до розділу ................................................................................................. 58 
3 ПРОЕКТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ ............................................ 60 
3.1. Моделювання предметної області .................................................................... 60 
3.1.1. Предметна область моделювання: модель, словник ........................... 60 
3.1.2. Елементи моделювання предметної області ........................................ 60 
3.1.3. Робоча область моделювання ................................................................ 62 
3.2. Формування та аналіз вимог ............................................................................. 63 
3.2.1. Формування вимог .................................................................................. 63 
3.2.2. Формування вимог за допомогою діаграми прецедентів ................... 64 
3.2.3. Проектування логічної структури ......................................................... 66 
3.2.3.1. Діаграми класів .......................................................................... 66 
3.2.3.2. Діаграми пакетів ........................................................................ 70 
3.2.4. Архітектурне проектування ................................................................... 71 
3.2.4.1. Діаграма компонентів ................................................................ 71 
3.2.4.2. Розгортання програмної системи на апаратних засобах ....... 73 
3.2.5. Моделювання поведінки системи ......................................................... 74 
4 
 
ЧДТУ.232223.026 ПЗ 
3.2.5.1. Діаграма діяльності .................................................................... 74 
3.2.5.2. Діаграма послідовності ............................................................. 76 
3.2.5.3. Діаграма комунікації ................................................................. 79 
3.2.5.4. Діаграма скінченного автомату ................................................ 81 
Висновки до розділу ................................................................................................. 86 
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ ...................... 87 
4.1. Розробка програмного комплексу .................................................................... 87 
4.1.1. Обґрунтування вибору засобів реалізації ............................................. 87 
4.1.2. Опис структурної (функціональної) схеми .......................................... 88 
4.1.3. Опис логічної схеми ............................................................................... 90 
4.1.4. Розробка бази даних ............................................................................... 92 
4.1.5. Розробка інтерфейсу користувача ......................................................... 94 
4.1.6. Розробка програмних компонентів ....................................................... 95 
4.2. Тестування програмного комплексу ................................................................ 99 
4.2.1. Модульне тестування ............................................................................. 99 
4.2.2. Інтеграційне тестування ....................................................................... 100 
4.2.3. Системне тестування ............................................................................ 101 
4.2.4. Приймальне тестування ........................................................................ 101 
4.3. Приклади впровадженого програмного комплексу ...................................... 101 
Висновки до розділу ............................................................................................... 105 
ВИСНОВКИ ................................................................................................................. 106 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................... 109 
ДОДАТОК А Специфікація ............................... Ошибка! Закладка не определена. 
ДОДАТОК Б Інструкція користувачеві ............ Ошибка! Закладка не определена. 
 
5 
 
ЧДТУ.232223.026 ПЗ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ 
БД – база даних 
НБД – нереляційна база даних 
РБД – реляційна база даних 
СУБД – система управління базами даних 
ТБД – база даних у вигляді текстового файлу 
UML – Unified Modeling Language (уніфікована мова моделювання) 
6 
 
ЧДТУ.232223.026 ПЗ 
ВСТУП 
Актуальність теми. В світі сучасних інформаційних технологій, коли 
ринок насичений різноманітними програмними продуктами та інструментами для 
роботи з базами даних, вибір оптимального типу бази даних стає стратегічно 
важливим завданням. Хоча класичні реляційні бази даних є широко поширеними 
та універсальними, вони можуть бути занадто об’ємними для невеликих проектів. 
Зокрема, враховуючи структуру та складність програмного продукту, інколи 
виправдано віддати перевагу менш поширеним, але більш ефективним 
інструментам. 
Вибір типу бази даних стає особливо актуальним у контексті масштабу 
проекту, його завдань та фінансових можливостей. Для невеликих проектів, де 
обсяг даних менш об’ємний, а вимоги до швидкодії не настільки критичні, 
спеціалізовані бази даних можуть забезпечити більш оптимальний та ефективний 
підхід. Такий підхід дозволяє зекономити ресурси та оптимізувати використання 
програмного забезпечення, що може бути ключовим для успіху невеликих 
проектів в умовах конкурентного середовища. 
Зв’язок з науковими програмами, планами, темами. Робота в рамках 
наукових досліджень кафедри програмного забезпечення автоматизованих 
систем. 
Мета і завдання досліджень. Вдосконалення методу застосування не 
реляційних баз даних. Для досягнення цієї мети треба виконати такі завдання: 
1 Провести інформаційний пошук методів та засобів розв’язання 
поставлених задач. 
2 Дослідити структуру баз даних з метою виявлення напрямків їх 
вдосконалення. 
3 Вдосконалити метод побудови не реляційних баз даних. 
4 Спроектувати та програмно реалізувати програмний продукт оцінки 
швидкодії баз даних для отримання додаткових результатів досліджень. 
5 Експериментально дослідити ефективність застосування не реляційних 
баз даних на практиці. 
7 
 
ЧДТУ.232223.026 ПЗ 
Об’єкт досліджень. Практичне застосування вдосконаленого методу 
побудови не реляційних баз даних. 
Предмет досліджень. Процес створення та застосування не реляційної бази 
даних. 
Методи досліджень. Для досягнення поставленої мети застосовано такі 
методи: порівняння і спостереження – під час вивчення існуючих підходів до 
зберігання масиву даних в контексті вибору оптимального типу бази даних; 
абстрагування, емпіричний аналіз, моделювання, системний підхід та 
формалізація – в процесі формування теорії та гіпотези, а також прогнозуванні 
конкретних подій при виборі типу баз даних; експеримент і синтез – при перевірці 
та валідації теоретичних концепцій, а також у побудові прототипу реалізації, для 
підтвердження його відповідності обраній моделі. 
Наукова новизна отриманих результатів. Вдосконалення методу 
побудови та застосування не реляційних баз даних за рахунок використання 
текстових файлів для зберігання масиву даних, що дозволяє зменшити час та 
знизити витрати коштів на розробку проекту. 
Практичне значення отриманих результатів. Вдосконалено метод 
застосування не реляційних баз даних для використання в web-проектах не 
великого обсягу.  
Особистий внесок автора. Всі відображені в роботі результати 
представлені автором особисто. 
Публікації. Участь у ІІ Міжнародній науково-практичній Інтернет-
конференції: «Інновації та перспективні шляхи розвитку інформаційних 
технологій» 6 Грудня 2023 року на тему: «Вдосконалення методу застосування не 
реляційних баз даних» (результати конференції у формі тез). 
8 
 
ЧДТУ.232223.026 ПЗ 
1 ІСНУЮЧІ МЕТОДИ І ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАДАЧ 
У світі сучасних інформаційних технологій управління базами даних займає 
центральне місце в розробці та збереженні великих обсягів даних. Для досягнення 
ефективності та оптимальності обробки інформації, використання різних типів баз 
даних стає ключовим аспектом. Існує три основних підходи до організації 
зберігання даних, кожен з яких має свої унікальні характеристики та визначається 
застосуванням у різноманітних сценаріях роботи з даними. Ретельний аналіз 
переваг і недоліків кожного типу бази даних дозволить визначити оптимальні 
стратегії використання в залежності від конкретних вимог та завдань. 
1.1. Реляційні бази даних 
Реляційні бази даних представляють собою основний компонент сучасної 
системи управління даними, заснований на реляційній моделі Едгара Кодда. Вони 
використовують таблиці для організації та зберігання даних, визначаючи 
відносини між ними. Реляційні бази даних відіграють ключову роль у розв’язанні 
завдань обробки та аналізу інформації в різноманітних областях, забезпечуючи 
ефективне управління великим обсягом даних [1]. 
1.1.1. Історія виникнення 
Історія реляційних баз даних почалася в 1970 році, коли Едгар Кодд 
представив реляційну модель даних, що визначила новий підхід до організації і 
управління інформацією. З того часу, з розвитком стандартів SQL та появою 
різноманітних систем управління реляційними базами даних, вони стали 
визнаними та широко використовуваними інструментами в галузі обробки даних 
та управління інформацією. Основними етапами розвитку є [2]: 
1 Попередні моделі даних (до 1960-х). Перші етапи роботи з базами даних 
пов’язані з ієрархічними та мережевими моделями даних, такими як CODASYL та 
IMS. Ці моделі використовували структуру дерева для зберігання та організації 
даних. 
2 Поява реляційної моделі (1970). В 1970 році Едгар Кодд (Edgar Codd) 
9 
 
ЧДТУ.232223.026 ПЗ 
представив реляційну модель даних в статті «A Relational Model of Data for Large 
Shared Data Banks» [3]. Вона визначала дані у вигляді таблиць, що визначали 
відносини між рядками та стовпцями. 
3 Розробка системи управління базами даних (1970-1974). Під впливом 
реляційної моделі Тед Кодд (Ted Codd), Реймонд Бойс (Raymond Boyce) та 
Дональд Чемберлін (Donald Chamberlin) розробили SQL (Structured Query 
Language) – мову запитів, яка стала основою для взаємодії з реляційними базами 
даних. 
4 Поширення реляційних баз даних (1970-1980). Протягом наступного 
десятиліття концепція реляційних баз даних стала популярною, і розпочалася 
розробка різних систем управління реляційними базами даних, таких як Oracle, 
IBM DB2, та Microsoft SQL Server. 
5 Комерційне застосування (1980-1990). В цей час великі компанії почали 
впроваджувати реляційні бази даних для зберігання та управління великим 
обсягом інформації. Це стало ключовим етапом у комерційному використанні 
реляційних баз даних. 
6 Стандартизація та розширення (1990-2000). У цей період реляційні бази 
даних стали об’єктом стандартизації, і ANSI SQL став загально прийнятим 
стандартом для мови запитів. Появилися різноманітні розширення, такі як 
тригери, процедури та індекси. 
7 Інтернет та біг дата (з 2000-х). З розвитком Інтернету та зростанням 
обсягів даних з’явилися нові виклики. Реляційні бази даних стали 
використовуватися для вирішення завдань обробки великих обсягів даних (біг 
дата), адаптуючись до нових сценаріїв використання. 
8 Хмарні рішення та інновації (з 2010-х). З розвитком хмарних технологій, 
реляційні бази даних стали доступні для користувачів через хмарні сервіси. 
З’явилися нові можливості інтеграції з іншими технологіями, такими як машинне 
навчання, інтернет речей (IoT) та інші інновації. 
Історія реляційних баз даних свідчить про їхню еволюцію від концепційних 
моделей до потужних інструментів управління даними, що успішно 
10 
 
ЧДТУ.232223.026 ПЗ 
використовуються в сучасному світі для різноманітних завдань та застосувань. 
1.1.2. Структура 
Структура реляційної бази даних ґрунтується на реляційній моделі, яка 
використовує таблиці для організації та представлення даних [4]. Основні 
компоненти структури включають: 
1 Таблиці (Relational Tables): 
 таблиця представляє собою реляцію, що містить дані конкретного 
типу; 
 рядок таблиці – це кортеж, або запис, що представляє сутність даних; 
 стовпчик таблиці – це атрибут, або поле, яке визначає конкретний 
аспект сутності. 
2 Ключі (Keys): 
 первинний ключ (Primary Key). Унікальний ідентифікатор для кожного 
запису в таблиці; 
 зовнішній ключ (Foreign Key). Вказує на зв’язок між двома таблицями, 
базуючись на первинному ключі однієї з них. 
3 Відносини (Relationships): 
 зв’язки між таблицями визначають, як вони пов’язані між собою; 
 взаємодія відбувається через використання ключів. 
4 Схема даних (Database Schema): 
 визначає структуру бази даних, включаючи таблиці, їхні атрибути та 
відносини. 
Отже, структура реляційних баз даних, ґрунтована на реляційній моделі, 
визначається таблицями, ключами та відносинами, що забезпечує організацію та 
управління даними в ефективний та структурований спосіб. 
1.1.3. Види 
На ринку існує безліч реляційних баз даних, але деякі з них набули 
особливої популярності через їхню ефективність, функціональність та 
розповсюдженість. Ось кілька найпоширеніших видів реляційних баз даних: 
11 
 
ЧДТУ.232223.026 ПЗ 
1 MySQL [5] є відкритою реляційною системою управління базами даних, 
яка здобула широку популярність завдяки своїй простоті використання та 
великому співтовариству користувачів. Вона широко використовується для web-
розробки та інших застосувань. 
2 PostgreSQL [6] є могутньою об’єктно-реляційною системою управління 
базами даних, яка надає велику кількість функціональних можливостей. Вона 
добре підходить для великих проектів та додатків, де важлива розширюваність та 
дотримання стандартів SQL. 
3 Oracle Database [7] є комерційною реляційною системою управління 
базами даних, яка використовується у великих корпоративних середовищах. Вона 
відома своєю високою продуктивністю, надійністю та розширюваністю. 
4 Microsoft SQL Server [8] є розробкою корпорації Microsoft, це 
комплексне рішення для управління базами даних в середовищі Windows. Він 
використовується для різних застосувань, включаючи корпоративні інформаційні 
системи та веб-додатки. 
5 SQLite [9] є легкою та вбудовуваною реляційною системою управління 
базами даних, яка часто використовується в мобільних додатках, вбудованих 
системах та web-розробці. Вона славиться своєю простотою та ефективністю. 
6 MariaDB [10] є відкритою альтернативою MySQL, яка зберігає сумісність 
з MySQL та розвивається спільнотою. Вона підтримує велику кількість функцій 
та є однією з популярних вибірок для розробників. 
Ці системи управління базами даних представляють лише кілька прикладів 
реляційних баз даних, і вибір конкретної залежить від конкретних потреб проекту, 
вимог до продуктивності, масштабованості та інших факторів. 
1.1.4. Застосування в реальних сценаріях 
Реляційні бази даних виконують ключову роль в сучасному світі обробки 
інформації, забезпечуючи ефективне та структуроване зберігання даних для 
найрізноманітніших сфер. Застосування реляційних баз даних охоплює широкий 
спектр галузей, а їхня надійність, продуктивність та зручність у використанні 
роблять реляційні бази даних невід’ємною частиною інфраструктури для 
12 
 
ЧДТУ.232223.026 ПЗ 
зберігання та управління великими обсягами даних у реальному часі [11]. Серед 
них є: 
1 Електронна комерція (E-commerce): 
 системи керування замовленнями. Реляційні бази даних 
використовуються для зберігання та обробки інформації про товари, 
клієнтів та замовлення в онлайн-магазинах; 
 бази даних користувачів та профілі. Для управління даними 
користувачів, їхніми профілями та історією покупок. 
2 Фінансовий сектор: 
 системи банківського обліку. Зберігання та обробка інформації про 
транзакції, клієнтські рахунки та фінансові операції; 
 системи управління ризиками. Використання реляційних баз даних для 
аналізу фінансових даних та керування ризиками в інвестиціях. 
3 Освіта: 
 університетські інформаційні системи. Зберігання та управління 
даними про студентів, викладачів, навчальні плани та оцінки; 
 електронні бібліотеки та ресурси. Використання реляційних баз даних 
для організації та пошуку літературних ресурсів. 
4 Бізнес та логістика: 
 системи Управління Ланцюгом постачання. Використання реляційних 
баз даних для відстеження запасів, замовлень та взаємодії з 
постачальниками; 
 клієнтські відносини та CRM-системи. Зберігання та аналіз даних про 
клієнтів для покращення обслуговування та взаємодії. 
5 Організаційні ІТ-системи: 
 системи управління проектами. Використання реляційних баз даних 
для організації даних про завдання, виконавців та витрати на проекти; 
 внутрішні ІТ-системи. Зберігання даних про користувачів, доступи та 
системи управління ресурсами. 
6 Органи управління та державні служби: 
13 
 
ЧДТУ.232223.026 ПЗ 
 системи електронного урядування. Забезпечення зберігання та обробки 
даних для державних служб, реєстрації населення та електронних 
послуг; 
 фіскальні системи. Використання реляційних баз даних для зберігання 
та аналізу фіскальних даних та звітності. 
7 Медична галузь: 
 електронні медичні записи. Зберігання та управління медичними 
історіями, діагнозами та рецептами пацієнтів; 
 системи управління лікарнями та клініками. Використання реляційних 
баз даних для оптимізації лікарської діяльності, призначення 
обладнання та контролю лікарських запасів. 
Це лише кілька прикладів того, як реляційні бази даних використовуються в 
реальних сценаріях. Вони дозволяють ефективно управляти великими обсягами 
даних, забезпечуючи надійність та доступність для різних галузей та бізнес-
сегментів. 
1.1.5. Переваги та недоліки 
Реляційні бази даних є ключовим елементом сучасного управління 
інформацією, пропонуючи структуровану та надійну систему для зберігання 
даних. Вони володіють великим рядом переваг, однак, на їх фоні, вони також 
мають і недоліки. Тому важливо їх зрозуміти для збалансованого та ефективного 
використання цієї технології у різних контекстах [12]. 
Переваги: 
1 Структурована організація даних. Реляційні бази даних забезпечують 
чітку та структуровану організацію даних у вигляді таблиць, що робить легким 
їхнє розуміння та управління. 
2 Мова SQL. Використання SQL (Structured Query Language) спрощує 
вирази запитів та надає їхню універсальність, що робить роботу з базою даних 
доступною та ефективною. 
3 Цілісність та нормалізація даних. Реляційні бази даних дозволяють 
14 
 
ЧДТУ.232223.026 ПЗ 
визначати відносини між таблицями, що сприяє цілісності даних та уникненню 
дублювання інформації. 
4 Транзакційна безпека. Механізми транзакцій забезпечують безпеку 
даних, забезпечуючи атомарність, консистентність, ізольованість та довершеність 
транзакцій. 
5 Легка розширюваність. Додавання нових атрибутів та таблиць може 
бути легко виконано без великої переробки схеми даних, що робить систему легко 
розширюваною. 
6 Універсальність застосування. Реляційні бази даних широко 
використовуються у багатьох галузях, від бізнесу та освіти до медицини та галузі 
інформаційних технологій. 
Недоліки: 
1 Гнучкість схеми даних. Ускладнення внесення змін у схему даних може 
бути часом важким та вимагати великої уваги. 
2 Обмежена швидкодія при складних запитах. При обробці великих 
обсягів даних чи складних запитів швидкодія реляційних баз даних може стати 
обмеженою. 
3 Схильність до надмірної нормалізації. Намагання до повної нормалізації 
може призвести до переускладнення структури бази даних, що ускладнює 
використання. 
4 Неефективність для деяких типів запитів. Реляційні бази даних можуть 
бути менш ефективними для деяких видів запитів, зокрема тих, які включають 
складні операції об’єднання та групування. 
5 Споживання ресурсів. Деякі реляційні бази даних можуть споживати 
значні ресурси, особливо при роботі з великим обсягом даних, що може вимагати 
потужних серверів та обладнання. 
6 Неефективність для неструктурованих даних. Реляційні бази даних не 
завжди ефективно обробляють неструктуровані дані, такі як тексти, зображення 
або відео. 
Незважаючи на недоліки, реляційні бази даних залишаються одними з 
15 
 
ЧДТУ.232223.026 ПЗ 
найпоширеніших та ефективних засобів управління даними в різних сценаріях. 
При виборі варто враховувати конкретні потреби та вимоги проекту. 
1.1.6. Сучасні тенденції та розширення 
Сучасні тенденції та розширення в галузі реляційних баз даних 
відображають динаміку розвитку цієї технології в епоху цифрових інновацій. 
Вони постійно розвиваються для відповіді на виклики сучасного світу даних. 
Тенденції включають в себе розширення можливостей для обробки 
нестандартних типів даних, високу доступність та масштабованість, а також 
підтримку хмарних технологій [13]. Основними напрямками є: 
1 Хмарні реляційні бази даних (DBaaS). Зростаючий інтерес до хмарних 
технологій призводить до появи різноманітних хмарних рішень для розміщення та 
управління реляційними базами даних як послуги (DBaaS). Це спрощує 
розгортання, масштабування та керування реляційних баз даних, знижуючи 
необхідність в інфраструктурі на місці. 
2 Інтернет речей (IoT) та біг дата. Збільшення обсягів даних від сенсорів 
та пристроїв IoT призводить до використання реляційних баз даних для 
ефективного зберігання та аналізу великих обсягів інформації. Розширені 
можливості обробки даних дозволяють витягати цінні знання з біг даних. 
3 Нові системи управління даними (DBMS). З’являються нові DBMS, що 
орієнтовані на підвищення продуктивності та ефективності в роботі з великими 
обсягами даних. Деякі з них використовують новаторські підходи, такі як графові 
бази даних, для вирішення конкретних викликів. 
4 Автоматизоване управління та оптимізація. Зростання автоматизації 
управління базами даних дозволяє покращити їх продуктивність та надійність. 
Інтелектуальні системи можуть автоматично оптимізувати запити, виявляти та 
усувати помилки та підтримувати цілісність даних. 
5 Інтеграція з машинним навчанням та штучним інтелектом. 
Розширення можливостей аналізу даних та використання моделей машинного 
навчання в базах даних дозволяє здійснювати продуктивний аналіз та витягати 
нові знання з інформації. 
16 
 
ЧДТУ.232223.026 ПЗ 
6 Географічно розподілені системи (GDDBMS). Зростаюча потреба у 
роботі з географічно розподіленими даними (наприклад, глобальні організації, де 
дані зберігаються на різних континентах) призводить до розвитку GDDBMS для 
забезпечення ефективності та доступності. 
7 Використання умовних моделей консистентності. Розширення 
концепцій консистентності даних, включаючи введення умовних моделей (як 
CAP-теорія), для більш гнучкого керування рівнем доступності та 
консистентності в розподілених системах. 
8 Безпека та захист даних. Зростаюча увага до кібербезпеки призводить до 
розробки нових методів шифрування, контролю доступу та інших заходів захисту 
даних у реляційних баз даних. 
Ці тенденції та розширення в галузі реляційних баз даних свідчать про 
постійний розвиток та адаптацію до сучасних викликів у сфері обробки даних. 
1.1.7. Методи вдосконалення 
Реляційні бази даних визнані за стабільні та надійні, але від початку свого 
існування до наших днів розвиваються та вдосконалюються. Методи 
вдосконалення спрямовані на поліпшення продуктивності, гнучкості та 
забезпечення оптимальної роботи в умовах сучасних викликів обробки даних [14]. 
Отже, ключовими аспектами є: 
1 Нормалізація: 
 мета. Зменшити або усунути аномалії та дублювання даних; 
 рішення. Розбиття таблиць на менші, більш специфічні одиниці для 
забезпечення цілісності та ефективності. 
2 Індексація: 
 мета. Покращення швидкодії запитів шляхом створення індексів на 
певні стовпці; 
 рішення. Створення структур, які прискорюють пошук та фільтрацію 
даних. 
3 Партіціювання: 
17 
 
ЧДТУ.232223.026 ПЗ 
 мета. Розділення великих таблиць на менші частини (партіції) для 
оптимізації управління та операцій з даними; 
 рішення. Розміщення даних на окремих фізичних пристроях або в 
різних таблицях за певним критерієм. 
4 Горизонтальне та вертикальне шардування: 
 мета. Розбиття бази даних на частини (шарди) для підвищення 
швидкодії та масштабованості; 
 рішення. Горизонтальне – розподіл рядків, вертикальне – розподіл 
стовпців між різними серверами або базами даних. 
5 Інтеграція з іншими технологіями: 
 мета. Забезпечення взаємодії реляційних баз даних з новими 
технологіями, такими як графові бази даних, NoSQL рішення, системи 
потокової обробки тощо; 
 рішення. Використання спеціалізованих інструментів для оптимізації 
конкретних видів даних чи завдань. 
6 Оптимізація запитів: 
 мета. Забезпечення ефективності виконання запитів до бази даних; 
 рішення. Використання індексів, аналіз та оптимізація структури 
запитів, кешування та інші техніки для поліпшення продуктивності. 
7 Безпека та аудит: 
 мета. Захист даних від несанкціонованого доступу та відновлення в 
разі виникнення проблем; 
 рішення. Використання шифрування, прав доступу, систем аудиту та 
резервного копіювання для забезпечення безпеки. 
Ці методи та стратегії вдосконалення допомагають не лише оптимізувати 
роботу реляційних баз даних, але й адаптуватися до зростаючих вимог у сфері 
обробки та управління даними. 
1.2. Нереляційні бази даних 
Нереляційні бази даних представляють новий підхід до зберігання та 
18 
 
ЧДТУ.232223.026 ПЗ 
обробки даних, відрізняючись від традиційних реляційних баз своєю гнучкістю та 
можливістю ефективно опрацьовувати великі обсяги структурованих та 
неструктурованих даних. Цей різноманітний клас систем управління базами 
даних відповідає на виклики, що виникають у сучасних сценаріях роботи з 
інформацією, таких як обробка великих обсягів даних, робота з великими 
потоками інформації та інші аспекти сучасного інформаційного середовища [15]. 
1.2.1. Історія виникнення 
Нереляційні бази даних з’явилися як реакція на виклики традиційних 
реляційних систем управління даними. Починаючи з 2000-х років, вони стали 
експериментальними рішеннями для забезпечення гнучкості та масштабованості в 
умовах великих обсягів даних та розподіленого обчислення. Їхня історія 
відзначається постійним розвитком та диверсифікацією, щоб відповідати 
різноманітним потребам індустрії в обробці даних. Основними етапами розвитку 
є [16]: 
1 Фон: перед нереляційними базами даних (1970-2000). До своєї появи, 
реляційні бази даних були основним інструментом для зберігання та управління 
даними. Проте, з ростом обсягів даних та потреб у вищій швидкості обробки, 
почали виникати виклики для традиційних реляційних баз даних. 
2 Початок ери нереляційних баз даних (2000-2009). З появою Web 2.0 
з’явилися нові вимоги до обробки даних, особливо в галузі соціальних мереж та 
великих обсягів користувацьких даних. Програмісти та інженери стали шукати 
альтернативні рішення до традиційних реляційних баз даних. 
3 Перші кроки: динамічні мови та ключ-значення (2000-2010). Перші 
рішення зосереджувалися на простих моделях даних, таких як ключ-значення. 
Програмісти почали використовувати нереляційні бази даних для швидкої 
зберігання та отримання даних в областях, де не потрібна складна структура. 
4 Диверсифікація: документоорієнтовані та колоночні сховища (з 2010-
х). У цей період розвитку нереляційних баз даних з’явилися різні підтипи, 
включаючи документоорієнтовані бази даних, колоночні сховища тощо. Це 
дозволило краще відповідати конкретним вимогам різних сценаріїв використання. 
19 
 
ЧДТУ.232223.026 ПЗ 
5 Зростання популярності та прийняття (з 2010-х). З 2010-х років 
нереляційних баз даних стали популярними в багатьох індустріях, зокрема в 
інтернет-гігантах, де обробка великих обсягів даних стала нормою. Ці системи 
знайшли застосування в розподілених та масштабованих системах. 
6 Інтернет речей (IoT) та біг дата (з 2010-х). З ростом кількості 
підключених пристроїв та збільшенням обсягів даних виникла потреба в 
розподілених та гнучких рішеннях, що дозволяють ефективно працювати з 
великим потоком інформації, що надходить в режимі реального часу. 
7 Хмарні рішення (з 2010-х). В останні роки нереляційні бази даних стали 
доступними через хмарні сервіси, що робить їх ще більш доступними для 
розробників та підприємств, що прагнуть швидко масштабувати свої бази даних. 
Історія розвитку нереляційних баз даних віддзеркалює потреби сучасного 
світу у гнучких та масштабованих рішеннях для зберігання та обробки даних. Від 
початкового етапу експериментів до визнання у великих індустріях, нереляційні 
бази даних відіграють важливу роль у сучасному ландшафті управління даними. 
1.1.2. Структура 
Нереляційні бази даних відрізняються від класичних реляційних моделей, 
враховуючи різноманітні підходи до організації та зберігання інформації. Їх 
структура різноманітна, оскільки вона залежить від конкретного типу [17], а саме: 
1 Ключ-значення сховища (Key-Value Stores). Представляють собою 
простий механізм зберігання даних у вигляді пар ключ-значення. Кожен елемент 
має унікальний ключ, який вказує на відповідний йому набір даних. 
2 Документоорієнтовані сховища (Document Stores). Зберігають дані у 
вигляді документів, часто у форматі JSON чи BSON. Документ представляє собою 
пару «ключ-значення» та може включати вкладені структури. 
3 Колоночні сховища (Column-Family Stores). Дані зберігаються у вигляді 
колонок, а не рядків, іноді групуються у сімейства колонок. Підходить для 
операцій з великим обсягом даних. 
4 Графові бази даних (Graph Databases). Моделюють дані у вигляді 
графів, де вузли представляють об’єкти, а ребра – взаємозв’язки між ними. 
20 
 
ЧДТУ.232223.026 ПЗ 
5 Масивні онлайн аналітичні системи (Massive Online Analytical 
Processing). Використовують широкі колонки для зберігання та операцій з 
даними. Використовується для аналізу великих обсягів даних у режимі реального 
часу. 
6 Векторні сховища даних (Vector Data Stores). Спеціалізовані для роботи 
із векторними даними, що використовуються у геоінформаційних системах (ГІС) 
та обробці геоданих. 
7 Мультимодальні бази даних (Multi-model Databases). Дозволяють 
зберігати дані різних типів (структуровані, неструктуровані, графові) в одній базі 
даних. 
Кожен тип нереляційної бази даних має свою внутрішню структуру та 
особливості, що роблять їх оптимальними для конкретних випадків використання. 
Такий диверсифікований підхід дозволяє вибирати оптимальний тип бази даних в 
залежності від вимог конкретного проекту. 
1.2.3. Види 
Нереляційні бази даних охоплюють різноманітні типи систем управління 
даними, що відрізняються за своєю структурою та підходом до зберігання і 
обробки інформації. Кожен тип нереляційної бази даних має свої унікальні 
властивості та використовується для вирішення певного спектру завдань в 
сучасних системах обробки даних. Можна виділити ключові категорії, такі як: 
1 Redis [18], Amazon DynamoDB [19] (ключ-значення сховища) – 
зберігання сесій, кешування, швидкодіяльність у випадку простих операцій. 
2 MongoDB [20], Apache CouchDB [21] (документоорієнтовані сховища) 
– зберігання та опрацювання документів, колекцій, інтеграція з різноманітними 
джерелами даних. 
3 Apache Cassandra [22], Apache HBase [23] (колоночні сховища) – 
аналітика даних, зберігання великих обсягів даних з високою швидкодією. 
4 Neo4j [24], Amazon Neptune [25] (графові бази даних) – аналіз 
соціальних мереж, маршрутизація, виявлення взаємозв’язків у складних даних. 
5 Google Bigtable [26], Apache Accumulo [27] (масивні онлайн аналітичні 
21 
 
ЧДТУ.232223.026 ПЗ 
системи) – аналітика великих обсягів даних, бізнес-звітність. 
6 GeoMesa [28], Couchbase [29] (векторні сховища даних) – зберігання та 
опрацювання географічних даних. 
7 ArangoDB [30], OrientDB [31] (мультимодальні бази даних) – 
універсальні рішення для різноманітних типів даних та сценаріїв використання. 
Кожен тип нереляційної бази даних має свої особливості, які визначаються 
призначенням та потребами конкретних сценаріїв використання. Вибір 
підходящого типу залежить від конкретних вимог до даних та характеристик 
системи. 
1.2.4. Застосування в реальних сценаріях 
Нереляційні бази даних стали необхідною складовою для вирішення 
викликів, що виникають у світі сучасних технологій. Їх застосування в реальних 
сценаріях охоплює широкий спектр областей. Ці бази даних надають гнучкість, 
ефективність та масштабованість, використовуючи різноманітні моделі даних для 
вирішення конкретних вимог різних галузей та сценаріїв використання. 
Розглянемо, як нереляційні бази даних трансформують підходи до зберігання та 
обробки інформації у сучасному цифровому середовищі [32]: 
1 Соціальні мережі: 
 застосування. Бази даних типу графових дозволяють ефективно 
моделювати взаємозв’язки між користувачами та їх взаємодії, що є 
критичним у соціальних мережах; 
 приклади. Facebook використовує Apache Cassandra для зберігання 
великих обсягів даних про соціальні взаємодії. 
2 Інтернет речей (IoT): 
 застосування. Для обробки великих потоків даних від підключених 
пристроїв та забезпечення швидкодії та масштабованості системи; 
 приклади. MongoDB застосовується в IoT-проектах для зберігання та 
обробки даних в реальному часі. 
3 Аналітика та біг дата: 
22 
 
ЧДТУ.232223.026 ПЗ 
 застосування. Колоночні сховища використовуються для аналізу 
великих обсягів структурованих даних, забезпечуючи високу 
швидкодію та масштабованість; 
 приклади. Apache Cassandra, Amazon DynamoDB використовуються в 
аналітичних системах для забезпечення ефективного зберігання та 
обробки даних. 
4 Електронна торгівля: 
 застосування. Документоорієнтовані бази даних підтримують гнучкі 
структури даних, що є важливим для електронної торгівлі, де формати 
товарів можуть варіюватися; 
 приклади. CouchDB застосовується для зберігання та обробки даних в 
електронній торгівлі. 
5 Геоінформаційні системи (ГІС): 
 застосування. Векторні сховища даних використовуються для 
зберігання та опрацювання географічних даних, що є ключовим в ГІС-
проектах; 
 приклади. GeoMesa використовується для зберігання та аналізу 
геоданих. 
6 Логістика та управління ланцюгом постачання: 
 застосування. Графові бази даних дозволяють моделювати складні 
взаємозв’язки у логістичних мережах та управляти ланцюгом 
постачання; 
 приклади. Neo4j використовується для оптимізації логістичних 
процесів та управління інфраструктурою постачання. 
7 Онлайн геймінг: 
 застосування. Бази даних типу ключ-значення використовуються для 
зберігання стану гри та даних гравців, забезпечуючи швидкий доступ 
до ігрової інформації; 
 приклади. Redis використовується в онлайн іграх для забезпечення 
низької латентності та швидкодії. 
23 
 
ЧДТУ.232223.026 ПЗ 
Застосування нереляційних баз даних розповсюджене в різних галузях і 
вирішує різноманітні завдання, від обробки великих обсягів даних до 
забезпечення швидкодії та гнучкості у високонавантажених системах. 
1.2.5. Переваги та недоліки 
В епоху великих обсягів даних та швидкого розвитку технологій, вибір 
оптимального типу бази даних стає стратегічно важливим завданням для багатьох 
організацій. Нереляційні бази даних виступають як відповідь на виклики, 
пов’язані з обробкою та зберіганням даних в умовах, коли традиційні реляційні 
моделі можуть досягти свого межового рівня. Нереляційні бази даних 
представляють собою інноваційний підхід до зберігання та обробки даних, 
визнаний своєю гнучкістю та ефективністю. Проте переваги і недоліки потрібно 
ретельно враховувати при виборі рішення для конкретного проекту [33]. 
Переваги: 
1 Гнучкість та швидкодія. Вони гнучкі та дозволяють працювати з 
різними типами даних, що важливо в умовах зростаючого різноманіття та обсягів 
інформації. Володіють швидкодією у зберіганні та отриманні даних, спрощенням 
розробки за рахунок адаптивності до змін структури даних. 
2 Масштабованість. Добре підходять для горизонтального масштабування, 
що дозволяє легко розширювати інфраструктуру за рахунок додавання нових 
серверів. Вони здатні обробляти великі обсяги даних та запитів, гнучкі у роботі з 
розподіленими системами. 
3 Робота з неструктурованими даними. Дозволяють зберігати та 
обробляти неструктуровані та напівструктуровані дані, що є важливим у 
сучасному цифровому середовищі. Зручні у роботі з даними різної природи, існує 
можливість зберігання документів, графів, ключ-значення тощо. 
4 Ефективність у роботі з великими обсягами даних. Деякі типи 
нереляційних баз даних, такі як колоночні сховища, оптимізовані для роботи з 
великими обсягами даних та аналітикою. Мають високу швидкодію при обробці 
запитів, спрощену роботу з великими обсягами структурованих даних. 
5 Простота моделювання даних. Схема бази даних може бути змінена без 
24 
 
ЧДТУ.232223.026 ПЗ 
необхідності перебудови всього додатку, що дозволяє швидше реагувати на зміни 
в бізнес-логіці. Це надає зниження витрат на розробку та підтримку, а також 
більшу гнучкість у зміні структури даних. 
Недоліки: 
1 Відсутність стандартів. Відсутність загальноприйнятих стандартів у світі 
може ускладнити інтеграцію різних систем та розробку загальнодоступних 
рішень. Специфічність різних систем може створювати труднощі у роботі з 
різними нереляційними базами даних. 
2 Складніша модель запитів. Деякі нереляційні бази даних можуть 
виявитися складнішими для реалізації складних запитів, порівняно з 
традиційними реляційними базами даних. Ускладнення в реалізації деяких 
операцій та складніше написання складних запитів. 
3 Відсутність транзакцій. Багато нереляційні бази даних не підтримують 
транзакції, що може призводити до виникнення проблем із цілісністю даних в 
деяких сценаріях. Це тягне за собою ускладнення управління консистентністю та 
цілісністю даних. 
4 Обмежена функціональність SQL. Деякі нереляційні бази даних не 
підтримують стандартні SQL-запити, що може ускладнювати роботу для тих, хто 
звик до реляційних баз даних. Потребують додаткового навчання персоналу та 
перепроектування деяких частин системи. 
5 Брак консистентності. В режимі горизонтального масштабування та 
роботі з розподіленими системами може виникати брак консистентності даних. 
Також, можливість виникнення конфліктів та неоднорідності даних в 
розподілених системах. 
Нереляційні бази даних є потужним інструментом, але їх використання 
варто розглядати з огляду на конкретні вимоги та особливості проекту. 
1.2.6. Сучасні тенденції та розширення 
Сучасні нереляційні бази даних перебувають на передньому краї інновацій в 
області обробки даних. Нинішні тенденції та розширення визначають їхню 
еволюцію та адаптацію до сучасних вимог. Від розвитку мультимодальних систем 
25 
 
ЧДТУ.232223.026 ПЗ 
до інтеграції засобів штучного інтелекту та розподіленого аналізу даних у 
реальному часі, ці напрямки визначають новий рівень гнучкості, продуктивності 
та безпеки в світі інформаційних технологій. Ключові тенденції та розширення, 
що визначають сучасний ландшафт нереляційних баз даних [34]: 
1 Мультимодальність та комбіновані системи. Розвиток 
мультимодальних нереляційних баз даних, які об’єднують різні моделі даних 
(ключ-значення, графові, колоночні, тощо) в одній системі. Це забезпечить 
більшу гнучкість та можливість використання різних підходів залежно від 
конкретного сценарію. 
2 Системи забезпечені штучним інтелектом та машинним навчанням. 
Інтеграція засобів штучного інтелекту та машинного навчання для автоматизації 
аналізу даних та вибіркового отримання інформації. Це сприятиме розробці 
інтелектуальних систем, що можуть самостійно визначати та адаптуватися до змін 
у даних. 
3 Розподілені бази даних «в режимі реального часу». Використання 
розподілених систем для обробки даних у режимі реального часу, де актуальні 
дані доступні миттєво. Це забезпечить швидкий доступ до інформації та 
дозволить реагувати на події миттєво. 
4 Розвиток графових баз даних. Зростання популярності графових баз 
даних для вирішення завдань, пов’язаних з взаємозв’язками між об’єктами. Це 
надасть ефективну обробку та аналіз графових структур, що знадобляться у 
соціальних мережах, логістиці, та інших галузях. 
5 Збільшення кількості NoSQL типів. Поява нових типів нереляційних баз 
даних, спрямованих на конкретні завдання (часові ряди, географічні дані, 
георозподілені системи тощо). Це забезпечить спеціалізовані рішення для різних 
областей, що підвищать ефективність та точність обробки даних. 
6 Розширення систем обробки потокових даних. Розвиток систем, які 
можуть обробляти великі потоки даних в режимі реального часу. Це забезпечить 
ефективну обробку та аналіз великих обсягів потокових даних, таких як дані 
сенсорів IoT або дані великих мереж. 
26 
 
ЧДТУ.232223.026 ПЗ 
7 Безпека та захист даних. Зростання уваги до забезпечення безпеки даних 
в нереляційних базах даних, враховуючи виклики, пов’язані із збільшенням 
кількості кіберзагроз та вимог до конфіденційності. Подальша розробка 
механізмів шифрування, автентифікації та авторизації для забезпечення високого 
рівня захисту даних. 
Все це відображає стрімкий розвиток та адаптацію до нових викликів у світі 
обробки даних. Ці тенденції спрямовані на вдосконалення продуктивності, 
гнучкості та безпеки систем, що робить нереляційні бази даних більш 
універсальним та ефективним інструментом для сучасних завдань обробки та 
аналізу даних. 
1.2.7. Методи вдосконалення 
Розвиток та вдосконалення нереляційних баз даних активно відбувається 
для вирішення сучасних викликів обробки та зберігання даних [35]. Основними 
методами вдосконалення є: 
1 Гнучкість масштабування: 
 мета. Забезпечення ефективного горизонтального та вертикального 
масштабування, що дозволяє системам легко збільшувати потужність 
або розширювати кількість серверів; 
 рішення. Використання розподілених систем, розділення даних та 
паралельна обробка. 
2 Швидкодія: 
 мета. Оптимізація продуктивності та швидкодії обробки запитів; 
 рішення. Використання індексації, кешування, асинхронних операцій, 
оптимізація алгоритмів обробки даних. 
3 Можливості розподіленого зберігання: 
 мета. Забезпечення ефективного зберігання та розподілу даних на 
різних серверах або вузлах; 
 рішення. Реплікація даних, шарування, розподілені індекси. 
4 Підтримка схем на вимогу (Schema on Demand): 
27 
 
ЧДТУ.232223.026 ПЗ 
 мета. Можливість змінювати схему бази даних без значних перерв в 
роботі системи; 
 рішення. Використання гнучких форматів даних, таких як JSON або 
BSON. 
5 Оптимізація для роботи з багатьма типами даних: 
 мета. Забезпечення ефективного зберігання та обробки різноманітних 
типів даних; 
 рішення. Використання мультимодальних баз даних, підтримка 
різноманітних форматів (JSON, XML, графові структури тощо). 
6 Автоматизована оптимізація запитань: 
 мета. Розробка механізмів автоматичної оптимізації та розпізнавання 
ефективних шляхів виконання запитів; 
 рішення. Використання оптимізаторів запитань, кешування запитів, 
реактивна обробка. 
7 Підвищення безпеки даних: 
 мета. Захист від кіберзагроз та недозволених доступів до даних; 
 рішення. Використання шифрування даних, автентифікації та 
авторизації, аудиту безпеки. 
8 Інтеграція засобів штучного інтелекту (AI) та машинного навчання (ML): 
 мета. Використання алгоритмів штучного інтелекту та машинного 
навчання для покращення аналізу та вибіркового отримання 
інформації; 
 рішення. Інтеграція з AI/ML бібліотеками, використання підходів 
обробки природної мови. 
9 Підтримка ACID транзакцій (Atomicity, Consistency, Isolation, Durability): 
 мета. Забезпечення стандартних властивостей транзакцій для 
збереження консистентності даних; 
 рішення. Реалізація транзакцій в розподілених системах, використання 
журналів. 
10 Моніторинг та аналіз продуктивності: 
28 
 
ЧДТУ.232223.026 ПЗ 
 мета. Забезпечення засобів для моніторингу та аналізу продуктивності 
баз даних; 
 рішення. Використання систем моніторингу, реактивна оптимізація в 
залежності від навантаження. 
Ці методи вдосконалення спрямовані на створення ефективних, гнучких та 
безпечних нереляційних баз даних, які можуть відповідати високим вимогам 
сучасних додатків та обробки даних. 
1.3. Бази даних у вигляді текстових файлів 
Бази даних у вигляді текстових файлів представляють собою особливий 
підхід до зберігання та обробки даних. У цій концепції інформація зберігається у 
формі текстових файлів, де дані можуть бути структуровані за допомогою 
різноманітних форматів, таких як CSV, JSON, XML тощо. Такий підхід відкриває 
можливості для простоти зберігання, редагування та обміну даними, а також 
зручності в розробці та обробці інформації. Важливо знати їх переваги та 
обмеження, щоб враховувати сучасні тенденції та стратегії їх використання в 
різних областях технологічного ландшафту [36]. 
1.3.1. Історія виникнення 
Історія виникнення баз даних у вигляді текстових файлів має свої коріння в 
ранніх етапах розвитку обчислювальної техніки, коли зберігання та обробка 
даних велася на великих мейнфреймах і міні-комп’ютерах. На початковому етапі 
існування комп’ютерів, коли ресурси були обмеженими, а вимоги до обробки 
даних були невеликими, текстові файли стали простим та зручним засобом 
збереження інформації. Основними етапами розвитку є [37]: 
1 Початки ери карток або директорій (1950-1970). Коли мейнфрейми 
перетворювалися на платформи для обчислювання, інформацію часто зберігали 
на перфокартках або в структурованих директоріях текстових файлів. 
2 Системи управління файлами (1970-1980). З появою мейнфреймів і 
операційних систем, таких як IBM OS/360, з’явилися системи управління 
файлами, які дозволяли створювати, читати та оновлювати тексти в файловій 
29 
 
ЧДТУ.232223.026 ПЗ 
системі. 
3 Поширення комп’ютерів з особистими бажаннями (1980-1990). З 
поширенням персональних комп'ютерів, текстові файли залишалися популярними 
для зберігання даних через їх простоту та легкість редагування. 
4 Зростання використання CSV, JSON, XML та інших форматів (1990-
2000). З появою цих інших текстових форматів, зручних для імпорту та експорту 
даних між різними програмами, бази даних у вигляді текстових файлів знайшли 
новий струмінь використання. 
5 Використання текстових файлів в інтернет-технологіях (з 2000-х). В 
інтернет-технологіях, особливо на етапі розвитку web-сайтів, текстові файли 
стали популярними для зберігання конфігурацій, журналів та навіть даних 
користувачів. 
6 Відновлення зацікавленості (з 2010-х). Останнім часом спостерігається 
відновлення зацікавленості в текстових файлах через їхню легкість використання, 
читабельність для людей та потужність у сучасних сценаріях роботи з даними. 
Історія баз даних у вигляді текстових файлів є історією постійного пошуку 
оптимальних та зручних способів зберігання даних, і текстові файли, незважаючи 
на вікові зміни технологій, залишаються актуальними у багатьох сферах. 
1.3.2. Структура 
Бази даних у вигляді текстових файлів мають просту структуру, яка часто 
визначається форматом, в якому дані зберігаються [38]. Основні компоненти 
структури включають: 
1 Формат даних. Основним аспектом структури баз даних у вигляді 
текстових файлів є формат, у якому дані представлені у текстовому вигляді. 
2 Рядки та колонки. В текстових файлах дані організовані у вигляді рядків 
та колонок, аналогічно тому, як це відбувається у таблицях реляційних баз даних. 
Рядки відповідають окремим записам, а колонки – атрибутам чи полям. 
3 Роздільники. Для визначення місця, де закінчується одне поле чи 
колонка, а починається інше, використовуються роздільники. Найчастіше 
використовується кома, але можуть бути використані інші символи чи 
30 
 
ЧДТУ.232223.026 ПЗ 
послідовності. 
4 Заголовок. Деякі формати можуть включати заголовок, який містить 
імена полів або колонок. Це полегшує читання та розуміння структури даних. 
5 Вкладеність та ієрархія. Деякі формати дозволяють вкладати структури 
одну в одну. Це може бути об’єкт, вкладений у інший об’єкт, або елемент, 
вкладений у інший елемент. Це дозволяє представляти складні дані з ієрархічною 
структурою. 
6 Коментарі та метадані. Деякі формати текстових файлів дозволяють 
включати коментарі або метадані, які можуть містити додаткову інформацію про 
дані, таку як опис поля, автор чи дата створення файлу. 
7 Індексація. В деяких випадках, зокрема у великих текстових файлах, 
може бути застосована індексація для прискорення пошуку та доступу до певних 
даних. 
Структура баз даних у вигляді текстових файлів є відносно простою, але її 
ефективність залежить від відповідності формату вимогам конкретного завдання 
та зручності для подальшої обробки даних. 
1.3.3. Види 
Бази даних у вигляді текстових файлів можуть використовувати різні 
формати для представлення та зберігання даних. Найпоширенішими форматами є: 
1 CSV [39] (Comma-Separated Values). Є одним з найпоширеніших 
форматів для зберігання даних у текстових файлах. Кожен запис відокремлюється 
комою, а рядки розділяються символом нового рядка. Зазвичай, перший рядок 
може містити заголовок з іменами полів. 
2 JSON [40] (JavaScript Object Notation). Є легким та гнучким форматом, 
який використовується для обміну даними між сервером та клієнтом. Дані 
представляються у вигляді пар «ключ-значення» та можуть бути вкладеними. 
3 XML [41] (eXtensible Markup Language). Є універсальним форматом, 
який дозволяє представляти структуровані дані в текстовому вигляді. Дані 
визначаються тегами та атрибутами, а також можуть бути вкладені. 
4 YAML [42] (YAML Ain’t Markup Language). Є форматом, який 
31 
 
ЧДТУ.232223.026 ПЗ 
зосереджений на читабельності для людей та легкості використання. 
Використовує відступи для визначення структури даних. 
Вибір конкретного формату бази даних у вигляді текстових файлів залежить 
від конкретного завдання та потреб в обробці даних. Кожен з цих форматів має 
свої унікальні переваги та недоліки, і вибір повинен здійснюватися враховуючи 
конкретні вимоги проекту. 
1.3.4. Застосування в реальних сценаріях 
Бази даних у вигляді текстових файлів виявляють широке застосування в 
реальних сценаріях, забезпечуючи простоту та універсальність в зберіганні та 
обміні даними. Вони виявляються зручним та гнучким інструментом у різних 
галузях, надаючи просте та швидке рішення для роботи з обмеженими обсягами 
даних [43]: 
1 Конфігураційні файли. Використовуються для зберігання 
конфігураційних параметрів програм та систем. Це може включати налаштування 
серверів, параметри web-додатків чи конфігурації програмного забезпечення. 
2 Журнали логування. Застосовуються для зберігання журналів логування 
подій. Кожен запис у файлі може містити інформацію про час, подію, рівень 
важливості та інші параметри. 
3 Зберігання та обмін даними між системами. Використовуються для 
обміну даними між різними системами, особливо у випадках, коли необхідно 
швидко та ефективно передавати невеликі об’єми даних. 
4 Імпорт та експорт даних. Застосовуються для імпорту та експорту даних 
між програмами та платформами. CSV-файли, наприклад, використовуються для 
швидкого перенесення табличних даних між різними системами. 
5 Зберігання простих даних. Випадки, коли дуже складні системи баз 
даних виявляються зайвими, але є необхідність в зберіганні простих даних, 
можуть бути покриті базами даних у вигляді текстових файлів. Наприклад, список 
товарів або контактів. 
6 Конфігураційні файли у програмуванні. Використовуються для 
зберігання конфігурацій та налаштувань програм. Файли у форматі YAML чи 
32 
 
ЧДТУ.232223.026 ПЗ 
JSON дозволяють легко читати та змінювати параметри програми. 
7 Організація даних для аналізу. Застосовуються для попередньої обробки 
та організації даних перед подальшим аналізом. Наприклад, створення CSV-
файлів для зручного введення даних у статистичні інструменти. 
8 Ведення списків та реєстрів. У випадках, коли потрібно вести прості 
списки або реєстри, текстові файли можуть бути ефективним рішенням. 
Наприклад, список задач, адрес клієнтів чи інше подібне. 
Використання баз даних у вигляді текстових файлів у реальних сценаріях 
дозволяє ефективно зберігати та обробляти дані в різних галузях, забезпечуючи 
при цьому зручність в роботі та легкість обміну інформацією між системами. 
1.3.5. Переваги та недоліки 
Бази даних у вигляді текстових файлів представляють собою універсальний 
та простий спосіб зберігання даних. Однак, вони також володіють і недоліками, 
що може стати проблемою у великих та складних системах обробки даних [44]. 
Переваги: 
1 Простота та легкість. Однією з головних переваг є їхня простота 
використання та легкість читання та редагування. Текстові файли доступні для 
багатьох текстових редакторів і не вимагають спеціалізованого програмного 
забезпечення. 
2 Універсальність. Текстові файли є універсальним форматом, що може 
бути використаний в різних сценаріях. Вони підходять для зберігання 
конфігурацій, обміну даними між різними програмами та інших випадків 
використання. 
3 Легкість імпорту та експорту. Текстові файли, особливо у форматі CSV, 
легко імпортуються та експортуються. Це дозволяє легко обмінюватися даними 
між різними системами та програмами. 
4 Людиночитаемість. Текстові файли можуть бути читабельними для 
людей, що полегшує їхнє редагування та відладку. 
5 Гнучкість. Текстові файли дозволяють гнучко визначати структуру 
даних, особливо у форматах JSON та XML, які підтримують вкладені структури 
33 
 
ЧДТУ.232223.026 ПЗ 
та складні ієрархії. 
Недоліки: 
1 Відсутність цілісності даних. Текстові файли не завжди підтримують 
механізми для забезпечення цілісності даних, так як це роблять реляційні бази 
даних. Це може стати проблемою у великих та складних системах. 
2 Важкість роботи з великими обсягами даних. У випадку великих 
обсягів даних текстові файли можуть виявитися менш ефективними для операцій, 
таких як пошук, оновлення та видалення даних, порівняно з реляційними базами 
даних. 
3 Відсутність можливостей запитів. Текстові файли не надають 
можливостей для складних запитів та агрегаційних функцій, які можуть 
виконуватися в реляційних базах даних за допомогою SQL. 
4 Відсутність стандарту. У порівнянні з реляційними базами даних, для 
текстових файлів відсутня стандартизована мова запитів чи мова опису схеми 
даних. 
5 Обмеження у підтримці вкладених відносин. Деякі текстові формати, 
особливо CSV, можуть мати обмеження в підтримці вкладених відносин між 
даними, що ускладнює моделювання складних структур. 
Із розгляду переваг та недоліків баз даних у вигляді текстових файлів 
виходить, що їх ефективність залежить від конкретного використання та потреб 
проекту. 
1.3.6. Сучасні тенденції та розширення 
Сучасні тенденції та розширення у сфері текстових баз даних визначають 
нові шляхи розвитку цього формату для зберігання та обробки даних. Їх 
використання свідчать про гнучкість та сучасний підхід до управління 
інформацією. Автоматизація процесів та розширення універсальних бібліотек 
демонструють розвиток баз даних у вигляді текстових файлів як потужного 
інструменту для сучасних вимог у сфері обробки даних [45]. Серед них є: 
1 Використання JSON та YAML. Сучасні бази даних у вигляді текстових 
файлів все частіше використовують формати JSON та YAML для зберігання 
34 
 
ЧДТУ.232223.026 ПЗ 
даних. Ці формати дозволяють структурувати ієрархічні та складні дані, що 
робить їх особливо ефективними для сучасних додатків. 
2 Розширення універсальних бібліотек. Поява універсальних бібліотек, 
які спрощують роботу з різними форматами баз даних у вигляді текстових файлів, 
дозволяє розробникам легко зчитувати та записувати дані незалежно від 
вибраного формату, забезпечуючи гнучкість в роботі з даними. 
3 Застосування в мікросервісній архітектурі. Сучасні мікросервісні 
архітектури, де кожен сервіс може використовувати власну базу даних, зробили 
бази даних у вигляді текстових файлів привабливим вибором для зберігання 
конфігурацій, локальних даних та інших потреб окремих сервісів. 
4 Інтеграція з Git та іншими інструментами контролю версій. 
Використання текстових форматів для баз даних узгоджується із сучасними 
системами контролю версій, такими як Git. Це дозволяє ефективно відстежувати 
та управляти змінами в даних. 
5 Захист даних та шифрування. Сучасні бази даних у вигляді текстових 
файлів активно впроваджують засоби захисту даних та шифрування для 
забезпечення конфіденційності та цілісності інформації, що надає їм додатковий 
рівень безпеки. 
6 Інтеграція з іншими технологіями. Сучасні бази даних у вигляді 
текстових файлів легко інтегруються з іншими технологіями, такими як облікові 
записи користувачів у соціальних мережах чи системами аутентифікації на основі 
токенів, що сприяє створенню уніфікованих та зручних для взаємодії додатків. 
7 Автоматизація процесів роботи з даними. Поява інструментів для 
автоматизації процесів роботи з даними в базах даних у вигляді текстових файлів, 
таких як інструменти міграції даних, дозволяє розробникам ефективно керувати 
структурою та вмістом баз даних. 
8 Використання у інтернеті речей (IoT). Текстові файли стають зручним 
форматом для зберігання та обміну даними у великих обсягах в інтернеті речей, 
де пристрої можуть генерувати величезні потоки даних, які легко зберігаються та 
обробляються. 
35 
 
ЧДТУ.232223.026 ПЗ 
Сучасні тенденції та розширення баз даних у вигляді текстових файлів 
демонструють їхню адаптабельність та спроможність задовольняти вимоги 
сучасних інформаційних технологій, надаючи засоби для ефективної роботи з 
різноманітними структурами даних. 
1.3.7. Методи вдосконалення 
Сучасний вимір зберігання та обробки даних насичений новими вимогами 
до ефективності, безпеки та гнучкості. В цьому контексті текстові бази даних 
стають об’єктом удосконалення, враховуючи виклики та вимоги сучасного 
інформаційного середовища [46]. Ключовими перспективами розвитку є: 
1 Використання сучасних форматів: 
 мета. Забезпечення зручної структуризації та обробки складних даних 
в базах даних у вигляді текстових файлів; 
 рішення. Перехід до форматів JSON та YAML, які дозволяють 
ефективно представляти вкладені структури даних. 
2 Впровадження систем контролю версій: 
 мета. Забезпечення відстеження та управління змінами в базах даних у 
вигляді текстових файлів для підтримки командної розробки; 
 рішення. Використання системи контролю версій, такої як Git, для 
ефективного ведення історії та спільної роботи. 
3 Шифрування та захист даних: 
 мета. Забезпечення безпеки конфіденційної інформації в базах даних у 
вигляді текстових файлів; 
 рішення. Застосування алгоритмів шифрування та встановлення прав 
доступу для запобігання несанкціонованому доступу. 
4 Розробка інструментів автоматизації: 
 мета. Спрощення управління та розвитку баз даних у вигляді 
текстових файлів через автоматизацію рутинних завдань; 
 рішення. Створення скриптів або використання готових інструментів 
для автоматизованих операцій, таких як міграція даних. 
36 
 
ЧДТУ.232223.026 ПЗ 
5 Інтеграція з хмарними сервісами: 
 мета. Забезпечення високого рівня доступності та масштабованості баз 
даних у вигляді текстових файлів; 
 рішення. Використання хмарних сервісів для зберігання та обробки 
даних в розподіленому середовищі. 
6 Оптимізація запитань та операцій: 
 мета. Підвищення ефективності читання та запису даних у базах даних 
у вигляді текстових файлів; 
 рішення. Оптимізація SQL-запитів, використання швидких алгоритмів 
та впровадження кешування. 
7 Розширення функціоналу запитів: 
 мета. Посилення можливостей запитів до даних з баз даних у вигляді 
текстових файлів; 
 рішення. Впровадження додаткових параметрів у запити та розширення 
можливостей фільтрації. 
8 Моніторинг та логування: 
 мета. Виявлення аномалій та підвищення продуктивності баз даних у 
вигляді текстових файлів через засоби моніторингу; 
 рішення. Встановлення систем логування та моніторингу для аналізу та 
оптимізації роботи бази даних. 
9 Управління версіями схеми даних: 
 мета. Зміни в структурі баз даних у вигляді текстових файлів без 
втрати даних та цілісності; 
 рішення. Використання міграцій для внесення змін до схеми та 
управління версіями. 
У світі, що стрімко розвивається, сучасні вимоги до зберігання та обробки 
даних поставляють перед системами баз даних нові завдання. Текстові бази даних 
виявляються на передовій цього еволюційного процесу, зазнаючи вдосконалень 
для відповіді на виклики сучасного інформаційного ландшафту. 
37 
 
ЧДТУ.232223.026 ПЗ 
Висновки до розділу 
Опрацювавши різноманітні типи баз даних з урахуванням їхньої структури 
та різновидів, а також вивчивши їх застосування у реальних сценаріях, переваги 
та недоліки, а також оцінивши сучасні тенденції та напрямки розширення та 
вдосконалення, прийшов до наступного: 
1 Реляційні бази даних виступають як стандарт і ефективний засіб для 
зберігання та опрацювання структурованих даних великого обсягу. З цього 
випливає, що вони здатні впоратися з великою кількістю зв’язаних таблиць, 
надаючи стійку та надійну основу для багатьох застосувань. 
2 Нереляційні бази даних представляють інноваційний підхід до роботи з 
великими потоками неструктурованих даних. Їх використання особливо цінне в 
умовах великого об’єму даних та потреби в гнучкості сховища даних. Такі бази 
даних дозволяють ефективно взаємодіяти з навантаженням, яке зазвичай складно 
адаптувати до стандартних реляційних моделей. 
3 Бази даних у вигляді текстових файлів стають важливим компонентом для 
зберігання конфігураційних даних, журналів логування та обміну інформацією 
між різними системами. Їхнє використання особливо актуально у випадках, коли 
потрібно простий та доступний інструмент для роботи з обмеженими обсягами 
даних. 
Однак, при розгляді застосування нереляційних баз даних у вигляді 
самостійних систем для зберігання та опрацювання даних, виявляється, що цей 
підхід часто не використовується чи робить це зовсім опосередковано, 
використовуючи їх як компоненти більш складних систем. Таким чином, постає 
завдання вдосконалення методу застосування не реляційних баз даних, щоб 
визначити їх як ключовий інструмент у інших сценаріях використання. 
38 
 
ЧДТУ.232223.026 ПЗ 
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
Однією з сучасних тенденцій у галузі баз даних є зростаюча популярність 
не реляційних систем, які використовуються як компоненти більш складних 
інформаційних систем. Проте, при розгляді їх застосування як самостійних 
інструментів для зберігання та обробки даних, виявляється, що цей підхід часто 
використовується опосередковано. Тому постає завдання у детальному 
дослідженні застосування не реляційних баз даних і визначення шляхів їх 
вдосконалення для визнання їх ключовою складовою у інших сценаріях 
використання. 
2.1. Теоретичні дослідження 
Ці дослідження полягають у формалізації задачі структурної ідентифікації 
досліджуваного виду баз даних, формулюванні гіпотези їх створення та 
використання, додаткового аналізу. Він розподілений на проміжні етапи, що 
охоплюють весь цикл роботи з базами даних, включаючи їх створення та 
використання в проекті, його подальший супровід та підтримка, а отже аспекти 
імпорту/експорту даних для редагування та оновлення інформації, зміна web-
хостингу. 
Робочий процес має бути орієнтований на детальний порівняльний аналіз 
витрат часу, виміряного у людино-годинах, та в ключових критеріях ефективності 
для двох типів баз даних: бази даних у вигляді текстового файлу та реляційної 
бази даних. 
Сукупність ефективних взаємодій [47] визначається формулою: 
��
 �� =  (2.1) 
��
де 
E – ефективність, 
K – користь, 
Z – затрати. 
Стадії ефективності: 
39 
 
ЧДТУ.232223.026 ПЗ 
1 Збільшується, коли: 
 користь зростає, а затрати залишаються сталими; 
 користь залишається сталою, а затрати спадають; 
 користь зростає, а затрати спадають (ідеальний варіант). 
2 Зменшується, коли: 
 користь спадає, а затрати залишаються сталими; 
 користь залишається сталою, а затрати зростають; 
 користь спадає, а затрати зростають (недосконалий варіант). 
3 Стабільна, коли: 
 користь і затрати пропорційно зростають; 
 користь і затрати пропорційно спадають; 
 користь і затрати залишаються сталими. 
Ця формула використовується для оцінки та порівняння ефективності 
різних систем, процесів чи рішень. Вона вказує на те, наскільки успішно вкладені 
ресурси (затрати) призводять до досягнення певних цілей чи отримання користі. 
Ця формула стала важливим інструментом у різних сферах для оцінки аспектів 
діяльності та прийняття обґрунтованих рішень щодо використання ресурсів. 
2.1.1. Постановка задачі структурної ідентифікації 
Формалізація задачі структурної ідентифікації нової бази даних розроблена 
на основі сформованої методики [48]. 
Задача ідентифікації – процес визначення оператора F0 об’єкта, тобто 
побудови такого оператора моделі F, котрий був би максимально близьким до 
оператора об’єкта F0. 
Однак, оскільки вигляд оператора F0 практично ніколи не відомий, 
безпосередньо оцінити близькість згадуваних операторів неможливо. Тому, 
природньо оцінювати близькість операторів по їх реакціях на одинакові вхідні 
стани X, тобто по виходах об’єкта: 
  �� �� = ��0 ��, �� ��   (2.2) 
і моделі: 
40 
 
ЧДТУ.232223.026 ПЗ 
  ���� �� = �� ��  (2.3) 
Степінь близькості цих реакцій можна оцінити величиною квадрата модуля 
різниці векторів виходу: 
��
 �� �� =  �� �� − ���� ��  2 =   ��  �� − ���� 2
��  ��   (2.4) 
��
��=1
На практиці близькість об’єкта і моделі оцінюється за допомогою функції 
нев’язки q. Вона представляє собою скалярну функцію двох векторних аргументів 
– виходів об’єкта і моделі: 
 �� �� = �� �� �� , ���� ��   (2.5) 
Постановка задачі. Необхідно побудувати такий оператор моделі F, 
котрий би реагував на зміну вхідного стану Х аналогічно реакції об’єкта У, тобто: 
  ���� = �� ��  (2.6) 
 M
Таким чином, модельний оператор F повинен бути таким, щоб Y  ≈ Y, 
тобто виходи моделі і реального об’єкта при однакових вхідних станах повинні 
бути еквівалентними. Це можна отримати, якщо ввести єдину міру близькості на 
всьому інтервалі спостережень, а не тільки в кожній точці, як в (2.5). 
Такою мірою може бути функціонал нев’язки: 
1 Для неперервного об’єкта: 
��
  �� =  �� �� �� , �� ��  ℎ �� ���� (2.7) 
0
2 Для дискретного об’єкта: 
��
  �� �� =  �� ���� , �� ��  ℎ��  (2.8) 
��=1
Величина h(t) (або hi) називається ваговою функцією. ЇЇ фізичний зміст 
полягає в нормуванні апостеріорної інформації в різні моменти часу. Якщо об’єкт 
стохастичний і виміри вихідної величини зашумлені випадковими похибками із 
змінною дисперсією, то вагові множники визначають як: 
��
  ℎ =  (2.9) 
��2
Далі процес ідентифікації будується так, щоб мінімізувати отриману 
41 
 
ЧДТУ.232223.026 ПЗ 
нев’язку. Тобто вирішується задача мінімізації функціонала Q(F) по оператору F: 
  �� �� → min �� Ω ��∗ (2.10) 
Цей символічний запис означає, що функціонал Q(F) необхідно 
мінімізувати не довільною зміною F, а в деякому визначеному класі операторів 
(або функцій) Q. 
Таким чином, для ідентифікації в певному класі функцій Ω необхідно 
знайти оператор (функцію) F, котрий би мінімізував функціонал нев’язки Q(F) на 
цьому класі. 
Задача структурної ідентифікації полягає в визначенні структури оператора 
F, тобто в попередньому визначенні форми математичної моделі. 
2.1.2. Теорія та гіпотеза 
У розгляді архітектури web-проектів виникає проблема вибору 
оптимального механізму для зберігання інформації – використати повноцінну 
реляційну базу даних чи обмежитися простими текстовими файлами. 
Теорія. Рішення, щодо вибору підходу, залежить від ряду факторів, 
насамперед, обсягу проекту. У випадку об’ємних проектів, швидкість обробки 
масивів інформації відіграє важливу роль, включаючи різноманітні процедури 
виведення, редагування, додавання, оновлення, видалення, сортування, 
фільтрування тощо. Тому доцільно використовувати класичні бази даних, які 
відзначаються простотою запитів та швидкістю їх обробки. 
Для менших web-проектів, ми оперуємо невеликим об’ємом даних і час 
обробки запитів, так само як і різноманітні додаткові процедури, не є критичним 
фактором у порівнянні з класичними базами даних. 
Не заглиблюючись в типи та різновиди реляційних баз даних, а також 
систем управління базами даних, по суті – це ніщо інше, як сукупність таблиць (в 
іншому випадку – текстових файлів), об’єднаних в один фізичний файл бази 
даних. 
Гіпотеза. В реляційній базі даних інформація зберігається в табличному 
вигляді. Але і у текстовий файл інформацію можна записати теж у вигляді таблиці 
(псевдо), розділивши майбутні поля певними не часто використовуваним 
42 
 
ЧДТУ.232223.026 ПЗ 
символом, наприклад, вертикальною рискою, тільдою, знаком табуляції, іншими 
символами чи їх послідовністю. Головне, щоб цей символ (чи їх послідовність) в 
подальшому не використовувався в файлі як користувацький, бо це порушить 
саму концепцію формування таблиці (краще реалізувати ще й алгоритм 
відслідковування та програмне реагування на введення цього символу). Я ж 
використовую саме знак табуляції. Таким чином, ми можемо створити псевдо-
табличний текстовий файл, а саме базу даних у вигляді текстового файлу. 
2.1.3. Створення баз даних 
Першим і найголовнішим етапом є створення баз даних. 
Існує два основні способи створення текстової бази даних: 
1 Фізичне створення файлу з необхідною назвою. 
2 Динамічне створення файлу з потрібною назвою в процесі роботи 
програми. У разі виникнення необхідності створення нового файлу або зміни 
структури існуючого, програма може динамічно створити файл за допомогою 
відповідних операцій та вирішити завдання безпосередньо в процесі виконання. 
Для створення реляційної бази даних існує також два основні способи: 
1 Використання СУБД. 
2 Використання спеціального програмного коду. Однак це зазвичай не є 
практичним або ефективним способом роботи з базами даних, особливо якщо є 
потреба в ефективному зберіганні та оптимізованому доступі до великої кількості 
даних. Щоб створити базу даних та таблиці, доведеться вручну створювати 
структуру бази даних та опрацьовувати SQL-запити для визначення полів, 
індексів, ключів тощо. Також, доведеться реалізувати механізми для зберігання та 
обробки даних у програмному коді. 
Важливо враховувати, що використання системи управління базами даних 
надає багато переваг, таких як ефективність, безпека даних, можливість 
використання готових інструментів для роботи з даними та інші. Без системи 
управління базами даних доведеться вручну вирішувати багато проблем, які вже 
вирішені в готових рішеннях. 
43 
 
ЧДТУ.232223.026 ПЗ 
2.1.4. Робота з базами даних 
Проаналізувавши існуючий ринок на наявність програмного забезпечення 
для порівняння швидкості роботи стандартних операцій з базами даних у вигляді 
текстового файлу та реляційними базами даних виявилось, що в прямому 
контексті подібних програм не існує. Було прийнято рішення у проектуванні та 
розробці програмного продукту оцінки швидкодії баз даних. 
Бази даних мають бути наповнені різноманітною, але, водночас, і 
ідентичною інформацією, процес формування якої полягає у застосування методу 
«Random()» – генератора простих чисел, а також методів «Date()» – формування 
поточної дати і «Time()» – формування поточного часу. 
Мають бути також опрацьовані й інші стандартні операції з базами 
даних: 
1 Виведення з баз даних. 
2 Додавання запису до баз даних. 
3 Редагування запису у базах даних. 
4 Видалення запису з баз даних. 
Інформація має розподілятись за трьома варіантами кількості записів для 
забезпечення різноманітності та адаптації до різних обсягів даних. Кожен варіант 
має включати у себе 1 000, 5 000 та 10 000 записів відповідно. 
2.1.5. Імпорт/експорт даних до/з електронної таблиці Microsoft Excel 
Excel – дуже потужний програмний продукт корпорації Microsoft, що 
вирізняється своєю високою функціональністю та широким спектром 
можливостей для роботи з табличними даними. Завдяки зручному інтерфейсу та 
розгалуженому арсеналу інструментів і формул, цей програмний продукт 
вважається одним з найефективніших у галузі обробки та аналізу інформації у 
табличному форматі. 
Імпорт даних до електронної таблиці MS Excel стає ключовим елементом 
для полегшення рутинних завдань з редагування та додаванням інформації в базу 
даних. Використання Excel дозволяє не лише зручно працювати з великими 
44 
 
ЧДТУ.232223.026 ПЗ 
обсягами даних, але і швидко виконувати операції обробки, розрахунків та 
аналізу, завдяки вбудованим інструментам та формулам. 
Цей інтегрований підхід до роботи з Excel в контексті бази даних дозволяє 
забезпечити ефективність і точність обробки інформації, що робить його 
популярним інструментом серед розробників та контент менеджерів. 
Основні способи імпорту інформації з текстової бази даних до 
електронної таблиці MS Excel: 
1 Фізичне перенесення даних. 
2 Використання стандартних інструментів MS Excel для імпорту. 
Програмний інтерфейс Excel надає можливість імпортувати дані з різних 
форматів, включаючи текстові файли. 
3 Створення спеціального програмного алгоритму для динамічного 
формування файлу з усією структурою та його вивантаження в потрібному 
форматі. 
4 Використання сторонніх програм чи скриптів, написаних на інших мовах 
програмування. 
Процес імпорту інформації з реляційної бази даних до електронної 
таблиці MS Excel може бути реалізований за допомогою наступних засобів: 
1 Вбудовані інструменти СУБД. Багато систем управління базами даних, 
таких як MySQL, PostgreSQL, або Microsoft SQL Server, надають вбудовані 
інструменти для експорту даних. Ці інструменти можуть включати консольні 
утиліти або графічні інтерфейси для вибору таблиць, форматів та інших 
параметрів експорту. 
2 SQL-запити. Використання SQL-запитів для вибірки даних з бази даних і 
збереження їх у файлі певного формату. Наприклад, можна використовувати 
оператори «SELECT INTO OUTFILE» для експорту в CSV або інші формати. 
3 Сторонні інструменти. Існують сторонні програми та інструменти, які 
спеціалізуються на експорті даних з баз даних. Наприклад, DataGrip, DBeaver, або 
Navicat можуть надавати зручний інтерфейс для вибору таблиць, вказання 
форматів експорту та інших опцій. 
45 
 
ЧДТУ.232223.026 ПЗ 
4 Скрипти мов програмування. Використання скриптів на мовах 
програмування, таких як Python, для підключення до бази даних, вибірки даних та 
збереження їх у файлі з вказаним форматом. 
По завершенні редагування чи наповнення даними у електронній таблиці 
MS Excel, виникає необхідність експортувати змінені дані назад у бази даних. Цей 
процес стає важливим етапом, який забезпечує взаємодію між електронною 
таблицею та базами даних, дозволяючи зберігати та оновлювати актуальну 
інформацію в обох середовищах. 
Основні способи експорту інформації до текстової бази даних з 
електронної таблиці MS Excel: 
1 Фізичне перенесення даних. 
2 Використання стандартних інструментів MS Excel для експорту. 
Програмний інтерфейс Excel надає можливість експортувати дані у текстовий 
файл (з роздільниками табуляції). 
Процес експорту інформації до реляційної бази даних з електронної 
таблиці MS Excel може бути реалізований за допомогою наступних засобів: 
1 Вбудовані інструменти СУБД. Більшість систем управління базами 
даних, таких як MySQL, PostgreSQL, чи Microsoft SQL Server, надають власні 
інструменти для імпорту даних. Це може включати консольні утиліти або 
графічні інтерфейси для вибору файлу, форматів та інших параметрів імпорту. 
2 SQL-запити. Використання SQL-запитів для завантаження даних з 
текстового файлу, що може бути згенеровано з Excel. Наприклад, використання 
операторів «LOAD DATA INFILE» для імпорту з формату CSV чи інших. 
3 Сторонні інструменти. Існують сторонні програми та інструменти, які 
спеціалізуються на імпорті даних до баз даних. Наприклад, DataGrip, DBeaver, або 
Navicat можуть надавати зручний інтерфейс для завантаження даних з файлу 
Excel. 
4 Скрипти мов програмування. Використання скриптів на мовах 
програмування, таких як Python, для підключення до бази даних і завантаження 
даних зі згенеровано Excel-файлу. 
46 
 
ЧДТУ.232223.026 ПЗ 
2.1.6. Редагування інформація у хостинг-панелі web-сайту 
В контексті розробки невеликих web-проектів, таких як сайти-візитівки чи 
інтернет-каталоги, часто виникає необхідність у зручному та витратно-
ефективному управлінні інформацією. Особливо це стосується ситуацій, де дані в 
основному залишаються статичними та рідко оновлюються. У таких випадках 
використання текстового файлу в якості бази даних може виявитися оптимальним 
рішенням, оскільки це дозволяє уникнути впровадження панелі адміністрування 
сайту та зменшити витрати часу та бюджету проекту. 
Важливо зазначити, що в порівнянні з класичною реляційною базою даних, 
текстові файли дозволяють здійснювати зміни безпосередньо через стандартну 
хостинг-панель. Це робить процес управління інформацією більш зручним та 
економічно вигідним, оскільки не вимагає використання адмін-панелі та її 
впровадження. 
При роботі з класичною реляційною базою даних часто потрібно 
використовувати додаткові програми або скрипти, які інколи ще й можуть бути 
платними, що може призвести до збільшення бюджету проекту. Також зазначимо, 
що безпосереднє взаємодію з SQL-запитами у хостинг-панелі може бути 
складним завданням для кінцевого користувача. 
2.1.7. Зміна web-хостингу 
Перенесення web-ресурсу з одного web-хостингу на інший є завданням, яке 
може виникнути з різних причин. Однак, незважаючи на його технічну простоту 
на перший погляд, цей процес вимагає обачності та правильного підходу. Однією 
з ключових аспектів є перенесення файлів, які складають основну інфраструктуру 
web-сайту. 
Зазвичай, цей процес включає в себе завантаження всіх файлів з поточного 
сервера та їхнє вивантаження на новий. У контексті баз даних, вибір між 
реляційною базою даних та текстовим файлом може впливати на легкість та 
швидкість перенесення. З урахуванням спільності файлів, прийнято рішення 
зосередитися на операціях з файлами баз даних, які є критичним компонентом для 
47 
 
ЧДТУ.232223.026 ПЗ 
відновлення функціоналу веб-ресурсу. 
Під час цього перенесення слід враховувати не лише самі файли, але й 
параметри конфігурації бази даних, забезпечуючи правильність її функціонування 
на новому web-хостингу. Крім того, важливо взяти до уваги можливі відмінності в 
середовищі web-хостингу, щоб уникнути можливих проблем з сумісністю. 
У цілому, перенесення web-сайту між web-хостингами є стратегічно 
важливим завданням, яке потребує системності, акуратності та уважності до всіх 
деталей для забезпечення успішної міграції і надійності подальшої роботи web-
ресурсу на новому web-хостингу. 
2.2. Експериментальні дослідження 
Ці дослідження полягають у підтвердженні сформульованих теорії та 
гіпотези шляхом аналізу, що включає проміжні етапи, охоплюючи весь життєвий 
цикл роботи з базами даних. Він включає в себе створення баз даних, її 
використання в проекті, подальший супровід та підтримку. Окремий акцент 
робиться на аспектах імпорту та експорту даних для редагування та оновлення 
інформації, а також зміні web-хостингу. 
Робочий процес орієнтований на детальний порівняльний аналіз витрат 
часу, виміряного у людино-годинах, та ключових критеріях ефективності для двох 
типів баз даних: бази даних у вигляді текстового файлу та реляційної бази даних. 
Кожен етап та його підетапи повторюються тричі для обох типів баз даних, 
забезпечуючи точність та консистентність результатів. Отримані дані фіксуються 
та усереднюються, а далі вносяться в таблицю. 
Такий підхід до проведення експерименту дозволяє не лише отримати 
конкретні дані про витрати часу на кожному етапі, але і забезпечити високий 
рівень надійності результатів, що є важливим фактором при порівняльному 
аналізі. Також враховується можливість впливу інших факторів, які можуть 
вплинути на результати дослідження. 
2.2.1. Створення баз даних 
Першим і найголовнішим етапом є створення баз даних. 
48 
 
ЧДТУ.232223.026 ПЗ 
Для створення текстової бази даних використовувався перший із 
запропонованих способів, а саме фізичне створення файлу. 
Для створення текстового файлу необхідно лише дві прості дії: 
1 Створення самого файлу. 
2 Перейменування створеного файлу у робочу назву. 
Цей процес не використовує спеціалізованого програмного забезпечення, 
лише стандартний набір програмних компонентів операційної системи 
«Windows». 
Для створення реляційної бази даних використовувався перший із 
запропонованих способів, а саме використання СУБД. 
Процес створення реляційної бази даних складніший: 
1 Запускаємо допоміжне програмне забезпечення. Використовувався 
безкоштовний програмний продукт – «phpMyAdmin». 
2 Створюємо власне саму базу даних. Використовувалась безкоштовна 
реляційна база даних – «MariaDB». 
3 Створюємо у базі даних таблицю, даємо їй назву. 
4 Створюємо у таблиці 5 полів, даємо їм назву, назначаємо типи, довжину, 
задати інші параметри. 
5 Вносимо службову інформацю та зберігаємо, налаштовуємо права 
доступу. 
Результати експерименту відображені в таблиці 2.1. 
Таблиця 2.1 
Результати витраченого часу на створення баз даних 
Час (сек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова 3 3 3 3 
157 
Реляційна 165 160 155 160 
 
Різниця є очевидною. 
2.2.2. Робота з базами даних 
49 
 
ЧДТУ.232223.026 ПЗ 
Для роботи з базами даних був спроектований та розроблений спеціальний 
програмний продукт для порівняння швидкості роботи з текстовою та реляційною 
базами даних. 
Різниця в роботі з готовими базами даних обох типів, так само як і процес їх 
підключення до проекту є незначною. В обох випадках програмний код обробки 
даних реалізується схожими алгоритмами, що роблять ідентичні дії кожен для 
свого виду баз даних. 
Важливо відзначити, що цей програмний продукт дозволяє проводити 
об’єктивне порівняння, розкриваючи переваги та недоліки обох типів баз даних у 
контексті конкретного завдання чи проекту. Це сприяє кращому розумінню 
впливу вибору типу бази даних на продуктивність та ефективність програмного 
забезпечення. 
Робота з базами даних була розподілена за трьома варіантами кількості 
записів для забезпечення різноманітності та адаптації до різних обсягів даних. 
Кожен варіант включав у себе 1 000, 5 000 та 10 000 записів відповідно. 
Наповнення баз даних. Полягає у циклічному додаванні записів до 
досягнення необхідної загальної кількості записів у кожному варіанті. Це 
дозволило забезпечити консистентність та порівнянність даних, необхідних для 
об’єктивного аналізу роботи обох типів баз даних. 
Результати експерименту відображені в таблиці 2.2. 
Таблиця 2.2 
Результати витраченого часу на наповнення баз даних 
Час (мсек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова (1 000 записів) 5,15 4,82 4,94 4,97 
72,54 
Реляційна (1 000 записів) 81,85 72,95 77,74 77,51 
Текстова (5 000 записів) 24,45 26,53 23,67 24,88 
369,77 
Реляційна (5 000 записів) 396,18 374,47 413,31 394,65 
Текстова (10 000 записів) 50,41 45,78 45,68 47,29 
711,07 
Реляційна (10 000 записів) 745,62 737,68 791,79 758,36 
 
Виведення з баз даних. Полягає у відображення усієї доступної інформації, 
50 
 
ЧДТУ.232223.026 ПЗ 
що включає у собі кожна з баз даних. 
Результати експерименту відображені в таблиці 2.3. 
Таблиця 2.3 
Результати витраченого часу на виведення з баз даних 
Час (мсек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова (1 000 записів) 0,06 0,07 0,05 0,06 
1,14 
Реляційна (1 000 записів) 1,26 1,16 1,18 1,20 
Продовження таблиці 2.3 
Текстова (5 000 записів) 0,21 0,22 0,20 0,21 
2,92 
Реляційна (5 000 записів) 3,13 3,12 3,14 3,13 
Текстова (10 000 записів) 0,41 0,43 0,48 0,44 
14,35 
Реляційна (10 000 записів) 14,92 14,17 15,28 14,79 
 
Додавання запису до баз даних. Полягає у формуванні та додаванні 
інформації із визначеними полями та відповідним вмістом до баз даних. 
Результати експерименту відображені в таблиці 2.4. 
Таблиця 2.4 
Результати витраченого часу на додавання запису до баз даних 
Час (мсек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова (1 000 записів) 0,23 0,25 0,24 0,24 
1,56 
Реляційна (1 000 записів) 1,75 1,96 1,69 1,80 
Текстова (5 000 записів) 0,49 0,47 0,48 0,48 
4,78 
Реляційна (5 000 записів) 5,29 5,38 5,11 5,26 
Текстова (10 000 записів) 0,84 0,86 0,91 0,87 
9,59 
Реляційна (10 000 записів) 10,67 10,17 10,54 10,46 
 
Редагування запису у базах даних. Полягає у заміні існуючої інформації 
(за вказаним ідентифікатором) на користувацьку із визначеними полями та 
відповідним вмістом у базах даних. 
Результати експерименту відображені в таблиці 2.5. 
Таблиця 2.5 
Результати витраченого часу на редагування запису у базах даних 
51 
 
ЧДТУ.232223.026 ПЗ 
Час (мсек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова (1 000 записів) 0,33 0,35 0,31 0,33 
2,27 
Реляційна (1 000 записів) 2,42 2,64 2,74 2,6 
Текстова (5 000 записів) 1,61 1,62 1,75 1,66 
9,38 
Реляційна (5 000 записів) 11,15 11,01 10,96 11,04 
Текстова (10 000 записів) 1,25 1,23 1,27 1,25 
19,79 
Реляційна (10 000 записів) 20,91 21,32 20,89 21,04 
 
Видалення запису з баз даних. Полягає у знищенні існуючої інформації (за 
вказаним ідентифікатором) з баз даних. 
Результати експерименту відображені в таблиці 2.6. 
Таблиця 2.6 
Результати витраченого часу на видалення запису з баз даних 
Час (мсек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова (1 000 записів) 0,32 0,36 0,31 0,33 
0,40 
Реляційна (1 000 записів) 0,73 0,74 0,72 0,73 
Текстова (5 000 записів) 0,81 0,72 0,75 0,76 
1,80 
Реляційна (5 000 записів) 2,61 2,56 2,51 2,56 
Текстова (10 000 записів) 1,24 1,32 1,31 1,29 
3,47 
Реляційна (10 000 записів) 4,76 4,70 4,82 4,76 
 
На основі проведених експериментів можна зробити висновок, що різниця в 
часі стандартних операцій у текстовій та реляційній базах даних становить 
декілька мілісекунд і у контексті обробки даних такого обсягу, ця різниця фізично 
непомітна для користувача. Обидва типи баз даних продемонстрували приблизно 
однакову швидкодію при операціях з різним обсягом даних. 
Таким чином, у контексті розглядуваних операцій, ефективність 
використання текстових файлів як баз даних значно не відрізняється від 
реляційних баз даних. 
2.2.3. Імпорт/експорт даних до/з електронної таблиці Microsoft Excel 
Дана процедура спрямована на систематичне дослідження процесів обміну 
52 
 
ЧДТУ.232223.026 ПЗ 
даними між різними типами баз даних. Цей етап аналізу вивчає ефективність 
інтеграції інформації між електронними таблицями та базами даних, спрощуючи 
взаємодію між цими двома формами зберігання та обробки даних. 
Імпорт даних до MS Excel. У ході нашого дослідження використано два 
різні типи баз даних з аналогічною інформацією, що складається з полів різних 
типів та обсягом даних у 10 000 записів у кожній. 
Для імпорту інформації з текстової бази даних до електронної таблиці MS 
Excel використовувався перший із запропонованих способів, а саме фізичне 
перенесення даних. 
Щоб перенести інформацію з текстової бази даних до електронної 
таблиці MS Excel необхідно зробити наступні кроки: 
1 Відкриваємо текстовий файл з інформацією, яку ми будемо переносити у 
будь-якому текстовому редакторі. Відкриваємо програмне середовище MS Excel 
та створюємо у ньому новий лист. 
2 Виділяємо всю інформацію з файла-джерела, копіюємо її та вставляємо у 
порожній лист Excel. 
3 Зберігаємо Excel-файл та закриваємо обидва файли. 
Важливо зауважити, що для цього процесу не вимагалося використання 
спеціалізованого програмного забезпечення, лише вбудований в операційну 
систему «Windows» текстовий редактор «Блокнот». 
Для імпорту інформації з реляційної бази даних до електронної таблиці MS 
Excel використовувався перший із запропонованих способів, а саме використання 
вбудованих інструментів СУБД. 
Процес імпорту інформації з реляційної бази даних до електронної 
таблиці MS Excel значно складніший: 
1 Запускаємо допоміжне програмне забезпечення. Використовувався 
безкоштовний програмний продукт – «phpMyAdmin». 
2 Вибираємо формат та методи, налаштовуємо параметри. 
3 Експортуємо дані та зберігаємо файл експорту. 
4 Відкриваємо отриманий файл в програмному середовищі MS Excel. 
53 
 
ЧДТУ.232223.026 ПЗ 
Результати експерименту відображені в таблиці 2.7. 
Таблиця 2.7 
Результати витраченого часу на імпорт даних до MS Excel 
Час (сек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова 6 6 6 6 
64 
Реляційна 75 70 65 70 
Експорт даних з MS Excel. В ході цього дослідження маємо лист Excel-
таблиці з п’ятьма полями різних типів імпортованої інформації і 10 000 записами 
у кожному. 
Для експорту інформації до текстової бази даних з електронної таблиці MS 
Excel використовувався перший із запропонованих способів, а саме фізичне 
перенесення даних. 
Щоб перенести інформацію до текстової бази даних з електронної 
таблиці MS Excel необхідно зробити наступні кроки: 
1 Відкриваємо Excel-файл з інформацією, яку ми будемо переносити. 
Відкриваємо текстовий файл у будь-якому текстовому редакторі. 
2 Виділяємо всю інформацію на листі Excel, копіюємо її та вставляємо у 
текстовий файл. 
3 Зберігаємо текстовий файл та закриваємо обидва файли. 
Важливо зауважити, що для цього процесу не вимагалося використання 
спеціалізованого програмного забезпечення, лише вбудований в операційну 
систему «Windows» текстовий редактор «Блокнот». 
Для експорту інформації до реляційної бази даних з електронної таблиці MS 
Excel використовувався перший із запропонованих способів, а саме використання 
вбудованих інструментів СУБД. 
Процес експорту інформації до реляційної бази даних з електронної 
таблиці MS Excel значно складніший: 
1 Відкриваємо Excel-файл з інформацією та експортуємо дані у необхідний 
формат. 
54 
 
ЧДТУ.232223.026 ПЗ 
2 Запускаємо допоміжне програмне забезпечення. Використовувався 
безкоштовний програмний продукт – «phpMyAdmin». 
3 Вибираємо файл для імпорту, формат та методи, налаштовуємо додаткові 
параметри. 
4 Імпортуємо дані, зберігаємо результат та проводимо додаткові 
налаштування. 
Результати експерименту відображені в таблиці 2.8. 
Таблиця 2.8 
Результати витраченого часу на експорт даних з MS Excel 
Час (сек) 
Вид бази даних 1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова 4 4 4 4 
96 
Реляційна 105 100 95 100 
 
Різниця в трудомісткості та часоємності є суттєвими. 
2.2.4. Редагування інформація у хостинг-панелі web-сайту 
Концепція цього етапу полягає у використанні лише текстової бази даних. 
Реалізувати це у класичній базі даних майже не можливо. Тому великий «плюс» 
йде до текстової бази даних. 
Слід зазначити що, впровадження панелі адміністрування сайту може 
витратити інколи й до третини всього бюджету при розробці web-проекту. А це є 
немаловажливим фактором. 
Ще однією перевагою використання текстової бази даних є усунення 
додаткового ризику щодо безпеки. Відсутність панелі адміністрування сайту 
усуває можливість несанкціонованого доступу та «зламання» сайту з боку 
зловмисників, що є важливим фактором для забезпечення безпеки. 
Тому, використання текстових баз даних для управління інформацією на 
web-сайтах може бути ефективним та економічно вигідним рішенням, особливо в 
умовах невеликих проектів з обмеженим бюджетом та ресурсами. 
2.2.5. Зміна web-хостингу 
55 
 
ЧДТУ.232223.026 ПЗ 
Процес перенесення web-ресурсу з одного web-хостингу на інший полягає в 
скачуванні всіх файлів з одного сервера та завантаження їх на інший. Так як 
файли у нас одні і ті самі, і різняться лише наявністю бази даних чи текстового 
файлу, було прийнято рішення оперувати лише з файлами баз даних, так як 
додаткові рухи на результат експерименту не вплинуть. 
Для перенесення текстової бази даних з одного web-хостингу на інший 
необхідно зробити наступні прості кроки: 
1 Відкриваємо web-хостинг і у менеджері файлів вбираємо необхідний файл 
текстової бази даних. 
2 Вивантажуємо файл. 
3 Відкриваємо інший web-хостинг і у менеджері файлів вбираємо необхідну 
директорію для завантаження файлу текстової бази даних. 
4 Завантажуємо файл. 
Зміна web-хостингу для класичної бази даних виглядає дещо 
складніше: 
1 Відкриваємо web-хостинг і переходимо у розділ «Бази даних», вибираємо 
базу даних. 
2 Експортуємо дамп. 
3 У менеджері файлів web-хостингу вбираємо експортований дамп. 
4 Вивантажуємо дамп. 
5 Відкриваємо інший web-хостинг і у менеджері файлів вбираємо необхідну 
директорію для завантаження дампу. 
6 Завантажуємо дамп. 
7 Переходимо у web-хостингу в розділ «Бази даних». 
8 Імпортуємо дамп. 
9 Налаштовуємо права доступу до бази даних. 
Результати експерименту відображені в таблиці 2.9. 
Таблиця 2.9 
Результати витраченого часу на зміну web-хостингу 
Вид бази даних Час (сек) 
56 
 
ЧДТУ.232223.026 ПЗ 
1-ша 2-га 3-тя Середнє 
Різниця 
спроба спроба спроба значення 
Текстова 19 17 18 18 
112 
Реляційна 135 120 130 130 
 
Як бачимо, різниця також є, і це при умові, коли все правильно робиться з 
першого разу. Важливою деталлю є те, що вибір текстової бази даних може 
спростити процес перенесення, зменшуючи час і зберігаючи високу 
продуктивність. Це стає особливо важливим у випадках, коли ресурси або 
технічні навички користувача є обмеженими. 
57 
 
ЧДТУ.232223.026 ПЗ 
Висновки до розділу 
Ця очевидна різниця у виборі між класичними базами даних та текстовими 
файлами стає ще більш суттєвою, коли враховуються фінансові та кваліфікаційні 
аспекти розробки web-проекту. Нерідко програмне забезпечення для створення 
баз даних та самі бази можуть бути платними, що безпосередньо впливає на 
фінансові витрати проекту. 
Економія суттєвого шматка бюджету може бути досягнута завдяки вибору 
текстових файлів. Їх створення та обробка не вимагають використання 
додаткового програмного забезпечення або покупки ліцензій, що робить цей 
варіант привабливим для проектів із обмеженими фінансовими ресурсами. 
Крім того, важливо враховувати, що робота з класичними базами даних 
може вимагати більш високого рівня кваліфікації фахівців. У такому випадку, 
необхідність залучення спеціалізованих фахівців призводить до додаткових 
витрат на зарплату та навчання персоналу. За використання текстових файлів, які 
може опрацьовувати менш кваліфікований персонал, ці витрати можна 
мінімізувати. 
Отже, вибір між класичними базами даних та текстовими файлами 
визначається не лише потребами проекту, але і фінансовими можливостями та 
кваліфікацією команди розробників. 
Результати дослідження відображені в таблиці 2.10. 
Таблиця 2.10 
Критерії порівняння баз даних обох типів 
Критерії оцінювання Текстова БД Реляційна БД 
Простота створення  × 
Зручність робочого алгоритму   
Швидкодія   
Імпорт/експорт даних до/з MS Excel  × 
Легкість редагування у хостинг-панелі  × 
Легкість зміни web-хостингу  × 
 
В результаті дослідженні переслідувалась мета визначення ефективності 
58 
 
ЧДТУ.232223.026 ПЗ 
застосування не реляційних баз даних у невеликих web-ресурсах. Текстові бази 
даних виявились ефективнішими. Ми пересвідчились у цьому завдяки 
предметному аналізу способів реалізації баз даних, їх впровадження, оцінки часу, 
фінансових аспектів та трудомісткості роботи з ними. 
Текстові бази даних явно переважають за критеріями простоти створення, 
процедурі імпорту/експорту даних до/з MS Excel, легкості редагування у хостинг-
панелі та легкості зміни web-хостингу. При цьому, вони зрівнялись з реляційними 
базами даних за зручністю робочого алгоритму та швидкодією. 
59 
 
ЧДТУ.232223.026 ПЗ 
3 ПРОЕКТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ 
Проаналізувавши існуючий ринок на наявність програмного забезпечення 
для порівняння швидкості роботи стандартних операцій з базами даних у вигляді 
текстового файлу та реляційними базами даних виявилось, що в прямому 
контексті подібних програм не існує. Тому постає завдання у проектуванні 
програмного продукту оцінки швидкодії баз даних. 
3.1. Моделювання предметної області 
Побудова моделі предметної області полягає у виявленні абстракцій, 
існуючих у реальному світі, тобто тих основних концептуальних об’єктів, які 
зустрічаються в системі. 
3.1.1. Предметна область моделювання: модель, словник 
Модель предметної області розроблюваної системи оцінки швидкодії баз 
даних полягає в тому, що завдяки цій системі користувач, використовуючи два 
різних види баз даних, а саме базу даних у вигляді текстового файлу та реляційну 
базу даних, може перевірити швидкість обробки даних використовуючи 
стандартні операції з базами даних і отримати результати цієї роботи. 
Словник предметної області – часто згадувані поняття об’єктно-
орієнтованого аналізу і проектування. 
При моделюванні системи оцінки швидкодії баз даних використовуються 
наступні часто згадувані поняття: база даних, система управління базою даних, 
текстова база даних, реляційна база даних, стандартні операції з БД – наповнення 
БД, виведення з БД, додавання запису до БД, редагування запису в БД та 
видалення запису з БД. 
Формалізація моделі та її додаткових аспектів дозволили в повній мірі 
сформувати концептуальну модель об’єктів предметної області. 
3.1.2. Елементи моделювання предметної області 
Для моделювання предметної області задіяна підмножина мови UML 
представлена у таблиці 3.1. 
60 
 
ЧДТУ.232223.026 ПЗ 
Таблиця 3.1 
Елементи моделювання предметної області 
Графічний символ Назва елемента 
Дійова особа (актор) 
 
Варіант використання 
 
Коментар 
 
Пакет 
 
Клас 
 
Об’єкт 
 
Компонент 
 
Діяльність 
 
Стан 
 
Лінія життя, фокус управління 
 
Логічний з’єднувач, розгалужувач 
 
61 
 
ЧДТУ.232223.026 ПЗ 
Продовження таблиці 3.1 
 Паралельний з’єднувач, розгалужувач 
 Початковий і кінцевий стани 
 Відношення асоціації 
 Відношення коментаря 
 Відношення залежності 
 Виклик 
 Рекурсія 
 Повернення 
 
Представлені елементи моделювання предметної області в повній мірі 
дозволяють скласти різноманітні діаграми. 
3.1.3. Робоча область моделювання 
Розроблювана система оцінки швидкодії баз даних має бути web-ресурсом 
клієнт-серверної архітектури з використанням двох типів баз даних: 
1 База даних у вигляді текстового файлу. 
2 Реляційна база даних. 
На цьому web-ресурсі користувач може виконувати різноманітні 
операції, такі як: 
1 Робота зі стандартними операціями з базами даних: 
 наповнення баз даних в автоматичному режимі певною кількістю 
записів; 
 виведення усієї інформації з баз даних; 
 додавання запису до баз даних в автоматичному режимі; 
 редагування запису в базах даних, вказуючи ідентифікаційний номер 
запису та вносячи дані у поля вручну або автоматичному режимах; 
 видалення запису з баз даних, вказуючи ідентифікаційний номер 
62 
 
ЧДТУ.232223.026 ПЗ 
запису. 
2 Робота зі звітністю: 
 перегляд журналу звіту; 
 очищення журналу звіту; 
 збереження журналу звіту. 
Цей функціонал надає користувачу можливість зручно та ефективно 
взаємодіяти з системою для оцінки швидкодії баз даних. 
3.2. Формування та аналіз вимог 
Задача формування та аналізу вимог є ключовим етапом та полягає у 
процесі розумінні, чим повинна бути і що робить система та його подальше 
документування. Основною задачею є знаходження, обговорення і фіксування 
того, що дійсно вимагається від системи у зрозумілій для всіх формі. 
3.2.1. Формування вимог 
Ретельно сформульовані первинні вимоги відображають очікування 
замовника, визначаючи функціональні та нефункціональні характеристики 
системи. Детальні вимоги визначають специфічні деталі реалізації, враховуючи 
технічні аспекти та можливості розробників. 
Первинні вимоги (вимоги замовника): 
1 Функціональні вимоги: 
 забезпечення засобів для виконання стандартних операцій з базами 
даних; 
 надання можливостей для наповнення баз даних різною кількістю 
записів; 
 реалізація засобів для вимірювання часу виконання запитів; 
 забезпечення можливості введення даних як в автоматичному, так і в 
ручному режимах; 
 розробка інтуїтивно зрозумілого та ефективного інтерфейсу 
користувача для взаємодії з програмою. 
63 
 
ЧДТУ.232223.026 ПЗ 
2 Нефункціональні вимоги: 
 забезпечення високої продуктивності та швидкодії роботи системи, 
навіть при обробці великих обсягів даних; 
 гарантування безпеки даних у системі; 
 забезпечення сумісності системи з різними операційними системами та 
web-браузерами. 
Детальні вимоги (вимоги розробника): 
1 Функціональні вимоги: 
 створення інтерфейсу для візуалізації результатів; 
 розробка інструменту формування вхідних даних для наповнення та 
редагування баз даних; 
 створення засобів ведення журналу звіту щодо швидкодії баз даних; 
 реалізація механізму щодо очищення та збереження журналу звіту; 
 захист від «недосвідченого користувача»; 
 можливість розширення та модифікації програми в майбутньому; 
 розробка програми з використанням сучасних технологій та патернів 
програмування. 
2 Нефункціональні вимоги: 
 забезпечення високої якості коду та документації для полегшення 
подальшого розвитку та супроводу; 
 використання ефективних методів оптимізації для досягнення високої 
продуктивності; 
 гарантування відсутності помилок та стабільної роботи програми в 
різних умовах використання. 
Гармонійне виконання цих вимог сприятиме успішній розробці 
програмного забезпечення, що відповідатиме потребам та очікуванням усіх 
зацікавлених сторін. 
3.2.2. Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (використання) – графічне візуальне уявлення про 
64 
 
ЧДТУ.232223.026 ПЗ 
вимоги користувача та поведінку системи з погляду користувача, яке 
розглядається як головний засіб для первинного моделювання динаміки системи і 
використовується для з’ясування чітких вимог замовника до розроблюваної 
системи, фіксації цих вимог у формі, що дозволить проводити подальшу розробку 
системи. 
Діаграма прецедентів розроблена з використанням мови UML і 
представлена на рисунку 3.1. 
 
 
Рисунок 3.1 – Діаграма прецедентів 
65 
 
ЧДТУ.232223.026 ПЗ 
 
Опис діаграми прецедентів: 
1 Користувач – людина, яка взаємодіє з інтерфейсом користувача. 
2 Інтерфейс користувача – компоненти графічного дизайну та елементи 
керування введенням/виведенням. Взаємодіє з: 
 текстова СУБД – система управління ТБД, що взаємодіє власне з 
самою ТБД та забезпечує роботу стандартних операцій з БД; 
 реляційна СУБД – система управління РБД, що взаємодіє власне з 
самою РБД та забезпечує роботу стандартних операцій з БД; 
 генератор – інструмент формування вхідних даних, які 
використовують текстова та реляційна СУБД для наповнення та 
редагування БД. 
3 Стандартні операції з БД – наповнення БД, виведення з БД, додавання 
запису до БД, редагування запису в БД та видалення запису з БД. Взаємодіє з 
інспектором. 
4 Інспектор – інструмент звітування роботи з БД. Отримує результати та 
формує журнал звіту, з яким взаємодіє менеджер. 
5 Менеджер – інструмент виведення, очищення та збереження журналу 
звіту. З ним також взаємодіє інтерфейс користувача. 
Діаграма прецедентів та її опис в повній мірі формують функціональні 
вимоги до розроблюваної системи. 
3.2.3. Проектування логічної структури 
Проектування логічної структури – процес розробки деталізованої 
логічної моделі системи, представленої у вигляді класів та пакетів. Цей етап 
визначає, з яких компонентів складатиметься система та як вони взаємодіятимуть 
між собою. 
3.2.3.1. Діаграми класів 
Діаграма класів – графічна візуалізація об’єктів системи і статичних 
відношень між ними, що складається з іменованого опису сукупності (групи) 
66 
 
ЧДТУ.232223.026 ПЗ 
об’єктів із загальними властивостями (атрибутами), однаковою поведінкою 
(операціями) та типами відношень, способів доступу до даних і методів, зв’язками 
і семантикою. 
Діаграма класів розроблена з використанням мови UML і представлена на 
рисунку 3.2. 
 
 
Рисунок 3.2 – Діаграма класів 
 
67 
 
ЧДТУ.232223.026 ПЗ 
Опис діаграми класів: 
1 Інтерфейс користувача – об’єкт керування модулями системи: 
 атрибути: 
 txt – підключення до ТБД; 
 rel – підключення до РБД. 
 операції: 
 Fill() – підключення модуля наповнення БД; 
 Output() – підключення виведення з БД; 
 Add() – підключення модуля додавання до БД; 
 Edit() – підключення модуля редагування в БД; 
 Remove() – підключення модуля видалення в БД. 
2 Модуль наповнення БД – наповнення однаковою інформацією обох БД: 
 атрибути: 
 count – кількість записів в БД; 
 txtTimeStart – час початку операції наповнення ТБД; 
 txtTimeEnd – час кінця операції наповнення ТБД; 
 relTimeStart – час початку операції наповнення РБД; 
 relTimeEnd – час кінця операції наповнення РБД. 
 операції: 
 TxtFill() – процедура наповнення інформацією ТБД; 
 RelFill() – процедура наповнення інформацією РБД; 
 Generation() – процедура генерації даних. 
3 Модуль виведення з БД – виведення інформації з обох БД: 
 атрибути: 
 last – останній індекс запису в БД; 
 txtTimeStart – час початку операції виведення з ТБД; 
 txtTimeEnd – час кінця операції виведення з ТБД; 
 relTimeStart – час початку операції виведення з РБД; 
 relTimeEnd – час кінця операції виведення з РБД. 
68 
 
ЧДТУ.232223.026 ПЗ 
 операції: 
 TxtOutput() – процедура виведення інформації з ТБД; 
 RelOutput() – процедура виведення інформації з РБД; 
 Cycle() – процедура циклічної обробки даних. 
4 Модуль додавання до БД – додавання запису до обох БД: 
 атрибути: 
 last – останній індекс запису в БД; 
 txtTimeStart – час початку операції додавання запису до ТБД; 
 txtTimeEnd – час кінця операції додавання запису до ТБД; 
 relTimeStart – час початку операції додавання запису до РБД; 
 relTimeEnd – час кінця операції додавання запису до РБД. 
 операції: 
 TxtAdd() – процедура додавання запису до ТБД; 
 RelAdd() – процедура додавання запису до РБД; 
 Generation() – процедура генерації даних. 
5 Модуль редагування в БД – редагування запису в обох БД: 
 атрибути: 
 id – індекс запису в БД; 
 txtTimeStart – час початку операції редагування запису в ТБД; 
 txtTimeEnd – час кінця операції редагування запису в ТБД; 
 relTimeStart – час початку операції редагування запису в РБД; 
 relTimeEnd – час кінця операції редагування запису в РБД. 
 операції: 
 TxtEdit() – процедура редагування запису в ТБД; 
 RelEdit() – процедура редагування запису в РБД; 
 Check() – процедура перевірки існування запису в БД. 
6 Модуль видалення з БД – видалення запису з обох БД: 
 атрибути: 
 id – індекс запису в БД; 
69 
 
ЧДТУ.232223.026 ПЗ 
 txtTimeStart – час початку операції видалення запису з ТБД; 
 txtTimeEnd – час кінця операції видалення запису з ТБД; 
 relTimeStart – час початку операції видалення запису з РБД; 
 relTimeEnd – час кінця операції видалення запису з РБД. 
 операції: 
 TxtRemove() – процедура видалення запису з ТБД; 
 RelRemove() – процедура видалення запису з РБД; 
 Check() – процедура перевірки існування запису в БД. 
7 Модуль звітування – отримання результатів та подальше їх виведення, 
очищення чи збереження: 
 атрибути: 
 date – поточна дата операції; 
 time – поточний час операції; 
 operation – поточна операція; 
 count – кількість записів в БД у поточній операції; 
 txtTime – час виконання операції в ТБД; 
 relTime – час виконання операції в РБД. 
 операції: 
 Report() – процедура виведення журналу звіту; 
 Clear() – процедура очищення журналу звіту; 
 Save() – процедура збереження журналу звіту. 
3.2.3.2. Діаграми пакетів 
Діаграма пакетів – графічне представлення способу розбивки великої 
моделі на частини, групуючи класи, що мають деяку спільність і значною мірою 
спрощує розуміння та підтримку проектованої моделі. 
Діаграма пакетів розроблена з використанням мови UML і представлена на 
рисунку 3.3. 
 
70 
 
ЧДТУ.232223.026 ПЗ 
 
Рисунок 3.3 – Діаграма пакетів 
Опис діаграми пакетів: 
1 Інтерфейсна частина – взаємодіє зі стандартними операціями з БД і 
операціями із звітністю та поєднує інтерфейс користувача. 
2 Стандартні операції з БД – взаємодіє з операціями із звітністю та поєднує 
модулі: 
 наповнення БД; 
 виведення з БД; 
 додавання до БД; 
 редагування в БД; 
 видалення з БД. 
3 Операції із звітністю – взаємодіє з інтерфейсною частиною та поєднує 
модуль звітування. 
Діаграми класів, пакетів та їх опис в повній мірі формують логічну 
структуру розроблюваної системи. 
3.2.4. Архітектурне проектування 
Архітектурне проектування – процес розробки деталізованої фізичної 
моделі системи, представленої у вигляді сукупності програмних компонентів та 
процесу їх розгортання на апаратних засобах у певній системі. Цей етап визначає, 
з яких компонентів складатиметься система та як вони мають взаємодіяти між 
собою. 
3.2.4.1. Діаграма компонентів 
Діаграма компонентів – графічне відображення програмних складових 
шляхом опису процесу об’єктно-орієнтованої декомпозиції системи до рівня 
переліку підсистем, їх зв’язків та опису її внутрішньої логічної структури у 
71 
 
ЧДТУ.232223.026 ПЗ 
вигляді пакетів компонентів, залежності між ними та алгоритмами їх 
функціональної взаємодії. 
Діаграма компонентів розроблена з використанням мови UML і 
представлена на рисунку 3.4. 
 
Рисунок 3.4 – Діаграма компонентів 
 
Опис діаграми компонентів: 
1 Виконавчий файл проекту (index.php) – пов’язаний з усіма компонентами і 
підключає до себе: 
72 
 
ЧДТУ.232223.026 ПЗ 
 бази даних: 
 txt.db – файл ТБД; 
 rel.db – РБД. 
 бібліотеки: 
 script.js – бібліотека динамічних сценаріїв та функцій; 
 style.css – файл стилів візуального оформлення інтерфейсу. 
2 Модулі стандартних операцій з БД – пов’язані з виконавчим файлом 
проекту та модулем звітування і включають до себе: 
 fill.php – модуль наповнення БД; 
 output.php – модуль виведення з БД; 
 add.php – модуль додавання до БД; 
 edit.php – модуль редагування в БД; 
 remove.php – модуль видалення з БД. 
3 Модуль звітування (report.php) – пов’язаний з виконавчим файлом 
проекту і включає до себе: 
 report.txt – файл журналу звіту. 
3.2.4.2. Розгортання програмної системи на апаратних засобах 
Діаграма розгортання (розміщення) – графічна візуалізація фізичної 
структури програмної системи, що відображає відповідність конкретних 
програмних артефактів (виконуваних файлів) обчислювальним вузлам 
(виконуючим обробку), які показують розміщення програмних елементів у 
фізичній архітектурі системи і взаємодію між фізичними елементами. 
Діаграма розгортання розроблена з використанням мови UML і 
представлена на рисунку 3.5. 
 
73 
 
ЧДТУ.232223.026 ПЗ 
 
Рисунок 3.5 – Діаграма розгортання 
Опис діаграми розгортання. Розроблювана система представляє собою 
web-ресурс клієнт-серверної архітектури, компоненти якої працюють на стороні 
сервера. Процес розгортання системи на апаратних засобах складається з 
наступних етапів: 
1 Завантаження архіву проекту до файлової системи сервера через хостинг-
панель чи іншими засобами. 
2 Розпакування файлів у зазначену директорію вбудованими засобами 
хостинг-панелі. 
3 Імпорт дампу БД вбудованими засобами хостинг-панелі. 
Система готова до роботи і доступна з будь-якого сучасного пристрою 
довільної архітектури і операційної системи через будь-який сучасний web-
браузер по зазначеній інтернет-адресі. 
Діаграми компонентів, розгортання (розміщення) та їх опис в повній мірі 
формують архітектуру розроблюваної системи. 
3.2.5. Моделювання поведінки системи 
Моделювання поведінки системи – процес розробки деталізованого опису 
алгоритму роботи системи, що визначається множиною об’єктів, які обмінюються 
повідомленнями і задається діяльністю, послідовністю, комунікацією 
(кооперацією) та скінченними автоматами (станами). 
3.2.5.1. Діаграма діяльності 
Діаграма діяльності – графічна візуалізація узагальненого уявлення 
74 
 
ЧДТУ.232223.026 ПЗ 
функціонального алгоритму, що відображає аналізований варіант використання та 
дозволяє докладно ілюструвати його сценарії на практиці реалізації програмної 
системи. 
Діаграма діяльності розроблена з використанням мови UML і представлена 
на рисунку 3.6. 
 
Рисунок 3.6 – Діаграма діяльності 
75 
 
ЧДТУ.232223.026 ПЗ 
 
Опис діаграми діяльності: 
1 Робота із стандартними операціями з БД. Працювати можливо лише при 
наповнених БД інформацією. Тому спочатку йде перевірка на наповненість БД: 
 ні – доступно: 
 наповнення БД – наповнення однаковою інформацією обох БД. 
 так – доступно: 
 виведення з БД – виведення інформації з обох БД; 
 додавання до БД – додавання запису до обох БД; 
 перевірка на існування запису в БД: 
 так – доступно: 
 редагування у БД – редагування запису в обох БД; 
 видалення з БД – видалення запису з обох БД. 
 ні – нічого не доступно. 
 після цього відбувається виведення звіту, запис до журналу звіту та 
повернення на початок. 
2 Робота зі звітністю. Працювати можливо лише за наявністю журналу 
звіту. Тому спочатку йде перевірка на наявність журналу звіту: 
 ні – повернення на початок або вихід. 
 так – доступно: 
 очищення журналу звіту – очищення усієї звітності з файлу; 
 збереження журналу звіту – збереження усієї звітності до 
зовнішнього файлу. 
 після цього відбувається повернення на початок або вихід. 
3 Є можливість одразу закрити програму. 
3.2.5.2. Діаграма послідовності 
76 
 
ЧДТУ.232223.026 ПЗ 
Діаграма послідовності – графічна візуалізація моделювання поведінки у 
формі опису протоколу сеансу обміну повідомленнями між взаємодіючими 
екземплярами класифікаторів під час виконання одного з можливих сценаріїв. 
Діаграма послідовності розроблена з використанням мови UML і 
представлена на рисунку 3.7. 
 
77 
 
ЧДТУ.232223.026 ПЗ 
Рисунок 3.7 – Діаграма послідовності 
 
Опис діаграми послідовності: 
1 Інтерфейс користувача надсилає запит «Наповнити БД» до Модуля 
наповнення БД, який ініціює наповнення БД. 
2 Модуль наповнення БД надсилає запит «Звітувати про наповнення БД» до 
Модуля звітування, який робить запис до журналу звіту про наповнення БД. 
3 Модуль звітування надсилає «Звіт про наповнення БД» Інтерфейсу 
користувача, який його виводить. 
4 Інтерфейс користувача надсилає запит «Вивести з БД» до Модуля 
виведення з БД, який ініціює виведення з БД. 
5 Модуль виведення з БД надсилає запит «Звітувати про виведення з БД» до 
Модуля звітування, який робить запис до журналу звіту про виведення з БД. 
6 Модуль звітування надсилає «Звіт про виведення з БД» Інтерфейсу 
користувача, який його виводить. 
7 Якщо БД не наповнені Модуль виведення з БД ігнорує запит. 
8 Інтерфейс користувача надсилає запит «Додати до БД» до Модуля 
додавання до БД, який ініціює додавання до БД. 
9 Модуль додавання до БД надсилає запит «Звітувати про додавання до 
БД» до Модуля звітування, який робить запис до журналу звіту про додавання до 
БД. 
10 Модуль звітування надсилає «Звіт про додавання до БД» Інтерфейсу 
користувача, який його виводить. 
11 Якщо БД не наповнені Модуль додавання до БД ігнорує запит. 
12 Інтерфейс користувача надсилає запит «Редагувати в БД» до Модуля 
редагування в БД, який ініціює редагування в БД. 
13 Модуль редагування в БД надсилає запит «Звітувати про редагування в 
БД» до Модуля звітування, який робить запис до журналу звіту про редагування в 
БД. 
14 Модуль звітування надсилає «Звіт про редагування в БД» Інтерфейсу 
78 
 
ЧДТУ.232223.026 ПЗ 
користувача, який його виводить. 
15 Якщо БД не наповнені Модуль редагування в БД ігнорує запит. 
16 Якщо Запис не існує в БД Модуль редагування в БД ігнорує запит. 
17 Інтерфейс користувача надсилає запит «Видалити з БД» до Модуля 
видалення з БД, який ініціює видалення з БД. 
18 Модуль видалення з БД надсилає запит «Звітувати про видалення з БД» 
до Модуля звітування, який робить запис до журналу звіту про видалення з БД. 
19 Модуль звітування надсилає «Звіт про видалення з БД» Інтерфейсу 
користувача, який його виводить. 
20 Якщо БД не наповнені Модуль видалення з БД ігнорує запит. 
21 Якщо Запис не існує в БД Модуль видалення з БД ігнорує запит. 
22 Інтерфейс користувача надсилає запит «Очистити журнал звіту» до 
Модуля звітування, який ініціює очищення журналу звіту. 
23 Якщо Журнал звіту порожній Модуль звітування ігнорує запит. 
24 Інтерфейс користувача надсилає запит «Зберегти журнал звіту» до 
Модуля звітування, який ініціює збереження журналу звіту. 
25 Якщо Журнал звіту порожній Модуль звітування ігнорує запит. 
3.2.5.3. Діаграма комунікації 
Діаграма комунікації (кооперації) – графічне представлення опису 
поведінки як взаємодії, тобто як протокол обміну повідомлень між 
функціональними об’єктами, де один і той же об’єкт може брати участь у різних 
взаємодіях, граючи в них різні ролі. Таким чином, взаємодія завжди відбувається 
в певному контексті, який визначається множиною учасників у взаємодії об’єктів 
і зв’язків. 
Діаграма комунікації розроблена з використанням мови UML і представлена 
на рисунку 3.8. 
 
79 
 
ЧДТУ.232223.026 ПЗ 
 
Рисунок 3.8 – Діаграма комунікації 
Опис діаграми комунікації: 
1 Інтерфейс користувача надсилає запит «Наповнити БД» до Модуля 
наповнення БД, який ініціює наповнення БД. 
2 Модуль наповнення БД надсилає запит «Звітувати про наповнення БД» до 
Модуля звітування, який робить запис до журналу звіту про наповнення БД та 
виводить його. 
3 Інтерфейс користувача надсилає запит «Вивести з БД» до Модуля 
виведення з БД, який ініціює виведення з БД, якщо вони наповнені. 
4 Модуль виведення з БД надсилає запит «Звітувати про виведення з БД» до 
Модуля звітування, який робить запис до журналу звіту про виведення з БД та 
виводить його. 
5 Інтерфейс користувача надсилає запит «Додати до БД» до Модуля 
додавання до БД, який ініціює додавання до БД, якщо вони наповнені. 
6 Модуль додавання до БД надсилає запит «Звітувати про додавання до 
БД» до Модуля звітування, який робить запис до журналу звіту про додавання до 
БД та виводить його. 
7 Інтерфейс користувача надсилає запит «Редагувати в БД» до Модуля 
редагування в БД, який ініціює редагування в БД, якщо вони наповнені і запис 
існує. 
8 Модуль редагування в БД надсилає запит «Звітувати про редагування в 
БД» до Модуля звітування, який робить запис до журналу звіту про редагування в 
80 
 
ЧДТУ.232223.026 ПЗ 
БД та виводить його. 
9 Інтерфейс користувача надсилає запит «Видалити з БД» до Модуля 
видалення з БД, який ініціює видалення з БД, якщо вони наповнені і запис існує. 
10 Модуль видалення з БД надсилає запит «Звітувати про видалення з БД» 
до Модуля звітування, який робить запис до журналу звіту про видалення з БД та 
виводить його. 
11 Інтерфейс користувача надсилає запит «Очистити журнал звіту» до 
Модуля звітування, який ініціює очищення журналу звіту, якщо він не є 
порожнім. 
12 Інтерфейс користувача надсилає запит «Зберегти журнал звіту» до 
Модуля звітування, який ініціює збереження журналу звіту, якщо він не є 
порожнім. 
3.2.5.4. Діаграма скінченного автомату 
Діаграма скінченного автомату (станів) – графічне відображення 
поведінки системи, яка визначає послідовність станів в ході існування об’єкту, а 
саме визначає для кожного стану об’єкту – конкретну дію, яка виконується 
об’єктом при отриманні ним сигналу про подію. Один і той самий об’єкт системи 
може виконувати різні дії у відповідь на одну і ту ж подію в залежності від стану 
об’єкту. 
Діаграма скінченного автомату інтерфейсу користувача розроблена з 
використанням мови UML і представлена на рисунку 3.9. 
 
 
Рисунок 3.9 – Діаграма скінченного автомату інтерфейсу користувача 
 
Опис діаграми скінченного автомату інтерфейсу користувача. 
81 
 
ЧДТУ.232223.026 ПЗ 
Інтерфейсу користувача має наступні стани: 
1 Наповнення БД. 
2 Виведення з БД. 
3 Додавання до БД. 
4 Редагування у БД. 
5 Видалення з БД. 
6 Очищення журналу звіту. 
7 Збереження журналу звіту. 
Діаграма скінченного автомату наповнення БД розроблена з використанням 
мови UML і представлена на рисунку 3.10. 
 
Рисунок 3.10 – Діаграма скінченного автомату наповнення БД 
 
Опис діаграми скінченного автомату наповнення БД. Модуль 
Наповнення БД має наступні стани: 
1 БД наповнена – вихід. 
2 БД не наповнена – ініціалізується процедура генерації даних і наповнення 
БД. 
Діаграма скінченного автомату виведення з БД розроблена з використанням 
мови UML і представлена на рисунку 3.11. 
 
 
82 
 
ЧДТУ.232223.026 ПЗ 
Рисунок 3.11 – Діаграма скінченного автомату виведення з БД 
 
Опис діаграми скінченного автомату виведення з БД. Модуль Виведення 
з БД має наступні стани: 
1 БД наповнена – ініціалізується процедура циклічної обробки даних і 
виведення з БД. 
2 БД не наповнена – вихід. 
Діаграма скінченного автомату додавання до БД розроблена з 
використанням мови UML і представлена на рисунку 3.12. 
 
 
Рисунок 3.12 – Діаграма скінченного автомату додавання до БД 
 
Опис діаграми скінченного автомату додавання до БД. Модуль 
Додавання до БД має наступні стани: 
1 БД наповнена – ініціалізується процедура генерації даних і додавання до 
БД. 
2 БД не наповнена – вихід. 
Діаграма скінченного автомату редагування у БД розроблена з 
використанням мови UML і представлена на рисунку 3.13. 
 
 
83 
 
ЧДТУ.232223.026 ПЗ 
Рисунок 3.13 – Діаграма скінченного автомату редагування у БД 
 
Опис діаграми скінченного автомату редагування у БД. Модуль 
Редагування у БД має наступні стани: 
1 БД наповнена: 
 запис існує в БД – ініціалізується процедура редагування в БД; 
 запис не існує в БД – вихід. 
2 БД не наповнена – вихід. 
Діаграма скінченного автомату видалення з БД розроблена з використанням 
мови UML і представлена на рисунку 3.14. 
 
Рисунок 3.14 – Діаграма скінченного автомату видалення з БД 
 
Опис діаграми скінченного автомату видалення з БД. Модуль 
Видалення з БД має наступні стани: 
1 БД наповнена: 
 запис існує в БД – ініціалізується процедура видалення з БД; 
 запис не існує в БД – вихід. 
2 БД не наповнена – вихід. 
Діаграма скінченного автомату звітування розроблена з використанням 
мови UML і представлена на рисунку 3.15. 
 
84 
 
ЧДТУ.232223.026 ПЗ 
 
Рисунок 3.15 – Діаграма скінченного автомату звітування 
 
Опис діаграми скінченного автомату звітування. Модуль Звітування має 
наступні стани: 
1 Виведення звіту (виклик після стандартних операцій з БД) – ініціалізація 
процедури запису до журналу звіту. 
2 Наявність журналу звіту (виклик з інтерфейсу користувача): 
 так – доступно: 
 очищення журналу звіту – ініціалізація процедури очищення усієї 
звітності із файлу; 
 збереження журналу звіту – ініціалізація процедури збереження 
усієї звітності до зовнішнього файлу. 
 ні – вихід. 
Діаграми діяльності, послідовності, комунікації (кооперації), скінченного 
автомату (станів) та їх опис в повній мірі формують поведінку розроблюваної 
системи. 
85 
 
ЧДТУ.232223.026 ПЗ 
Висновки до розділу 
На даному етапі проектування програмного забезпечення для порівняння 
швидкості роботи з різними типами баз даних був проведений ряд комплексних 
заходів та аналіз. 
Починаючи з моделювання предметної області, де визначався загальний 
функціонал майбутнього продукту, і закінчуючи чітким формулюванням 
первинних та детальних вимог, проектування виявилося ключовим для успішної 
реалізації завдань. 
Логічне, архітектурне та поведінкове проектування, висвітлене 
різносторонніми діаграмами та відповідними описами до них, дозволило не лише 
чітко структурувати програмний продукт, але і визначити оптимальні методи та 
підходи до його розробки. 
Чітко визначені вимоги виходячи з предметної області гарантують, що 
функціональні та нефункціональні аспекти системи будуть впроваджені і 
відповідатимуть усім вимогам при розробці програмного продукту оцінки 
швидкодії баз даних. 
86 
 
ЧДТУ.232223.026 ПЗ 
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО КОМПЛЕКСУ 
На даному етапі у життєвому циклі проекту, концепції та ідеї, сформовані 
на етапі проектування, набувають конкретної реалізації. Процес розробки 
реалізується в створенні програмного продукту оцінки швидкодії баз даних, 
враховуючи всі визначені раніше вимоги та рішення, а тестування дозволить 
перевірити ефективність та надійність реалізованого програмного продукту. 
4.1. Розробка програмного комплексу 
Розробка програмного забезпечення – складний та важливий етап у 
життєвому циклі створення інформаційних систем. Вибір засобів реалізації, 
створення бази даних, розробка інтерфейсу користувача та програмних 
компонентів є критичними аспектами цього процесу, які визначають ефективність 
та якість кінцевого продукту. 
4.1.1. Обґрунтування вибору засобів реалізації 
Вибір конкретних інструментів, мов програмування та технологій 
визначається не лише їхньою потужністю та можливостями, але й відповідністю 
конкретним вимогам проекту та сприяє досягненню поставлених цілей ефективно 
та з максимальним комфортом для розробників. 
Розроблена система є web-орієнтованою та має клієнт-серверну архітектуру, 
для створення якої використовувались наступні мови програмування та 
технології: 
1 Серверна частина (Back-end): 
 серверна мова програмування PHP. Відома своєю універсальністю та 
застосуванням у web-розробці, що робить її ідеальним вибором для 
реалізації серверної частини; 
 структурована мова запитів SQL. Відома своєю розповсюдженістю у 
web-розробці, що сприяє ефективній роботі з базою даних та 
забезпечує потрібний рівень безпеки. 
2 Клієнтська частина (Front-end): 
87 
 
ЧДТУ.232223.026 ПЗ 
 мова гіпер-текстової розмітки HTML5. Основна складова для верстки 
сучасних web-сайтів; 
 каскадна таблиця стилів CSS3. Сучасний стандарт для розробки 
адаптивних та естетичних дизайнів; 
 мова програмування динамічних сценаріїв JavaScript. Дозволяє 
створювати динамічні елементи та вражаючі ефекти на стороні клієнта, 
що підвищує користувацький досвід. Також є інструментом для 
створення різних користувацьких функцій і виступає обробником 
різного роду подій. 
Цей стек технологій обраний з метою забезпечення ефективної, надійної та 
сучасної реалізації web-системи, а також для спрощення процесу розробки та її 
підтримки. 
4.1.2. Опис структурної (функціональної) схеми 
Структурна схема – графічне відображення основних структурних 
компонентів системи та взаємозв’язків між ними. 
Структурна схема програмного продукти оцінки швидкодії баз даних 
представлена на рисунку 4.1. 
 
 
Рисунок 4.1 – Структурна схема 
 
Опис структурної схеми. Система оцінки швидкодії БД складається з 
основних підсистем: 
1 Підсистема стандартних операцій з БД. 
2 Підсистема звітування. 
88 
 
ЧДТУ.232223.026 ПЗ 
Усі підсистеми тісно взаємодіють одна з одною. 
Функціональна схема – графічне відображення схеми взаємодії 
компонентів системи з описом інформаційних потоків, складу даних у потоках і 
зазначенням використовуваних файлів і пристроїв зберігання та відображення 
даних. 
Функціональна схема програмного продукти оцінки швидкодії баз даних 
представлена на рисунку 4.2. 
 
 
Рисунок 4.2 – Функціональна схема 
 
Опис функціональної схеми. Система оцінки швидкодії БД – включає: 
89 
 
ЧДТУ.232223.026 ПЗ 
інтерфейсну частину і складається з основних підсистем: 
1 Підсистема стандартних операцій з БД – включає: 
 наповнення БД – наповнення однаковою інформацією обох БД; 
 виведення з БД – виведення інформації з обох БД; 
 додавання до БД – додавання запису до обох БД; 
 редагування в БД – редагування запису в обох БД; 
 видалення з БД – видалення запису з обох БД. 
2 Усі елементи підсистеми пов’язані та працюють зі зберіганням даних в 
текстовій БД та зберіганням даних в реляційній БД. 
3 Підсистема звітування, що включає в себе: 
 виведення звіту – виведення результату роботи зі стандартними 
операціями з БД; 
 запис до журналу звіту – запис результату роботи зі стандартними 
операціями з БД до файлу; 
 очищення журналу звіту – очищення усієї звітності з файлу; 
 збереження журналу звіту – збереження усієї звітності до зовнішнього 
файлу. 
Операції підсистеми з журналом звіту пов’язані та працюють зі зберіганням 
інформації у файлі звіту. 
Представлені схеми та їх опис в повній мірі формують структуру та 
функціонал системи. 
4.1.3. Опис логічної схеми 
Логічна схема – графічне відображення послідовності дій, що відбуваються 
у системі, алгоритми її функціонування, що призводить до того чи іншого 
результату при роботі з системою. 
Логічна схема програмного продукти оцінки швидкодії баз даних 
представлена на рисунку 4.3. 
90 
 
ЧДТУ.232223.026 ПЗ 
 
Рисунок 4.3 – Логічна схема 
 
Опис логічної схеми. З інтерфейсу користувача доступні наступні 
операції: 
1 Робота із стандартними операціями з БД. Працювати можливо лише при 
наповнених БД інформацією. Тому спочатку йде перевірка на наповненість БД: 
 ні – доступно: 
 наповнення БД – наповнення однаковою інформацією обох БД. 
 так – доступно: 
 виведення з БД – виведення інформації з обох БД; 
 додавання до БД – додавання запису до обох БД; 
 перевірка на існування запису в БД: 
 так – доступно: 
91 
 
ЧДТУ.232223.026 ПЗ 
 редагування у БД – редагування запису в обох БД; 
 видалення з БД – видалення запису з обох БД. 
 ні – нічого не доступно. 
 після цього відбувається виведення звіту, запис до журналу звіту та 
повернення на початок. 
2 Робота зі звітністю. Працювати можливо лише за наявністю журналу 
звіту. Тому спочатку йде перевірка на наявність журналу звіту: 
 ні – повернення на початок; 
 так – доступно: 
 очищення журналу звіту – очищення усієї звітності з файлу; 
 збереження журналу звіту – збереження усієї звітності до 
зовнішнього файлу. 
 після цього відбувається повернення на початок. 
3 Є можливість одразу закрити програму. 
Представлена схема та її опис в повній мірі формують логіку системи. 
4.1.4. Розробка бази даних 
Невід’ємною частиною чисельної категорії інформаційних систем є бази 
даних. База даних є єдиним і великим сховищем даних, що визначається один раз, 
а потім багаторазово і спільно використовується різними користувачами або 
функціональними частинами системи. 
База даних розробленої системи є реляційною моделлю та складається з 
однієї таблиці (рисунок 4.4), яка має містить наступні поля: 
1 Id – ідентифікатор: 
 тип даних – Integer (Int); 
 довжина – 5; 
 нуль – не може бути порожнім; 
 опис – представляє собою ціле невід’ємне число. Використовується для 
унікальної ідентифікації записів і являє собою порядковий номер, 
починаючи з одиниці. 
92 
 
ЧДТУ.232223.026 ПЗ 
2 Numb – число: 
 тип даних – Real (Float); 
 довжина – 5; 
 нуль – може бути порожнім; 
 опис – представляє собою випадкове число з плаваючою крапкою. Це 
число має до двох цифр в цілій частині та до двох цифр у дробовій 
частині. 
3 Text – текст: 
 тип даних – String (VarChar); 
 довжина – 5; 
 нуль – може бути порожнім; 
 опис – представляє собою текст з п’яти випадкових символів у 
довільному регістрі. 
4 Date – дата: 
 тип даних – Date; 
 нуль – може бути порожнім; 
 довжина – 10; 
 опис – містить поточну дату у форматі: yyyy-mm-dd. 
5 Time – час: 
 тип даних – Time; 
 довжина – 8; 
 нуль – може бути порожнім; 
 опис – містить поточний час у форматі: hh:mm:ss. 
 
 
93 
 
ЧДТУ.232223.026 ПЗ 
Рисунок 4.4 – Структура таблиці бази даних 
Представлена структура бази даних повністю задовольняє вимоги 
розробленої системи. 
4.1.5. Розробка інтерфейсу користувача 
Розробка інтерфейсу користувача є ключовим етапом у процесі 
конструювання, спрямованим на створення зручного та ефективного середовища 
взаємодії між користувачем і програмним забезпеченням. Ця стадія має важливе 
значення, оскільки від неї залежить задоволеність та зручність користувача під 
час використання системи. 
Розроблений інтерфейс (рисунок 4.5) не лише спрощує взаємодію з 
програмою, але й забезпечує естетичний та ергономічний дизайн. 
 
 
94 
 
ЧДТУ.232223.026 ПЗ 
Рисунок 4.5 – Інтерфейс користувача 
Основні аспекти інтерфейсу користувача включають: 
1 Зручний та інтуїтивно зрозумілий інтерфейс. 
2 Використання в кольоровій схемі сірих, світло-сірих та білих тонів для 
максимальної зручності та мінімізації втоми очей. 
3 Елементи керування стандартними операціями з базами даних згруповані 
в окремі блоки, що спрощує навігацію. 
4 Оптимальне розташування та вигляд елементів керування. 
5 Розміщення полів для виведення інформації з обох баз даних поруч один з 
одним для зручності співставлення даних. 
6 Розташування кнопок управління журналом звіту під полем для його 
виведення. 
7 Можливість оновлення чи доробки інтерфейсу без суттєвих змін у 
системі. 
8 Використання сучасних підходів та технологій для забезпечення 
актуальності та сучасності інтерфейсу. 
Розроблений інтерфейс користувача, створений з урахуванням цих аспектів, 
сприяє не лише функціональності системи, але й приємному та продуктивному 
користувацькому досвіду. 
4.1.6. Розробка програмних компонентів 
Програмні компоненти являють собою цеглини у створенні програмного 
забезпечення, відіграючи визначальну роль у структурі системи, надаючи не лише 
зрозумілість логіки її функціонування, але й забезпечуючи необхідний 
функціонал для ефективної роботи. Вибір оптимальних алгоритмів та структур 
даних, їхня взаємодія та інтеграція в систему є вирішальними аспектами, які 
впливають на продуктивність та ефективність програмного продукту. 
Опис роботи алгоритмів розроблених програмних компонентів: 
1 index.php – виконавчий файл проекту, при ініціалізації якого виконуються 
наступні дії: 
95 
 
ЧДТУ.232223.026 ПЗ 
 підключення до текстової бази даних; 
 підключення до реляційної бази даних; 
 підключення до бібліотеки динамічних сценаріїв та функцій; 
 підключення до файлу стилів візуального оформлення інтерфейсу; 
 підключення до модулів стандартних операцій з БД; 
 підключення до модуля звітування; 
 відрисовка інтерфейсу користувача та елементів керування 
введенням/виведенням. 
2 fill.php – модуль наповнення БД, при ініціалізації якого виконуються 
наступні дії: 
 створюється файл ТБД, якщо він відсутній; 
 очищується файл ТБД, якщо він не порожній; 
 запускається таймер операції наповнення ТБД; 
 в циклі до вказаної кількості записів генеруються поля з інформацією і 
записуються у файл ТБД; 
 зупиняється таймер операції наповнення ТБД; 
 очищується таблиця РБД, якщо вона не порожня; 
 запускається таймер операції наповнення РБД; 
 в циклі до вказаної кількості записів генеруються поля з інформацією і 
додаються до таблиці РБД; 
 зупиняється таймер операції наповнення РБД; 
 передаються отримані результати модулю звітування. 
3 output.php – модуль виведення з БД, при ініціалізації якого виконуються 
наступні дії: 
 якщо БД порожні, наступні дії пропускаються; 
 запускається таймер операції виведення з ТБД; 
 в циклі виводиться вся інформація з файлу ТБД; 
 зупиняється таймер операції виведення з ТБД; 
 запускається таймер операції виведення з РБД; 
96 
 
ЧДТУ.232223.026 ПЗ 
 виводиться вся інформація з таблиці РБД; 
 зупиняється таймер операції виведення з РБД; 
 передаються отримані результати модулю звітування. 
4 add.php – модуль додавання до БД, при ініціалізації якого виконуються 
наступні дії: 
 якщо БД порожні, наступні дії пропускаються; 
 запускається таймер операції додавання до ТБД; 
 генеруються поля з інформацією і записуються в кінець файлу ТБД; 
 зупиняється таймер операції додавання до ТБД; 
 запускається таймер операції додавання до РБД; 
 генеруються поля з інформацією і додаються в кінець таблиці РБД; 
 зупиняється таймер операції додавання до РБД; 
 передаються отримані результати модулю звітування. 
5 edit.php – модуль редагування в БД, при ініціалізації якого виконуються 
наступні дії: 
 якщо БД порожні, наступні дії пропускаються; 
 запускається таймер операції редагування в ТБД; 
 шукається в файлі ТБД вказаний ідентифікаційний номер запису; 
 якщо запис по вказаному ідентифікаційному номеру не знайдено, 
наступна дія пропускається; 
 поля, які не пусті оновлюються вказаною інформацією, а пусті – 
залишаються без змін і перезаписується файл ТБД; 
 зупиняється таймер операції редагування в ТБД; 
 запускається таймер операції редагування в РБД; 
 якщо запис по вказаному ідентифікаційному номеру не знайдено, 
наступна дія пропускається; 
 поля, які не пусті оновлюються вказаною інформацією, а пусті – 
залишаються без змін і перезаписуються в таблиці РБД; 
 зупиняється таймер операції редагування в РБД; 
97 
 
ЧДТУ.232223.026 ПЗ 
 передаються отримані результати модулю звітування. 
6 remove.php – модуль видалення з БД, при ініціалізації якого виконуються 
наступні дії: 
 якщо БД порожні, наступні дії пропускаються; 
 запускається таймер операції видалення з ТБД; 
 шукається в файлі ТБД вказаний ідентифікаційний номер запису; 
 якщо запис по вказаному ідентифікаційному номеру не знайдено, 
наступна дія пропускається; 
 запис видаляється і перезаписується файл ТБД; 
 зупиняється таймер операції видалення з ТБД; 
 запускається таймер операції видалення з РБД; 
 якщо запис по вказаному ідентифікаційному номеру не знайдено, 
наступна дія пропускається; 
 запис видаляється з таблиці РБД; 
 зупиняється таймер операції видалення з РБД; 
 передаються отримані результати модулю звітування. 
7 report.php – модуль звітування, при ініціалізації якого виконуються 
наступні дії: 
 отримані результати формуються: додається поточна дата і час, назва 
операції і кількість записів у БД; 
 інформація записується у файл журналу звіту; 
 виводиться звіт; 
 при ініціалізації процедури очищення журналу звіту, інформація з 
файлу, якщо він не пустий, очищується; 
 при ініціалізації процедури збереження журналу звіту, інформація з 
файлу, якщо він не пустий, зберігається через діалогове вікно до файлу 
на клієнтській машині. 
Розподіл структури системи на індивідуальні компоненти дозволило 
організувати логічну структуру та забезпечити ефективне функціонування. Це 
98 
 
ЧДТУ.232223.026 ПЗ 
створює сприятливі умови для проведення ефективних тестувань та полегшує 
процес вдосконалення чи модифікації окремих компонентів системи. 
4.2. Тестування програмного комплексу 
Тестування програмного забезпечення – процес визначення 
характеристик або властивостей системи чи її компонентів, зазвичай шляхом 
введення визначених вхідних даних та оцінки отриманих результатів, з метою 
переконання в правильності роботи системи чи виявлення потенційних помилок, 
спрямований на підтвердження відповідності програмного забезпечення 
визначеним вимогам та виявлення його недоліків для подальшого виправлення. 
4.2.1. Модульне тестування 
Модульне тестування – процес перевірки окремих програмних процедур 
(модулів) і підпрограм, що входять до складу програм. Перевіряються всі 
внутрішні структури і потоки даних у кожному модулі. Проводиться 
безпосереднім розробником і входить до етапу розробки. 
Процес тестування полягав у перевірці коректності генерації та формування 
даних, результати якого відображені в таблиці 4.1. 
Таблиця 4.1 
Результати модульного тестування 
Очікуваний Отриманий Корект-
Опис і код тесту 
результат результат ність 
Генерація випадкового числа: число з плаваючою 62.34  
$test_numb = mt_Rand(0,99). крапкою, що має по 
78.56  
".".mt_Rand(0,99); дві цифрі в цілій та 
Echo $test_numb; дробовій частинах 18.92  
Генерація випадкового тексту: 
$test_text = Chr(mt_Rand(65,90)). HrPaQ  
текст з п’яти 
Chr(mt_Rand(97,122)). 
випадкових 
Chr(mt_Rand(65,90)). JgRpA  
символів у 
Chr(mt_Rand(97,122)). 
довільному регістрі 
Chr(mt_Rand(65,90)); AcYoM  
Echo $test_text; 
Формування поточної дати: поточна дата у 2023-11-25  
$test_date = Date("Y-m-d"); форматі: 2023-11-26  
99 
 
ЧДТУ.232223.026 ПЗ 
Echo $test_date; yyyy-mm-dd 2023-11-27  
Формування поточного часу: поточний час у 21:56:24  
$test_time = Date("H:i:s"); форматі: 22:30:48  
Echo $test_time; hh:mm:ss 23:03:11  
В ході модульного тестування в розробленій системі генерація та 
формування даних функціонували коректно та без помилок. 
4.2.2. Інтеграційне тестування 
Інтеграційне тестування – процес перевірки спільної роботи окремих 
модулів і передує тестуванню всієї системи як єдиного цілого. Перевіряються 
зв’язки між модулями, їх сумісність і функціональність. Проводиться незалежним 
тестувальником і входить до етапу тестування. 
Так як скористатись послугами незалежного тестувальника не було 
можливості весь процес інтеграційного тестування проводився власноруч. Процес 
тестування полягав у перевірці типізації переданих значень, результати якого 
відображені в таблиці 4.2. 
Таблиця 4.2 
Результати інтеграційного тестування 
Значення 
Очікуваний Отриманий Корект-
Код тесту змінної 
результат результат ність 
$test (*) 
$test = *; 5 true true  
$test_id = Is_Int($test); 3,5 false false  
Echo $test_id; abc false false  
$test = *; 36.48 true true  
$test_numb = Is_Float($test); 7 false false  
Echo $test_numb; qwe false false  
$test = *; HtZ true true  
$test_text = Is_String($test); 25 false false  
Echo $test_text; 18.54 false false  
$test = *; 2023-11-27 true true  
$test_date = Is_Date($test); 2023-11-32 false false  
Echo $test_date; 2023-13-27 false false  
$test = *; 22:30:18 true true  
$test_time = Is_Time($test); 22:61:18 false false  
Echo $test_time; 25:30:18 false false  
 
100 
 
ЧДТУ.232223.026 ПЗ 
В ході інтеграційного тестування в розробленій системі зв’язки між 
модулями у вигляді типізації переданих значень функціонували коректно та без 
помилок. 
4.2.3. Системне тестування 
Системне тестування – процес перевірки програмної системи в цілому, її 
організації та функціонування на відповідність специфікаціям вимог. 
Проводиться незалежним тестувальником після успішного завершення 
інтеграційного тестування. 
Так як скористатись послугами незалежного тестувальника не було 
можливості весь процес системного тестування проводився власноруч, в ході 
якого організація та функціонування розробленої системи відповідала 
специфікаціям вимог. 
4.2.4. Приймальне тестування 
Приймальне тестування – процес перевірки відповідності програмної 
системи визначеним вимогам та готовності до впровадження в експлуатацію. 
Проводиться організацією, що відповідає за інсталяцію, супровід та навчання 
кінцевого користувача. 
Так як скористатись послугами організації, що відповідає за інсталяцію, 
супровід та навчання кінцевого користувача не було можливості весь процес 
системного тестування проводився власноруч, в ході якого розроблена система 
відповідала визначеним вимогам та готова до впровадження в експлуатацію. 
4.3. Приклади впровадженого програмного комплексу 
У своїй довгостроковій практиці розробки web-сайтів різного рівня 
складності я використовую текстові бази даних вже більше 18 років. Вони 
зарекомендували себе як простий, ефективний та зручний інструмент зберігання 
даних. Цей метод неодноразово вдосконалювався, а алгоритми для роботи з 
текстовою базою даних постійно оптимізуються та покращуються. Це дозволяє 
тримати рівень web-розробки «на пульсі сьогодення» і розробляти сучасні, швидкі 
101 
 
ЧДТУ.232223.026 ПЗ 
та конкурентоздатні проекти. 
Мої останні розробки включають такі проекти: 
1 Teplodim.ck.ua – інтернет-магазин опалювальних систем магазину 
«Теплодім» (рисунок 4.6). 
 
 
Рисунок 4.6 – Web-сайт Teplodim.ck.ua 
 
Представлений web-ресурс працює з 2018 року. Використовує основну 
текстову базу даних для зберігання товару та його характеристик. А також багато 
другорядних для зберігання опису товарів та брендів, категорій та підкатегорій, 
статей, коментарів та рейтингу, журналів відвідувань та різних параметрів 
налаштувань. 
102 
 
ЧДТУ.232223.026 ПЗ 
2 Dumohod.com.ua – інтернет-магазин димохідних систем від виробника 
(рисунок 4.7). 
 
Рисунок 4.7 – web-сайт Dumohod.com.ua 
 
Представлений web-ресурс працює з 2016 року. Використовує основну 
текстову базу даних для зберігання товару та його характеристик. А також багато 
другорядних для зберігання опису товарів, категорій та підкатегорій, статей, 
відгуків, коментарів та рейтингу, журналів відвідувань та різних параметрів 
103 
 
ЧДТУ.232223.026 ПЗ 
налаштувань. 
3 Zhenprih.com.ua – інтернет-магазин жіночого одягу (рисунок 4.8). 
 
Рисунок 4.8 – web-сайт Zhenprih.com.ua 
 
Представлений web-ресурс працює з 2020 року. Використовує основну 
текстову базу даних для зберігання товару та його характеристик. А також багато 
другорядних для зберігання опису товарів, категорій та підкатегорій, відгуків, 
коментарів та рейтингу, журналів відвідувань та різних параметрів налаштувань. 
Використані алгоритми дозволяють швидко та зручно виводити необхідний 
перелік товарів, фільтрувати, сортувати та порівнювати його, додавати, 
редагувати та видаляти картки товарів та виконувати багато інших операцій з 
текстовими базами даних. 
104 
 
ЧДТУ.232223.026 ПЗ 
Висновки до розділу 
На етапі розробки та тестування програмного забезпечення для порівняння 
швидкості роботи з різними типами баз даних були вжиті важливі кроки для 
забезпечення якості та ефективності системи. 
Перш за все, було ретельно обґрунтовано вибір засобів реалізації, 
враховуючи вимоги проекту та потреби користувачів. Описані структурна, 
функціональна та логічна схеми допомогли сформувати архітектуру системи, 
чітко визначити функції та взаємозв’язки компонентів. Створена база даних, 
обрана з урахуванням особливостей текстових файлів і реляційних баз даних, 
забезпечили ефективне зберігання та обробку інформації. Інтерфейс користувача 
був розроблений з урахуванням естетичних та ергономічних аспектів, надаючи 
інтуїтивно зрозумілу платформу для взаємодії з системою. Розроблені програмні 
компоненти з оптимальними алгоритмами та структурами даних, забезпечили 
необхідний функціонал і ефективність роботи. 
Комплекс заходів з тестування не виявив критичних помилок, забезпечивши 
відповідність системи визначеним вимогам та готовність до впровадження. 
Врахування практики довгострокового використання текстових баз даних 
стало важливим фактором, який додатково відобразився в прикладах успішного 
впровадження програмного комплексу. 
105 
 
ЧДТУ.232223.026 ПЗ 
ВИСНОВКИ 
Метою цієї наукової роботи було вдосконалення методу застосування не 
реляційних баз даних. Цей складний підхід було розбито на проміжні етапи. 
На першому етапі був проведений інформаційний пошук методів та засобів 
розв’язання поставлених задач. В результаті якого були досліджені існуючі види 
баз даних, ознайомлено з історією їх формування та досліджено їх структури та 
види. Також були розглянуті сценарії застосування цих баз даних у реальному 
житті, проведено аналіз їх переваг та недоліків, а також тенденцій до їх 
розширення та методи вдосконалення. 
Однак, при розгляді застосування не реляційних баз даних у вигляді 
самостійних систем для зберігання та опрацювання даних, виявилось, що цей 
підхід не використовується чи робить це зовсім опосередковано, використовуючи 
їх як компоненти більш складних систем. Таким чином, постало завдання 
виявлення напрямків вдосконалення не реляційних баз даних, щоб визначити їх 
як ключовий інструмент у сценарії самостійної системи зберігання масиву даних. 
На другому етапі були проведені теоретичні та експериментальні 
дослідження. В результаті якого була сформована теорія та гіпотеза 
вдосконалення методу побудови не реляційних баз даних. Аналіз включав 
проміжні етапи, охоплюючи весь життєвий цикл роботи з базами даних, а саме: 
створення баз даних, їх використання в проекті, подальший супровід та 
підтримку. Окремий акцент робився на аспектах імпорту та експорту даних для 
редагування та оновлення інформації, а також зміні web-хостингу. Проведений 
ряд досліджень у вигляді експериментів довів правильність теорій та підтвердив 
гіпотезу. 
Результатом стала суттєва перевага у виборі вдосконаленої не реляційної 
бази даних, яка стала особливо актуальною, коли враховуються фінансові та 
кваліфікаційні аспекти розробки проекту. Нерідко програмне забезпечення для 
створення баз даних та самі бази можуть бути платними, що безпосередньо 
впливає на фінансові витрати проекту. Економія суттєвого шматка бюджету може 
бути досягнута завдяки вибору вдосконаленої не реляційної бази даних. Її 
106 
 
ЧДТУ.232223.026 ПЗ 
створення та обробка не вимагають використання додаткового програмного 
забезпечення або покупки ліцензій, що робить цей варіант привабливим для 
проектів із обмеженими фінансовими ресурсами. Крім того, важливо враховувати, 
що роботу з ними може опрацьовувати менш кваліфікований персонал. У такому 
випадку, відпадає потреба у необхідності залучення спеціалізованих фахівців, що 
призводить до додаткових витрат на зарплату та навчання персоналу. Отже, цей 
вибір визначається не лише потребами проекту, але і фінансовими можливостями 
та кваліфікацією команди розробників. 
Для отримання додаткових результатів досліджень був проаналізований 
існуючий ринок на наявність програмного забезпечення для порівняння 
швидкості роботи стандартних операцій з базами даних. Виявилось, що в 
прямому контексті подібних програм не існує. 
На третьому етапі було спроектовано програмний продукту оцінки 
швидкодії баз даних. Починаючи з моделювання предметної області, де 
визначався загальний функціонал майбутнього продукту, і закінчуючи чітким 
формулюванням первинних та детальних вимог, проектування виявилося 
ключовим для успішної реалізації завдань. 
Логічне, архітектурне та поведінкове проектування, висвітлене 
різносторонніми діаграмами та відповідними описами до них, дозволило не лише 
точно структурувати програмний продукт, але і визначити оптимальні методи та 
підходи до його розробки. Чітко визначені вимоги виходячи з предметної області 
гарантували, що функціональні та нефункціональні аспекти системи будуть 
впроваджені і відповідатимуть усім вимогам при розробці програмного продукту 
оцінки швидкодії баз даних. 
На четвертому етапі розробки та тестування програмного забезпечення для 
порівняння швидкості роботи з різними типами баз даних були вжиті важливі 
кроки для забезпечення якості та ефективності системи. 
Перш за все, було ретельно обґрунтовано вибір засобів реалізації, 
враховуючи вимоги проекту та потреби користувачів. Описані структурна, 
функціональна та логічна схеми допомогли сформувати архітектуру системи, 
107 
 
ЧДТУ.232223.026 ПЗ 
чітко визначити функції та взаємозв’язки компонентів. Створена база даних, 
обрана з урахуванням особливостей текстових файлів і реляційних баз даних, 
забезпечили ефективне зберігання та обробку інформації. Інтерфейс користувача 
був розроблений з урахуванням естетичних та ергономічних аспектів, надаючи 
інтуїтивно зрозумілу платформу для взаємодії з системою. Розроблені програмні 
компоненти з оптимальними алгоритмами та структурами даних, забезпечили 
необхідний функціонал і ефективність роботи. Комплекс заходів з тестування не 
виявив критичних помилок, забезпечивши відповідність системи визначеним 
вимогам та готовність до впровадження. 
Практика довгострокового використання текстових баз даних стала 
важливим фактором, який додатково відобразився в прикладах успішно 
впроваджених систем з використанням вдосконаленого методу застосування не 
реляційних баз даних. 
108 
 
ЧДТУ.232223.026 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1  https://studfile.net/preview/9262554/page:3/ – реляційні бази даних. 
2  http://dspace.nbuv.gov.ua/bitstream/handle/123456789/180674/04-
ReznichenkoNEW.pdf – етапи розвитку реляційних баз даних. 
3  https://seas.upenn.edu/~zives/03f/cis550/codd.pdf – реляційна модель даних 
Едгара Кодда. 
4  https://studfile.net/preview/9219838/page:2/ – структура реляційної бази даних. 
5  https://mysql.com/ – MySQL. 
6  https://postgresql.org/ – PostgreSQL. 
7  https:// oracle.com/database/ – Oracle Database. 
8  https:// microsoft.com/sql-server/ – Microsoft SQL Server. 
9  https:// sqlite.org/ – SQLite. 
10 https://mariadb.org/ – MariaDB. 
11 https://foxminded.ua/reliatsiini-bazy-danykh/ – сфери застосування реляційних 
баз даних. 
12 https://ua5.org/database/189-reljacjjna-baza-danikh.html – переваги та недоліки 
реляційних баз даних. 
13 https://studfile.net/preview/9735420/page:3/ – тенденції розвитку реляційних баз 
даних. 
14 https://studfile.net/preview/9924999/page:9/ – вдосконалення реляційних баз 
даних. 
15 https://studfile.net/preview/4149524/page:4/ – нереляційні бази даних. 
16 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/191029/08-Reznichenko.pdf 
– етапи розвитку нереляційних баз даних. 
17 https://studfile.net/preview/6338057/page:4/ – структура нереляційної бази даних. 
18 https://redis.io/ – Redis. 
19 https://aws.amazon.com/dynamodb/ – Amazon DynamoDB. 
20 https://mongodb.com/ – MongoDB. 
21 https://couchdb.apache.org/ – Apache CouchDB. 
22 https://cassandra.apache.org/ – Apache Cassandra. 
109 
 
ЧДТУ.232223.026 ПЗ 
23 https://hbase.apache.org/ – Apache HBase. 
24 https://neo4j.com/ – Neo4j. 
25 https://aws.amazon.com/neptune/ – Amazon Neptune. 
26 https://cloud.google.com/bigtable/ – Google Bigtable. 
27 https://accumulo.apache.org/ – Apache Accumulo. 
28 https://geomesa.org/ – GeoMesa. 
29 https://couchbase.com/ – Couchbase. 
30 https://arangodb.com/ – ArangoDB. 
31 http://orientdb.org/ – OrientDB. 
32 https://conferences.vntu.edu.ua/index.php/all-fitki/all-fitki-
2020/paper/view/9416/7928/ – сфери застосування реляційних баз даних. 
33 https://qagroup.com.ua/publications/nosql-perevagy-ta-nedoliky-nereliatcijnykh-baz-
danykh/ – переваги та недоліки нереляційних баз даних. 
34 https://core.ac.uk/download/pdf/288212436.pdf – тенденції розвитку 
нереляційних баз даних. 
35 https://ir.kneu.edu.ua/server/api/core/bitstreams/0238db0a-3c61-4236-b4cb-
7ac85de72dab/content – вдосконалення нереляційних баз даних. 
36 https://studfile.net/preview/5280774/page:3/ – текстові бази даних. 
37 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/183494/04-Reznichenko.pdf 
– етапи розвитку текстових баз даних. 
38 https://socialdata.org.ua/manual/manual2/ – структура текстової бази даних. 
39 https://uk.wikipedia.org/wiki/CSV – CSV. 
40 https://uk.wikipedia.org/wiki/JSON – JSON. 
41 https://uk.wikipedia.org/wiki/XML – XML. 
42 https://uk.wikipedia.org/wiki/YAML – YAML. 
43 https://kb.fileformat.app/uk/extension/txt-file-info/ – сфери застосування 
текстових баз даних. 
44 https://uk.wikipedia.org/wiki/Текстовий_файл – переваги та недоліки текстових 
баз даних. 
45 https://habr.com/ru/articles/729298/ – тенденції розвитку текстових баз даних. 
110 
 
ЧДТУ.232223.026 ПЗ 
46 https://uk.wikipedia.org/wiki/Текстові_дані – вдосконалення текстових баз 
даних. 
47 https://buklib.net/books/37218/ – методики визначення ефективності. 
48 https://studfile.net/preview/5213512/page:2/ – методологія постановки задачі 
структурної ідентифікації.
111 
 
 
 
 
 
 ЗАТВЕРДЖЕНО: 
 Зав. кафедри ПЗАС, професор 
 _________________________ Голуб С.М. 
 «_____» ___________________ 2023 
року 
 
 
 
Вдосконалення методу застосування не реляційних баз даних 
 
 
 
Специфікація 
482.ЧДТУ.232223-01 
Листів 2 
 
 
 
Виконавець _______________ Турченко А.С. 
 
Керівник _______________ Метелап В.В. 
 
Н.контроль _______________ Півень О.Б. 
 
 
 
 
Черкаси 2023
 
 
Позначення Найменування Примітка 
482.ЧДТУ.232223-01 34 01 Інструкція користувачеві  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
 
ДОДАТОК Б 
 
 
 
 
 
 
 
 
 
 
Вдосконалення методу застосування не реляційних баз даних 
 
 
 
Інструкція користувачеві 
482.ЧДТУ.232223-01 34 01 
Листів 12 
 
 
 
 
Виконавець _______________ Турченко А.С. 
 
 
 
 
 
 
 
 
Черкаси 2023
 
 
АНОТАЦІЯ 
Інструкція користувачеві надає детальну інформацію про призначення та 
можливості програмного продукту оцінки швидкодії баз даних, що є складовою 
вдосконалення методу застосування не реляційних баз даних, а також інформацію, 
необхідну користувачеві для роботи з системою. В інструкції користувачеві 
описуються порядок та правила роботи. 
Інструкція користувачеві складається з 14 листів і 18 рисунків.
ЗМІСТ 
Призначення системи ...................................................................................................... 4 
Умови запуску системи .................................................................................................. 5 
Запуск системи ................................................................................................................ 6 
Наповнення баз даних ..................................................................................................... 7 
Виведення з баз даних .................................................................................................... 9 
Додавання запису .......................................................................................................... 12 
Редагування запису ....................................................................................................... 14 
Видалення запису .......................................................................................................... 17 
Робота зі звітністю ........................................................................................................ 19 
Вихід із системи ............................................................................................................ 20 
 
 
 
Призначення системи 
Програмний продукт оцінки швидкодії баз даних дозволяє в реальному часі 
оцінити швидкість роботи зі стандартними операціями з базами даних, такі як: 
1 Наповнення баз даних в автоматичному режимі певною кількістю записів. 
2 Виведення усієї інформації з баз даних. 
3 Додавання запису до баз даних в автоматичному режимі. 
4 Редагування запису в базах даних, вказуючи ідентифікаційний номер 
запису та вносячи дані у поля вручну або автоматичному режимах. 
5 Видалення запису з баз даних, вказуючи ідентифікаційний номер запису. 
6 Серед можливостей є також виведення результатів у вигляді звіту: 
7 Поточної дати операції. 
8 Поточного часу операції. 
9 Назви поточної операції. 
10 Кількості записів у базах даних при поточній операції. 
11 Часу виконання операції у текстовій базі даних. 
12 Часу виконання операції у реляційній базі даних. 
Програмний продукт має засоби для забезпечення налаштувань, візуалізації, 
та захисту від недосвідченого користувача. 
 
 
Умови запуску системи 
Програмний продукт є web-ресурсом клієнт-серверної архітектури і для 
своєї роботи вимагає: 
1 Будь-який сучасний пристрій довільної архітектури і операційної системи: 
 стаціонарний комп’ютер чи ноутбук; 
 леп-топ або планшет; 
 смартфон. 
2 Доступ до мережі Інтернет не нижче 2G. 
3 Будь-який сучасний web-браузер. 
 
 
Запуск системи 
Для запуску програмного продукту необхідно в рядок адреси web-браузера 
ввести адресу web-ресурсу. Відкриється інтерфейс користувача (рисунок Б.1). 
 
 
Рисунок Б.1 – Інтерфейс користувача 
 
Система готова до роботи. 
 
 
Наповнення баз даних 
Для наповнення баз даних інформацією необхідно в блоці «Наповнення баз 
даних» (рисунок Б.2) в полі «Кількість записів» вибрати необхідну кількість 
записів для наповнення від «1» до «10000». Для цього необхідно натискати лівою 
кнопкою «миші» на стрілочки лічильника цього поля чи, після натискання лівої 
кнопки «миші» на цьому полі, натискати кнопки клавіатури «» чи «». Цей 
процес збільшує (зменшує) поточне число на «1». Також можна ввести потрібне 
значення з клавіатури. Для цього необхідно натиснути лівою кнопкою «миші» на 
цьому полі, видалити поточне значення і ввести необхідне. Якщо введене 
значення буде менше «0», тоді при втраті фокусу значення в цьому полі 
автоматично зміниться на мінімальне можливе, тобто «1». Якщо введене значення 
буде більше «10000», тоді при втраті фокусу значення в цьому полі автоматично 
зміниться на максимальне можливе, тобто «10000». За замовчуванням 
встановлене значення «1000». Після цього слід натиснути лівою кнопкою «миші» 
на кнопку «Наповнити». 
 
 
Рисунок Б.2 – Блок «Наповнення баз даних» 
 
В результаті відбудеться наповнення баз даних інформацією. В журнал 
звітування запишеться інформація по цій операції. У полі блоку «Звіт» (рисунок 
Б.3) відобразиться результат цієї операції. 
 
 
 
 
Рисунок Б.3 – Блок «Звіт» після наповнення баз даних 
 
Система знову готова до роботи. 
 
 
Виведення з баз даних 
Якщо бази даних порожні, вивести інформацію з баз даних неможливо. 
Кнопка «Вивести» блоку «Виведення з баз даних» буде неактивною (рисунок Б.4). 
 
Рисунок Б.4 – Блок «Виведення з баз даних» з порожніми базами даних 
 
Для виведення інформації з баз даних необхідно в блоці «Виведення з баз 
даних» (рисунок Б.5) натиснути лівою кнопкою «миші» на кнопку «Вивести». 
 
 
Рисунок Б.5 – Блок «Виведення з баз даних» 
 
В результаті відбудеться виведення інформації з баз даних (рисунок Б.6). 
 
 
 
 
Рисунок Б.6 – Блок «Виведення з баз даних» після виведення з баз даних 
В журнал звітування запишеться інформація по цій операції. 
Виведену інформацію у суб-блоках «Текстова БД» і «Реляційна БД» можна 
переглядати різними способами: 
1 Використовувати смужки прокрутки: 
 натискати лівою кнопкою «миші» на стрілочки навігації цієї смужки; 
 натиснути і утримувати ліву кнопкою «миші» на повзунку цієї смужки 
і рухати «мишу» вгору чи вниз. 
2 Навести курсор «миші» на цю область і скористатись колесом скролу 
«миші». 
3 Навести курсор «миші» на цю область, натиснути середню кнопку «миші» 
і рухати «мишу» вгору чи вниз. 
4 Натиснути ліву кнопку «миші» на потрібному суб-блоці і скористатись 
кнопками клавіатури «стрілочка вгору»/«стрілочка вниз» чи «Page Up»/«Page 
Down». 
У полі блоку «Звіт» (рисунок Б.7) відобразиться результат цієї операції. 
 
 
 
 
Рисунок Б.7 – Блок «Звіт» після виведення з баз даних 
 
Система знову готова до роботи. 
 
 
Додавання запису 
Якщо бази даних порожні, додати запис до баз даних неможливо. Кнопка 
«Додати» блоку «Додавання запису» буде неактивною (рисунок Б.8). 
 
 
Рисунок Б.8 – Блок «Додавання запису» з порожніми базами даних 
 
Для додавання запису до баз даних необхідно в блоці «Додавання запису» 
(рисунок Б.9) натиснути лівою кнопкою «миші» на кнопку «Додати». 
 
 
Рисунок Б.9 – Блок «Виведення з баз даних» 
 
В результаті відбудеться додавання запису до баз даних. В журнал 
звітування запишеться інформація по цій операції. У полі блоку «Звіт» (рисунок 
Б.10) відобразиться результат цієї операції. 
 
 
Рисунок Б.10 – Блок «Звіт» після додавання запису 
 
 
 
Система знову готова до роботи. 
 
 
Редагування запису 
Якщо бази даних порожні, редагувати запис у базах даних неможливо. Поля 
«Id», «Numb», «Text», «Date», «Time» і кнопка «Редагувати» блоку «Редагування 
запису» будуть неактивними (рисунок Б.11). 
 
 
Рисунок Б.11 – Блок «Редагування запису» з порожніми базами даних 
 
Для редагування запису у базах даних необхідно в блоці «Редагування 
запису» (рисунок Б.12) виконати наступні дії: 
1 В полі «Id» вибрати необхідний ідентифікаційний номер запису для 
редагування від «1» до останнього ідентифікаційного номеру запису в базах 
даних. Для цього необхідно натискати лівою кнопкою «миші» на стрілочки 
лічильника цього поля чи, після натискання лівої кнопки «миші» на цьому полі, 
натискати кнопки клавіатури «» чи «». Цей процес збільшує (зменшує) поточне 
число на «1». Також можна ввести потрібне значення з клавіатури. Для цього 
необхідно натиснути лівою кнопкою «миші» на цьому полі, видалити поточне 
значення і ввести необхідне. Якщо введене значення буде менше «0», тоді при 
втраті фокусу значення в цьому полі автоматично зміниться на мінімальне 
можливе, тобто «1». Якщо введене значення буде більше останнього 
ідентифікаційного номеру запису в базах даних, тоді при втраті фокусу значення в 
цьому полі автоматично зміниться на максимальне можливе, тобто значення 
останнього ідентифікаційного номеру запису в базах даних. За замовчуванням 
встановлене значення останнього ідентифікаційного номеру запису в базах даних. 
2 В полі «Numb» натиснути лівою кнопкою «миші», після чого в ньому 
автоматично згенерується число з плаваючою крапкою у форматі: дві цифри в 
цілій частині і дві цифри в дробовій частині, розділені крапкою. Також можна 
ввести потрібне значення з клавіатури. Для цього необхідно натиснути лівою 
 
 
кнопкою «миші» на цьому полі, видалити поточне значення і ввести необхідне. 
Якщо введене значення не буде відповідати формату, тоді при втраті фокусу 
значення в цьому полі очиститься. 
3 В полі «Text» натиснути лівою кнопкою «миші», після чого в ньому 
автоматично згенерується текст з п’яти символів у довільному регістрі. Також 
можна ввести потрібне значення з клавіатури. Для цього необхідно натиснути 
лівою кнопкою «миші» на цьому полі, видалити поточне значення і ввести 
необхідне. Якщо введене значення не буде відповідати формату, тоді при втраті 
фокусу значення в цьому полі очиститься. 
4 В полі «Date» натиснути лівою кнопкою «миші», після чого в ньому 
автоматично сформується поточна дата у форматі YYYY-MM-DD. Також можна 
ввести потрібне значення з клавіатури. Для цього необхідно натиснути лівою 
кнопкою «миші» на цьому полі, видалити поточне значення і ввести необхідне. 
Якщо введене значення не буде відповідати формату, тоді при втраті фокусу 
значення в цьому полі очиститься. 
5 В полі «Time» натиснути лівою кнопкою «миші», після чого в ньому 
автоматично сформується поточний час у форматі HH:MM:SS. Також можна 
ввести потрібне значення з клавіатури. Для цього необхідно натиснути лівою 
кнопкою «миші» на цьому полі, видалити поточне значення і ввести необхідне. 
Якщо введене значення не буде відповідати формату, тоді при втраті фокусу 
значення в цьому полі очиститься. 
Після цього слід натиснути лівою кнопкою «миші» на кнопку «Редагувати». 
 
 
Рисунок Б.12 – Блок «Редагування запису» 
 
В результаті відбудеться редагування запису у базах даних. В журнал 
звітування запишеться інформація по цій операції. 
 
 
Якщо будь-яку кількість полів залишити порожніми, то ці поля не будуть 
відредаговані. Якщо ввести не існуючий в базах даних ідентифікаційний номеру 
запису, то процес редагування пропуститься. 
У полі блоку «Звіт» (рисунок Б.13) відобразиться результат цієї операції. 
 
Рисунок Б.13 – Блок «Звіт» після редагування запису 
 
Система знову готова до роботи. 
 
 
Видалення запису 
Якщо бази даних порожні, видалити запис з баз даних неможливо. Поле 
«Id» і кнопка «Видалити» блоку «Видалення запису» будуть неактивними 
(рисунок Б.14). 
 
 
Рисунок Б.14 – Блок «Видалення запису» з порожніми базами даних 
 
Для видалення запису з баз даних необхідно в блоці «Видалення запису» 
(рисунок Б.15) в полі «Id» вибрати необхідний ідентифікаційний номер запису для 
редагування від «1» до останнього ідентифікаційного номеру запису в базах 
даних. Для цього необхідно натискати лівою кнопкою «миші» на стрілочки 
лічильника цього поля чи, після натискання лівої кнопки «миші» на цьому полі, 
натискати кнопки клавіатури «» чи «». Цей процес збільшує (зменшує) поточне 
число на «1». Також можна ввести потрібне значення з клавіатури. Для цього 
необхідно натиснути лівою кнопкою «миші» на цьому полі, видалити поточне 
значення і ввести необхідне. Якщо введене значення буде менше «0», тоді при 
втраті фокусу значення в цьому полі автоматично зміниться на мінімальне 
можливе, тобто «1». Якщо введене значення буде більше останнього 
ідентифікаційного номеру запису в базах даних, тоді при втраті фокусу значення в 
цьому полі автоматично зміниться на максимальне можливе, тобто значення 
останнього ідентифікаційного номеру запису в базах даних. За замовчуванням 
встановлене значення останнього ідентифікаційного номеру запису в базах даних. 
Після цього слід натиснути лівою кнопкою «миші» на кнопку «Видалити». 
 
 
 
 
Рисунок Б.15 – Блок «Видалення запису» 
 
В результаті відбудеться видалення запису у базах даних. В журнал 
звітування запишеться інформація по цій операції. 
Якщо ввести не існуючий в базах даних ідентифікаційний номеру запису, то 
процес видалення пропуститься. 
У полі блоку «Звіт» (рисунок Б.16) відобразиться результат цієї операції. 
 
 
Рисунок Б.16 – Блок «Звіт» після видалення запису 
 
Система знову готова до роботи. 
 
 
Робота зі звітністю 
Якщо журнал звітування порожній, то працювати з ним неможливо. Кнопка 
«Очистити» і кнопка «Зберегти» блоку «Звіт» будуть неактивними (рисунок Б.17). 
 
 
Рисунок Б.17 – Блок «Звіт» з порожнім журналом звітування 
 
Існує можливість очищення журналу звітування. Для цього необхідно в 
блоці «Звіт» (рисунок Б.16) натиснути лівою кнопкою «миші» на кнопку 
«Очистити». 
В результаті відбудеться видалення інформації з журналу звітування. Поле 
блоку «Звіт» очиститься (рисунок Б.17). 
Існує можливість збереження журналу звітування. Для цього необхідно в 
блоці «Звіт» (рисунок Б.16) натиснути лівою кнопкою «миші» на кнопку 
«Зберегти». Після цього з’явиться діалогове вікно збереження (рисунок Б.18). 
 
 
 
 
Рисунок Б.18 – Діалогове вікно збереження 
 
Стандартне системне діалогове вікно збереження дозволяє робити 
стандартні системні операції з файлами та директоріями. 
Файл, зі встановленим за замовчуванням ім’ям «Report.txt» можна змінити, 
вибрати необхідну директорію для збереження чи створити нову тощо. Після 
цього слід натиснути лівою кнопкою «миші» на кнопці «Save» чи кнопку «Enter» 
на клавіатурі. Дана дія призводить також до закриття діалогового вікна 
збереження файлу звіту. 
Існує можливість припинення збереження. Для цього слід натиснути лівою 
кнопкою «миші» на кнопці «Cancel», хрестику у правому верхньому куті 
діалогового вікна збереження чи кнопку «Esc» на клавіатурі, і вікно закриється. 
Вихід із системиДля виходу необхідно закрити вікно web-браузера чи 
вкладку, в якій відкрита система.
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
