Разработка средств информационной поддержки менеджмента ресторанного зала (стр. 5 из 13)

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

2.1.2 Разработка инфологической модели предметной области

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

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

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

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

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

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

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

Связь сущностей характеризуется идентификацией и степенью.

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

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

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

На данной диаграмме показана связь между сущностями «Меню» и «Рецепт». Атрибутами сущности «Меню» является: наименования блюда, его цена и его категория (блюдо или напиток). Атрибутами сущности «Рецепт» является: наименования блюда и имя файла. Степень связи многие к одному.

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

2.1.3 Разработка даталогической модели базы данных

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

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

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

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

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

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

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

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

2.1.4 Функциональная структура СИП МРЗ

Характеризуя структуру системы, можно выделить несколько основных элементов:

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

- Модуль «Администратор».

- Модуль «Официант».

- Модуль «Кассир».

- Модуль «Повар».

- Модуль «Бармен».

Информация в БД поступает со склада автоматически. Далее через БД происходит обмен между модулями. Рассмотрим работу каждого модуля отдельно.

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

Модуль «Официант». Официант получает из БД все наименования блюда. Заполняя формы, официант вносит в БД информацию о заказе (номер заказа, номер столика, наименования заказанного блюда, количество порций, дату).

Модули «Повар» и «Бармен» работают одинаково. Повар и бармен получают информацию из БД (наименования блюда, количество порций, рецепт).

2.1.5 Разработка алгоритма функционирования СИП МРЗ

Алгоритм - это

· описание последовательности действий для решения задачи или достижения поставленной цели;

· правила выполнения основных операций обработки данных;

· описание вычислений по математическим формулам.

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

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

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

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