第5章数据库表的规范化

主要学习内容

-什么是规范化，以及它在数据库设计中的作用

-范式1NF、2NF、3NF-范式如何从低范式转换为高范式

-规范化和ER建模被同时用来生成优秀的数据库设计

-要求非规范化以有效生成信息的情况

第5章数据库表的规范化§5.1数据表和规范化表是数据库设计过程中的基本构件。规范化（normalization）是估算并校正表结构以使数据冗余最小化的过程，它可以帮助消除数据异常。规范化通过叫做“范式”的一组平台进行工作。前3个平台记述为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。从结构的观点来看，2NF优于1NF，而3NF优于2NF。出于大多数商务数据库设计目的考虑，在规范化过程中对3NF的需要最多。实际应用中会涉及规范化和非规范化的权衡。§5.1数据表和规范化—规范化需要§5.1.1数据表和规范化—规范化需要续报表中的总费用为派生值，它没必要存储在数据表中。§5.1.1数据表和规范化—规范化需要续

但该表与关系数据库要求不符合，而且在数据处理方面做的不好：主键标包括空值表项目引起数据不一致。例如，可以将JOB_CLASS值“Elect.Engineer”输入为“Elect.Eng”。表显示了数据冗余。从而生成了下面的异常：

—更新异常

—插入异常

—删除异常§5.1.2数据表和规范化—转换为第一范式步骤1：消除重复组

先从介绍表格式中的数据开始，在表格式中，每个单元格都有单个值，而且没有重复组。为了消除重复组，通过确保每一个重复组属性包括一个合适的数据值来消除空值。步骤2：标识键标为了保持惟一标识任何属性值的正确的主键标，新键标必须由PROJ_NUM和EMP_NUM的组合组成步骤3：标识所有依赖，步骤2中PK的标识意味着你已经标识了下面的依赖：

PROJ_NUM，EMP_NUM—>PROJ_NAME，EMP_NAME，

JOB_CLASS，CHG_HOUR，HOURSPROJ_NUM—>PROJ_NAME§5.1.2数据表和规范化—转换为第一范式PRJ_NUMPRJ_NAMEEMP_NUMEMP_NAMEJOB_CLASSCHG_HOURHOURS部分依赖部分依赖传递依赖§5.1.2数据表和规范化—转换为第一范式续部分依赖(partialdependencies)：只基于复合主键标的一部分的依赖。传递依赖(transitivedependency)：一个非主属性对于另一个非主属性的依赖依赖图（dependencydiagram）

§5.1.2数据表和规范化—转换为第一范式续术语1NF（第一范式，firstnormalform）描述了表格式，在表格式中：定义了所有键标属性。表中没有重复组。换句话说，每一行/列插入仅可以包括一个值，而不是一组值。所有属性都依赖于主键标。所有的关系表都满足1NF，该范式的问题是包括了部分依赖，也就是说，只基于键标一部分的依赖。1NF到2NF的转换很简单：从上图所示的1NF格式开始，完成下面的步骤：步骤1：标识所有键标组件

PROJ_NUM EMP_NUM PROJ_NUMEMP_NUM

每一个组件将成为新表中的键标。换句话说，原始表现在分成了3个表。我们把这些表分别叫做PROJECT，EMPLOYEE和ASSIGN。步骤2：标识依赖属性

3个新表PROJECT，EMPLOYEE和ASSIGN可以描述如下：

PROJECT（PROJ_NUM，PROJ_NAME）

EMPLOYEE（EMP_NUM，EMP_NAME，JOB_CLASS，CHG_HOUR）

ASSIGN（PROJ_NUM，EMP_NUM，ASSIGN_HOURS）§5.1.3数据表和规范化—转换为第二范式PRJ_NUMPRJ_NAMEEMP_NUMEMP_NAMEJOB_CLASSCHG_HOURASSIGN_HOURS传递依赖§5.1.3数据表和规范化—转换为第二范式续表名：PROJECTEMP_NUMPRJ_NUM表名：EMPLOYEE表名：ASSIGN§5.1.3数据表和规范化—转换为第二范式续术语2NF（第二范式，secondnormalform）：它属于1NF。它不包括部分依赖；也就是说，没有属性只依赖于主键标的一部分由于只有表的主键标由几个属性组成时，部分依赖才存在，所以主键标只有单个属性组成的表属于1NF，那么他就自动属于2NF。

属于2NF的表仍可能显示出传递依赖；也就是说，一个或多个属性可以在功能上依赖于非键标属性。§5.1.4数据表和规范化—转换为第三范式

通过完成下面的3个步骤，可以很容易地消除由图5-4中所示的数据库体系结构引起的数据异常：步骤1：标识每一个新的行列式（determinant）对于每一个传递依赖，将它的行列式写为新表的PK（行列式是它的值确定行中其他值的任何属性）

步骤2：标识依赖属性,

标识依赖于步骤1中所标识的每一个行列式的属性，并标识依赖。在本例中，写为：JOB_CLASS—>CHG_HOUR，命名表来反映它的内容和功能。在本例中，JOB似乎是合适的。步骤3：从传递依赖中消除依赖属性从具有这样的传递关系的每一个表中消除传递关系（一个或多个）中的所有依赖属性。PRJ_NUMPRJ_NAMEEMP_NUMEMP_NAMEJOB_CLASSASSIGN_HOURS§5.1.4数据表和规范化—转换为第三范式续表名：PROJECTEMP_NUMPRJ_NUM表名：EMPLOYEE表名：ASSIGNJOB_CLASSCHG_HOUR表名：JOB§5.1.4数据表和规范化—转换为第三范式续术语3NF（第三范式，thirdnormalform）：它属于2NF。它不包括传递依赖。§5.1.5数据表和规范化—改进的设计

依靠规范化我们消除了数据冗余，但是我们不能仅仅依赖规范化做出好的设计，现在我们来看看如何在规范化的基础上提高数据库的操作性能和提供数据的能力。PK分配命名约定属性原子性添加属性精制PKPRJ_NUMPRJ_NAME表名：PROJECTPRJ_NUMPRJ_NAME表名：PROJECTJOB_DESCRIPTIONJOB_CHG_HOUR表名：JOBEMP_NUMJOB_CODEJOB_CLASSCHG_HOUR表名：JOB—

PK分配—命名约定—添加属性§5.1.5数据表和规范化—改进的设计PRJ_NUMPRJ_NAME表名：PROJECTJOB_DESCRIPTIONJOB_CHG_HOUR表名：JOBEMP_NUMJOB_CODE§5.1.5数据表和规范化—改进的设计续EMP_NUMEMP_NAMEJOB_CLASS表名：EMPLOYEEEMP_HIREDATEEMP_FNAMEEMP_NUMEMP_LNAMEEMP_INITIALJOB_CODE—命名的原子性—添加属性§5.1.5数据表和规范化—改进的设计续§5.1.5数据表和规范化—改进的设计续ASSIGN_HOURSPRJ_NUMASSIGN_NUMASSIGN_DATEEMP_NUMASSIGN_HOURSEMP_NUMPRJ_NUM表名：ASSIGN—精制PK§5.1.5数据表和规范化—改进的设计续§5.2规范化和数据库设计

为了确解说明规范化在设计过程中的作用，我们从概念设计的角度说明建筑公司简单业务的数据库设计过程.

商务规则：公司管理很多工程。每一个工程要求很多雇员。一个雇员可以分配到几个不同的工程。一些雇员没有分配到工程处，而且执行与工程不是特别相关的任务。一些雇员是劳动供应源的一部分，所有工程组都需要他们的服务工作。例如，公司的管理文书不分配到任何一个具体的工程。每一个雇员具有一个（单个）主要的工作种类。这个工作种类决定每小时开单率。很多雇员的工作种类可能相同。例如公司雇用一个以上的电工。

§5.3非规范化

尽管规范化关系的创建是很重要的数据库设计目标，但它只是很多这样的目标中的一个。优秀的数据库设计还要考虑处理要求。当分解表来符合规范化要求时，数据库表的数量增加。加入更多数量的表占用了额外的磁盘输入/输出（I/O）操作和处理逻辑，因此减慢了系统速度。为了加快处理速度，可能有非常偶然的情况允许一