ибутів сутностей.
. Приведення моделі до необхідному рівню нормальної форми.
. Перехід до фізичного опису моделі: призначення відповідностей - ім'я сутності - ім'я таблиці, атрибут сутності - атрибут таблиці, завдання тригерів, процедур і обмежень.
У розглянутої предметної області виділені наступні сутності:
? користувач;
? тур;
? заявка;
? турист.
У таблиці 6 показана перша нормальна форма, що характеризує ці сутності.
Таблиця 6 - Перша нормальна форма моделі БД
СущностьАтрібутТіп даннихПрімечаніе ПользователіІдентіфікаціонний номер пользователяintegerNOT NULLЛогінvarcharNOT NULLПарольhashNOT NULLФаміліяvarcharІмяvarcharОтчествоvarchar
Таблиця 7 - Продовження
ПользователіТелефон домашнійvarcharТелефон рабочійvarcharТелефон сотовийvarcharE-mailvarcharNOT NULLТурІдентіфікаціонний номер тураintegerNOT NULLСтранаvarcharNOT NULLКурортvarcharNOT NULLОтельvarcharNOT NULLУровень обслужіваніяintegerNOT NULL Діапазон 1-5Кол-во человекintegerNOT NULLЦенаrealNOT NULLДата вилетаdateNOT NULLДата прілетаdateNOT NULLТуроператорvarcharПаспортние дані для путівки Ідентифікаційний номер турістаintegerNOT NULLФамілія в паспорті РФvarcharІмя в паспорті РФvarcharОтчество паспорті РФvarcharСерія паспорта РФvarcharНомер паспорта РФintegerДата видачі паспорта РФdateФамілія в закордонний. паспортеvarcharІмя в закордонний. паспортеvarcharОтчество в закордонний. паспортеvarcharСерія загран. паспортаintegerНомер загран. паспортаintegerДата видачі загран. паспортаdateДата рожденіяdateКсерокопія 2-3 стор. паспорта РФmemoКсерокопія прописки з паспорта РФmemoКсерокопія 2-3 стор. загран. паспортаmemoЗаявкаІдентіфікаціонний номер заявкіintegerNOT NULLСостояніеvarcharNOT NULL
Малюнок 12 - Друга нормальна форма моделі БД
Наведемо модель до другої нормальної форми, не повинно бути частковою функціональної залежності неключових атрибутів від ключа (залежність неключових атрибутів від частини ключа). На малюнку 12 показана перша нормальна форма моделі БД.
Наведемо всі відносини до третьої нормальної форми, т. е. позбудемося транзитивних залежностей. Для створення нормально функціонуючої БД достатньо, щоб відносини в ній знаходилися в третій нормальній формі.
Логічна модель розроблюваної технології представлена ??на малюнку 13.
Малюнок 13 - Логічна модель даних розроблюваної технології
При переході до фізичної моделі системи необхідно:
1. Позначити імена атрибутів сутностей так, як названі стовпці
таблиць розроблюваної бази даних.
2. Саманта тип атрибутів.
3. Ввести обмеження NotNull на необхідні атрибути.
Побудуємо таблицю з відповідністю типів даних в логічної моделі мережевої технології з використовуваними типами даних в СУБД MySQL.
Таблиця 6 - Співвідношення типів даних
Тип даннихЛогіческая модельMySQLЦелочісленнийintegerintСімвольнийVarchar () Varchar () Дата і времяDateDatetime
Фізична модель мережевої технології реєстрації заявок представлена ??на малюнку 14.
Малюнок 14 - Фізична модель даних розроблюваної технології
2.2 Розробка моделі управління системою
Після створення і реалізації моделі БД, необхідно розробити і реалізувати користувача частину мережевої технології, що дозволяє зручно і наочно вводити дані, проводити їх обробку, редагування і вибір в БД.
Необхідно розробити структуру інтерфейсу ІС, що дозволяє швидко і максимально зручно знаходити користувачеві мережевої технології цікавлять його дані, коректувати і обробляти їх.
Виділимо форми інформаційної системи. Головною формою при запуску додатка є форма «Авторизація користувача», що перевіряє ім'я і пароль користувача. Після перевірки правильності введеного імені і пароля АІС дозволяє доступ до форм відповідні типу користувача. Структура управління мережевою технологією для турагента і клієнта представлена ??на малюнках 15 і 16.
Малюнок 15 - Структура інтерфейсу мережевої технології для турагента
2.3 Розробка графічних форм інтерфейсу користувача
Згідно з розробленим інтерфейсу необхідно розробити такі форми:
. Форма авторизації.
. Форма реєстрації.
