基于工作流的系统数据库设计

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

这些问题引起了许多问题。例如：

• 在您的表中，Workflow将从一个状态到另一个状态的转换定义为将分配从一个用户更改为下一个用户。
• 这可能是个问题。假设使用者生病了，离开，度假，.然后你的流量就被堵住了。
• 它也不允许群体概念。
• 其他人(如我)将定义一个转换表。StartState，NextState.
• 工作流程将是一个过渡列表。
• 每个转换都要求用户具有某种类型。或者从用户管理的角度来看，有一定的角色，或者是一个组的成员。

如果您的工作流是固定的，并且不受更改的影响，那么您的方法就可以了。但是，如果工作流是灵活的，或者可能会更改/适应，那么您应该使用更灵活的工作流程。

您所讨论的设置类型让我想到了Jira软件()，在这里您定义了票证、状态、工作流和用户。您是否可以使用工作流管理工具(例如，购买或OpenSource)？从长远来看，这可能比建造一个更便宜。

您的模型可能会扩展到包括：

• 客户。这个建议是给哪个客户的？
• 谁是销售代表或客户经理，负责审核工作流程并将其向前推进？
• 链接到其他系统:它如何链接到采购，应收账款，.

到目前为止，这需要一个深入的分析，这是很难做在这样的媒介(所以)。

编辑: 20181004

我在您的评论之后添加了以下模型。我决定将工作流放在数据库中：

​

​

注(按字母顺序排列的表格)：

• 员工

- Each employee can be linked to n number of EmployeeRole via the Employee\_has\_EmployeeRole table.

• 建议书

- An Employee is linked as the Sales Officer, since he initiates a proposal.
- A workflow is linked since many workflows could exist for different proposals.

• 过渡

- Linked to State twice.  The start state and the end state.
- An EmployeeRole is linked, to identify which role an employee must have to perform this transition.
- Enforcing that will be done by the application.

• Workrlow_has_Transition

- Links Transitions to Workflows.
- The Employee who completed the transition is recorded here.
- The date it was done is also kept here.
- The OrderInWorkflow is just a number that allows you to order Workflow\_has\_Transition entries.
- The application will have to make sure a Transition is not done before the others of lower order are done (i.e. DoneDate is null).
- It will also validate that the Employee trying to complete it has the proper 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.

在浏览应用程序场景时，您将发现空白或缺少的项。

是否要记录拒绝转换的情况？那又如何处理呢？您向具有此转换角色的员工发送通知以检查它吗？

你想保留提案的完整历史吗？例如。它的转变X被拒绝了两次，但批准了第三次。

有许多类似这样的场景，这些场景将显示模型的弱点，在完成此分析时您将修复这些缺陷。现在它还不完美，我没有花很多时间在它上。但这是一个起点，说明了我的想法。

Answer 2

我建议你在这段时间里

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时会使生活变得更容易。

希望这会有所帮助，但我建议您做一个流程图，看看所有可能的用例。