Проект базы данных ресторана

 

 

 

 

СОДЕРЖАНИЕ

 

Введение

1 Описание предметной области                                                                               8

2 Инфологическое проектирование                                                                         9 

  2.1 Определение, формулировка и описание сущностей                        9

  2.2 Спецификация атрибутов                                                                                  9

  2.3 Выбор идентифицирующих атрибутов                                                            10

  2.4 Спецификация связей «Сущность-сущность»                                                11

  2.5 Диаграммы  связей «Атрибут-атрибут»                                                           13

  2.6 Список задач, решаемых пользователем                                                         13

  2.7 Концептуальная инфологическая модель                                                        13

3 Логическое проектирование                                                                                  14

  3.1 Проектирование реляционной логической модели БД                                  14

  3.2 Установление дополнительных логических связей                                        14

  3.3 Отображение концептуальной логической модели на реляционную           15

  3.4 Нормализация отношений                                                                                 22

        3.4.1 Приведение отношений к первой нормальной форме                          22

        3.4.2 Приведение отношений ко второй нормальной форме                        23

        3.4.3 Приведение отношений к третьей нормальной форме                         26

4 Физическое проектирование                                                                                  27

5 Программное и техническое  обеспечения                                                            28

  5.1 Обоснование выбора СУБД                                                                              28

  5.2 Системные требования                                                                                      28

6 Руководство пользователя                                                                                      30

Заключение                                                                                                                 35

Библиографический список                                                                                      36

Приложение А. Исследование предметной области                                             37

Приложение Б. Спецификация атрибутов каждой сущности                              38

Приложение В. Определение связей типа «Атрибут - атрибут»                           41

Приложение Г. Справочник задач, решаемых пользователем                              44

Приложение Д. Итоговая концептуально-инфологическая модель                      45

Приложение Е. Матрица частоты совместного использования                            46

Приложение Ж. Логическая модель, полученная с помощью пакета ERWin     47

Приложение З. Физическое представление атрибутов отношений                      48

Приложение И. Физическая модель, полученная с помощью пакета ERWin     53

 

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И  СОКРАЩЕНИЯ

 

В данной курсовой работе использованы следующие сокращения:

БД          база данных

ЭВМ      электронные вычислительные машины

РФ          Российская Федерация

НФ        нормальная форма

СУБД     система управления базами  данных

 

ВВЕДЕНИЕ

 

Как всем известно, в настоящее  время обработка и хранение информации являются важнейшими задачами для предприятия любого типа. Поэтому для оперативного, гибкого, эффективного управления и внедряются различные БД, ведь при большом объеме информации и сложности производимых с ней операций проблема эффективности и быстродействия средств организации хранения, доступа и обработки данных приобретает особое значение.

При осуществлении своей  деятельности ресторан русской кухни «Матрешка» ежедневно сталкивается с большими объемами информации, которые нуждаются в обработке. Исходя из этого, возникает потребность в профессионально-сделанной, эффективно работающей базе данных, которая сможет упростить работу операторов, управляющего коллектива  и всего предприятия в целом.

Как уже отмечалось выше, основой разрабатываемой системы стала база данных, содержащая информацию о ежедневной работе предприятия. Предполагается, что она позволит сократить время на обработку больших объемов информации, поступающей как из вне (сведения о клиентах, оформление заказов, учет поставок), так и «вращающейся» внутри самого предприятия (начисление заработной платы, премии, данные о сотрудниках и т.д.), обеспечить быстрый доступ к данным, особенно тем, которые чаще всего используются.

Таким образом, спроектированная информационная система сможет обеспечить своевременное формирование отчетов по соответствующим запросам для предоставления не только сотрудникам, но и клиентам (например, вывод чеков), а также обеспечить учет входящей и исходящей информации, необходимой для работы данного предприятия.

 

 

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

 

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

Основные данные о предприятии  представлены в таблице А.1.

Как уже упоминалось, предприятие  ещё не успело разрастись, и поэтому  об отделах как таковых речи быть не может.

 

 

2 ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

 

На этапе инфологического проектирования БД разработчик должен определить, из каких должна состоять будущая база, какие данные нужно поместить в каждую таблицу и как связать полученные таблицы, т.е.определяются состав реляционных таблиц, их структура и межтабличные связи.

2.1 Определение, формулировка и описание сущностей

В результате проведения анализа рассмотренной предметной области представляется возможность определить весь набор сущностей, необходимых для удовлетворения требований к системе. Перечислим эти сущности:

• «Сотрудники» – данная сущность содержит полную информацию о сотрудниках ресторана «Матрёшка».
• «Клиенты» – данная сущность содержит информацию о посетителях ресторана.
• «Меню» – эта сущность содержит полный перечень блюд, предоставленных на выбор посетителям.
• «Заказы» – с помощью этой сущности ведётся учёт обо всех заказах, имевших место в рассматриваемом ресторане.
• «Ингредиенты» – данная сущность отражает информацию обо всех ингредиентах, входящих в состав предлагаемых блюд.
• «Поставка» – сущность содержит информацию о продуктах, поставляемых на кухню.
• «Поставщик» – данная сущность содержит информацию о фирмах, поставляющих свою продукцию.
• «Зарплата» – данная сущность содержит полную информацию о начислении заработной платы сотрудникам.
• «Скидка» – данная сущность содержит информацию скидках, которые предоставляются клиентам.

2.2 Спецификация атрибутов

В ходе анализа  данных сущностей были выделены следующие  атрибуты, представленные в таблицах Б.1 – Б.9.

2.3 Выбор идентифицирующих атрибутов

Для каждой сущности укажем идентификатор, который необходим для однозначного распознавания ее экземпляра. Атрибут или совокупность из нескольких атрибутов (составной идентификатор), значения которых уникально идентифицируют каждый экземпляр сущности, называются ключом.

• «Сотрудники»

Под экземпляром сущности «Сотрудники», понимается сотрудник ресторана, которого нельзя однозначно идентифицировать при  помощи  ФИО, должности, даты рождения, дата найма или их комбинации. Поэтому, для идентификации сотрудника вводится атрибут «Код сотрудника», являющийся ключевым.

• «Клиенты»

Ни один из атрибутов сущности не является ключевым, так как однозначно не определял экземпляр сущности. Поэтому ввели новый атрибут  «Код клиента», являющийся уникальным для каждого экземпляра, то есть, назначаем атрибут «Код клиента» ключевым.

• «Меню»

Для данной сущности выбран составной  ключ, состоящий из атрибутов «Код блюда» и «Код ингредиента».

• «Ингредиент»

Для данной сущности определен идентифицирующий атрибут «Код ингредиента» (уникальная комбинация цифр, присваиваемая каждому ингредиенту в отдельности).

• «Заказы»

«Код заказа» и «Код блюда»–  ключевые атрибуты, так как остальные  атрибуты не могут идентифицировать сущность «Заказы» среди других сущностей, а данные атрибуты представляют собой уникальный комбинацию чисел.

• «Поставка»

Под экземпляром сущности «Поставка» понимается запись о поставке какого-либо продукта. Значение атрибута «Код поставки»  будет уникальным для каждого  экземпляра данной сущности, поэтому  его будем считать первичным  ключом.

• «Поставщик»

Экземпляр рассматриваемой сущности – некая фирма, поставляющая свою продукцию в ресторан. Атрибут «Код поставщика» присваивается персонально каждому поставщику, а, следовательно, будет являться идентифицирующим.

• «Зарплата»

Экземпляром рассматриваемой сущности является запись о выплате тому или  иному сотруднику заработанной платы  за некоторый месяц. Атрибут «Код выплаты» – ключевой.

• «Скидки»

Данная сущность отражает все скидки, которые действуют в ресторане. Ее наименование и значение не являются уникальными. Для этого введен дополнительный атрибут «Код скидки», который сможет идентифицировать данную сущность среди остальных.

2.4 Спецификация связей «Сущность - Сущность»

Установим зависимости между двумя сущностями. Опишем типы взаимосвязей объектов предметной области, которые определяются из их отношений.

1 Связь «Скидка – Клиенты»

В данном случае имеем связь «один–ко–многим», так как одной скидкой могут пользоваться несколько клиентов, а один клиент может пользоваться только одной скидкой

2 Связь «Клиенты – Заказы»

Сущности соединены связью «один–ко–многим»: один клиент может сделать много  заказов, но один заказ может быть сделан только одним клиентом.

3 Связь «Заказы – Меню»

В данном случае имеем связь «многие–ко–многим», потому что в состав одного заказа может входить несколько блюд, в то же время одно блюдо может быть заказано несколькими клиентами.

4 Связь «Меню – Ингредиенты»

Рассматриваемые сущности соединены  связью «многие–ко–многим», так как  один ингредиент может входить в состав нескольких блюд, а одно блюдо может состоять из нескольких ингредиентов.

5 Связь «Ингредиент – Поставка»

Так как один ингредиент может поставляться сколь угодно большое число раз, а в состав каждой поставки входит лишь один ингредиент, то установим между рассматриваемыми сущностями связь «один–ко–многим»

6 Связь «Поставщик – Поставка»

В данном случае имеем связь «один–ко–многим», т.к. каждому поставщику соответствует несколько поставок, а каждой поставке соответствует только один поставщик.

 

7 Связь «Сотрудники – Заказы»

Сущности соединяет связь типа «один–ко–многим», потому что один заказ может обслуживать только один сотрудник, но один сотрудник принять несколько заказов.

8   Связь «Сотрудники»–«Зарплата»

Сотрудники получают зарплату ежемесячно, каждая выплата предназначена одному сотруднику. Следовательно, сущности «Сотрудники» и «Зарплата» соединены связью «один–ко–многим».

2.5 Диаграммы связей «Атрибут - атрибут»

На данном этапе определим связи  типа «атрибут-атрибут», которые представляют собой отношение между атрибутами одной и той же сущности.

Связи типа «Атрибут-атрибут» представлены в приложении В.

2.6 Список задач, решаемых пользователем

При исследовании предметной области и выше полученных данных были выделены следующие задачи, которые будет решать проектируемая база данных. Все задачи представлены в таблице Г.1, в которой также приведены данные о частоте решения задач и используемых при этом сущностях.