Разработка базы данных для ресторана

 

 

 

 

 

 

Сущность «Ингредиенты» описывается атрибутами: «Табельный номер»,  «Название», «Цена за», «Вес». (Таблица 3.1.5)

Таблица 3.1.5

Атрибут	Смысловое значение	Тип
Табельный_номер	Табельный номер ингридиента	Счетчик
Блюдо	Название ингидиента	Текстовый
Цена_за	Цена за вес	Денежный
Вес	Вес	Текстовый

 

Сущность «Состав» описывается атрибутами: «Код состава», «Код блюда», «Название ингредиента», «Необходимое количество», «Вес», «Табельный номер». (Таблица 3.1.6)

Таблица 3.1.6

Атрибут	Смысловое значение	Тип
Код_состава	Код состава блюда	Счетчик
Код_Блюда	Код блюда	Числовой
Название_ингредиента	Название ингредиента	Текстовый
Необходимое количество	Необходимое количество в  штуках	Числовой
Вес в граммах	Необходимый вес ингредиента	Числовой
Табельный_номер	Табельный номер ингредиента	Числовой
Необходимая стоимость	Стоимость необходимого веса ингредиента	Денежный

 

 

 

 

 

 

 

 

 

 

 

- Связи:

Связь представляет взаимодействие между сущностями. (Рисунок 3.1.1)

 

 

 

 

 

 

 

 

Рисунок 3.1.1

 

3.2 Нормализация базы данных

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

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

Поскольку все отношения  имеют  простые ключи, то они автоматически  находятся во 2 нормальной форме.

Поскольку во всех отношениях не имеют  места транзитивные зависимости, то они находятся в 3 нормальной форме. Например, отношение «Блюда» находится в 3 нормальной форме т.к. все его не ключевые поля: «Блюдо», «Код_раздела», «Стоимость блюда»  полностью зависят от ключевого атрибута «Код_блюда». Аналогично для всех других отношений.

Таким образом, отношения  находятся в 3 нормальной форме

ER - диаграмма разработанной базы данных имеет следующий вид. На диаграмме сущность представляется прямоугольником, в котором указано ее имя; атрибуты представляются овалами с указанием их имен, связь изображается ромбом, который соединяет сущности, участвующие в связи.  (Рисунок 3.2.1)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 3.2.1

 

 

 

3.3 Даталогическое проектирование  базы данных

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

Создаваемая база данных будет  содержать следующие таблицы: «Блюда» (Таблица 3.3.1), «Заказ» (Таблица 3.3.2), «Ингредиенты» (Таблица 3.3.3), «Приложение к заказу» (Таблица 3.3.4), «Раздел» (Таблица 3.3.5), «Состав» (Таблица 3.3.6).

Таблица 3.3.1

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Код_Блюда	Счетчик		NOT NULL	+		Первичный ключ
Блюдо	Строка	255				Название книги
Код_раздела	Число		NOT NULL		+	Код автора
Стоимость блюда	Денежный					Издательство книги

 

Таблица 3.3.2

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Код_заказа	Счетчик		NOT NULL	+		Первичный ключ
Номер столика	Текст	255				ФИО автора книги

 

 

 

Таблица 3.3.3

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Табельный_ номер	Счетчик		NOT NULL	+		Первичный ключ
Название ингредиента	Текст	255				Имя читателя
Цена за	Денежный					Контактные данные
Вес	Текст	255				Заметки о читателе

 

Таблица 3.3.4

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Код_приложения	Счетчик		NOT NULL	+		Код читателя
Код_заказа	Число		NOT NULL		+	Код книги
Код_блюда	Число		NOT NULL		+	Дата взятия книгу
Блюдо	Текст	255				Дата возврата книги
Количество порций	Число

 

Таблица 3.3.5

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Код_раздела	Счетчик		NOT NULL	+		Код читателя
Раздел	Текст	255	NOT NULL			Код книги

 

 

 

 

Таблица 3.3.6

Наименование поля	Тип данных	Длина	Допустимое значение	Первичный ключ	Внешний ключ	Описание
Код_состава	Счетчик		NOT NULL	+		Код читателя
Код_блюда	Число		NOT NULL		+	Код книги
Название_ингредиента	Текст	255				Дата взятия книгу
Необходимое_количество	Число					Дата возврата книги
Вес в граммах	Число
Табельный номер	Число				+
Необходимая стоимость	Денеж-ный

 

 

3.4 Формирование условий  целостности базы данных

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

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

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

Ограничения целостности  сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности  сущности достаточно гарантировать  отсутствие в любом отношении  кортежей с одним и тем же значением  первичного ключа. С целостностью по ссылкам дела обстоят несколько  более сложно.

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

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

 

 

 

 

 

 

4. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ

4.1 Выбор СУБД и реализация  базы данных

Для разработки информационной системы «Ресторан «Беллини»  необходимо было определиться с программным  обеспечением, то есть с выбором  СУБД для реализации базы данных. В  качестве кандидатов СУБД были рассмотрены  такие как: MS Excel, MS Access 2007, MS SQL, MySQL, Oracle. Данные СУБД рассматривались по ряду параметров:

- размер базы данных;

- цена;

- тип продукта;

- защита данных;

- сложность настройки,  установки и поддержки.

 

 Исходя из анализа  данных о различных СУБД и  учитывая решаемую задачу, для  реализации базы данных «Ресторан  «Беллини» выбирается СУБД MS Access 2007. 

Microsoft Access – это СУБД предназначенная для хранения и поиска информации, ее представления в удобном виде. Чтобы реализовать базу данных, в СУБД Access надо ввести через режим конструктора свою модель. Для начала надо ввести названия таблиц и все их атрибуты. При вводе атрибутов надо задать тип данных и первичный ключ.  Для таблицы «Блюда» поле «Код_раздела» создаем через подстановку из таблицы «Раздел». Для таблицы «Приложение к заказу» поле «Код_блюда», «Блюдо» создаем через подстановку таблицы «Блюда», а поле «Код_заказа» через подстановку таблицы «Заказ». Для таблицы «Состав» поле «Код_блюда» создаем через подстановку таблицы «Блюда», а поле «Название_ингредиента» и «Табельный_номер»  через подстановку таблицы «Ингредиенты».