下载文档原格式
关系数据库的规范化理论与数据库设计在当今数字化的时代，数据成为了企业和组织的重要资产，而关系数据库作为存储和管理数据的重要手段，其设计的合理性直接影响着数据的质量、完整性和可用性。
关系数据库的规范化理论是指导数据库设计的重要原则，它能够帮助我们避免数据冗余、更新异常等问题，从而提高数据库的性能和可靠性。
首先，我们来了解一下关系数据库的基本概念。
关系数据库是由一组二维表组成的，每张表都有一个唯一的表名，表中的每一行称为一个元组，代表一个实体；每一列称为一个属性，代表实体的一个特征。
通过在不同的表之间建立关联，我们可以实现数据的查询和操作。
那么，什么是规范化理论呢？规范化理论是一种用于设计关系数据库的方法和原则，其目的是通过对关系模式进行分解和优化，消除数据冗余和更新异常，确保数据的一致性和完整性。
规范化理论主要包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求表中的每个属性都是不可再分的原子值。
例如，如果有一个“联系人信息”表，其中包含“地址”这个属性，如果地址又分为“省”“市”“区”“详细地址”等子属性，那么就不满足第一范式，需要将其拆分成多个属性。
第二范式要求在满足第一范式的基础上，每个非主属性都完全依赖于主键。
举个例子，如果有一个“订单”表，主键是“订单号”，而“客户姓名”和“客户地址”等非主属性只依赖于“客户编号”，而不是“订单号”，那么就不满足第二范式，需要将其拆分成两个表，一个是“订单”表，一个是“客户”表。
第三范式要求在满足第二范式的基础上，每个非主属性都不传递依赖于主键。
比如说，有一个“员工”表，主键是“员工编号”，“部门名称”依赖于“部门编号”，而“部门编号”又依赖于“员工编号”，这就不满足第三范式，需要将“部门名称”这个属性移到“部门”表中。
规范化理论在数据库设计中具有重要的意义。
通过规范化设计，可以减少数据冗余，节省存储空间。
想象一下，如果一个客户的信息在多个表中重复存储，不仅浪费空间，而且当客户信息发生变化时，需要在多个地方进行更新，容易导致数据不一致。
关系型数据库设计原则与方法关系型数据库设计是一种常见的数据库设计方法，它的设计原则和方法可以用于设计和优化关系型数据库模式。
本文将介绍关系型数据库设计的五个基本原则和一些常用的方法，以帮助您更好地进行数据库设计和优化。
第一原则：数据分离原则数据分离原则是指将不同的数据类型分开存储，不混杂在同一个表中。
这个原则主要是考虑到数据的规范性和易维护性。
每个数据类型都应该有自己的表，通过相关字段建立关联，并通过外键实现关系。
这种设计方式使数据库的结构更清晰、规范，也方便日后对数据更新和查询。
第二原则：范式设计原则范式设计原则是关系型数据库设计中的核心概念。
它主要是通过分解数据，将重复的数据避免在表中出现，减少冗余和更新异常。
范式的级别分为一到五级，分别用1NF、2NF、3NF、BCNF、4NF和5NF表示。
一般来说，我们在设计数据库时应尽可能遵循更高级别的范式，以减少数据冗余和保证数据的一致性。
第三原则：主键设计原则主键是一种唯一标识数据记录的方式，它在关系型数据库中非常重要。
主键的设计要符合以下要求：1. 唯一性：每个记录的主键值是唯一的，确保数据的完整性和一致性。
2. 稳定性：主键的值应该是稳定不变的，不能频繁修改。
3. 简洁性：主键的值应该是简洁的，便于查询和索引。
常见的主键类型包括自增主键，UUID，日期时间等。
第四原则：索引设计原则索引在关系型数据库中起着加速查询和提高性能的作用。
但是过多或不恰当的索引设计可能会导致数据库性能下降。
索引的设计原则包括：1.覆盖索引：将索引包含需要查询的字段，减少数据库访问次数。
2.唯一性：非重复且唯一的字段适合设计索引。
3.选择性：选择那些频繁被查询的字段。
4.大小：索引的大小应控制在合理范围内，避免占用过多磁盘空间。
第五原则：范围控制原则通过范围控制可以将数据库的规模控制在一定的范围内，避免不必要的数据增长。
范围控制主要包括以下几方面：1.数据量估算：在设计数据库时要对数据量进行预估，合理规划存储空间。
关系数据库理论基础在当今数字化的时代，数据的管理和处理变得至关重要。
关系数据库作为一种广泛应用的数据存储和管理方式，有着坚实的理论基础。
理解这些理论基础，对于我们有效地设计、使用和优化关系数据库至关重要。
关系数据库的核心概念是关系，也就是通常所说的表。
一个关系由一组属性（列）和一组元组（行）组成。
每个属性都有特定的数据类型，例如整数、字符串、日期等。
而元组则代表了一条具体的数据记录。
关系数据库遵循一系列的约束和规则，以确保数据的完整性和准确性。
其中，实体完整性是指主键的值不能为空且必须唯一，用于唯一标识每一条记录。
例如，在一个学生信息表中，学号通常被设定为主键，每个学生的学号都不能重复且不能为空。
参照完整性则规定了表之间的关联关系。
如果存在两个表通过某个字段相关联，那么在相关联的表中，对应的值必须存在或者为空。
比如，一个课程表和一个选课表，选课表中的课程编号必须在课程表中存在，否则就违反了参照完整性。
关系代数是关系数据库操作的理论基础。
它包括了选择、投影、连接、并、交、差等基本运算。
选择操作类似于筛选，根据给定的条件从关系中选取满足条件的元组。
投影则是从关系中选取指定的属性列。
连接操作用于将两个或多个关系根据共同的属性值组合在一起。
函数依赖是关系数据库设计中的一个重要概念。
如果属性 A 的值决定了属性 B 的值，那么就说 B 函数依赖于 A。
例如，一个订单表中，订单号决定了订单日期，那么就可以说订单日期函数依赖于订单号。
范式是关系数据库设计的重要指导原则。
常见的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求每个属性都是不可再分的原子值。
第二范式在满足第一范式的基础上，要求非主键属性完全依赖于主键，而不能仅依赖于主键的一部分。
第三范式则进一步要求非主键属性之间不存在传递依赖。
满足更高的范式可以减少数据冗余，提高数据的一致性和完整性，但并不是范式越高就一定越好。
在实际应用中，需要根据具体的业务需求和性能要求来权衡范式的级别。
真诚为您提供优质参考资料，若有不当之处，请指正。
第4章关系数据库设计理论习题一、选择题1、C2、B3、C4、C5、A6、B7、A 8、B9、D 10、B二、填空题1、数据依赖主要包括_函数_依赖、_多值_依赖和连接依赖。
2、一个不好的关系模式会存在_插入异常_、_删除异常_和__修改复杂_等弊端。
3、设X→Y为R上的一个函数依赖，若_对任意X的真子集X’,均无X’→Y 存在__，则称Y完全函数依赖于X。
4、设关系模式R上有函数依赖X→Y和Y→Z成立，若_Y不包含于X_且_Y→X不成立_，则称Z传递函数依赖于X。
5、设关系模式R的属性集为U，K为U的子集，若_K→U为完全函数依赖_，则称K 为R的候选键。
6、包含R中全部属性的候选键称_主属性_。
不在任何候选键中的属性称__非主属性_。
7、Armstrong公理系统是_有效__的和_完备__的。
8、第三范式是基于_函数_依赖的范式，第四范式是基于_多值_依赖的范式。
9、关系数据库中的关系模式至少应属于_第一_范式。
10、规范化过程，是通过投影分解，把_一个范式级别较低的_的关系模式“分解”为_若干个范式级别较高__的关系模式。
三、简答题1、解释下列术语的含义：函数依赖、平凡函数依赖、非平凡函数依赖、部分函数依赖、完全函数依赖、传递函数依赖、范式、无损连接性、依赖保持性。
解：111 / 6真诚为您提供优质参考资料，若有不当之处，请指正。
112 / 6 函数依赖：设关系模式R （U ，F ），U 是属性全集，F 是U 上的函数依赖集，X 和Y 是U 的子集，如果对于R （U ）的任意一个可能的关系r ，对于X 的每一个具体值，Y 都有唯一的具体的值与之对应，则称X 函数决定Y ，或Y 函数依赖于X ，记X →Y 。
我们称X 为决定因素，Y 为依赖因素。
当Y 不函数依赖于X 时，记作：X Y 。
当X →Y 且Y →X 时，则记作：X ↔Y 。
平凡函数依赖：当属性集Y 是属性集X 的子集时，则必然存在着函数依赖X →Y ，这种类型的函数依赖称为平凡的函数依赖。
第4章关系数据库规范化理论数据库设计的一个最基本的问题是怎样建立一个合理的数据库模式，使数据库系统无论是在数据存储方面，还是在数据操作方面都具有较好的性能。
什么样的模型是合理的模型，什么样的模型是不合理的模型，应该通过什么标准去鉴别和采取什么方法来改进，这是在进行数据库设计之前必须明确的问题。
为使数据库设计合理可靠、简单实用，长期以来，形成了关系数据库设计理论，即规范化理论。
它是根据现实世界存在的数据依赖而进行的关系模式的规范化处理，从而得到一个合理的数据库设计效果。
本章首先说明关系规范化的作用，接着引入函数依赖和范式等基本概念，然后介绍关系模式等价性判定和模式分解的方法，最后简要介绍两种数据依赖的概念。
4.1 关系规范化的作用4.1.1问题的提出从前面的有关章节可知，关系是一张二维表，它是涉及属性的笛卡尔积的一个子集。
从笛卡尔积中选取哪些元组构成该关系，通常是由现实世界赋予该关系的元组语义来确定的。
元组语义实质上是一个n目谓词（n是属性集中属性的个数）。
使该n目谓词为真的笛卡尔积中的元素（或者说凡符合元组语义的元素）的全体就构成了该关系。
但由上述关系所组成的数据库还存在某些问题。
为了说明的方便，我们先看一个实例。
【例4.1】设有一个关于教学管理的关系模式R(U)，其中U由属性Sno、Sname、Ssex、Dname、Cname、Tname、Grade组成的属性集合，其中Sno的含义为学生学号，Sname为学生姓名，Ssex为学生性别，Dname为学生所在系别，Cname为学生所选的课程名称，Tname 为任课教师姓名，Grade为学生选修该门课程的成绩。
若将这些信息设计成一个关系，则关系模式为：教学（Sno，Sname，Ssex，Dname，Cname，Tname，Grade）选定此关系的主键为（Sno,Cname）。
由该关系的部分数据（如表4-1所示），我们不难看出，该关系存在着如下问题：1. 数据冗余（Data Redundancy）●每一个系名对该系的学生人数乘以每个学生选修的课程门数重复存储。
第四章关系数据库设计理论一、单项选择题1．关系数据库中的关系必须满足：每个属性都是 B 。
A．长度不变的B．不可分解的C．互相关联的D．互不相关的2．若关系模式R(A,B,C,D,E)及其上的FD集F={A→D,B→C,E→A}，则R的候选码为 B 。
A．AB B．BE C．CD D．DE3．2NF的关系模式 B 。
A．可能是1NF B．一定是1NF C．一定是3NF D．一定是BCNF 4．若关系模式R的属性全是主属性，则R的至少应属于 C 。
A．1NF B．2NF C．3NF D．BCNF5．消除了部分函数依赖的1NF关系模式必定是___B___。
A．1NF B．2NF C．3NF D．BCNF6．关系模式的候选码可以有一个或多个，而主码__C____。
A．可以有多个B．可能没有C．只能有一个D．可以有一个或多个7．候选码中的属性可以有 D 。
A．0个或多个B．0个C．1个D．1个或多个8．设关系模式R(A,B,C)的分解ρ={AB, AC}，当R上的FD集F= C 时，ρ为无损分解。
A．{ B→C } B．{ C→B } C．{ A→C } D．{C→A }9．设关系模式R(A,B,C)的分解ρ={AB, AC}，当R上的FD集F= A时，ρ为无损分解且保持函数依赖。
A．{ A→B } B．{ A→B, B→C } C．{ B→A } D．{C→B, B→A } 10．设有关系模式R(S, D, M)，其函数依赖集为F={S→D,D→M}, 则R最高属于 B 。
A．1NF B．2NF C．3NF D．BCNF 11．设有关系模式R(A, B, C, D)，其函数依赖集为F={AB→C, C→D}, 则R最高属于B 。
A．1NF B．2NF C．3NF D．BCNF 12．当 B 成立时，称X→Y为平凡函数依赖。
A．X⊆Y B．Y⊆X C．X∩Y=φD．X∩Y≠φ13．在关系模式R中，函数依赖X→Y的语义是 B 。
关系型数据库的设计与实现关系型数据库是一种基于关系模型来组织和管理数据的数据库系统。
它采用表格的形式表示数据，并通过表格之间的关联来实现数据的高效查询和管理。
在本文中，我们将探讨关系型数据库的设计与实现，介绍其核心概念、设计原则和实施步骤。
1. 关系数据库的核心概念1.1 表格和关系关系型数据库中的数据存储在表格中，每个表格由若干列和若干行组成。
每一列代表一个数据字段，每一行代表一个数据记录。
表格之间可以建立关系，通过定义外键约束来指明数据之间的关联关系。
1.2 主键和外键主键是表格中唯一识别每条记录的字段，它的值必须是唯一且非空的。
外键是指一个表格中的字段引用了另一个表格中的主键，用于建立两个表格之间的关联。
1.3 视图视图是由一个或多个表格生成的虚拟表格，它可以隐藏底层数据结构的复杂性，并提供更简化和高效的数据访问接口。
视图可以用于数据查询、数据过滤和数据修改等操作。
2. 关系型数据库设计原则2.1 原子性每个字段要保持原子性，即每个字段只包含一个值。
这样可以简化数据的操作和查询，并提高数据的可靠性和一致性。
2.2 唯一性每张表格应该具有唯一的主键，以保证每条记录的唯一性。
这样可以避免数据冗余和数据不一致的问题，提高数据的质量和一致性。
2.3 一致性数据在各个表格之间应该保持一致性，即通过定义外键约束来约束数据的关联关系。
这样可以避免数据的混乱和不一致，提高数据的可靠性和完整性。
2.4 数据分离不同种类的数据应该放在不同的表格中，避免数据的混杂和复杂性。
通过合理划分表格和定义关联关系，可以提高数据的可读性和易用性。
3. 关系型数据库的实施步骤3.1 需求分析在设计关系型数据库之前，需要先进行需求分析，明确数据库系统的功能和数据需求。
此阶段需要和用户或相关部门进行沟通，了解业务流程和数据流程，并识别出主要实体、属性和关系。
3.2 数据建模根据需求分析的结果，可以进行数据建模。
数据建模是将现实世界中的实体、属性和关系映射到关系模型中的一个过程。
关系数据库的规范化理论与数据库设计E.F.CODD提出的数据库规范化理论1.1“不好”的关系模式中存在的问题可能存在的问题：数据冗余更新异常插入异常删除异常数据依赖：是可以作为关系模式的取值的任何一个关系所必须满足的一种约束条件，是通过一个关系中各个元组的某些属性值之间的相等与否体现出来的相互关系。
数据依赖包括：函数依赖和多值依赖和其他1.2函数依赖1.21函数依赖的定义设R(A1,A2,……..An)是一个关系模式，X,Y是{A1,A2……..An}的子集，若只要关系r是关系模式R的可能取值，则r中不可能有两个元组在X中的属性值相等，而在Y中的属性值不相等，则称”X函数决定Y”或”Y函数依赖于X”,记做X→Y。
（ps：一些属性决定另一些属性称为函数决定）只能根据语义来判断。
相关的属性：若X->Y, 但Y不属于X, 则称X->Y为非平凡依赖，否则为平凡依赖。
若X->Y, 则称X为决定元素。
若X->Y,Y->X, 则记做X←>Y若Y不函数依赖于X, 记做X不函数决定Y在关系模式R中，如果X->Y，并且对于X的任意一个真子集X` 都有X` 不函数决定Y，则称Y对X完全函数依赖，记做X__f__Y若X->Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记做X__p___Y若X—>Y（Y不包含于X），Y不函数决定X，Y函数决定Z，则称Z 对X传递函数依赖。
把关系模式表示为R<U，F>，其中U是一组属性，F是属性组U上的一组数据依赖，当且仅当U上的一个关系r满足F时，r称为关系模式R<U，F>的一个关系。
1.22 函数依赖的逻辑蕴含设R<U，F>是一个关系模式，X，Y是U中的属性组，若在R<U，F>的任何一个满足F中函数依赖的关系r上，都有函数依赖X->Y成立，则称F逻辑蕴含X->Y。
（ps:即是函数依赖组隐含决定的其他函数依赖关系）如关系模式R<U，F>中为F所逻辑蕴含的函数依赖的全体称作F的闭包，记做F+ .1.23 码设K为关系模式R<U，F>中的属性或属性组，若K->U在F闭包中，而找不到K 的任何一个真子集K` ,能使K`->U在F闭包中，则称K为关系模式R的候选码，当候选码多于一个时，选定其中一个做主码。
数据库工程师复习重点：关系数据库逻辑设计关系数据库逻辑设计5.1 概述5.2 基本概念5.2.1 关系模型1、关系模型采用一个二维表格在计算机中组织、存储、处理和管理数据。
(1) 关系名(数据库名)：由字母数字组成;(2) 属性名;(3) 关系模式和关系：描述模式描述关系的静态结构，由模式名、关系模式所包含的属性及属性值所满足的条件组成模式定义。
(4) 元组：描述关系中的行;(5) 域：它定义关系的每个属性取值的类型;(6) 主码：能够惟一标识关系中每一个元组的属性或属性组;(7) 关系的数学定义：关系模式是建立在集合集论的基础上的，用数学的概念定义关系有;(A) 定义一：域是值的集合，同一个域中的值具有相同的数据类型;(B) 定义二：(C) 定义三：(D) 当关系引用了属性名后关系具有以下属性：[1] 不能有重复的元组;[2] 元组上下无序;[3] 按属性名引用时属性左右无序;[4] 所有属性值都是原子项(不可再分);(8) 总结：关系是一张二维表，表中的一行被称为一个元组，一列称为属性，由一组域值组成。
关系是元组的集合，关系中的每个元组在数学上被定义为这个关系所涉及的全部域值中笛卡儿积的一个元素。
5.2.2 关系数据库1、关系数据库是按照二维表组织和存储的相互关联的关系的集合，关系数据库模式是关系模式的集合;5.2.3 关系的完整性1、关系的完整性(完整性约束)：是对关系的某种约束规则和关系满足的定义。
通常这组约束规则用来限定和检查数据库所含实例的合法性和正确性;2、完整性约束分静态和动态两种，静态完整性约束是基于关系模式的，主要有主码、外码约束和域约束组成;动态完整性约束是基于企业的业务规则的。
3、静态完整性约束规则：(1) 主码约束：主码必须满足：(A) 惟一性：在一个关系中不存在两个元组，它们具有相同的主码值;(B) 最小性：不存在从组成主码的属性集中去掉一个属性，还仍能保持数据的惟一性;(2) 外码约束：(3) 用户定义的完整性：5.3 关系数据库设计理论5.3.1 问题的提出究竟一个关系数据库包含哪些属性是合理的，如何评价一个关系模式设计的优劣?5.3.2 函数依赖函数依理论利用一个关系中属性之间的依赖关系评价和优化关系模式，以保证存储到数据库中的关系具有较好特性;1、函数依赖：(1) 设R(U)为一关系模式，X和Y为属性全集U的子集，若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称“X函数决定Y”或“Y函数依赖于X”，并记作X Y，其中X称为决定因素，因为根据函数依赖定义，给定一个X，就能惟一决定一个Y。
关系数据库设计理论练习题答案第四章关系数据库设计理论练习题一、选择题1、关系规范化中的删除操作异常是指①A，插入操作异常是指②DA、不该删除的数据被删除.B、不该插入的数据被插入;C、应该删除的数据未被删除;D、应该插入的数据未被插入.2、关系数据库规范化是为解决关系数据库中（）问题而引入的。
A、插入异常、删除异常和数据冗余；B、提高查询速度;C、减少数据操作的复杂性;D、保证数据的安全性和完整性。
3、假设关系模式R（A，B）属于3NF，下列说法中（）是正确的。
A、R一定消除了插入和删除异常；B、R仍可能存在一定的插入和删除异常;C、R一定属于BCNF；D、A和C都是.4、关系模式的分解A、唯一B、不唯一.5、设有关系W（工号，姓名，工种，定额），将其规范化到第三范式正确的答案是（）A、W1（工号，姓名），W2（工种，定额）；B、W1（工号，工种，定额），W2（工号，姓名）；C、W1（工号，姓名，工种），W2（工种，定额）;D、以上都不对.6、设学生关系模式为：学生（学号，姓名，年龄，性别，平均成绩，专业），则该关系模式的主键是（）A、姓名；B、学号，姓名；C、学号;D、学号，姓名，年龄. 7根据数据库规范化理论，下面命题中正确的是（）A、若R∈2NF,则R∈3NFB、若R∈1NF,则R不属于BCNFC、若R∈3NF,则R∈BCNFD、若R∈BCNF,则R∈3NF8、关系数据库设计理论中，起核心作用的是A、范式；B、模式设计；C、函数依赖;D、数据完整性.9、设计性能较优的关系模设称为规范化，规范化的主要理论依据是（）A、关系规范化理论;B、关系运算理论；C 、关系代数理论；D 、数理逻辑。
10、规范化理论是关系数据库进行逻辑设计的理论依据。
根据这个理论，关系数据库中的关系必须满足：其每一属性都是（）A 、互不相关的；B 、不可分解的C 、长度可变的；D 、互相关联的。
11、规范化过程主要为克服数据库逻辑结构中的插入异常、删除异常以及（）的缺陷。
第6章关系数据库设计理论本章主要讲解在关系数据库的设计过程中，如何减少数据冗余，避免出现异常，该如何对数据库模式进行中心设计。
1．深入理解函数依赖和键码的概念。
学会计算属性的封闭集。
2．模式设计是本章的重点。
了解数据冗余和更新异常产生的根源；理解关系模式规范化的途径；准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别；深入理解模式分解的原则；熟练掌握模式分解的方法，能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。
3.了解多值依赖和第四范式的概念，掌握把关系模式分解成属于第四范式的模式的方法。
本章主要的知识点包括：知识点1 函数依赖知识点2 模式设计知识点3 多值依赖学习要点1、函数依赖1.1函数依赖的定义如果关系R的两个元组在属性A1，A2，… An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。
那么，我们就说在关系R中属性B函数依赖于属性A1A2…An。
记做A1A2…An ，也可以说“A1，A2，…，An函数决定B”。
A1A2…An称为决定因素。
举例：在这个关系中，学号确定后，学生的姓名及所在的系就都确定了。
属性中的这种依赖关系就是函数依赖。
在本例中存在下列函数依赖。
•Sno SN ame•Sno S dept•S dept Mname•Sno C name Grade1.2 关系的键码如一个或多个属性的集合{A1，…，An}满足如下条件，称该集合为关系R的键码：1. 这些属性函数决定该关系的所有其它属性。
2. {A1，…，An}的任何真子集都不能函数决定R的所有其它属性，键码必须是最小的。
1.3 超键码包含键码的属性集称为“超键码” 。
因此，每个键码都是超键码。
某些超键码不是（最小的）键码。
每个超键码都满足键码的第一个条件：函数决定它所在的关系的所有其它属性。
超键码不必满足键码的第二个条件：最小化条件。
1.4 函数依赖规则分解/合并规则可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。
同样，我们也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。
两种情况下，新的依赖集都等价于旧的依赖集。
平凡依赖规则对于函数依赖A1A2…An B来说，如果B是A中的某一个，我们就称之为“平凡的”。
对于函数依赖A1A2…An B1B2…Bm，如果B是A的子集，则称该依赖为平凡的。
如果B中至少有一个属性不在A中，则称该依赖为非平凡的。
如果B中没有一个属性在A中，则称该依赖为完全非平凡的。
函数依赖A1A2…An B1B2…Bm等价于A1A2…An C1C2…Ck，其中C是B 的子集，但不在A中出现。
我们称这个规则为“平凡依赖规则”。
举例：下面三个函数依赖关系中Sno Cname Grade Cname Grade右边属性集是左边属性集的子集，根据平凡依赖的定义，这个函数依赖属于平凡依赖。
（设计人员注意：请用动画表示黄色字和蓝色字。
）Sno Cname Cname Grade右边的Cname属性在左边的属性集Z中，而Grade属性不在左边的属性集中，这个函数依赖是非平凡依赖。
（设计人员注意：请用动画表示黄色字和蓝色字。
）Sno Cname Sname Grade右边的属性都不在左边的属性集中，这个函数的依赖是完全非平凡依赖。
传递规则传递规则使我们能把两个函数依赖级联成一个新的函数依赖。
如果A1A2…An B1B2…Bm和B1B2…Bm C1C2…Ck，在关系R中成立，则A1A2…An C1C2…Ck在R中也成立。
这个规则就称为传递规则。
举例：对于关系Student，有如下两个依赖：Sno SdeptSdept Mname根据传递规则，可以得到一个新的依赖Sno Mname学习要点2 模式设计2.1问题的提出设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。
造成这种冗余的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。
当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。
主要表现如下：1．数据冗余。
2．修改异常。
3．删除异常。
4．插入异常。
举例：12．修改异常：修改了一个学生对应的系主任，其他的没有修改。
3．删除异常。
删除一个学生选修的课程可能导致这个学生的全部信息丢失。
4．插入异常。
如果缺少键码属性集合中的元素，会导致不合理情况的发生。
例如无法对数据库进行插入、更新等操作。
2.2问题的根源关系的键码函数决定该关系的所有其它属性。
由于键码能唯一确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。
一个关系中的所有属性都函数依赖于该关系的键码。
不同的属性在关系模式中所处的地位和扮演的角色是不同的。
把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。
不同的属性对键码函数依赖的性质和程度是有差别的。
有的属于直接依赖，有的属于间接依赖（通常称为传递依赖）。
当键码由多个属性组成时，有的属性函数依赖于整个键码属性集，而有的属性只函数依赖于键码属性集中的一部分属性。
完全依赖与部分依赖对于函数依赖W A，如果存在V W（V是W的真子集）而函数依赖V A成立，则称A部分依赖于W；若不存在这种V，则称A完全依赖于W。
当存在非主属性对键码部分依赖时，就会产生数据冗余和更新异常。
若非主属性对键码完全函数依赖，则不会出现类似问题。
传递依赖对于函数依赖X Y，如果X（X不函数依赖于Y）而函数依赖Y Z成立，则称Z对X传递依赖。
如果X Y，且Y X，则X，Y相互依赖，这时Z与X之间就不是传递依赖，而是直接依赖了。
我们以前所讨论的函数依赖大多数是直接依赖。
举例：其中{Sno, Cname}为键码，函数依赖集如下：Sno Sname,Sdept;Sdept Mname;Sno Mname;pSno, CnamefSno,Cname Grade分析可得：Sname，Sdept，Mname函数依赖于Sno，部分依赖于键码；Grade完全依赖于键码。
则对键码完全依赖的Grade没有任何冗余；对键码部分依赖的属性Sname，Sdept，Mname存在大量的数据冗余，并且有可能出现更新异常。
Mname传递依赖于Sno，当一个学生选修多门课程的时候，系主任的名字会多次重复出现，并有可能出现更新异常。
结论：（1）在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。
（2）在一个关系模式中，当存在非主属性对键码的传递依赖时，就会产生数据冗余和更新异常。
（3）主属性对键码的部分依赖和传递依赖也会导致产生数据冗余和更新异常。
2.3 解决的途径部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖。
部分依赖是以对键码的某个真子集的依赖为基础；传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。
导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。
在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然从形式上看多一种描述方式，但从本质上看，则完全是冗余的。
正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。
解决的途径——消除关系模式中各属性对键码的冗余的依赖。
2.4 范式范式就是符合某一种级别的关系模式的集合。
目前主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。
第一范式需满足的要求最低，在第一范式基础上满足进一步要求的为第二范式：1NF 2NF 3NF BCNF 4NF通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化。
第一范式（1NF）如果一个关系模式R的所有属性都是不可分的基本数据项，则这个关系属于第一范式。
在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。
不满足第一范式的数据库模式不能称为关系数据库。
第二范式（2NF）若关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码，则R属于第二范式。
第二范式就是不允许关系模式中的非主属性部分函数依赖于键码。
对于不符合第二范式要求的关系模式可以通过分解消除非主属性对键码的部分依赖。
关系分解的含义关系R的分解包括两个方面，一方面是把R的属性分开，以构成两个新的关系模式：另一方面是通过对R的元组进行投影而产生两个新的关系。
给定一个模式为{A1，A2，…，An}的关系R，我们可以把R分解为两个关系S和T，模式分别为{B1，B2，…，Bm}和{C1，C2，…，Ck}，使得：1．{A1，…，An}={B1，…，Bm}∪{C1，…，Ck}2．关系S中的元组是R的所有元组在{B1，…，Bm}上的投影。
对于R的当前实例的每个元组t，取t在属性B1，B2，…，Bm上的分量。
这些分量构成一个元组，它属于S的当前实例。
3．类似地，关系T中的元组是R的当前实例中的元组在属性集{C1，C2，…，Ck}上的投影。
第三范式（3NF）若关系模式R属于第一范式，且每个非主属性都不传递依赖于键码，则R属于第三范式。
这里应说明一点：属于第三范式的关系模式必然属于第二范式。
因为可以证明部分依赖蕴含着传递依赖BC范式（BCNF）若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R 属于BC范式。
通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。
BC范式既检查非主属性，又检查主属性。
当只检查非主属性时，就成了第三范式。
满足BC范式的关系都必然满足第三范式举例：学生关系模式Student（Sno，Sname，Sdept，Mname，Cname，Grade）。
该关系模式存在如下部分依赖：pSno，Cname Sname，Sdept，Mname显然不满足“每个非主属性都完全函数依赖于键码”的条件。
所以学生关系模式不属于第二范式。
将关系Student分解为关系模式S1（Sno, Sname, Sdept, Mname）和关系模式S2（Sno, Cname, Grade）S1为S2为对于关系模式S1有如下函数依赖：Sno Sname，Sdept，MnameSdept Mname键码为单属性，S1属于第二范式；对于关系模式S2的键码为（Sno, Cname）有如下函数依赖：Sno,Cname GradeS2属于第二范式。
关系模式S1（Sno，Sname，Sdept，Mname）由于存在传递依赖，所以不属于第三范式。
做如下分解：S11（Sno，Sname，Sdept）S12（Sdept，Mname）关系S如下：举例：关系模式STC（Sname, Tname, Cname, Grade），其中4个属性分别为学生姓名、教师姓名、课程名和成绩。
