Разработка автоматизированной системы учета договоров для отеля (стр. 2 из 7)

3.1 Описание задачи

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

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

О контрагенте (физическое лицо)(фио, адрес, домашний телефон, e-mail);

О контрагенте (юридическое лицо)(адрес фирмы, контактный телефон, e-mail).

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

Вывести отчеты об:основных договоров, дополнительных договоров, просроченных договоров, основных и дополнительных договоров.

3.2 Проектирование структуры базы данных методом "Сущность - связь"

3.2.1 Построение диаграммы ER-типа

1)Определение типов сущностей

Стержневые сущности: Основные договоры, дополнительные договоры.

Характеристические сущности: Юридическое лицо, физическое лицо,информация о исполнителе.

2) Определение типов и характеристик связей

Сущности "Основные договоры" и "Дополнительные договоры" имеют степень отношения 1:n, класс принадлежности необязательный и обязательный соответственно. Следовательно, генерируем 2 отношения по одному на сущность.

Сущности "Планируемая дата" и "Основные договоры" имеют степень отношения 1:n, класс принадлежности не обязательный и обязательный соответственно. Следовательно, генерируем 2 отношения по одному на сущность.

Сущности "Основные договоры" и "Юридическое лицо" имеют степень отношения 1:n, класс принадлежности обязательный и обязательный соответственно. Следовательно, генерируем 2 отношения по одному на сущность. Сущности "Физическое лицо" и" имеют степень отношения 1:1, класс принадлежности обязательный и обязательный соответственно. Следовательно, генерируем 2 отношения, по одному на сущность.

Сущности "Основные" и "Информация о исполнителе" имеют степень отношения 1:n, класс принадлежности обязательный и обязательный соответственно. Следовательно генерируем 2 отношения, по одному отношению на сущность.

По выделенным отношениям построим диаграмму ER-типа:

Рис 3.1 - Диаграмма ER-типа

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

Построим предварительный набор отношений, и определим их атрибуты:

Основные договоры (N_Agr#, Регистрационный_номер, Юридический_номер, Дата_договора, Дата_регистрации,Срок_окончания , Контрагент, Объект_договора, Сумма_договора, Планируемая_дата# );

Дополнительные договоры (N_Sup_Agr#, Регистрационный_номер, Юридический_номер, Дата_регистрации, Дата_договора,Предмет_договора,Сумма_договора, Срок_окончания, Контрагент#);

Юридическое лицо (N_Contr1#, Контактный_телефон, Количество_сделок, e-mail, Контрагент#);

Информация о исполнителе (N_P#, Адрес,Сотовый_телефон, Количество_выполненых_сделок, Заработная_плата);

Физическое лицо(N_Contr2#, Адрес, Телефон, Контрагент#, e-mail).

3.2.3 Проверка отношений на НФБК

Отношение Основные договора:

Список функциональных зависимостей:

N_Agr#-Регистрационный номер

N_Agr#-Юридический номер

N_Agr#-Дата договора

N_Agr#-Дата регистрации

N_Agr#-Срок окончания

N_Agr#-Контрагент

N_Agr#-Сумма договора

N_Agr#-Предмет договора

N_Agr#-дата#

Детерминанты: N_Agr#

Возможные ключи: N_Agr#

Отношение Основные договор находится в НФБК

Отношение Дополнительные договора:

Список функциональных зависимостей:

N_Sup_Agr#-Доп_Регистрационный номер

N_Sup_Agr#-Доп_Юридический номер

N_Sup_Agr#-Доп_Дата регистрации

N_Sup_Agr#-Доп_Дата договора

N_Sup_Agr#-Доп_Предмет договора

N_Sup_Agr#-Доп_Сумма договора

N_Sup_Agr#-Доп_Срок окончания

N_Sup_Agr#-Доп_Контрагент#

Детерминанты: N_Sup_Agr#

Возможные ключи: N_Sup_Agr#

Отношение Дополнительные договора находится в НФБК

Отношение Юридическое лицо:

Список функциональных зависимостей:

N_Contr1#- Контактный телефон

N_Contr1#- Количество сделок

N_Contr1#- e-mail

N_Contr1#-Контрагент#

Детерминанты: N_Contr1#

Возможные ключи: N_Contr1#

Отношение Юридическое лицо находится в НФБК

Отношение Физическое лицо:

Список функциональных зависимостей:

N_Contr2#-Адрес

N_Contr2#-Телефон

N_Contr2#- e-mail

N_Contr2#-Контрагент#

Детерминанты: N_Contr2#

Возможные ключи: N_Contr2#

Отношение Физическое лицо находится в НФБК

Отношение Планируемая дата:

Список функциональных зависимостей:

N_D#-Дата

Детерминанты: N_D#

Возможные ключи: N_D#

Отношение Спец.Одежда находится в НФБК

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

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

Основные договоры (N_Agr#, Регистрационный_номер, Юридический_номер, Дата_договора, Дата_регистрации,Срок_окончания , Контрагент, Объект_договора, Сумма_договора, Планируемая_дата# );

Дополнительные договоры (N_Sup_Agr#, Регистрационный_номер, Юридический_номер, Дата_регистрации, Дата_договора,Предмет_договора,Сумма_договора, Срок_окончания, Контрагент#);

Юридическое лицо (N_Contr1#, Контактный_телефон, Количество_сделок, e-mail, Контрагент#);

Физическое лицо (N_Contr2#, Адрес, Телефон, Контрагент#, e-mail);

Просроченные договоры (N_FD#,Рег_номер,Юрид_номер,Дата_регистрации,Дата_договора,Исполнитель,Сумма_договора, Объект_договора, Контрагент#);

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

3.3 Проектирование структуры БД при помощи CASE-средства Erwin

3.3.1 Проектирование логической и физической схемы БД

Используя построенную диаграмму ER-типа представленную выше, спроектируем базу данных при помощи CASE-средства Erwin. Все связи из диаграммы ER-типа при переносе в нотацию IDEF1XCASE-средства Erwin имеют характеристики:

Таблица 1 – Характеристики связей

Связь	Тип связи	Количество элементов
Основной договор-дополнительный договор	Идентифицирующая	1 или много
Основной договор-Юридическое лицо	Идентифицирующая	1 или много
Основной договор-Физическое лицо	Идентифицирующая	1
Дополнительный договор-информация о исполнителе	Не Идентифицирующая	Много ко многим

Рис 3.2 - "Логическая модель. Нотация IDEF0"

Рис 3.3 – Физическая модель данных

3.3.2 Исследование информационной модели

На основе физической модели ERwin был сгенерирован SQL – скрипт (Приложение A), в котором представлены:

· 5 таблиц;

· 10 триггеров;

· 4генераторов суррогатных ключей;

В результате проверки SQL-скрипта в CASE-средстве ErwinExaminer 4.0, получен отчет Рисунок 3.4.

Рисунок 3.4 – Результат проверки SQL-скрипта

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

4. Программное обеспечение

4.1 Описание функций, выполняемых приложением

Функции, выполняемые программой:

1)Добавление, удаление и редактирование данных (основных договоров,

дополнительных, словаря дат, а так же информации о контрагентах );

2)Просмотр просроченных договоров;

3)Сортировка (упорядочение) записей (строк) по возрастанию;

4)Поиска конкретной записи в БД;

5)Фильтрации данных (отбора записей);

6)Выводит графики;

7)Выполняет экспорт из БД в MsWord;

8)Формирование отчетности для основных и дополнительных договоров.

4.2 Проектирование ПО с помощью CASE - пакета "EnterpriseArchitect 4.0"

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

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

Диаграмма вариантов использования разрабатываемой системы представлена на рисунке 4.1.