公文转发流程自定义的数据建模

开拓比拟搀杂的企业多用户处置消息体例(mis)，不大概不波及到体例内多个用户之间的数据文献的流转、审查批准等功效的开拓。因为企业的需要老是跟着功夫推移连接爆发变革，加之各个企业里面所树立的办公室过程不尽沟通，一套通用性比拟好的处置消息体例该当能让体例处置员本人设置公函转发的过程。  　　纵然笔者没有时机在已介入开拓了的mis中实行出文献转发过程自设置的功效，然而，早在2002年头就曾深刻推敲过这上面的安排。其时因为某些因为不许公然本人的安排思绪，此刻市情上仍旧有不少mis产物供给如许的功效，笔者又已离任，以是是功夫把我的安排思绪整治出来，和大师瓜分。 　　开始，让咱们领会需要，拟订目的。 　　1)普遍情景下，企行业内部的公函转发、审查批准是按部分或地位来转赠，即对岗不对人。比方：某个过程的某个步骤须要财政总监审查批准，遥远财政总监换人，该过程该当不受感化。并且，过程中某个步骤大概展示某个部分中的任何一人都能审查批准，大概须要该部分的一切职员共通审查批准。 　　2)过程中转赠，审查批准的公函普遍分为文献和表单2种方法。文献方法的公函该当扶助批处置，即一次不妨转发多个文献，审查批准时不妨只归还个中某一个不对格的文献，其余的文献不妨转赠到下一个步骤连接处置。表单方法的公函该当能让用户本人设置表单方法，决定表单中的表项。同理，表单也该当扶助批处置。 　　3)过程中处置公函的举措该当能让用户本人设置。如许一旦遥远减少了新的处置举措，也不必窜改mis体例的底层数据建立模型。固然，要实行新的处置举措，仍旧须要在交易论理层编写相映的代码，然而和窜改底层数据建立模型比起来，处事量要少得多。 　　4)每个过程的步骤数不确定沟通，该当能让用户设定步骤数，指定公函流转中每个步骤的发送部分和接收部分，处置形式，最长等候功夫。 　　5)当待处置的公函发出后，体例该当在等候功夫中按期向该过程中下个步骤的用户(们)发出报告，指示该用户(们)准时处置，直至公函已被处置。即使胜过最长等候功夫，公函还未被用户(们)处置，此次过程处置波折。企业处置层大概会诉求记载关系消息，再不在遥远交易过程重组(bpr)时参考。 　　6)某些企业因为特出因为，在某个过程中要务实现跨步骤处置。比方，该过程有6步，实行到第二个步骤时诉求处置后不妨跳过中央三个步骤，径直转到结果一个步骤等待处置。本来，这种情景下，并不确定要在本领层面上实行其精巧性，这种惯例究竟是少量。用户只需设置一个新过程，把上头过程的第1，2，6步复制介入进入，2个过程之间用过程名来辨别即可。一个特出的体例框架结构安排师该当充溢运用现有的东西，不要什么都自行架设开拓。 　　上头的需要对精巧性诉求较高，笼统化水平较深，以是在展现层和交易论理层的开拓量较大，前期入股较多，然而开拓结束后估量不需对底层数据库窜改，即可满意遥远连接变革的公函流转需要。即使不须要这么高的精巧性，不妨按本质名目简化某些假如前提。底下依照上头的需要举行用例(use case)领会和数据建立模型。 　　1)因为过程步骤的发送方和接收方是对岗不对人，咱们该当先刻画出所有企业的组织树立，决定每个部分的权力工作。个中大的部分内大概有几何子部分，每个子部分内又有各别地位，控制处置相映的工作。以是，可先创造一个树形联系的数据表来生存企业构造，而后，沿用权力表和用户组相贯串的办法来生存每个部分每个地位的本能。这块的安排思绪见我之前颁布的“浅谈数据库安排本领(上)、(下)”，我在底下径直给出大概的数据表构造： 部分表(department_table) 称呼　　　　典型　　　　牵制前提　　　                    证明 dp_id   　  int     　  无反复　　                   类型标识，主键 dp_name　　 varchar(50) 不承诺为空                   典型称呼，不承诺反复 dp_father   int         不承诺为空                   该类型的父类型标识，即使是顶节点的话设定于某个独一值 dp_layer    varchar(6)  控制3层,初始值为000000       类型的先序遍历，重要为缩小检索数据库的度数 功效表(function_table) 称呼　　　　典型　　　　牵制前提　　　证明 f_id        int    　   无反复　　   功效标识，主键 f_name      varchar(20) 不承诺为空   功效称呼，不承诺反复 f_desc      varchar(50) 承诺为空     功效刻画 用户组表(user_group) 称呼　　　　典型　　　　 牵制前提　　　证明 group_id    int          无反复        用户组标识，主键 group_name  varchar(20)  不承诺为空    用户组称呼 group_power varchar(100) 不承诺为空    用户组权力表，实质为功效表f_id的汇合 用户表(user_table) 称呼　　　　典型　　　　牵制前提　　　证明 user_id     int         无反复        用户标识，主键 user_name   varchar(20) 无反复        用户名 user_pwd    varchar(20) 不承诺为空    用户暗号 user_type   int         不承诺为空    分属用户组标识，和user_group.group_id关系 　　证明：个中，按部分的各别地位树立各别权力的用户组，如某个用户组为“商场部交易员”，该用户组的用户可在过程“报销请求”中发送报销请求。 　　2)纵然过程中的公函分为文献和表单2种方法，然而每个文献/表单都该当有其独一标识，称呼等属性。以是，咱们把公函笼统化，把这2种方法的公函的公有属性索取出来创造一张公函表。 公函表(document_table) 称呼　　　　典型　　　　牵制前提　　　证明 doc_id      int         无反复        公函标识，主键 doc_name    varchar(50) 不承诺为空    公函称呼 doc_type    char(1)     不承诺为空    公函典型 　　doc_type字段用来辩别公函方法，暂时惟有2种方法，可设“1”表白文献方法，“2”表白表单方法。估量将来新增公函方法不会太多，以是该字段只需一位字符。文献方法的公函普遍是在文献内恒定好方法，咱们可用一个二进制的字段径直生存所有文献的实质。文献方法的公函须要建一个表来生存关系消息，其大概数据表如次： 文献表(file_table) 称呼　　　 典型　　　　牵制前提　　　证明 file_id    int         无反复       文献标识，主键 file_name  varchar(50) 不承诺为空   文献称呼 file_value binary      不承诺为空   文献实质 …… 　　表单方法的公函要让用户本人设置表单方法，决定表单中的表项。有两种本领来实行： 　　①每当用户创造一个新方法的表单时，就新创造一个表，把用户输出的表单表项看成该表的字段。这种办法的便宜是表单查问速率较快简单，交易论理层的开拓量较小。缺陷是不太精巧，即使企业所运用的各别方法的表单较多(>20种)，所有数据库的构造显得比拟凌乱，并且大局部表单中都有沟通的字段，如许也减少了数据冗余。这种办法的数据建立模型如次： 表单总表(sheet_table) 称呼　　　　典型　　　　牵制前提　　　证明 sheet_id    int         无反复        表单标识，主键 sheet_name  varchar(50) 不承诺为空    表单称呼 table_name  varchar(20) 不承诺为空    表单子表名，如sub_table1/sub_table2 表单子表1(sub_table1) 称呼　　　典型　　　牵制前提　　　证明 sub_id    int       无反复        表单子表标识，主键 option1   varchar   不承诺为空    表单表项1 option2   varchar   不承诺为空    表单表项2 option3   varchar   不承诺为空    表单表项3 ……