Алгоритм побудови типових бізнес-процесів

Проектирование реляционной модели

При проектировании баз данных в реляционной модели следует учитывать специфику документооборота системы CompanyMedia. Набор таблиц в БД будет отражать движение связанных документов по рабочим местам.

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

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

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

Для формы «РКК» значимыми полями будут являться:

• · вид документа;
• · корреспондент;
• · подписант;
• · адресат;
• · место регистрации.

Значимые поля формы «Резолюция»:

• · автор;
• · исполнитель.

Используемые поля формы «Ознакомление»:

• · инициатор;
• · участник.

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

Для тестирования алгоритма с помощью среды Microsoft Management Studio созданы следующие таблицы:

• 1. таблица карточки документа CardDocs;
• 2. лист ознакомления LO1;
• 3. карточки резолюции:
• 3.1. R111 — резолюция 1-ого уровня;
• 3.2. R121 — резолюция 1-ого уровня;
• 3.3. R131 — резолюция 1-ого уровня;
• 3.4. R211 — резолюция 2-ого уровня;
• 3.5. R311 — резолюция 3-его уровня;

А также таблицы со справочными данными:

• 4. Departs — справочник отделов в организации;
• 5. Doc_type — возможные виды документов (приказ, служебная записка, письмо и т. д.);
• 6. Organizations — справочник организаций;
• 7. Posts — справочник должностей в организации.

В таблицах пунктов 1−3 первичным ключом являются Id документов. Также во всех таблицах предполагается существование внешнего ключа по полю par_id (ссылка на документ). Внешний ключ будет ссылаться на Id документа в предшествующей таблице.

Для таблицы LO1 и резолюций 1-ого уровня (R111, R121, R131) внешний ключ будет ссылаться на Id документа из таблицы CardDocs. Резолюция 2-ого уровня R211 ссылается на Id Документа из таблицы R111. Резолюция 3-его уровня R311 — на таблицу R211.

Тем самым обеспечивается целостность спроектированной базы данных.