第5章 数据库表的规范化

ASSIGN_NUM ASSIGN_DATE PRJ_NUM
EMP_NUM ASSIGN_HOURS
§ 5.1.5 数据表和规范化 — 改进的设计 续
§ 5.2 规范化和数据库设计
为了确解说明规范化在设计过程中的作用，我们从概念 设计的角度说明建筑公司简单业务的数据库设计过程 .
商务规则：
公司管理很多工程。 每一个工程要求很多雇员。 一个雇员可以分配到几个不同的工程。 一些雇员没有分配到工程处，而且执行与工程不是特别相关的任务。 一些雇员是劳动供应源的一部分，所有工程组都需要他们的服务工作。 例如，公司的管理文书不分配到任何一个具体的工程。 每一个雇员具有一个（单个）主要的工作种类。这个工作种类决定 每小时开单率。 很多雇员的工作种类可能相同。例如公司雇用一个以上的电工。
§ 5.1.4 数据表和规范化 — 转换为第三范式 续
PRJ_NUM PRJ_NAME
表名：PROJECT
EMP_NUM EMP_NAMEJOB_CLASS
JOB_CLASS CHG_HOUR
表名：EMPLOYEE
表名：JOB
EMP_NUM PRJ_NUM
ASSIGN_HOURS
表名：ASSIGN
§ 5.1.4 数据表和规范化 — 转换为第三范式 续
术语3NF（第三范式，third normal form）： 它属于2NF。 它不包括传递依赖。
§ 5.1.5 数据表和规范化 — 改进的设计
依靠规范化我们消除了数据冗余，但是我们不能仅仅 依赖规范化做出好的设计，现在我们来看看如何在规范化的 基础上提高数据库的操作性能和提供数据的能力。 PK分配 命名约定 属性原子性 添加属性 精制PK
§ 5.1.3 数据表和规范化 — 转换为第二范式
1NF到2NF的转换很简单：从上图所示的1NF格式开始， 完成下面的步骤：
步骤1：标识所有键标组件
PROJ_NUM EMP_NUM PROJ_NUM EMP_NUM 每一个组件将成为新表中的键标。换句话说，原始表现在分成了3个表。我 们把这些表分别叫做PROJECT，EMPLOYEE和ASSIGN。
§ 5.1.2 数据表和规范化 — 转换为第一范式 续
术语1NF（第一范式，first normal form）描述了表格式， 在表格式中：
定义了所有键标属性。 表中没有重复组。换句话说，每一行/列插入仅可以包括一 个值，而不是一组值。 所有属性都依赖于主键标。
所有的关系表都满足1NF，该范式的问题是包括了部分依 赖，也就是说，只基于键标一部分的依赖。
第5章 数据库表的规范化
主要学习内容 - 什么是规范化，以及它在数据库设计中的作用 - 范式1NF、 2NF、 3NF - 范式如何从低范式转换为高范式 - 规范化和ER建模被同时用来生成优秀的数据库设计 - 要求非规范化以有效生成信息的情况
§ 5.1 数据表和规范化
表是数据库设计过程中的基本构件。规范化 （normalization）是估算并校正表结构以使数据冗余最 小化的过程，它可以帮助消除数据异常。 规范化通过叫做“范式”的一组平台进行工作。前3个平 台记述为第一范式（1NF）、第二范式（2NF）、第三范 式（3NF）。 从结构的观点来看，2NF优于1NF，而3NF优于2NF。出 于大多数商务数据库设计目的考虑，在规范化过程中对 3NF的需要最多。 实际应用中会涉及规范化和非规范化的权衡。
依赖图（dependency diagram）
PRJ_NUM PRJ_NAME EMP_NUM EMP_NAMEJOB_CLASSCHG_HOUR
HOURS
传递依赖 部分依赖 部分依赖
部分依赖(partial dependencies)：只基于复合主键标的一 部分的依赖。 传递依赖(transitive dependency)：一个非主属性对于另 一个非主属性的依赖
步骤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）
术语2NF（第二范式，second normal form）： 它属于1NF。 它不包括部分依赖；也就是说，没有属性只依赖于主键标 的一部分 由于只有表的主键标由几个属性组成时，部分依赖才存 在，所以主键标只有单个属性组成的表属于1NF，那么他就 自动属于2NF。 属于2NF的表仍可能显示出传递依赖；也就是说，一个 或多个属性可以在功能上依赖于非键标属性。
§ 5.3 非规范化
尽管规范化关系的创建是很重要的数据库设计目标， 但它只是很多这样的目标中的一个。优秀的数据库设计还要考 虑处理要求。当分解表来符合规范化要求时，数据库表的数量 增加。加入更多数量的表占用了额外的磁盘输入/输出（I/O） 操作和处理逻辑，因此减慢了系统速度。为了加快处理速度， 可能有非常偶然的情况允许一定程度上非规范化。 请记住必须仔细权衡更快处理速度的好处与数据异常 的弊端。另一方面，一些异常只是在理论上引起注意。例如， 处于现实世界数据库环境中的人们需要担心在主键标是顾客编 号的CUSTOMER表中，ZIP_CODE决定CITY吗？为了消除 CUSTOMER表中的传递依赖，生成下面的分割表确实实用吗？ ZIP（ZIP_CODE， CITY） 我们的建议：在规范化过程中使用一些常识。
表名：PROJECT 表名：JOB
PRJ_NUM PRJ_NAME EMP_NUM
JOB_CODE
JOB_DESCRIPTION
JOB_CHG_HOUR
§ 5.1.5 数据表和规范化 — 改进的设计 续
表名：EMPLOYEE
EMP_NUM EMP_NAMEJOB_CLASS
— 命名的原子性 — 添加属性
§ 5.1.2 数据表和规范化 — 转换为第一范式
步骤1：消除重复组 先从介绍表格式中的数据开始，在表格式中，每个单元格都有单个值， 而且没有重复组。为了消除重复组，通过确保每一个重复组属性包括一个合 适的数据值来消除空值。
步骤2：标识键标 为了保持惟一标识任何属性值的正确的主键标，新键标必须由 PROJ_NUM和EMP_NUM的组合组成
§ 5.1.4 数据表和规范化 — 转换为第三范式
通过完成下面的3个步骤，可以很容易地消除由图5-4中 所示的数据库体系结构引起的数据异常： 步骤1：标识每一个新的行列式（determinant） 对于每一个传递依赖，将它的行列式写为新表的PK（行 列式是它的值确定行中其他值的任何属性） 步骤2：标识依赖属性, 标识依赖于步骤1中所标识的每一个行列式的属性，并标 识依赖。在本例中，写为：JOB_CLASS —>CHG_HOUR， 命名表来反映它的内容和功能。在本例中，JOB似乎是合适 的。 步骤3：从传递依赖中消除依赖属性 从具有这样的传递关系的每一个表中消除传递关系（一 个或多个）中的所有依赖属性。
表名：PROJECT
表名：JOB
PRJ_NUM PRJ_NAME
JOB_CLASS CHG_HOUR
— 添加属性
— PK分配 — 命名约定
表名：PROJECT
表名：JOB
PRJ_NUM PRJ_NAME EMP_NUM
JOB_CODE
JOB_DESCRIPTION
JOB_CHG_HOUR
§ 5.1.5 数据表和规范化 — 改进的设计
§ 5.1 数据表和规范化 — 规范化需要
§ 5.1.1 数据表和规范化 — 规范化需要 续
报表中的总费用为派生值，它没必要存储在数据表中。
§ 5.1.1 数据表和规范化 — 规范化需要 续
但该表与关系数据库要求不符合，而且在数据处理 方面做的不好： 主键标包括空值 表项目引起数据不一致。例如，可以将JOB_CLASS值 “Elect. Engineer”输入为“Elect. Eng”。 表显示了数据冗余。从而生成了下面的异常： — 更新异常 — 插入异常 —删除异常
EMP_NUM
EMP_LNAME EMP_FNAME EMP_INITIAL EMP_HIREDATE
JOB_CODE
§ 5.1.5 数据表和规范化 — 改进的设计 续
§ 5.1.5 数据表和规范化 — 改进的设计 续
表名：ASSIGN
EMP_NUM PRJ_NUM ASSIGN_HOURS
— 精制PK
步骤3：标识所有依赖，步骤2中PK的标识意味着你已经标识了下面的依赖： PROJ_NUM，EMP_NUM —> PROJ_NAME，EMP_NAME， JOB_CLASS，CHG_HOUR，HOURS PROJ_NUM —> PROJ_NAME
§ 5.1.2 数据表和规范化 — 转换为第一范式
§ 5.1.2 数据表和规范化 — 转换为第一范式 续
§ 5.1.3 数据表和规范化M PRJ_NAME
表名：PROJECT
EMP_NUM EMP_NAMEJOB_CLASSCHG_HOUR 表名：EMPLOYEE
传递依赖
EMP_NUM PRJ_NUM
ASSIGN_HOURS
表名：ASSIGN
§ 5.1.3 数据表和规范化 — 转换为第二范式 续