Материал: Автоматизация учета клиентов туристического агентства (на примере ООО "Актив-тур")
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
47
Между сущностями могут быть связи – бинарные ассоциации,
указывающие, как сущности взаимодействуют или сравниваются между
собой. Связь может быть между двумя разными сущностями или между одной
и той же сущностью (рекурсия). Она отражает, как связаны экземпляры
сущностей друг с другом. При этом если есть связь между двумя сущностями,
то она отражает взаимосвязь между экземплярами той и другой сущности.
Связи можно разделить на три типа по множественности:
• Связь один-ко-одному (1:1) показывает, что экземпляр первой
сущности связан с одним экземпляром второй сущности;
• Связь один-ко-многим (1:М) показывает, что один экземпляр
первой сущности, расположенный слева по связи, связывается с несколькими
экземплярами второй сущности, расположенными с правой стороны по связи;
• Связь «многие-ко-многим» (М:М) показывает, что несколько
экземпляров первой сущности связываются с несколькими экземплярами
второй сущности. Между двумя сущностями можно задать множество связей
с разными смысловыми нагрузками.
Связь любого из этих типов будет обязательной, если в данной связи
участвует каждый экземпляр сущности, и вовсе не обязательной – если не
каждый экземпляр сущности участвует в данной связи. При этом связь будет
обязательной с одной стороны и необязательной, с другой стороны.
Наглядное изображение логической модели возможно табличным
способом, когда каждому типу записи соответствует таблица с множеством
полей записи, как показано на рисунке 8.
48
Договора
PK iddog
idkldog
datedog
kolvodog
nomdog
idproddog
Туры
PK idprod
nameprod
art
edizmpr
selfst
optst
rozst
primP
udalPr
FK1 iddog
FK2 idKlient
FK3 idsotr
FK3 idhot
FK3 idstr
Должности
PK iddolg
namedolg
udald
Клиенты
PK idKlient
namekl
krnamekl
adresskl
uradrkl
banrekKl
kontlizoKl
tlfKl
emailKl
dateregKl
udalKl
FK1 idPR
FK2 iddog
Сотрудники
PK idsotr
name
dolg
login
parol
dates
surname
datebor
udal
FK1 iddolg
Заказы
PK idPR
datePP
idklpr
idprodpr
kolvopr
Платежи
PK idpl
idklpl
nomdogpl
datepl
summa
FK1 idKlient
Страна
PK idstr
namestr
visa
uslvisa
stoliza
valuta
Hotel
PK idhot
namehot
star
tip
beach
reit
adress
tele
Рис. 7 Логическая модель базы данных
Назначение таблиц представлено в таблице 15.
Таблица 5 - Назначение таблиц базы данных
№ пп
Наименование
Назначение
1.
Клиенты
Хранит данные о клиентах
2.
Туры
Хранит данные о турах
3.
Платежи
Хранит данные о платежах
4.
Заказы
Хранит данные о заказах
49
5.
Договоры
Хранит данные о договорах
6.
Сотрудник
Хранит данные о сотрудниках
7.
Должности
Хранит данные о должностях
8.
Отели
Хранит информацию об отелях
9.
Страны
Хранит информацию о странах
Описание каждой таблицы базы данных с учетом особенностей
выбранного средства реализации базы данных приведено ниже.
Таблица 6 - Структура таблицы «Клиенты»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код клиента
idKlient
int(11)
Ключевое,
автозаполнение
2.
Фамилия
namekl
varchar(45)
3.
Имя и отчество
krnamekl
varchar(45)
4.
Адрес
adresskl
varchar(45)
5.
Образование
uradrkl
varchar(45)
6.
Данные паспорта
banrekKl
varchar(45)
7.
Семейное положение
kontlizoKl
varchar(45)
8.
Сведения о членах
семьи
semja
text
9.
Телефон
tlfKl
varchar(45)
10.
Адрес электронной
почты
emailKl
varchar(45)
11.
Дата регистрации
dateregKl
timestamp
12.
Отметка об удалении
udalKl
int(1)
Таблица 7 - Структура таблицы «Платежи»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код платежа
idpl
int(11)
Ключевое,
автозаполнение
2.
Код клиента
idklpl
int(11)
3.
Номер договора
nomdogpl
varchar(10)
4.
Дата платежа
datepl
varchar(30)
5.
Сумма
summa
varchar(10)
Таблица 8 - Структура таблицы «Должности»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код должности
idd
int(11)
Ключевое,
автозаполнение
2.
Наименование
должности
namedolg
varchar(45)
50
Таблица 9 - Структура таблицы «Сотрудники»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код сотрудника
idsotr
int(11)
Ключевое,
автозаполнение
2.
Фамилия
name
varchar(45)
3.
Логин
login
varchar(45)
4.
Пароль
parol
varchar(45)
5.
Дата регистрации
dates
varchar(45)
6.
Имя и отчество
surname
varchar(45)
7.
Дата рождения
datebor
varchar(45)
8.
Отметка об удалении
udal
int(1)
Таблица 10 - Структура таблицы «Договора»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код договора
iddog
int(11)
Ключевое,
автозаполнение
2.
Код клиента
idkldog
int(11)
3.
Дата договора
datedog
varchar(45)
4.
Количество дней
kolvodog
varchar(10)
5.
Номер договора
nomdog
varchar(10)
6.
Код тура
idproddog
int(11)
Таблица 11 - Структура таблицы «Заказы»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код записи
idPR
int(11)
Ключевое,
автозаполнение
2.
Дата
datePP
varchar(25)
3.
Код клиента
idklpr
int(11)
4.
Код тура
idprodpr
int(11)
5.
Количество дней
kolvopr
varchar(45)
Таблица 12 - Структура таблицы «Туры»
№
Наименование поля
Идентификатор
Тип
Примечание
1.
Код продукции
idprod
int(11)
Ключевое,
автозаполнение
2.
Наименование
nameprod
varchar(45)
3.
Страна
art
varchar(45)
4.
Количество
дней/ночей
edizmpr
varchar(45)
5.
Курорт/отель
selfst
varchar(45)
6.
Питание
optst
varchar(45)
7.
Стоимость за сутки
rozst
varchar(45)
8.
Описание
primP
text
51
9.
Отметка об удалении
udalPr
int(1)
Физическая модель баз данных представлена на рисунке 98.
Рисунок 8 - Физическая модель базы данных
3.3 Описание требований к интерфейсу
Любой сайт состоит из фронт-энда, то есть части, которая обращена к
его пользователю, и бек-энда – части сайта, которую использует его
администраторы. И если при разработке сайта к внешнему виду бек-енда
обычно не предъявляется суровых требований, то фронт-энд просто обязан
быть максимально удобным для пользователя[11].
Источник: https://baza.diplomsite.ru/previewfile/1438