Проектирование базы данных для системы на основе Workflow

Question

Я проектирую базу данных для сбытовой компании, имеющей сложный рабочий процесс.Процесс начинается с менеджера по продажам, затем идет к руководителю группы и, наконец, к менеджеру.Перед утверждением предложения менеджер отправит его в отдел бизнес-аналитики.После получения замечаний от dba он может отправить предложение обратно сотруднику отдела продаж для внесения изменений в предложение.Менеджер также может отклонить предложение.В случае удовлетворения менеджер направит его директору по продажам.Таблицы разработаны следующим образом: -

Table: ProposalBasicData 

Id, Title, ProposalDate, Scope, Objective

Table: ProposalState

Id, Name
(Values - Forwarded , Approved ,  Returned  ,  Rejected)

Table: UserType

Id, Name
(Values - SalesOfficer, TeamLead,  Manager ,  DBA, DirectorSales)

Table: WorkFlow

Id, StartUserType, NextUserType, StateId, IsActive

Table: RequestAction 

Id, ProposalId, WorkFlowId, UserId, ActionDate

Пожалуйста, предложите относительно дизайна.

Answer 1

Я бы посоветовал вам структурировать что-то вроде этого

ProposalBasicData {PBID,Title, ProposalDate,Scope,Objective} 
ProposalState {PSID,Name}
UserType {UTID,Name}
User {UID,Name,UTID(Usertype UTID FK) }
Request{ RID, StartUID, StartDate ,PSID, IsActive } 
RequestAction {AID,RID, RequesterUID, ReceiverUID, Date, Comments, IsCompleted }

, так как я думаю, что может быть несколько пользователей одного типа, более того, вы захотите прокомментировать, почему было отклонено RequestAction,Запрашивающая сторона выполнит действие requestAction для получателя, и, если оно выполнено, оно будет показано в системе, что упростит жизнь при обработке нескольких запросов requestActions одного и того же запроса.

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

Answer 2

Есть много вопросов, поднятых такими проблемами.Например:

• в ваших таблицах Workflow определяет переходы из одного состояния в другое как изменение назначения от одного пользователя к другому.
• это может быть проблемой.Допустим, пользователь болен, уходит, в отпуск, ... Тогда ваш поток заблокирован.
• Это также не учитывает концепцию группы.
• другие (как я) определяттаблица переходов.StartState, NextState.
• Рабочий процесс представляет собой список переходов.
• Каждый переход требует, чтобы пользователь был определенного типа.Или с точки зрения управления пользователями, иметь определенную роль или быть членом группы.

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

Тип настройки, о которой вы говорите, заставляет меня задуматься о программном обеспечении Jira (форма Atlassian), где вы определяететикеты, со статусом, рабочими процессами и пользователями.Возможно ли использовать инструмент управления рабочим процессом (т. Е. Buyasse или OpenSource)?В долгосрочной перспективе это может быть дешевле, чем строительство.

Ваша модель потенциально может быть расширена, чтобы включить:

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

Все это на сегодняшний день требует глубокого анализа, который трудно выполнить на таких носителях, как этот (SO).

---

РЕДАКТИРОВАТЬ: 20181004

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

Примечания (таблицы в алфавитном порядке):

• Сотрудник

  • Каждый сотрудник может быть связан с n номером EmployeeRole через таблицу Employee_has_EmployeeRole.

• Предложение

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

• Переход

  • Дважды связан с государством.Начальное состояние и конечное состояние.
  • Связано EmployeeRole, чтобы определить, какую роль сотрудник должен выполнять для этого перехода.
  • Обеспечение выполнения приложением.

• Workrlow_has_Transition

  • Связывает переходы с рабочими процессами.
  • Сотрудник, который завершил переход, записывается здесь.
  • Theдата, в которой это было сделано, также хранится здесь.
  • OrderInWorkflow - это просто число, позволяющее упорядочивать записи Workflow_has_Transition.
  • Приложение должно убедиться, что переход не выполнен, прежде чем другиеболее низкого порядка (т. е. DoneDate имеет значение null).
  • Также будет подтверждено, что Сотрудник, пытающийся выполнить его, имеет правильную EmployeeRole.

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

Сценарии приложения:

- Start a Proposal
    - Verify that the user trying to start a new one has the role "Sales Officer"
    - Collect basic information.
    - Link the Sales Officer to it (current user).
    - Link a Workflow to it.  Only propose the workflows which have at least 1 Workflow_has_Transition.
    - Send a notification to the Employee(s) which have the EmployeeRole for the first Workflow_has_Transition for this new Workflow.
    - These employees receive a notification.
- Progressing through the workflow
    - An employee receives a notification about a Proposal and it's "todo" Transition.
    - Employee views Proposal and Workflow (use the OrderInWorkflow to ORDER BY Transitions).
    - Employee approves if he has the proper EmployeeRole, fill DoneBy_idEmployee and DoneDate.

При просмотре сценариев приложения вы найдете пробелы или пропущенные элементы.

Пример 1 Вы хотите записать отклонение Перехода?Как это будет обработано тогда?Вы отправляете уведомление сотрудникам с ролью для этого Перехода, чтобы просмотреть его?

Пример 2. Вы хотите сохранить полную историю предложения?Ex.Это Переход X отклонен дважды, но одобрен в третий раз.

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