Проектирование базы данных «Ресторан»

Оглавление Введение

1.Проектирование баз данных

1.1 Этапы и основные принципы проектирования баз данных

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

2.1 Модель «Сущность — Связь» (ERD)

2.2 Структурный подход при разработке инфологической модели

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

3.Выбор СУБД

3.1 Классификация и сравнительная характеристика СУБД

3.2 Требования к СУБД

4.Даталогическая (реляционная) модель БД

5.Обеспечение целостности данных

5.1 Типы ограничений целостности

6.Описание программного средства

6.1 Таблицы

6.2 Запросы

6.3 Формы БД

6.4 Отчеты в базе данных «Ресторан»

Заключение

• Список использованной литературы

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

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

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

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

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

Очевидны неоспоримые преимущества автоматизированного ресторана перед другими подобными заведениями:

· высокое качество сервиса и скорость обслуживания клиентов;

· абсолютный контроль всех процессов от момента приема заказа до его исполнения;

Специализированный комплекс программного обеспечения и оборудования для автоматизации ресторанов на порядок расширяет возможности управления ресторанным бизнесом:

· автоматизация позволяет внедрять маркетинговые и учетные политики нового поколения и всегда иметь достоверную информацию о работе заведения;

· четко зафиксировав обязанности и ответственность персонала, можно предотвратить злоупотребления со стороны сотрудников, свести к минимуму роль человеческого фактора в управлении;

· благодаря системе автоматизации ресторана появляется возможность исключить трудоемкие операции по учету, обеспечить гибкое управление политикой скидок и бонусов;

· становится возможным вести непрерывный мониторинг работы всех структур заведения, анализировать и прогнозировать результаты деятельности ресторана.

Таким образом, в результате автоматизации предприятия ресторатор имеет возможность постоянно повышать конкурентоспособность, рентабельность своего бизнеса.

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

1.Проектирование баз данных

1.1 Этапы и основные принципы проектирования баз данных

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

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

· Должности;

· Сотрудники;

· Заказ;

· Меню;

· Склад.

Рисунок 1 — Системный анализ предметной области Затем составляется инфологическая концептуальная модель в соответствии с требованиями пользователей. Описывается информация, требуемая каждому конкретному пользователю, то есть запросы к базе данных. Формируются описания внешних инфологических моделей, их взаимная увязка с инфологической концептуальной моделью. Полученные описания отражают составляющие предметной области, связи между ними. Эти описания не должны зависеть от методов представления данных и от конкретной СУБД. Концептуальная инфологическая модель должна обеспечивать прочную и долговременную работу всей системы, выдерживать замену одной СУБД на другую.

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

Системный анализ предметной области

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

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

Все объекты баз данных имеют свои атрибуты, например, у объекта сотрудники будут такие атрибуты как: код сотрудника, должность, ФИО, адрес, телефон и др., где атрибут код должности является ключевым, по которому в дальнейшем будет реализована связь.

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

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

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

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т. д. Наиболее популярной из них оказалась модель «сущность-связь». В инфологическом подходе выделяются: Сущность (Объект) — это то, о чем должна накапливаться информация в системе. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Типом сущности иди объектным множеством.

Конкретизация. Объектное множество, являющееся подмножеством другого объектного множества.

Обобщение. Объектное множество, являющееся надмножеством другого объектного множества (содержащее его).

Объекты могут быть атомарными или составными, причем объект может в одном приложении быть атомарным, а в другом — составным. Для составного объекта должны быть определены его внутренние составляющие. Каждый объект в определенный момент времени характеризуется определенным состоянием. Это состояние описывается с помощью набора свойств и связей с другими объектами. Свойства объекта могут не зависеть от его связей (отношений) с другими объектами. Такие свойства называются локальными. Свойства, которые зависят от связей с другими объектами, называются реляционными. Связь (отношение) между объектами в зависимости от числа входящих в нее объектов характеризуется мощностью. Мощность — это максимальное количество элементов одного объектного множества, связанных с одним элементом другого объектного множества. Некоторые отношения не имеют конкретного значения максимальной мощности, тогда мощность обозначают *, т. е. «много».

2.1 Модель «Сущность — Связь» (ERD)

Это модель предметной области, которая используется на этапе инфологического проектирования. Нотация ERD была впервые введена П. Ченом (Chen). Модель использует три основных элемента: сущность, атрибут и связь. Сущность — это абстракция какого-либо объекта, процесса или явления реального мира, о котором нужно хранить информацию. В качестве сущности могут выступать материальные и нематериальные объекты. Тип сущности определяет набор однородных объектов, а экземпляр сущности — конкретный объект в наборе. Каждый тип сущности обладает одним или несколькими атрибутами. Каждому типу сущности должно быть дано уникальное имя. К одному и тому же имени должна всегда применяться одна и та же интерпретация.

Для идентификации конкретных экземпляров сущностей используются атрибуты — идентификаторы (один или несколько), которые позволяют однозначно отличать один экземпляр сущности от другого. Каждая сущность может обладать любым количеством связей с другими сущностями модели. Атрибут — это поименованная характеристика сущности, которая принимает значения из некоторого множества значений. Например, для сущности ДОЛЖНОСТИ атрибутами являются Наименование должности, Код должности, Требования и т. п. Чтобы задать атрибут в модели, необходимо присвоить ему наименование, привести смысловое описание атрибута, определить множество его допустимых значений и указать, для чего он используется. Основное назначение атрибута — описание свойства сущности, а также идентификация экземпляров сущности. Атрибут можно использовать и как связь — это тоже признак сущности. Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т. е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа). Первичный ключ — набор атрибутов, значения которого однозначно определяют экземпляр сущности. Внешний ключ — это набор атрибутов, используемый для представления связей между сущностями. Связи — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это средство, с помощью которого представляются отношения между сущностями, имеющие место в предметной области. Связи может даваться имя, выражаемое грамматическим оборотом глагола. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными.

Связи могут быть между двумя (бинарные), тремя (тернарные) и более сущностями. Чаще всего используются бинарные. Они классифицируются следующим образом: Связь «один — к — одному» (отображение 1: 1). Когда каждому экземпляру сущности, А соответствует один и только один экземпляр сущности Б, и наоборот. Связь двунаправленная. Связь «один — ко — многим» (отображение 1: М). Это такой тип связи, когда каждому экземпляру сущности, А может соответствовать ни одного, один или несколько экземпляров сущности Б, однако каждому экземпляру сущности Б соответствует один и только один экземпляр сущности А. Связь «многие — к — одному» (отображение М: 1). Это отображение обратно предыдущему. Связь «многие — ко — многим» (отображение М: N). Это такой тип связи, при котором каждому экземпляру сущности, А может соответствовать ни одного, один или несколько экземпляров сущности Б, и наоборот.

В нашей базе данных используются связи «один — ко — многим» и «многие — к — одному» (отображение М: 1), например такие как Должности <=>> Сотрудники, где на одной должности могут находится разные люди одновременно, Заказ <<=> Меню, где одно из одного и того же меню можно сделать заказ блюда неоднократно и т. д.

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

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

— сущности — прямоугольниками;

— атрибуты — овалами, соединяя их с соответствующими сущностями ненаправленными ребрами; идентифицирующие атрибуты подчеркиваются;

— связи (отношения) — ромбами, соединяя их с соответствующими сущностями ненаправленными ребрами, за исключением бинарных связей, которые соединяются направленными ребрами.

Инфологическая модель БД Ресторана представлена на рис. 2.

Рисунок 2 — Инфологическая модель базы данных

2.2 Структурный подход при разработке инфологической модели

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

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

Понятие нормализации отношений

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

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

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

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

· Первая нормальная форма

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

Например, отношение Сотрудники = (Код должности, ФИО, № паспорта, Адрес, телефон, возраст, код должности) находится в первой нормальной форме.

· Вторая нормальная форма

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

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

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

Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.

· Третья нормальная форма

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

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

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

Рисунок 3 — Схема процесса нормализации

3.Выбор СУБД

3.1 Классификация и сравнительная характеристика СУБД

Классифицировать СУБД можно по следующим признакам:

— по используемой модели данных (классификация МД будет рассмотрена далее);

— по способу организации БД (централизованная или распределенная);

— по реализуемым режимам работы (однопользовательский, многопользовательский и т. д.);

— по способам физической организации данных.

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

Таблица 1 — Сравнительный анализ СУБД Microsoft SQL Server и Oracle

3.2 Требования к СУБД

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

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

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

— модель данных (предусмотренные типы данных, средства поиска, реализация языка запросов, средства поддержания целостности базы данных);

— особенности разработки приложений (средства проектирования, поддержка большого количества национальных языков, возможности разработки Web-приложений, поддерживаемые языки программирования);

— производительность (Рейтинг TPC (Transactions per Cent) т. е. отношение количества запросов, обрабатываемых за некий промежуток времени, к стоимости всей системы, возможности параллельной обработки данных, возможности оптимизирования запросов);

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

— требования к рабочей среде (минимальные требования к оборудованию, максимальный размер адресуемой памяти, операционные системы, под управлением которых способна работать СУБД);

— требуемый уровень квалификации персонала ресторана;

— смешанные критерии (качество и полнота документации, стоимость, стабильность производителя, распространенность СУБД).

4.Даталогическая (реляционная) модель БД

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

На данном этапе даталогического проектирования строится логическая структура БД нашего ресторана. При этом происходит преобразование исходной инфологической модели (рис.2) в модель данных, которая поддерживается конкретной СУБД. После этого производится проверка адекватности даталогической модели, отображаемой предметной области. Конечным результатом даталогического проектирования является описание структуры БД на языке описания данных конкретных СУБД. Пример модели данных приведен на рис. 4.

Рисунок 4 — Даталогическая модель данных

5.Обеспечение целостности данных

5.1 Типы ограничений целостности

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

Обязательные данные. Некоторые атрибуты не могут иметь пустого значения.

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

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

2. Значения, которые принимает некоторый атрибут, должны быть ограничены специальным диапазоном. Ограничение специфицируется специальным выражением.

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

4. Значение некоторого атрибута должно удовлетворять определенному формату. Ограничение специфицируется специальной фразой при описании атрибута.

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

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

Возможны следующие ситуации:

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

2. Удаление строки из дочерней таблицы. Нарушений целостности нет.

3. Обновление внешнего ключа в дочерней таблице. Новое значение внешнего ключа не должно быть равно одному из значений соответствующего ключа родительской таблицы, либо пусто.

4. Вставка строки в родительскую таблицу. Нарушений целостности нет.

6.Описание программного средства

Для построения базы данных выбрана программная среда MS Access.

Для реализации задачи были разработаны 5 таблиц и 4 запроса.

6.1 Таблицы

Таблицы:

1) Сотрудники (Код сотрудника, ФИО, Возраст, Адрес, Телефон, Паспортные данные, Код должности). (Рис.5)

Рисунок 5 — таблица «Сотрудники»

2) Должности (Код должности, Наименование должности, Оклад, Обязанности, Требования). (Рис.6)

Рисунок 6 — таблица «Должности»

Склад (Код ингредиента, Наименование ингредиента, Дата закупки, Количество, Стоимость, Поставщик). (Рис.7)

Рисунок 7 — таблица «Склад»

3) Меню (Код блюда, Наименование блюда, Код ингредиента 1, Код ингредиента 2, Код ингредиента 3, Код ингредиента 4, Объем порции, Стоимость, Время приготовления). (Рис.8)

Рисунок 8 — таблица «Меню»

Заказ (Дата, Время, ФИО заказчика, Телефон, Код блюда 1, Код блюда 2, Код блюда 3, Стоимость, Отметка о выполнении, Код сотрудника). (Рис.9)

Рисунок 9 — таблица «Заказ»

6.2 Запросы

Запросы:

1) «Отдел кадров» связывает таблицы «Должности» и «Сотрудники» по полю код должности.

2) «Выполнение заказа» связывает таблицы «Сотрудники» и «Заказ» по полю «код сотрудника».

3) «Формирование меню» связывает таблицы «Меню» и «Склад» по полям «код ингредиента», «код ингредиента 1», «код ингредиента 2», «код ингредиента 3» и «код ингредиента 4».

4) «Заказ» связывает таблицы «Заказ» и «Меню» по полям код блюда, код блюда 1, код блюда 2, код блюда 3.

6.3 Формы БД

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

Ниже рассматриваются следующие формы:

Форма «Главная форма» открывается при открытии базы данных «Ресторан». Содержит информацию о базе данных. Открытие этой формы одновременно с базой данных осуществлено путем помещения имени формы в строку «Форма» меню «Сервис/Параметры запуска». При нажатии кнопки запускается процедура обработки события, которая закрывает эту форму. Форма «Главная форма» предназначена для работы пользователя с базой данных. Щелчок мыши по каждой из кнопок вызывает соответствующее событие — открытие формы, так как все элементы базы данных «Ресторан» вызываются для удобства из форм и отчетов. Главная форма представлена на рис. 10.

Рисунок 10 — Главная форма Формы «Заказ» и «Сотрудники» созданы для внесения и редактирования соответствующей информации. Кроме того, из формы «Главная форма» можно вызывать 3 отчета: «Отчет Сотрудники» и «Просмотр заказов» и «Меню».

Форма «Сотрудники» выглядит следующим образом рис. 11.

Рисунок 11 — форма «Сотрудники»

Форма «Заказ» выглядит следующим образом рис. 12.

Рисунок 12 — форма «Заказ»

6.4 Отчеты в базе данных «Ресторан»

Отчеты в базе данных «Ресотран» демонстрируют способ эффективного представления данных в печатной форме. Они созданы для предоставления выдаваемых базой данных сведений в удобном для восприятия виде.

Отчет «Меню» формируется на основе служебного запроса «Просмотр Отчета» и служит для того, чтобы вывести на экран монитора меню в наглядной форме. Отчет вызывается из формы «Главная форма» => «Меню». Отчет выглядит следующим образом рис. 13.

Рисунок 13 — отчет «Меню»

Заключение

На примере базы данных «Ресторан» мы познакомились с инструментом разработки баз данных Microsoft Access. С его помощью можно быстро создавать деловые приложения для различных сфер деятельности человека. В то же время СУБД Access имеет архитектурные ограничения (например, максимальный размер базы данных не более одного гигабайта), которые не позволяют использовать этот инструмент для управления большими промышленными распределенными базами данных. Для таких целей применяются клиент-серверные СУБД Oracle, IBM DB2, Microsoft SQL Server, Sybase и ряд других.

Microsoft Access — это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объектами информации. Области применения Access обозначены достаточно ясно. Во-первых, пользователи этой системы являются непрограммирующие персоналы-люди, близкие к вычислительной технике, но не имеющие достаточно времени на ее изучение, поскольку она лежит вне области их профессиональных интересов и служит лишь подспорьем в работе. Таких пользователей привлекает легкость изучения программы, возможность решить большинство проблем без программирования, а также средства быстрого создания приложений. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственно базу данных, но и разрабатывать простые и сложные приложения. В отличие от других настольных СУБД Access хранит всю информацию в одном файле, хотя и распределяется и по разным таблицам.

1. Базы данных: учебное пособие / Н. Ю. Братченко. — Ставрополь: Сев-КавГТУ, 2011. — 195 с.

2. Партыка Т. Л., Попов И. И. Информационная безопасность. Учебное пособие для студентов учреждений среднего профессионального образования. ~М.: ФОРУМ: ИНФРА-М, 2004,-368с.: ил. — (Серия «Профессиональное образование»)

3. Информатика: Базовый курс / Под редакцией С. В. Симоновича, Издательский дом «Питер», 2002, 640с.

4. Завгородний В. И. Комплексная защита информации в компьютерных системах: Учебное пособие. — М.: Логос; ПБОЮЛ Н. А. Егоров, 2001. — 264с.: ил.

5. Мельников В. В. Защита информации в компьютерных системах. -М.: Финансы и статистика; Электронинформ, 2006. — 368с.: ил.

6. Информатика: Базовый курс. С. В. Симонович и др. СПб.: Питер. 2002.-458с.