Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
СОДЕРЖАНИЕ
ВВЕДЕНИЕ………………………………………………………………………..4
1 СИСТЕМНЫЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ РЕСТОРАНА……………........5
1.1 Описание деятельности ресторана……………………………………..5
1.2 Описание организационной структуры ресторана…………………....6
1.3 Анализ информационных потоков в ресторане……………………...10
1.4 Информационные технологии в ресторанном бизнесе...…………....12
2 МОДЕЛИРОВАНИЕ СТРУКТУРЫ ДАННЫХРЕСТОРАНА………….….17
3 РАЗРАБОТКА БАЗЫ ДАННЫХ РЕСТОРАНА В СРЕДЕ MS ACCESS......32
3.1 Разработка таблиц и установка связей в базе данных ресторана….32
3.2 Разработка запросов в базе данных ресторана……………………...35
3.3 Разработка пользовательских форм в базе данных рестора...……..39
3.4 Разработка отчетов в базе данных ресторана……………………….41
3.5 Разработка макросов в базе данных ресторана……………….…….43
3.6 Обеспечение информационной безопасности базы данных.….......44
ЗАКЛЮЧЕНИЕ………………………………………………………………….51
ЛИТЕРАТУРА…………………………………………………………………...52
ПРИЛОЖЕНИЕ…………………………………………………………….........53
ВВЕДЕНИЕ
Потоки информации, циркулирующие в мире, который окружает людей, огромны. Во времени они имеют тенденцию к увеличению. Поэтому в любой организации возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Большинство предпочитают компьютеризированные способы – базы данных, позволяющие эффективно хранить, структурировать и систематизировать большие объемы данных. Сегодня без баз данных невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций.
Существует много веских причин перевода информации на компьютерную основу. Сейчас стоимость хранения информации в файлах на компьютере дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Использование клиент-серверных технологий позволяют сберечь значительные средства и время для получения необходимой информации, упрощают доступ и ведение.
Для использования столь огромных объемов хранимой информации, помимо развития системных устройств, средств передачи данных, памяти необходимы средства обеспечения диалога человек-компьютер, которые позволяют пользователю вводить запросы, читать файлы, модифицировать хранимые данные, добавлять новые данные или принимать решения на основании хранимых данных. Для обеспечения этих функций созданы специализированные средства – системы управления базами данных (СУБД).
Цель данного курсового проекта – создание базы данных ресторана для упрощения, оптимизации и модернизации работы с информацией для повышения эффективности работы всего предприятия в целом.
В практической части курсового проекта для создания модели и базы данных ресторана использованы программы Microsoft Access и ERWin.
На примере одного ресторана, входящего в сеть ресторанов, принадлежащей предприятию частного типа – обществу с ограниченной ответственностью «Цитадель 2004», произведен системный анализ деятельности ресторана и приведено его описание.
Ресторан считается наиболее комфортабельным предприятием питания с самым широким ассортиментом блюд сложного приготовления.
В ресторане высокий уровень обслуживания сочетается с организацией отдыха посетителей.
В основные виды деятельности ресторана входят:
а) приготовление блюд по ассортименту;
Производственный процесс приготовления блюд состоит из следующих действий (операций):
- прием заказа;
- подготовка ингредиентов;
- контроль качества;
- непосредственного изготовления блюда;
- оформление и подача заказа.
К функциональным обязанностям поваров относят приготовление блюд по заказам потребителя по ассортименту. Приготовление блюд занимает от 20 до 60 минут в зависимости от выбранного наименования и количества заказанного, так как ассортимент достаточно широк и довольно сложно представить себе единую схему технологического процесса. Производственная мощность ресторана зависит и от производительности повара;
б) доставка продуктов, питьевых и пищевых. Она происходит каждый день. Список закупок составляется заранее и отправляется через главный офис сети ресторанов. Повар производит проверку, взвешивание доставленной поставщиком продукции. Повар расписывается за выполнение заказа на ресурсы, заполняя бланк;
4) реклама и маркетинг. Функции отдела маркетинга в ресторане выполняет директор. В его компетенцию входят следующие функции:
- анализ конъюнктуры рынка;
- изучение потребительского спроса, желаний клиентов;
- рекламная деятельность;
- вопросы сбыта;
- заключения договоров о сотрудничестве с рекламными компаниями;
- вопросы качества обслуживания и т.д.
Основные роли в ресторане:
На рисунке 1.1 отображена организационная структура ресторана, включающая ее основные элементы и функциональные связи между ними.
Рисунок 1.1 - Общая схема организации ресторана
Управленческие и организационные роли выполняют директор, управляющий и технолог. Вышестоящее лицо – директор, который исполняет следующие функции:
а) организует работу предприятия;
б) несет полную ответственность за его состояние и состояние трудового коллектива;
в) представляет предприятие во всех учреждениях и организациях;
г) распоряжается имуществом предприятия;
д) заключает договоры;
е) осуществляет поиск поставщиков материала;
ж) обеспечивает сбыт продукции (то есть поиск клиентов);
з) издает приказы по предприятию в соответствии с трудовым законодательством, принимает и увольняет работников;
и) применяет меры поощрения и налагает взыскания на работников предприятия;
к) открывает в банках счета предприятия.
На один-два заведения рассчитано по одному управляющему, который, как правило, обеспечивает саму деятельность ресторана, проводя набор новых работников.
Технолог или управляющий несет ответственность за следующие виды работ:
Роли помощников управленцев выполняют бухгалтер, товаровед и администратор.
На всю сеть ресторанов один бухгалтер. Он является также заместителем директора по экономическим вопросам. Выполняет следующие функциональные действия:
а) руководит работой по планированию и экономическому стимулированию на предприятии, повышению производительности труда, выявлению и использованию производственных резервов улучшению организации производства, труда и заработной платы;
б) разрабатывает нормативы для образования фондов экономического стимулирования;
в) проводит всесторонний анализ результатов деятельности предприятия;
г) разрабатывает мероприятия по снижению себестоимости и повышению рентабельности предприятия, улучшению использования производственных фондов, выявлению и использованию резервов на предприятии;
д) осуществляет учет средств предприятия и хозяйственных операций с материальными и денежными ресурсами;
е) устанавливает результаты финансово-хозяйственной деятельности предприятия;
ж) производит финансовые расчеты с заказчиками и поставщиками, связанные с реализацией готовой продукции, приобретением необходимого сырья, в его задачи также получение кредитов в банке, своевременный возврат ссуд, взаимоотношение с государственным бюджетом.
Администратор следит за порядком и выполнением работ и обязанностей персонала, а также соблюдением их прав.
Товаровед отвечает за продукцию, ее доставку в ресторан и качество доставляемого товара.
Схема информационных потоков, приведенная на рисунке 1.2, схожа с организационной структурой, так как распределение информации происходит в соответствии с функциями элементов организационной схемы.
1 – информация о ресурсах на складе;
3, 5 – информация о выполняемых обязанностях и самой работе;
Рисунок 1.2 - Информационные потоки в структуре ресторана
Директор получает информацию в основном от управляющего и бухгалтера, на основе которой делает анализ и выводы, что было сделано и что необходимо сделать или изменить.
Как видно из рисунка 1.2, много информации проходит через управляющего, имеющего прямую связь со следующими структурными элементами:
- директором ( информация о бизнес-плане, стратегии, рекламных акциях, изменениях в структуре и ценовой политике, планировании , в свою очередь, сам управляющий отчитывается за деятельность ресторана и выполнение плана и т.д.);
- бухгалтером (информация о ценах, заработной плате, затратах на ресторанную деятельность и имущество, на рекламу, расходах, доходах);
- специалистами (решение временных проблем, дизайн-проект ресторана, ремонт оборудования, консультация менеджера, решение вопросов, связанных с законодательством, организаторы развлекательных мероприятий, рекламные акции и др.);
- администратором ( информация о спросе потребителя, его качестве обслуживания, о престиже ресторана, его посещаемости, о работе персонала, его составе, о заказах потребителей, о состоянии оборудования и имущества ресторана);
- поваром ( информация о ресурсах , новых предложениях в ассортименте, об используемой технологии в своей работе, о состоянии склада, о технологии приготовления ассортимента);
- поставщиком (информация о заказе ресурсов, цен, новых предложениях).
В секторе общественного питания, как и в торговой отрасли в целом, определяющими факторами конкурентоспособности являются не высокие технологии, а совершенно другие, никак не связанные с ними вещи.
Однако информационные технологии (ИТ), технологии автоматизации ресторанного бизнеса всё больше начинают рассматриваться как важный и необходимый компонент успешного бизнеса. Пока о четких трендах в информатизации сектора общепита говорить нельзя, однако существуют факты, указывающие на то, что и этот вид бизнеса начинает приобщаться к высоким технологиям.
Объем ИТ-затрат в секторе общественного питания (чуть более 500 млн. руб. за 2006-й год и 0,18 % в общих ИТ-расходах по экономике) — самый низкий не только в секторе торговли, но и в сравнении с подавляющим большинством производящих и обслуживающих отраслей экономики. При этом в объеме прибыли уровень расходов достаточно высок — 1,27 %, что не намного ниже , чем в рознице (1,6 %), зато больше, чем у автодилеров (1 %), и в 2 раза больше, чем у оптовиков (0,6 %) [1]. На рисунке 1.3 изображена диаграмма затрат на ИТ в данном секторе с 2002-й по 2006-й год.
Рисунок 1.3 – Динамика затрат на ИТ в секторе услуг общественного питания
Данную ситуацию, однако, нельзя пока рассматривать как типичную для предприятий общепита. Текущий уровень ИТ-расходов — феномен всего лишь двухлетней истории, возникший на фоне неожиданного всплеска ИТ-затрат этих предприятий в 2005-м году.
Темпы прироста ИТ-затрат показаны на графике на рисунке 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.1 Разработка модели «сущность-связь» ресторана
Моделирование информационной системы ресторана, в первую очередь, необходимо для выявления недостатков существующей системы, ее слабых мест, основных показателей, улучшение которых может стать основанием новых информационных технологий.
Основными направлениями деятельности ресторана является реализация товара и обеспечение условий для отдыха клиентов. Предметной областью является учет товара, оформление документов по поставкам и заказам.
Описательная неформализованная модель: характерной особенностью ресторана является обслуживание посетителей. В обязанности сотрудников ресторана входит обслуживание посетителей, включающие в себя: приготовление холодных и горячих напитков и блюд, коктейлей, а также подача закусок и кондитерских изделий. Бармен и официант получают заказ на изготовление блюд, и, по необходимости, передают заказ на кухню. При получении заказа бармен и официант фиксируют заказ в ведомости заказов. После выполнения заказа бармен и официант записывают выполненный заказ в учетную ведомость. Повар отмечает наличие и недостачу ингредиентов для приготовления заказа в ведомости. Ведомость заказов необходима для выявления недостающего товара. Учетная ведомость позволяет вести учет расходов продукции. По этим ведомостям отслеживается товар, подлежащий заказу, а также расход товара за смену. Заказ выполняется поваром, барменом, официантом. На основании заявки управляющему, поданной барменом, поваром, осуществляется заказ продукции поставщику. На основании заказа поставщик осуществляет поставки товара, закупленный товар поставляется на склад, управляющему предоставляется накладная на товары. Бармен, повар получает товар, проверяет его наличие и количество на основании накладной. Полученный товар выставляется на барную стойку, ставится в холодильную камеру и специальные емкости в ящики.
Цель моделирования данных состоит в разработке концептуальной схемы базы данных в форме информационной модели.
Информационная модель представляется в виде диаграмм «сущность-связь», отражающих основные объекты предметной области и связи между ними.
Семантическую основу модели «cущность-связь» составляют следующие предположения:
Такое определение связи, как сущности особого рода, отражает существо реляционного подхода, для которого характерно единообразное представление сущностей всех типов, включая связи посредством переменных-отношений.
Под сущностью подразумевается нечто, абстракция объекта предметной области, информация о чем подлежит сохранению в базе данных. В модели «сущность-связь» ресторана зафиксированы следующие сущности:
Сущность имеет атрибуты (свойства) - это элементарные данные, относящиеся к сущности (характеристики сущности). На диаграмме обозначается в виде прямоугольника с именем сущности внутри. В модели «сущность-связь» ресторана зафиксированы следующие атрибуты соответствующих сущностей:
Свойство «адрес» является составным, так как его значение составляется из значений простых свойств «город», «улица», «дом». Свойство «телефон» является множественным, так как может иметь несколько значений. Остальные свойства являются базовыми, единичными, простыми безусловными.
Диаграмма «сущность-связь» для базы данных ресторана приведена на рисунке 2.1.
Рисунок 2.1 - Модель «сущность-связь» ресторана
Свойство может рассматриваться как ключевое, если его значение уникально и однозначно идентифицирует сущность. На диаграмме оно обозначается подчеркиванием.
В модели «сущность-связь» ресторана зафиксированы следующие ключевые атрибуты: номер блюда, номер сотрудника, номер поставки, номер поставщика, номер отдела, номер помещения.
Связь - это ассоциация, объединяющая несколько сущностей. Атрибуты с сущностями и сущности со связями соединяются прямыми линиями. Связь на диаграмме отображается в виде ромба с именем связи внутри. В модели «сущность-связь» ресторана отображены следующие связи:
Существуют типы связей, задающие количественный характер участия экземпляров сущностей: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М). В модели «сущность-связь» ресторана использованы следующие типы связей:
В данной модели ресторана отмечена одна слабая сущность – «поставки», так как поставки зависят от поставщиков и сотрудников, подающих на них заявку, то есть запись о поставке будет удалена при удалении записи о сотруднике, который размещает заказ, поставляет поставщик, следовательно, сущность «поставки» слабая.
Цель моделирования данных на логическом уровне состоит в обеспечении разработчика информационных систем (ИС) концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Отдел», «Фамилия сотрудника». Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Такая модель данных является универсальной и никак не связана с конкретной реализацией системы управления базой данных(СУБД). Построение логической модели ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания.
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Для реляционной базы данных проектирование логической структуры заключается в том, чтобы разбить всю информацию по отношениям и определить состав атрибутов для каждого из этих отношений.
Существуют разные способы проектирования логической структуры реляционных баз данных. В данном проекте используется способ проектирования, основанный на анализе инфологической модели и переходе от нее к реляционным отношениям. Этот метод является достаточно простым и наглядным и в то же время дает хорошие результаты.
На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим.
На логическом уровне модели данных в среде Erwin различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углам. Экземпляр зависимой сущности определяется только через отношение к родительской сущности [9].
Логическая модель базы данных ресторана содержит следующие сущности:
Так между сущностями «Меню» и «Сотрудник» связь М-М, то их связывание осуществляется через ассоциативную (вспомогательную) сущность «Меню_Сотрудник»; используется функция в программе Erwin «many-to-many transform» для изменения связи М-М между сущностями «Меню» и «Сотрудник».
В логической модели данных ресторана установлены следующие типы связей:
На рисунке 2.2 приведена ненормализованная логическая модель ресторана. Для ее основы использовалась построенная в предыщем пункте модель «сущность – связь» ресторана.
Каждый экземпляр сущности должен быть уникален и отличаться от других атрибутов.
При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).
Таким образом, в модели ресторана в сущности «Поставки», находящейся в идентифицирующей связи со сущностями «Сотрудник» и «Поставщик», отмечены внешние ключи «номер сотрудника» и «номер поставщика» над чертой. Сущности «Отдел» и «Сотрудник», «Материальная база» и «Сотрудник» независимы друг от друга, поэтому связь между ними неидентифицирующая, а у сущности «Сотрудник» зафиксированы внешние ключи «номер отдела» и «номер помещения» под чертой.
Рисунок 2.2 – Логическая модель базы данных ресторана
Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии.
Выбор первичного ключа может оказаться непростой задачей, решение которой может повлиять на эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).
Следовательно, в логической модели ресторана выявлены следующие альтернативные ключи: «наименование блюда», так как от самого блюда зависят его категория, вес и цена; «наименование помещения», так как необходимое оборудование определяется назначением помещения; набор атрибутов «фамилия», «имя», «отчество», так как от них зависят остальные неключевые атрибуты в сущности «Сотрудник».
Процесс нормализации – это разбиение таблицы на две или более с целью ликвидации дублирования данных и их потенциальной противоречивости.
Цель нормализации – удаление избыточных данных и обеспечение максимальной гибкости структуры таблиц, то есть получение такого проекта базы данных, в котором каждый факт появляется лишь в одном месте.
В теории реляционных БД выделяется следующая последовательность нормальных форм:
На практике достаточно для структуры базы данных обеспечить выполнение третьей нормальной формы, а в некоторых случаях допускается снижение нормальных форм, так как в процессе нормализации значительно усложняется структура базы данных.
Для структуры базы данных ресторана более рационально привести сущности к нормальной форме Бойса-Кодда, а не к третьей нормальной форме, так как в реальной практике чрезмерное увлечение следованиям правил нормализации приведет к неоправданному снижению производительности и усложнению структуры.
Нормализованная модель базы данных отображена на рисунке 2.3.
Первоначально база данных приводится к первой нормальной форме.
В сущности «Сотрудник» содержится атрибут «телефон», который нарушает требования первой нормальной формы. Тогда создается новая сущность «Телефон», в которую переносятся атрибуты с неатомарными значениями, и его возможный ключ – «Номер сотрудника». Аналогична ситуация с атрибутом «оборудование» сущности «Материальная база». Таким же образом приводится данная сущность к первой нормальной форме.
Требования второй нормальной формы выполнены, так как нет сущностей со сложными первичными ключами в модели базы данных ресторана.
Рисунок 2.3 – Нормализованная модель базы данных ресторана
Далее база данных приводится к третьей нормальной форме. Неключевой атрибут «оклад» зависит от неключевого атрибута «должность» сущности «Сотрудник». Аналогична ситуация с неключевыми атрибутами «наименование поставки» и «сумма» сущности «Поставки». Тогда создается сущность «Должность», в которую переносятся зависимые от нее неключевые атрибуты, устанавливается первичный ключ «Должность» и неидентифицирующую связь между старой и новой сущностями. Аналогичные действия производятся в сущности «Поставки».
С сущностью «Поставщик» производятся следующие действия: создается сущность «Данные поставщика», в которую переносятся все неключевые атрибуты, которые зависят от неключевого атрибута «ФИО», кроме «контактного лица» и устанавливается неидентифицирующая связь между данными сущностями.
Рассматривается далее подробно сущность «Меню». Неключевой атрибут «цена» зависит от неключевых атрибутов «наименование блюда», «вес», при этом атрибут «вес» зависит от атрибута «наименование блюда», однако создание новых сущностей нерационально и усложнит структуру базы данных ресторана, поэтому атрибуты «наименование блюда» и «вес» принимаются как альтернативный первичный ключ.
В конечном итоге, база данных ресторана приведена к нормальной форме Бойса-Кодда: каждый атрибут любой сущности содержит атомарное значение, каждый неключевой атрибут полностью зависит от первичного ключа (выполнены требования второй нормальной формы) и нет зависимостей от неключевых атрибутов.
Физическая модель данных - это последний этап в проектировании той части ИС, которая отвечает за организацию данных. Для ее построения необходимо определиться с типом СУБД, так как данная модель предполагает точное описание создаваемой базы данных в терминах выбранной СУБД.
Физическая модель ресторана также строится на модели "сущность-связь" ресторана и логически создается на базе концептуальной модели.
Сущности становятся таблицами базы данных (БД). Атрибуты сущностей преобразуются в поля таблиц. Связи преобразуются в ограничения.
Атрибутам сущностей присваиваются конкретные типы полей. При помощи ограничений в БД переносятся бизнес-логика обработки и хранения данных ИС.
Концептуальная модель подвергается более тщательной нормализации и, при необходимости, денормализации.
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах.
Различают два подуровня физического уровня модели данных:
Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам баз данных лучше представлять, какие объекты базы данных хранятся в словаре данных, и проверить, насколько физический уровень модели данных удовлетворяет требованиям к ИС.
Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах.
Для того, чтобы получить физическую модель базы данных ресторана в MS Access 2000-2003 из полученной в ERwin логической модели генерируется физическая модель через встроенные процедуры Erwin. Сначала выбирается сервер. Для выбора СУБД служит редактор Target Server (меню Database/Choose Database доступно только на физическом уровне) [4].
Генерация физической модели базы данных ресторана в MS Access из ERwin отображена на рисунке 1 в приложении.
Прежде чем приступить к работе с каким-либо программным продуктом, важно понять его возможности и типы задач, для решения которых он предназначен. Microsoft Access (далее — просто Access) — это система управления базами данных (СУБД). Как и другие продукты этой категории, она предназначена для хранения и поиска данных, представления информации в удобном виде и автоматизации часто повторяющихся операций.
Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет использовать одновременно несколько таблиц базы данных. При этом можно существенно упростить структуру данных, облегчая тем самым выполнение поставленных задач [5].
Создание базы данных начинается с создания таблиц, в которых и хранится информация о предметной области. База данных обычно включает несколько взаимосвязанных таблиц.
Создать таблицу можно в разных режимах: режиме таблицы, конструктора, мастера таблиц, импорта таблиц и связи с таблицами. Самый используемый режим – режим конструктора. В режиме конструктора открывается окно для описания структуры таблицы и других ее характеристик.
Для создания таблицы необходимо открыть вкладку «Создание» и из меню «Таблицы» выбрать подходящую таблицу. В новом окне появится таблица, далее производится переход в режим «Конструктора» и осуществляется наполнение таблицы необходимой информацией, такой как: имена полей, тип данных для этих полей, ограничения на ввод данных и маски ввода и прочее.
Имя поля должно быть уникальным в пределах таблицы. И хотя система не запрещает использование одинаковых имен полей в разных таблицах, избегается использование одинаковых имен для обозначения разных по смыслу атрибутов.
После задания имени нужно выбрать тип поля. Если щелкнуть мышью по свободной ячейке графы «Тип поля», то высветится список допустимых типов полей, из которого и следует выбрать подходящий для описываемого поля тип. Имя и тип поля должны задаваться обязательно.
Графа «Описание» может не заполняться. Эта графа используется в целях документирования проекта.
В списке допустимых типов полей имеется строка «Мастер подстановок». При его использовании можно создать поле, содержание которого формируется путем выбора значений из списка, содержащего набор постоянных значений или значений из другой таблицы или запроса. Если источником для подстановки выбран столбец другой таблицы, то тип и длина поля, созданного таким способом, будут определяться типом и длиной элементов, служащих источником для подстановки значений.
Каждая реляционная таблица по определению имеет ключ. Access позволяет задавать ключ при описании таблицы, но также разрешает и отказаться от этой возможности. По ключу система автоматически выполняет индексирование, а также проверяет уникальность значений ключа при вводе новых записей или их корректировке. Создание таблиц базы данных ресторана показано на рисунке 2 в приложении.
После создания таблиц осуществляется их связывание. Схема данных базы данных ресторана отображена на рисунке 3.1.
База данных ресторана, сгенерированная в Access из Erwin, содержит следующие таблицы:
Рисунок 3.1 – Схема данных базы данных ресторана
Запросы занимают особое место в управлении данными. Они позволяют выводить сводную информацию из нескольких таблиц, анализировать ее, можно даже изменять и удалять определенные данные.
Запрос в Access может быть использован в качестве источника данных для создания форм и отчетов, обеспечивает эффективный доступ к данным (уже не требуется открывать одновременно несколько форм или таблиц и подолгу выбирать нужные сведения – с этой работой быстро справиться заранее подготовленный запрос).
В Access предусмотрены следующие типы запросов:
В базе данных ресторана реализованы следующие запросы:
Рисунок 3.2 – Запрос с параметром «Дата поставки»
Рисунок 3.3 – Запрос к связанным таблицам «Поставки», «Стоимость поставки», «Поставщик»
Остальные запросы приведены в приложении на рисунке 3-4.
Рисунок 3.4 – Сводная диаграмм запроса «Должности сотрудников»
3.3 Разработка пользовательских форм в базе данных ресторана
В базах данных Access информация вводится и обрабатывается с помощью форм. Формы являются электронными аналогами бумажных бланков и содержат области для ввода данных, называемые полями. Совокупность полей формы образует запись.
Любой элемент в базе данных Access является графическим объектом. Графические объекты, предназначенные для ввода, отображения и поиска данных, называются элементами управления. Поля формы представляют собой элементы управления. Помимо полей формы могут включать такие элементы управления, как кнопки выбора и командные кнопки.
Так как информация в базах данных постоянно обновляется, необходимо добавлять в них новые данные и удалять устаревшие. Проще всего выполнять эти функции с помощью форм.
Существует несколько способов создания форм, среди них: создание формы с помощью мастера, в режиме конструктора, использование автоформы.
Для базы данных необходимо создать простые формы и формы с вложенными подчиненными формами.
Подчиненной называется форма, вложенная в другую форму, которая считается главной. Такая структура формы позволяет просматривать данные из нескольких таблиц. Поля главной формы отображают информацию из одной таблицы, а поля подчиненной из другой. Такой подход упрощает ввод информации и обеспечивает ее достоверность, так как данные, хотя и хранятся в отдельных таблицах, связаны между собой.
В базе данных ресторана содержатся следующие пользовательские формы:
Рисунок 3.5 – Форма «Меню»
Вышеперечисленные формы приведены на рисунке 5-7 в приложении.
Информация, содержащаяся в таблицах базы данных, может быть представлена в виде документа или отчета. Как и формы, отчеты позволяют извлечь из базы нужные сведения и придать им содержательный вид. Но если формы предназначены для просмотра и корректировки данных, отчеты используются для анализа или передачи информации в другие инстанции. Отчеты могут быть напечатаны, отправлены по электронной пересланы в общую папку, а также опубликованы в Интернете, что делает их доступными для самой широкой аудитории.
Access отображает в отчете данные из запроса или таблицы, добавляя к ним текстовые элементы, которые упрощают его восприятие.
В Access можно создавать отчеты различными способами:
В базе данных ресторана с помощью мастера отчетов целесообразно были созданы следующие отчеты:
На рисунке 8-10 в приложении отображены остальные отчеты.
Рисунок 3.6 – Отчет «Поставки» базы данных ресторана
3.5 Разработка макросов в базе данных ресторана
Создание макросов в Access не требует написания программного кода. В состав Access входит набор параметрических макрокоманд для выполнения стандартных операций, таких как открытие форм и отчетов, отправка запросов, поиск записей, импорт и экспорт данных. Макросы в Access создаются путем выбора нужных значений в списках и могут содержать структуры условного ветвления. Можно настроить автоматический запуск макросов в ответ на определенные действия со стороны пользователя.
Каждая макрокоманда имеет определенное имя и, возможно, один или несколько аргументов, которые задаются пользователем.
Основное назначение макросов — это создание удобного интерфейса приложения: чтобы формы и отчеты открывались при нажатии кнопок в форме или на панели инструментов или же привычным выбором команды меню; чтобы при открытии приложения пользователь видел на экране не окно База данных (Database), наполненное множеством таблиц, запросов, форм и отчетов, а некую понятную форму, с помощью которой можно было бы сразу производить желаемые действия.
Однако использование макросов имеет и некоторые недостатки:
Тем не менее во многих случаях использование макросов вполне оправдано, так как это существенно упрощает и ускоряет разработку приложения [7].
Для удобства пользования базой данных создается главная форма с кнопками, приведенная на рисунке 3.7. Для этого в режиме конструктора форм выбирается на панели инструментов значок «кнопка» и переносится в область данных.
Рисунок 3.7 – Главная пользовательская форма ресторана
Далее создаются макросы со следующими макрокомандами:
На странице свойств в режиме конструктора в вкладке «Событие» выбирается нужный макрос напротив поля «нажатие кнопки».
Таким образом получена главная форма с пятью кнопками, при нажатии на которых открываются соответствующие формы для меню, материальной базы, поставок и работников ресторана. Пятая кнопка «Выход» закрывает базу данных ресторана. А форма поставок имеет еще одну кнопку, при нажатии на которую откроется форма поставщика.
В современных условиях любая деятельность сопряжена с оперированием большими объемами информации, которое производится широким кругом лиц. Защита данных от несанкционированного доступа является одной из приоритетных задач при проектировании любой информационной системы. Следствием возросшего в последнее время значения информации стали высокие требования к конфиденциальности данных. Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом в этой области. Обеспечение информационной безопасности СУБД приобретает решающее значение при выборе конкретного средства обеспечения необходимого уровня безопасности организации в целом.
СУБД выполняет роль посредника между пользователями приложений и данными. Также СУБД должна обеспечивать гарантии безопасности и целостности базы данных. Пользователи компьютера должны иметь возможность защитить свои данные от несанкционированного доступа, а также восстановить их в случае неких системных сбоев. Централизованное обеспечение безопасности данных – важная особенность СУБД. Наиболее значительное преимущество систем с базами данных – это централизованное обеспечение целостности данных.
Для СУБД важны три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Критерии безопасности данных могут быть определены следующим образом. Конфиденциальность данных предполагает их доступность только для тех лиц, которые имеют на это соответствующие полномочия. Целостность информации предполагает ее неизменность в процессе передачи от отправителя к получателю. Под доступностью можно понимать гарантию того, что злоумышленник не сумеет помешать работе законных пользователей. В частности, в задачу обеспечения доступности входит исключение возможности атак, вызывающих отказ в обслуживании.
Политика безопасности определяется администратором данных. Однако решения защиты данных не должны быть ограничены только рамками СУБД. Абсолютная защита данных практически не реализуема, поэтому обычно довольствуются относительной защитой информации - гарантированно защищают ее на тот период времени, пока несанкционированный доступ к ней влечет какие-либо последствия. Разграничение доступа к данным также описывается в базе данных посредством ограничений, и информация об этом хранится в ее системном каталоге. Иногда дополнительная информация может быть запрошена из операционных систем, в окружении которых работают сервер баз данных и клиент, обращающийся к серверу баз данных.
Конфиденциальная информация - информация, которая требует защиты.
В СУБД на этапе подключения к БД производится идентификация и проверка подлинности пользователей. В дальнейшем пользователь или процесс получает доступ к данным согласно его набору полномочий. В случае разрыва соединения пользователя с базой данных текущая транзакция откатывается, и при восстановлении соединения требуется повторная идентификация пользователя и проверка его полномочий.
Многоуровневая защита - защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности.
Пользователей СУБД можно разделить на три группы:
Администратор каждой базы занимается созданием круга возможных пользователей создаваемой им БД и разграничением полномочий этих пользователей. Данные о разграничениях располагаются в системном каталоге БД. Очевидно, что данная информация может быть использована для несанкционированного доступа и поэтому подлежит защите. Защита этих данных осуществляется средствами самой СУБД.
СУБД позволяет зарегистрировать пользователя и хранить информацию о его уникальном идентификаторе.
Для того, чтобы более эффективно обезопасить систему, необходимо произвести анализ и выявить, каким угрозам она должна противостоять. Это позволит детально рассмотреть наиболее уязвимые места и решить задачу защиты информации. Безопасность ИС – это комплекс организационно-технических мероприятий:
- общие меры безопасности; ни о какой информационной безопасности системы не может быть и речи, если не соблюдаются основные меры безопасности:
- физический доступ к основным ресурсам: серверы, активное оборудование. Даная угроза имеет место при бесконтрольном доступе к активному оборудованию. В результате чего злоумышленник может получить доступ к информации, произвести неправомерные действия по отношению к ней или иным образом навредить системе. Для того, чтобы избежать данную ситуацию, необходимо обеспечить физическую охрану помещения, в котором установлено активное оборудование. Данное помещение должно закрываться на ключ, правом доступа к которому должны обладать лица, имеющие для этого соответствующие полномочия, а на случай экстренной необходимости разработана система оповещения ответственных лиц;
- физический доступ к персональному компьютеру пользователя. Персональное место пользователя так же является угрозой. Для усложнения доступа к системе необходимо использовать механизмы аутентификации и идентификации пользователя. Каждый пользователь, прежде чем получить право совершать какие-либо действия в системе, должен идентифицировать себя. Обычный способ идентификации - ввод имени пользователя при входе в систему. В свою очередь, система должна проверить подлинность личности пользователя, то есть что он является именно тем, за кого себя выдает. Стандартное средство проверки подлинности (аутентификации) – пароль. Администратор в свою очередь должен позаботиться об эффективности паролей, и соответствующей настройке контроллера домена;
- прослушивание сетевого трафика. Реализовать такую атаку можно, используя сетевой анализатор. Для предотвращения этой угрозы необходимо использовать сетевые протоколы, поддерживающие защиту от несанкционированного доступа, а также конфиденциальность данных;
- подмена сетевых объектов;
- использование ненадежного программного обеспечения;
- заражение вирусами;
- технические сбои оборудования;
- человеческий фактор[8].
К информации в базе данных ресторана имеют доступ следующие группы пользователей:
Для данных групп пользователей создаются пароли в вкладке «Пользователи и разрешения».
Система защиты паролем приведена на рисунке 3.8.
Рисунок 3.7 – Защита паролем базы данных ресторана
ЗАКЛЮЧЕНИЕ
В ходе выполнения курсовой проекта были решены следующие задачи:
В процессе создания базы данных были проанализированы основные проблемы обычного бумажного документирования данных и нахождения альтернативного способа хранения информации о деятельности ресторана.
Упрощение, оптимизация и модернизация работы с информацией, практичность, открытость к дополнениям и надстройкам, простота сопровождения – цели, поставленные на начальном этапе проектирования курсового проекта, достигнуты.
Готовая база данных ресторана может активно применяться сотрудниками предприятий питания, что обеспечит быстрый и удобный доступ ко всем необходимым данным. В разработанную базу данных ресторана просто добавлять, удалять данные и модифицировать ее структуру. Также база данных может быть доработана соответствующим программным обеспечением, направленным на поддержание информационной безопасности данных и защите данных от несанкционированного доступа.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ
Рисунок 1 – Генерация физической модели базы данных ресторана в MS Access из ERwin
Рисунок 2 – Создание таблиц в базе данных ресторана в Access
Рисунок 3 – Запрос на сотрудников с окладом, меньшим 15 т. р.
Рисунок 4 – Запрос к связанным таблицам «Рабочие_места_сотрудников»
Рисунок 5 – Форма «Оклад»
Рисунок 6 – Форма «Материальная база»
Рисунок 7 – Форма «Поставки»
Рисунок 8 – Отчет «Даты_поставок»
Рисунок 9 – Отчет «Сотрудники»
Рисунок 10 – Отчет «Меню»