连载之11
原创：胖子刘（转载请注明作者和出处，谢谢）
1. 人员
在需求调研和分析阶段、通常需要制作用例图，记录当前应用系统Actor及用例。假设系统Actor包括公司员工、签约人、供应商联络员、客户联络员4种类型，那么有些系统可能就会设计成4个表来分别存储。如果某个人所属的公司既是本公司的供应商又是客户，他则既是供应商联络员、又是客户连锁员，那么这个人的信息就要在“供应商联络员”、“客户联络员”表里各存一条记录，这就造成了数据冗余。
为了避免这种情况，我们采用“主扩展模式”进行设计，首先抽取4种Actor的共同属性创建“人员”表，然后创建其余4个表存储主表的扩展属性。
在这一节，我们重点讲述主表、即“人员”表的设计细节，其他表的设计放到后面再说。
人员表的主键为什么是“当事人ID”，而不是“人员ID”呢？这个问题留到第3节讲述，此处只要把它看作是人员表的主键就可以了。
在设计人员表以及其他实体表的时候，需要注意实体属性的类型。一般可以分成三类：（1）自然属性，与该实体紧密相关，除非录入错误，否则不存在修改的情况；（2）社会属性，与实体松散相关，会随着实际情况的变化而变化；（3）系统属性，与实体基本无关，属于系统控制层次的属性。
对照上面的“人员表”我们可以看到，对于确定的一个人，排除录入错误的情况，他的“出生日期”、“身份证号”是不会发生变化的，这就是一个人的自然属性；除此以外的其他属性都是社会属性，都有可能会发生变化。大家都知道目前国内改名的现象比较多，尽管公安机关的限制很严，依然挡不住改名的热潮。至于身高、体重、职务、婚姻状况，就更不用说了，就像美女的脸、说变就变。护照一般都有有效期，过了有效期需要重新领新的护照，号码自然会发生变化。为什么“性别”也会变化呢？其实“性别”的取值范围是有国家标准的，取值分别是“男性”、“女性”、“未知的性别”、“未确定的性别”，感兴趣的朋友可以在网上搜搜。一般在录入人员信息的时候，如果不知道该人是男是女，默认应当选“未知的性别”，等以后知道了具体性别再作修正；此外男变女、女变男也不是什么新鲜事了，所以人的“性别”也是社会属性。
说了这么多，大家可以发现，一般的“社会属性”的名称前都有一个“现”字，用来提示大家这个属性是社会属性，是很可能会发生变化的，目前数据库里存储的只是最后一次修改的结果。有些系统（例如我举的这个例子）不关心这些属性的变化过程，只要有一个最新值就可以了。有些系统则必须跟踪属性变化的全过程，例如“干部考评系统”，可能就要记录某人“职务”变化的全部历史；“海关出入境登记系统”，就要记录一个人“护照”号码所有的变化；“康体中心”可能会记录其会员在一段时间内每天的“体重”变化值，等等。这样，就需要采用“主从模式”或者“名值模式”来进行相应设计，而不是简简单单的建一个表完事了。
但是无论是什么系统，在记载人员的“自然属性”的时候，由于其不会产生变化历史，所以只要作为“人员”表的字段就可以了。
“系统属性”，属于系统控制手段的范畴。例如有些系统对人员管理较严格、不允许随便增删人员记录，就在人员表中设置一个属性——“状态”，取值范围是“新增/有效/无效”。办事员录入一个人员信息后，“状态”属性被设置为“新增”，由管理人员审核通过后属性改为“有效”，只有状态为“有效”的人员才能进行相应的业务处理；当需要删除人员信息时，将“状态”属性改为“无效”。这就是实体的系统属性。
对于一个属性而言，它到底是“自然属性”、还是“社会属性”，需要我们在作需求分析阶段认真分析业务、与一线业务人员充分沟通之后予以确定。而“系统属性”一般是在系统设计阶段、结合业务逻辑确定。
文章来源:http://blog.csdn.net/liu7537/archive/2006/05/09/713979.aspx
