三大范式定义

三大建表范式
建立数据库时，需要注意数据表的设计，保证数据规范、准确性和一致性。

为此，数据库设计者通常会遵循三大标准化范式，分别是第一范式、第二范式和第三范式。

第一范式要求数据表中的每个字段只包含单一属性值，不可再拆分为更小的属性，这样可以避免数据冗余。

例如，一个学生表中只包含学生的姓名字段，而不再将姓名分为姓和名两个字段。

第二范式要求数据表中的每个非主键字段都必须完全依赖于主键，即每个非主键字段必须与主键相关。

这样可以消除表中的数据冗余。

例如，一个订单表中，订单号是主键，订单日期、客户姓名、地址等字段完全依赖于订单号。

第三范式要求数据表中的每个非主键字段都不应该依赖于其他
非主键字段，而应该直接依赖于主键。

这样可以消除表中的传递依赖关系。

例如，一个学生表中，学生姓名、学生性别、学生班级等字段都应该直接依赖于主键学生编号，而不应该依赖于其他非主键字段。

通过遵循三大标准化范式，数据库设计者可以建立符合规范、准确、一致和易于维护的数据表。

- 1 -。

关系型数据库三⼤范式基础概念：关键字、主关键字、候选关键字,⾮关键字如果某个字段或多个字段的值可以唯⼀地标识⼀条记录，则该字段或字段组就称为关键字。

如果⼀个关键字是⽤以标识每条记录的唯⼀性，并作为该表与其他表实现关联之⽤，则称其为主关键字（主键，primary key）或主码。

除主关键字以外的其他关键字称为候选关键字。

除关键字意外的字称为⾮关键字例如，有⼀个表字段为：id firstname lastname address phone IDcard那么id或IDcard或firstname+lastname（不存在同名的情况下）都可以说是关键字。

其中id为主关键字，IDcard和firstname+lastname为候选关键字。

数据库设计范式第⼀范式(1NF)：数据表中的字都是单⼀属性，不可再分的（原⼦性）。

单⼀属性由基本类型构成，包括整型、实数、字符型、逻辑型、⽇期型等。

在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。

第⼆范式(2NF)：数据表中⾮关键字都不存在对候选关键字的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定⾮关键字段的情况），则符合第⼆范式（完全依赖于主键），也即所有⾮关键字段都完全依赖于任意⼀组候选关键字。

例：假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满⾜第⼆范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定⾮关键字的情况。

由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余： 同⼀门课程由n个学⽣选修，"学分"就重复n-1次；同⼀个学⽣选修了m门课程，姓名和年龄就重复了m-1次。

数据库范式第一第二第三范式的区别
主要是针对数据库来说。

第一范式、第二范式都是针对数据表的，而第三范式针对的则是数据库中的数据模型了。

比如说，在关系型数据库里面，第三范式又称为实体完整性规范化（ Entity Completeness Normatification），即将数据库中的每个数据项，按照某种方法进行组织和存储。

例如，关系型数据库的第一范式，又叫做完全范式，是指所有的表，其字段都具备相同类型的数据值。

在实际应用中，通常使用第一范式设计的数据库管理系统比较简单，因此大多数的数据库开发人员习惯于这样设计他们的系统。

但由于很少考虑用户的特殊需求，致使许多第一范式设计的系统不能满足用户的需要。

也就是说，在第一范式下设计出来的数据库没办法处理各种各样的事务操作。

如何解决这个问题呢？答案就是采用第二范式。

这里所谓的“第二范式”并非指在实体上增加一个额外的范围，而是指改变第一范式中的某些规定以适应新的情况。

一般地讲，采取第二范式后，可以提高数据库的性能。

- 1 -。

数据库设计是指按照特定的规范和要求，对数据库的数据存储和管理进行规划和设计的过程。

数据库设计的三个范式是指数据库设计中的基本规范，其中第一范式（1NF）、第二范式（2NF）和第三范式（3NF）分别规定了数据库中的数据应该满足的标准和要求。

下面我们将简要介绍数据库设计的三个范式的含义。

一、第一范式（1NF）1. 第一范式是指数据库表中的所有字段都是不可再分的最小单元，即每个数据项都是不可再分的，不能再被分割为更小的数据项。

2. 数据库表中的每一列都是单一的值，不可再分。

3. 所有的字段都应该是原子性的，即不能再分。

4. 如果数据库表中的字段不满足第一范式的要求，就需要进行适当的调整和修改，使之满足第一范式的要求。

二、第二范式（2NF）1. 第二范式是指数据库表中的所有非主属性都完全依赖于全部主键。

2. 所谓主属性是指唯一标识一个记录的属性，而非主属性是指与主键相关的其他属性。

3. 如果一个表中的某些字段与主键没有直接关系，而是依赖于其他字段，则需要将这些字段拆分到另一个表中。

4. 通过将非主属性与主键分离，可以避免数据冗余和更新异常。

5. 第二范式要求数据库表中的数据项应该是唯一的，不可再分，且完全依赖于全部主键。

三、第三范式（3NF）1. 第三范式是指数据库表中的所有字段都不依赖于其他非主字段。

2. 也就是说，一个表中的字段之间应该相互独立，不应该存在字段之间的传递依赖关系。

3. 如果一个字段依赖于其他非主字段，则应该将其拆分到另一张表中，以避免数据冗余和更新异常。

4. 第三范式要求数据库表中的字段之间应该是独立的，不应该存在传递依赖关系。

数据库设计的三个范式分别规范了数据库表中数据的原子性、依赖性和独立性。

遵循这些范式可以有效地减少数据冗余和更新异常，提高数据库的数据完整性和稳定性。

在进行数据库设计时，设计人员应该严格遵循这些范式的要求，以确保数据库的高效性和可靠性。

众所周知，数据库设计的三个范式是设计和维护关系型数据库时非常重要的标准和指导原则。

设计范式简介（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。

构造数据库必须遵循一定的规则。

在关系数据库中，这种规则就是范式。

关系数据库中的关系必须满足一定的要求，即满足不同的范式。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。

满足最低要求的范式是第一范式（1NF）。

在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。

一般说来，数据库只需满足第三范式（3NF）就行了。

下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。

这样可能使数据库产生重复数据，从而导致创建多余的表。

范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。

下面是范化的一个例子Customer Item purchased Purchase price------------------------------------------------------------------------Thomas Shirt $40Maria Tennis shoes $35Evelyn Shirt $40Pajaro Trousers $25如果上面这个表用于保存物品的价格，而你想要删除其中的一个顾客，这时你就必须同时删除一个价格。

范化就是要解决这个问题，你可以将这个表化为两个表，一个用于存储每个顾客和他所买物品的信息，另一个用于存储每件产品和其价格的信息，这样对其中一个表做添加或删除操作就不会影响另一个表。

关系数据库的几种设计范式介绍第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

MySQL数据库三⼤范式第⼀范式（1NF） 所谓第⼀范式（1NF）是指在关系模型中，对域添加的⼀个规范要求，所有的域都应该是原⼦性的，即数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。

即实体中的某个属性有多个值时，必须拆分为不同的属性。

在符合第⼀范式（1NF）表中的每个域值只能是实体的⼀个属性或⼀个属性的⼀部分。

简⽽⾔之，第⼀范式就是⽆重复的域。

说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的设计基本要求，⼀般设计中都必须满⾜第⼀范式（1NF）。

不过有些关系模型中突破了1NF的限制，这种称为⾮1NF的关系模型。

换句话说，是否必须满⾜1NF的最低要求，主要依赖于所使⽤的关系模型。

第⼆范式（2NF） 在1NF的基础上，⾮码属性必须完全依赖于候选码（在1NF基础上消除⾮主属性对主码的部分函数依赖。

第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。

第⼆范式（2NF）要求数据库表中的每个实例或记录必须可以被唯⼀地区分。

选取⼀个能区分每个实体的属性或属性组，作为实体的唯⼀标识。

例如在员⼯表中的⾝份证号码即可实现每个⼀员⼯的区分，该⾝份证号码即为候选键，任何⼀个候选键都可以被选作主键。

在找不到候选键时，可额外增加属性以实现区分，如果在员⼯关系中，没有对其⾝份证号进⾏存储，⽽姓名可能会在数据库运⾏的某个时间重复，⽆法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。

（该主键的添加是在ER设计时添加，不是建库时随意添加） 第⼆范式（2NF）要求实体的属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键<字⼀部分的属性，如果存在，那么这个属性和主关键字的这⼀部分应该分离出来形成⼀个新的实体，新实体与原实体之间是⼀对多的关系。

为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。

第⼀范式第⼆范式第三范式BC范式第四范式1．第⼀范式(确保每列保持原⼦性)第⼀范式是最基本的范式。

如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表满⾜了第⼀范式。

第⼀范式的合理遵循需要根据系统的实际需求来定。

⽐如某些数据库系统中需要⽤到“地址”这个属性，本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。

但是如果系统经常会访问“地址”属性中的“城市”部分，那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储，这样在对地址中某⼀部分操作的时候将⾮常⽅便。

这样设计才算满⾜了数据库的第⼀范式，如下表所⽰。

上表所⽰的⽤户信息遵循了第⼀范式的要求，这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便，也提⾼了数据库的性能。

2．第⼆范式(确保表中的每列都和主键相关)第⼆范式在第⼀范式的基础之上更进⼀层。

第⼆范式需要确保数据库表中的每⼀列都和主键相关，⽽不能只与主键的某⼀部分相关（主要针对联合主键⽽⾔）。

也就是说在⼀个数据库表中，⼀个表中只能保存⼀种数据，不可以把多种数据保存在同⼀张数据库表中。

⽐如要设计⼀个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所⽰。

订单信息表这样就产⽣⼀个问题：这个表中是以订单编号和商品编号作为联合主键。

这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，⽽仅仅是与商品编号相关。

所以在这⾥违反了第⼆范式的设计原则。

⽽如果把这个订单信息表进⾏拆分，把商品信息分离到另⼀个表中，把订单项⽬表也分离到另⼀个表中，就⾮常完美了。

如下所⽰。

这样设计，在很⼤程度上减⼩了数据库的冗余。

如果要获取订单的商品信息，使⽤商品编号到商品信息表中查询即可。

3．第三范式(确保每列都和主键列直接相关,⽽不是间接相关)第三范式需要确保数据表中的每⼀列数据都和主键直接相关，⽽不能间接相关。

⽐如在设计⼀个订单数据表的时候，可以将客户编号作为⼀个外键和订单表建⽴相应的关系。

数据库三⼤范式通俗解释⼀、三⼤范式通俗解释：（1）简单归纳： 第⼀范式（1NF）：字段不可分； 第⼆范式（2NF）：有主键，⾮主键字段依赖主键； 第三范式（3NF）：⾮主键字段不能相互依赖。

（2）解释： 1NF：原⼦性。

字段不可再分,否则就不是关系数据库;； 2NF：唯⼀性。

⼀个表只说明⼀个事物； 3NF：每列都与主键有直接关系，不存在传递依赖。

⼆、例⼦说明 （1）不符合第⼀字段的例⼦表：字段1，字段2（字段2.1，字段2.2），字段3字段2可以拆分成字段2.1和字段2.2，不符合第⼀范式。

（2）不符合第⼆范式的例⼦表：学号，姓名，年龄，课程名称，成绩，学分这个表明显说明了两个事务：学⽣信息，课程信息。

1）存在以下问题：a、数据冗余：每条记录都含有相同信息；b、删除异常：删除所有学⽣成绩，就把课程信息全删除了；c、插⼊异常：学⽣未选课，⽆法记录进数据库；d、更新异常：调整课程学分，所有⾏都调整。

2）修正：学⽣表：学号，姓名，年龄课程表：课程名称，学分选课关系表：学号，课程名称，成绩 （3）不符合第⼆范式的例⼦表：学号，姓名，年龄，所在学院，学院联系电话其中关键字为单⼀关键字"学号"。

存在依赖传递:：(学号) → (所在学院) → (学院联系电话) 。

1）存在问题:： a、数据冗余：有重复值； b、更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不⼀致的情况 c、删除异常 2）修正：学⽣表：学号，姓名，年龄，所在学院；学院表：学院，电话⼀范式就是属性不可分割。

属性是什么？就是表中的字段。

不可分割的意思就按字⾯理解就是最⼩单位，不能再分成更⼩单位了。

这个字段只能是⼀个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合⼀范式。

不过能不能分割并没有绝对的答案，看需求，也就是看你的设计⽬标⽽定。

举例：学⽣信息组成学⽣信息表，有姓名、年龄、性别、学号等信息组成。

数据库三大范式详解设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

满足最低要求的范式是第一范式（1NF）。

在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。

一般说来，数据库只需满足第三范式(3NF）就行了。

第一范式（1NF）无重复的列所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

即实体中的某个属性有多个值时，必须拆分为不同的属性。

在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。

简而言之，第一范式就是无重复的域。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。

不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。

换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

第二范式（2NF）属性在1NF的基础上，非码属性必须完全依赖于主键[在1NF基础上消除非主属性对主码的部分函数依赖]第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。

选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。

例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。

在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。

数据库的第一范式第二范式第三范式
在数据库设计中，为了保证数据的完整性和一致性，需要遵循数
据范式。

在数据范式中，第一范式、第二范式和第三范式是最常见和
最重要的范式。

第一范式（1NF）
第一范式是指关系模式中的每个属性都是原子的（即不可再分解的）。

换句话说，每个属性都应该是单值属性，比如一个订单只能有
一个订单号，不能有两个或更多个。

如果属性可以分解为多个属性，
则需要重新设计关系模式以满足第一范式的要求。

第二范式（2NF）
第二范式是指关系模式中的每个非主属性都完全依赖于主键。

非
主属性是指不是唯一标识某个关系记录的属性。

如果存在某些非主属
性只依赖于主键的部分属性，则需要将这些属性分离到新的关系模式中。

第三范式（3NF）
第三范式是指关系模式中的每个非主属性都不依赖于其他非主属性。

如果存在某个非主属性依赖于其他非主属性，则需要将其分离到
新的关系模式中。

总结
遵循第一范式、第二范式和第三范式可以保证数据库的一致性和
准确性。

但是，需要注意的是，过度正规化可能会导致查询性能下降，因此需要在正规化和反规范化之间做出权衡。

同时，在设计数据库时，还需要考虑实际业务需求和数据访问模式，以便优化数据结构和查询
性能。