Разработка автоматизированной системы управления производственными процессами ресторана 'Альянс'

Дипломный проект

на тему: Разработка автоматизированной системы управления производственными процессами ресторана «Альянс»

Реферат

Целью работы является разработка программного обеспечения для автоматизации производственных процессов и формирования аналитических отчетов для ресторана ООО «Альянс». В основе построения АСУПП лежит разработка базы данных, реализующей хранение данных, организацию доступа к ним и редактирование. Методом выполнения работы является построение реляционной базы данных средствами Microsoft Access. Результатом выполнения работы является создание программного обеспечения “Автоматизированная система управления производственными процессами ресторана «Альянс».

Область применения разработанного программного комплекса - коммерческая деятельность ООО «Альянс», повышение эффективности организации информационных потоков на предприятии.

Введение

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

Проблема разработки автоматизированных систем управления для таких организаций, как рестораны и кафе, до настоящего времени не была предметом специального общего исследования. В основном в литературе рассматриваются общие вопросы организации информационных систем и систем документооборота на предприятиях такого профиля, а также проводится анализ отдельных технологических разработок. Из обширного круга различных публикаций по проблемам автоматизации процессов управления и документооборота наиболее привлекательными для данной темы представляются изданные в последнее время научно-методические разработки по вопросам проектирования систем корпоративного электронного документооборота, среди которых выделяется работа М. В. Бобылевой [6], коллективная работа Д. А. Романова, Т. Н. Ильиной, А. Ю. Логиновой [31], недавно вышедшие из печати книги А. В. Данилина [10] и работа В. А. Конявского и В. А. Гадасина [20], научный доклад Н. Н. Куняева [21], переводное издание книги американского специалиста Майкла Дж. Саттона [22]. В данных работах содержатся взгляды на электронный документооборот и различные элементы системы электронного обмена информацией, основанные на использовании компьютерных информационных технологий, излагаются методические основы их внедрения, обобщен отечественный и зарубежных опыт постановки задач и разработки решений в данной отрасли, требующих интеграции различных информационных платформ и аппаратно-программных средств.

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

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

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

Объектом дипломного исследования является система автоматизации производственно-технологических процессов в ресторане ООО «Альянс».

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

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

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

Методы исследования, применяемые в работе:

Кабинетные исследования (работа со вторичной информацией)

Опросы клиентов и сотрудников ресторана

Наблюдение

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

1. Аналитическая часть

 

. 1 Общая характеристика ресторана ООО "Альянс"

Ресторан «Альянс» имеет организационно-правовую форму общества с ограниченной ответственностью. Ресторан “Альянс” является малым предприятием, т. к. численность работающего персонала не превышает 50 человек. Ресторан «Альянс» является рестораном категории Люкс. Ресторан расположен в нескольких минутах ходьбы от метро «Беляево», имеет удобное территориальное расположение на пересечении нескольких крупных улиц, перед рестораном расположена удобная автомобильная парковка.

Ресторан «Альянс» располагается в г. Москве по адресу: улица 35-я Гвардейская д. 1. Зал рассчитан на 60 посадочных мест. В состав здания входят: производственные помещения, административные помещения, бытовые помещения для персонала, торговый зал, фойе. В состав производственных помещений входят; горячий цех, холодный цех, цех доработки полуфабрикатов, овощной цех, моечная кухонной посуды, моечная столовой посуды, сервизная столовой посуды. К административным помещениям причисляют кабинет директора, бухгалтерию, кабинет зав производством. К бытовым помещениям относят раздевалку для персонала, душевую и туалетные комнаты.

При входе в ресторан «Альянс» расположено фойе. В фойе предусмотрены: гардероб, туалетные комнаты, пост охраны. Торговый зал ресторана «Альянс» разделен на 2 части, образуя при этом большой и малый зал. В малом зале предусмотрена барная стойка с высокими стульями для посетителей и небольшое количество четырехместных столов. В большом зале располагается касса для расчета с клиентами, установка для диджея, сцена и по периметру зала расставлены 8 - 10-местные столы.

Ресторан «Альянс» - это общедоступное предприятие общественного питания, предоставляющее потребителям широкий ассортимент блюд сложного приготовления, в основном по индивидуальным заказам, а также вино-водочные, табачные и кондитерские изделия. Высокий уровень обслуживания сочетается с организацией отдыха посетителей. Услуги ресторана «Альянс» оказываются в соответствии с правилами оказания услуг общественного питания, которые утверждены постановлением Правительства РФ от 15. 03. 02, а так же с Общероссийским классификатором услуг населению ОК 022-93 и ГОСТом Р. 50764-01. Услуги должны содержать: перечень услуг и условия их организации, цены, фирменное наименование предлагаемых услуг, сведения о весе (объеме) порций готовых блюд, сведения о сертификации услуг, подлинный сертификат, копию сертификата. Все услуги предприятия должны иметь сертификат, табачные и алкогольные товары лицензию позволяющие продажу данного вида товара. [40, стр. 76-78]. Услуги, предоставляемые рестораном «Альянс», сведены в таблицу 1. 1.

Таблица 1. 1 Услуги, предоставляемые рестораном «Альянс»

Код	КЧ	Наименование
12200	0	Услуги общественного питания
122100	4	Услуги питания
122101	2	Услуга питания ресторана
122200	8	Услуги по изготовлению кулинарных и кондитерских изделий.
122201	3	Изготовление кулинарной продукции и кондитерских изделий по заказам потребителей, в том числе в сложном исполнении и с дополнительным оформлением на предприятиях общественного питания
122300	1	Услуги по организации потребления и обслуживания
122303	8	Организация и обслуживание торжеств, семейных обедов и ритуальных мероприятий
122310	б	Бронирование мест в зале предприятий общественного питания
122313	2	Организация рационального комплексного питания
122500	9	Услуги по организации досуга
122501	4	Услуги по организации музыкального обслуживания
122502	1	Организация проведения концертов, программ варьете и видеопрограмм
122600	2	Информационно-консультативные услуги
122601	8	Консультация специалистов по изготовлению, оформлению кулинарной продукции и кондитерских изделий, сервировке столов
122603	9	Организация обучения кулинарному мастерству
122700	2	Прочие услуги общественного питания
122704	8	Гарантированное хранение ценностей потребителей
122705	3	Вызов такси по заказу потребителя (посетителя предприятия общественного питания)
122706	9	Парковка личных автомобилей потребителя на организованную стоянку у предприятия общественного питания

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

Меню ресторана составляют

холодные закуски;

горячие закуски;

супы;

промежуточные блюда;

горячие блюда;

салаты;

десерты;

фирменные блюда;

шоколадные и кондитерские изделия;

горячие и холодные напитки;

безалкогольные и алкогольные напитки;

коктейли.

Примерный ассортимент блюд (Ассортиментный минимум) - это определенное количество наименований холодных блюд, горячих блюд, напитков [33, стр. 81-84]. Примерный ассортимент выпускаемой и реализуемой продукции для ресторана «Высшего» класса приведен в таблице 1. 2

Таблица 1. 2 Ассортиментный минимум блюд ресторана

Холодные блюда и закуски	10
Горячие закуски	2
Супы	4
Горячие блюда	11
Сладкие блюда	4
Напитки	4
Кондитерские изделия	5

автоматизированный производство управление ресторан

Ресторан «Альянс» имеет, кроме обычной вывески, вывеску световую с элементами оформления. У ресторана имеются удобные подъездные пути для транспорта, а также охраняемая автостоянка. Применяется посуда из мельхиора, нержавеющей стали, фарфоро-фаянсовая с монограммой, из хрусталя. Ресторан работает с 9. 00 до 4. 00 часов утра, 312 дней в году. Целевые группы: семьи, туристы, посетители культурных учреждений, представители фирм, коммерсанты.

Степень централизации ООО ресторана “Альянс” - средняя, т. к. функции распределены по управленческому персоналу.

ООО "Альянс" имеет разветвленную централизованную иерархическую структуру управления, которая приведена на рис. 1. 1.

Рис. 1. 1. Схема организационно-функциональной структуры предприятия ООО "Альянс".

Возглавляет работу ресторана “Альянс” - директор, который назначается высшим органом управления - общим собранием участников.

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

обеспечение бракеража готовой пищи;

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

составление графиков выхода на работу;

проведение инструктажа по технике безопасности на рабочем месте;

своевременное составление и предоставление в бухгалтерию отчетов об использовании товарно-материальных ценностей;

расстановка работников на рабочих местах в соответствии с их квалификацией;

установление дисциплины.

Функции учета, планирования и различные финансовые операции выполняют работники бухгалтерии. Ее возглавляет главный бухгалтер.

Инженерно-эксплуатационную службу ресторана возглавляет инженер-технолог.

Отделом по закупкам и складам руководит руководитель по закупкам. Его функции:

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

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

проверяет все складские запасы и следит за их своевременным пополнением;

учитывает в своей работе основные направления развития и управления предприятием;

организует и контролирует использование персонала в сферах складирования и закупок;

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

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

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

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

руководит своей сферой с учетом основных производственных направлений развития фирмы;

организуют, руководит, контролирует работу всех занятых на кухне сотрудников;

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

осуществляет контроль за качеством.

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

Действующее штатное расписание ООО «Альянс» имеет вид:

Таблица 1. 3 Штатное расписание смены ООО «Альянс»

№ п/п	Наименование должностей	Численность	Оклад (ставка)	Сумма окладов
1.	Административно-управленческий персонал:
	Директор	1	30000, 00	30000, 00
	заместитель директора	1	25000, 00	25000, 00
	Главный бухгалтер	1	25000, 00	25000, 00
	Итого:			80000
2.	Работники производства:
	зав. производством	1	23000, 00	23000, 00
	повар-бригадир	2	20000, 00	40000, 00
	Повар	2	17000, 00	34000, 00
	кухонный работник	2	7000, 00	14000, 00
	Итого:			111000
3.	Работники зала:
	Кассир	2	10000, 00	20000, 00
	Официант	2	1500, 00	30000, 00
	Бармен	2	12000, 00	24000, 00
	Администратор	2	20000, 00	40000, 00
	Уборщица	2	9000, 00	18000, 00
	Итого:			132000
4.	Прочие рабочие:
	ди-джей	1	15000, 00	15000, 00
	Охрана	3	10000, 00	30000, 00
	Бухгалтер	1	20000, 00	20000, 00
	Калькулятор	1	17000, 00	17000, 00
	Гардеробщица	2	6000, 00	12000, 00
	Итого:			94000
	Всего:	28		417000

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

ООО ресторан “Альянс” делает упор на два метода управления: экономические и социально-психологические. Выбор в пользу этих методов сделан по причине небольшого размера организации и особенностей работающего коллектива. Именно в следствие верного и совместного труда всего персонала предприятие является прибыльным.

В ООО ресторане “Альянс” обязанности по оперативному управлению поделены между метрдотелем и заведующим производством. Эти люди постоянно согласовывают свои действия друг с другом. Метрдотель контролирует работу зала.

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

Миссия ООО ресторан “Альянс”:обеспечить культурный отдых, освободить людей от повседневных забот. Цель деятельности ООО: получение прибыли, удовлетворение потребностей.

 

. 2 Анализ конъюнктуры рынка услуг общественного питания

Для исследования рынка необходимо тщательно изучить маркетинговую среду фирмы (предприятия). Среда фирмы складывается из микросреды и макросреды. Микросреда представлена субъектами, имеющими непосредственное отношение к самой фирме и ее возможностям по обслуживанию клиентуры, то есть поставщиками, маркетинговыми посредниками, клиентами, конкурентами и контактными аудиторами. Макросреда представлена силами более широкого социального плана, такими, как факторы демографического, экономического, природного, экологического, технического и культурного характера, которые оказывают влияние на микросреду [1, стр. 107].

Исходя из этого, определим факторы микросреды и макросреды, влияющие на рынок услуг, предоставляемых рестораном.

Таблица 1. 4 Факторы микросреды, влияющие на рынок услуг ресторана.

Положительные факторы	Отрицательные факторы
1. Бесперебойность работы ресторана.  2. Стабильность поставок сырья.  3. Приобретение новых потребителей.  4. Потребители удовлетворены качеством, оказываемых услуг.  5. Положительное отношение контактной аудитории.  6. Нестабильная работа конкурентов.	1. Задержки в работе, связанные с настроением работников.  2. Нестабильность поставок сырья.  3. Потеря существующих связей с потребителями.  4. Неудовлетворенность потребителей качеством продукции.  5. Отрицательное отношение контактной аудитории.  6. Стабильная работа конкурентов.

Таблица 1. 5 Факторы макросреды, влияющие на рынок услуг ресторана.

Положительные факторы	Отрицательные факторы
1. Принятие законов, предусматривающих льготы для производителей такого вида услуг.  2. Повышение общего уровня покупательной способности.  3. Спад инфляции.  4. Снижение уровня безработицы.  5. Рост уровня образования.  6. Быстрый рост субкультур.  7. Быстрое изменение в ценностях и идеях.  8. Использование новых технологий.	1. Принятие законов, ущемляющих права производителей услуг.  2. Снижение общего уровня покупательной способности.  3. Рост инфляции.  4. Увеличение уровня безработицы.  5. Снижение уровня образования.  6. Медленный рост субкультур.  7. Медленное изменение в ценностях и идеях.  8. Не использование новых технологий.

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

1. Создать производственные запасы.

2. Наладить контакты с новыми поставщиками.

3. Постоянно контролировать настроение работников.

4. Постоянный поиск нового рынка сбыта.

5. Действовать по обстоятельствам.

Цель исследования рыночного сегмента состоит в оценке существующей ситуации и разработке прогноза развития рынка [1, стр. 117].

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

посредством анкетирования собрать информацию о потребностях населения (см. Приложение 1);

посредством построения дерева потребностей определить пути удовлетворения общей потребности (см. Приложение 2);

посредством построения субъектно - объектной схемы определить конкретный способ удовлетворения потребности (см. Приложение 3);

посредством составления портрета потребителя определить емкость рынка.

Сегментация дает возможность:

более точно очертить целевой рынок в значениях потребностей клиентов;

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

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

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

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

Сегментация рынка будет проводиться по уровню доходов и по возрасту. Потенциальную емкость рынка можно определить следующим образом: При определении емкости будет рассматриваться население района м. Беляево в непосредственной близости к месту расположения ресторана - 30-минутная транспортная доступность. Численность населения в районе составляет 371, 1 тыс. чел. ; взрослое население составляет 59, 4%, что в абсолютных величинах составит: 371100 чел. * 0, 594 = 220433 человек.

Итак, потенциальная емкость нашего рынка составляет 220433 чел.

Рис. 1. 2. Сегментация рынка по уроню дохода

Рис. 1. 3. Сегментация рынка по возрасту

Анализируя ситуацию на рынке сбыта услуг ресторана можно прийти к выводу, что основными конкурентами являются ресторан «Астория», ресторан «Вечерняя Москва». Их продукция почти всегда отличается хорошим качеством, широким ассортиментом. Основной недостаток - достаточно высокие цены. Результаты исследования конкурентов можно представить в виде сравнительной таблицы:

Таблица 1. 6 Балльная оценка основных показателей конкурентов ресторана «Альянс»

Параметр	Ресторан «Астория»	Ресторан «Вечерняя Москва»	Ресторан «Альянс»
1. Качество продукции	4	4, 5	5
2. Качество обслуживания	4	3	5
4. Цена	4	4	5
5. Реклама	2	3	5
6. Месторасположение	4	5	5
7. Привлекательный внешний вид (вывеска, фасад )	4	4	5
8. Интерьер ресторана	4	4	5

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

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

Таблица 1. 7 Матрица конкурентной реакции

Услуги ресторана “Андромеда”	Услуги ресторана «Астория»			Услуги ресторана «Вечерняя Москвас»
	Цена	Реклама	Качество	Цена	Реклама	Качество
Цена	5%	10%	5%	10%	12%	5%
Реклама	2%	5%	2%	5%	5%	3%
Качество	10%	2%	10%	15%	2%	10%

Если изменить цену на услуги (ресторан «Альянс»), то есть снизить на 10%, то конкуренты вынуждены будут снизить цены: ресторан «Астория» - на 5%, а ресторан «Вечерняя Москва» - на 10%, при этом им придется увеличить расходы на рекламу соответственно: на 10% и на 12%; им также придется улучшить качество соответственно: на 5% и на 5%.

Если увеличить расходы на рекламу на 10%, то «Астория» снизит свои цены на 2%, а «Вечерняя Москва» - на 5%. Им придется увеличить расходы на рекламу соответственно на 5% «Астории» и на 5% «Вечерняя Москва» и улучшить качество услуг «Астории» на 2%, «Вечерняя Москва» на 3%.

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

 

. 3 Анализ хозяйственной деятельности ООО "Альянс"

 

. 3. 1 Анализ экономических показателей деятельности предприятия

Общими задачами анализа хозяйственной деятельности предприятия сферы услуг могут являться следующие [13, стр. 66-68]:

1.       Изучение и объективная оценка результатов работы предприятия;

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

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

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

.        Контроль за экономным использованием всех имеющихся у предприятия ресурсов (трудовых, материальных, финансовых и т. п. ).

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

.        Обоснование управленческих решений

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

За анализируемый период финансовым результатом деятельности ООО была прибыль, причем ее размер увеличивался от года к году. Так, прибыль от продаж возросла на 31, 9%, а чистая прибыль - на 30, 4%. Однако отметим, что ресторан имеет достаточно низкий показатель рентабельности для предприятий сферы услуг, который кроме того, склонен к снижению. Эффективность использования основных и оборотных фондов в 2011 году снижается, о чем свидетельствуют пониженные значения фондоотдачи и оборачиваемости оборотных средств.

В таблице 1. 8. представлена характеристика основных экономических показателей деятельности ООО "Альянс".

Таблица 1. 8 Анализ экономических показателей деятельности предприятия

Показатели	Ед. изм.	2010	2011	Абс. Откл. 2011/2010	Относительное откл. От 2010 года
					Темп роста (%)	Темп прироста %
1. Выручка от продаж	Тыс. руб.	146750	156560	9810	106, 6	6, 6
2. Себестоимость услуг	Тыс. руб.	131640	140550	8910	106, 7	6, 7
3. Прибыль от продаж услуг	Тыс. руб.	15110	16010	900	105, 9	5, 9
4. Прибыль до н/о	Тыс. руб.	15110	16010	900	105, 9	5, 9
5. Чистая прибыль	Тыс. руб.	11480	12170	690	106, 1	6, 1
6. Численность работников	Чел.	58	62	4	106, 9	6, 9
7. Среднегодовая стоимость ОФ	Тыс. руб.	30970	35800	4830	115, 6	15, 6
8. годовой остаток оборотных средств	Тыс. руб.	20950	26320	5370	125, 6	25, 6
9. выработка на 1 работника	Тыс. руб.	253, 0	2525	-5	99, 8	-0, 2
10. Затраты на 1 рубль объема услуг	руб.	0, 89	0, 90	+0, 1	98, 9	-1, 2
11. Рентабельность	%	7, 8	7, 7	-0, 1	99, 9	-0, 1
12. Фондоотдача	Руб.	4, 8	4, 4	-0, 4	91, 7	- 8, 3
13. Фондоемкость	Руб.	0, 21	0, 23	0, 02	109, 5	+9, 5
14. Фондовооруженность	Тыс. руб. / чел.	534	577	43	108, 0	+0, 2
15. Фондорентабельность	%	37, 1	33, 9	-3, 2	91, 4	-8, 6
16. К-т обрачиваемости		7, 0	5, 9	-1, 1	84, 2	-15, 8
18. Длительность оборота оборотных средств	дней	51, 4	61, 0	9, 6	118, 7	18, 7

1. 3. 2 Анализ объема реализации услуг

Показатели объема реализации и себестоимости услуг являются основными производственными результатами деятельности предприятия. Анализ объема продажи услуг начинается с характеристики целевых рынков сбыта услуг. В первую очередь необходимо определить тип рынка, на котором действуем предприятие. От типа рынка во многом зависят объем реализации услуг, их себестоимость, средний уровень цен, сумма полученной прибыли, рентабельность и др. Например, “рынок продавцов” характеризуется повышенным спросом на услуги и сравнительно небольшим количеством предприятий оказывающих эти услуги. Как правило, это монополизированные рынки. Цены на таких рынках могут быть необоснованно завышенными, а качество при этом оставаться низким. «Рынок покупателей» - это рынок, на котором предложение превышает спрос. Для данного типа рынка характерно большое число предприятий, функционирующих в условиях конкуренции. Качество услуг на этих рынках, как правило, полностью соответствует цене на них. Основными показателями величины рынка (количественными показателями) являются емкость рынка и рыночная доля предприятии [1, стр. 104].

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

В таблице проведем анализ динамики объема продажи услуг ООО на 2005-2011 год.

Таблица 1. 9 Анализ объема продажи услуг ООО “Альянс” за 2005-2011 г. (в сопоставимых ценах)

Показатели	2005 г	2010г	2011 г.
1. Объем продажи услуг	128530	146750	156560
2. Абсолютное отклонение от базисного года	-	18220	9810
3. Общее отклонение от базисного года	-	1822	28030
4. Темпы роста (в %) к предыдущему году	-	114, 2	106, 7
5. Темпы прироста (в %) к предыдущему году	-	14, 2	6, 7

Из таблицы 1. 9 видно , что основной рост объема продаж услуг наблюдался в 2010 году по сравнению с 2005 годом. Темп роста в 2011 году ниже темпа роста объема продаж в 2010 году.

Далее проведем анализ структуры услуг предприятия. В ходе данного анализа определяется удельный вес каждого вида реализуемых предприятием услуг, в каждом из рассматриваемых периодов. Результаты анализа оформляются в соответствии с таблицей 1. 10. В деятельности ООО произошли следующие структурные сдвиги:

Почти на 6% произошло увеличение доходов от проведения банкетов и торжеств, однако реализация продукции собственного производства снизилась на 6%.

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

Таблица 1. 10. Оценка структуры услуг предприятия

Виды услуг	Объем продажи услуг		Структура услуг(в %)
	2010	2011	2010	2011
Оказание услуг общепита	99310	105440	67, 7	67, 3
Проведение банкетов и торжеств	11400	21450	7, 8	13, 7
Оказание услуг «обеды на дом»	3320	4480	2, 3	2, 9
Реализация продукции собственного производства через розничную торговлю	32720	25190	22, 3	16, 1
Итого	146750	156560	100	100

Данные о выполнении плана товарооборота и его составе приведены в таблице 1. 11.

Таблица 1. 11 Оценка выполнения плана товарооборота в 2011 году, тыс. руб.

Месяцы	Товарооборот ООО “Альянс”				Общий объем товаро-оборота	Месячный план това-рооборота	Откло нение от плана	Выпол нение плана, %
	Реализация продукции собственного производства	В % к общему объему т/о	Продажа покупных товаров	В % к общему объему т/о
Июнь	7010	90, 7%	7170	9, 3%	7730	7480	+ 250	103%
Июль	8180	90, 9%	8150	9, 1%	9000	8790	+ 210	102%
Август	4940	90, 4%	5250	9, 6%	5460	8020	-256	68%
Сентябрь	2710	86, 1%	4380	13, 9%	3150	8270	-511	38%
Октябрь	4190	80, 7%	1 0030	19, 3%	5200	8500	-32	61%
Ноябрь	9270	86, 2%	1 4910	13, 8%	1070	8600	+216	125%
Декабрь	1080	84, 3%	2 0350	15, 7%	1290	8650	+428	149%

Важным показателем, характеризующим торгово-производственную деятельность предприятия, является доля продукции собственного производства в общем объеме товарооборота. Этот показатель за исследуемые месяцы в среднем составил 87, 1%, что является достаточно высоким уровнем для предприятий питания. Однако по сравнению с июнем 2010 года доля реализации продукции собственного производства имеет тенденцию спада. Она снизилась с 90, 7% до 86, 2%. Наиболее вероятной причиной этого является продолжающийся рост числа новых баров и кафе, открываемых ООО “Альянс”, которые реализуют в основном покупные изделия.

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

Поэтому далее следует проанализировать товарооборот ресторана за три месяца 2011 года, по которым не был выполнен план, путем вычисления сезонной волны методом простой средней (табл. 1. 12).

Таблица 1. 12 Анализ сезонности способом простой средней арифметической (товарооборот ресторана, в тыс. руб. )

Месяц	Декада			Итого за месяц	Среднедекадные уровни по месяцам
	1	2	3
Август	1240	2400	1810	5450	1817
Сентябрь	2300	840	1190	4330	1443
Октябрь	1770	2070	1350	5190	1730
Итого	5310	5310	3170	13790	4597
Подекадные сред. уровни	1770	1730	4520	8720	2907
Сезонная волна, %	115, 6	115, 5	68, 9	300, 0	100, 0

Средний декадный объем продаж за весь период в целом вычисляется как отношение общей суммы продаж к числу периодов, т. е. 4597/9 или как средняя арифметическая простая из декадных средних:

(5310+5310+3170 )/3 = 4597/3 = 1532 тыс. руб.

Из таблицы 1. 10 видно, что самый низкий уровень товарооборота ресторанного комплекса был в 3 декаде, но это объясняется тем, что с 14 по 30 сентября ресторанный комплекс был закрыт по техническим причинам.

В среднем за все три месяца (август, сентябрь, октябрь) он оказался ниже на 31, 1% (68, 9% - 100, 0%) среднедекадного товарооборота. В 1 и 2 декадах уровень товарооборота практически одинаковый, и выше среднедекадного на 15, 6% и 15, 5% соответственно.

Это во многом объясняется увеличением числа туристов в соседней гостинице, и, следовательно, посетителей ресторанного комплекса в данные периоды. Поскольку 53% потребителей приехали в гостиницу именно по работе (в командировку), то можно ожидать, что в летнее время значительных колебаний товарооборота в связи с увеличением спроса на туристические услуги не произойдет.

 

. 4 Анализ прибыли и рентабельности

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

Для этого выручку корректируют на средневзвешенный индекс роста цен на продукцию предприятия в среднем по отрасли, а затраты по реализованной продукции уменьшают на их прирост в результате повышения цен на потребленные ресурсы за анализируемый период [31, стр. 45-51]. .

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

Таблица 1. 13 Анализ состава налогооблагаемой прибыли ресторана «Альянс»

Состав налогооблагаемой прибыли	2010	2011	Абс. отклонение
1. Прибыль (убыток) от продаж услуг	15110	16010	900
2. Сальдо операционных доходов и расходов: В т. ч.  - операционные доходы  - операционные расходы	0 0 0	0 0 0	-
3. Сальдо внереализационных доходов и расходов: В т. ч.  - внереализационные доходы  - внереализационные расходы	0 0 0	0 0 0
4. Налогооблагаемая прибыль	15110	16010	900

За анализируемый период финансовым результатом деятельности ООО была прибыль, причем ее размер увеличивался от года к году. Так, прибыль от продаж возросла на 31, 9%, а чистая прибыль - на 30, 4%.

Прибыль от реализации продукции в целом на предприятии зависит от четырех факторов первого уровня соподчиненности: объема реализации продукции; ее структуры; себестоимости и уровня среднереализационных цен.

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

Изменение уровня среднереализационных цен и величина прибыли находятся в прямо пропорциональной зависимости: при увеличении уровня цен сумма прибыли возрастет, и наоборот. Далее проведем анализ прибыли от продажи услуг (таблица 1. 14. ).

Таблица 1. 14 Анализ прибыли от продажи услуг предприятия

Состав налогооблагаемой прибыли	В 2010 году		2011 год
	С учетом объема продаж услуг 2004 г.	В пересчете на объем продажи услуг 2005 г
1. Объем продажи услуг	146750	156560	156560
2. Себестоимость услуг	131640	140550	140550
3. Прибыль от продажи услуг	15110	24920	24920

Таким образом, в пересчете на объем продажи услуг 2011 года прибыль увеличилась бы на 9810 тыс. руб.

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

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

Основные факторы	Расчет влияния основных факторов на прибыль
1. Изменение физического объема	(156560-146750) = 9810
2. Изменение цен на услуги	Не было
3. Изменение себестоимости услуг	(140550-131640) = 8910
4. Изменение структуры услуг	Не было
Изменение прибыли от продаж	9810

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

Далее проведем анализ рентабельности продажи услуг ресторана. За анализируемый период финансовым результатом деятельности ООО “Альянс” была прибыль, причем ее размер увеличивался от года к году. Так, прибыль от продаж возросла на 31, 9%, а чистая прибыль - на 30, 4%.

Таблица 1. 16 Анализ рентабельности ресторана

Показатели	2005 г.	2010 г.	2011 г.	Темп роста 2011 г. к 2005 г. , %
Выручка от продаж, тыс. руб.	128530	146750	156560	121, 8
Себестоимость реализованной продукции, тыс. руб.	116390	131640	140550	120, 7
Прибыль от продаж, тыс. руб.	12140	15110	16010	131, 9
Чистая прибыль, тыс. руб.	9330	11480	12170	130, 4
Рентабельность продаж, %	9, 4	10, 3	10, 3	-
Рентабельность произведенных затрат, %	10, 4	11, 5	11, 4	-
Рентабельность совокупного капитала, %	21, 8	21, 4	18, 7	-
Рентабельность собственного капитала, %	26, 0	26, 1	26, 5	-

1. 5 Оценка эффективности хозяйственной деятельности

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

Таблица 1. 17 Оценка экстенсивности экономического развития

Показатели	2010	2011	Отклонение
			+/-	%
1. Среднесписочная численность работников	58	62	4	106, 9
2. Фонд оплаты труда работников	83520	119040	35520	142, 5
3. Среднегодовая стоимости ОПФ	30970	35800	4830	115, 6
4. Годовой остаток оборотных средств	20950	26320	5370	125, 6
5. Материальные затраты	70420	89190	18770	126, 7

Все показатели экстенсивности экономического развития ресторана в 2011 году возросли. Для проведения анализа эффективности общей деятельности ресторана необходимо провести анализ интенсивности экономического развития ресторана.

Таблица 1. 18 Оценка интенсивности экономического развития

Показатели	2010	2011	Отклонение
			+/-	%
1. Среднегодовая выработка одного работника	2530	2525	-0, 5	98, 8
2. Среднемесячная зарплата	12000	16000	4000	133, 3
3. Фондоотдача	4, 8	4, 4	-0, 4	91, 7
4. Коэффициент оборачиваемости	7	5, 9	-1, 1	84, 2

В 2011 году наблюдается снижение основных показателей интенсивности развития предприятия, что говорит о неэффективности управления основными видами ресурсов предприятия. Так при росте заработной платы на 33% в 2011 году наблюдается снижение общей выработки продукции одним работником на 1, 2%. Наблюдается также и снижение фондоотдачи (0, 4) и коэффициента оборачиваемости оборотных средств (-1, 1), что также отрицательно влияет на деятельности предприятия и говорит о неэффективности управления данными видами активов.

Таблица 1. 19 Использование ресурсов на предприятии

Виды ресурсов	Прирост на 1% прироста объема реализации услуг	Доля влияния на прирост объема реализации услуг		Относительная экономия (перерасход) ресурсов
		экстенсивности	интенсивности
1. Численность работников	0, 31	6, 9	-1, 2	5, 7
2. ФОТ	1, 95	6, 9	-33, 3	-26, 4
3. Основные производственные фонды	0, 71	15, 6	-8, 3	7, 3
4. Оборотные активы	1, 17	25, 6	-15, 8	9, 8
5. материальные ресурсы	1, 22	26, 7	5, 8	32, 5

Таким образом из таблицы 1. 19 видно, что практически все показатели интенсивности отрицательны, а экстенсивности напортив - положительны, на что ресторану необходимо обратить особе внимание.

В заключении проведем анализ деловой активности на основании показателей оборачиваемости (табл. 1. 20).

Таблица 1. 20 Показатели оборачиваемости

Показатели	2005 г.	2010 г.	2011 г.	Абсол. изменение 2011г. от 2005 г.
Выручка от продаж, тыс. руб.	128530	146750	156560	28030
Дебиторская задолженность, тыс. руб.	3760	9880	15830	12070
Запасы и затраты, тыс. руб.	8680	9970	10250	1570
Оборотные активы, тыс. руб.	13490	20950	26320	12830
Кредиторская задолженность, тыс. руб.	6870	9690	10010	3140
Собственный капитал, тыс. руб.	3587	4396	4598	1011
Оборачиваемость дебиторской задолженности, раз	34, 2	14, 9	9, 9	-24, 03
Оборачиваемость запасов, раз	14, 8	14, 7	15, 3	0, 5
Оборачиваемость оборотных активов, раз	9, 5	7, 0	5, 9	-3, 6
Оборачиваемость кредиторской задолженности, раз	18, 7	15, 1	15, 6	-3, 1
Оборачиваемость собственного капитала, раз	3, 6	3, 3	3, 4	-0, 2
Продолжительность одного оборота дебиторской задолженности, дней	11	24	36	25
Продолжительность одного оборота запасов, дней	24	24	24	-
Продолжительность оборота оборотных активов, дней	38	51	61	23
Продолжительность оборота кредиторской задолженности, дней	19	24	23	4
Продолжительность оборота собственного капитала, дней	100	109	106	6

За анализируемый период скорость оборота снизилась. Об этом свидетельствует увеличение продолжительности оборота по всем рассматриваемым пунктам.

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

 

. 6 Организационно-экономическая характеристика предметной области автоматизации на ООО «Альянс»

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

Оперативное планирование в ресторане «Альянс» включает в себя следующие элементы [40, стр. 114-119]:

1. Составление планового меню на неделю и разработку на его основе меню- плана, отражающего дневную программу предприятия.

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

3. Оформление требования - накладной на отпуск продуктов из кладовой.

. Распределение сырья между цехами и бригадами.

. Производственная программа составляется на основании:

. Графика загрузки торгового зала и расчета посетителей.

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

8. Составление плана - меню.

9. Расчет сырья, необходимого для приготовления данных блюд.

10. Составление технологических карт.

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

Используемая конфигурация программного комплекса "1С:Предприятие 8. 0" включает в себя платформу и прикладные решения, разработанные на ее основе, для автоматизации деятельности бухгалтерии, администрации и отдела кадров. Финансово-экономический отдел в настоящее время не использует программные решения от 1:С, его информационная система основана на программных продуктах фирмы «Галактика», наиболее подходящих для решения стоящих перед подразделением задач финансового анализа и прогнозирования. При этом продукты «галактика» и 1:С работают в единой информационной системе, поскольку программные решения обеих фирм позволяют использовать практически все документы в обеих программных комплексах совместно. Такой подход позволяет автоматизировать различные виды деятельности, используя единую технологическую платформу. Гибкость платформы позволяет применять 1С:Предприятие 8. 0 в самых разнообразных областях:

автоматизация бухгалтерского учета в полном объеме, в том числе и процессов начисления заработной платы;

автоматизация работы отдела кадров ресторана;

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

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

решение задач планирования, бюджетирования и финансового анализа;

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

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

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

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

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

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

План-меню составляется специалистами отдела планирования. В основе плана-меню лежат уже сформированные заказы (в среднем, уровень обеспеченности ресторана предварительными заказами составляет сейчас около 70-75% в зависимости от сезона) и анализ статистики заказов, позволяющий выявить сезонные закономерности посещаемости и предпочтений клиентов. Источниками оперативной информации для отдела планирования является информация, поступающая от менеджеров ресторана, работающих с корпоративными и постоянными клиентами. Источниками аналитической информации являются статистические данные, формируемые руководителями смен и содержащие исчерпывающие данные о заказах за смену. Аналитическая обработка производится с использованием программного комплекса «Галактика 5. », которые в настоящее время полностью удовлетворяет всем стоящим перед отделом планирования задачам.

Таким образом, процесс оперативного планирования на ООО «Альянс» можно представить в виде следующей схемы:

Рис. 1. 4. Основные информационные потоки на ООО «Альянс»

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

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

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

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

Наконец, одна из приоритетных задач, которые сейчас ставят рестораторы, в частности, руководство ООО «Альянс» - добиться того, чтобы система не только помогала обслуживать гостей, но и предусматривала возможности для развития заведения: возможность делать различные дисконтные программы, программы лояльности, обслуживание постоянных клиентов. Понятно, что любой ресторатор хочет видеть в своем заведении постоянных клиентов (именно они дают 80% оборота). К таким посетителям нужно подходить индивидуально, предоставлять скидки, особое обслуживание и т. д. Изменились условия рынка, конкуренция растет, и необходимо прилагать больше усилий на привлечение гостей в свое заведение. Популярны акции по привлечению в кафе и рестораны определенной категории посетителей: предположим, в ресторане объявляются скидки на конкретные позиции блюд в конкретные часы один день в неделю. Поскольку это не банальная процентная скидка, а дисконт, привязанный ко времени и дню недели, реализовать его можно не во всех системах. А когда система автоматизации не предусматривает такую функцию, предоставление скидки гостям отдается на откуп персоналу, а значит, разница в цене благополучно оседает в карманах официантов. Программа по привлечению клиентов выливается в дополнительные непредвиденные расходы.

Поэтому в настоящий момент ресторану «Альянс» необходима эффективная и достаточно простая информационная система, позволяющая решать следующие задачи:

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

обеспечивать удобный ввод данных по заказам за смену начальниками смен

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

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

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

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

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

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

2. Обоснование проектных решений по автоматизированному решению задачи управления производством ресторана «Альянс»

 

. 1 Моделирование бизнес-процессов управления производством ресторана «Альянс»

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

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

1.       объекты информационной системы (сущности в концептуальной модели);

2.       их свойства (атрибуты);

.        взаимодействие объектов (связи) и информационные потоки внутри и между ними.

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

Схема формирования информационной модели представлена на рисунке 2. 1.

Рис. 2. 1. Схема формирования информационной модели [65, стр. 144]

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

Для решения задач проектирования сложных систем существуют специальные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Стандарты IDEF0- IDEF1X описывают приемы изображения компонентов ИС, связей между ними и построения модели данных ИС [42, стр. 56-57].

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

Ниже для проведения анализа и организации бизнес-процессов турагенства использовано CASE-средство верхнего уровня BPWin, (AllFusion Process Modeler 4. 1 (Bpwin 4. 1)), поддерживающее методологии:

- IDEF0 (функциональная модель);

- DFD (DataFlow Diagram);

- IDEF3 (Workflow Diagram) [42, стр. 102].

Построение модели ЭИС по автоматизации производственных процессов в ресторане начинается с описания функционирования системы организации производства в целом в виде контекстной диаграммы. На рис. 2. 2 представлена контекстная диаграмма производственного процесса в ООО «Альянс»:

Рис. 2. 2 Первый уровень детализации процесса автоматизации производственного процесса ресторана в нотификации IDEF0

Взаимодействие системы с окружающей средой описывается в терминах входа (на рис. 21 это “Список поваров”, ”Справочная информация о классах блюд и рецептуре (фактически данные технологических карт)» и «Приготовленные блюда»), выхода (основной результат процесса - “Отчеты”, «Системные сообщения», «Представление хранимых данных» и “Справочники”), управления (“Запросы и “Справочник пользователя”) и механизмов (“Пользователь”, “Аппаратно-технические средства”- это ресурсы, необходимые для процесса функционирования системы в целом).

“Список товаров” - те материальные ресурсы, которые используются при обслуживании клиентов ресторана, прежде всего - это составляющие меню.

“Запросы” и “Справочник пользователя” - это правила, которыми управляется процесс функционирования ресторана как предприятия со своими внутренними правилами.

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

На этом уровне модель описывает деятельность ресторана в части плана-меню ресторана, а именно следующие предоставляемые ею услуги:

- Формирование списка продуктов, необходимых для выполнения плана-меню,

- Обеспечение персонала производственных цехов ресторана необходимыми материально-техническими средствами,

- Администрирование процедур материального производства составляющих плана-меню.

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

Рис. 2. 3. Формирование данных по производственным процессам в ситуации КАК ЕСТЬ

Следующий уровень детализации позволяет представить схему КАК ЕСТЬ обработки данных для формирования отчетов по запросам заинтересованных пользователей.

Рис. 2. 4 Обработка данных при формировании отчетов КАК ЕСТЬ

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

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

Наиболее слабыми местами в данной схеме работы являются:

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

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

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

Рис. 2. 5. Алгоритм работы по формированию и выполнению план-меню на ООО «Альянс»

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

1.       Создание информационного хранилища данных, содержащего все сведения из технологических карт ресторана «Альянс».

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

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

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

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

Рис. 2. 6. Формирование данных по производственным процессам в ситуации КАК БУДЕТ

Следующий уровень детализации позволяет представить схему КАК БУДЕТ обработки данных для ведения базы данных ЭИС:

Рис. 2. 7. Схема ведения базы данных ЭИС АСУПП в ситуации КАК БУДЕТ

Схема обработки справочной информации в ситуации КАК БУДЕТ представлена на рисунке 2. 8:

Рис. 2. 8. Обработка справочной информации в ситуации КАК БУДЕТ

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

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

Характерными чертами экономической информации [46, стр. 16-18] являются её числовой характер, линейная форма (1) , большая размерность и простые арифметические операции обработки, высокая степень структуризованности и регламентированности форм представления отчетов, табличная форма представления групп показателей, достоверность, регулярность (2) . Исходная и результативная информация в основной массе дискретна и представлена в алфавитно-цифровом виде. Исходная информация, как правило, фиксируется в первичных документах (3) . Полученная результативная информация часто используется в качестве исходной при последующих расчетах.

Необходимо выделить следующие особенности экономических задач:

высокая алгоритмизуемость;

иерархичность (вхождение в блоки, функции и т. д. );

регулярность решения;

ограниченные сроки решения;

массовость и возможность типизации схем решения;

большой объём и структурированность данных на входе и выходе экономической информационной системы.

Экономическая информационная система состоит их набора элементов (подсистем), находящихся в определенных отношениях друг с другом. Множество этих отношений совместно с каждым элементом системы образуют структуру ЭИС. В ЭИС АСУПП ресторана «Альянс» можно выделить две основные части: обеспечивающую и функциональную [48, стр. 29] (рис. 2. 9).

Рис. 2. 9. - Состав экономической информационной системы

Обеспечивающая часть ЭИС состоит из следующих видов обеспечения: 1) информационного; 2) технического; 3) математического и программного; 4) организационного; и 5) правового.

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

анализ потоков и объемов информации;

создание массивов информации на машинных носителях.

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

Составные единицы информации в ЭИС обладают определенной структурой [48, стр. 96-99]. Существуют различные способы представления структуры ЭИС; каждый из них отображает состав ЭИС, упорядоченность составляющих, уровни составных и составляющих. Наиболее распространёнными способами представления структуры ЭИС являются табличный, графический и аналитический.

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

уникальный код продукта в меню

краткое наименование (описание)

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

наименование выпускающего цеха и ответственного исполнителя

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

стоимость производства единицы продукта меню

наличие на производственном складе

используемая наценка ресторана

итоговая цена реализации

Назовем базисные элементы меню ресторана продуктами нулевого уровня.

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

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

При описании каждого элемента на уровне i следует в обязательном порядке указывать:

уникальный код комплексного элемента меню

краткое наименование (описание)

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

наименование выпускающего цеха и ответственного исполнителя

существенные условия изготовления и предоставления (технологическая карта)

стоимость производства элемента меню или стоимость оказания услуги

наличие на оперативном складе

используемая наценка ресторана

итоговая цена реализации рестораном комплексного продукта

Отметим, что практически не существует разумного алгоритма, который мог бы самостоятельно комбинировать услуги и определять цену комплексной услуги в зависимости от составляющих её компонентов. Эти вопросы являются исключительной компетенцией менеджеров ресторана, которые фактически должны выполнять всю содержательную работу по формированию списка план-меню и характеристик предоставляемых услуг. Таким образом, в исходной форме экономический документ, относящийся в сфере действия ЭИС АСУ, имеет табличную форму представления. Данный документ содержит некоторое количество уровней. С₀, допустим, представляет базовый продукт ресторана, включаемый в план-меню. Далее документы С₁, С₂, и т. д. представляют собой продукты первого уровня. Расположенные на один шаг ниже документы С представляют собой описания продуктов уровня 2 и т. д. В конце построенного таким образом дерева расположены продукты самого высокого уровня сложности, обозначенные на рисунке внизу буквами А. Например, общая часть С1 содержит составляющие А1, А2, А3, А4, А5. Предметная часть С2 содержит С4, С5, С6, А14, С8. Оформительная часть С3 А18, А19. Графический способ представления структуры ЭИС основан на структурном графе [31, стр. 144-155]. Методика построения структурного графа для экономического документа проектируемой ЭИС такова:

1.       каждой составляющей в документе ставится в соответствие вершина графа;

2.       последовательно выделяемые вершины соединяются линиями, которые указывают на соподчинение выделенных составляющих;

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

.        вершинам следующего (второго) уровня ставятся в соответствие выделенные элементы списка технологических карт ресторана (например, С1, С2, С3);

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

 

Рис. 2. 10 - Графическая структура представления экономического документа

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

А) Свяжем висячие вершины графа с условным "нулевым" элементом.

Рис. 2. 11 - Графическая интерпретация документа и связь атрибутов с "0"

Б) Припишем каждой дуге, входящей в определённую составную (составляющую), параметр, характеризующий размерность атрибута или составной.

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

Объём информации по такому графу определяется суммой объёмов информации по каждому пути графа из начальной вершины (0) в конечную [30, стр. 272]:

где qi - объем информации i-го пути, вычисляемый по формуле:

Названию списка и характеристик агентства, которые фактически должны выполнять всех. агентов. Агентство  где qj объем информации j-й дуги i-го пути.

Рис. 2. 12 - Пронумерованные вершины графа с размерностями всех компонентов (составных, атрибутов)

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

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

Поскольку на ООО «Альянс» в настоящее время немного сотрудников (фактически доступ к проектируемой базе данных необходимо обеспечить для девяти человек), а количество записей в базе ограничивается несколькими тысячами, то наиболее приемлемым и простым с точки зрения реализации на данном предприятии способом обработки данных является централизованная база данных. Существующая на предприятии локальная сеть (100 Мб/сек) обеспечивает быстрый доступ всех заинтересованных сотрудников к базе данных, а мощности используемых ПК вполне хватает для быстрой обработки всех возможных запросов. По способу доступа проектируемая база, несомненно, является базой с сетевым доступом. Более того, должна быть реализована возможность работы с базой данных через Интернет, что позволяет решить важную проблему обеспечения работы с базой для удаленно работающих сотрудников.

Наиболее оптимальной архитектурой для проектируемой базы данных является клиент-серверная архитектура. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL. Концепция клиент-сервер условно изображена на рисунке 2. 13 [13, стр. 41].

Рисунок 2. 13. - Схема обработки информации в БД по принципу клиент-сервер

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

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

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

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

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

каждый элемент таблицы - один элемент данных;

все столбцы в таблице однородные, т. е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д. ) и длину;

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

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

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

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

2. 4 Обоснование проектных решений по технологии сбора, передачи, обработки и выдачи информации

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

централизованная использование больших ЭВМ и вычислительных центров;

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

Наиболее перспективной следует считать организацию технических средств на базе распределенных сетей из ПК и сервера, мэйнфрейма для хранения баз данных, общих для всех функциональных подсистем, организованных по технологии клиент-сервер. Этот режим предполагает выделение отдельного компьютера и представляет схему взаимодействия рабочих станций (клиентов) и сервера вычислительной сети, при которой рабочая станция получает от сервера и обрабатывает только то подмножество данных, которые соответствуют условию, указанному в запросе [50, стр. 76-]. В отличие от режима "файл-сервер", на данном компьютере находятся не только общие базы данных, но и программы первичной обработки данных. Это позволяет другим программам на удалённых компьютерах запрашивать не всю информацию из базы данных, а только частично или полностью обработанную сервером.

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

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

При работе ЭИС АСУПП основным инструментом извлечения информации является построение структурированных запросов к имеющейся базе данных. Поэтому основным технологическим вопросом является следующий - какой следует выбрать механизм управления базой данных? В соответствии с общими требованиями к проектируемой ЭИС должны выполняться следующие требования:

программный комплекс должен быть масштабируемым

программный комплекс должен быть платформонезависимым

программный с ЭИС использует решения типа «клиент-сервер

обеспечение доступа к данным через интернет

С этой точки зрения наиболее современным и функциональным вариантом является использование для обслуживания запросов к системе языка запросов SQL. SQL является инструментом, предназначенным для обработки и чтения данных, содержащихся в компьютерной базе данных. SQL (структурированный язык запросов) [8, стр. 55].

Рис. 2. 14. Схема функционирования SQL-сервера базы данных

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

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

·   Чтение данных. SQL дает пользователю или приложению возможность читать из базы данных содержащиеся в ней данные и пользоваться ими.

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

·   Управление доступом. С помощью SQL можно ограничить возможности пользователя по чтению и изменению данных и защитить их от несанкционированного доступа.

·   Совместное использование данных. SQL координирует совместное использование данных пользователями, работающими параллельно, чтобы они не мешали друг другу.

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

Другой важной технологической задачей является организация доступа к данным с использованием простого и понятного неподготовленному пользователю интерфейса. Поскольку объем базы данных, очевидно, оказывается достаточно большим, то для решения задачи наиболее эффективным методом является организация доступа к БД, который осуществляется специальной программой, запускаемой сервером в момент запуска системы и обслуживающей запросы пользователей ЭИС. Эта программа, обрабатывая запрос, просматривает содержимое БД и создает выходной документ, возвращаемый клиенту. Это решение эффективно для больших баз данных со сложной структурой и при необходимости поддержки операций поиска, что должно быть предусмотрено в ЭИС АСУПП при постановке задачи на проектирование. Показаниями такого решения также являются частое обновление данных (происходящее фактически несколько раз в день) и невозможность синхронизации преобразования БД в статические документы с обновлением содержимого. В этом варианте возможно осуществлять изменение БД из интерфейса обслуживающей программы[8, стр. 45-47]. При описании алгоритма работы системы формирования экономической информации в ЭИС АСУПП необходимо обратить внимание на то, что вложенность комплексных продуктов ресторана не ограничена никакими внешними условиями и поэтому при разработке базы данных для ввода и хранения информации необходимо предусмотреть её динамический характер - при необходимости должен автоматически создаваться новый уровень данных, куда должен будет осуществляться ввод данных по элементам меню продуктам соответствующего высокого уровня сложности.

Блок-схема алгоритма формирования комплексных элементов меню в ЭИС АСУПП, осуществляемая менеджерами ООО «Альянс» с использованием доступа к ресурсам ЭИС по локальной сети фирмы, представлена на рисунке 2. 15:

Рис. 2. 15. Блок-схема алгоритма внесения и редактирования информационных блоков в базе данных ЭИС АСУПП

 

2. 5 Обоснование проектных решений по программному обеспечению комплекса задач автоматизации производственных процессов в ресторане «Альянс»

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL, а в предыдущем параграфе было отмечено, что использование языка запросов является оптимальным решением в случае построения ЭИС ресторана «Альянс»), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем являются непроцедурными, т. е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу [18, стр. 63]. Требования, предъявляемые к современным СУБД:

1.       Поддержка определённой логической модели данных.

2.       Наличие встроенных языковых средств, в том числе:

а) язык определения данных - Data Definition Language(DDL).

б) языки манипулирования данных - Data Manipulation Language(DML).

в) язык запросов - Query Language(QL).

.        Наличие графического интерфейса, в котором можно выделить: интерфейс пользователя(User Interface), интерфейс разработчика(Developer Interface), интерфейс администратора(Administrator Interface).

4.       Наличие подсистемы словаря данных и системного каталога.

.        Наличие программных средств контроля целостности данных.

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

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

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

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. В Access существуют средства просмотра и манипулирования объектами базы данных [9, стр. 34-37]:

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

полоса объектов, предназначенная для просмотра объектов БД. Ее вертикальное расположение более удобно в использовании;

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

настройка способов выбора и открытия объектов в окне базы данных;

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

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

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

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

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

поддержка 16-разрядного стандарта код ировки символов Unicode;

использование Microsoft ActiveX Data Objects (ADO) для доступа и манипулирования данными в базах данных сервера.

Microsoft Access предоставляет максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можно задать также форматы хранения и представления этих данных при выводе на экран или печать. Microsoft Access может работать с большим числом самых разнообразных форматов данных, включая файловые структуры других СУБД. Можно оосуществлять импорт и экспорт данных из файлов текстовых редакторов или электронных таблиц. С помощью Access вы можно непосредственно обрабатывать файлы Paradox, dBASE III, dBASE IV, Btrieve, FoxPro и др. В Microsoft Access для обработки данных ваших таблиц используется мощный язык SQL (Structured Query Language - Структурированный язык запросов). Используя SQL, можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. При любой обработке данных из нескольких таблиц Access использует однажды заданные вами связи между таблицами [4, стр. 82-85].

Microsoft Access спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети - в режиме «клиент - сервер». Поскольку в Access к данным могут иметь доступ одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. Можно заранее указать, какие пользователи или группы пользователей могут иметь доступ к объектам (таблицам, формам, запросам) к базам данных. Access автоматически обеспечивает защиту данных от одновременной их корректировки разными пользователями, в Access имеются средства, позволяющие легко проектировать и создавать приложения для работы с базами данных без знания языка программирования. Работа в Access начинается с определения реляционных таблиц и их полей, которые будут содержать данные. Microsoft Access предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой базы данных SQL, поддерживающей стандарт ODBC. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на сервере [29, стр. 90-93].

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

3. Проектная часть

 

. 1 Информационное обеспечение комплекса задач автоматизации производственных процессов в ресторане «Альянс»

 

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

Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Объединяя частные представления о содержимом базы данных, полученные в результате анализа запросов пользователей, проектировщик сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (Рисунок 3. 1) [8, стр. 34].

Рисунок 3. 1. Уровни моделей данных

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

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

Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют дата логической моделью данных. [5, стр. 42-43]. Трехуровневая архитектура (инфологический, дата логический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Администратор БД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. Можно подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, дата логическую модель. Указанные изменения физической и дата логической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты) [31, стр. 28-30].

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

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

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

Связь - ассоциирование двух или более сущностей.

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т. е. сущность-связь) [31, стр. 39]. В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Как правило, определяются три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения. [25, стр. 76-77].

Стержневая сущность (стержень) - это независимая сущность.

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" ("-ко-многим" и т. д. ) между двумя или более сущностями или экземплярами сущности.

Ассоциации рассматриваются как полноправные сущности:

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

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

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

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рисунок 3. 2).

Рисунок 3. 2. - Элементы расширенного языка ER-диаграмм

 

Обозначающая сущность или обозначение - это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

3. 1. 2 Инфологическая модель задачи автоматизации работа ресторана «Альянс»

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

·              стержни Адреса, Заказы, Блюда, Продукты и Сотрудники;

·              ассоциации Состав (связывает Блюда с Продуктами), Поставки (связывает Поставщиков с Продуктами), Заказано (связывает Заказы с Блюдами), Обслуживание (связывает Сотрудников с Заказами);

·              обозначение Клиенты и Поставщики;

·              характеристики Рецепты и Расход. диаграмма модели показана на рис. 3. 3. а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид, Наценка)

Сотрудники (С, ФИО, должность)

Заказы (З, Дата , Столик, Кол-во мест)

Продукты (ПР, Продукт, Описание)

Поставщики (ПОС, Адрес, Поставщик) [Адреса]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Цена, Ед. измерения)

Заказано [Заказы, Блюда] (З, БЛ, Кол-во)

Обслуживание [Заказы, Сотрудники] (З, С, Время, Примечания)

Адреса (Город, Организация)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата _Р, Порций) {Блюда}

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

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

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

1.       Название поставщика (все поставщики - фирмы или частные предприниматели, имеющие фирменное наименование)

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

.        Город поставщика

.        Область поставщика

.        Индекс поставщика

.        Страна поставщика

.        Телефон поставщика (с код ом страны или региона)

.        Факс поставщика (с код ом страны или региона)

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

Ключевым полем сущности разумно считать уникальный код Поставщика.

Далее рассмотрим обозначающую сущность Блюда. Ей присущи следующие обязательные атрибуты:

1.       Наименование блюда

2.       Единица измерения

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

.        Вводим в качестве атрибута уникальный Код Блюда. Этот код является ключом сущности.

Рассмотрим стержневую сущность ПРОДУКТЫ. По сути, это база используемых в работе производственных цехов ресторана элементов. Атрибутами сущности являются:

1.       Название продукта

2.       Описание продукта.

.        Единица измерения

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

Важной стержневой сущностью базы данных является сущность СОТРУДНКИ, с помощью которой ведется база работников предприятия, заносится вся необходимая информация о сотруднике. Необходимыми атрибутами данной сущности являются:

1.       Фамилия, имя и отчество сотрудника

2.       Пол сотрудника

.        Должность сотрудника

.        Дата рождения сотрудника

.        Адрес сотрудника

.        Домашний телефон сотрудника (с код ом страны или региона)

.        Мобильный телефон сотрудника (с код ом страны или региона)

.        Общие сведения о сотруднике

.        Уникальный идентификационный номер сотрудника, являющийся также и ключом данной сущности.

Сущность ЗАКАЗЫ является стержневой сущностью в данной инфологической модели. Её атрибутами являются:

1.       Уникальный код заказа

2.       Дата размещения заказа

.        Номер столика заказа

.        Количество обслуживаемых по заказу мест

Следующей сущностью, которую следует проанализировать, является ассоциативная сущность ЗАКАЗАНО. Он связывает сущности ЗАКАЗЫ и Блюда. Её атрибутами являются:

1.       Код заказа

2.       Код блюда в заказе

.        Количество данного блюда в заказе

.        Предоставленная скидка

.        Ключевыми атрибутами для сущности ЗАКАЗАНО являются пары значений Код заказа и Код Блюда.

Последней сущностью является сущность ОБСЛУЖИВАНИЕ, связывающая сущности СОТРУДНИЕИ и ЗАКАЗЫ. Её атрибутами являются:

1.       Код заказа

2.       Код сотрудника

.        Время обслуживания заказа

.        Примечания по заказу

Ключевыми атрибутами сущности является пара Код заказа и Код сотрудника.

По результатам проведенного анализа легко видеть, что все рассматриваемые сущности обладают уникальным код ом и этот код является простым, т. е. содержащим только один атрибут сущности либо их связанные пары. Для того, чтобы впоследствии эффективно работать с заявленными сущностями, необходимо точно указать, каким типом данных выражается тот или иной атрибут сущности и каков его размер при размещении в базе данных. Также важно для атрибутов установить, обязательными ли они являются для данной сущности и возможны ли повторения для данных атрибутов [14, стр. 112]. Проведя анализ имеющихся записей у официантов, работающих с клиентами и менеджера зала, можно дать соответствующие оценки. Итоговые данные по сущностям, используемым в инфологической модели базы данных, приведены в Приложении А. Модель на языке ЯИМ имеет следующий вид:

ПОСТАВЩИКИ(Код Поставщика, Название, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

ПРОДУКТЫ (Код Продукта, Наименование, Описание)

БЛЮДА (Код Блюда, Наименование блюда, Тип блюда, выпускающий цех, Единица измерения, Торговая наценка в %)

СОТРУДНИКИ (Код Сотрудника, ФИО, Пол, Должность, Дата Рождения, Адрес, ДомашнийТелефон, Мобильный Телефон, Примечание)

ЗАКАЗЫ (Код Заказа, Дата , Столик, Количество мест)

ОБСЛУЖИВАНИЕ [Сотрудники-1, Заказы-М] (Код Заказа, Код Сотрудника, Время, Примечания)

ЗАКАЗАНО [Заказы М, Блюда N] (Код Заказа, Код Блюда, Количество, скидка)

СОСТАВ [Блюда М, Продукты N] (Код Блюда, Код Продукта, Единица измерения, Расход)

ПОСТАВКИ [Продукты M, Поставщики N] (Код Продукта, Код Поставщика, Единица измерения, Цена)

РЕЦЕПТЫ (Код Блюда, Наименование блюда, Рецепт) {Блюда}

РАСХОД(Код Блюда, Количество порций, Дата потребления) {Блюда}

3.1.3 Анализ ключей сущностей проектируемой базы данных

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

Теперь о внешних ключах:

Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

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

Связь между первичными и внешними ключами сущностей иллюстрируется рисунке 1. 6 [14, стр. 119]:

Рисунок 3. 4 - Структуры: а - ассоциации; б - обозначения (характеристики)

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

Для сущности ЗАКАЗАНО первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Заказа и Код Блюда, принадлежащие соответственно сущностям БЛЮДА и ЗАКАЗЫ. В случае с сущностями-обозначениями и характеристиками (это сущности БЛЮДА и ЗАКАЗЫ) их первичные ключи Код Блюда и Код Заказа соответственно.

Для сущности ОБСЛУЖИВАНИЕ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Заказа и Код Сотрудника, принадлежащие соответственно сущностям ЗАКАЗЫ и СОТРУДНИКИ.

Для сущности ПОСТАВКИ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Продукта и Код Поставщика, принадлежащие соответственно сущностям ПРОДУКТЫ и ПОСТАВЩИКИ.

Для сущности СОСТАВ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Блюда и Код Продукта, принадлежащие соответственно сущностям БЛЮДА и ПРОДУКТЫ.

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

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

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?

. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку.

Существует три возможности [12, стр. 65-67]:

КАСКАДИРУЕТСЯ	Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика.
ОГРАНИЧИВАЕТСЯ	Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка.

Имеются те же три возможности, как и при удалении:

КАСКАДИРУЕТСЯ Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика.
ОГРАНИЧИВАЕТСЯ	Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

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

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей. В ситуации с рассмотренными выше сущностями базы данных ООО «Альянс» имеют место следующие общие наблюдения:

Сущность ПОСТАВЩИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Поставщика )

ПОЛЯ (Код Поставщика, Название, Адрес, Город, Индекс, Страна, Телефон, Факс);

Сущность СОТРУДНИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Сотрудника )

ПОЛЯ (Код Сотрудника, ФИО, Пол, Должность, Дата Рождения, Адрес, Домашний Телефон, Мобильный Телефон, Примечания);

Сущность ЗАКАЗЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа )

ПОЛЯ (Код Заказа, Дата заказа, Номер столика, Количество мест);

Сущность ПРОДУКТЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Продукта )

ПОЛЯ (Код Продукта, Название, Единица измерения);

Сущность БЛЮДА *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда )

ПОЛЯ (Код Блюда, Название блюда, Вид, Описание);

Сущность РЕЦЕПТЫ *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда )

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДАзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда ОГРАНИЧИВАЕТСЯ)

ПОЛЯ (Код Блюда, Рецепт)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда должны принадлежать набору значений соответствующих полей сущности БЛЮДА; при нарушении вывод предупреждающего сообщения);

Сущность РАСХОД *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда, Дата Расхода)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДАзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда ОГРАНИЧИВАЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Дата Расходазначения НЕ ДОПУСТИМЫ

Должен представлять дату в формате ДД. ММ. ГГГГ)

ПОЛЯ (Код Блюда, Дата Расхода, ЕдИзмерения, Расход)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда должны принадлежать набору значений соответствующих полей сущности БЛЮДА; при нарушении вывод предупреждающего сообщения);

Сущность ЗАКАЗАНО *( Характеризует БЛЮДА и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа, Код Блюда )

ВНЕШНИЙ КЛЮЧ ( Код Заказа ИЗ ЗАКАЗЫзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ. Код Заказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДАзначения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Заказа, Код Блюда, Количество )

ОГРАНИЧЕНИЯ ( Значения поля Код Заказа должны принадлежать набору значений соответствующего поля сущности Заказы, значение поля Код Блюда принадлежит набору значений соответствующего поля сущности БЛЮДА; при нарушении вывод сообщения);

Сущность ОБСЛУЖИВАНИЕ *( Связывает СОТРУДНИКИ и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа, Код Сотрудника )

ВНЕШНИЙ КЛЮЧ ( Код Заказа ИЗ ЗАКАЗЫзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ. Код Заказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Сотрудника ИЗ СОТРУДНИКАзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ТОВАРЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ТОВАРЫ. Код Сотрудника КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Заказа, Код Сотрудника, Время, Примечания )

ОГРАНИЧЕНИЯ ( Значения полей Код Заказа и Код Сотрудника должны принадлежать набору значений соответствующих полей сущностей ЗАКАЗЫ и СОТРУДНИКИ; при нарушении вывод сообщения);

Сущность ПОСТАВКИ *( Связывает ПРОДУКТЫ и ПОСТАВЩИКИ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Продукта, Код Поставщика)

ВНЕШНИЙ КЛЮЧ ( Код Продукта ИЗ ПРОДУКТЫзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПРОДУКТЫ ОГРАНИЧИВАЕТСЯ

ВНЕШНИЙ КЛЮЧ ( Код Поставщика ИЗ ПОСТАВЩИКИзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПОСТАВЩИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПОСТАВЩИКИ Код Поставщика КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Продукта, Код Поставщика, Цена, ЕдИзмерения)

ОГРАНИЧЕНИЯ ( Значения полей Код Продукта и Код Поставщика должны принадлежать набору значений соответствующих полей сущностей ПРОДУКТЫ и ПОСТАВЩИКИ; при нарушении вывод сообщения);

Сущность СОСТАВ *( Связывает БЛЮДА и ПРОДУКТЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда, Код Продукта)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДАзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Продукта ИЗ ПРОДУКТЫзначения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПРОДУКТЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПРОДУКТЫ. Код Продукта КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Блюда, Код Продукта, ед. измерения, Количество)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда и Код Продукта должны принадлежать набору значений соответствующих полей сущностей БЛЮДА и ПРОДУКТЫ; при нарушении вывод сообщения);

3.1.4 Разработка и нормализация системы таблиц базы данных

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

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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

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

Нормализация - это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации [12, стр. 188-190].

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

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

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

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

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

Итак, можно сказать, что нормализация - это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Можно дать и другое определение: нормализация - это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в НФБК.

Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все содержащиеся записи относятся к конкретному поставщику, которому присвоен уникальный Код Поставщика, то эта таблица находится во 2НФ, а так как каждое поле однозначно определяется этим уникальным код ом, то таблица находится и в НФБК. Аналогичные замечания полностью применимы к таблицам Продукты, Блюда, Заказы и Сотрудники, которые, следовательно, также находятся в НФБК.

Что касается таблиц Расход и Рецепты, то они имею ключевые поля вида Код Блюда-Дата Расхода и Код Блюда соответственно. Очевидно, что эти таблицы находятся в нормальной форме Бойса-Код да.

Наиболее сложными для анализа являются таблицы Обслуживание, Поставки, Состав и Заказано. Ключевым полем в таблице Заказано является поле Код Заказа-Код Блюда, оно действительно однозначно определяет все другие поля таблицы. Следовательно, таблица находится в 2НФ. Но, совершенно очевидно, что все другие поля содержат только сведения о количестве блюд данного наименования в данном заказе и поэтому функционально зависят от ключевого поля. Следовательно, таблица находится в НФБК. Что касается таблицы Обслуживание, то её ключевое поле является составным (Код Заказа - Код Сотрудника). Поскольку исключены повторения сотрудников при выполнении одного и того же заказа, а время выполнения заказа однозначно определено этими двумя полями, то и эта таблица находится в НФБК. Аналогичные рассуждения применимы и к таблицам Поставки и Состав.

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

 

.1.5 Определение форматов данных в таблицах базы данных

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

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

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

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

поле Город является текстовым и имеет длину 15

поле Область является текстовым и имеет длину 15

поле Индекс является текстовым и имеет длину 10

поле Страна является текстовым и имеет длину 20

поле Телефон является текстовым и имеет длину 24 (поскольку кроем 10-значного номера возможно, потребуется вводить еще и дополнительные цифры)

поле Факс является текстовым и имеет длину 24

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

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

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

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

Что касается ключевого поля Код Продукта, то в данном случае целесообразно сделать его текстовым (длины 12) для возможности унифицированного ввода продуктов в зависимости от их пользовательских характеристик. В настоящее время в ресторане «Альянс» используется следующая унифицированная форма код ирования продуктов:

Первая буква код а соответствует форме хранения (жидкий -Ж, мягкий - М, твердый - Т и т. п. ), вторая и третья буквы соответствуют типу продукта (мясной - МЯ. молочный - МО и т. п. ), далее идет трехзначное число, соответствующее сроку хранения в часах, далее, через еще один символ - тире, указывается двузначное число, соответствующее нормативной температуре хранения и после него указывается символ Н (при положительной температуре) или Х (в условиях холода), далее указывается номер цеха, принимающего данный продукт. Остальные символы являются резервными. Например, обычное молоко в пакетах в такой системе код ирования получит обозначение ЖМО048-05Н3м (суффикс м означает, что используется мягкая упаковка). Поскольку данная форма код ирования на предприятии является уже сложившейся и даже по форме записи работники цехов могут визуально определить тип и характеристики продукта, то целесообразно при автоматизации работы ресторана сохранить эту форму записи для продуктов без изменений.

Таблица Блюда содержит информацию обо всех изготавливаемых в ресторане блюдах, составляющих меню ресторана, с указанием их полного названия, типа блюда, выпускающего цеха и используемой в данном ресторане единице измерения, а также принятой торговой наценкой (в % от себестоимости продуктов, использцуемых при приготовлении данного блюда). Для эффективной работы с содержащейся в таблице информацией целесообразно задать форматы полей следующим образом:

поле Название является текстовым с длиной 50 - этого вполне достаточно для ввода всех возможных названий блюд. При необходимости оператор может использовать сокращенные наименования.

поле Вид является текстовым длиной 50

поле Описание содержит полное описание блюда и поэтому его необходимо определить в формате МЕМО.

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

Ключевым является поле Код Блюда, его по сложившейся в ресторане «Альянс» практике следует считать текстовым с длиной 12. Код блюда определяется по следующей схеме: первая буква определяет тип блюда (П- первое, В- второе, Т- третье, З - закуска, Н - напиток), вторая характеристику блюда ( Г- горячее, Х - холодное, А - алкогольное т т. п. ), затем три цифры определяют вес порции, затем идет номер выпускающего цеха, затем указывается двухзначный план сервировки, трехзначное число, идущее после дефиса, определяет срок хранения. Например, для супа харчо запись будет иметь вид: ПГ245103-024.

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

поля ФИО, Пол, Должность, Дата Рождения, Адрес, Домашний Телефон, Мобильный Телефон целесообразно определить как текстовые длиной 50, а поле Примечания - как поле в формате МЕМО.

Ключевым является поле Код Сотрудника, его по сложившейся в ресторане «Альянс» практике следует считать текстовым с длиной 6. Код сотрудника определяется по следующей схеме: первая буква определяет служебную категорию сотрудника, затем идет дефис, затем две буквы служат сокращением должности, затем идет указание номера структурного подразделения ресторана, к которому приписан данный сотрудник, через дефис - номер сотрудника в сводной ведомости. Например, официант получит запись вида 2-Оф02-044.

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

поле дата должно вводиться в формате ДД. ММ. ГГГГ.

поля Номер Столика и Количество Мест должны быть числовыми. При вводе данных долен осуществляться контроль за соответствием вводимых чисел реальному состоянию дел (например, количество столиков в ресторане 26, а количество посадочных мест ограничено числом 146).

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

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

Таблица Заказано также является ассоциацией двух других таблиц, поэтому её ключевые поля Код Заказа и Код Блюда уже были определены раньше. Поле Количество следует выбрать числовым, а поле Скидка также должно быть числовым, но необходимо определить контроль: значение скидки должно быть в пределах от 0 до 100 (поскольку она указывается в процентах).

Таблица Состав является ассоциацией двух других таблиц, поэтому её ключевые поля Код Блюда и Код Продукта уже были определены раньше. Поле Единица Измерения целесообразно выбрать текстовым дины 12, а поле Расход должно быть числовым.

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

3.1.6 Характеристика входной, справочно-нормативной и результатной информации при использовании ЭИС АСУПП ресторана «Альянс»

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

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

сведения о поставщиках, содержащиеся в таблице Поставщики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

3.2 Программное обеспечение комплекса задач ЭИС АСУПП ресторана «Альянс»

 

.2.1 Разработка средств анализа данных в базе данных ресторана «Альянс»

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

Рисунок 3. 5. Схема данных базы данных автоматизации производственных процессов ресторана «Альянс».

Подробные описания таблиц базы данных вынесены в Приложение 4.

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

Рисунок 3. 6. Запрос Самый Дешевый Продукт в режиме конструктора

Соответствующая инструкция на языке SQL имеет вид:

SELECT Поставки. Код Продукта, Min (Поставки. Код Поставщика) AS [Min-Код Поставщика], Поставки. Название, Поставки. Ед Измерения, Min (Поставки. Цена) AS [Min-Цена]ПоставкиBY Поставки. Код Продукта, Поставки. Название, Поставки. Ед Измерения;

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

Рис. 3. 7 Запрос Блюда Состав Поставщики в режиме конструктора

Соответствующий SQL-код имеет вид:

Блюда. Код Блюда, Блюда. Название Блюда, Состав. Код Продукта, Самый Дешевый Поставщик. Название, Состав. Количество, Поставщики. Название, Самый Дешевый Поставщик. [Min-Цена]((Блюда INNER JOIN Состав ON Блюда. Код Блюда = Состав. Код Блюда) INNER JOIN Самый Дешевый Поставщик ON Состав. Код Продукта = СамыйДешевыйПоставщик. Код Продукта) INNER JOIN Поставщики ON СамыйДешевыйПоставщик. [Min-Код Поставщика] = Поставщики. Код Поставщика;

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

Блюда Состав Поставщики. Код Блюда, Sum([Количество]*[Min-Цена]) AS ИтогоБлюда Состав Поставщики; GROUP BY Блюда Состав Поставщики. Код Блюда;

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

Блюда. Код Блюда, Блюда. НазваниеБлюда, Блюда. Наценка, СтоимостьБлюда. Итого, [Итого]*(1+[Наценка]/100) AS ЦенаFROM СтоимостьБлюда INNER JOIN Блюда ON СтоимостьБлюда. Код Блюда = Блюда. Код Блюда;

Запрос по формированию полных сведений об обслуженных заказах имеет вид:

 

Рисунок 3.8. Запрос Заказы в режиме конструктора

Следующим шагом нужно научиться рассчитывать стоимость каждого заказа. Для этого построим запрос СтоимостьЗаказа, его SQL-код имеет вид:

[Запрос Заказы]. Код Заказа, Sum(Блюда Цена. Итого) AS [Sum-Итого], Sum(Блюда Цена. Цена) AS [Sum-Цена], Sum([Цена]*(1-[Скидка %]/100)) AS Цена Расчета([Запрос Заказы] INNER JOIN Блюда Цена ON [Запрос Заказы]. Код Блюда = Блюда Цена. Код Блюда) INNER JOIN Заказано ON ([Запрос Заказы]. Код Блюда = Заказано. Код Блюда) AND ([Запрос Заказы]. Код Заказа = Заказано. Код Заказа)BY [Запрос Заказы]. Код Заказа;

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

Рис. 3.9. Запрос Заявка План Меню в режиме конструктора

В формате SQL запрос имеет вид:

[План-меню]. Дата , Блюда Состав Поставщики. Код Продукта, Блюда Состав Поставщики. Самый Дешевый Поставщик. Название, Блюда Состав Поставщики. Количество, Блюда Состав Поставщики. Поставщики. Название, Блюда Состав Поставщики. [Min-Цена], Sum([План-Меню. Количество]*[Блюда Состав Поставщики. Количество]) AS Заказ Продукта[План-меню] INNER JOIN Блюда Состав Поставщики ON [План-меню]. Код Блюда = Блюда Состав Поставщики. Код БлюдаBY [План-меню]. Дата , Блюда Состав Поставщики. Код Продукта, Блюда Состав Поставщики. Самый Дешевый Поставщик. Название, Блюда Состав Поставщики. Количество, Блюда Состав Поставщики. Поставщики. Название, Блюда Состав Поставщики. [Min-Цена];

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

Заявка План Меню. Дата , Заявка План Меню. Код Продукта, Заявка План Меню. Поставщики. Название, Заявка План Меню. [Min-Цена], Заявка План Меню. Заказ Продукта, [Min-Цена]*[Заказ Продукта] AS СуммаЗаявка План Меню;

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

Первым рассмотрим запрос, позволяющий анализировать динамику продаж за различные временные промежутки. Запрос Продажи по годам для удобства пользователей запускается из специально созданной для этого формы Продажи по годам вида. Данная форма содержит два поля - Начальная Дата и Конечная Дата . При передаче управления кнопкой Выполнить запрос введенные в эти поля даты (для ввода дат установлены естественные ограничения - рассматривается период с 2005 по 2009 годы) передаются запросу Продажи по годам, конструкция которого имеет вид:

[Forms]![Продажи по годам]![Начальная Дата ] DateTime, [Forms]![Продажи по годам]![Конечная Дата ] DateTime;Sum(Стоимость Заказа. Цена Расчета) AS [Sum-Цена Расчета]Заказы INNER JOIN Стоимость Заказа ON Заказы. Код Заказа = Стоимость Заказа. Код Заказа;

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

Для того, чтобы получить анализ продаж за предыдущий 2011 год, сформируем запрос Продажи товаров в 2011 вида:

Блюда. Код Блюда, Блюда. Название Блюда, Sum(CCur([Блюда Цена]. [Цена]*[Количество]*(1-[Скидка %])/100)*100) AS Продажи Товаров, "Кв " & DatePart("q", [Дата Заказа]) AS Квартал