第5章 数据库表的规范化
数据库第五章习题及答案
数据库第五章习题及答案本文档为数据库第五章的习题及答案，帮助读者巩固数据库相关知识。
习题1. 数据库的优点有哪些？数据库具有以下优点： - 数据共享：多个用户可以同时访问和共享数据库中的数据。
- 数据一致性：数据库提供事务管理能力，保证了数据的一致性。
- 数据持久性：数据在数据库中是永久存储的，不会因为系统关机或程序结束而丢失。
- 数据冗余度低：数据库通过规范化设计，减少了数据的冗余性，提高了数据的存储效率。
- 数据独立性：数据库支持数据与应用程序的独立性，提高了系统的灵活性和维护性。
- 数据安全性：数据库提供了用户权限管理和数据备份机制，保证了数据的安全性。
2. 数据库的三级模式结构是什么？数据库的三级模式结构包括： - 外模式（视图层）：外模式是用户所看到的数据库的子集，用于描述用户对数据库的逻辑视图。
每个用户可以有不同的外模式来满足自己的需求。
- 概念模式（逻辑层）：概念模式是全局数据库的逻辑结构和组织方式，描述了数据的总体逻辑视图。
概念模式独立于具体的应用程序，是数据库管理员的角度来看待数据库的。
- 内模式（物理层）：内模式是数据库的存储结构和物理组织方式，描述了数据在存储介质上的实际存储方式。
3. 数据库的完整性约束有哪些？数据库的完整性约束包括： - 实体完整性约束：确保表的主键不为空，每个实体都能够唯一标识。
- 参照完整性约束：确保外键的引用关系是有效的，即外键值必须等于被引用表中的主键值或者为空。
- 用户定义完整性约束：用户可以自定义额外的完整性约束，如检查约束、唯一约束、默认约束等。
4. 数据库的关系模型有哪些特点？数据库的关系模型具有以下特点： - 数据用二维表的形式进行组织，表由行和列组成，每一行表示一个实体，每一列表示一个属性。
- 表与表之间通过主键和外键建立关联关系，形成关系。
- 关系模型提供了一种数据独立性的设计方法，使得应用程序与数据的逻辑结构相分离，提高了系统的灵活性和可维护性。
教你如何进行数据库设计与规范化
教你如何进行数据库设计与规范化数据库是现代信息系统中非常重要的组成部分，它能够有效地管理数据，提供数据的快速访问和数据的持久化存储。
数据库设计与规范化是数据库开发过程中的关键环节，本文将以专业的角度为读者介绍如何进行数据库设计与规范化。
第一章：数据库设计的基本原则数据库设计的目标是根据系统需求，合理地组织和存储数据，以满足数据的可靠性、安全性、一致性和高性能等要求。
在设计数据库时，应遵循以下基本原则：1. 数据库的结构应反映系统的实际需求，逻辑结构和组织结构要合理。
2. 数据库的设计应具有一定的可扩展性和灵活性，便于后期的扩展和维护。
3. 数据库的设计要考虑数据的完整性，包括实体完整性、参照完整性和用户定义的完整性。
4. 数据库的设计要避免冗余和不一致，保证数据的一致性和准确性。
5. 数据库的设计要考虑性能问题，包括查询的效率和数据的存储空间等方面。
数据库设计的过程包括需求分析、概念设计、逻辑设计和物理设计等阶段。
1. 需求分析：明确系统需求，包括数据的输入、输出和处理等方面，分析用户的需求和期望。
2. 概念设计：根据需求分析结果，设计出概念模型，包括实体-联系图、数据流图等，描述数据的组织和关系。
3. 逻辑设计：将概念模型转化为逻辑模型，选择合适的数据模型，设计出数据库的结构和关系。
4. 物理设计：将逻辑模型转化为物理模型，选择合适的存储结构和索引等，确定数据库的存储方式和存储结构。
第三章：数据库规范化的基本理念数据库规范化是为了消除数据中的冗余和不一致，提高数据库的设计质量和性能。
数据库规范化的基本理念包括：1. 第一范式：每个属性都是不可再分的，属性值的原子性。
2. 第二范式：每个非主属性完全依赖于主键，不存在部分依赖。
3. 第三范式：每个非主属性只依赖于主键，不存在传递依赖。
4. BCNF范式：消除主键以外的属性之间的函数依赖关系。
数据库规范化的步骤包括：1. 识别主键和函数依赖：确定实体和属性，识别主键，分析函数依赖关系。
5第五章第4讲关系模式的规范化
5第五章第4讲关系模式的规范化关系模式的规范化是数据库设计中的一个重要概念，它通过一系列规则和规范化原则，使得关系模式能够更加合理、高效地组织和管理数据。
规范化的目的是消除冗余和数据依赖，以避免数据异常和不一致的情况发生。
本文将介绍关系模式规范化的基本概念、规则和原则，并讨论规范化的实际应用。
关系模式规范化的基本概念是：在关系数据库中，每个关系模式都应该经过规范化，以达到最佳的数据结构和数据组织方式。
规范化是一个多阶段的过程，每个阶段都有特定的规则和原则。
第一范式（1NF）是最基本的规范化原则。
它要求每个关系模式的属性都是原子性的，即不可再分的。
这意味着属性的值不可以是集合、数组或多值的。
如果一个属性的值可以被分解为更小的数据项，则需要拆分为多个属性，使得每个属性都是原子的。
第二范式（2NF）要求在满足1NF的基础上，消除非主属性对码的部分函数依赖。
函数依赖指的是当一个属性的值确定之后，另一个属性的值也能确定。
如果一个属性只依赖于码中的一部分属性，而不是整个码，那么它就存在部分函数依赖，需要拆分为多个关系模式，以消除这种依赖。
第三范式（3NF）要求在满足2NF的基础上，消除非主属性对互相之间的传递依赖。
传递依赖指的是当一个属性的值确定之后，其他非主属性的值也能确定。
如果一个非主属性依赖于另一个非主属性，而不是直接依赖于码，那么它就存在传递依赖，需要拆分为多个关系模式，以消除这种依赖。
此外，还有更高级的规范化形式，如BCNF（巴斯-科德范式）和第四范式。
BCNF要求在满足3NF的基础上，消除所有非主属性对码的冗余依赖。
第四范式则要求在满足BCNF的基础上，消除多值依赖和联合依赖。
这些规范化原则和规则都是为了最大程度地消除数据冗余和依赖问题，并提高数据库的性能和数据完整性。
关系模式规范化在实际应用中有着广泛的应用。
首先，在数据库设计阶段就应该考虑规范化原则，选择合适的属性和关系模式，避免冗余和依赖问题。
SQL数据库第5章表数据操作
•例 • 创建一个规则，并绑定到表KC的课程号列，用于限制课
程号的输入范围 • use xscj • go • Create rule kc_rule • as @rang like ‘[1-5][0-9][0-9]’ • go • Use xscj • exec sp_bindrule ‘kc_rule’,’kc.kch’ • go
• use xscj
• create table xs3
• (xh char(6) not null constraint xh_pk primary key,
• xm char(8)not null,identtitycard char(20) constraint sh_uk unique,
• delete [from ]
•
{table_name׀view_name}
[where <search_condition>] •
的行删39Example:将XSCJ数据库的表XS中总学分小于 • 除：
USE XSCJ •
DELETE FROM XS •
39<
WHERE 总学分 •
go •
• 2. 使用TRUNCATE TABLE语句删除表 数据
• select xh,xm,zhy
• from xs1
•
Where zhy=‘生工’
• 查询结果：select * from xs2
• 二、使用DELETE或TRUNCAT删除数据
• delete 语句的功能是从表中删除行，其基本语法格式为：
• 二、 实体完整性的实现 • 通过选择一列或多列做主键可实现表的实体完整性。 • 一个表只能有一个primary key约束,且primary key
数据库原理第五章关系数据库的规范化设计
12
模式分解是关系规范化的 主要方法(二)
与TDC相比，分解为三个关系模式后，数据的冗余度明显 降低。 当新插入一个系时，只要在关系D中添加一条记录。 当某个教师尚未讲课，只要在关系T中添加一条教师记录， 而与TC授课关系无关，这就避免了插入异常。 当某个系的教师不再讲课时，只需在TC中删除该教师的 全部授课记录，而关系D中有关该系的信息仍然保留，从 而不会引起删除异常。 同时，由于数据冗余度的降低，数据没有重复存储，也不 会引起更新异常。
24
2.2 完全函数依赖和部分函数依赖
例如：学生成绩表中
姓名 王一 王二 王三 王一
学号 1 2 3 4
年龄 16 15 16 16
籍贯 河北 山东 北京 天津
姓名不能推出年龄，学号也不能推出年龄，但是 姓名 + 学号能推出年龄，故完全依赖；
学号能直接推出籍贯，故是部分依赖
25
2.3 传递函数依赖
当关系中的元组增加、删除或更新后都不能被破 坏这种函数依赖。因此，必须根据语义来确定属 性之间的函数依赖，而不能单凭某一时刻关系中 的实际数据值来判断。
20
函数依赖的定义和性质（六）
函数依赖可以保证关系分解的无损连接性
设R(X,Y,Z)，X,Y,Z为不相交的属性集合，如果X Y或X Z，则有R(X,Y,Z)=R[X,Y]*R[X,Z]，其中，R[X,Y]表示关 系R在属性(X,Y)上的投影，即 R等于其投影在X上的自然连 接，这样便保证了关系R分解后不会丢失原有的信息，称为 关系分解的无损连接性
第5章 数据库表的规范化
§ 5.1.4 数据表和规范化 — 转换为第三范式 续
术语3NF（第三范式，third normal form）： 它属于2NF。 它不包括传递依赖。
§ 5.1.5 数据表和规范化 — 改进的设计
依靠规范化我们消除了数据冗余，但是我们不能仅仅 依赖规范化做出好的设计，现在我们来看看如何在规范化的 基础上提高数据库的操作性能和提供数据的能力。 PK分配 命名约定 属性原子性 添加属性 精制PK
表名：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 数据表和规范化 — 改进的设计
步骤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.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章 数据库管理
3.5视图3.5.1为什么要使用视图（1）视图能减少S Q L查询语句编写的工作量及对它进行合理的管理。
（2）视图使用户以不同的方式看待相同数据。
（3）视图对数据库的使用提供一定的逻辑独立性。
（4）视图能够对数据提供安全保护。
3.5.2创建视图•C R E A T E V I E W语句可以创建视图，其一般语法格式为：C R E A T E V I E W<视图名>[(<列名>[，<列名>]…)]A S<S E L E C T语句>[W I T H C H E C K O P T I O N];•W I T H C H E C K O P T I O N可选项关键词表示在对视图进行U P D A T E，I N S E R T 和D E L E T E操作时需要保证更新、插入或删除的记录必须满足视图定义中的条件（即S E L E C T语句中的条件表达式）。
•在创建一个视图时要么指定视图的全部列名，要么全部都不指定。
如果缺省了视图的各个属性列名，则该视图就由查询中S E L E C T子句的目标列的列名组成。
但在下列三种情况下必须明确指定组成视图的所有列名： 第一种：视图中包含了多个来自于不同表的相同列名。
第二种：视图中定义的列是由集函数或列表达式所定义。
第三种：视图中为了某些列定义新的列名。
数据库在创建视图时，将其定义存放到相应的系统表中，以供使用。
【例3.56】创建来自加州的作者信息（p u b s数据库的a u t h o r s表，只包含a u_i d, a u_f n a m e,a u_l n a m e,c i t y）视图C A_A u t h o r s。
•语句如下：C R E A T E V I E W C A_A u t h o r sA S S E L E C T a u_i d,a u_f n a m e,a u_l n a m e,c i t y F R O M a u t h o r sW H E R E(s t a t e='C A')•该例没有指定视图的列名，视图则沿用基本表的指定列的列名。
数据库系统概论 课件 第05章_数据库完整性
列值非空（NOT NULL约束） 列值唯一（UNIQUE约束） 检查列值是否满足一个布尔表达式（CHECK约束）
SQL Server 实现用户定义数据完整性的主要方法 有：约束、默认、规则、自定义数据类型和触发器
1、不允许取空值
DB
例5 在定义“学生”表时，说明学号Sno为主键，姓
数据库系统原理
DB
Principles of Database System
第五章 数据库完整性
第五章
DB
数据库完整性
数据库的完整性(Integrity)
数据的正确性、有效性和相容性
防止不合语义的数据进入数据库
例：学生的年龄必须是整数，取值范围为14-35；
学生的性别只能是男或女； 学生的学号一定是唯一的； 学生所在的系必须是学校开设的系；
DB
FOREIGN KEY(<列名>) REFERENCES <表名> [(<列名>)] [ ON DELETE <参照动作> ] [ ON UPDATE <参照动作> ] 其中 第一个“列名”是外部关键字 第二个“列名”是被参照表中的主键或候选键 。
参照动作
DB
NO ACTION（拒绝）
CASCADE（级联）
FOREIGN KEY(Sno) REFERENCES Student(Sno),
FOREIGN KEY(Cno) REFERENCES Course(Cno)
);
5.2.2 参照完整性检查和违约处理
DB
一个参照完整性将两个表的相应元组联 系起来了
对被参照表和参照表进行增删改操作时
有可能破坏参照完整性 因此，必须进行检查
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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 数据表和规范化 — 转换为第二范式 续