Автоматизация обработки информации по работе туристической фирмы

 

Определим связи:

Связь между сущностями Type/Dish(тип/блюдо):

Блюдо имеет один тип. Один тип может  соответствовать разным блюдам. Блюдо обязано иметь тип. Из этого следует, что один экземпляр сущности Type может быть связан с N экземплярами сущности Dish. Один экземпляр сущности Dish связан только с одним экземпляром сущности Type. Таким образом, мы получили связь 1 :N. Класс принадлежности сущности Dish обязательный.

Связь  Dish/Recipe (блюдо/рецепт) имеет следующие характеристики:

Каждое блюдо может иметь один рецепт. В свою очередь каждый рецепт принадлежит одному блюду. Блюдо может не иметь рецепта. Рецепт должен иметь блюдо. Из этого следует, что один экземпляр сущности Dish может быть связан c 1 экземплярами сущности Recipe. Каждый экземпляр сущности Recipe может быть связан с 1 экземплярами сущности Dish. Таким образом, мы получили связь    1:1, класс принадлежности сущности Recipe обязательный.

Связь Dish/Consumption(блюдо/расход):

Каждый блюдо может обладать нескольким расходами. В свою очередь каждый расход может принадлежать только одному блюду. Для каждого расхода должен быть указан хотя бы одно блюдо. Из этого следует, что один экземпляр сущности Dish может быть связан c N экземплярами сущности Consumption. Каждый экземпляр сущности Consumption может быть связан с 1 экземплярами сущности Dish. Таким образом, мы получили связь 1:n, класс принадлежности сущности Consumption обязательный.

Dish/Product (блюдо/продукт):

Каждое блюдо может  включать в состав несколько продуктов. В свою очередь каждый продукт может требоваться в нескольких блюд. Для каждого блюда должен быть указан хотя бы один продукт, не каждый продукт может быть в блюде. Из этого следует, что один экземпляр сущности Dish может быть связан c M экземплярами сущности Product. Каждый экземпляр сущности Product может быть связан с N экземплярами сущности Dish. Таким образом, мы получили связь N :M, класс принадлежности сущности Dish обязательный.

Логическая модель представлена в приложении А (рис. 5).

3.1.2 Генерация набора предварительных отношений

 

Генерация набора предварительных  отношений производится по 8 основным правилам. В результате было получено 6 отношений:

Тип (Номер типа, Название типа);

Блюдо (Номер блюда, Номер типа, Название блюда, Цена, Калории, Рисунок);

Рецепт (Номер рецепта, Описание рецепта, Номер блюда);

Расход (Номер расхода, Номер блюда, Количество порций, Дата, Столик, Адрес, Фамилия_Имя_Отчество, Телефон);

Продукт_Блюдо (Номер блюда, Номер продукта, Вес);

Продукт (Номер продукта, Название продукта, Количество продукта).

База данных проектировалась на Erwin 4.1. Физическая модель представлена в приложении А (рис. 6).

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

Генераторы

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

Например, добавление генератора к  таблице Product:

CREATE GENERATOR Product_ID;

set term !! ;

CREATE TRIGGER tI_Product_ID FOR Product Before INSERT  POSITION 0 AS

   begin

   New.N_Product=Gen_ID(Product_ID,1);

end!!

Триггеры

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

Триггер никогда не вызывается непосредственно. Наоборот, когда приложение или пользователь пытаются выполнить инструкцию INSERT, UPDATE или DELETE над строкой в таблице, любые триггеры связанные с этой таблицей и операцией автоматически выполняются.

Рассмотрим пример. Ниже приведен код триггера, который срабатывает  при добавлении нового блюда:

CREATE TRIGGER tI_Dish FOR Dish AFTER INSERT AS

DECLARE VARIABLE numrows INTEGER;

BEGIN

    select count(*)

      from Type

      where

        NEW.N_Type = Type.N_Type into numrows;

    IF (

      numrows = 0

    ) THEN

    BEGIN

      EXCEPTION ERWIN_CHILD_INSERT_RESTRICT;

    END

END !!

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

Хранимая процедура FIND_CONSUMPTION возвращает в выходном параметре название блюда NAZ_DISH, количество  порций KOL и цену PR блюд, дата потребления которых находится в интервале дат (входной параметр), причем количество порций блюд за предложенный период суммируется:

CREATE PROCEDURE FIND_CONSUMPTION (B_DATA DATE,A_DATA DATE)

RETURNS (NAZ_DISH VARCHAR (20), KOL INTEGER, PR INTEGER)  

AS

BEGIN

      FOR

             SELECT Dish_Name ,sum(N_Portion),sum(Price* N_Portion)

             FROM Dish,Consumption

             WHERE Dish.N_Dish=Consumption.N_Dish AND

                   Consumption.Date_of_order BETWEEN :B_Data AND :A_DATA

             GROUP BY Dish_Name

       INTO : NAZ_DISH ,:KOL, :PR  

       DO

BEGIN  

SUSPEND;

  END

 END;

 

Хранимая процедура TIP_DISH возвращает в выходном параметре LIST номер типа блюда, задаваемого входным параметром T_N:

 

CREATE PROCEDURE TIP_DISH (T_N INTEGER)

RETURNS (LIST VARCHAR (20))  

AS

BEGIN

      FOR

             SELECT Distinct Dish_Name FROM Dish,Tip

             WHERE :T_N = Dish.N_Type

             INTO : LIST

     DO

      BEGIN

       SUSPEND;

     END

 END;

 

Хранимая процедура FIND_PRODUCT возвращает в выходых параметрах PROD продукты и REC рецепт, соответствующие номеру блюда - входному параметру В_N:

 

CREATE PROCEDURE FIND_PRODUCT (B_N INTEGER)

RETURNS (PROD CHAR (18), REC VARCHAR (500))  

AS

BEGIN

      FOR

             SELECT Product_Name, Cooking_method

             FROM PRODUCT, RECIPE,Product_Dish

             WHERE :B_N = Product_Dish.N_Dish

             AND Product.N_product=Product_Dish.N_Product

             AND Product_Dish.N_Dish=RECIPE.N_Dish

             INTO : PROD, :REC

      DO

       BEGIN

        SUSPEND;

       END

 END;

 

Полученный SQL–скрипт приведен в приложении Б.

3.1.3 Исследование набора отношений на избыточность

 

Ни одно отношение не имеет множества  атрибутов, являющегося подмножеством множества атрибутов какого-либо другого отношения

 

 

4 Тестирование информационной модели с использованием CASE-пакета

 

   Информационная модель тестируется при помощи программы Erwin Examiner. Обнаружены следующие ошибки:

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

• UndefinedAlternateKey. Таблица имеет суррогатный первичный ключ и не имеет альтернативного ключа.

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

 

• MissingIndex. Отсутствие индексов, например на внешнем ключе.

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

 

5 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1 Требования к системе

5.1.1 Функциональные требования

 

На  основе Постановки задачи и дополнительных требований к системе определён окончательный набор функций:

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

Требования  к программному обеспечению

Для функционирования программы необходимо следующее:

• Операционная система – Windows XP Professional, Windows 7, Windows Vista;
• СУБД InterBase версии 1.0 и выше;

 

5.1.2 Нефункциональные требования

Удобство использования

 

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

К развёртыванию системы предъявляются  следующие требования: простая, быстрая и удобная инсталляция и настройка.

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

• эргономичность;
• эстетическая привлекательность;

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

 

Надёжность

 

К надёжности системы  предъявляются следующие требования:

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

5.2 Архитектура и структура системы

 

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

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

5.3 Базовое программное обеспечение

5.3.1 Операционная система

 

Система разрабатывается  для работы в операционных системах Windows XP/Vista/7. Эти операционные системы являются фактическим стандартом и установлены на абсолютном большинстве компьютеров учебных и иных заведений, что обуславливает лёгкость освоения интерфейса системы. Операционные системы Windows XP/Vista/7 функционируют достаточно стабильно и соответствуют требованиям к надёжности работы. Процесс разработки Windows-приложений является более эффективным по сравнению с другими операционными системами ввиду существования мощных визуальных сред программирования и дополнительного программного обеспечения.

5.3.2 Средства разработки

 

Процесс разработки ведётся  в визуальной среде программирования Borland С++ 6. Драйверы баз данных dbGo for ADO, dbExpress и BDE, входящие в состав C++Builder, обеспечивают высокопроизводительную работу приложений с такими СУБД, как DB2, Informix, Oracle, Sybase, Microsoft SQL Server, MySQL, Access, Paradox и InterBase. Широкий выбор управляемых данными элементов интерфейса дает возможность быстро создавать прототипы приложений. SQL Monitor и другие отладочные инструменты служат повышению производительности, масштабируемости и уменьшению времени отклика приложений баз данных.

Для создания базы данных использовался InterBase SMP 2009, который объединяет в себе преимущества производительности, которые предлагает мультигенерационная архитектура (multi-generational architecture), с возможностями журналирования и восстановления после сбоев. Новые функции безопасности и шифрования обеспечивают улучшенную защиту данных. Удобная установка, компактность, автоматическое восстановление после сбоев, Unicode, встроенная поддержка симметричной многопроцессорной обработки, соответствие стандарту SQL 92 и минимальные требования к обслуживанию делают InterBase SMP 2009 идеальной базой данных (БД) для встроенных и ответственных серверных приложений для малых и средних организаций.

5.4 Диаграмма вариантов использования

 

Диаграмма вариантов использования     (Use Case, а также: вариант использования, сценарий использования) - спецификация последовательности действий (варианты последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актерами (англ. Actors).

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

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

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