databases-coursework/main.typ

#import "template.typ": *
#import "@preview/indenta:0.0.3": fix-indent

#let author = (
  name: "Білоус А. А.",
  full_name_gen: "Білоуса Антона Андрійовича",
  variant: 13, // TODO: custom variant.
  group: "ПЗПІ-23-3",
  gender: "m",
)

#let mentors = (
  (
    name: "Широкопетлєва М. С.",
    gender: "f",
    degree: "Ст. викл. каф. ПІ",
  ),
  (
    name: "Черепанова Ю. Ю.",
    gender: "f",
    degree: "Ст. викл. каф. ПІ",
  ),
  (
    name: "Русакова Н. Є.",
    gender: "f",
    degree: "Доц. каф. ПІ",
  ),
)

#let task_list = (
  done_date: datetime(year: 2024, month: 12, day: 27),
  initial_data: datetime(year: 2024, month: 9, day: 15),
  source: "методичні вказівки до виконання курсової роботи, вимоги до інформаційної системи, предметна область, що пов’язана з пакунковим репозиторієм та його менеджментом.",
  content: "вступ, аналіз предметної області; постановка задачі; проектування бази даних; опис програми; висновки; перелік джерел посилання.",
  graphics: "загальна діаграма класів, ER-діаграма, UML-діаграми, DFD-діаграма, схема БД в 1НФ, 2НФ, 3НФ, копії екранів (“скриншоти”) прикладної програми, приклади звітів прикладної програми.",
)

#let calendar_plan = (
  plan_table: [],
  approval_date: datetime(year: 2024, month: 12, day: 27),
)

#let abstract = (
  keywords: (
    "БАЗА ДАНИХ",
    // "АВТОМАТИЗАЦІЯ",
    "РЕПОЗИТОРІЙ",
    "ПАКУНОК",
    "RUST",
    "MYSQL",
    "SQL",
  ),
  text: [
    Мета даної роботи -- проєктування та розробка інформаційної системи "Репозиторій пакунків. Колаборація над пакунками", яка спрямована на створення ефективного середовища для спільної розробки та управління програмними пакунками. Система забезпечує зберігання інформації про програмні пакунки, а також надає інструменти для їх вдосконалення колективною співпрацею користувачів.

    Для реалізації інформаційної системи було обрано сучасний стек технологій, а саме:
    Rust @rust -- як основна мова програмування для всих частин застосунку,
    iced @iced -- бібліотека для побудови графічних інтерфейсів з Elm архітектурою,
    SQLx @sqlx -- бібліотека для низькорівневої роботи з базою даних, що забезпечує коректність і гнучкість,
    MySQL @mysql -- як СУБД для зберігання інформації про пакунки, користувачів, та їх відносини,
    Neovim @neovim -- як сучасний редактор коду для швидкої і зручної розробки.

    Результат розробки -- комп'ютерна програма, яка дозволяє зберігати та відображати інформацію про користувачів, пакунки та їх відносини; генерувати статистику про користувача та його пакунки. Застосунок, створений з використанням мови програмування Rust є безпечним, правильним, надійним та швидким.
  ],
)

#let appendices = (
  /*(
    title: "Приклад звіту 1",
    content: [test],
  ),
  (
    title: "Приклад звіту 2",
    content: [test],
  ),
  (
    title: "Приклад звіту 3",
    content: [test],
  ),*/
)

#show: cw-template.with(
  title: [Інформаційна система "Репозиторій пакунків". Колаборація над пакунками],
  subject_shorthand: "БД",
  department_gen: "Програмної інженерії",
  edu_program_shorthand: "ПЗПІ",
  author: author,
  mentors: mentors,
  task_list: task_list,
  calendar_plan: calendar_plan,
  abstract: abstract,
  bib_path: "bibl.yml",
  appendices: appendices,
)

#show: fix-indent()

#nheading("Вступ")
У сучасному світі істують мільйони пакунків з програмним забезпеченням, програмними бібліотеками та іншою інформацією.
Інформаційні системи управління цими пакунками стали критично важливим елементом сучасної розробки програмного забезпечення. Їх значення особливо зросло з розвитком відкритого програмного забезпечення та модульного підходу до розробки, де кожен проект може залежати від десятків, сотень, або навіть тисяч сторонніх компонентів.

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

Метою цієї курсової роботи є розробка інформаційної системи "Репозиторій пакунків. Колаборація над пакунками", яка спрощує процес менеджменту пакунків, створення їх відносин, керування залежностями, та надання користувачам різних ролей у розвитку репозиторію. У процесі роботи над системою було проведено детальний аналіз зхожої системи AUR @aur, котра ефективно використовується для надання користувачам дистрибутиву Arch Linux @archlinux можливості публіковати свої пакунки. Було спроектовано реляційну базу даних і розроблено комп'ютерну програму, яка дозволяє взаємодіяти з репозиторієм.

Весь застосунок написано мовою програмування Rust @rust, для графічного інтерфейсу використовується бібліотека iced @iced, для взаємодії з базою даних використвуєтсья бібліотека SQLx @sqlx. Інформація зберігається у базі даних MySQL @mysql. Розробка виконувалася у текстовому редакторі Neovim @neovim.

= АНАЛІЗ ТА КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
#v(-spacing)
== Аналіз предметної області
Дослідження предметної області є ключовим етапом у розробці інформаційної системи "Репозиторій пакунків. Колаборація над пакунками". Основною метою даного аналізу є визначення функціональних вимог та технічних особливостей системи, необхідних для ефективного управління програмними пакунками та забезпечення продуктивної співпраці розробників.

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

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

В якості системи-аналогу розглянемо Arch User Repository (AUR) @aur -- репозиторій користувацьких пакунків для дистрибутиву Arch Linux @archlinux. AUR є яскравим прикладом успішної реалізації концепції колаборативної розробки та управління пакунками. Система надає користувачам можливість самостійно створювати та поширювати пакунки, які не входять до офіційного репозиторію.

При відвідуванні головної сторінки AUR @aur_main можна побачити статиску свого акаунту, всього репозиторію а також останні оновлення пакунків. За допомогою поля пошуку можна перейти до сторінки пошуку пакунків @aur_search.

#img("img/aur_main.png", "Головна сторінка AUR")

#img("img/aur_search.png", "Сторінка пошуку AUR")

Зі сторінки пошуку пакунків можна перейти до сторінки інформації пакунку, або ж до сторінки користувача який супроводжує пакунку. На сторінці інформації пакунку @aur_package можна побачити що пакунок має базу пакунку, пошукові слова, ліцензії, різні ролі користувачів, інформацію про залежності, тощо. На сторінці інформації про користувача @aur_user можна побачити різні атрибути пов'язані з акаунтом.

#img("img/aur_package.png", "Деталі пакунку в AUR")

#img("img/aur_user.png", "Деталі користувача в AUR")

Навігація по репозиторію здебільного здійснюється за допомогою гіперпосилань на сторінку пошуку де можна обрати досить багато критерій пошуку. Наприклад, при натисканні посилання "View this user's packages" в профілі користувача lsf, можна побачити всі пакунки котрі цей користувач підтримує @aur_search_func.

#img("img/aur_search_func.png", "Фунціонал пошуку AUR")

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

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

Основні інформаційні потреби користувачів системи включають:
- забезпечення повного циклу управління пакунками: створення, редагування, версіонування та видалення;
- надання інструментів для автоматизованої перевірки залежностей та сумісності компонентів;
- забезпечення генерації технічної документації та звітів про використання пакунків.

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

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

== Концептуальне моделювання предметної області
Інформаційна система передбачає взаємодію як для читачів (неавтентифікованих користувачів), так і для автентифікованих користувачів. Система автоматизує процеси пов'язні з відстеженням залежностей пакунків, прав користувачів, пошуком пакунків і генеруванням статистик.

Кожний неавтентифікований користувач буде мати можливість ефективно:
- здійснювати пошук пакунків за різними параметрами;
- переглядати інформацію про пакунки, їх бази;
- переглядати інформацію про користувачів;
- переглядати статистику репозиторію;
- увійти у існуючий, або створити новий акаунт.

Разом з можливостями неавтентифікованих користувачів, автентифіковані користувачі повинні мати можливість ефективно:
- створювати пакунки;
- створювати бази пакунків;
- видаляти власні пакунки та бази пакунків;
- додавати, видаляти та оновлювати залежності та відносини для власних пакунків;
- додавати, видаляти та оновлювати ролі інших користувачів для власних пакунків;
- оновлювати чужі пакунки та бази пакунків до яких був наданий доступ редагування;
- переглядати статистику свого акаунту;
- змінювати інформацію своєго акаунту;
- вийти з акаунту;
- видалити свій акаунт.

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

#img("img/class_diagram.png", "Загальна діаграма класів (рисунок виконаний самостійно)")

Система буде зберігати наступні дані:
- об'єкт користувача буде зберігати інформацію про користувачів системи. Він буде містити ім'я користувача, електронну пошту, пароль, час останнього використання обілкового запису, та його час створення з оновленням. Ця інформація необхідна для автентифікації та авторизації користувачів, а також для аудиту дій користувачів в системі;
- об'єкт бази пакунку буде зберігати базову інформацію про групи пакунків. Він дозволить об'єднувати пакунки зі спільними компонентами та користувачами. Містить ім'я та опис групи пакунків, а також час створення та останнього оновлення. Ця інформація дозволяє групувати пакунки за їх базовою функціональністю;
- об'єкт типу ролі користувача буде описувати ролі користувачів у контексті груп пакунків. Містить ідентифікатор ролі, її ім'я та опис. Приклади ролей: submitter (відправник), packager (пакувальник), maintainer (супроводжуючий), flagger (позначник). Цей об'єкт визначає дозволи користувачів на певні дії з групами пакунків;
- об'єкт ролі користувача буде прив'язувати користувачів до груп пакунків та визначати їх ролі в цих групах. Містить ідентифікатор групи пакунків, ідентифікатор користувача, ідентифікатор ролі та коментар від користувача. Ця інформація дозволяє визначити, хто, чому, і які права має в кожній групі пакунків;
- об'єкт пакунку буде зерігати інформацію про окремі пакунки. Містить ідентифікатор групи пакунків, ім'я пакунку, версію, опис, веб-покликання, опціональний час позначення, час створення та останнього оновлення. Ця інфрмація є основною для ідентифікації та опису кожного пакунку;
- об'єкт виду залежності буде визначати типи залежностей пакунків (наприклад, проста залежність, залежність для збірки пакунку, опціональна залежність). Містить ідентифікатор типу залежності та її назву. Цей об'єкт дозволить класифікувати залежності пакунків;
- об'єкт залежностей пакунку буде зберігати інформацію про залежності пакунків. Він буде містити архітектуру, умову, опис, ідентифікатор пакунку, ідентифікатор типу залежності та псевдонім назви залежності. Ця інформація дозволяє визначити, від яких інших пакунків залежить даний пакунок.
- об'єкт виду відносин буде визначати типи відносин між пакунками (наприклад: конфліктує, надає, замінює). Містить ідентифікатор типу відношення та його назву. Цей об'єкт дозволяє класифікувати відносини між пакунками;
- об'єкт відносин пакунків буде зберігати інформацію про відносини пакунків (конфлікти, надання, заміна). Містить архітектуру, вимоги, ідентифікатор пакунку, ідентифікатор типу відношення та ім'я пакунку-відношення. Ця інформація дозволяє визначити, які пакунки конфліктують з даним пакунком, які функції він надає, і які пакунки він замінює.

Користувач системи має можливість здійснювати пошук пакунків та перегляди їх інформацію, переходити до профілей користувачів та переглядати їх пакунки. Для наочного представлення процесів та потоків даних в системі під час виконання користувачем поставленої задачі створимо DFD-діаграму @data_diagram, що відображатиме послідовність кроків під час виконання користувачем цільової бізнес-задачі перегляду інформації про пакунок та отримання звіту з цієї інформації.

#img("img/data_diagram.png", "Діаграма потоків даних (рисунок виконано самостійно)")

Для ефективного відображення інформаційних потреб користувачів необхідно побудувати діаграму варіантів використання (Use Case). Ця діаграма /* @usecase_diagram */ демонструє взаємодію між різними акторами системи, такими як користувачі, адміністратори та інші учасники, та функціональними можливостями системи, такими як управління пакунками, їх створення, перегляд, отримання інформації та інші операції. Діаграма варіантів використання дозволяє визначити основні сценарії взаємодії користувачів з системою, ідентифікувати ключові функції та процеси, що відбуваються під час цієї взаємодії, та забезпечити розробку системи, яка відповідає реальним потребам користувачів. Крім того, діаграма варіантів використання може бути використана для визначення пріоритетів функціональних можливостей системи, виявлення потенційних проблем та слабких місць у процесах взаємодії з користувачами, а також для оптимізації архітектури системи для забезпечення максимальної ефективності та зручності використання.

//#img("img/usecase_diagram.png", "Use-Case діаграма (рисунок виконаний самостійно)")

= Постановка задачі

Метою курсової роботи є розробка інформаційної системи "Репозиторій пакунків. Колаборація над пакунками", яка забезпечить ефективне зберігання, пошук, управління та спільну розробку програмних пакунків. Після аналізу предметної області було виділено наступні вимоги щодо функціоналу інформаційної системи:

+ Підтримка основних процесів управління пакунками та їх метаданими:
  + створення пакунків, їх оновлення та видалення;
  + керування метаданими пакунків, включаючи назву, версію, веб-покликання на ресурс, ліцензію, опис та групу;
  + додання, оновлення та видалення залежностей між пакунками, а саме: обов'язкова залежність, опціональна залежність, та залежність під час збірки пакунку;
  + додання, оновлення та видалення відносин пакунків таких як: надання залежності, конфлікт з залежністю та заміна залежності.

+ Забезпечення системи користувацьких акаунтів:
  + надійний механізм реєстрації та автентифікації користувачів;
  + можливість видалення свого акаунту та передачі пакунків іншому користувачеві;
  + механізм блокування недобросовісних користувачів.

+ Система прав користувачів над пакунками:
  + мітчик пакунку -- будь-який користувач котрий знаходить проблему в пакунку та помічає його з коментарем який описує цю проблему;
  + автор пакунку -- користувач який створив пакунок, він володіє пакунком та може здійснювати всі процеси управління пакунком, в тому числі надавати права іншим користувачам;
  + пакувальник пакунку -- користувач котрий має дозвіл на завантаження нових збірок пакунку до репозиторію;
  + супроводжуючий пакунку -- користувач котрий був назначений автором як його заступник який може здійснювати всі процеси управління пакунком окрім назначення нових авторів і супроводжуючих та видалення пакунку.

+ Функції пошуку та категоризації:
  + пошук та фільтрація пакунків за веб-покликанням, назвою, групою, описом пакунку, описом групи, навзвою та описом пакунку, користувачем, помітчиком, пакувальником, подавачем та супроводжуючим пакунку;
  + можливість точного та довільного пошуку;
  + можливість вибору ліміту кількості результатів пошуку;
  + сортування результатів за назвою пакунку, його версією, назвою групи, часом створення та часом останнього оновлення.

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

= Проектування бази даних
#v(-spacing)
== Побудова ER-діаграми
Проведений аналіз предметної області дозволив визначити наступні сутності та їх атрибути:

- сутність "Користувач": ім'я, електронна пошта, пароль, дата останнього використання, дата створення, дата оновлення;
- сутність "Пакунок": назва, версія, опис, веб-покликання, дата позначення, дата створення, дата оновлення;
- сутність "База пакунку": назва, опис, дата створення, дата оновлення;
- сутність "Тип ролі": назва ролі, опис;
- сутність "Роль": коментар;
- сутність "Тип залежності": назва виду залежності;
- сутність "Залежність": архітектура, умова, опис, назва залежного пакунку;
- сутність "Тип відношення": назва виду відношення;
- сутність "Відношення": архітектура, умова, назва пакунку з яким є відношення.

Між цими сутностями існують наступні зв’язки:

- "Користувач" - "Роль": один до жодного або багатьох;
- "База пакунку" - "Роль": один до жодного або багатьох;
- "Тип ролі" - "Роль": один до жодного або багатьох;
- "База пакунку" - "Пакунок": один до жодного або багатьох;
- "Пакунок" - "Залежність": один до жодного або багатьох;
- "Тип залежності" - "Залежність": один до жодного або багатьох;
- "Пакунок" - "Відношення": один до жодного або багатьох;
- "Тип відношення" - "Відношення": один до жодного або багатьох.

Зобразимо визначені сутності та відповідні зв’язки у вигляді ER-діаграми @er_diagram.

#img("img/er_diagram.png", "ER-діаграма концептуальної моделі (рисунок виконаний самостійно)")

Отримана ER-діаграма буде використана для обрання та побудови логічної моделі бази даних.

== Вибір та побудова логічної моделі бази даних на базі ER-діаграми


#img("img/logic_model.png", "Логічна модель бази даних (рисунок виконаний самостійно)")



== Побудова логічної моделі бази даних шляхом нормалізаці
...

= Опис програми
#v(-spacing)
== Загальні відомості
...
== Виклик і завантаження
...
== Призначення і логічна структура
...
== Опис фізичної моделі бази даних
...
== Опис програмної реалізації

#nheading("Висновки")
...