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 следует в обязательном порядке указывать:
уникальный код комплексного элемента меню
краткое наименование (описание)
развернутое описание с перечислением всех входящих в состав продукта элементарных составляющих (чем более детализирован этот список, тем удобнее впоследствии работать с данным информационным блоком)
наименование выпускающего цеха и ответственного исполнителя
существенные условия изготовления и предоставления (технологическая карта)
стоимость производства элемента меню или стоимость оказания услуги
наличие на оперативном складе
используемая наценка ресторана
итоговая цена реализации рестораном комплексного продукта
Отметим, что практически не существует разумного алгоритма, который мог бы самостоятельно комбинировать услуги и определять цену комплексной услуги в зависимости от составляющих её компонентов. Эти вопросы являются исключительной компетенцией менеджеров ресторана, которые фактически должны выполнять всю содержательную работу по формированию списка план-меню и характеристик предоставляемых услуг. Таким образом, в исходной форме экономический документ, относящийся в сфере действия ЭИС АСУ, имеет табличную форму представления. Данный документ содержит некоторое количество уровней. С0, допустим, представляет базовый продукт ресторана, включаемый в план-меню. Далее документы С1, С2, и т. д. представляют собой продукты первого уровня. Расположенные на один шаг ниже документы С представляют собой описания продуктов уровня 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-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
Наиболее современным и практичным с точки зрения программирования является использование реляционной модели данных. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
каждый элемент таблицы - один элемент данных;
все столбцы в таблице однородные, т. е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д. ) и длину;
каждый столбец имеет уникальное имя;
одинаковые строки в таблице отсутствуют;
порядок следования строк и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы - атрибутам отношений, доменам, полям. Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ. Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ - ключ второй таблицы.
Детально вопросы организации реляционной базы данных для ООО «Альянс» будут рассмотрены в следующей главе при построении инфологической модели ЭИС АСУПП.