Добавлен: 03.12.2023
Просмотров: 390
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Опишем детально предназначение каждой сущности и ее атрибутов.
Сущность «Страны».
Отвечает за хранение перечня стран мира, в которые совершаются туристические туры. Важным атрибутом этой сущности является «Название страны».
Сущность «Города».
Отвечает за хранение перечня городов, в которые совершаются туристические туры. Важными атрибутами этой сущности являются:
-
Название города; -
Название страны, которой принадлежит город.
Атрибут сущности «Название страны» имеет связь «один-ко-многим» с сущностью «Страны».
Сущность «Виды транспорта».
Отвечает за хранение перечня видов транспорта, которым туристы доставляются от транспортных развязок к отелям. Важным атрибутом этой сущности является «Название транспорта».
Сущность «Туристы».
Отвечает за хранение перечня туристов, которые совершили туристические туры. Важными атрибутами этой сущности являются:
-
ФИО туриста; -
Возраст.
Сущность «Отели».
Отвечает за хранение перечня отелей, которые принимают туристов на отдых. Важными атрибутами этой сущности являются:
-
Название отеля; -
Класс обслуживания; -
Суточная плата за проживание в отеле; -
Название города, где размещен отель.
Атрибут сущности «Название города» имеет связь «один-ко-многим» с сущностью «Города».
Сущность «Туры».
Отвечает за хранение перечня туров в отелях, с указанием продолжительности заезда. Важными атрибутами этой сущности являются:
-
Название тура; -
Продолжительность; -
Описание; -
Вид транспорта для доставки туристов в отель.
Атрибут сущности «Вид транспорта» имеет связь «один-ко-многим» с сущностью « Виды транспорта».
Сущность «Путевки».
Основная сущность информационной системы, хранящая информацию о распределении туристов по отелям и заездам. Важными атрибутами этой сущности являются:
-
Дата вылета на отдых; -
Тур; -
Отель; -
Турист.
Атрибут сущности «Тур» имеет связь «один-ко-многим» с сущностью «Туры».
Атрибут сущности «Отель» имеет связь «один-ко-многим» с сущностью «Отели».
Атрибут сущности «Турист» имеет связь «один-ко-многим» с сущностью «Туристы».
Построенная ER-модель в графической нотации «Crow's Foot» представлена на рис. 3.
Рис. 3. ER-модель информационной системы
Таким образом, при помощи модели «сущность-связь» на высоком уровне проанализирована предметная область, выявлены её важнейшие сущности, а также их атрибуты и характер взаимосвязей. Результат представлен в соответствующей графической нотации.
3. ПРЕОБРАЗОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ В РЕЛЯЦИОННУЮ
Дальнейшим шагом нашей работы будет построение логической модели хранения данных на основании концептуального проектирования. Модель данных есть формальная теория, определяющая фундаментальные свойства хранения и обработки данных. Классическими примерами моделей данных являются иерархическая, сетевая, реляционная и объектная. Главенствующей на текущий момент моделью данных является реляционная. Исторически она пришла на смену иерархической и сетевой моделям в широком использовании, начиная примерно с 1970-х годов. Превосходствами этой модели являются отчетливая и простая логическая структура, сильная теоретическая база, помощь целостности данных, существование широкого спектра добротных языковых и программных средств. Значимой составляющей реляционной модели является теория типичных форм. Типичные формы представляют собой определенные состояния взаимоотношений, характеризующие их избыточность. Существуют типичные формы от первой до шестой включительно, с некоторыми промежуточными состояниями, не которые имеют номера. Всякая последующая типичная форма дополняет требования к предыдущей. Процесс приведения реляционной базы данных в соответствие с типичными формами именуется нормализацией. Данный процесс является рекомендуемым этапом при проектировании структур реляционных баз данных. Использование нормализации разрешает исключить избыточность, возвести отчетливую и логичную связь данных, заложить фундамент их целостности. На исходном этапе довольной глубиной нормализации считается доведение до третьей типичной формы включительно. Исходя из фактических соображений, на последующих этапах проектирования и реализации допустима дальнейшая нормализация либо деморализация. Первая нормальная форма требует, чтобы каждый атрибут каждого кортежа содержал единственное значение. Данное требование выполняется в реляционной модели всегда по определению.
Вторая нормальная форма требует неприводимой зависимости каждого неключевого атрибута от потенциального ключа отношения. На практике это означает, что в отношениях с составным ключом все неключевые атрибуты должны зависеть от каждого атрибута составного ключа. Также данное требование вносит ограничение на существование независимых от потенциального ключа неключевых атрибутов.
Третья нормальная форма требует отсутствия транзитивной зависимости неключевых атрибутов от потенциального ключа. На практике при существовании таких транзитивных зависимостей для достижения третьей нормальной формы необходимо разбивать одно отношение на несколько с отсутствием таких зависимостей.
Создадим все необходимые ключевые атрибуты, определим отношения между ними. После выполнения работ по преобразованию концептуальной модели в логическую получим следующую структуру логических сущностей.
Сущность «Страны» (табл. 1).
Таблица 1
Структура сущности «Страны»
Название атрибута | Ключ | Обязательное |
Код страны | Главный | Да |
Название страны | | Да |
Сущность «Города» (табл. 2).
Таблица 2
Структура сущности «Города»
Название атрибута | Ключ | Обязательное |
Код города | Главный | Да |
Код страны | Внешний | Да |
Название города | | Да |
Поле «Код страны» сущности «Города» ссылается на перечень значений «Код страны» сущности «Страны»
Сущность «Виды транспорта» (табл. 3).
Таблица 3
Структура сущности «Виды транспорта»
Название атрибута | Ключ | Обязательное |
Код вида транспорта | Главный | Да |
Название вида транспорта | | Да |
Сущность «Туристы» (табл. 4).
Таблица 4
Структура сущности «Туристы»
Название атрибута | Ключ | Обязательное |
Код туриста | Главный | Да |
ФИО туриста | | Да |
Возраст туриста | | Да |
Сущность «Туры» (табл. 5).
Таблица 5
Структура сущности «Туры»
Название атрибута | Ключ | Обязательное |
Код тура | Главный | Да |
Название тура | | Да |
Продолжительность | | Да |
Описание | | Нет |
Код вида транспорта | Внешний | Да |
Поле «Код вида транспорта» сущности «Туры» ссылается на перечень значений «Код вида транспорта» сущности «Вида транспорта»
Сущность «Отели» (табл. 6).
Таблица 6
Структура сущности «Отели»
Название атрибута | Ключ | Обязательное |
Код отеля | Главный | Да |
Название отеля | | Да |
Класс обслуживания | | Нет |
Суточная плата за проживание | | Да |
Код города | Внешний | Да |
Поле «Код города» сущности «Отели» ссылается на перечень значений «Код города» сущности «Города».
Сущность «Путевки» (табл. 7).
Таблица 7
Структура сущности «Путевки»
Название атрибута | Ключ | Обязательное |
Код путевки | Главный | Да |
Дата вылета на отдых | | Да |
Код тура | Внешний | Да |
Код отеля | Внешний | Да |
Код туриста | Внешний | Да |
Поле «Код тура» сущности «Путевки» ссылается на перечень значений «Код тура» сущности «Туры».
Поле «Код отеля» сущности «Путевки» ссылается на перечень значений «Код отеля» сущности «Отели».
Поле «Код туриста» сущности «Путевки» ссылается на перечень значений «Код туриста» сущности «Туристы».
При помощи инструмента моделирования Sybase Power Designer создадим реляционную модель информационной системы (рис. 4).
Рис. 4. Реляционная модель информационной системы
На этой модели присутствуют обозначения:
-
- главный ключ; -
- внешний ключ; -
null/not null – обязательное/ не обязательное поле.
ЗАКЛЮЧЕНИЕ
В курсовой работе была разработана база данных, разрешающая автоматизировать активность туристического агентства в процессе подбора служб и учёта заказчиков в туристической фирме, то есть автоматизировать основные функционирования администратора по туризму. Разработанная база данных поможет снизить вероятность недостоверной информации о наличии туров, повысить качество и скорость сервиса путешественников. В процессе реализации работы были изучены теоретические аспекты рассматриваемой темы, была дана оценка предметной области. При проектировании базы данных были реализованы: Концептуальная модель информационной системы; Реляционная модель базы данных; Сделанная база данных была наполнена тестовым комплектом данных. При этом было зафиксировано непротиворечивость внесенных данных, их достаточность, отсутствие избыточности.