Розробка логічної моделі бази даних “Репозиторый ПЗ”

2.3 Розробка логічної моделі бази даних “Репозиторый ПЗ”

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

В окремі таблиці віднесемо такі сутності як Автор, Дистрибутив, ПЗ. (Модель даних подана на рисунку 6.) У кожній таблиці слід вписати атрибути, які будуть характерні для даної сутності. Кожен атрибут має свій тип, який визначається типом даних, який зберігатиметься у базі даних.Також вкажемо, яким ключем є кожен атрибут. Атрибути, які організують зв”язок між таблицями, є зовнішніми ключами (FK). Кожна сутність повинна мати ключ, який використовується для пошуку – PK – первинний ключ, якщо атрибут є альтернативою для пошуку, то він є альтернативним ключом (AK). Якщо за даним атрибутом можна впорядкувати інформацію, то цей атрибут є індексним ключом.

ПЗ

Назва ПЗ S PK IK1 Версія ПЗ S PK IK1 №розробника N IK FK №дистрибутива N IK FK Дата випуску D Null Ліцензія S ftp-адреса вихідних  файлів ПЗ S AK

Розробник

Ф S AK  IK1 И S AK IK1 О S AK IK1 Адреса S Null №розробника N IK PK

 

ПЗ

 

Дистрибутив

Назва S AK IK1 Версія S AK IK1 ftp-адреса вихідних файлів S №дистрибутива N IK PK

 

Рисунок 4 – Логічна модель бази даних «Репозиторій ПЗ».

2.4 Розробка алгоритмів і графічних інтерфейсів програмних модулів

Алгоритм програми являє собою блок вибору дії та виклик відповідної підпрограми. Нижче наведено блок-схему алгоритма програми.

 Рисунок 5 – Блок-схема основного алгоритма програми ( головна форма)

Рисунок 6 – Алгоритм підпрограми Додати/видалити дистрибутив

Рисунок 7 – Алгоритм підпрограми Додати/видалити автора

 

Рисунок 8 – Алгоритм підпрограми Додати/видалити ПЗ

Рисунок 9 – Алгоритм підпрограми Пошук ПЗ з а датою

Рисунок 10 – Алгоритм підпрограми Пошук ПЗ за назвою

Рисунок 11 – Алгоритм підпрограми Пошук ПЗ за автором

 

Програма складається з двох частин:

бази даних, яку обслуговує сервер MySQL;

клієнтської частини, яка надає графічний інтерфейс, реалізованої в вигляді html форм, що обробляються php.

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

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

Після відкриття має з’являтися меню. За допомогою нього можна буде обрати необхідну операцію, а саме, Додати/видалити дистрибутив, Додати/видалити автора, Додати/видалити ПЗ, Пошук ПЗ за датою, Пошук ПЗ за автором, Пошук ПЗ за назвою, Пошук автора, Звіт. Вище перелічені операції можна обрати за допомогою натискання відповідних кнопок в меню.

Якщо натиснути кнопку “Додати/видалити дистрибутив”, відкриється форма, в якій необхідно буде заповнити наступні поля: Назва, Версія, ftp-адреса. Можна переглянути наявні дистрибутиви та видалити необхідні, вибравши їх та натиснувши кнопку “Видалити дистрибутив”. З кожної підпорядкованої форми перехід до головного меню здійснюється натисканням на посилання “Повернутися на головну сторінку”Аналогічно можна додавати інформацію про нового автора, натиснувши кнопку “Додати/видалити автора” в головному меню. З’явиться форма реєстрації нового автора, до якої треба буде занести ім”я, по-батькові, та прізвише автора, його email-адресу. Також можна переглянути наявних авторів та видалити необхідні, вибравши їх та натиснувши кнопку “Видалити автора”. Для реєстрації програмного забезпечення потрібно буде натиснути на кнопку «Додати/видалити ПЗ» в головному меню, відкриється форма «Додати/видалити ПЗ», до якої необхідно буде занести назву, версію, дату створення, ліцензію та ftp-адресу вихідних файлів програми. Також потрібно обрати автора та дистрибутив із вже наявних у базі даних. Також можна переглянути наявне програмне забезпечення та видалити необхідне, вибравши його та натиснувши кнопку “Видалити ПЗ”.

Ряд форм, які реалізують пошук даних побудовані у вигляді полів введення параметрів пошуку та кнопки “Пошук”. Результати пошуку повертаються у вигляді таблиці.

 

2.5 Розробка фізичної моделі бази даних «Репозиторій ПЗ»

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

Таблиця 3 – фізична модель БД репозиторію програмного забезпечення

Ім’я фізичної моделі	Тип	Формат поля	Ключ в ЛМ	Індек-сація	Обов. поле
Розробник
Номер розробника	Лічильник	Довге ціле	PK	IK1	Так
Прізвище	Текстовий	20	AК	IK2	Так
Ім’я	Текстовий	20	AК	IK2	Так
Побатькові	Текстовий	20	AК	IK2	Так
Адреса елктронної пошти	Текстовий	50			Ні
ПЗ
Назва ПЗ	Текстовий	20	PK	IK1	Так
Версія ПЗ	Текстовий	10	PK	IK1	Так
Номер розробника	Числовий	Довге ціле	FK1		Так
Номер дистрибутива	Числовий	Довге ціле	FK2		Ні
Дата випуску	Дата/час	Короткий формат дати			Ні
Ліцензія	Текстовий	20			Так
ftp-адреса вихідних файлів ПЗ	Текстовий	50	AK		Так
Дистрибутив
Назва	Текстовий	20	AK1	IK2	Так
Версія	Текстовый	20	AК1	IK2	Так
Номер дистрибутиву	Лічилькик	Довге ціле	PK	IK1	Так
ftp-адреса вихідних файлів	Текстовий	50	AK2		Так

На основі побудованої логічної моделі даних репозиторію побудуємо фізичну модель в середовищі MySQL. Створимо таблиці “ПЗ”, “Дистрибутив”, “Розробник” .

Визначення таблиці “Розробник”:

CREATE TABLE rozrobnuk (

first_name varchar(30) NOT NULL default '',

last_name varchar(30) NOT NULL default '',

surname varchar(30) NOT NULL default '',

id int(11) NOT NULL auto_increment,

addr varchar(30) default NULL,

PRIMARY KEY (id),

UNIQUE KEY (first_name,last_name,surname)

) ;

Визначення таблиці “Дистрибутив”:

CREATE TABLE distr (

name varchar(30) NOT NULL default '',

version varchar(30) NOT NULL default '',

id int(11) NOT NULL auto_increment,

addr varchar(30) NOT NULL default '',

PRIMARY KEY (id),

UNIQUE KEY (name,version)

) ;

Визначення таблиці “ПЗ”:

CREATE TABLE PZ (

name varchar(30) NOT NULL default '',

version varchar(10) NOT NULL default '',

dev_id int(11) default 0,

distr_id int(11) default 0,

date date default NULL,

licence varchar(30) default NULL,

addr varchar(30) NOT NULL default '' UNIQUE,

PRIMARY KEY (name,version),

FOREIGN KEY (dev_id) REFERENCES dev(id)

ON DELETE SET NULL

ON UPDATE CASCADE,

FOREIGN KEY (distr_id) REFERENCES distr(id)

ON DELETE SET NULL

ON UPDATE CASCADE

) ;

Додаємо індекси:

CREATE INDEX pib ON dev(first_name,last_name,surname);

CREATE INDEX pzindex1 ON PZ(name,version);

CREATE INDEX distrindex1 ON distr(name,version);

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

Після створення фізичної моделі даних можна зробити наступні висновки:

·                  схема зв’язку фізичної та логічної моделі ідентичні;

·                  в ході роботи була досягнута третя нормальна форма;

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