Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1 СИСТЕМНЫЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ РЕСТОРАНА

1.1 Описание деятельности ресторана

1.2 Описание организационной структуры ресторана

1.3 Анализ информационных потоков в ресторане

1.4 Информационные технологии в ресторанном бизнесе

2 МОДЕЛИРОВАНИЕ СТРУКТУРЫ ДАННЫХРЕСТОРАНА

2.1 Разработка модели «сущность-связь» ресторана

2.2 Разработка логического уровня модели данных в среде Erwin

2.3 Нормализация модели данных ресторана

2.4 Разработка физического уровня модели данных в среде ERwin

3 РАЗРАБОТКА БАЗЫ ДАННЫХ РЕСТОРАНА В СРЕДЕ MS ACCESS

3.1 Разработка таблиц и установка связей в базе данных ресторана

3.2 Разработка запросов в базе данных ресторана

3.3 Разработка пользовательских форм в базе данных ресторана

3.4 Разработка отчетов в базе данных ресторана

3.5 Разработка макросов в базе данных ресторана

3.6 Обеспечение информационной безопасности базы данных

ЗАКЛЮЧЕНИЕ

ЛИТЕРАТУРА

ПРИЛОЖЕНИЕ

база данные ресторан erwin access

ВВЕДЕНИЕ

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

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

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

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

В практической части курсового проекта для создания модели и базы данных ресторана использованы программы Microsoft Access и ERWin.

1 СИСТЕМНЫЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ РЕСТОРАНА

1.1 Описание деятельности ресторана

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

Ресторан считается наиболее комфортабельным предприятием питания с самым широким ассортиментом блюд сложного приготовления.

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

В основные виды деятельности ресторана входят:

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

2) управление рестораном и персоналом. Роли управленца выполняют директор, а также управляющий под его начальством;

3) обеспечение ресурсами для всех сфер деятельности ресторана. Это две деятельности:

а) приготовление блюд по ассортименту;

Производственный процесс приготовления блюд состоит из следующих действий (операций):

- прием заказа;

- подготовка ингредиентов;

- контроль качества;

- непосредственного изготовления блюда;

- оформление и подача заказа.

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

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

4) реклама и маркетинг. Функции отдела маркетинга в ресторане выполняет директор. В его компетенцию входят следующие функции:

- анализ конъюнктуры рынка;

- изучение потребительского спроса, желаний клиентов;

- рекламная деятельность;

- вопросы сбыта;

- заключения договоров о сотрудничестве с рекламными компаниями;

- вопросы качества обслуживания и т.д.

1.2 Описание организационной структуры ресторана

Основные роли в ресторане:

­ управленческие;

­ помощники управленцев;

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

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

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

Рисунок 1.1 - Общая схема организации ресторана

Управленческие и организационные роли выполняют директор, управляющий и технолог. Вышестоящее лицо - директор, который исполняет следующие функции:

а) организует работу предприятия;

б) несет полную ответственность за его состояние и состояние трудового коллектива;

в) представляет предприятие во всех учреждениях и организациях;

г) распоряжается имуществом предприятия;

д) заключает договоры;

е) осуществляет поиск поставщиков материала;

ж) обеспечивает сбыт продукции (то есть поиск клиентов);

з) издает приказы по предприятию в соответствии с трудовым законодательством, принимает и увольняет работников;

и) применяет меры поощрения и налагает взыскания на работников предприятия;

к) открывает в банках счета предприятия.

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

Технолог или управляющий несет ответственность за следующие виды работ:

1) выпуск высококачественной продукции и ее совершенствование;

2) разработки новых видов продукции;

3) внедрение в производство новейших достижений науки и техники;

4) механизации и автоматизации производственных процессов;

5) соблюдение установленной технологии;

6) использование новейшей техники и технологии;

7) осуществляет оперативный контроль за ходом производства;

8) разрабатывает календарные графики работы;

9) устраняет причины, нарушающие нормальный режим производства;

10) осуществляет контроль за комплексностью и качеством готовой продукции;

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

Роли помощников управленцев выполняют бухгалтер, товаровед и администратор.

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

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

б) разрабатывает нормативы для образования фондов экономического стимулирования;

в) проводит всесторонний анализ результатов деятельности предприятия;

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

д) осуществляет учет средств предприятия и хозяйственных операций с материальными и денежными ресурсами;

е) устанавливает результаты финансово-хозяйственной деятельности предприятия;

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

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

Товаровед отвечает за продукцию, ее доставку в ресторан и качество доставляемого товара.

1.3 Анализ информационных потоков в ресторане

Схема информационных потоков, приведенная на рисунке 1.2, схожа с организационной структурой, так как распределение информации происходит в соответствии с функциями элементов организационной схемы.

1 - информация о ресурсах на складе;

2 , 5, 6 - информация о спросе, престиже, посещаемости ресторана;

3 - информация о материальном состоянии ресторана;

3, 5 - информация о выполняемых обязанностях и самой работе;

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

6 - информация о предложении ( услуги ресторана, их цена).

Рисунок 1.2 - Информационные потоки в структуре ресторана

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

Как видно из рисунка 1.2, много информации проходит через управляющего, имеющего прямую связь со следующими структурными элементами:

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

- бухгалтером (информация о ценах, заработной плате, затратах на ресторанную деятельность и имущество, на рекламу, расходах, доходах);

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

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

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

- поставщиком (информация о заказе ресурсов, цен, новых предложениях).

1.4 Информационные технологии в ресторанном бизнесе

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

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

Объем ИТ-затрат в секторе общественного питания (чуть более 500 млн. руб. за 2006-й год и 0,18 % в общих ИТ-расходах по экономике) -- самый низкий не только в секторе торговли, но и в сравнении с подавляющим большинством производящих и обслуживающих отраслей экономики. При этом в объеме прибыли уровень расходов достаточно высок -- 1,27 %, что не намного ниже , чем в рознице (1,6 %), зато больше, чем у автодилеров (1 %), и в 2 раза больше, чем у оптовиков (0,6 %) [1]. На рисунке 1.3 изображена диаграмма затрат на ИТ в данном секторе с 2002-й по 2006-й год.

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



Рисунок 1.3 - Динамика затрат на ИТ в секторе услуг общественного питания

Темпы прироста ИТ-затрат показаны на графике на рисунке 1.4. Следует констатировать, что сегодняшний уровень ИТ-расходов сопоставим с уровнем 2002-го года. Таким образом, на протяжении периода 2002-2006 гг. можно говорить скорее о стагнации спроса на ИТ в секторе общественного питания, нежели о каких-либо тенденциях развития. Скорее всего, внедрения происходят локальные, без особых усилий по дальнейшему развитию ИТ-инфраструктуры предприятий [2].

Рисунок 1.4 - Темпы прироста ИТ-затрат в секторе общественного питания

При этом предложение ИТ для предприятий общественного питания существует, а опыт имевших место внедрений показывает, что ИТ в ресторанном бизнесе не является лишним . Современный ресторан -- это не просто место, где продают еду и выделяют место для ее поглощения, это красивый способ времяпрепровождения, один из основных элементов досуга в современных городах. Организация подобного процесса крайне сложна по своему содержанию и наполнению, требует соблюдения санитарных и технологических норм, контроля за стилем и культурой поведения обслуживающего персонала, за учетным процессом, а также анализа транзакций, учета поступления продуктов, формирования стоимости блюд и полуфабрикатов, процедур списания продуктов «под ноль» и т.д. Требование автоматизации всех этих процессов вытекает, прежде всего, из необходимости учёта большого количества деталей. Удобство автоматизации и информатизации процессов на предприятии общественного питания очевидно не только с точки зрения «ведения дел», но и с позиций клиентов, так как ИС позволяют более оперативно работать с расчетами с посетителями, очередностью обслуживания, обеспеченностью предлагаемого меню всеми необходимыми ингредиентами [3].

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

Во-первых, ИТ берут на себя процедуру формирования блюда на основе набора ингредиентов (произвольно и часто меняющегося во времени) и схемы закупки продуктов (не только от организаций, но и с рынка по закупочным актам) и так далее. Автоматизируется ведение списка блюд с учетом нормативов расхода продуктов, сезонных норм закладок продуктов на основе использования справочников продуктов и блюд.

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

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

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

Таким образом, целью работы является повышение эффективности работы сети ресторанов «Цитадель 2004» на основе разработки и внедрения базы данных, позволяющей автоматизировать и упростить множество операций в данной деятельности. Для создания и разработки базы данных ресторана используются в данном курсовом проекте программы Microsoft Office Access и ERwin.

Для достижения поставленной цели в работе должны быть решены две основные задачи: моделирование структуры данных ресторана в среде ERwin и разработка базы данных ресторана в среде Microsoft Office Access.

В моделировании структуры данных ресторана существуют следующие аспекты:

- разработка модели «сущность-связь»;

- разработка логического уровня модели данных ресторана в среде ERWIN;

- нормализация модели данных ресторана;

- разработка физического уровня модели данных в среде ERWIN;

В разработке базы данных ресторана в среде Microsoft Office Access будут пройдены следующие этапы:

- разработка таблиц, отображающих данные ресторана, и установление связей между ними;

- разработка пользовательских форм;

- разработка запросов;

- разработка отчетов;

- разработка макросов;

- обеспечение информационной безопасности при работе с базой данных ресторана.

Вышеописанные две основные задачи: моделирование структуры данных ресторана в среде ERwin и разработка базы данных ресторана в среде Microsoft Office Access - рассмотрены довольно подробно и решены во второй и третьей главах данного курсового проекта.

2 МОДЕЛИРОВАНИЕ СТРУКТУРЫ ДАННЫХ РЕСТОРАНА

2.1 Разработка модели «сущность-связь» ресторана

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

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

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

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

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

Семантическую основу модели «cущность-связь» составляют следующие предположения:

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

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

3) сущности можно классифицировать по типам сущностей: каждый экземпляр сущности (представляющий некоторый
объект) может быть отнесен к классу -- типу сущностей, каждый экземпляр которого обладает общими для них и отличающими их от сущностей других классов свойствами;

4) систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность типа А является подтипом сущности В, если каждый экземпляр типа А является экземпляром сущности типа В;

5) взаимосвязи объектов могут быть представлены как связи -- сущности, которые служат для фиксирования (представления) взаимозависимости двух или нескольких сущностей.

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

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

1) меню;

2) сотрудник;

3) поставка;

4) поставщик;

5) отдел;

6) материальная база.

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

1) меню - номер блюда, наименование блюда, категория, вес, цена;

2) сотрудник - номер сотрудника, ФИО, дата рождения, должность, оклад, телефон, адрес;

3) поставка - номер поставки, наименование поставки, дата поставки, сумма;

4) поставщик - номер поставщика, фирма, номер сертификата, контактное лицо, адрес;

5) отдел - номер отдела, наименование отдела;

6) материальная база - номер помещения, наименование помещения, оборудование.

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

Диаграмма «сущность-связь» для базы данных ресторана приведена на рисунке 2.1.

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

В модели «сущность-связь» ресторана зафиксированы следующие ключевые атрибуты: номер блюда, номер сотрудника, номер поставки, номер поставщика, номер отдела, номер помещения.

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

1) заказ - он производится по меню клиентом ресторана и передается сотруднику;

2) разработка меню - управляющий ресторана после анализа возможностей ресторана и потребностей потребителей обеспечивает обновления в меню ресторана;

3) состав - каждый работник ресторана состоит в определенном отделе;

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

5) составление - каждый сотрудник подает заявку на пополнение необходимых ресурсов ресторана;

6) доставка - выполнение поставщиком заявок на поставки ресторана.



Рисунок 2.1 - Модель «сущность-связь» ресторана

Существуют типы связей, задающие количественный характер участия экземпляров сущностей: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М). В модели «сущность-связь» ресторана использованы следующие типы связей:

1) 1:М - связи «отдел - сотрудник», «материальная база - сотрудник», «сотрудник - поставка», «поставщик - поставка», «сотрудник - разработка -меню»;

2) М:М - «сотрудник - заказ -меню».

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

2.2 Разработка логического уровня модели данных в среде Erwin

Цель моделирования данных на логическом уровне состоит в обеспечении разработчика информационных систем (ИС) концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Отдел», «Фамилия сотрудника». Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Такая модель данных является универсальной и никак не связана с конкретной реализацией системы управления базой данных(СУБД). Построение логической модели ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания.

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

1) диаграмма сущность-связь (Entity Relationship Diagram, ERD);

2) модель данных, основанная на ключах (Key Based model, KB);

3) полная атрибутивная модель (Fully Attributed model, FA).

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

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

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

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

На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим.

На логическом уровне модели данных в среде Erwin различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углам. Экземпляр зависимой сущности определяется только через отношение к родительской сущности [9].

Логическая модель базы данных ресторана содержит следующие сущности:

1) «Сотрудник», атрибуты - ключевой «Номер сотрудника», «Фамилия», «Имя», «Отчество», «Дата рождения», «Должность», «Адрес», «Телефон», «Оклад», «Номер отдела», «Номер помещения»;

2) «Поставщик», атрибуты - ключевой «Номер поставщика», «ИП», «Адрес», «Телефон», «Номер сертификата», «Контактное лицо»;

3) «Меню», атрибуты - ключевой «Номер блюда», «Наименование блюда», «Вес», «Цена», «Категория»;

4) «Материальная база», атрибуты - ключевой «Номер помещения», «Наименование помещения», «Оборудование»;

5) «Отдел», атрибуты - ключевой «Номер отдела», «Наименование отдела»;

6) «Поставки», атрибуты - ключевой «Номер поставки», «Дата поставки», «Сумма», «Номер сотрудника», «Номер поставщика»;

7) «Меню_Сотрудник», атрибуты - «Номер блюда», «Номер сотрудника», которые образуют первичный составной ключ.

Так между сущностями «Меню» и «Сотрудник» связь М-М, то их связывание осуществляется через ассоциативную (вспомогательную) сущность «Меню_Сотрудник»; используется функция в программе Erwin «many-to-many transform» для изменения связи М-М между сущностями «Меню» и «Сотрудник».

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

1) идентифицирующая - между сущностями «сотрудник» и «меню» (М-М), «сотрудник» и «поставки» (1-М), «поставщик» и «поставки» (1-М);

2) неидентифицирующая - между сущностями «сотрудник» и «отдел», «сотрудник» и «материальная база».

На рисунке 2.2 приведена ненормализованная логическая модель ресторана. Для ее основы использовалась построенная в предыщем пункте модель «сущность - связь» ресторана.

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

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

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



Рисунок 2.2 - Логическая модель базы данных ресторана

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

Выбор первичного ключа может оказаться непростой задачей, решение которой может повлиять на эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).

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

2.3 Нормализация модели данных ресторана

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

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

В теории реляционных БД выделяется следующая последовательность нормальных форм:

1) первая нормальная форма (1NF) - сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, то есть несколько значений для каждого экземпляра;

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

3) третья нормальная форма (3NF) - сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута, то есть не должно быть взаимозависимости между неключевыми атрибутами;

4) нормальная форма Бойса-Кодда (BCNF) - сущность находится в нормальной форме Бойса-Кодда, если любая функциональная зависимость между атрибутами сводится к полной функциональной зависимости от возможного первичного ключа;

5) четвертая нормальная форма (4NF) - является частным случаем пятой нормальной формы, когда полная декомпозиция является соединением ровно двух проекций;

6) пятая нормальная форма (5NF) - сущность находится в пятой нормальной форме, если в каждой ее полной декомпозиции все проекции содержат возможный ключ;

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

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

Нормализованная модель базы данных отображена на рисунке 2.3.

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

В сущности «Сотрудник» содержится атрибут «телефон», который нарушает требования первой нормальной формы. Тогда создается новая сущность «Телефон», в которую переносятся атрибуты с неатомарными значениями, и его возможный ключ - «Номер сотрудника». Аналогична ситуация с атрибутом «оборудование» сущности «Материальная база». Таким же образом приводится данная сущность к первой нормальной форме.

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



Рисунок 2.3 - Нормализованная модель базы данных ресторана

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

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

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

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

2.4 Разработка физического уровня модели данных в среде ERwin

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

Физическая модель ресторана также строится на модели "сущность-связь" ресторана и логически создается на базе концептуальной модели.

Сущности становятся таблицами базы данных (БД). Атрибуты сущностей преобразуются в поля таблиц. Связи преобразуются в ограничения.

Атрибутам сущностей присваиваются конкретные типы полей. При помощи ограничений в БД переносятся бизнес-логика обработки и хранения данных ИС.

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

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах.

Различают два подуровня физического уровня модели данных:

1) трансформационная модель (Transformation Model);

2) модель СУБД (DBMS Model).

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

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

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах.

Для того, чтобы получить физическую модель базы данных ресторана в MS Access 2000-2003 из полученной в ERwin логической модели генерируется физическая модель через встроенные процедуры Erwin. Сначала выбирается сервер. Для выбора СУБД служит редактор Target Server (меню Database/Choose Database доступно только на физическом уровне) [4].

Генерация физической модели базы данных ресторана в MS Access из ERwin отображена на рисунке 1 в приложении.

3 РАЗРАБОТКА БАЗЫ ДАННЫХ РЕСТОРАНА В СРЕДЕ MS ACCESS

3.1 Разработка таблиц и установка связей в базе данных ресторана

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

Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. При этом можно существенно упростить структуру данных, облегчая тем самым выполнение поставленных задач [5].

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

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

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

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

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

Графа «Описание» может не заполняться. Эта графа используется в целях документирования проекта.

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

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

После создания таблиц осуществляется их связывание. Схема данных базы данных ресторана отображена на рисунке 3.1.

База данных ресторана, сгенерированная в Access из Erwin, содержит следующие таблицы:

1) данные поставщика, столбцы - фамилия, адрес, телефон, номер сертификата;

2) должность, столбцы - должность, оклад;

3) материальная база, столбцы - номер помещения, его наименование, номер сотрудника;

4) меню, столбцы - номер блюда, его наименование, категория, вес, цена;

5) оборудование, столбцы - номер помещения, оборудование;

6) отдел, столбцы - наименование отдела, его номер;

7) поставки, столбцы - номер поставки, ее дата наименование, номера сотрудника и поставщика;

8) поставщики, столбцы - номер поставщика, фамилия, контактное лицо;

9) сотрудники, столбцы - номер сотрудника, фамилия, имя, отчество, дата рождения, номер отдела, должность, адрес;

10) сотрудники и меню, столбцы - номера сотрудника и блюда;

11) стоимость поставки , столбцы - наименование поставки и ее сумма;

12) телефон, столбцы - телефон и номер сотрудника.



Рисунок 3.1 - Схема данных базы данных ресторана

3.2 Разработка запросов в базе данных ресторана

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

Запрос в Access может быть использован в качестве источника данных для создания форм и отчетов, обеспечивает эффективный доступ к данным (уже не требуется открывать одновременно несколько форм или таблиц и подолгу выбирать нужные сведения - с этой работой быстро справиться заранее подготовленный запрос).

В Access предусмотрены следующие типы запросов:

1) простой запрос на выборку из определенных полей - запрос с простыми условиями, включающими только один аргумент поиска. При создании простого запроса условие отбора записывается в соответствующий столбец бланка запроса. В Access при задании запроса ограничители можно не ставить. В зависимости от типа поля, которое вводится в выражение, определяющее условие отбора, ограничители добавляются системой автоматически: прямые кавычки (" ") вокруг строковых значений; символы (#) вокруг дат. В столбце можно записывать не только значение атрибута, но и знак операции сравнения; по умолчанию принимается знак равенства (=). Если в условии отбора должны использоваться операции сравнения, отличные от знака равенства, то их надо указывать в явном виде;

2) сложный запрос. Если в условиях отбора используется несколько полей, то они могут соединяться оператором «и» или «или», а ответ зависит от взаимного расположения аргументов поиска относительно друг друга;

3) перекрестный, выводящий данные в компактном формате, подобном формате электронной таблицы. В перекрестном запросе отображаются результаты статистических расчетов (такие, как суммы, количество записей, средние значения), выполненных по данным из одного поля. Эти результаты группируются по двум наборам данных в формате перекрестной таблицы. Первый набор выводится в левом столбце и образует заголовки строк, а второй - выводится в верхней строке и образует заголовки столбцов. При создании перекрестного запроса в качестве источника данных можно задать только одну таблицу. Если для реализации запроса требуются поля из разных таблиц, то надо предварительно создать вспомогательный запрос, который будет включать все требуемые поля;

4) запрос на создание таблицы. Запрос на создание таблицы фактически означает запоминание результата запроса в таблице. Чтобы использовать такую возможность, необходимо создать запрос, результат которого следует поместить в новую таблицу. Затем в режиме конструктора запроса нужно выбрать Тип запроса/Создание таблицы. На экране появится диалоговое окно Создание таблицы. В поле «Имя таблицы» необходимо ввести имя таблицы, в которую будут переноситься данные;

5) корректирующий, то есть запросы на добавление, на удаление, на обновление записей из одной таблицы или нескольких связанных таблиц в конец другой таблицы;

6) запрос к связанным таблицам. Если была предварительно определена схема данных, то при добавлении таблиц в запрос они будут должным образом связаны. Даже если связи между таблицами не были созданы пользователем, то при добавлении в запрос двух таблиц, при условии, что они имеют поля с одинаковым или совместимым типом данных и одно из полей связи является ключевым, связи могут быть созданы автоматически. Автоматическое объединение можно разрешить или запретить;

7) специальные запросы, то есть поиск записей, не имеющих подчиненных и поиск повторяющихся записей;

8) запрос с параметрами. Если приходится часто выполнять однотипный запрос на выборку или перекрестный запрос, изменяя при этом значение какого-либо атрибута в условии отбора, то можно использовать запрос с параметрами. Запрос с параметрами не требует каждый раз вносить изменения в бланк запроса; вместо этого выводится приглашение пользователю ввести условия отбора. Для каждого поля, которое предполагается использовать как параметр, в «Конструкторе запросов» необходимо ввести в ячейку строки «Условие отбора» текст приглашения, заключенный в квадратные скобки. Это приглашение будет выводиться при запуске запроса. Текст подсказки должен отличаться от имени поля, но может включать его;

9) запрос в режиме сводной таблицы и сводной диаграммы. Сводная таблица или сводная диаграмма может быть получена при работе с таблицей, запросом или формой.

В базе данных ресторана реализованы следующие запросы:

1) запрос с параметром «Дата поставки», в котором в приглашении требуется ввести дату поставки и запрос выведет все поставки в назначенный день, создание запроса приведено на рисунке 3.2;

Рисунок 3.2 - Запрос с параметром «Дата поставки»

2) запрос поставок к связанным таблицам «Поставки», «Стоимость поставки», «Поставщик» приведен на рисунке 3.3;

3) простой запрос на сотрудников с окладом меньше пятнадцати тысяч рублей, запрос на адреса и номера телефонов сотрудников;

4) перекрестные запросы «Итоговая сумма» и «Общая сумма поставок»;

5) запрос-диаграмма «Должности» приведен на рисунке 3.4;

6) запросы к связанным таблицам «Рабочие места сотрудников» и «Ответственные за оборудование»;

7) простые запросы на телефоны сотрудников и поставщиков.



Рисунок 3.3 - Запрос к связанным таблицам «Поставки», «Стоимость поставки», «Поставщик»

Остальные запросы приведены в приложении на рисунке 3-4.

Рисунок 3.4 - Сводная диаграмм запроса «Должности сотрудников»

3.3 Разработка пользовательских форм в базе данных ресторана

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

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

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

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

Для базы данных необходимо создать простые формы и формы с вложенными подчиненными формами.

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

В базе данных ресторана содержатся следующие пользовательские формы:

1) меню, где вводится информация о блюде или напитке из ассортимента ресторана, его категории, весе, цене, а также должности и номере сотрудника, который готовит это блюдо или напиток. Форма меню приведена на рисунке 3.5. В ресторане важно распределение блюд и напитков между сотрудниками, так как каждый работник отвечает за свою конкретную деятельность. В форме меню есть в наличии две кнопки - для создания новой записи при регистрации нового работника и для вывода другой формы, в которой отображены более точные данные работника, готовящего соответствующие блюда или напитки, то есть его фамилия, имя, отчество. В меню входит подчиненная форма из таблицы «Меню»;