РАЗРАБОТКА ЛОГИЧЕСКОЙ МОДЕЛИ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ

3.         РАЗРАБОТКА ЛОГИЧЕСКОЙ МОДЕЛИ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ

На основе функциональной модели была построена логическая модель. В логической модели выделено 10 сущностей:

1)         Vnutr_documents –содержит сведения обо всех внутренних документах, используемых организацией;

2)         ishod_documents – содержит сведения об исходящих документах гимназии ;

3)         vid_documenta – содержит справочную информацию о видах документов, используемых в школе ;

4)         vhod_documents - содержит сведения о входящих документах гимназии;

5)         potoki_dokumentov – содержит сведения о потоках документов, характеризующих документооборот организации;

6)         podpischik - содержит сведения, касающиеся подписчиков документов;

7)         dolgnosty – содержит справочную информацию о штатных должностях гимназии;

8)         ispolnitely – содержит сведения, касающиеся исполнителей ;

9)         podrazdeleniya – содержит сведения о структурных подразделениях организации; 10)sotrudniki – содержит информацию о сотрудниках.

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

4.         РАЗРАБОТКА МОДЕЛИ ПРЕДМЕТНОГО ВОПЛОЩЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ

 

4.1      Физическая модель, структура Базы Данных

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

Рис.3 "Физическая модель данных"

База данных имеет следующую структуру:

Vnutr_documents:

vnutr_reg_number(текст) – внутренний регистрационный номер

Date_registr(дата) – дата регистрации документа

Soderzhanie(текст) – содержание документа

Srok_ispolneniya(дата) – срок исполнения документа

Status_documenta(текст) – статус документа

ishod_documents:

ishod_number(текст) – номер исходящего документа

Date_registr(дата) – дата регистрации исходящего документа

Soderzhanie(текст) – содержание документа

Srok_ispolneniya(дата) – срок исполнения документа

Status_documenta(текст) – статус документа

vhod_documents:

vhod_number – номер входящего документа

Date_registr(дата) – дата регистрации исходящего документа

Soderzhanie(текст) – содержание документа

Srok_ispolneniya(дата) – срок исполнения документа

Status_documenta(текст) – статус документа

vid_documenta:

Code_vida_documenta (текст) – код вида документа

Vid _documenta(текст) – вид документа

Tip_documenta(текст) – тип документа

potoki_dokumentov:

Code_potoka(текст) – код потока документов

Naimenovanie_potoka(текст) - наименование потока документов

Podpischik:

Code_podpischika(текст) – код подписчика

Podpischik(текст) – ФИО подписчика

Code_dolgnosty – код должности

Ispolnitely:

Code_ispolnitelya(текст) – код исполнителя

Ispolnitely(текст) – ФИО исполнителя

Code_dolgnosty – код должности

Podrazdelenie:

Code_podrazdeleniya(текст) – код подразделения

Nazvanie_podradeleniya(текст) – название подразделения

Dolgnosty:

Code_dolgnosty(текст) – код должности

Dolgnosty (текст) – должность

Sotrudniki:

Sotrudnik(текст) – ФИО сотрудника

Login(текст) – системное имя

Password(текст) - пароль

Kabinet(текст) - № кабинета сотрудника

Telephone(текст) - № телефона сотрудника

e-mail(текст) – адрес электронной почты сотрудника

AS(логический) – администрирование системы

AD(логический) – администрирование документооборота

RK(логический) – расширенный контроль

KIZ(логический) – контроль исполнения задания

CR(логический) – создание отчетов

SRF(логический) – создание регистрационных форм.

В логических полях БД фиксируются права пользователей ИСУД.

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

Рис.4 "Схема данных"

 

4.2 Архитектурная функциональность

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

Безусловно, основным видом архитектуры для ИСУД является архитектура "клиент-сервер" (рис. 5.).

Рис. 5. Клиент-серверная архитектура СУД

 

Однако проектируемая система поддерживает архитектуру "файл-сервер" (рис. 6). В дальнейшем будет осуществлен переход к архитектуре "Клиент- Сервер".

Рис. 6. Файл-серверная архитектура СУД

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

Сравнительная характеристика "клиент-серверной" и "файл-серверной" архитектур представлена в таблице 1.

Таблица 1 Сравнительная характеристика архитектур

Файловая система	Клиент-серверная система
Низкая цена	Большой разброс цен
Хорошо подходит для малых БД и БД конечного пользователя	Годится для малых БД. Не подходит для БД конечного пользователя
Масштабируется до средних БД	Масштабируется до больших БД
Минимально централизованное управление	Высокая степень централизации управления
Очень гибкий интерфейс конечного пользователя	Гибкий интерфейс конечного пользователя
Низкая или средняя зависимость от поставщика	Средняя зависимость от поставщика
Неэффективно использует сеть	Может эффективно использовать сеть

4.3      Функциональная целостность

Понятие функциональной целостности имеет отношение к сохранности документов в базе данных в неизменном виде.

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

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