Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Гостиница1 / титульник1.doc
Скачиваний:
109
Добавлен:
01.05.2014
Размер:
1 Mб
Скачать
    1. Разработка окончательной структуры базы данных

Исходя из ER-диаграмм предметной области, правил теории баз данных [4,6] и общих соображений по эффективной организации систем следует, что нужно создать следующие сущности и связи:

  • “Клиент”-“Номер”: Для создания отношений по бинарной связи “один – ко – многим”, если класс принадлежности n – связной сущности является обязательным, требуется сформировать 2 отношения: по одному для каждой сущности (таблицы “Клиент” и “Номер”) с первичным ключом, соответствующим сущности. Используется правило 4.

  • “Номер”-“Этаж”: Для создания отношений по бинарной связи “один – ко – многим”, если класс принадлежности n – связной сущности является обязательным, требуется сформировать 2 отношения: по одному для каждой сущности (таблицы “Этаж” и “Номер”) с первичным ключом, соответствующим сущности. Используется правило 4.

  • “Этаж”-“Служащий”: Для создания отношений по бинарной связи “многие – ко – многим” требуется сформировать 3 отношения: по одному для каждой сущности (таблицы “Служащий” и “Этаж”) и одно для связи. Используется правило 6.

Следовательно нам понадобятся следующие сущности:

1)Клиент(фио , № паспорта , город прибытия , дата поселения , номер где клиент остановился)

2)Номер(идентификатор[номер] номера , количество жилых мест номера , № этажа , количество проживающих в номере, цена номера)

3)Этаж(№этажа)

4)Служащий(ФИО служащего , дата приема на работу)

И одно отношение для связи сущностей “Служащий” и “Этаж”(см. далее)

Анализ основных связей и их модификация:

Для сущности “Клиент” все необходимее атрибуты уже выписаны и единственная возможная связь сущности “Клиент” - это связь “Клиент-Номер” по ключевому полю номер(ROOM). В целях уменьшения занимаемого объему ОЗУ и места на жестком диске вынесем атрибут “стоимость номера” из сущности “Номер” в отдельную таблицу состоящую из двух полей – “Стоимость номера” и “Количество мест в номере”. Эта новая сущность “Стоимость номера” связана с сущностью “Номер” по атрибуту “Количество мест в номере” и служит для сопоставления стоимости номера количеству его мест. Для возможности получения информации о том, кто из служащих убирал номер указанного клиента в заданный день недели, необходимо реализовать связь м-у сущностями “Номер” и “Этаж” , т.к. служащие убирают не номера а этажи целиком и нам необходима информация на каком этаже какой номер находится. Для этого добавим к сущности “Номер” новый атрибут “Этаж”(FLOUR) и установим связь м-у сущностями “Номер” и “Этаж” по этому атрибуту. Для того чтобы все-таки точно узнать кто из кто из служащих убирал номер указанного клиента в заданный день недели надо установить связь м-у сущностями “Служащий” и “Этаж”. После реализации ER-диаграмм(см. Приложение 1) установлено , что эта связь должна содержать 3 отношения результатом чего становится дополнительная таблица состоящая из полей “День недели” , “Этаж” и “ФИО служащего” которая служит для связи сущностей “Служащий” и “Этаж” и определяет в какой день недели должен работать служащий.

К атрибутам сущности “Служащий” добавим атрибут ID_служащего , который будет служить для связи сущностей “Служащий” и “Этаж” , чтобы избежать возможной избыточности.

Окончательно сущности будут выглядеть следующим образом:

Соседние файлы в папке Гостиница1