数据模型的设计 通用数据库模型分析.docVIP

数据模型设计 通用数据库模型分析 在我们数据库模型设计领域，有一个很有趣的比例--5：3：2，我称之为五三二法则。具体是什么含义呢? 这个5，表示大约50%的功能设计是跨行业通用的，不管你是做商业流通项目、还是电子政务项目、或者是网上拍卖系统，虽然各个项目所属行业不同，但是它们中的50%的设计思想都是相同的，这就是本章(第五章)所要讲述的通用模型设计。换句话说，本章所讲述的模型设计思想，你可以在任何项目中使用；3表示在某行业内部的各个不同的公司之间又有30%的设计思想是相同的，这就是下一章(第六章)所要说明的行业模型设计；2表示余下的20%才是某一特定公司所独有的业务需求，这部分内容我这个连载就不介绍了。 (一)人与组织 大部分的企业系统都会记录有关人与组织的信息，比如公司员工、供货商、销售客户、网上客户、会员卡客户、子公司、公司内部组织机构等信息。而大部分系统对这些信息进行数据库设计时，都是创建各自独立的表，没有抽取共有信息，因而造成了数据的冗余。 比如A公司为了开辟销售市场，通常会给与会员卡客户一定的优惠条件，那么显然不能排除持卡人为公司员工这种情形、也不能排除持卡人为公司的供货商这种情形。 假设B公司既是A公司的供货商、同时也是A公司的会员卡客户，如果按照各自独立的方式设计数据库表，则B公司的信息，如公司名称、联系人、联系电话、联系地址等信息必然要在A公司的会员卡客户表及供货商表作重复记录。如果B公司的某些信息，如联系电话和地址发生了变更，则A公司必须将会员卡客户表和供货商表中的记录同时修改，否则业务人员就会发现同一家公司(B公司)的信息，在系统内两个地方登记的不一样，那么，哪个是正确的?业务人员就会对软件数据的准确性产生怀疑，进而对整个系统持怀疑态度。 同样道理，在一些大型企业，内部各部门、各子公司之间有时也会按照销售的方式进行业务往来。生产车间是产品营销部的供货商，生产车间同时也是原料采购部的销售客户。有些大型企业集团还会建立集团内部银行，内部各部门、各子公司之间通过内部转帐支票的方式完成内部往来结算，各部门、各子公司之间采取相对独立的成本核算的经营方式。这样的话，如果每个部门、子公司都自己创建一套独立的组织表，那么同一个组织的信息就会存储在多个表里，这样就产生了数据重复。 如果同一数据重复存储在多个表里，一旦某个部门由于业务的发展而发生变更的时候，就会给系统使用者带来很大的麻烦--不但增加了数据修改的工作量，还必须要对所做的多处修改进行认真核对，以保证同一部门的信息在软件的各个地方都是一致的。 综上所述，为了解决数据在系统内部不必要的重复存储问题，关于这方面的数据库设计模式就用到了我们前面提到的主扩展模式。 1,人员 在需求调研和分析阶段、通常需要制作用例图，记录当前应用系统Actor及用例。假设系统Actor包括公司员工、签约人、供应商联络员、客户联络员4种类型，那么有些系统可能就会设计成4个表来分别存储。如果某个人所属的公司既是本公司的供应商又是客户，他则既是供应商联络员、又是客户连锁员，那么这个人的信息就要在供应商联络员、客户联络员表里各存一条记录，这就造成了数据冗余。 为了避免这种情况，我们采用主扩展模式进行设计，首先抽取4种Actor的共同属性创建人员表，然后创建其余4个表存储主表的扩展属性。 在这一节，我们重点讲述主表、即人员表的设计细节，其他表的设计放到后面再说。 人员表的主键为什么是当事人ID，而不是人员ID呢?这个问题留到第3节讲述，此处只要把它看作是人员表的主键就可以了。 在设计人员表以及其他实体表的时候，需要注意实体属性的类型。一般可以分成三类： (1)自然属性，与该实体紧密相关，除非录入错误，否则不存在修改的情况； (2)社会属性，与实体松散相关，会随着实际情况的变化而变化； (3)系统属性，与实体基本无关，属于系统控制层次的属性。 对照上面的人员表我们可以看到，对于确定的一个人，排除录入错误的情况，他的出生日期、身份证号是不会发生变化的，这就是一个人的自然属性；除此以外的其他属性都是社会属性，都有可能会发生变化。大家都知道目前国内改名的现象比较多，尽管公安机关的限制很严，依然挡不住改名的热潮。至于身高、体重、职务、婚姻状况，就更不用说了，就像美女的脸、说变就变。护照一般都有有效期，过了有效期需要重新领新的护照，号码自然会发生变化。为什么性别也会变化呢?其实性别的取值范围是有国家标准的，取值分别是男性、女性、未知的性别、未确定的性别，感兴趣的朋友可以在网上搜搜。一般在录入人员信息的时候，如果不知道该人是男是女，默认应当选未知的性别，等以后知道了具体性别再作修正；此外男变女、女变男也不是什么新鲜事了，所以人的性别也是社会属性。 说了这么多，大家可以发现，一般的社会属性的名称前都有一个现字，用来