Пример проектирования базы данных «Гостиница" Irina Kisseljova 2010 a. irinak@nvtc.ee. - презентация

1 Пример проектирования базы данных «Гостиница" Irina Kisseljova 2010 a.

2 Назначение и предметная область. Анализ предметной области База данных создаётся для информационного обслуживания администраторов гостиницы. База данных предназначена для хранения данных о постояльцах гостиницы, о бронированных местах, предложения гостиницы и предоставлять возможность получать разнообразные отчёты. Задача – информационная поддержка деятельности гостиницы.

3 Функции БД должна осуществлять следующие функции: ведение списка постояльцев; учёт забронированных мест; учёт получаемых услуг

4 Особенности системы В соответствии с предметной областью система строится с учётом следующих особенностей: – Каждый номер сдается постояльцу в рамках договора; – Договор подписывается одним администратором гостиницы во время прибытия постояльца; – Один номер могут занять несколько постояльцев; – Клиент может посещать гостиницу несколько раз (по разным договорам); – Клиент может заказать несколько услуг(завтрак в номер); – Каждая договор оформляется на одного заказчика или на фирму; – При бронирование может быть перечислено несколько номеров; – Расторжение договора происходит после выселения постояльца из номера и оплаты счета. – Договор при желание постояльца можно продлён.

5 Пользователи Система создаётся для обслуживания следующих групп пользователей: – Администраторы гостиницы – Клиенты

6 Границы Определим границы информационной поддержки пользователей: Функциональные возможности: – ведение БД (запись, чтение, модификация, удаление в архив); – обеспечение логической непротиворечивости БД; – обеспечение защиты данных от несанкционированного или случайного доступа (определение прав доступа); – реализация наиболее часто встречающихся запросов в готовом виде; – предоставление возможности сформировать произвольный запрос на языке манипулирования данными.

7 Границы(2) Готовые запросы: – получение списка всех текущих договоров – получение полной информации о конкретном постояльце – получение полной информации о конкретных услугах – получение полной информации о конкретном номере – получение списка услуг каждого постояльца – получение статистики

8 Базовые сущности Выделим базовые сущности этой предметной области: – Клиенты – Номера – Договоры Добавим дочерную сущность этой предметной области: – Услуги

9 Бизнес-правила Каждый клиент имеет один или несколько договоров Каждый договор принадлежать только одному клиенту Клиент может проживать в одном или нескольких номерах В каждый номере проживает один или несколько постояльцев В каждом договоре указываем одну или несколько услуг. Каждая услуга может быть указана в одном или несколько договорах

10 ER–диаграмма КЛИЕНТЫ ДОГОВОРА УСЛУГИ НОМЕРА M M M M 1 M

11 Нормализуем В процессе нормализации уменьшаем избыточность информации в базе данных и избавляемся от нежелательных связей между сущностями. Связь «М:М» разбиваем с помощью промежуточной таблицы на два отношения «1:М» Бронирование будем рассматривать как связь между клиентом и номером Пользование услугами будем рассматривать как связь между договором и услугой

12 Бизнес-правила Каждый клиент подписывает один или несколько договоров Каждый договор принадлежать только одному клиенту Клиент может заказать забронировать один или несколько номеров Каждый номер бронируется на одного или несколько постояльцев В каждом договоре указывается пользование одной или несколькими услугами Каждая выбранная услуга принадлежит только одному договору Каждая услуга может быть выбрана один или несколько раз Каждый выбор услуги принадлежать только одной услуги Каждый договор оформляется на один или несколько забронированных номеров Каждая бронь указывается только в одном договоре

13 ER–диаграмма 1 1 Клиент Договор Бронирование Номер 2 3 Пользование услугами Услуги

14 ОбъектыДействиеОбъект 1 Клиент Договор Подписывается один или много Подписывается только одим договоров клиентом 2 Клиент Бронь Регистрирует одну или несколько Принадлежит только одному броней клиенту 3 Договор Бронь Прописывается одну или несколько Указывается только в одном броней договоре 4 Номер Бронь Регистрируется в одной или нескольких Офорляется только на один бронях номер 5 Договор Выбранные услуги Указывается одна или несколько Принадлежат только одному выбранных услуг договору 6Услуга Выбор услуги выбирается один или несколько раз Указывает только на одну услугу

15 Преобразование ER–диаграммы в схему базы данных Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы БД). Обозначения, используемые на схеме базы данных

16 Схема РБД Часть схема РБД, полученная из ER– диаграммы издательской компании

17 Семантика объектов и атрибутов Содержание поляИмя поляТип, длинаПримечания Личный кодIsikukoodText(11) (varChar)PK ИмяFirst_nameText(50) (varChar)обязательное поле ФамилияLast_nameText(50) (varChar)обязательное поле ГородTownText(50) (varChar)обязательное поле АдресAadressText(100) (varChar)обязательное поле ТелефонTelephoneText(50) (varChar) Э-почта Text(100) (varChar) Паспортные данные Passport_nrText(8) (varChar)обязательное поле PK - Первичный ключ FK -Внешний ключ Таблица «client» - Клиенты

18 Определение дополнительных ограничений целостности Личный код – 1 символ может быть только 3,4,5 или 6. – 4-5 символ должен быть меньше 13, но больше 0. – 6-7 символ должен быть меньше 32, но больше 0. Паспортные данные – 1 символ обязательная буква (A-Z)

19 Семантика объектов и атрибутов PK - Первичный ключ FK -Внешний ключ Таблица «contract» - Контракты Содержание поляИмя поляТип, длинаПримечания Код контрактаID_contract Number (Autonumber) PK Код клиентаID_clientText(11)FK (т. «Клиенты») Статус договораStatusText()обязательное поле СуммаSummaNumber (BigInt)обязательное поле Дата заключенияDate_startDate/Timeобязательное поле Дата подписания DateDate/Time Дата расторжения Date_endDate/Time

20 Определение дополнительных ограничений целостности Код контракта – 1-4 символ = текущему году(полный формат) – 5-8 символ = порядковый номер договора Статус договора – Область значений атрибута В процессе подписания Подписан Расторгнут

21 Структура базы данных

22 Физическое проектирование БД Не привязывать к конкретной СУБД и выполняем описание логической схемы БД на SQL Отношение contract (договоры): CREATE TABLE contract ( ID_contract INT NOT NULL primary key, ID_client VARCHAR( 11 ) NOT NULL, Status VARCHAR( 50 ) NOT NULL, Summa BIGINT NOT NULL, Date_start DATE NOT NULL, Date DATE NULL, Date_end DATE NULL )

23 Готовые запросы Получение списка всех текущих договоров SELECT ID_contract FROM contract WHERE Date_end is NULL Получение полной информации о конкретном номере SELECT * FROM room WHERE ID_room='207'

24 Выбор средств реализации В первую очередь при выборе СУБД необходимо принимать во внимание следующие факторы: – максимальное число пользователей одновременно обращающихся к базе; – характеристики клиентского ПО; – аппаратные компоненты сервера; – серверную операционную систему; – уровень квалификации персонала.

25 Анализ СУБД

26 Вывод Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД. Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными. Проанализировав, представленные выше СУБД, автор остановил свой выбор на свободной объектно- реляционной системе управления базами данных MySQL, учитывая, в первую очередь, фактор того, что данная СУБД является свободной и многопользовательской.

27 Составитель : Ирина Киселёва Спасибо за внимание!