时间戳

首页 > 解决方案 > 基于工作流的系统的数据库设计

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

问题描述

我正在为具有复杂工作流程的销售公司设计数据库。流程从销售官开始，然后是团队主管，最后是经理。在批准提案之前，经理会将其发送给部门业务分析师。在得到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

请就设计提出建议。

标签： databasepostgresqldatabase-designrelational-database

解决方案

此类问题引发了许多问题。前任：

  • 在您的表格中，工作流将状态转换定义为将分配从一个用户更改为下一个用户。
  • 这可能是一个问题。假设用户生病、离开、休假……然后您的流程被阻塞。
  • 它也不允许组概念。
  • 其他人（比如我）会定义一个转换表。开始状态，下一个状态。
  • 工作流将是一个转换列表。
  • 每个转换都要求用户属于某种类型。或者从用户管理的角度来看，有一定的角色，或者是某个组的成员。

如果您的工作流程是固定的并且不会更改，那么您的方法可能没问题。但是如果工作流程是灵活的或者可能会改变/调整，你应该选择更灵活的东西。

您所说的设置类型让我想到了 Jira 软件（来自 Atlassian），您可以在其中定义工单、状态、工作流程和用户。您是否可以使用（即购买或开源）工作流管理工具？从长远来看，它可能比建造一个更便宜。

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

  • 客户。提案是针对哪个客户的？
  • 谁是负责审核工作流程并将其向前推进的销售代表或客户经理？
  • 链接到其他系统：它如何链接到采购、应收账款……

时至今日，这需要进行深入分析，而这在诸如此类 (SO) 的媒体上是很难做到的。

编辑：20181004

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

在此处输入图像描述

注释（按字母顺序排列的表格）：

  • 员工

    • 每个员工可以通过 Employee_has_EmployeeRole 表链接到 n 个 EmployeeRole。

  • 提议

    • 员工被链接为销售官，因为他发起了提案。
    • 工作流程是链接的，因为不同提案可能存在许多工作流程。

  • 过渡

    • 两次链接到状态。开始状态和结束状态。
    • 一个 EmployeeRole 被链接，以确定员工必须具有哪个角色才能执行此转换。
    • 强制执行将由应用程序完成。

  • Workrlow_has_Transition

    • 将转换链接到工作流。
    • 完成转换的员工记录在这里。
    • 它的完成日期也保存在这里。
    • OrderInWorkflow 只是一个允许您订购 Workflow_has_Transition 条目的数字。
    • 应用程序必须确保在其他低阶转换完成之前没有完成转换（即 DoneDate 为空）。
    • 它还将验证尝试完成它的 Employee 是否具有正确的 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 您要记录对转换的拒绝吗？那要怎么处理呢？您向具有该转换角色的员工发送通知以对其进行审查？

Ex.2 你想保留提案的完整历史吗？前任。它Transition X 两次被拒绝，但第三次被批准。

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

推荐阅读