1.2.2 Переключение между режимами.
Для переключения режимов можно использовать команды в меню Главная/Режим, для быстрой смены режимов служат кнопки в правом нижнем углу окна PowerPoint.
2 Практическая часть
2.1 Постановка задачи
Средствами реляционной СУБД Microsoft Access разработать БД для заданной предметной области, включая пользовательский интерфейс для ввода исходных данных, их анализа и отображения результатов.
Разработать исходные данные контрольного примера, выполнить заполнение и проверку работоспособности БД.
Средствами Microsoft PowerPoint разработать презентацию информационного продукта (индивидуальной базы данных).
Исходные данные:
Предметная область: Сеть ресторанов.
Входная информация: каталог ресторанов , бланк заказа , сведения о посетителях.
Выходная информация: запросы, формы, отчеты по срезам Рестораны, Заказы, Посетители.
Количественные ограничения: БД содержит информацию о 4 ресторанов, о 4 посетителях, и для каждого посетителя не менее 3-х заказов.
2.2 Анализ предметной области
При традиционной организации деятельность жилищного фонда находит свое отражение в таких документах как:
- каталог жилищных фондов, содержащий все необходимые параметры;
- договор на аренду содержит всю информацию о заключенной сделке и сведения об арендаторе;
- карточка арендатора включает подробную информацию об арендаторе.
Ручная обработка всей информации без использования вычислительной техники не может выполняться оперативно, требует значительных временных и трудозатрат. Использование базы данных "Сеть ресторанов" позволит оперативно накапливать, систематизировать и эффективно обрабатывать информацию по различным срезам, формировать отчеты, выявлять слабые звенья в системе заключения договор на аренду и т.д.
2.3 Построение информационно-логической модели предметной области
Целью создания БД "Сеть Ресторанов" является автоматизация учета информации по общественному питанию .
Функции проектируемой БД:
- хранение информации о посетителях;
- хранение информации о заказах ;
- хранение информации о ресторанах;
- обновление и добавление информации;
- анализ информации по различным срезам (рестораны, посетители, заказы);
- выдача итоговой информации в виде отчетов.
На основе анализа первичных документов предметной области можно выделить примерный перечень информации проектируемой БД:
- фамилия, имя, отчество, адрес, дата рождения, телефон посетителей;
- параметры и характеристики ресторана;
-название ресторана;
- меню;
- кухня и количество залов.
На втором этапе проектирования БД выделяют информационные объекты предметной области. Функциональный анализ информации проектируемой БД позволяет выделить следующие информационные объекты: Посетители и Ресторан (рисунок 2).
Рисунок 2 – Информационные объекты предметной области «Заказы»
В соответствии с понятиями реляционной СУБД каждому информационному объекту в проектируемой БД будет соответствовать таблица. На третьем этапе проектирования определяют логическую структуру проектируемой БД (отношения между информационными объектами).
Реальные отношения между информационными объектами являются отношениями "многие–ко-многим". Такие отношения непосредственно не поддерживаются реляционными СУБД. Реальные отношения "многие–ко- многим" разбиваются на отношения "один-ко-многим" после ввода объекта- связки Заказы. Для установления связей каждому объекту назначается ключ (ключевое поле). Причем ключи объектов Посетитель, Ресторан (первичные) должны присутствовать как внешние ключи в объекте Заказы (рисунок 3).
Рисунок 3 – Отношения 1:∞ между информационными объектами
В реляционной модели вышеуказанным информационным объектам соответствуют двумерные таблицы-отношения: Посетитель, Ресторан, Заказ. Логические связи между двумерными таблицами осуществляются при помощи ключевых полей. Важным требованием, предъявляемым к таблицам, является нормализация данных, которая позволяет минимизировать повторение данных.
В третьей нормальной форме устраняются атрибуты, которые зависят от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
С учетом требований к содержанию реляционных таблиц: нормализация по нормальным формам и содержанию информационных систем, получен список полей для каждой таблицы.Структура таблиц после нормализации представлена в таблицах 1-4.
Талица 1 – Структура таблицы «Посетитель» (главная таблица)
№ |
Название |
Тип |
1 |
Код посетителя |
Счетчик, поле первичного ключа |
2 |
Фамилия |
Текстовый |
3 |
Имя |
Текстовый |
4 |
Отчество |
Текстовый |
5 |
Дата рождения |
Дата/время |
6 |
Адрес |
Текстовый |
7 |
Телефон |
Текстовый |
Талица 2 – Структура таблицы «Ресторан» (главная таблица)
№ |
Название |
Тип |
1 |
Код ресторана |
Счетчик, поле первичного ключа |
2 |
Название ресторана |
Текстовой |
3 |
Меню |
Текстовый |
4 |
Кухня |
Текстовый |
5 |
Количество залов |
Числовой |
6 |
Изображение |
Поле объекта OLE |
Талица 3 – Структура таблицы «Заказ» (таблица-связка)
№ |
Название |
Тип |
1 |
Код заказа |
Счётчик, поле первичного ключа |
2 |
Код посетителя |
Числовой, поле внешнего ключа |
3 |
Код ресторана |
Числовой, поле внешнего ключа |
4 |
Дата заказа |
Дата/время |
5 |
Цена |
Денежный |
6 |
Скидка |
Числовой |
7 |
Оплачено |
Логический |