Project description
This commit is contained in:
@ -62,6 +62,14 @@ iced-editor:
|
||||
|
||||
# ===== DESIGN ==== #
|
||||
|
||||
elm:
|
||||
type: Web
|
||||
title: Elm - delightful language for reliable web applications.
|
||||
author: Elm - delightful language for reliable web applications.
|
||||
url:
|
||||
value: https://elm-lang.org/
|
||||
date: 2025-02-11
|
||||
|
||||
# Richard Feldman. Making Impossible States Impossible, 2016. YouTube. URL: https://www.youtube.com/watch?v=IcgmSRJHu_8 (date of access: 09.02.2025).
|
||||
elm-conf:
|
||||
type: Web
|
||||
@ -73,6 +81,15 @@ elm-conf:
|
||||
date: 2025-02-09
|
||||
|
||||
hexagonal:
|
||||
type: Web
|
||||
title: Гексагональна архітектура (програмування) — Вікіпедія
|
||||
author: Учасники проектів Вікімедіа
|
||||
publisher: Вікіпедія
|
||||
url:
|
||||
value: https://uk.wikipedia.org/wiki/%D0%93%D0%B5%D0%BA%D1%81%D0%B0%D0%B3%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0_%D0%B0%D1%80%D1%85%D1%96%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F)
|
||||
date: 2025-02-11
|
||||
|
||||
hexagonal-guide:
|
||||
type: Web
|
||||
title: How to apply hexagonal architecture to Rust
|
||||
author: Josip Benko-Đaković
|
||||
|
||||
BIN
3/coursework/img/repo/project_structure.png
Normal file
BIN
3/coursework/img/repo/project_structure.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
3/coursework/img/repo/repo_login.png
Normal file
BIN
3/coursework/img/repo/repo_login.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
BIN
3/coursework/img/repo/repo_register.png
Normal file
BIN
3/coursework/img/repo/repo_register.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
@ -35,7 +35,28 @@
|
||||
)
|
||||
|
||||
#let calendar_plan = (
|
||||
plan_table: [],
|
||||
plan_table: [
|
||||
// thanks Yehor
|
||||
#table(
|
||||
columns: 4,
|
||||
align: (center, left, center, center),
|
||||
[Номер], [Назва етапів курсової роботи], [Строк виконання етапів роботи], [Примітки],
|
||||
[1], [Аналіз предметної області], [15.09.24 – 24.09.24], [Виконано],
|
||||
[2], [Концептуальне моделювання], [24.09.24-30.09.24], [~],
|
||||
[2], [Постановка задачі], [28.09.24 – 2.10.24], [Виконано],
|
||||
[3], [Побудова ER-діаграми та схеми БД], [2.10.24 – 18.10.24], [Виконано],
|
||||
[4], [Оформлення розділів 1, 2 та 3.1, 3.2 пояснювальної записки], [10.10.24 - 18.10.24], [Виконано],
|
||||
[5], [Перша контрольна точка з курсової роботи], [20.10.24], [Виконано],
|
||||
[6], [Нормалізація бази даних], [20.10.24 - 15.11.24], [Виконано],
|
||||
[7], [Створення програми], [20.10.24 – 20.11.24], [Виконано],
|
||||
[8], [Тестування програми, наповнення бази даних], [20.11.24 - 5.12.24], [Виконано],
|
||||
[9], [Друга контрольна точка з курсової роботи], [7.12.24], [Виконано],
|
||||
[10], [Реалізація остаточної версії програми], [7.12.24-15.12.24], [Виконано],
|
||||
[11], [Оформлення інших розділів пояснювальної записки], [1.11.24 – 25.12.24], [Виконано],
|
||||
[12], [Третя контрольна точка з курсової роботи], [27.12.24], [Виконано],
|
||||
)
|
||||
|
||||
],
|
||||
approval_date: datetime(year: 2024, month: 12, day: 27),
|
||||
)
|
||||
|
||||
@ -109,7 +130,7 @@
|
||||
== Аналіз предметної області
|
||||
Дослідження предметної області є ключовим етапом у розробці інформаційної системи "Репозиторій пакунків. Колаборація над пакунками". Основною метою даного аналізу є визначення функціональних вимог та технічних особливостей системи, необхідних для ефективного управління програмними пакунками та забезпечення продуктивної співпраці розробників.
|
||||
|
||||
Пакунковий репозиторій являє собою централізоване сховище інформації про програмне забезпечення, що забезпечує зберігання, версіонування та розповсюдження програмних компонентів. В сучасних умовах критично важливою є автоматизація таких процесів як управління залежностями, контроль версій, перевірка сумісності та забезпечення безпеки пакунків. Це дозволяє значно підвищити ефективність розробки програмного забезпечення та мінімізувати ризики, пов'язані з використанням сторонніх компонентів.
|
||||
Репозиторій пакунків являє собою централізоване сховище інформації про програмне забезпечення, що забезпечує зберігання, версіонування та розповсюдження програмних компонентів. В сучасних умовах критично важливою є автоматизація таких процесів як управління залежностями, контроль версій, перевірка сумісності та забезпечення безпеки пакунків. Це дозволяє значно підвищити ефективність розробки програмного забезпечення та мінімізувати ризики, пов'язані з використанням сторонніх компонентів.
|
||||
|
||||
Для створення ефективної системи управління пакунками необхідно ретельно проаналізувати існуючі рішення та їх особливості. Такий аналіз допомагає виявити найбільш важливі функціональні можливості та уникнути потенційних проблем при проектуванні власної системи.
|
||||
|
||||
@ -187,6 +208,7 @@
|
||||
|
||||
Для ефективного відображення інформаційних потреб користувачів необхідно побудувати діаграму варіантів використання (Use Case). Ця діаграма /* @usecase_diagram */ демонструє взаємодію між різними акторами системи, такими як користувачі, адміністратори та інші учасники, та функціональними можливостями системи, такими як управління пакунками, їх створення, перегляд, отримання інформації та інші операції. Діаграма варіантів використання дозволяє визначити основні сценарії взаємодії користувачів з системою, ідентифікувати ключові функції та процеси, що відбуваються під час цієї взаємодії, та забезпечити розробку системи, яка відповідає реальним потребам користувачів. Крім того, діаграма варіантів використання може бути використана для визначення пріоритетів функціональних можливостей системи, виявлення потенційних проблем та слабких місць у процесах взаємодії з користувачами, а також для оптимізації архітектури системи для забезпечення максимальної ефективності та зручності використання.
|
||||
|
||||
// TODO
|
||||
//#img("img/usecase_diagram.png", "Use-Case діаграма (рисунок виконаний самостійно)")
|
||||
|
||||
= Постановка задачі
|
||||
@ -368,7 +390,10 @@
|
||||
|
||||
Відношення зберігають першу нормальну форму та не містять неповних функціональних залежностей, оскільки кожне з них має лише один ключовий атрибут. Таким чином, можна зробити висновок, що ці відношення відповідають вимогам другої нормальної форми.
|
||||
|
||||
#img("img/normal/normal_t_dep.png", "Універсальне відношення T із визначеними залежностями (рисунок виконаний самостійно)")
|
||||
#img(
|
||||
"img/normal/normal_t_dep.png",
|
||||
"Універсальне відношення T із визначеними залежностями (рисунок виконаний самостійно)",
|
||||
)
|
||||
|
||||
#img("img/normal/normal_t12.png", "Універсальні відношення T1 та Т2 (рисунок виконаний самостійно)")
|
||||
|
||||
@ -385,7 +410,10 @@
|
||||
|
||||
Можна помітити, що відношення Т2 та Т3 мають спільне відношення "База пакунку id". Утворимо відношення "Пакунок" та "Роль" виділив з відношень Т2 та Т3 відповідно відношення "База пакунку", залишимо на його місці ключ "База пакунку id".
|
||||
|
||||
#img("img/normal/normal.png", [Відношення "Користувач", "Пакунок", "База пакунку", "Тип ролі" та "Роль" (рисунок виконаний самостійно)])
|
||||
#img(
|
||||
"img/normal/normal.png",
|
||||
[Відношення "Користувач", "Пакунок", "База пакунку", "Тип ролі" та "Роль" (рисунок виконаний самостійно)],
|
||||
)
|
||||
|
||||
Тепер необхідно перевірити отримані відношення на відповідність третій нормальній формі.
|
||||
|
||||
@ -401,16 +429,258 @@
|
||||
= Опис програми
|
||||
#v(-spacing)
|
||||
== Загальні відомості
|
||||
...
|
||||
Для забеспечення простоти, ефективності та елегантності розробки інформаційної системи "Репозиторій пакунків. Колаборація над пакунками" було використано операційну систему Arch Linux@archlinux та текстовий редактор Neovim@neovim.
|
||||
|
||||
Для реалізації всієї комп'ютерної програми було обрано сучасну мову програмування Rust@rust, яка є надзвичайно швидкою, надійною та продуктивною. За зберігання даних відповідає база даних MySQL@mysql, вона відома своєю стабільнітю, можливостями та швидкістю. Для взаємодії з базою даних було обрано бібліотеку SQLx@sqlx, вона є дуже гарно спроектованим проектом, розрахована на асинхроні операції та підтримку багатьох баз даних на низькому рівні. Для написання інтерфейсу комп'ютерної програми було обрано бібліотеку iced@iced, ця бібліотека фокусується на простоті та безпеці програм з графічним інтерфейсом за допомогю дотримання принципів проектування Elm@elm.
|
||||
|
||||
== Виклик і завантаження
|
||||
...
|
||||
Користувач може взаємодіяти з ком'ютерною програмою після встановки її до своєї операційної системи та запуску бази даних.
|
||||
|
||||
Для зберігання даних використовується СУБД MySQL@mysql. База даних та комп'ютерна програма можуть знаходитись на різних пристроях. Перед тим як кінцевий користувач приступить до використання програми, системний адміністратор, котрий відповідає за роботу інформаційної системи, має налаштувати змінну середовища "DATABASE_URL" в котрій буде адреса до налаштованого екземпляру MySQL. Для максимальної зручності налаштування рекомендуєтсья використовувати контейнерізацю за допомогою Docker@docker, особливо рекомендується його інструмент Compose@compose.
|
||||
|
||||
Інформаційна система була розроблена з використанням мови Rust@rust, тому результуюча програма не потребує залежностей під час виконання і може бути використана у вигляді самодостатнього файлу виконання.
|
||||
|
||||
== Призначення і логічна структура
|
||||
...
|
||||
Інформаційна система полегшує колаборацію над пакунками у репозиторії для розробників. Система забеспечує інтуїтивний інтерфейс для навігації по пакункам, їх залежностям з відносинами, та користувачам. Перелік основних функцій системи:
|
||||
- управління пакунками та їх метаданими;
|
||||
- система користувацьких акаунтів;
|
||||
- система різних рівней доступу користувачей до пакунків;
|
||||
- пошу та категоризація пакунків за багатьма факторами;
|
||||
- надання аналітичної інформації про репозиторій, пакунки та користувачів.
|
||||
|
||||
Під час розробки було використано гексагональну архітектуру@hexagonal, також відому як "архітектура портів та адаптерів". Структура проекту складаєтсья з кількох рівнів @project_structure:
|
||||
+ Шар взаємодії з базою даних (тека data):
|
||||
+ декларація інтерфейсу взаємодії (тека ports);
|
||||
+ імплементації взаємодії (тека adapters).
|
||||
+ Шар сервісів для бізенс логіки програми (тека service), cервіси мають:
|
||||
+ декларацію репозиторію який бере дані з задекларованого шару бази даних (файли з назвою repository);
|
||||
+ імплементацію адаптеру репозиторію який оперує отриманням даних з шару імплементації бази даних (файли з назвою adapter);
|
||||
+ декларацію контракту який будується на репозиторії і описує дані з котрими буде працювати сервіс (файли з назвою contract);
|
||||
+ імплеменацію сервісу котрий оперує над даними контракту та здійснює логічні операції з обчисленнями (файли з назвою service).
|
||||
+ Шар графічного інтерфесу (тека src) використовує контракти з шару сервісів для валідації даних від користувача та надсилання запитів до логічної частини застосунку.
|
||||
+ Головний файл проекту (тека src, файл main.rs) відповідає за конпонування всих шарів:
|
||||
+ встановлення підключення до бази даних;
|
||||
+ ініціалізацю адаптерів бази даних;
|
||||
+ ініціалізацію адаптерів репозиторіїв за допомогою створених підключень та адаптерів бази даних;
|
||||
+ запуск сервісів передаючи їм створені репозиторії;
|
||||
+ відображення та менеджмент графічних частин застосунку яким передаються сервіси.
|
||||
|
||||
#img("img/repo/project_structure.png", "Побудована схема даних (рисунок виконаний самостійно)")
|
||||
|
||||
Проєкт має всі використані під час розробки ресурси, такі як SQL скрипти та Compose@compose файли, за допомогою яких можна створити тестову базу даних та наповнити її даними.
|
||||
|
||||
== Опис фізичної моделі бази даних
|
||||
...
|
||||
Для інформаційної системи створено базу даних яка має дев’ять таблиць. Код для її створення яких описаний нижче.
|
||||
|
||||
Таблиця "Users" містить інформацію про користувачів системи та має таку структуру:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- ім'я - унікальне текстове поле яке зберігає ім'я користувача (довжина до 31 символа), не може бути порожнім;
|
||||
- пошта - унікальне текстове поле яке зберігає електронну пошту користувача (довжина до 255 символів), не може бути порожнім;
|
||||
- пароль - текстове поле яке зберігає хеш пароля (довжина до 255 символів), не може бути порожнім;
|
||||
- останній логін - зберігає дату останнього використання облікового запису, може бути порожнім;
|
||||
- час створення - зберігає дату створення облікового запису не може бути порожнім;
|
||||
- час оновлення - час оновлення даних в таблиці, автоматично оновлюється при зміні запису, не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- Required info for an account
|
||||
CREATE TABLE Users (
|
||||
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
name VARCHAR(31) UNIQUE NOT NULL,
|
||||
email VARCHAR(255) UNIQUE NOT NULL,
|
||||
password VARCHAR(255) NOT NULL,
|
||||
|
||||
last_used TIMESTAMP NULL,
|
||||
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
|
||||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
|
||||
);
|
||||
```
|
||||
|
||||
Таблиця "PackageBases" містить інформацію про бази пакунків:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- назва - унікальне текстове поле, зберігає назву базового пакунку (до 127 символів), не може бути порожнім;
|
||||
- опис - текстове поле (до 510 символів), може бути порожнім, зберігає опис пакунку;
|
||||
- час створення - зберігає дату створення бази пакунку, не може бути порожнім;
|
||||
- час оновлення - час оновлення даних в таблиці, автоматично оновлюється при зміні запису, не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- Enables multiple packages to have the same base yet different components
|
||||
CREATE TABLE PackageBases (
|
||||
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
name VARCHAR(127) UNIQUE NOT NULL,
|
||||
description VARCHAR(510) NULL,
|
||||
|
||||
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
Таблиця "PackageBaseRoles" визначає ролі користувачів для роботи з пакунками:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- назва - унікальне текстове поле, зберігає назву ролі (наприклад: submitter, packager; довжина до 31 символу), не може бути порожнім;
|
||||
- опис - текстове поле яке описує роль (до 255 символів), може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- User roles for working on packages: flagger, packager, submitter, maintainer, etc.
|
||||
CREATE TABLE PackageBaseRoles (
|
||||
id TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
name VARCHAR(31) UNIQUE NOT NULL,
|
||||
description VARCHAR(255) NULL
|
||||
);
|
||||
|
||||
INSERT INTO PackageBaseRoles (id, name) VALUES
|
||||
(1, 'submitter'),
|
||||
(2, 'packager'),
|
||||
(3, 'maintainer'),
|
||||
(4, 'flagger');
|
||||
```
|
||||
|
||||
Таблиця "PackageBaseUserRoles" описує ролі користувачів для баз пакунків:
|
||||
- база пакунку - числове поле (ціле додатнє число), зовнішній ключ на таблицю PackageBases;
|
||||
- користувач - числове поле (ціле додатнє число), зовнішній ключ на таблицю Users;
|
||||
- роль - числове поле (ціле додатнє число), зовнішній ключ на таблицю PackageBaseRoles;
|
||||
- коментар - текстове поле для збереження приміток (до 255 символів), може бути порожнім;
|
||||
- (base, user, role) - складний (композитний) первинний ключ, необхідний для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
|
||||
```sql
|
||||
-- Roles that a user has for a package
|
||||
CREATE TABLE PackageBaseUserRoles (
|
||||
base INT UNSIGNED,
|
||||
user INT UNSIGNED,
|
||||
role TINYINT UNSIGNED,
|
||||
|
||||
comment VARCHAR(255) NULL,
|
||||
|
||||
PRIMARY KEY (base, user, role), -- composite key
|
||||
FOREIGN KEY (base) REFERENCES PackageBases(id) ON DELETE CASCADE,
|
||||
FOREIGN KEY (user) REFERENCES Users(id) ON DELETE CASCADE,
|
||||
FOREIGN KEY (role) REFERENCES PackageBaseRoles(id) ON DELETE CASCADE
|
||||
);
|
||||
```
|
||||
|
||||
Таблиця "Packages" містить інформацію про окремі пакунки:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- база - зовнішній ключ (ціле додатнє число) на таблицю PackageBases;
|
||||
- назва - унікальне текстове поле для збереження назви пакунку (до 127 символів), не може бути порожнім;
|
||||
- версія - текстове поле для збереження версії пакунку (до 127 символів), не може бути порожнім;
|
||||
- опис - текстове поле для збереження опису пакунку (до 255 символів), може бути порожнім;
|
||||
- веб-покликання - текстове поле, зберігає посилання на ресурс пакунку (до 510 символів);
|
||||
- час позначення - час, коли пакунок був позначений, може бути порожнім;
|
||||
- час створення - зберігає дату створення пакунку, не може бути порожнім;
|
||||
- час оновлення - час оновлення даних в таблиці, автоматично оновлюється при зміні запису, не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- Information about the actual packages
|
||||
CREATE TABLE Packages (
|
||||
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
base INT UNSIGNED NOT NULL,
|
||||
name VARCHAR(127) UNIQUE NOT NULL,
|
||||
version VARCHAR(127) NOT NULL,
|
||||
description VARCHAR(255) NULL,
|
||||
url VARCHAR(510) NULL,
|
||||
|
||||
flagged_at TIMESTAMP NULL,
|
||||
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
||||
|
||||
FOREIGN KEY (base) REFERENCES PackageBases (id) ON DELETE CASCADE
|
||||
);
|
||||
```
|
||||
|
||||
Таблиця "DependencyTypes" визначає типи залежностей:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- назва - унікальне текстове поле, зберігає назву типу залежності (наприклад: depends, makedepends; довжина до 31 символу), не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- depends, makedepends, optdepends, etc.
|
||||
CREATE TABLE DependencyTypes (
|
||||
id TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
name VARCHAR(31) UNIQUE NOT NULL
|
||||
);
|
||||
|
||||
INSERT INTO DependencyTypes (id, name) VALUES
|
||||
(1, 'depends'),
|
||||
(2, 'makedepends'),
|
||||
(3, 'checkdepends'),
|
||||
(4, 'optdepends');
|
||||
```
|
||||
|
||||
Таблиця "PackageDependencies" відображає залежності пакунків:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- архітектура - текстове поле, зберігає цільову архітектуру залежності (до 63 символів), може бути порожнім;
|
||||
- умова - текстове поле, яке зберігає умову залежності (до 255 символів), може бути порожнім;
|
||||
- опис - текстове поле, зберігає опис залежності (до 127 символів), може бути порожнім;
|
||||
- пакунок - зовнішній ключ на таблицю Packages;
|
||||
- тип залежності - зовнішній ключ на таблицю DependencyTypes;
|
||||
- назва залежного пакунку - текстове поле яке зберігає назва залежного пакунку (до 127 символів), не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- Track which dependencies a package has
|
||||
CREATE TABLE PackageDependencies (
|
||||
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
arch VARCHAR(63) NULL,
|
||||
requirement VARCHAR(255) NULL,
|
||||
description VARCHAR(127) NULL,
|
||||
|
||||
package INT UNSIGNED NOT NULL,
|
||||
dependency_type TINYINT UNSIGNED NOT NULL,
|
||||
dependency_package_name VARCHAR(127) NOT NULL, -- Not an actual package, but an an alias. Allows for package substitution.
|
||||
|
||||
FOREIGN KEY (package) REFERENCES Packages (id) ON DELETE CASCADE,
|
||||
FOREIGN KEY (dependency_type) REFERENCES DependencyTypes (id)
|
||||
);
|
||||
```
|
||||
|
||||
Таблиця "RelationTypes" визначає типи зв'язків між пакунками:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- назва - унікальне текстове поле яке зберігає назву зв'яку (наприклад: conflicts, provides; довжина до 31 символу), не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- conflicts, provides, replaces, etc.
|
||||
CREATE TABLE RelationTypes (
|
||||
id TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
name VARCHAR(31) UNIQUE NOT NULL
|
||||
);
|
||||
|
||||
INSERT INTO RelationTypes (id, name) VALUES
|
||||
(1, 'conflicts'),
|
||||
(2, 'provides'),
|
||||
(3, 'replaces');
|
||||
```
|
||||
|
||||
Таблиця "PackageRelations" описує зв'язки між пакунками:
|
||||
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
|
||||
- архітектура - текстове поле, зберігає цільову архітектуру зв'яку (до 63 символів), може бути порожнім;
|
||||
- умова - текстове поле, яке зберігає умову зв'яку (до 255 символів), може бути порожнім;
|
||||
- пакет - зовнішній ключ на таблицю Packages;
|
||||
- тип зв'язку - зовнішній ключ на таблицю RelationTypes;
|
||||
- тип зв'язку з пакетом - текстове поле, зберігає назву пакунку, з яким є зв'язок (до 127 символів), не може бути порожнім.
|
||||
|
||||
```sql
|
||||
-- Track which conflicts, provides and replaces a package has
|
||||
CREATE TABLE PackageRelations (
|
||||
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
|
||||
arch VARCHAR(63) NULL,
|
||||
requirement VARCHAR(255) NULL,
|
||||
|
||||
package INT UNSIGNED NOT NULL,
|
||||
relation_type TINYINT UNSIGNED NOT NULL,
|
||||
relation_package_name VARCHAR(127) NOT NULL,
|
||||
|
||||
FOREIGN KEY (package) REFERENCES Packages (id) ON DELETE CASCADE,
|
||||
FOREIGN KEY (relation_type) REFERENCES RelationTypes (id)
|
||||
);
|
||||
```
|
||||
|
||||
== Опис програмної реалізації
|
||||
|
||||
|
||||
#img("img/repo/repo_login.png", "Сторінка логіну")
|
||||
|
||||
|
||||
#img("img/repo/repo_login.png", "Сторінка регістрації")
|
||||
|
||||
|
||||
#nheading("Висновки")
|
||||
|
||||
В результаті виконання курсової роботи було розроблено інформаційну систему "Репозиторій пакунків" для організації ефективної колаборації над програмними пакунками. В процесі розробки було проведено ґрунтовний аналіз предметної області, визначено ключові вимоги до системи та спроектовано оптимальну структуру бази даних для зберігання інформації про пакунки, їх версії, залежності, користувачів та їхні ролі.
|
||||
|
||||
Reference in New Issue
Block a user