下载文档原格式
关系数据库范式（1NF,2NF,3NF,BCNF）基本概念定义：符合某⼀种级别的关系模式的集合，表⽰⼀个关系内部各属性之间的联系的合理化程度。
关系模式的范式主要有4种，即第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）和BCNF范式。
满⾜这些范式条件的关系模式可以在不同程度上避免冗余问题、插⼊问题、更新问题和删除问题。
符合⾼⼀级范式的设计，必定符合第⼀级范式。
如符合2NF，必定符合1NF。
把⼀个给定关系模式转化为某种范式的过程称为关系范式的规范化过程，简称规范化。
1. 第⼀范式（1NF）关系模式R中每个属性的值域都是不可分的简单数据项的集合，则称这个关系模式为第⼀范式关系模式1NF。
在任何⼀个关系数据库系统中，第⼀范式都是⼀个最基本的要求。
2. 第⼆范式（2NF）定义：关系模式R是1NF的前提下，每⼀个⾮主键属性都完全函数地依赖于R的键，则R成为第⼆范式关系模式2NF。
例如，关系模式TaobaoPucharsedLog(s_id#, date, buyer_id#, buyer_name, buyer_age, seller_id#, seller_age, goods_id#, goods_name, amount), 其中的键为s_id, buyer_id, seller_id, goods_id四个。
就其中的seller_name属性来说，它仅仅依赖于键seller_id, 和其他键没有关系，即⾮主键属性seller_name部分地依赖于键{s_id#, buyer_id#, seller_id#, goods_id#}，因此TaobaoPucharsedLog关系不符合2NF定义，不是2NF，这将导致三个问题：(1)插⼊异常。
插⼊时必须给定键值，如果键值的⼀部分为空，则导致数据⽆法插⼊。
(2)删除异常。
删除某个信息，整个元组就不能存在了，也必须跟着删除，从⽽丢失了其他信息，产⽣了删除异常，即不应删除的信息也删除了。
关系数据库范式
关系数据库范式是一种用于设计关系数据库的规则和标准，以确保数据的一致性、完
整性和有效性。
主要目的是减少数据冗余和数据维护的复杂性，从而提高数据库的性能和
可靠性。
在关系数据库中，范式共有6个阶段，分别为第一范式（1NF）、第二范式（2NF）、
第三范式（3NF）、巴斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
第一范式（1NF）：属性不可分
第一范式指任何一个关系模式的所有属性都是不可分的原子值，也就是属性的值都不
能再细分成更小的部分。
例如，一个表中的地址字段，可以将其拆分为街道、城市、州和邮政编码等多个部分，但是在1NF中，这些部分都必须被当做单独的属性来存储。
第二范式（2NF）：满足1NF的基础上，消除部分依赖
第二范式指任何非主键属性都必须完全依赖于主键，也就是非主键属性不能只依赖于
主键的一部分。
例如，一个订单表中的商品名称、商品价格和商品数量，都必须依赖于唯一的订单编
号（主键），而不能只依赖于日期等其他属性。
如果存在部分依赖，需要对表进行拆分。
例如，一个客户和订单表中，一个客户可以下多个订单，但是每个订单只能对应一个
客户。
如果将客户的联系方式和收货地址存储在订单表中，就会出现多值依赖的问题。
因此，需要对表进行拆分。
第五范式（5NF）：尽量避免冗余
第五范式指关系模式中的数据不能通过拆分为更小的关系模式来避免冗余数据。
例如，一个图书馆书籍表中，如果将每个书籍作者的个人信息存储在作者表中，就会
出现多次重复的数据。
因此，需要将重复的数据存储在单独的表中，并通过关联方式进行
连接。
关系数据库的规范化之第⼀范式、第⼆范式、第三范式以及BC范式 关系数据库设计的⽅法之⼀就是设计满⾜适当范式的模式，通常可以通过判断分解后的模式达到⼏范式来评价模式规范化的程度。
范式有1NF,2NF,3NF,BCNF,4NF,5NF，其中1NF的级别最低。
这⼏种范式之间，5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF成⽴。
通过分解，可以将⼀个低⼀级范式的关系模式转化成若⼲个⾼⼀级范式的关系模式，这个过程为规范化。
下⾯我们来看⼀个栗⼦（好吃），有错误的地⽅希望读者可以提出改正。
供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下： FIRST(Sno,Sname,Status,City,Pno,Qty)（公司编号，名称，状态，城市，产品编号，数量） F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno->Qty)} 可以很明显的看出，该关系中不含有可以再分的数据项（什么是可以再分的数据项？想象⼀张table，不应存在两个相同的字段，即两个相同的数据项。
如果存在了，就说明他有了可以再分的数据项，就不是关系模式的数据库了。
存在了可再分的数据项，就要考虑新增实体，将两个数据项分别放到两个实体上），所以该关系满⾜第⼀范式的条件。
1NF 第⼀范式 定义：若关系模式R的每⼀个分量是不可再分的数据项，则关系模式R属于第⼀范式 第⼀范式有四个缺点：（1）冗余度⼤（2）引起数据修改不⼀致（3）插⼊异常（4）删除异常此处对该四个缺点不进⾏详细描述 当我们使⽤第⼀范式设计数据库的时候，会发现我们以Sno作为主键（码）的时候，不能唯⼀标识⾮主键字段（⾮主属性）Qty，但是⾮主属性Sname，Status却可以被Sno唯⼀标识且和Pno没有关系，此时对于数据库的使⽤会存在影响，所以要消除这种部分函数依赖的情况。
消除了这种部分函数依赖关系后，所得到的两个关系中⾮主属性完全依赖于码，这种规范称为第⼆范式。
数据库设计是指按照特定的规范和要求，对数据库的数据存储和管理进行规划和设计的过程。
数据库设计的三个范式是指数据库设计中的基本规范，其中第一范式（1NF）、第二范式（2NF）和第三范式（3NF）分别规定了数据库中的数据应该满足的标准和要求。
下面我们将简要介绍数据库设计的三个范式的含义。
一、第一范式（1NF）1. 第一范式是指数据库表中的所有字段都是不可再分的最小单元，即每个数据项都是不可再分的，不能再被分割为更小的数据项。
2. 数据库表中的每一列都是单一的值，不可再分。
3. 所有的字段都应该是原子性的，即不能再分。
4. 如果数据库表中的字段不满足第一范式的要求，就需要进行适当的调整和修改，使之满足第一范式的要求。
二、第二范式（2NF）1. 第二范式是指数据库表中的所有非主属性都完全依赖于全部主键。
2. 所谓主属性是指唯一标识一个记录的属性，而非主属性是指与主键相关的其他属性。
3. 如果一个表中的某些字段与主键没有直接关系，而是依赖于其他字段，则需要将这些字段拆分到另一个表中。
4. 通过将非主属性与主键分离，可以避免数据冗余和更新异常。
5. 第二范式要求数据库表中的数据项应该是唯一的，不可再分，且完全依赖于全部主键。
三、第三范式（3NF）1. 第三范式是指数据库表中的所有字段都不依赖于其他非主字段。
2. 也就是说，一个表中的字段之间应该相互独立，不应该存在字段之间的传递依赖关系。
3. 如果一个字段依赖于其他非主字段，则应该将其拆分到另一张表中，以避免数据冗余和更新异常。
4. 第三范式要求数据库表中的字段之间应该是独立的，不应该存在传递依赖关系。
数据库设计的三个范式分别规范了数据库表中数据的原子性、依赖性和独立性。
遵循这些范式可以有效地减少数据冗余和更新异常，提高数据库的数据完整性和稳定性。
在进行数据库设计时，设计人员应该严格遵循这些范式的要求，以确保数据库的高效性和可靠性。
众所周知，数据库设计的三个范式是设计和维护关系型数据库时非常重要的标准和指导原则。
数据库第一范式,第二范式和第三范式
数据库是以某种数据模型为基础，组织数据的集合。
而数据库范式是指满足不同依赖
关系的要求。
目前有多种范式，其中较为常见的是第一范式、第二范式和第三范式，其分
别对数据集的性质进行了不同程度的要求，下面我们详细介绍这三种范式。
一、第一范式（1NF）
第一范式是所有范式中最基本且最重要的一种。
它要求数据库中的每个字段都是原子
性的，即每个字段只包含一个数据。
如果一个字段包含多个数据，则应该将其拆分成多个
字段。
这样可以方便数据的管理和维护，而且还能保证数据的唯一性，避免冗余数据。
例如，如果有一个学生表，包含了学生姓名和所选课程，如果一条记录中同时包含多
个课程，则应该将其拆分成多个记录，每个记录只包含一个课程。
第二范式是在第一范式的基础上进一步规范化的范式。
它要求数据库中的表必须满足
如下两个条件：
1.表的每个非主键字段必须完全依赖于主键。
2.表中不能存在部分依赖关系。
这样可以使得数据库表结构更加规范，同时也可以避免数据的冗余，提高数据的存取
效率。
例如，如果有一个订单表，包含了订单号、商品名、商品数量和单价四个字段。
其中，订单号是主键，商品名是非主键字段。
如果一个商品对应多个单价，则存在部分依赖关系。
这种情况下，应该将商品名和单价分别存储在两个表中，建立一对多的关系。
总的来说，不同的范式适用于不同的业务需求。
正确使用范式可以规范化数据，提高
数据管理的效率，同时也会降低数据冗余的程度，避免数据的不一致性。
数据库范式名词解释
数据库范式是数据库设计中的一种理论，它基于离散数学中的知识，主要为了解决数据存储和优化的问题。
其核心目标是为了减少数据冗余，提高数据的一致性和完整性。
范式包括六种，从低到高依次是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF)和第五范式（5NF，又称完美范式）。
其中，满足最低要求的范式是第一范式（1NF）。
第一范式（1NF）要求在关系模型中，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合、数组、记录等非原子数据项。
如果实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第一范式（1NF）的表中，每个域值只能是实体的一个属性或一个属性的一部分。
简而言之，第一范式就是无重复的域。
数据库范式的主要作用是解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题。
通过应用数据库范式，可以避免数据冗余，减少数据库的存储空间，并降低维护数据完整性的成本。
数据库范式是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。
数据库范式定义数据库范式是数据库设计中的重要概念，它是指将数据库中的数据按照一定的规则进行组织和存储，以达到数据的高效性、一致性和可维护性。
数据库范式通常分为一至五个级别，每个级别都有其特定的规则和要求。
第一范式（1NF）要求每个数据表中的每个字段都是原子性的，即不可再分解。
这意味着每个字段只能包含一个值，而不能包含多个值或者数组。
例如，一个订单表中的“商品列表”字段就不符合1NF，因为它包含了多个商品信息。
为了符合1NF，可以将商品信息拆分成多个字段或者单独建立一个商品表。
第二范式（2NF）要求每个数据表中的非主键字段都必须完全依赖于主键，而不能依赖于主键的一部分。
这意味着每个数据表应该只包含与主键相关的信息。
例如，一个订单表中的“客户地址”字段就不符合2NF，因为它依赖于主键中的“客户ID”字段。
为了符合2NF，可以将“客户地址”字段移动到客户表中。
第三范式（3NF）要求每个数据表中的非主键字段都不能相互依赖，即不能存在传递依赖关系。
这意味着每个数据表应该只包含与主键直接相关的信息。
例如，一个订单表中的“客户电话”字段和“客户邮编”字段就存在传递依赖关系，因为它们都依赖于“客户地址”字段。
为了符合3NF，可以将“客户电话”和“客户邮编”字段移动到客户表中。
BCNF范式要求每个数据表中的非主键字段都不能依赖于非候选键字段。
这意味着每个数据表应该只包含与候选键直接相关的信息。
例如，一个订单表中的“商品价格”字段就不符合BCNF，因为它依赖于“商品名称”字段而不是主键。
为了符合BCNF，可以将“商品价格”字段移动到商品表中。
第五范式（5NF）要求每个数据表中的每个非主键字段都不能存在多值依赖关系。
这意味着每个数据表应该只包含单一的信息。
例如，一个订单表中的“商品评价”字段就存在多值依赖关系，因为它包含了多个评价信息。
为了符合5NF，可以将“商品评价”字段移动到评价表中。
数据库范式是数据库设计中的重要概念，它可以帮助我们规范化数据，提高数据的可靠性和可维护性。
第⼀范式第⼆范式第三范式BC范式第四范式1．第⼀范式(确保每列保持原⼦性)第⼀范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。
⽐如某些数据库系统中需要⽤到“地址”这个属性，本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。
但是如果系统经常会访问“地址”属性中的“城市”部分，那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储，这样在对地址中某⼀部分操作的时候将⾮常⽅便。
这样设计才算满⾜了数据库的第⼀范式，如下表所⽰。
上表所⽰的⽤户信息遵循了第⼀范式的要求，这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便，也提⾼了数据库的性能。
2．第⼆范式(确保表中的每列都和主键相关)第⼆范式在第⼀范式的基础之上更进⼀层。
第⼆范式需要确保数据库表中的每⼀列都和主键相关，⽽不能只与主键的某⼀部分相关（主要针对联合主键⽽⾔）。
也就是说在⼀个数据库表中，⼀个表中只能保存⼀种数据，不可以把多种数据保存在同⼀张数据库表中。
⽐如要设计⼀个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所⽰。
订单信息表这样就产⽣⼀个问题：这个表中是以订单编号和商品编号作为联合主键。
这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，⽽仅仅是与商品编号相关。
所以在这⾥违反了第⼆范式的设计原则。
⽽如果把这个订单信息表进⾏拆分，把商品信息分离到另⼀个表中，把订单项⽬表也分离到另⼀个表中，就⾮常完美了。
如下所⽰。
这样设计，在很⼤程度上减⼩了数据库的冗余。
如果要获取订单的商品信息，使⽤商品编号到商品信息表中查询即可。
3．第三范式(确保每列都和主键列直接相关,⽽不是间接相关)第三范式需要确保数据表中的每⼀列数据都和主键直接相关，⽽不能间接相关。
⽐如在设计⼀个订单数据表的时候，可以将客户编号作为⼀个外键和订单表建⽴相应的关系。
数据库各范式的判定标准
数据库范式是关系型数据库设计中的一种理论，用于确保数据的完整性和减少数据冗余。
以下是常见的数据库范式及其判定标准：
1. 第一范式（1NF）：确保每列保持原子性，即列不能可分。
第一范式的合理遵循需要根据系统的实际需求来定。
2. 第二范式（2NF）：在满足第一范式的基础上，非主键列必须完全依赖于主键，不能只依赖于主键的一部分。
3. 第三范式（3NF）：在满足第二范式的基础上，任何列都不能依赖于其他非主键列。
4. 巴斯-科德范式（BCNF）：在满足第三范式的基础上，任何非主键列都不能依赖于非超键列。
除了以上常见的范式外，还有其他范式，如第四范式、第五范式等，这些范式都是在前三范式的基础上进行了更严格的约束。
在实践中，通常需要满足第三范式，以避免数据冗余和破坏数据的完整性。
然而，在某些情况下，为了提高查询效率，可能会适当地违反某些范式，例如适当的水平或垂直分表等。
因此，在设计数据库时，应该根据实际需求和实际情况进行综合考虑和折中，以满足业务需求的同时保证数据的完整性和减少冗余。
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
范式说明第一范式（1NF）无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
例如，如下的数据库表是符合第一范式的：字段1 字段2 字段3 字段4而这样的数据库表是不符合第一范式的：字段1 字段2 字段3 字段4字段字段数据库表中的字段都是单一属性的，不可再分。
这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。
因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）属性完全依赖于主键[ 消除部分子函数依赖]如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称为第二范式模式。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
详解第⼀范式、第⼆范式、第三范式、BCNF范式什么是”范式(NF)”按照教材中的定义，范式是“符合某⼀种级别的关系模式的集合，表⽰⼀个关系内部各属性之间的联系的合理化程度”。
很晦涩吧？实际上你可以把它粗略地理解为⼀张数据表的表结构所符合的某种设计标准的级别。
就像家⾥装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。
数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。
⼀般在我们设计关系型数据库的时候，最多考虑到BCNF就够。
符合⾼⼀级范式的设计，必定符合低⼀级范式，例如符合2NF的关系模式，必定符合1NF。
接下来就对每⼀级范式进⾏⼀下解释。
1. 第⼀范式（1NF）符合1NF的关系（你可以理解为数据表。
“关系模式”和“关系”的区别，类似于⾯向对象程序设计中”类“与”对象“的区别。
”关系“是”关系模式“的⼀个实例，你可以把”关系”理解为⼀张带数据的表，⽽“关系模式”是这张数据表的表结构。
1NF的定义为：符合1NF的关系中的每个属性都不可再分。
表1所⽰的情况，就不符合1NF的要求。
表1实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作⼀定是不能成功的。
也就是说，只要在RDBMS中已经存在的数据表，⼀定是符合1NF的。
如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2但是仅仅符合1NF的设计，仍然会存在数据冗余过⼤，插⼊异常，删除异常，修改异常的问题，例如对于表3中的设计：表31. 每⼀名学⽣的学号、姓名、系名、系主任这些数据重复多次。
每个系与对应的系主任的数据也重复多次——数据冗余过⼤2. 假如学校新建了⼀个系，但是暂时还没有招收任何学⽣（⽐如3⽉份就新建了，但要等到8⽉份才招⽣），那么是⽆法将系名与系主任的数据单独地添加到数据表中去的（注１）——插⼊异常注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意⼀个属性都不能为空，所有属性的组合也不能重复。
第⼀范式，第⼆范式，第三范式，BCNF范式理解基础知识实体：现实世界中客观存在并可以被区别的事物。
⽐如“⼀个学⽣”、“⼀本书”、“⼀门课”等等。
值得强调的是这⾥所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，⽐如说“⽼师与学校的关系”。
属性：教科书上解释为：“实体所具有的某⼀特性”，由此可见，属性⼀开始是个逻辑概念，⽐如说，“性别”是“⼈”的⼀个属性。
在关系数据库中，属性⼜是个物理概念，属性可以看作是“表的⼀列”。
元组：表中的⼀⾏就是⼀个元组。
分量：元组的某个属性值。
在⼀个关系数据库中，它是⼀个操作原⼦，即关系数据库在做任何操作的时候，属性是“不可分的”。
否则就不是关系数据库了。
码：表中可以唯⼀确定⼀个元组的某个属性（或者属性组），如果这样的码有不⽌⼀个，那么⼤家都叫候选码，我们从候选码中挑⼀个出来做⽼⼤，它就叫主码。
全码：如果⼀个码包含了所有的属性，这个码就是全码。
主属性：⼀个属性只要在任何⼀个候选码中出现过，这个属性就是主属性。
⾮主属性：与上⾯相反，没有在任何候选码中出现过，这个属性就是⾮主属性。
外码：⼀个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
第⼀范式第⼀范式列不能再分。
第⼆范式第⼆范式建⽴在第⼀范式的基础上，⾮主属性完全依赖于码。
简单说：消除部分依赖。
（什么是码？）表中可以唯⼀确定⼀个元组的某个属性（或者属性组），如果这样的码有不⽌⼀个，那么⼤家都叫候选码，我们从候选码中挑⼀个出来做⽼⼤，它就叫主码。
注意码可以包含多个属性。
要理解第⼆第三范式需要理解完全函数依赖、部分函数依赖、传递函数依赖。
完全函数依赖定义：设X,Y是关系R的两个属性集合，X’是X的真⼦集，存在X→Y，但对每⼀个X’都有X’!→Y，则称Y完全函数依赖于X。
⽐如通过学号->姓名部分函数依赖定义：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真⼦集，存在X’→Y，则称Y部分函数依赖于X。
数据库四范式一、引言数据库设计是构建一个高效、可靠的数据库系统的重要步骤。
为了确保数据库的数据一致性、完整性和可维护性，数据库设计需要遵循一定的规范和范式。
本文将介绍数据库设计中的四个范式，即第一范式、第二范式、第三范式和BCNF范式，并详细阐述每个范式的定义、特点和应用场景。
二、第一范式（1NF）第一范式是数据库设计中最基本的范式，它要求数据库中的每个属性都是原子的，即不可再分。
具体来说，每个属性不能包含多个值或多个属性。
例如，一个存储员工信息的表，每个员工可能有多个电话号码。
若将电话号码作为一个属性，那么该属性就不符合第一范式。
正确的做法是将电话号码拆分成多个属性，每个属性只存储一个电话号码。
第一范式的优点是数据结构清晰，易于维护和查询。
但由于要求属性为原子性，可能会导致数据冗余和查询效率低下。
三、第二范式（2NF）第二范式在第一范式的基础上，进一步要求非主属性完全依赖于主键。
即数据库中的每个非主属性都必须完全依赖于主键，而不能部分依赖于主键。
例如，一个存储订单信息的表，主键是订单号和商品编号。
若在该表中添加了一个非主属性“商品名称”，该属性只与商品编号有关，而与订单号无关。
这样的设计就不符合第二范式。
正确的做法是将商品名称作为一个单独的实体，与订单表通过商品编号进行关联。
第二范式的优点是消除了部分依赖，减少了数据冗余，提高了数据存储和查询的效率。
但可能会导致表之间的关联查询增多，增加了数据库的复杂度。
四、第三范式（3NF）第三范式在第二范式的基础上，进一步要求非主属性之间不存在传递依赖。
即数据库中的每个非主属性都只依赖于主键，而不依赖于其他非主属性。
例如，一个存储学生选课信息的表，主键是学生编号和课程编号。
若在该表中添加了一个非主属性“学生姓名”，该属性依赖于学生编号，而与课程编号无关。
而另一个非主属性“课程教师”依赖于课程编号，而与学生编号无关。
这样的设计就不符合第三范式。
正确的做法是将学生姓名和课程教师分别与学生表和课程表关联。
数据库的范式（1NF、2NF、3NF、BNCF）第⼀范式：关系模式中，每个属性不可再分。
属性原⼦性第⼆范式：⾮主属性完全依赖于主属性，即消除⾮主属性对主属性的部分函数依赖关系。
第三范式：⾮主属性对主属性不存在传递函数依赖关系。
BNCF范式：在第三范式的基础上，消除主属性之间的部分函数依赖第⼀范式（1NF）：在关系模式R中的每⼀个具体关系r中，如果每个属性值都是不可再分的最⼩数据单位，则称R是第⼀范式的关系。
例：如职⼯号，姓名，电话号码组成⼀个表（⼀个⼈可能有多个电话号码）规范成为1NF有三种⽅法： ⼀是重复存储职⼯号和姓名。
这样，关键字只能是电话号码。
⼆是职⼯号为关键字，电话号码分为单位电话和住宅电话两个属性 三是职⼯号为关键字，但强制每条记录只能有⼀个电话号码。
以上三个⽅法，第⼀种⽅法最不可取，按实际情况选取后两种情况。
第⼆范式（2NF）：如果关系模式R（U，F）中的所有⾮主属性都完全依赖于任意候选关键字，则称关系R 是属于第⼆范式的。
例：选课关系 sc（sid，cid，grade，credit）其中sid为学号， cid为课程号，grade为成绩，credit为学分。
由以上条件，关键字为组合关键字（sid，cid）在应⽤中使⽤以上关系模式有以下问题： a.数据冗余，假设同⼀门课由40个学⽣选修，学分就重复40次。
b.更新异常，若调整了某课程的学分，相应的元组credit值都要更新，有可能会出现同⼀门课学分不同。
c.插⼊异常，如计划开新课，由于没⼈选修，没有学号关键字，只能等有⼈选修才能把课程和学分存⼊。
d.删除异常，若学⽣已经结业，从当前数据库删除选修记录。
某些门课程新⽣尚未选修，则此门课程及学分记录⽆法保存。
原因：⾮关键字属性credit仅函数依赖于cid，也就是credit部分依赖组合关键字（sid，cid）⽽不是完全依赖。
解决⽅法：分成两个关系模式sc（sid，cid，grade），c（cid，credit）。
关系模式分解的四个范式的区别在数据库设计中，关系模式分解是将一个关系模式分解为多个关系模式的过程。
范式是评估关系模式分解质量的标准，描述了关系模式的规范化程度。
常见的四个范式是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BC范式（BCNF）。
这四个范式有着不同的要求和特点，下面将分别介绍它们的区别。
1. 第一范式（1NF）第一范式是关系模式分解的最基本要求。
它要求关系模式中的每个属性都是原子的，即不可再分。
在第一范式中，每个属性都应该是一个简单的值，而不是一个集合或多值属性。
例如，如果一个关系模式包含一个“学生”属性，那么它应该是一个单一的值，而不是一个包含多个学生的集合。
2. 第二范式（2NF）第二范式是在满足第一范式的基础上进一步的要求，它要求关系模式中的非主属性完全依赖于主键。
简单来说，非主属性不能部分依赖于主键，必须完全依赖于主键。
为了满足第二范式，需要将非主属性拆分为新的关系模式，并将其与原来的关系模式通过主键进行连接。
3. 第三范式（3NF）第三范式是在满足第二范式的基础上进一步的要求，它要求关系模式中的非主属性不传递依赖于主键。
也就是说，如果一个非主属性依赖于另一个非主属性，而这个非主属性又依赖于主键，那么就违反了第三范式。
为了满足第三范式，需要进一步将非主属性拆分为新的关系模式，并通过外键与原来的关系模式进行连接。
4. BC范式（BCNF）BC范式是在满足第三范式的基础上进一步的要求，它要求关系模式中的所有函数依赖都是由候选键决定的。
函数依赖是指一个属性的值决定其他属性的值的关系。
如果一个关系模式中存在非主属性依赖于非候选键属性的情况，那么就违反了BC范式。
为了满足BC范式，需要将非主属性拆分为新的关系模式，并通过外键与原来的关系模式进行连接。
总结：四个范式是关系模式分解过程中的逐步规范化要求，从第一范式到BC范式，要求逐渐增加。
第一范式要求属性是原子的，第二范式要求非主属性完全依赖于主键，第三范式要求非主属性不传递依赖于主键，BC范式要求所有函数依赖都由候选键决定。
