5. 当事人角色

连载之15

原创：胖子刘（转载请注明作者和出处，谢谢）

5.       当事人角色

在这一节里，我们重点说一下，“角色类型”、“当事人角色类型”、“当事人”以及“当事人角色”这几个概念之间的关系。

其实这部分内容在国内的企业管理系统设计中多数属于权限控制部分。通常的权限控制的设计思路都是这样的：首先在系统开发时登记注册所有功能模块及代码，系统运行时由系统管理员来维护角色列表、并为每一种角色设定可访问的模块（角色和模块相关联）。业务人员登录系统后，系统读取当前用户所属的角色，并依据前述设定读取这些角色能够访问的所有模块、形成一个模块代码列表，存储为CS系统的全局变量或者BS系统的Session。每当用户试图进入一个功能模块前，系统都判断一下当前模块代码是否包含在“模块代码列表”中。如果包含，说明该用户有权限，允许进入；不包含，则说明该用户无权操作此功能模块。以此实现权限控制。

关于权限控制，这里先简单提一下，在这一章的最后一节我们来详细描述应用系统的权限控制。

回过头来说当事人角色。在这一节里我们所提到的当事人角色，主要的设计目的是为了满足特定的业务功能需求、描述当事人出于特定身份的情况下能够进行哪种业务。

举例说明：众所周知，“客户”代表一种身份，具备这种身份的人或组织（我们统一称之为“当事人”，这也从另一个方面体现了将“人员”和“组织”概括为“当事人”的好处）能够付钱给企业购买产品或者服务；“VIP客户”则是在“客户”的基础上更一步，能够享受更优惠的折扣或者更特别的服务，同时也意味着它能够给企业带来更大的效益或者更特别的社会关系。“供应商”是另外一种身份，具备这种身份的当事人给企业提供原材料、产品或服务以换取货币。

“客户”和“供应商”代表了两种不同类型的业务工作，需要不同的工作流程，当企业做到一定规模，客户和供应商的数量达到一定的数量级时，企业实际上是针对各种不同的角色来开展日常业务、而不是针对具体的某个人。例如肯德基、麦当劳每天食客上千，它实际上就是“堂食”和“外卖”两种角色的客户提供服务。不可能说张三来了提供一种服务，李四来了就换一种方式服务，过一会儿王五来了再为他奉上一种全新的业务！那样的话啥也别干了，累也累死了。

说到这里，再多说一句题外话。一段时间以来我总在想，我们中国的饮食文化源远流长，中餐馆遍布全球，为什么就没有一家类似肯德基、麦当劳一样驰名世界的饮食品牌呢？为什？？？五千年的时间除了打仗就是吃饭，到了今天更是发展到极致。什么花鸟虫鱼、珍禽异兽，统统都能端到饭桌上；电视里的明星访谈节目，无论嘉宾是歌星、影星、教授、体育……提到“吃”，首先都是会心的一笑，然后就滔滔不绝的给你讲上小半天。看到这帮人提到“吃”时的那副故作聪明的样子，我就想，如果你们能把数理化、天文、地理、生物、IT、经济、法律、制度等行业知识随便挑一样熟悉到这种程度，那我们的综合国力早就超过老美了。老美的专家在研究怎么样去撞击彗星，我们的“专家”在研究怎么吃果子狸，嘿嘿，这不是差距吗？某主持人连普通话都说不好，却愣是靠着主持一档饮食节目，在CCTV混了个风生水起。

天天谈吃、人人谈吃，为什么就没有一个享誉全球的饮食品牌？想了好久，终于让我想到一点端倪。我这个答案一公布出来，估计很有可能会在国内的饮食行业造成一场地震。如果哪位业内人士从我的答案受到启发，进而引发一场饮食行业的大洗牌、并创造出一个崭新的世界级餐饮品牌，到时候别忘了在记者招待会上注明出处——《胖子刘的数据库模型设计专栏》，谢谢！^_^

答案在这里暂时不公布，留待下节再说。嘿嘿，各位看官别忘了要经常来这里呀。

话题重新回到刚才说的，企业上规模之后的业务工作就是针对角色开展，而不再针对具体的客户，我们把这种情况叫做“大企业”；没上规模的企业，业务重点还是放在具体的客户身上，并为单个客户提供差异化服务或产品，这种情况我们称之为“小企业”。

小企业在设计当事人角色时，采用如下数据库模型设计：

大家可以看到，左上角是“角色类型”表，这个表很简单，里面存储若干记录，每条记录描述一个角色类型。角色其实也有很多种类型，包括订单角色类型、协议角色类型、需求角色类型和当事人角色类型等。上图中的“当事人角色类型”表，就是对“角色类型”表的扩展，设计模式就采用了“主扩展模式”。按照这种模式，还应该有3个扩展表，只是这3个扩展表不是本章讲述的内容，留待后文书进行扩充。

“当事人角色类型”和“当事人”之间就是一个简单的“多对多关系”，道理很明显，一个当事人角色类型下面可以有多个当事人，一个当事人也可以从属于多个当事人角色类型。按照4大设计模式中的第4种“多对多模式”进行设计，就得到了“当事人角色”表。

关键就在“当事人角色”表。区分一个数据库模型是为大企业而设计、还是为小企业而设计，最主要的就是这个表。

如果一个企业是大企业，那么企业的日常业务是为角色服务的，换句话说，企业不为单个客户提供差异化服务，那么只需要“当事人角色”表存储某个当事人所属的角色就可以了，不必对该表再继续细化。

如果一个企业是小企业，那么企业必然要对某个当事人提供差异化服务，就需要对“当事人角色”表进行细化。就如上图所示那样。通过采用“主扩展模式”，以“当事人角色”表为主表，设计出5个一级扩展表，分别是“股东”、“潜在客户”、“人员角色”、“组织角色”、“客户”，其中“人员角色”、“组织角色”、“客户”3个角色又可以继续扩展出若干个二级扩展表加以详细描述。“人员角色”的扩展表包括“家庭成员”、“雇员”、“签约人”、“联络员”，“组织角色”的扩展表包括“供应商”、“政府有关部门”、“合作伙伴”、“竞争对手”、“组织单位”、“行业协会”、“内部组织”、“住户”、“分销渠道”，“客户”的扩展表包括“收货人”、“最终使用人”、“付款人”。而某些二级扩展表还可以继续扩展出三级扩展表，详见设计图，文字部分就不再描述了。

这么多的扩展表，关键之处在于这些扩展表都是基于“当事人角色”扩展出来的。在系统运行阶段，需要为每个当事人的每一种角色设置进行详细记录。例如，某企业有1000个当事人，平均每个当事人具有2个角色，那么总的当事人角色就有1000*2=2000个，这2000个当事人角色都需要详细维护。以此提供针对当事人的差异化服务或产品。

大企业由于只是针对角色提供服务，所以在设计当事人角色时，将上图的“股东”、“潜在客户”、“人员角色”、“组织角色”、“客户”五个表的外键关系改到“当事人角色类型”表上、“组织角色”表删除其它所有字段仅保留“PARTY_ROLE_ID”即可，其它不变。同样的例子，如果该企业的当事人角色类型总计有20种的话，企业只需要对这20种角色类型进行维护即可，企业针对同一角色的所有当事人只需实现同质服务即可。此为针对角色的服务。

后期进入到业务功能设计阶段后，针对哪个角色类型开展业务，就只需针对该表设计扩展表或者子表，记录相应的业务信息即可，对于业务的扩展是很容易实现的。