数据库模型设计专栏

连载之2原创：胖子刘（转载请注明出处及作者，谢谢。）（一）主扩展模式主扩展模式，通常用来将几个相似的对象的共有属性抽取出来，形成一个“公共属性表”；其余属性则分别形成“专有属性表”，且“公共属性表”与“专有属性表”都是“一对一”的关系。“专有属性表”可以看作是对“公共属性表”的扩展，两者合在一起就是对一个特定对象的完整描述，故此得名“主扩展模式”。举例如下（注：这个例子已经

 连载之15原创：胖子刘（转载请注明作者和出处，谢谢）5.       当事人角色在这一节里，我们重点说一下，“角色类型”、“当事人角色类型”、“当事人”以及“当事人角色”这几个概念之间的关系。其实这部分内容在国内的企业管理系统设计中多数属于权限控制部分。通常的权限控制的设计思路都是这样的：首先在系统开发时登记注册所有功能模块及代码，系统运行时由系统管理员来维护角色列表

 连载之14原创：胖子刘（转载请注明作者和出处，谢谢）4.       当事人类别企业系统在记录当事人信息的时候，总会记录其所属类别。这样可以分门别类的统计各类当事人的业务信息、便于经营数据的分析和对比，为公司经营战略提供决策依据。关于当事人的分类方式很多且不固定。比如按照人员年收入水平可以作如下分类——1万元以下、1万-5万元、5万-10万元、10万-20万元

连载之13原创：胖子刘（转载请注明作者和出处，谢谢）3.       当事人在前两节，组织表和人员表的主键都是“当事人ID”，这是什么意思呢？答案：“当事人ID”是“当事人”表的主键，“当事人”是“组织”和“人员”的超类，是二者的公共属性。因为，组织和人有许多属性都是相同的，如信用等级、地址、邮编、联系电话等；组织和人在某些场合都扮演了相同的角色，如公司产品既可

连载之12原创：胖子刘（转载请注明作者和出处，谢谢）2.       组织事实上，“组织”的含义是很广的，分销渠道、供应商、公司内部的部门、政府机构、行业协会、行业主管部门、合作伙伴、竞争对手、家庭、团队……都是组织的一种；但同时，针对某一特定企业的业务需求而创建的应用系统，其需要打交道的“组织”的类型又是有限的。我们的设计人员所要做的就是在需求调研、分析阶段把所有需要与之

连载之11原创：胖子刘（转载请注明作者和出处，谢谢）1.       人员在需求调研和分析阶段、通常需要制作用例图，记录当前应用系统Actor及用例。假设系统Actor包括公司员工、签约人、供应商联络员、客户联络员4种类型，那么有些系统可能就会设计成4个表来分别存储。如果某个人所属的公司既是本公司的供应商又是客户，他则既是供应商联络员、又是客户连锁员，那么这个人的信息就要在“供应商

连载之10原创：胖子刘（转载请注明作者和出处，谢谢）五、通用数据库模型分析在我们数据库模型设计领域，有一个很有趣的比例——“5:3:2”，我称之为“五三二法则”。具体是什么含义呢？这个“5”，表示大约50%的功能设计是跨行业通用的，不管你是做商业流通项目、还是电子政务项目、或者是网上拍卖系统，虽然各个项目所属行业不同，但是它们中的50%的设计思想都是相同的，这就是本章（

连载之7原创：胖子刘（转载请注明作者和出处，谢谢）数据库物理模型设计的其他模式除了上面提到的四种主要设计模式，还有一些其他模式，在某些项目中可能会用到，在这里先简单做个说明，暂不做深入讨论，等到以后的项目用到这些模式的时候，再结合实际需求详细解说。（一）继承模式继承模式，可以看作是“主从模式”的一种特殊情况（或者说是“变形”），它所代表的两个对象也是“一对多”的关系。它与“主从

连载之5原创：胖子刘（转载请注明出处及作者，谢谢。）（四）多对多模式多对多模式，也是比较常见的一种数据库设计模式，它所描述的两个对象不分主次、地位对等、互为一对多的关系。对于A表来说，一条记录对应着B表的多条记录，反过来对于B表来说，一条记录也对应着A表的多条记录，这种情况就是“多对多模式”。“多对多模式”需要在A表和B表之间有一个关联表，这个关联表也是“多对多模式”的核心所在

        最近一直有个愿望：希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文字，算是对此前工作的一个总结，今天终于开始了万里长征的第一步。        在正式开始之前，我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源手册卷二》，国内有机械工业出版社出版的中文译本，很多同行可能都已看过，我本人也看过。        看过之后深受启发，同时也感到两点美中不足：

连载之8原创：胖子刘（转载请注明作者和出处，谢谢）（二）自联结模式自联结模式，也可以看作是“主从模式”的一种特殊情况（或者说是“变形”），它在一张表内实现了“一对多关系”，并且可以根据业务需要实现“有限层”或者“无限层”的主从嵌套。这种模式用得最多的情况就是实现“树形结构”数据的存储，比如各大网站上常见的细分类别、应用系统的组织结构、Web系统的菜单树等都能用到这种模式。自联结

连载之6原创：胖子刘（转载请注明出处及作者，谢谢。）（五）使用上述四种模式的一般原则1.       什么时候用“主扩展模式”？对象的个数不多；各个对象之间的属性有一定差别；各个对象的属性在数据库设计阶段能够完全确定；各个扩展对象有独立的、相对比较复杂的业务处理需求，此时用“主扩展模式”。将各个对象的共有属性抽取出来设计为“主表”，将各个对象的剩余属性分别设计为相应的“扩展表”，“

连载之1原创：胖子刘（转载请注明出处及作者，谢谢。）什么是模式？简单说来，模式类似于定式，就是遇到反复出现的同一问题时所固定使用的解决方案。下围棋的朋友可能对“定式”这个词比较熟悉，定式包含着下棋时做遇到的各种情况下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、边定式等等，定式懂的越多，围棋下的越好。那么是不是数据库设计模式懂得越多，设计工作越完美呢？理论上是这样，但是在我

连载之4原创：胖子刘（转载请注明出处及作者，谢谢。）（三）名值模式名值模式，通常用来描述在系统设计阶段不能完全确定属性的对象，这些对象的属性在系统运行时会有很大的变更，或者是多个对象之间的属性存在很大的差异。举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“名值模式”这个概念来使用的，请大家注意）。1.       使用名值模式进行设计时，如果对“其他属

连载之3原创：胖子刘（转载请注明出处及作者，谢谢。）（二）主从模式主从模式，是数据库设计模式中最常见、也是大家日常设计工作中用的最多的一种模式，它描述了两个表之间的主从关系，是典型的“一对多”关系。举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“主从模式”这个概念来使用的，请大家注意）。比如论坛程序。一个论坛通常都会有若干“板块”，在每个板块里面，大家

连载之16原创：胖子刘（转载请注明作者和出处，谢谢）6.       当事人权限书接上文，在这里占用一点篇幅，描述一下目前比较常用的“基于角色的权限控制”设计方法。如果有人有更好的设计，欢迎提供。“基于角色的权限控制”，核心思想是将权限控制通过当事人所属角色来实现，当事人本身并不直接绑定权限。有关当事人直接绑定权限的设计，不在本文的描述范围之内。设计思路都是这样