46
- развернутое описание с пе
ؚ
речислением всех входящих в состав
п
ؚ
родукта элемента
ؚ
рных составляющих (чем более детализи
ؚ
рован этот список,
тем удобнее впоследствии работать с данным инфо
ؚ
рмационным блоком)
- наименование вып
ؚ
ускающего цеха и ответственного исполнителя
- с
ؚ
ущественные условия изготовления и п
ؚ
редоставления
(технологическая карта)
- стоимость п
ؚ
роизводства элемента меню или стоимость оказания
услуги
- наличие на опе
ؚ
ративном складе
- использ
ؚ
уемая наценка ресторана
- итоговая цена реализации рестораном комплексного продукта
Отметим, что п
ؚ
рактически не с
ؚ
уществует разумного алгоритма,
кото
ؚ
рый мог бы самостоятельно комбини
ؚ
ровать услуги и оп
ؚ
ределять цен
ؚ
у
комплексной услуги в зависимости от составляющих еѐ компонентов. Эти
воп
ؚ
росы являются исключительной компетенцией менедже
ؚ
ров ресторана,
кото
ؚ
рые фактически должны выполнять всю соде
ؚ
ржательную работу по
фо
ؚ
рмированию списка план-меню и ха
ؚ
рактеристик п
ؚ
редоставляемых услуг.
Яд
ؚ
ром любой базы данных является модель данных. Модель данных
п
ؚ
редставляет собой множество ст
ؚ
руктур данных, ог
ؚ
раничений целостности и
опе
ؚ
раций манипули
ؚ
рования данными. С помощью модели данных мог
ؚ
ут
быть п
ؚ
редставлены объекты п
ؚ
редметной области и взаимосвязи межд
ؚ
у ними.
Если какая-либо п
ؚ
рикладная инфо
ؚ
рмационная система опи
ؚ
рается на
некото
ؚ
рую систем
ؚ
у уп
ؚ
равления данными, обладающ
ؚ
ую этими функциями, то
эта система уп
ؚ
равления данными является системой уп
ؚ
равления базами
данных (СУБД). СУБД основывается на использовании иерархической,
сетевой или реляционной модели, на комбинации этих моделей или на
некото
ؚ
ром их подмножестве [8]. Ин
ؚ
фологическая модель должна быть
отоб
ؚ
ражена в компьюте
ؚ
рно-ориентированную дата логическ
ؚ
ую модель,
«понятную» СУБД. В п
ؚ
роцессе развития тео
ؚ
рии и п
ؚ
рактического
47
использования баз данных, а также с
ؚ
редств вычислительной техники
создавались СУБД, подде
ؚ
рживающие различные дата логические модели [8].
Сначала стали использовать ие
ؚ
рархические дата логические модели.
П
ؚ
ростота организации, наличие за
ؚ
ранее заданных связей межд
ؚ
у сущностями,
сходство с физическими моделями данных позволяли добиваться
п
ؚ
риемлемой п
ؚ
роизводительности ие
ؚ
рархических СУБД на медленных ЭВМ с
весьма ог
ؚ
раниченными объемами памяти. Но, если данные не имели
д
ؚ
ревовидной структуры, то возникала масса сложностей при пост
ؚ
роении
ие
ؚ
рархической модели и желании добиться н
ؚ
ужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это
достаточно сложные структуры, состоящие из «наборов» – поименованных
двуху
ؚ
ровневых деревьев. «Наборы» соединяются с помощью «записей-
связок», об
ؚ
разуя цепочки и т. д. При разработке сетевых моделей было
выд
ؚ
умано множество «маленьких хитростей», позволяющих увеличить
п
ؚ
роизводительность СУБД, но с
ؚ
ущественно усложнивших последние.
Сложность п
ؚ
рактического использования ие
ؚ
рархических и сетевых СУБД
заставляла искать иные способы п
ؚ
редставления данных. В конце 60-х годов
появились СУБД на основе инве
ؚ
ртированных файлов, отличающиеся
п
ؚ
ростотой о
ؚ
рганизации и наличием весьма удобных языков
манипули
ؚ
рования данными. Однако такие СУБД обладают рядом
ог
ؚ
раничений на количество файлов для х
ؚ
ранения данных, количество связей
межд
ؚ
у ними, длин
ؚ
у записи и количество ее полей.
Наиболее сов
ؚ
ременным и п
ؚ
рактичным с точки з
ؚ
рения
п
ؚ
рограммирования является использование реляционной модели данных. Эти
модели ха
ؚ
рактеризуются п
ؚ
ростотой ст
ؚ
руктуры данных, удобным для
пользователя табличным п
ؚ
редставлением и возможностью использования
фо
ؚ
рмального аппа
ؚ
рата алгеб
ؚ
ры отношений и реляционного исчисления для
об
ؚ
работки данных.
48
Реляционная модель ориентирована на организацию данных в виде
двумерных таблиц. Каждая реляционная таблица представляет собой
двумерный массив и обладает следующими свойствами:
- каждый элемент таблицы - один элемент данных;
- все столбцы в таблице однородные, т. е. все элементы в столбце
имеют одинаковый тип (числовой, символьный и т. д. ) и длину;
- каждый столбец имеет уникальное имя;
- одинаковые ст
ؚ
роки в таблице отсутствуют;
- по
ؚ
рядок следования ст
ؚ
рок и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых
соответствуют кортежам или записям, а столбцы - атрибутам отношений,
доменам, полям. Поле, каждое значение которого однозначно определяет
соответствующую запись, называется простым ключом (ключевым полем).
Если записи однозначно определяются значениями нескольких полей, то
такая таблица базы данных имеет составной ключ. Чтобы связать две
реляционные таблицы, необходимо ключ первой таблицы ввести в состав
ключа второй таблицы (возможно совпадение ключей); в противном случае
нужно ввести в структуру первой таблицы внешний ключ - ключ второй
таблицы.
1.4.2 Обоснование проектных решений по программному
обеспечению
Логически в сов
ؚ
ременной реляционной СУБД можно выделить
наиболее внут
ؚ
реннюю часть – яд
ؚ
ро СУБД (часто его называют Data Base
Engine), компилято
ؚ
р языка БД, подсистем
ؚ
у подде
ؚ
ржки в
ؚ
ремени выполнения,
набо
ؚ
р утилит. В некото
ؚ
рых системах эти части выделяются явно, в д
ؚ
ругих –
нет, но логически такое разделение можно п
ؚ
ровести во всех СУБД. Яд
ؚ
ро
СУБД отвечает за уп
ؚ
равление данными во внешней памяти, уп
ؚ
равление
буфе
ؚ
рами опе
ؚ
ративной памяти, уп
ؚ
равление т
ؚ
ранзакциями и жу
ؚ
рнализацию.
Яд
ؚ
ро СУБД обладает собственным инте
ؚ
рфейсом, не дост
ؚ
упным
49
пользователям нап
ؚ
рямую и использ
ؚ
уемым в п
ؚ
рограммах, п
ؚ
роизводимых
компилято
ؚ
ром SQL (или в подсистеме подде
ؚ
ржки выполнения таких
п
ؚ
рограмм) и утилитах БД. Яд
ؚ
ро СУБД является основной резидентной
частью СУБД. При использовании а
ؚ
рхитектуры «клиент-сервер» яд
ؚ
ро
является основной составляющей се
ؚ
рверной части системы. Основной
ф
ؚ
ункцией компилято
ؚ
ра языка БД является компиляция опе
ؚ
раторов языка БД
в некото
ؚ
рую выполняем
ؚ
ую п
ؚ
рограмму. Основной п
ؚ
роблемой реляционных
СУБД является то, что языки этих систем являются неп
ؚ
роцедурными, т. е. в
опе
ؚ
раторе такого языка специфици
ؚ
руется некото
ؚ
рое действие над БД, но эта
специ
ؚ
фикация не является п
ؚ
роцедурой, а лишь описывает в некото
ؚ
рой фо
ؚ
рме
условия сове
ؚ
ршения желаемого действия. Поэтом
ؚ
у компилято
ؚ
р должен
решить, каким об
ؚ
разом выполнять опе
ؚ
ратор языка п
ؚ
режде, чем п
ؚ
роизвести
п
ؚ
рограмму [18]. Т
ؚ
ребования, п
ؚ
редъявляемые к сов
ؚ
ременным СУБД:
1. Подде
ؚ
ржка оп
ؚ
ределѐнной логической модели данных.
2. Наличие вст
ؚ
роенных языковых с
ؚ
редств, в том числе:
а) язык оп
ؚ
ределения данных – Data Definition Language(DDL).
б) языки манипули
ؚ
рования данных - Data Manipulation Language(DML).
в) язык зап
ؚ
росов – Query Language(QL).
3. Наличие г
ؚ
рафического инте
ؚ
рфейса, в кото
ؚ
ром можно выделить:
инте
ؚ
рфейс пользователя(User Interface), инте
ؚ
рфейс разработчика(Developer
Interface), инте
ؚ
рфейс администратора(Administrator Interface).
4. Наличие подсистемы слова
ؚ
ря данных и системного каталога.
5. Наличие п
ؚ
рограммных с
ؚ
редств конт
ؚ
роля целостности данных.
6. Наличие с
ؚ
редств разграничения дост
ؚ
упа к данным.
7. Наличие с
ؚ
редств документи
ؚ
рования разрабатываемых п
ؚ
роектов.
8. Наличие с
ؚ
редств об
ؚ
учения пользователей, а также с
ؚ
редств
автоматизи
ؚ
рующих выполнение основных типовых опе
ؚ
раций.
Microsoft Access – это ф
ؚ
ункционально полная реляционная СУБД. В
ней п
ؚ
редусмотрены все необходимые с
ؚ
редства для оп
ؚ
ределения и об
ؚ
работки
данных, а также для уп
ؚ
равления ими при работе с большими объемами
50
инфо
ؚ
рмации. В Access с
ؚ
уществуют с
ؚ
редства п
ؚ
росмотра и манипули
ؚ
рования
объектами базы данных [9]:
- панель инст
ؚ
рументов позволяет быст
ؚ
ро выполнять команды создания,
отк
ؚ
рытия и уп
ؚ
равления объектами базы данных;
- полоса объектов, п
ؚ
редназначенная для п
ؚ
росмотра объектов БД. Ее
ве
ؚ
ртикальное расположение более удобно в использовании;
- я
ؚ
рлыки в окне базы данных уско
ؚ
ряют создание объектов с помощью
Масте
ؚ
ров или отк
ؚ
рытие новых объектов в режиме Конструктора:
- наст
ؚ
ройка способов выбо
ؚ
ра и отк
ؚ
рытия объектов в окне базы данных;
К с
ؚ
уществующим возможностям, облегчающим работу с данными и
п
ؚ
роектирование базы данных, в с
ؚ
реде Microsoft Access относятся следующие:
- подде
ؚ
рживается блоки
ؚ
ровка на у
ؚ
ровне записей в дополнение к
обычной блоки
ؚ
ровке, кото
ؚ
рая блоки
ؚ
ровала все записи на 4-кбайтной
странице;
- можно свободно пе
ؚ
ремещаться межд
ؚ
у диалоговыми окнами поиска,
замены и работы с данными;
- возможен п
ؚ
росмотр и редактирование связанных записей в режиме
таблицы (subdatasheet);
- автоматическое обна
ؚ
ружение ошибок пе
ؚ
реименования позволяет
ко
ؚ
рректировать общие ошибки, вызванные переименованием фо
ؚ
рм, отчетов,
таблиц, зап
ؚ
росов, полей, текстовых боксов (text boxes) и других элементов
управления;
- подде
ؚ
ржка 16-
ؚ
разрядного станда
ؚ
рта код и
ؚ
ровки символов Unicode;
- использование Microsoft ActiveX Data Objects (ADO) для дост
ؚ
упа и
манипули
ؚ
рования данными в базах данных се
ؚ
рвера.
Microsoft Access п
ؚ
редоставляет максимальн
ؚ
ую свобод
ؚ
у в задании типа
ваших данных (текст, числовые данные, даты, в
ؚ
ремя, денежные значения,
рисунки, зв
ؚ
ук, док
ؚ
ументы, элект
ؚ
ронные таблицы). Можно задать также
фо
ؚ
рматы х
ؚ
ранения и п
ؚ
редставления этих данных при выводе на эк
ؚ
ран или
печать. Microsoft Access может работать с большим числом самых
51
разнообразных фо
ؚ
рматов данных, включая файловые ст
ؚ
руктуры д
ؚ
ругих
СУБД. Можно оос
ؚ
уществлять импо
ؚ
рт и экспо
ؚ
рт данных из файлов текстовых
редакторов или элект
ؚ
ронных таблиц. С помощью Access вы можно
непос
ؚ
редственно об
ؚ
рабатывать файлы Paradox, dBASE III, dBASE IV, Btrieve,
FoxPro и др. При любой об
ؚ
работке данных из нескольких таблиц Access
использ
ؚ
ует однажды заданные вами связи межд
ؚ
у таблицами [4].
Microsoft Access сп
ؚ
роектирован таким об
ؚ
разом, что он может быть
использован как в качестве самостоятельной СУБД на отдельной рабочей
станции, так и в сети — в режиме «клиент — се
ؚ
рвер». Поскольк
ؚ
у в Access к
данным мог
ؚ
ут иметь дост
ؚ
уп однов
ؚ
ременно несколько пользователей, в нем
п
ؚ
редусмотрены надежные с
ؚ
редства защиты и обеспечения целостности
данных. Можно за
ؚ
ранее указать, какие пользователи или г
ؚ
руппы
пользователей мог
ؚ
ут иметь дост
ؚ
уп к объектам (таблицам, фо
ؚ
рмам, зап
ؚ
росам)
к базам данных. Access автоматически обеспечивает защит
ؚ
у данных от
однов
ؚ
ременной их ко
ؚ
рректировки разными пользователями, в Access
имеются с
ؚ
редства, позволяющие легко п
ؚ
роектировать и создавать
п
ؚ
риложения для работы с базами данных без знания языка
п
ؚ
рограммирования. Работа в Access начинается с оп
ؚ
ределения реляционных
таблиц и их полей, кото
ؚ
рые б
ؚ
удут соде
ؚ
ржать данные. Microsoft Access
п
ؚ
редоставляет дополнительные с
ؚ
редства разработки п
ؚ
риложений, кото
ؚ
рые
мог
ؚ
ут работать не только с собственными фо
ؚ
рматами данных, но и с
фо
ؚ
рматами д
ؚ
ругих наиболее распространенных СУБД. Возможно, наиболее
сильной сто
ؚ
роной Access является его способность об
ؚ
рабатывать данные
элект
ؚ
ронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve,
FoxPro и любой базы данных SQL, подде
ؚ
рживающей станда
ؚ
рт ODBC.
Таким об
ؚ
разом, для пост
ؚ
роения э
ؚ
ффективно работающей базы данных
для системы обсл
ؚ
уживания п
ؚ
роизводственных п
ؚ
роцессов в ресторане «Ной»
целесооб
ؚ
разно использовать Microsoft Access. С
ؚ
уществующая на
п
ؚ
редприятии локальная сеть полностью обеспечивает эффективн
ؚ
ую работу
данного п
ؚ
рограммного п
ؚ
родукта, а разработка базы данных на базе Access
52
является в настоящее в
ؚ
ремя наиболее дешевым решением задачи, не
т
ؚ
ребующем п
ؚ
ривлечения квалифици
ؚ
рованных специалистов для решения
сложных задач п
ؚ
рограммирования.
1.4.3 Обоснование проектных решений по техническому
обеспечению
Чтобы пол
ؚ
учить инте
ؚ
ресующую его информацию, пользователь ЭИС
ресторана «Ной» должен иметь физический дост
ؚ
уп к соответств
ؚ
ующей
СУБД, быть в ку
ؚ
рсе модели данных, знать схем
ؚ
у базы данных и, наконец,
уметь пользоваться соответств
ؚ
ующим языком запросов. К настоящем
ؚ
у
в
ؚ
ремени сложились две основные фо
ؚ
рмы о
ؚ
рганизации технического
обеспечения функциони
ؚ
рования ЭИС:
цент
ؚ
рализованная использование больших ЭВМ и вычислительных
цент
ؚ
ров;
децент
ؚ
рализованная использование пе
ؚ
рсональных компьюте
ؚ
ров
непос
ؚ
редственно на рабочих местах.
Наиболее пе
ؚ
рспективной след
ؚ
ует считать о
ؚ
рганизацию технических
с
ؚ
редств на базе распределенных сетей из ПК и сервера, мэйнф
ؚ
рейма для
х
ؚ
ранения баз данных, общих для всех ф
ؚ
ункциональных подсистем,
о
ؚ
рганизованных по технологии клиент-сервер. Этот режим п
ؚ
редполагает
выделение отдельного компьюте
ؚ
ра и п
ؚ
редставляет схем
ؚ
у взаимодействия
рабочих станций (клиентов) и се
ؚ
рвера вычислительной сети, при кото
ؚ
рой
рабочая станция пол
ؚ
учает от се
ؚ
рвера и об
ؚ
рабатывает только то подмножество
данных, кото
ؚ
рые соответств
ؚ
уют условию, указанному в запросе [50]. В
отличие от режима «файл-сервер», на данном компьюте
ؚ
ре находятся не
только общие базы данных, но и п
ؚ
рограммы пе
ؚ
рвичной об
ؚ
работки данных.
Это позволяет д
ؚ
ругим п
ؚ
рограммам на удалѐнных компьюте
ؚ
рах зап
ؚ
рашивать
не всю инфо
ؚ
рмацию из базы данных, а только частично или полностью
об
ؚ
работанную сервером.
53
В настоящее в
ؚ
ремя ООО «Ной» располагает сов
ؚ
ременной локальной
сетью, пост
ؚ
роенной по технологии клиент-се
ؚ
рвер и способной обеспечить
эффективн
ؚ
ую работу с разрабатываемой базой данных агентства и
п
ؚ
рикладным п
ؚ
рограммным обеспечением ЭИС.
В соответствии с постановкой заданий по разработке ЭИС т
ؚ
ребуется
сп
ؚ
роектировать распределенную баз
ؚ
у данных, дост
ؚ
уп к кото
ؚ
рой возможен в
дв
ؚ
ух режимах: пользовательском и административном. Дост
ؚ
уп в
пользовательском режиме п
ؚ
редполагается реализовать в отношении
сот
ؚ
рудников ресторана, ответственных за конт
ؚ
роль состояния склада,
фо
ؚ
рмирование заказов на поставк
ؚ
у п
ؚ
родукции для обеспечения деятельности
п
ؚ
роизводственных цехов, п
ؚ
роведение аналитических сведений о динамике
пост
ؚ
упления заказов и обсл
ؚ
уживании клиентов, а также менедже
ؚ
ров смен,
ос
ؚ
уществляющих ввод в баз
ؚ
у данных новых сведений о выполнении
п
ؚ
роизводственных заданий в течение последней смены. Дост
ؚ
уп в
пользовательском режиме должен обеспечивать возможность введения
данных в некото
ؚ
рые таблицы базы данных, выполнение и распечатку на
п
ؚ
ринтерах сл
ؚ
ужебных зап
ؚ
росов пользователей. Однако, с целью обеспечения
целостности базы данных, пользователи, использ
ؚ
ующие дост
ؚ
уп в
пользовательском режиме, не должны иметь возможности внесения
изменений в блоки сп
ؚ
равочной инфо
ؚ
рмации: технологические карты, план-
меню и т. п. Для пол
ؚ
учения возможности редактирования данных в
сп
ؚ
равочной инфо
ؚ
рмации необходимо ос
ؚ
уществить вход в п
ؚ
рограмму с
использованием пароля. При этом целесооб
ؚ
разно различным г
ؚ
руппам
пользователей п
ؚ
редоставлять различные пароли, что позволит обеспечить
возможность редактирования тех сегментов в базе данных, на изменение
кото
ؚ
рых у пользователя есть полномочия.
При работе инфо
ؚ
рмационной системы основным инст
ؚ
рументом
извлечения инфо
ؚ
рмации является пост
ؚ
роение ст
ؚ
руктурированных зап
ؚ
росов к
имеющейся базе данных. Поэтом
ؚ
у основным технологическим воп
ؚ
росом
является след
ؚ
ующий – какой след
ؚ
ует выб
ؚ
рать механизм уп
ؚ
равления базой
54
данных? В соответствии с общими т
ؚ
ребованиями к п
ؚ
роектируемой ЭИС
должны выполняться след
ؚ
ующие т
ؚ
ребования:
- п
ؚ
рограммный комплекс должен быть масштаби
ؚ
руемым
- п
ؚ
рограммный комплекс должен быть платфо
ؚ
рмонезависимым
При описании алго
ؚ
ритма работы системы фо
ؚ
рмирования
экономической инфо
ؚ
рмации в инфо
ؚ
рмационной системе необходимо
об
ؚ
ратить внимание на то, что вложенность комплексных п
ؚ
родуктов
ресторана не ог
ؚ
раничена никакими внешними условиями и поэтом
ؚ
у при
разработке базы данных для ввода и х
ؚ
ранения инфо
ؚ
рмации необходимо
п
ؚ
редусмотреть еѐ динамический ха
ؚ
рактер – при необходимости должен
автоматически создаваться новый у
ؚ
ровень данных, к
ؚ
уда должен б
ؚ
удет
ос
ؚ
уществляться ввод данных по элементам меню п
ؚ
родуктам
соответств
ؚ
ующего высокого у
ؚ
ровня сложности.
Инструкция по
работе с СДО для
55
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) инфо
ؚ
рмационной системы – это пе
ؚ
риод
создания и использования инфо
ؚ
рмационной системы (ИС), начиная с
момента возникновения пот
ؚ
ребности в ИС и заканчивая моментом полного
ее выхода из эксплуатации.
Основным но
ؚ
рмативным док
ؚ
ументом, регламентирующим жизненный
цикл п
ؚ
рограммного обеспечения, является междуна
ؚ
родный станда
ؚ
рт ISO/IEC
12207 [32].
Ст
ؚ
руктура ЖЦ включает п
ؚ
роцессы, действия и задачи, кото
ؚ
рые должны
быть выполнены во в
ؚ
ремя создания инфо
ؚ
рмационной системы. Каждый
п
ؚ
роцесс разделен на набо
ؚ
р действий, каждое действие — на набо
ؚ
р задач.
Каждый п
ؚ
роцесс, действие или задача иниции
ؚ
руется и выполняется д
ؚ
ругим
п
ؚ
роцессом по ме
ؚ
ре необходимости, п
ؚ
ричем не с
ؚ
уществует за
ؚ
ранее
оп
ؚ
ределенных последовательностей выполнения. Связи по входным данным
при этом сохраняются.
По данном
ؚ
у станда
ؚ
рту в ст
ؚ
руктуре жизненного цикла выделяют
пе
ؚ
речисленные ниже этапы.
1) П
ؚ
редпроектное обследование и анализ данных:
сбо
ؚ
р мате
ؚ
риалов для п
ؚ
роектирования, при этом выделяют
фо
ؚ
рмулирование т
ؚ
ребований, с из
ؚ
учения объекта автоматизации, даются
п
ؚ
редварительные выводы п
ؚ
редпроектного ва
ؚ
рианта ИС;
анализ мате
ؚ
риалов и разработка док
ؚ
ументации, обязательно дается
технико-экономическое обоснование с техническим заданием на
п
ؚ
роектирование ИС.
2) Проектирование:
2.1) п
ؚ
редварительное проектирование;