数据库模型设计连载(1～6) 最近一直有个愿望：希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文 字，算是对此前工作的一个总结，今天终于开始了万里长征的第一步。 在正式开始之前，我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源 手册卷二》，国内有机械工业出版社出版的中文译本，很多同行可能都已看过，我本人也 看过。 看过之后深受启发，同时也感到两点美中不足： 1、这两部书的成书时间较早，且原作内容是基于美国企业的业务需求而建，有些最新 的行业信息及"中国特色"的东西没有收录。 2、书中原作者所使用的设计符号是作者专用的，而对于目前国内数据库模型设 计的专业人员来说，ER图或者PowerDesigner中的CDM、PDM图更容易理解和沟通。 所以，在今后一段时间，我希望每天能抽出2个小时，结合上面提到的两部书的 内容、PowerDesigner的PDM模型以及本人相关工作经验，在这里做一个数据库模型设计 的连载。本连载计划用120天的时间撰写完毕。 这么做的目的，一方面是将头脑里的无形信息落实到文字上、有效避免遗忘， 另一方面更加希望抛砖引玉，在与同行们沟通交流之后对我自己也是个促进和提高，对 其他同行也起到各借鉴的作用。望广大同行们不吝赐教，大家一起来推动数据库模型设 计的资源共享计划。 什么是模式？ 连载之1 原创：胖子刘（转载请注明出处及作者，谢谢。） 什么是模式？简单说来，模式类似于定式，就是遇到反复出现的同一问题时所固定使 用的解决方案。下围棋的朋友可能对"定式"这个词比较熟悉，定式包含着下棋时做遇到 的各种情况下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、边定式 等等，定式懂的越多，围棋下的越好。 那么是不是数据库设计模式懂得越多，设计工作越完美呢？理论上是这样，但是在我 这里，各位朋友所能看到的数据库设计模式只有四种。 为什么只有四种而不是更多？ 不时有那句话吗："浓缩的都是精华"！ 在后面的文章中，您会陆续看到浩浩荡荡的设计实例连篇累牍，却都是利用这四种基 本模式设计出来的。《易传·系辞》曰："易有太极，是生两仪，两仪生四象，四象生八卦 。"老子在《道德经》中也说："道生一，一生二，二生三，三生万物。" 设计模式不必多，只要掌握其中关键的几个，再结合实际的业务需求，一个完整的数 据库模型就可以推导出来。 下面让我们来逐一介绍这四种主要设计模式—— （一）主扩展模式 连载之2 原创：胖子刘（转载请注明出处及作者，谢谢。） （一）主扩展模式 主扩展模式，通常用来将几个相似的对象的共有属性抽取出来，形成一个"公共属性 表"；其余属性则分别形成"专有属性表"，且"公共属性表"与"专有属性表"都是"一对一 "的关系。 "专有属性表"可以看作是对"公共属性表"的扩展，两者合在一起就是对一个特定对象 的完整描述，故此得名"主扩展模式"。 举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解"主扩 展模式"这个概念来使用的，请大家注意）。 假设某公司包括如下6种类型的工作人员：采购员、营销员、库房管理员、收银员、 财务人员和咨询专家，采用主扩展模式进行设计，如下图所示。 无论哪种类型的工作人员，都要访问公司的办公软件，所以都有"登陆代码"和"登录 密码"；并且作为一般属性，"姓名"、"性别"、"身份证号"、"入职时间"、"离职时间"等 属性，都与个人所从事的工作岗位无关，所以可以抽取出来作为公共属性，创建"公司员 工"表。 很显然，公司委派员工采购哪些商品是"采购员"的专有属性，这是由公司的实际业务 特点决定的。换句话说，公司不可能把采购任务放到"营销员"身上，也不可能放到"库房 管理员"身上，"采购商品"属性就是"采购员"的专用属性。 "采购员"表的主键与"公司员工"表的主键是相同的，包括字段名称和字段的实际取值 ；"采购员"表的主键同时是"公司员工"表主键的外键。在PDM图里可以看到"采购员"表中 的"员工ID"字段后面有一个"<pk,fk>"标记，这个标记就说明"员工ID"字段既是"采购员 "表的主键，同时也是该表的外键。 "公司员工"表是主表，"采购员"表是扩展表，二者是"一对一"的关系，两个表的字段 合起来就是对"采购员"这个对象的完整说明。同理，"公司员工"表和其他5个表之间也都 分别构成了"一对一"的关系。 对于主表来说，从表既可以没有记录，也可以有唯一一条记录来对主表进行扩展说明 ，这就是"主扩展模式"。 （二）主从模式 连载之3 原创：胖子刘（转载请注明出处及作者，谢谢。） （二）主从模式 主从模式，是数据库设计模式中最常见、也是大家日常设计工作中用的最多的一种模 式，它描述了两个表之间的主从关系，是典型的"一对多"关系。 举例如下（注：这个例子已经作了相当