关系数据库设计理论
第4篇关系数据库设计理论
注意：如果R的候选关键字均为单属性，或R的全体 属性均为主属性，则R∈2NF。
4.2.6 第三范式
1．第三范式的定义 定义4.8 如果关系模式R∈2NF，R（U，F）中所有
非主属性对任何候选关键字都不存在传递函数依赖， 则称R是属于第三范式（Third Normal Form），简称 3NF，记作R∈3NF。 第三范式具有如下性质： (1)如果R∈3NF，则R也是2NF。 (2)如果R∈2NF，则R不一定是3NF。
4.2.1 函数依赖
（2）扩张性 若 X→Y 且 W→Z ， 则 （ X ， W ） → （ Y ， Z ） 。 例 如 ，
SNO→（SN，AGE），DEPT→MN，则有（SNO，DEPT）→ （SN，AGE，MN）。
说明：扩张性实现了两函数依赖决定因素与被决定 因素的分别合并作用。
(3) 合并性 若X→Y且X→Z则必有X→（Y，Z）。例如，在关系 SDC 中 ， SNO→ （ SN ， AGE ） ， SNO→DEPT ， 则 有 SNO→ （SN，AGE，DEPT）。 说明：决定因素相同的两函数依赖被决定因素的可 以合并。
4.2.2 码
已知关系模式R（U，F），如何来找出R的所有候 选键呢？方法的步骤为： 1、查看函数依赖集F中的每个形如Xi→Yi的（i=1,……,n） 函数依赖关系。看哪些属性在所有Yi（i=1,……,n） 中 没 有 出 现 过 ， 设 没 出 现 过 的 属 性 集 为 P （ P=U-Y1Y2……-Yn ） 。 则 当 P=φ （ 表 示 空 集 ） 时 ， 转 4 ； 当 P≠φ时，转2。
关系数据库的规范化理论与数据库设计
关系数据库的规范化理论与数据库设计在当今数字化的时代，数据成为了企业和组织的重要资产，而关系数据库作为存储和管理数据的重要手段，其设计的合理性直接影响着数据的质量、完整性和可用性。
关系数据库的规范化理论是指导数据库设计的重要原则，它能够帮助我们避免数据冗余、更新异常等问题，从而提高数据库的性能和可靠性。
首先，我们来了解一下关系数据库的基本概念。
关系数据库是由一组二维表组成的，每张表都有一个唯一的表名，表中的每一行称为一个元组，代表一个实体；每一列称为一个属性，代表实体的一个特征。
通过在不同的表之间建立关联，我们可以实现数据的查询和操作。
那么，什么是规范化理论呢？规范化理论是一种用于设计关系数据库的方法和原则，其目的是通过对关系模式进行分解和优化，消除数据冗余和更新异常，确保数据的一致性和完整性。
规范化理论主要包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求表中的每个属性都是不可再分的原子值。
例如，如果有一个“联系人信息”表，其中包含“地址”这个属性，如果地址又分为“省”“市”“区”“详细地址”等子属性，那么就不满足第一范式，需要将其拆分成多个属性。
第二范式要求在满足第一范式的基础上，每个非主属性都完全依赖于主键。
举个例子，如果有一个“订单”表，主键是“订单号”，而“客户姓名”和“客户地址”等非主属性只依赖于“客户编号”，而不是“订单号”，那么就不满足第二范式，需要将其拆分成两个表，一个是“订单”表，一个是“客户”表。
第三范式要求在满足第二范式的基础上，每个非主属性都不传递依赖于主键。
比如说，有一个“员工”表，主键是“员工编号”，“部门名称”依赖于“部门编号”，而“部门编号”又依赖于“员工编号”，这就不满足第三范式，需要将“部门名称”这个属性移到“部门”表中。
规范化理论在数据库设计中具有重要的意义。
通过规范化设计，可以减少数据冗余，节省存储空间。
想象一下，如果一个客户的信息在多个表中重复存储，不仅浪费空间，而且当客户信息发生变化时，需要在多个地方进行更新，容易导致数据不一致。
关系型数据库设计原则与方法
关系型数据库设计原则与方法关系型数据库设计是一种常见的数据库设计方法，它的设计原则和方法可以用于设计和优化关系型数据库模式。
本文将介绍关系型数据库设计的五个基本原则和一些常用的方法，以帮助您更好地进行数据库设计和优化。
第一原则：数据分离原则数据分离原则是指将不同的数据类型分开存储，不混杂在同一个表中。
这个原则主要是考虑到数据的规范性和易维护性。
每个数据类型都应该有自己的表，通过相关字段建立关联，并通过外键实现关系。
这种设计方式使数据库的结构更清晰、规范，也方便日后对数据更新和查询。
第二原则：范式设计原则范式设计原则是关系型数据库设计中的核心概念。
它主要是通过分解数据，将重复的数据避免在表中出现，减少冗余和更新异常。
范式的级别分为一到五级，分别用1NF、2NF、3NF、BCNF、4NF和5NF表示。
一般来说，我们在设计数据库时应尽可能遵循更高级别的范式，以减少数据冗余和保证数据的一致性。
第三原则：主键设计原则主键是一种唯一标识数据记录的方式，它在关系型数据库中非常重要。
主键的设计要符合以下要求：1. 唯一性：每个记录的主键值是唯一的，确保数据的完整性和一致性。
2. 稳定性：主键的值应该是稳定不变的，不能频繁修改。
3. 简洁性：主键的值应该是简洁的，便于查询和索引。
常见的主键类型包括自增主键，UUID，日期时间等。
第四原则：索引设计原则索引在关系型数据库中起着加速查询和提高性能的作用。
但是过多或不恰当的索引设计可能会导致数据库性能下降。
索引的设计原则包括：1.覆盖索引：将索引包含需要查询的字段，减少数据库访问次数。
2.唯一性：非重复且唯一的字段适合设计索引。
3.选择性：选择那些频繁被查询的字段。
4.大小：索引的大小应控制在合理范围内，避免占用过多磁盘空间。
第五原则：范围控制原则通过范围控制可以将数据库的规模控制在一定的范围内，避免不必要的数据增长。
范围控制主要包括以下几方面：1.数据量估算：在设计数据库时要对数据量进行预估，合理规划存储空间。
关系数据库的规范化理论与数据库设计
.
13
几个术语和符号
如果 X→Y，则 X 叫做决定因素（Determinant） 如果 X→Y ， Y → X ，则记作： X ←→ Y
如果Y不函数依赖于X，则记作： X→Y
.
14
二、平凡函数依赖与非平凡函数依赖 如果 X→Y，但 Y X，则称 X→Y 是非平凡的函数 依赖
关系模式的规范化：解决插入、删除和更 新异常，尽量消除数据冗余，消除不合适 的数据依赖
这就要求关系模式应该满足一定的条件
关系模式满足不同的条件，称为不同的范 式
.
30
1NF范式
如果关系模式R的所有属性都是不可再分解 的，则称R属于第一范式，简称1NF，记做 R∈1NF。
满足1NF的关系为规范化的关系，否则为非规 范化的关系
U，则【1】为F所逻辑蕴含
XZ->ZY 2008.09 3、下列关于部分函数依赖的叙述中，哪条是正确的？ A、若X->Y,且存在Y的真子集Y’,X->Y’,则Y对X部分函数依赖 B、若X->Y,且存在Y的真子集Y’,X->Y’,则Y对X部分函数依赖 C、若X->Y,且存在X的真子集X’，X’->Y,则Y对X部分函数依赖 D、若X->Y,且存在X的真子集X’，X’->Y,则Y对X部分函数依赖
CNAME 机械设计 高等数学 管道工程 数据结构
.
6
该关系模式可能出现如下 问题：
异常（多个记录更新，刘宏
容易产生数据不一致） 王明
插入异常：TNAME,CNO码， 李红
某个教师没上课，CNO为
空，不能插入）
ADDRESS CNO 18栋302 043
21栋503 056 18栋302 041 17栋503 002
关系数据库理论基础
关系数据库理论基础在当今数字化的时代，数据的管理和处理变得至关重要。
关系数据库作为一种广泛应用的数据存储和管理方式，有着坚实的理论基础。
理解这些理论基础，对于我们有效地设计、使用和优化关系数据库至关重要。
关系数据库的核心概念是关系，也就是通常所说的表。
一个关系由一组属性（列）和一组元组（行）组成。
每个属性都有特定的数据类型，例如整数、字符串、日期等。
而元组则代表了一条具体的数据记录。
关系数据库遵循一系列的约束和规则，以确保数据的完整性和准确性。
其中，实体完整性是指主键的值不能为空且必须唯一，用于唯一标识每一条记录。
例如，在一个学生信息表中，学号通常被设定为主键，每个学生的学号都不能重复且不能为空。
参照完整性则规定了表之间的关联关系。
如果存在两个表通过某个字段相关联，那么在相关联的表中，对应的值必须存在或者为空。
比如，一个课程表和一个选课表，选课表中的课程编号必须在课程表中存在，否则就违反了参照完整性。
关系代数是关系数据库操作的理论基础。
它包括了选择、投影、连接、并、交、差等基本运算。
选择操作类似于筛选，根据给定的条件从关系中选取满足条件的元组。
投影则是从关系中选取指定的属性列。
连接操作用于将两个或多个关系根据共同的属性值组合在一起。
函数依赖是关系数据库设计中的一个重要概念。
如果属性 A 的值决定了属性 B 的值，那么就说 B 函数依赖于 A。
例如，一个订单表中，订单号决定了订单日期，那么就可以说订单日期函数依赖于订单号。
范式是关系数据库设计的重要指导原则。
常见的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求每个属性都是不可再分的原子值。
第二范式在满足第一范式的基础上，要求非主键属性完全依赖于主键，而不能仅依赖于主键的一部分。
第三范式则进一步要求非主键属性之间不存在传递依赖。
满足更高的范式可以减少数据冗余，提高数据的一致性和完整性，但并不是范式越高就一定越好。
在实际应用中，需要根据具体的业务需求和性能要求来权衡范式的级别。
数据库原理及应用课后答案第4章关系数据库设计理论
真诚为您提供优质参考资料，若有不当之处，请指正。
第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章关系数据库(RDB)规范化设计理论
3. 完全函数依赖与部分函数依赖
完全函数依赖： 在关系模式R(U)中，如果X→Y，并且对于X的任何一 个真子集X′，都有X′ Y，则称Y完全函数依赖于X， 记作X f Y。 部分函数依赖： 若X→Y，但Y不完全函数依赖于X，则称Y部分函数依 p Y。 赖于X，记作X
例8： 学生(学号，姓名，所在系，系主任姓名，课程号，成绩) 学生关系模式存在的部分函数依赖： p (学号，课程号) 姓名 p 所在系 (学号，课程号) p (学号，课程号) 系主任姓名
教师姓 名
李林 78号
住址
课程号
C1
课程名
N1
李林
李林 汪佳 吴仪
78号
78号 59号 79号
C2
C3 C4 C5
N2
N3 N4 N5
师帆
76号
C6
N6
⑷当执行数据插入时，DB中的数据不能产生插入 异常现象 所谓“插入异常”是指希望插入的信息由于不 能满足数据完整性的某种要求而不能正常地被 插入到DB中的异常问题。 比如:上例中插入一个尚未安排授课的新进教师 信息. 原因： 因多种信息混合放在一个表中，可能造成因一 种信息被捆绑在其他信息上而产生的信息之间 相互依附存储的问题，使得信息不能独立插入。
第4章
关系数据库(RDB)规范化理论
4.1 关系模式规范化的必要性 4.2 数值依赖 4.3 范式与规范化 、关系分解原则
RDB规范化理论的目的是要设计“好的”RDB模式。要设计 好的关系模式，必须是关系满足一定的约束条件，此约束 形成了规范。 范式(Normal Form)：衡量DB规范的层次或深度，DB规范化 层次由范式来决定。简记作NF. 根据关系模式满足的不同性质和规范化的程度，将关系模 式分为第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、 BC范式、第四范式(4NF)、第五范式(5NF)，范式越高规范 化程度越高。 规范化：低级关系模式通过模式分解转换为若干高级范式 的关系模式集合的过程。 规范化是在RDB中减少数据冗余的过程。
关系数据库设计理论(关系模式、函数依赖、范式)
函数依赖关系是属性间的一种多对一的关系。 函数依赖关系是属性间的一种多对一的关系。 如果X →Y， X←Y， 是一对一关系。 如果X →Y，且X←Y，则X和Y是一对一关系。
如学号与身份证号。 如学号与身份证号。
7.2
函数依赖
SQL Server 2000
三、函数依赖的几种特例
1、平凡函数依赖与非平凡函数依赖 、 如果X→Y， 如果X→Y，且Y X→Y 若Y 由于Y 由于Y 称为非平凡函数依赖。 X，则X→Y 称为非平凡函数依赖。
7.1
关系模式的评价
SQL Server 2000
教学（学号，姓名，年龄，系名，系主任，课程名，成绩） 教学（学号，姓名，年龄，系名，系主任，课程名，成绩）
学号 98001 98001 98002 98002 98003 98003 99001 姓名 李华 李华 张平 张平 陈兵 陈兵 陆莉 年龄 21 21 22 22 21 21 23 系名 计算机 计算机 计算机 计算机 数学 数学 物理 系主任 王民 王民 王民 王民 赵敏 赵敏 王珊 课程名 C语言 高等数学 C语言 高等数学 高等数学 离散数学 普通物理 成绩 90 80 65 70 95 75 85
7.1
关系模式的评价
SQL Server 2000
对于有问题的关系模式， 对于有问题的关系模式，可以通过模式分解的方法使之 规范化， 规范化，上述关系模式如果分解为如下三个关系则可以克服 以上出现的问题。 以上出现的问题。 学生（学号，姓名，年龄，系名） 学生（学号，姓名，年龄，系名） 系（系名，系主任） 系名，系主任） 选课（学号，课程名，成绩） 选课（学号，课程名，成绩） 如何分解关系模式，分解的依据是什么？ 如何分解关系模式，分解的依据是什么？下二节将讨论 这些问题。 这些问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第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个属性分别为学生姓名、教师姓名、课程名和成绩。