Start normalization

main.typ

@@ -257,13 +257,70 @@
 
 == Вибір та побудова логічної моделі бази даних на базі ER-діаграми
 
+Для створення логічної моделі бази даних репозиторію пакунків було обрано реляційну модель. Ця модель дозволяє ефективно організувати дані у вигляді взаємопов'язаних таблиць, що забезпечує чітку структуру інформації в контексті управління пакунками та колаборації між користувачами. Вона гарантує узгодженість всіх зв'язків між сутностями, такими як "Користувач", "Пакунок", "База пакунку" та іншими, а також підтримує обмеження цілісності даних.
+
+Реляційна модель надає потужні можливості для виконання складних запитів, що є критичним для системи управління пакунками. Це дозволяє ефективно обробляти запити користувачів щодо пошуку пакунків, аналізу залежностей та відношень між ними, а також керування правами доступу через систему ролей. На основі розробленої ER-діаграми @er_diagram було спроєктовано логічну модель бази даних @logic_model.
+
+Для забезпечення точного розуміння відповідності між ER-діаграмою та логічною схемою створено довідник атрибутів /* TODO @attributes */. Цей довідник встановлює однозначну відповідність між термінами, використаними в концептуальній моделі (ER-діаграмі) та їх представленням у логічній моделі бази даних. Особливу увагу приділено відображенню зв'язків між сутностями, що реалізовані через механізм зовнішніх ключів, забезпечуючи цілісність даних та правильну роботу системи контролю версій пакунків.
+
+Обрана модель також враховує специфіку роботи з пакунками, їх залежностями та відношеннями, що є ключовим аспектом функціонування репозиторію пакунків. Це дозволяє ефективно відстежувати зміни в пакунках, керувати правами доступу користувачів та забезпечувати надійну основу для колаборації над пакунками.
+
+/* TODO table */
 
 #img("img/logic_model.png", "Логічна модель бази даних (рисунок виконаний самостійно)")
 
+Побудована база даних відповідає умовам третьої нормальної форм, адже кожна таблиця має первинний ключ, всі атрибути є атомарними, всі не ключові атрибути знаходяться у повній функціональній залежності від відповідних первинних ключів, та у таблицях відсутні транзитивні залежності.
 
 
++ Таблиця Users:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: name, email, password, last_used, created_at, updated_at;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця Packages:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: base, name, version, description, url, flagged_at, created_at, updated_at;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця PackageBases:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: name, description, created_at, updated_at;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця PackageBaseRoles:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: name, description;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця PackageBaseUserRoles:
+  + від складеного первинного ключа (base, user, role) залежать всі неключові атрибути, а саме: comment;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від складеного первинного ключа (base, user, role), відсутні транзитивні залежності.
+
++ Таблиця DependencyTypes:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: name;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця PackageDependencies:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: arch, requirement, description, package, dependency_type, dependency_package_name;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця RelationTypes:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: name;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
++ Таблиця PackageRelations:
+  + від первинного ключа id залежать всі неключові атрибути, а саме: arch, requirement, package, relation_type, relation_package_name;
+  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.
+
 == Побудова логічної моделі бази даних шляхом нормалізаці
-...
+
+
+Нормалізація бази даних виконується для оптимізації її структури, мінімізації надлишковості даних та забезпечення їх цілісності. Цей процес допомагає уникнути аномалій під час операцій з даними, підвищує ефективність роботи з базою та робить її більш адаптивною до змін. Нормалізація передбачає декомпозицію великих таблиць на менші, та встановлення логічних зв'язків між ними, що спрощує підтримку та покращує організацію даних.
+
+// TODO: img
+
+// Для перевірки відповідності бази даних третій нормальній формі, розглянемо п'ять основних сутностей з нашої ER-діаграми: "Користувач", "Пакунок", "База пакунку", "Роль" та "Залежність" (див. рис. 3.3). З атрибутів цих сутностей сформуємо універсальне відношення T (див. рис. 3.4).
+
+// Перша нормальна форма вимагає, щоб усі атрибути містили лише атомарні (неподільні) значення, а відношення мало первинні ключі для забезпечення унікальності записів. Аналіз універсального відношення показує, що всі його атрибути є атомарними. Оптимальними ключовими атрибутами виступають "Користувач_ID", "Пакунок_ID" та "Роль_ID". Кожен з цих ідентифікаторів дає доступ до відповідного набору атрибутів: "Користувач_ID" – до даних користувача, "Пакунок_ID" – до інформації про пакунок, а "Роль_ID" – до даних про роль користувача в системі.
+
+Таким чином, можна констатувати, що відношення T задовольняє вимогам першої нормальної форми.
+
 
 = Опис програми
 #v(-spacing)
@@ -277,5 +334,13 @@
 ...
 == Опис програмної реалізації
 
+
 #nheading("Висновки")
-...
+
+В результаті виконання курсової роботи було розроблено інформаційну систему "Репозиторій пакунків" для організації ефективної колаборації над програмними пакунками. В процесі розробки було проведено ґрунтовний аналіз предметної області, визначено ключові вимоги до системи та спроектовано оптимальну структуру бази даних для зберігання інформації про пакунки, їх версії, залежності, користувачів та їхні ролі.
+
+Створена система забезпечує зручний інтерфейс для пошуку пакунків, управління пакунками та колаборації між розробниками. Реалізовано функціонал створення та оновлення пакунків, відстеження залежностей та взаємозв'язків між пакунками, а також систему ролей для контролю доступу.
+
+База даних спроектована на основі реляційної моделі та нормалізована до третьої нормальної форми, що забезпечує оптимальну структуру даних та відсутність їх надлишковості. Під час розробки було використано мову програмування Rust@rust, систему управління базами даних MySQL@mysql та графічну бібліотеку iced@iced. Крім того використовуєтсья контейнеризація за допомогою Docker@docker та Docker Compose@compose що забезпечує надійність роботи системи, її масштабованість та простоту розгортання в різних середовищах.
+
+Розроблена інформаційна система значно спрощує процес управління та отримання інформації про програмні пакунки. Вона відповідає поставленим завданням та має потенціал подальшої реалізації завдяки використанню дуже модульної архітектури моделювання програмного забеспечення, відомої як Гексагональна архітектура@hexagonal.