数据库设计规范化的五个要求

通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达成数据库设计规范化的规定，一般来说，需要符合以下五个规定。规定一：表中应当避免可为空的列虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在解决的时候，需要进行特殊的解决。如此的话，就会增长数据库解决记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库解决的性能会减少许多。所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应当尽量避免。若的确需要的话，我们可以通过一些折中的方式，来解决这些空字段，让其对数据库性能的影响减少到最少。一是通过设立默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段也许允许为空。由于不是每个人都可以记住自己的身份证号码。而在员工报到的时候，也许身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些解决。如当用户没有输入内容的时候，则把这个字段的默认值设立为0或者为N/A。以避免空字段的产生。二是若一张表中，允许为空的列比较多，接近表所有列数的三分之一。并且，这些列在大部分情况下，都是可有可无的。若数据库管理员碰到这种情况，笔者建议此外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简朴，同时也可以满足存储空值信息的需要。规定二：表不应当有反复的值或者列如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完毕，而有时候又需要多个人合作才可以完毕。所以，在产品基本信息表产品开发者这个字段中，有时候也许需要填入多个开发者的名字。如进销存管理中，还需要对客户的联系人进行管理。有时候，公司也许只知道客户一个采购员的姓名。但是在必要的情况下，公司需要对客户的采购代表、仓库人员、财务人员共同进行管理。由于在订单上，也许需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致反复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设立第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若尚有第三联系人、第四联系人等等，则往往还需要加入更多的字段。可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不仅会导致空字段的增长，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以直接修改采购员的名字呀。可是这么解决的话，会把原先采购订单上采购员的名字也改变了。由于采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员相应的一个编号。在编号不改而名字改变了的情况下，采购订单上显示的就是更改后的名字。这不利于时候的追踪。所以，在数据库设计的时候要尽量避免这种反复的值或者列的产生。笔者建议，若数据库管理员碰到这种情况，可以改变一下策略。如把客户联系人此外设立一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将反复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。规定三：表中记录应当有一个唯一的标记符在数据库表设计的时候，数据库管理员应当养成一个好习惯，用一个ID号来唯一的标记行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应当有一个ID列，任何两个记录都不可以共享同一个ID值。此外，这个ID值最佳有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。此外，在数据库设计的时候，最佳还可以加入行号。如在销售订单管理中，ID号是用户不可以维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不可以更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，本来来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。规定四：数据库对象要有统一的前缀名一个比较复杂的应用系统，其相应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。并且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。为此，笔者建立，在开发数据库之前，最佳可以花一定的时间，去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用程序协商，拟定合理的命名规范。笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的，则可以运用C作为前缀。具体采用什么前缀可以以用户的爱好而定义。但是，需要注意的是，这个命名规范应当在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。另一方面，表、视图、函数等最佳也有统一的前缀。如视图可以用V为前缀，而函数则可以运用F为前缀。如此数据库管理员无论是在平常管理还是对象引用的时候，都可以在最短的时间内找到自己所需要的对象。规定五：尽量只存储单一实体类型的数据这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的自身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。如当后续有图书出版时，则需要为每次出版的图书增长作者信息，这无疑会增长额外的存储空间，也会增长记录的长度。并且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中所有删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。碰到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者相应表等等。如此设计以后，以上碰到的所有问题就都引刃而解了。以上五条是在数据库设计时达成规范化水平的基本规定。除了这些此外尚有很多细节方面的规定，如数据类型、存储过程等等。并且，数据库规范往往没有技术方面的严格限制，重要依靠数据库管理员平常工作经验的累积。++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++数据表的设计原则:(1)不应针对整个系统进行数据库设计，而应当根据系统架构中的组件划分，针对每个组件所解决的业务进行组件单元的数据库设计;不同组件间所相应的数据库表之间的关联应尽也许减少，假如不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，保证组件相应的表之间的独立性，为系统或表结构的重构提供也许性。(2)采用领域模型驱动的方式和自顶向下的思绪进行数据库设计，一方面分析系统业务，根据职责定义对象。对象要符合封装的特性，保证与职责相关的数据项被定义在一个对象之内，这些数据项可以完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，假如一个对象要负责两个或两个以上的职责，应进行分拆。(3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不管那种方式，都应保证关键字可以保证唯一性。在拟定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。(4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思绪的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。(5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1-N或N-N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。(6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，保证不存在多值依赖。这时，应根据反向工程的思绪反馈给领域模型。假如表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表假如满足BCNF，不应存在多值依赖。(7)在通过度析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定期间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务(数据间的一致性)，这一职责应由系统的逻辑层来保证，这种方式也保证了系统对于不对的数据(脏数据)的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力保证系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定限度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。(8)应针对所有表的主键和外键建立索引，有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据特别时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。(9)尽量少采用存储过程，目前已有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提高而性能又是非常重要的质量属性时，可通过平衡考虑选用存储过程。(10)当解决表间的关联约束所付出的代价(经常是使用性上的代价)超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是重要的问题时，表设计可以不符合四个范式。四个范式保证了不会出现异常，但也也许由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但一方面保证符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最佳办法。(11)设计出的表要具有较好的使用性，重要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。(12)设计出的表要尽也许减少数据冗余，保证数据的准确性，有效的控制冗余有助于提高数据库的性能。++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++1.原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据相应且只相应一个实体。

在特殊情况下，它们也许是一对多或多对一的关系，即一张原始单证相应多个实体，或多张原始单证相应一个实体。

这里的实体可以理解为基本表。明确这种相应关系后，对我们设计录入界面大有好处。

〖例1〗：一份员工履历资料，在人力资源信息系统中，就相应三个基本表：员工基本情况表、社会关系表、工作简历表。

这就是“一张原始单证相应多个实体”的典型例子。

2.主键与外键

一般而言，一个实体不能既无主键又无外键。在E—R图中,处在叶子部位的实体,可以定义主键，也可以不定义主键

(由于它无子孙),但必须要有外键(由于它有父亲)。

主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完毕以后，有个美国数据库设计专

家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核

心(数据模型)的高度抽象思想。由于：主键是实体的高度抽象，主键与外键的配对，表达实体之间的连接。

3.基本表的性质

基本表与中间表、临时表不同，由于它具有如下四个特性：

(1)原子性。基本表中的字段是不可再分解的。

(2)原始性。基本表中的记录是原始数据（基础数据）的记录。

(3)演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。

(4)稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

4.范式标准

基本表及其字段之间的关系,应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最佳的设计。

为了提高数据库的运营效率，经常需要减少范式标准：适当增长冗余，达成以空间换时间的目的。

〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表白该表的设计不满足第三范式，

由于“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增长“金额”这个冗余字段，

可以提高查询记录的速度，这就是以空间换时间的作法。

在Rose2023中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和

“数量”这样的列被称为“数据列”。

表1商品表的表结构

商品名称商品型号单价数量金额

电视机29吋2,50040100,000

5.通俗地理解三个范式

通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解

三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：

第一范式：1NF是对属性的原子性约束，规定属性具有原子性，不可再分解；

第二范式：2NF是对记录的惟一性约束，规定记录有惟一标记，即实体的惟一性；

第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它规定字段没有冗余。

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最佳的数据库，有时为了提高运营效率，就必须降

低范式标准，适当保存冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，减少范式标准的工作放到物理

数据模型设计时考虑。减少范式就是增长字段，允许冗余。

6.要善于辨认与对的解决多对多的关系

若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增长第三个实体。这样，本来一

个多对多的关系，现在变为两个一对多的关系。要将本来两个实体的属性合理地分派到三个实体中去。这里的第三个

实体，实质上是一个较复杂的关系，它相应一张基本表。一般来讲，数据库设计工具不能辨认多对多的关系，但能处

理多对多的关系。

〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一

个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在两者之

间增长第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表达借书，1表达还书)，此外，

它还应当有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。

7.主键PK的取值方法

PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串,由程序自动加1来实现。也可以是有物理意义

的字段名或字段名的组合。但是前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不仅索引

占用空间大，并且速度也慢。

8.对的结识数据冗余

主键与外键在多表中的反复出现,不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重

复出现,才是数据冗余！并且是一种低档冗余，即反复性的冗余。高级冗余不是字段的反复出现，而是字段的派生出现。

〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，

并且是一种高级冗余。冗余的目的是为了提高解决速度。只有低档冗余才会增长数据的不一致性，由于同一数据，可

能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低档冗余(反复性冗余)。

9.E--R图没有标准答案

信息系统的E--R图没有标准答案，由于它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，

就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：

结构清楚、关联简洁、实体个数适中、属性分派合理、没有低档冗余。

10.视图技术在数据库设计中很有用

与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的

一个窗口，是基表数据综合的一种形式,是数据解决的一种方法，是用户数据保密的一种手段。为了进行复杂解决、

提高运算速度和节省存储空间,视图的定义深度一般不得超过三层。若三层视图仍不够用,则应在视图上定义临时表,

在临时表上再定义视图。这样反复交迭定义,视图的深度就不受限制了。

对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完

成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。

并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，

才干直接在基本表上操作。请读者想想：这是为什么？

11.中间表、报表和临时表

中间表是存放记录数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓

库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员

自己用程序自动维护。

12.完整性约束表现在三个方面

域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通

过它定义字段的值城。

参照完整性：用PK、FK、表级触发器来实现。

用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。

13.防止数据库设计打补丁的方法是“三少原则”

(1)一个数据库中表的个数越少越好。只有表的个数少了，才干说明系统的E--R图少而精，去掉了反复的多余的

实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；

(2)一个表中组合主键的字段个数越少越好。由于主键的作用，一是建主键索引，二是做为子表的外键，所以组

合主键的字段个数少了，不仅节省了运营时间，并且节省了索引存储空间；

(3)一个表中的字段个数越少越好。只有字段的个数少了，才干说明在系统中不存在数据反复，且很少有数据冗

余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许

多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，此外单独建一个子表。这个方法很简

单，有的人就是不习惯、不采纳、不执行。

数据库设计的实用原则是：在数据冗余和解决速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，

不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功

能，一百个实体(共一千个属性)的E--R图，肯定比二百个实体(共二千个属性)的E--R图，要好得多。

提倡“三少”原则，是叫读者学会运用数据库设计技术进行系统的数据集成。数据集成的环节是将文献系统集成

为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的限度越高，数据

共享性就越强，信息孤岛现象就越少，整个公司信息系统的全局E—R图中实体的个数、主键的个数、属性的个数

就会越少。

提倡“三少”原则的目的，是防止读者运用打补丁技术，不断地对数据库进行增删改，使公司数据库变成了随意

设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后导致数据库中的基本表、代码表、中间表、临时表

杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。

“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的

原则，它规定有较高的数据库设计技巧与艺术，不是任何人都能做到的，由于该原则是杜绝用“打补丁方法”

设计数据库的理论依据。

14.提高数据库运营效率的办法

在给定的系统硬件和系统软件条件下，提高数据库系统的运营效率的办法是：

(1)在数据库物理设计时，减少范式，增长冗余,少用触发器,多用存储过程。

(2)当计算非常复杂、并且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文献系统方

式用C++语言计算解决完毕之后，最后才入库追加到表中去。这是电信计费系统设计的经验。

(3)发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键

PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则

垂直分割该表，将本来的一个表分解为两个表。

(4)对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。

(5)在使用面向数据的SQL语言进行程序设计时，尽量采用优化算法。

总之，要提高数据库的运营效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。

上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者

不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++在过去的很数年，我认为关系模型就是传统的公司应用当中DBA设计的那些无数冗余字段，多个模型合并到一个表里面的数据库设计方式，这种数据库设计非常适合复杂的OLAP类型的查询，他可以有效的消除多表联合查询，而我们大家都知道，大表的复杂关联查询是性能杀手，一旦无法有效运用索引，导致了全表扫描，等待你的只有数据库服务器硬盘灯的狂闪不止，和无数进程阻塞在IOWAIT状态的无奈。

我前几个月订购了一本人邮图灵出版的《MySQL5权威指南》第三版中文版，买这本书只是由于有人送我China-Pub的优惠券，我就顺手买本MySQL的书，用来管理JavaEye服务器的时候备查的。其实这本书内容很一般，他说的东西我都知道了，所以这本书我拿过来随手翻了翻就感觉到买的不值得。但是当我随手翻到第8章第5节第138页介绍什么是三大范式的时候，我终于知道我错了。

从138页到142页，作者进一步浅出举例说明了三大范式，我被震了，就这几页让我觉得买这本书值了。对于我这个不是计算机科班出身的人来说，到现在才知道什么是三大范式不算可耻。我震惊的只是三大范式和我们现在遵循ORM的原则去设计数据库的方式如出一辙！我简朴摘要书中内容如下：引用第一范式：

1、内容相似的数据列必须消除(消除的办法就是再创建一个数据表来存放他们，建立关联关系)

2、必须为每一组相关数据分别创建一个表

3、每条数据记录必须用一个主键来标示

第二范式：

1、只要数据列里面的内容出现反复，就意味着应当把表拆分为多个表

2、拆分形成的表必须用外键关联起来。

第三范式：

1、与主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们)

这三大范式就像给ORM的人如何设计数据库写的指南：引用第一范式：

1、每个持久对象映射一张表

2、每个持久对象必须有一个主键

第二范式：

1、持久对象要有内聚性，冗余的内容拿出去，单独创建持久对象

2、持久对象之间的关系用外键关联

第三范式：

1、持久对象要有内聚性，无关的内容拿出去，单独创建持久对象

关系模型和对象模型是不是在存储概念上一致，就不用多说废话了。

说关系模型和对象模型“阻抗不匹配”，当然是有不匹配的地方，比方说对象模型当中特有的“继承”，“组合”，“聚合”，“依赖”的概念在关系模型当中是不存在的，但是这种模型的“阻抗不匹配”最终在存储模型是还是可以统一起来的，这就是ORM的作用：

1、对象的继承关系可以表达为三种不同的关系存储模型：整个继承数一张表；每个继承层次一张表；每个对象一张表

2、对象的组合和聚合可以用主外键关联的表来存储，它可以表达1:n，n:1和n:m的关系

3、对象的依赖关系和存储无关，所以不需要ORM做什么。

所以结论就是这样：

关系模型和对象模型存在概念上的阻抗不匹配，但是在关系数据库的存储模型上是一致的，无论你从关系模型的三大范式理论出发，还是从对象模型的ORM理论出发，最终一定会得到一致的数据库表设计。

这里值得我们反思的一个问题是：为什么传统的数据库应用人们这样漠视和违反三大范式？在很多所谓的金融、电信等超级大项目当中，连主键都没有的表比比皆是，一张表上百个字段，字段之间没有什么逻辑关系的情况比比皆是？

我想答案在于：传统的数据库应用软件开发，程序员很难从符合三大范式的数据模型当中获得有效的查询性能。符合三大范式就意味着数据库表会拆分的很细，表间关联很多，记录分析查询就不可避免的导致n张表的联合查询，在没有有效的应用层缓存的情况下，这种查询无可避免的性能低下。这使得程序员宁肯违反三大范式，而选择查询性能优先的数据库设计。

但是我们现在不同样了，有了良好的ORM框架和应用层的对象缓存机制，我们可以做到：让比较简朴的查询主线不打扰数据库，让比较复杂的查询尽量少的扫描表记录，其最终达成的效果在OLTP类型的应用上面效果远远超过传统的方式。

以JavaEye网站为例：JavaEye使用了Rails的ActiveRecordORM，表设计符合三大范式，所有页面都是动态页面，要对数据库发送大量查询，很多Web页面至少要向数据库发送50条以上的SQL语句。根据对数据库和MemcachedServer的记录数据表白：JavaEye网站平均每秒向数据库发送140条SQL语句，平均每秒向MemcachedServer发送250次缓存查询，缓存命中率大约为85%，也就是说缓存服务器要比数据库服务器繁忙将近一倍，而Ruby应用程序的数据有60%是来自MemcachedServer，而只有40%是直接来自MySQL的。

为了加深大家印象，再给大家一个数据，目前JavaEye的Web服务器CPU负载在40-60%左右，而JavaEye的数据库服务器CPU负载只有20%-30%，IOWAIT几乎没有。所以良好的遵循三大范式，运用好ORM和对象缓存，可以取得非常棒的应用性能，还可以让你的数据库更加轻松。

最后，我的结论就是对象模型和关系模型在数据库存储上不存在阻抗不匹配，面向对象的程序设计和面向数据库的程序设计应当是一致的，而不应当是对立和冲突的，请不要把面向对象和面向数据库对立起来，不是他们对立，而是你不了解什么才是真正良好的设计。+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++前提声明，个人观点：

没有最佳的，只有最合适的。

对不同的视角，所谓的“最合适”也是不同的。

设计总是随着者“妥协”的。

请不要在讨论中试图证明个人的观点是“最佳的”。

大