Главная Обратная связь

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)






Построение информационно-логической модели предметной области



 

Целью создания БД "Сеть Ресторанов" является автоматизация учета информации по общественному питанию .

Функции проектируемой БД:

- хранение информации о посетителях;

- хранение информации о заказах ;

- хранение информации о ресторанах;

- обновление и добавление информации;

- анализ информации по различным срезам (рестораны, посетители, заказы);

- выдача итоговой информации в виде отчетов.

На основе анализа первичных документов предметной области можно выделить примерный перечень информации проектируемой БД:

- фамилия, имя, отчество, адрес, дата рождения, телефон посетителей;

- параметры и характеристики ресторана;

-название ресторана;

- меню;

- кухня и количество залов.

На втором этапе проектирования БД выделяют информационные объекты предметной области. Функциональный анализ информации проектируемой БД позволяет выделить следующие информационные объекты: Посетители и Ресторан (рисунок 2).

 

Рисунок 2 – Информационные объекты предметной области «Заказы»

 

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

Реальные отношения между информационными объектами являются отношениями "многие–ко-многим". Такие отношения непосредственно не поддерживаются реляционными СУБД. Реальные отношения "многие–ко- многим" разбиваются на отношения "один-ко-многим" после ввода объекта- связки Заказы. Для установления связей каждому объекту назначается ключ (ключевое поле). Причем ключи объектов Посетитель, Ресторан (первичные) должны присутствовать как внешние ключи в объекте Заказы (рисунок 3).

 

 

Рисунок 3 – Отношения 1:∞ между информационными объектами

 

В реляционной модели вышеуказанным информационным объектам соответствуют двумерные таблицы-отношения: Посетитель, Ресторан, Заказ. Логические связи между двумерными таблицами осуществляются при помощи ключевых полей. Важным требованием, предъявляемым к таблицам, является нормализация данных, которая позволяет минимизировать повторение данных.

В третьей нормальной форме устраняются атрибуты, которые зависят от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.



С учетом требований к содержанию реляционных таблиц: нормализация по нормальным формам и содержанию информационных систем, получен список полей для каждой таблицы.Структура таблиц после нормализации представлена в таблицах 1-4.

 

Талица 1 – Структура таблицы «Посетитель» (главная таблица)

 

 

Название Тип
Код посетителя Счетчик, поле первичного ключа
Фамилия Текстовый
Имя Текстовый
Отчество Текстовый
Дата рождения Дата/время
Адрес Текстовый
Телефон Текстовый

 

Талица 2 – Структура таблицы «Ресторан» (главная таблица)

 

 

Название Тип
Код ресторана Счетчик, поле первичного ключа
Название ресторана Текстовой
Меню Текстовый
Кухня Текстовый
Количество залов Числовой
Изображение Поле объекта OLE

 

 

Талица 3 – Структура таблицы «Заказ» (таблица-связка)

 

Название Тип
Код заказа Счётчик, поле первичного ключа
Код посетителя Числовой, поле внешнего ключа
Код ресторана Числовой, поле внешнего ключа
Дата заказа Дата/время
Цена Денежный
Скидка Числовой
Оплачено Логический

 


Эта страница нарушает авторские права

allrefrs.ru - 2019 год. Все права принадлежат их авторам!