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

2.3 Розробка логічної моделі бази даних студії веб-дизайну

Логічна модель відображає логічні зв'язки між елементами даних. Вона формулюється в термінах бази даних, але не залежить від конкретної СУБД. На основі концептуальної моделі розробляється логічна модель бази даних (БД). Для кожного атрибута таблиці визначається тип даних, а саме: N - число, S - рядок, D - дата.

Для кожного із ключів також прийняті скорочення: PK - основний ключ, FK - зовнішній ключ.

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

На підставі розробленої раніше діаграми сутностей (ER) складемо логічну модель. Логічна модель отбражает логічні зв'язки між елементами даних. Ці зв'язки зобразимо за допомогою таблиць, для кожної з яких буде зазначений перелік атрибутів і ключів

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

Далі представлена (рисунок 6) логічна модель БД «Студія веб-дизайну», що розроблена засобами Erwin.

Рисунок 6 – Логічна модель бази даних студії веб-дизайну (Erwin)

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

Виходячи с того, що база даних, яка розробляється, спрямована на обслуговування обмеженого за розміром закладу, інформація, яка в ній буде зберігатися має сенс лише для декількох ключових осіб, то не має рації створювати її для широкого серверного використання. Значно краще буде розробити базу на основі стаціонарної платформи, що значно спростило би безпосередню роботу по створенню бази даних,а також принцип роботи кінцевого програмного продукту. Для виконання даної роботи будемо використовувати СУБД Microsoft Access 2000, адже ця платформа є найдоступнішою та найрозповсюдженішою. В Access існує чотири типа модулів: модулі форм, модулі звітів, стандартні модулі і модулі класів. Нам потрібні будуть модулі форм та звітів.

Форма «Меню» представлятиме собою кнопочну форму, яка складатиметься з набору кнопок, що забезпечують доступ до інших форм та функцій програми. Всі кнопки форми „Меню” перелічені нижче (таблиця 3).

Таблиця 3 – Кнопки форми «Меню»

Назва кнопки	Реакція на натиснення кнопки
Услуги	Відкривається форма «Услуга»
Добавить заказчика	Відкривається форма «Заказчик»
Договор	Відкривається форма «Договор»
Отчёты	Відкривається форма «Отчёты»
Добавить исполнителя	Відкривається форма «Исполнитель»

Головна форма має кнопочну структуру, в яку входять таки кнопки:

-послуга;

-договір;

-звіти;

-додати замовника;

-додати виконавця;

Форма «Услуга» має кнопочну структуру, в яку входять такі кнопки:

- пошук послуги за назвою;

- пошук послуги за видом;

- додавання послуги в базу даних студії веб-дизайну;

Перші три кнопки в свою чергу відкривають інші форми.

Кнопка „Поиск услуги по названию” відкриє відповідну форму, в якій буде розміщене поле „Введите название услуги: ”. За даними, що будуть введені в дане поле, буде відбуватися запит, який буде здійснювати пошук послуги в базі за назвою. Після введення параметру та натиснення кнопки „ОК”,, повинна бути відкритися форма „Услуга”, в якій буде виводитися вся інформація про послугу, тобто її характеристика (назва, код послуги, вид, ціна, виконавець, додаткові матеріали), які зазначили, у лінійному вигляді.

В формі „Поиск услуги по виду”, яка з’явиться одразу після натиснення відповідної кнопки, буде розміщено поле „Введите вид услуги:”. За даними, що будуть введені в це поле, буде відбуватися запит, який здійснює пошук послуги в таблиці «Услуга». Після введення параметру для пошуку и натисканні «OK», повинна бути відкритися форма «Услуга», в якій буде виводитися вся інформація про послугу, тобто її характеристика (назва, код послуги, вид, ціна, виконавець, додаткові матеріали), які зазначили, у лінійному вигляді.

Натиснувши кнопку „Добавить услугу”, з’явиться форма „Услуга_доб”, яка має як і лінійчату, так і кнопочну структуру. В цій формі необхідно заповнити поля: код послуги, назва послуги, ціна послуги, вид, виконавець. Заповнення усіх полів обов’язкове. Якщо якесь поле залишеться не заповненим, з’явиться відповідне повідомлення. Після того, як всі поля будуть заповненні, можна буде, за допомогою відповідних кнопок, додавати ще один запис, удалити запис, зберегти та знайти запис.

Форма „Добавить заказчика” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення. В цю інформацію занасяться наступні дані про замовника: ПІБ, код замовника, адреса, телефон, назва фірми.

Форма „Добавить исполнителя” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення. В цю інформацію занасяться наступні дані про виробника: код виконавця, ПІБ, дата народження, адреса, телефон, посада, вид послуги, зарплата.

Форми „Добавить заказчика” та „Добавить исполнителя ” мають кнопки, які дозволяють додати запис, зберегти запис або видалити його.

Форма „Договор” має кнопочну структуру, в яку входять:

-додавання договору;

-пошук договору за період часу;

Форма „Добавить договор”, в яку входять поля зі списком необхідних даних для введення. В цю інформацію заносяться наступні дані про договір: основні положення, даатз аключення, дата виконання, код договору, виконан/не виконан, причина невиконання.

Форм „Отчёт по дате ” має лінійну структуру, в яку входять поля зі списком необхідних даних для введення.Необхідно ввести початкову та кінцеву дати певного періоду та натиснути кнопку „Выполнить запрос”, повинен бути відкритися запит «Запрос по дате», в якому буде виводитися вся інформація про договори у цей період.

- виконання запиту;

Форма „Звіт” містить в собі дві кнопки: „Отчёт о предоставленніх услугах” та „Отчётность студии”.

Натиснувши першу кнопку, відкриється звіт „Отчёт о предоставляеміх услугах”, яка містить в собі код послуги, код виконавця, назва послуги, ціна, кількість, сума.

- друк звіту.

Натиснувши кнопку „Отчётность студії”, на екрані з’явиться звіт прозвітність студії, який містить у собі таку їнформацію:доходи, розрахунок заробітної плати, кількість виконаних договорів.

Окрім всіх вищезазначених кнопок, кожна з форм має також має копку „Закрити форму”, яка має вигляд -.

2.5 Розробка фізичної моделі даних

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

Фізична модель бази даних будується на основі логічної моделі даних.

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

1. Таблиці перебувають в 1-й нормальній формі (НФ) тоді й тільки тоді, коли відсутні однакові картежи й у кожному з осередків будь-якої таблиці втримуються атомарні значення.

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

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

На підставі логічної моделі даних складемо фізичну модель, згідно з особливостями обраної СУБД. Для реалізації завдання по функціонуванню аптеки була обранна СУБД “Access 2003”. База даних зберігається в даної СУБД у вигляді одного файлу з розширенням *.mdb.

Для створення фізичної моделі бази даних приведемо її проектну частину (таблиця 4).

Таблиця 4- Замовник

Атрибут	Тип данных	Размер поля в байтах	Обязательность поля	Ключ
Код заказчика	Счетчик	4	Да	PK
Ф.И.О.	Текстовый	40	Да	FK
Адрес	Текстовый	50	Да	…
Телефон	Текстовый	20	Нет	…
Название фирмы	Текстовый	20	Да	…

Таблиця 5- Послуги

Атрибут	Тип данных	Размер поля в байтах	Обязательность поля	Ключ
Код услуги	Счетчик	4	Да	PK
Вид услуги	Текстовый	20	Нет	…
Название услуги	Текстовый	30	Да	FK2
Код исполнителя	Длинное целое	4	Да	FK1
Цена	Денежный	8	Да	…
Дополнительные материалы	Текстовый	50	Да	…

Таблиця 6- Виконавець

Атрибут	Тип данных	Размер поля в байтах	Обязательность поля	Ключ
Код исполнителя	Счетчик	4	Да	PK
Ф.И.О.	Текстовый	40	Да	…
Дата рождения	Дата/время	8	Нет	…
Адрес	Текстовый	50	Да	…
Телефон	Текстовый	20	Да	…
Должность	Текстовый	30	Да	FK
Вид услуги	Текстовый	30	Да	…
Зарплата	Длинное целое			...

Таблиця 7- Звіт

Атрибут	Тип данных	Размер поля в байтах	Обязательность поля	Ключ
Код услуги	Длинное целое	4	Да	PK FK2
Код исполнителя	Длинное целое	4	Да	PK FK3
Код заказчика	Счетчик	4	Да	PK FK1
Вид услуги	Текстовый	20	Да	…
Название услуги	Текстовый	30	Да	…
Цена	Денежный	8	Да	…
Кол-во	Длинное целое	4	Да	…
Сумма	Денежный	8	Да	…
Код договора	Длинное целое	4	Да	PK FK4

Таблиця 8- Договір

Атрибут	Тип данных	Размер поля в байтах	Обязательность поля	Ключ
Код договора	Счетчик	4	Да	PK
Положения договора	Текстовый	90	Нет	…
Дата заключения	Дата/время	8	Да	AK
Дата выполнения	Дата/время	8	Да	…
Выполнение/не выполнение	Текстовый	15	Да	…
Причина невыполнения	Текстовый	40	Да	…

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

Проведемо аналіз нормалізації побудованої БД. Всі таблиці БД перебувають у третій нормальній формі (НФ). Цієї НФ досить, щоб забезпечити в даній базі високий ступінь цілісності.

При аналізі бази дані аномалії виявлені не були.

На підставі фізичної моделі складемо базу даних у середовищі Microsoft Office Access версії 2003 (рисунок 7).

Рисунок 7 – Фізична модель даних, реалізована в середовищі Microsoft Office Access версії 2003.