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

Автор работы: Пользователь скрыл имя, 03 Апреля 2013 в 05:56, курсовая работа

Описание работы

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

Содержание работы

Введение
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
Библиографический список

Файлы: 1 файл

курсач.doc

— 2.62 Мб (Скачать файл)

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

Завершающей частью этапа инфологического  проектирования является построение итоговой концептуально-инфологической модели, графическое представление которой показано в приложении Д.

На данной модели представлены все сущности исследованной предметной области и определены  связи между ними.

 

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

 

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

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

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

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

Для получения реляционной логической модели базы данных необходимо:

  1. выполнить анализ полученной на предыдущем этапе концептуально-инфологической модели, чтобы установить дополнительные логические связи;
  2. отобразить полученную модель на реляционную путём совместного представления в ее отношениях ключевых элементов взаимосвязанных сущностей;
  3. выполнить анализ полученных отношений на соответствие их требованиям трех нормальных форм;
  4. представить полученную реляционную логическую модель.

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

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

Между сущностями исходной концептуально-инфологической модели устанавливаются дополнительные логические связи, если:

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

На первом этапе введения дополнительных логических связей рассчитаем матрицу R - матрицу суммарной частоты совместного использования сущностей модели при решении задач пользователя, которая представлена в таблице Е.1.

На втором этапе нам  необходимо рассчитать среднее значение матрицы R по формуле (1):

 

,                                                                                            (1)

где max(ri,j) и min(i,j) – соответственно максимальное и минимальное значение в матрице R, причем i и j изменяются в пределах от 1 до n, где n – число сущностей модели.

 

Подставив данные, взятые из таблицы 1, получим:

 

,                                                                                                         (2)

 

Теперь, для определения объема лишнего чтения, заполним таблицу  Е.2, в которой указана размерность массивов базы данных.

На третьем этапе определим  по матрице R сущности, для которых значение частоты совместного использования в модели больше либо равно среднему значению, полученному в формуле (2). Такими сущностями являются «Сотрудник» и «Расписание». У них частота совместного использования больше средней, но между этими сущностями уже установлена непосредственная логическая связь, и, следовательно, вопрос об установлении дополнительных логических связях исчерпан.

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

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

Существует общее правило  для отображения модели: ключ порожденной  сущности добавляется в исходную. Выполним отображения для каждой пары сущностей.

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

Между ними установлена связь типа "один-ко-многим". Поскольку простая связь исходит от сущности "Зарплата", то согласно правилу отображения концептуальной модели на реляционную, получаем следующие отношения.

Сущность «Сотрудник» - порожденная сущность

код сотрудника

фамилия

имя

отчество

дата рождения

адрес

№ телефона

должность

дата найма

дата увольнения


 

Сущность «Зарплата» - исходная сущность

код выплаты

код сотрудника

дата выплаты

месяц

оплата

количество часов


 

Результат отображения на реляционную модель:

Отношение 1 («Сотрудник»)

код сотрудника

фамилия

имя

отчество

дата рождения

адрес

№ телефона

должность

дата найма

дата увольнения


 

Отношение 2 («Зарплата»)

код выплаты

код сотрудника

дата выплаты

месяц

оплата

количество часов


 

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

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

Между данными сущностями существует связь типа "один-ко-многим", в роли исходной сущности выступает "Заказы". В последней уже есть ключ порожденной сущности, следовательно, отношения будут аналогичные сущностям.

Сущность «Сотрудник» - порожденная сущность

код сотрудника

фамилия

имя

отчество

дата рождения

адрес

№ телефона

должность

дата найма

дата увольнения


 

Сущность «Заказы» - исходная сущность

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

Результат отображения на реляционную  модель:

Отношение 3 («Сотрудник»)

код сотрудника

фамилия

имя

отчество

дата рождения

адрес

№ телефона

должность

дата найма

дата увольнения


 

Отношение 4 («Заказы»)

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

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

Между сущностями установлена связь  типа "один-ко-многим", причём в  качестве исходной сущности выступает сущность "Клиенты", которая уже содержит ключ порожденной сущности «Код скидки».

Сущность «Скидка» – порожденная сущность

код скидки

наименование

значение


 

Сущность «Клиент» – исходная сущность

код клиента

фамилия

имя

отчество

№ телефона

код скидки


 

Результат отображения на реляционную  модель:

Отношение 5 («Скидка»)

код скидки

наименование

значение


 

Отношение 6 («Клиент»)

код клиента

фамилия

имя

отчество

№ телефона

код скидки


 

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

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

Сущность «Клиент» – порожденная сущность

код клиента

фамилия

имя

отчество

№ телефона

код скидки


 

Сущность «Заказы» – исходная сущность

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

Результат отображения на реляционную  модель:

Отношение 7 («Сотрудник»)

код клиента

фамилия

имя

отчество

№ телефона

код скидки


 

Отношение 8 («Заказы»)

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

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

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

 

 

 

 

Сущность «Заказы»

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

Сущность «Меню»

код блюда

код ингредиента

наименование

цена


 

Результат отображения на реляционную  модель:

Отношение 9 («Заказы»)

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество


 

Отношение 10 («Заказы_Меню»)

код заказа

код блюда

код ингредиента


 

Отношение 11 («Меню»)

код блюда

код ингредиента

наименование

цена


 

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

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

Сущность «Меню»

код блюда

код ингредиента

наименование

цена


 

Сущность «Ингредиент»

код ингредиента

наименование

значение


 

Результат отображения на реляционную  модель:

Отношение 12 («Меню»)

код блюда

код ингредиента

наименование

цена


 

Отношение 13 («Меню_Состав»)

код ингредиента

код блюда


 

Отношение 14 (Ингредиент)

код скидки

наименование

значение


 

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

Сущности «Ингредиент» и «Поставка» соединены связью «один-ко-многим». Исходной в данном случае является сущность «Поставка».

Сущность «Ингредиент» - порожденная сущность

код ингредиента

наименование

значение

Информация о работе Проект базы данных ресторана