BCNF=3NF＋下面的规则：
　　每一个数据元素都完全依赖于键、整个键，而且除依赖于这个键以外，不依赖于任何其他数据元素。
　　4NF=3NF+下面的规则：
　　要把主键中拥有三个或更多外建数据元素、切割格外键之间不存在约束的那些实体分解成两个或更多个实体。
　　5NF=4NF+下面的规则：
　　把主键中拥有三个或更多的外键数据元素，且这些外键数据元素之间存在着约束的实体分解成为所有的约束都需要的多对多的关系。
　　当我们攀上5NF的顶峰后，再根据实际需求情况来进行“反向规范化”增加数据冗余，从而简化开发，提高查询速度。反向规范化是这样一个过程：在定义了一个可靠的、完全规范化了的数据结构之后，你借助这个过程，有选择地引入一些重复的数据，以促进特殊性能需求的实现。Steve Hoberman的“反向规范化生存指南”给如何适当增加冗余提供了一套可计算的评分标准。通过考察每个关系的6个问题，累加各个问题的得分之后，当得分大于等于10时，我们将对该关系进行反向规范化。
　　“反向规范化生存指南”的计分规则：
　　1.关系是什么类型的：该问题确定我们所分析的关系的类型。父实体对于子实体具有什么样的关系？
　　层次关系(20分)
　　同等关系(-10分)
　　确定关系(-20分)
　　2.参与率是多少：该问题确定一个关系中的每个实体的参与性。换句话说，对于一个给定的父实体数值，大概会有几个子实体数值？父与子的关系越接近“一对一”，我们对它进行反向规范化的机会就越大。
　　多达“一对五”的比率(20分)
　　多达“一对一百”的比率(-10分)
　　超过“一对一百”的比率(-20分)
　　3.父实体中有多少个数据元素
　　少于10个数据元素(20分)
　　数据元素的数量介于10到20之间(-10分)
　　多于20个数据元素(-20分)
　　4.使用率是多少：当用户需要来自子的信息时，通常情况下，它们是否还需要来自父的信息呢？换句话说，这两个实体的耦合或相关程度如何？
　　相互之间的关联很强(30分)
　　相互之间的关联较弱或者没有关联(-30分)
　　5.父实体时一个占位符吗：在不远的将来，我们是否还打算向父实体加入更多的数据元素或关系？如果答案是“不”，那么进行反向规范化的可行性就更强。
　　是(20分)
　　不(-20分)
　　6.变动对比率是多少：该问题是为了确定，在同一时间周期内，两个实体的插入和更新的频度是否相近。如果其中一个实体很少变化，而另一个实体却变动频繁，那么，我们就非常倾向于保持它们的规范化状态，把它们放在各自的表中。
　　相同(20分)
　　不同(-20分)
　　“反向规范化生存指南”的使用方法：
　　1)把模型中的关系按照优先级排序
　　2)选择一个关系
　　3)对这个关系回答提问
　　4)如果得分等于或大于10，就进行反向规范化
　　5)返回步骤二，直到完成所有的关系。
　　第九章：抽象化安全指南和组件
　　看过我的“浅谈数据库设计技巧(上) ”的朋友应该还记得我举的第二个例子：网上电子商务平台上的商品信息表的设计。本章将我在上面例子中所用的方法上升到了理论阶段，采用了面向对象的设计，将所有商品的共有属性提取出来，抽象成一个超类，再加入一个表来记录各个不同实体之间的细节来实现超类的派生，从而实现设计的灵活性。当出现下面两种条件的任何场合，抽象化都是极其有用的：
　　设计需要永久维持下去：要求以后尽可能的不修改数据库设计
　　需求可能发生变化：应用程序的需求发生变化，而要求业务流程重组或进行功能升级
　　数据仓库：当新的分类类型从源应用程序中传过来时，我们无须对数据仓库的设计进行任何改动，而只需在分类类型实体加入一个新行即可
　　元数据仓储库：和数据仓库的要求类似
　　当然，抽象化会大大增加工作量和开发的复杂度，而人们通常关注的是非常短期的应用和眼前的成本，而不关心将来的高得多的成本。所以，我非常赞同敏捷软件开发这个观点：在最初几乎不进行预先设计，但是一旦需求发生变化，此时作为一名追求卓越的程序员，应该从头审查整个架构设计，在此次修改中设计出能够满足日后类似修改的系统架构。
　　“抽象组件”就是小型的抽象模型片段，在许多的建模场合(无论是什么行业、组织，甚至什么主体域的建模场合)中，它们都可被反复使用。在键模阶段多次使用抽象化之后，你将开始看到出现的抽象化结构的趋势。这些“抽象组件”有如下的目的：
　　加快设计速度
　　加快开发速度
　　提供通用且有用的机构
　　第十章：数据模型美化技巧
　　本章通过关注如何改进逻辑和物理数据模型的视觉外观，使我们的设计超越直接的应用程序需求。本章中讨论了五个类别的美化技巧：
　　逻辑数据元素排列技巧：这些技巧是一个推荐的、对你的逻辑数据模型中的每一个实体的数据元素进行排序的方法。
　　物理数据元素排序技巧：这些技巧关注数据模型中每一个实体的最佳布局。
　　实体布局技巧：这些技巧关注数据模型中的每一个实体的最佳布局
　　关系布局技巧：这些技巧关注如何调整重叠的关系线条以及看起来穿越（而不是绕过）无关实体的关系
　　吸引注意力的技巧：这些技巧关注如何在我们的涉及中突出的某些元素、实体或关系。
　　第十一章：规划一个长盛不衰的数据建模生涯
　　对数据建模者的十大忠告清单：
　　1)记住：灵活性、准确性和背景
　　2)建模只是你的工作的一小部分
　　3)尝试其他角色
　　4)了解95/5规则：95%的时间将花费在5%的数据元素上
　　5)数据建模从不令人厌烦：如果你一直在做数据建模工作，而且发现自己经常感到厌烦，那么，你的确该改变一下了。这可能不是数据建模领域本身令人厌烦，而是你所在的特定的任务、公司或行业不再令人兴奋。冒险一下，尝试着道一个不同的项目或行业中进行数据建模工作吧！
　　6)站在技术前沿
　　7)尽量不要在模型上牵扯感情因素：建模者必须理解，人们在评审过程中的意见并不是针对模型的创建者，而是针对这个模型的内容。即那句老话：对事不对人。
　　8)让你的创造力展开翅膀：在考虑记录数据需求和改进设计的新方法时，要紧可能有创造性。有创造性也许就意味着修改本书中的某些工具。这还可能意味着提出你自己的电子表格或其他工具。
　　9)单纯的理论太昂贵了：在设计活动过程中，你要确保把这个观点牢记在心。为这个应用程序掏腰包的部门和组织期望看到的是能看得着的实用结果。
　　10)成为一个了不起的会讲故事的人：作为一名数据建模者，讲故事是工作的一个很重要的部分。为了帮组教化和影响项目经理以及对我们行业缺乏理解的其他人，我们需要讲故事或趣闻。
　　最后，我个人觉得，Steve Hoberman所提出的“抽象组件”的观念和面向对象设计中的的“设计模式”非常类似。即数据库专家在多次的数据建模后，将各个项目中的类似部分抽象化，提取出特定的建模模型片段，以后只需在新的项目中对这些模型片段细化派生，即可快速构建出适合于该项目的数据库架构。不过，这些建模模型片段并没有统一，形成标准，目前也没有出版这类的书籍。本人正在陆续总结自己在这方面的经验，但是自知水平有限，不敢在高人面前班门弄斧，只希望自己日后陆续发布的相关文章能起到抛转引玉的作用，争取由中国的程序员率先统一出数据建模领域的“设计模式”。