|
|
@@ -0,0 +1,50 @@
|
|
|
+# Модуль № 1: Проектирование и разработка информационных систем
|
|
|
+
|
|
|
+## Задание
|
|
|
+
|
|
|
+На основании _описания брифинга_ и _документов, представленных заказчиком_, необходимо _спроектировать ER-диаграмму_ для информационной системы. Обязательна **3 нормальная форма** с обеспечением ссылочной целостности. При разработке диаграммы обратите внимание на согласованную осмысленную схему именования, создайте необходимые первичные и внешние ключи. ER - диаграмма должна быть представлена в формате .pdf и содержать таблицы, связи между ними, атрибуты и ключи.
|
|
|
+
|
|
|
+Необходимые приложения: [Текст брифинга.pdf](./Текст%20брифинга.pdf), [Документы заказчика](./Документы%20заказчика/)
|
|
|
+
|
|
|
+>Приложения в каталоге `data` этого репозитория
|
|
|
+
|
|
|
+## Реализация
|
|
|
+
|
|
|
+>В файле [Задание модуль_1 Диаграмма.pdf](../solution/Задание%20модуль_1%20Диаграмма.pdf) есть разбор этого задания от другого преподавателя. В целом там нормально, но есть несколько огрехов. **Во-первых**, пользователи и клиенты разделены в разные сущности. В принципе можно сделать и так, тут надо смотреть исходные данные для импорта. **Во-вторых**, не реализована сущность **задачи** (заявки). **В-третьих**, часть информации о бронировании (дата заезда и выезда) почему-то записана клиенту, хотя её место в заказе.
|
|
|
+
|
|
|
+Внимательно читаем "текст бриффинга" и выделяем сущности:
|
|
|
+
|
|
|
+>Заказчик: Предполагается, что приложением будет пользоваться **руководитель** и **сотрудник** гостиницы, а так же некоторые функции будут доступны **клиенту** и **гостям**.
|
|
|
+
|
|
|
+Все роли можно объединить в одну сущность (Пользователь)
|
|
|
+
|
|
|
+- **User**
|
|
|
+- **Role**
|
|
|
+
|
|
|
+>Заказчик: Администратор гостиницы должен иметь полный доступ к **информации о бронированиях** и заселении гостей. Возможность управлять **номерным фондом** и назначать свободные номера, оперативно взаимодействовать с другими отделами гостиницы для решения **вопросов гостей**, проведения финансовых операций, таких как прием платежей и выставление счетов. Работать с клиентами с учетом их пожеланий и предпочтений.
|
|
|
+
|
|
|
+- **Booking** - бронь
|
|
|
+- **Room** - номерной фонд
|
|
|
+
|
|
|
+>Заказчик: При регистрации гостей администратор гостиницы производит поиск
|
|
|
+бронирования или создание нового бронирования номера для гостя. При регистрации
|
|
|
+администратор вводит данные гостя и другую информацию, выбирает нужный **типа номера**, проверяет доступность и назначает номера гостю. Далее администратор регистрирует оплату и оформление документов (например, квитанции или счета) на проживание.
|
|
|
+
|
|
|
+- **RoomType** - категория номера
|
|
|
+
|
|
|
+>После регистрации администратор предоставляет информацию о доступных услугах и
|
|
|
+удобствах гостиницы. Активирует карту доступа к номеру и передает ее гостю. При
|
|
|
+оформлении заезда гостей в номер, **номер приобретает статус** «Занят».
|
|
|
+
|
|
|
+- **RoomStatus** - статус номера
|
|
|
+- **RoomFloor** - этаж (есть в данных о номерном фонде), в соответствии с требованием ссылочной целостности (если сделать просто целым числом, то можно ввести 9999 этаж по ошибке)
|
|
|
+
|
|
|
+>Администратор создает график уборки номеров на определенный период времени
|
|
|
+(неделя, месяц), распределяет уборочный персонал на различные номера и **задачи** в соответствии с заявками от гостей или по расписанию, отслеживает выполнение уборочных работ, формирует отчетность о выполненных работах и статистику по уборке номеров.
|
|
|
+
|
|
|
+- **Task** - задачи
|
|
|
+- **TaskType** - тип задачи (уборка, вызов сантехника, электрика и т.п.)
|
|
|
+
|
|
|
+В итоге должна получиться примерно такая диаграмма ([файл в формате .mwb](./erd.mwb)):
|
|
|
+
|
|
|
+
|
