数据库的一二三范式
数据库(第一范式,第二范式,第三范式)
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。
范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。下面就简单介绍下这三个范式。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
什么是数据库三大范式，它们是做什么的？
什么是数据库三⼤范式，它们是做什么的？设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越⾼的范式数据库冗余越⼩。
关系数据库有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，⼜称完美范式）。
满⾜最低要求的范式是第⼀范式（1NF）。
在第⼀范式的基础上进⼀步满⾜更多规范要求的称为第⼆范式（2NF），其余范式以次类推。
⼀般来说，数据库只需满⾜第三范式(3NF）就⾏了。
1、第⼀范式（1NF）：所谓第⼀范式（1NF）是指在关系模型中，对于添加的⼀个规范要求，所有的域都应该是原⼦性的，即数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第⼀范式（1NF）表中的每个域值只能是实体的⼀个属性或⼀个属性的⼀部分。
简⽽⾔之，第⼀范式就是⽆重复的域。
2、第⼆范式（2NF）在1NF的基础上，⾮码属性必须完全依赖于候选码（在1NF基础上消除⾮主属性对主码的部分函数依赖）第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。
第⼆范式（2NF）要求数据库表中的每个实例或记录必须可以被唯⼀地区分。
选取⼀个能区分每个实体的属性或属性组，作为实体的唯⼀标识。
例如在员⼯表中的⾝份证号码即可实现每个⼀员⼯的区分，该⾝份证号码即为候选键，任何⼀个候选键都可以被选作主键。
在找不到候选键时，可额外增加属性以实现区分，如果在员⼯关系中，没有对其⾝份证号进⾏存储，⽽姓名可能会在数据库运⾏的某个时间重复，⽆法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。
（该主键的添加是在ER设计时添加，不是建库时随意添加），第⼆范式（2NF）要求实体的属性完全依赖于主关键字。
范式间区别
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
选课关系：SelectCourse(学号, 课程名称, 成绩)。
stuቤተ መጻሕፍቲ ባይዱent2(sno,sname,age,sex,class)
---------------------------------
class(class,department)
-----------------------
所以关系模式student 可分解成 4个3NF的关系模式student2 ,class ,course,sc
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
其实范式是关系型数据的基本知识.
1Nf--第1范式就是没有表中有表,即二维表就可以了
2Nf--第2范式就是表中没有重复列.
3Nf--第3范式就是没有传递依赖,表中所有列都函数依赖于主关键字.(比如,表a(ID,sum1,Sid,a1),表b(Sid,a1)例子中ID为表a的关键字,Sid为表b的关键字.
关系数据库的规范化之第一范式、第二范式、第三范式以及BC范式
关系数据库的规范化之第⼀范式、第⼆范式、第三范式以及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没有关系，此时对于数据库的使⽤会存在影响，所以要消除这种部分函数依赖的情况。
消除了这种部分函数依赖关系后，所得到的两个关系中⾮主属性完全依赖于码，这种规范称为第⼆范式。
简述数据库设计3个范式的含义
数据库设计是指按照特定的规范和要求，对数据库的数据存储和管理进行规划和设计的过程。
数据库设计的三个范式是指数据库设计中的基本规范，其中第一范式（1NF）、第二范式（2NF）和第三范式（3NF）分别规定了数据库中的数据应该满足的标准和要求。
下面我们将简要介绍数据库设计的三个范式的含义。
一、第一范式（1NF）1. 第一范式是指数据库表中的所有字段都是不可再分的最小单元，即每个数据项都是不可再分的，不能再被分割为更小的数据项。
2. 数据库表中的每一列都是单一的值，不可再分。
3. 所有的字段都应该是原子性的，即不能再分。
4. 如果数据库表中的字段不满足第一范式的要求，就需要进行适当的调整和修改，使之满足第一范式的要求。
二、第二范式（2NF）1. 第二范式是指数据库表中的所有非主属性都完全依赖于全部主键。
2. 所谓主属性是指唯一标识一个记录的属性，而非主属性是指与主键相关的其他属性。
3. 如果一个表中的某些字段与主键没有直接关系，而是依赖于其他字段，则需要将这些字段拆分到另一个表中。
4. 通过将非主属性与主键分离，可以避免数据冗余和更新异常。
5. 第二范式要求数据库表中的数据项应该是唯一的，不可再分，且完全依赖于全部主键。
三、第三范式（3NF）1. 第三范式是指数据库表中的所有字段都不依赖于其他非主字段。
2. 也就是说，一个表中的字段之间应该相互独立，不应该存在字段之间的传递依赖关系。
3. 如果一个字段依赖于其他非主字段，则应该将其拆分到另一张表中，以避免数据冗余和更新异常。
4. 第三范式要求数据库表中的字段之间应该是独立的，不应该存在传递依赖关系。
数据库设计的三个范式分别规范了数据库表中数据的原子性、依赖性和独立性。
遵循这些范式可以有效地减少数据冗余和更新异常，提高数据库的数据完整性和稳定性。
在进行数据库设计时，设计人员应该严格遵循这些范式的要求，以确保数据库的高效性和可靠性。
众所周知，数据库设计的三个范式是设计和维护关系型数据库时非常重要的标准和指导原则。
数据库 第一范式,第二范式和第三范式
数据库第一范式,第二范式和第三范式
数据库是以某种数据模型为基础，组织数据的集合。
而数据库范式是指满足不同依赖
关系的要求。
目前有多种范式，其中较为常见的是第一范式、第二范式和第三范式，其分
别对数据集的性质进行了不同程度的要求，下面我们详细介绍这三种范式。
一、第一范式（1NF）
第一范式是所有范式中最基本且最重要的一种。
它要求数据库中的每个字段都是原子
性的，即每个字段只包含一个数据。
如果一个字段包含多个数据，则应该将其拆分成多个
字段。
这样可以方便数据的管理和维护，而且还能保证数据的唯一性，避免冗余数据。
例如，如果有一个学生表，包含了学生姓名和所选课程，如果一条记录中同时包含多
个课程，则应该将其拆分成多个记录，每个记录只包含一个课程。
第二范式是在第一范式的基础上进一步规范化的范式。
它要求数据库中的表必须满足
如下两个条件：
1.表的每个非主键字段必须完全依赖于主键。
2.表中不能存在部分依赖关系。
这样可以使得数据库表结构更加规范，同时也可以避免数据的冗余，提高数据的存取
效率。
例如，如果有一个订单表，包含了订单号、商品名、商品数量和单价四个字段。
其中，订单号是主键，商品名是非主键字段。
如果一个商品对应多个单价，则存在部分依赖关系。
这种情况下，应该将商品名和单价分别存储在两个表中，建立一对多的关系。
总的来说，不同的范式适用于不同的业务需求。
正确使用范式可以规范化数据，提高
数据管理的效率，同时也会降低数据冗余的程度，避免数据的不一致性。
三大范式
数据库设计三大范式为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。
在关系型数据库中这种规则就称为范式。
范式是符合某一种设计要求的总结。
要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个：1．第一范式(确保每列保持原子性)第一范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。
比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。
但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。
这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2．第二范式(确保表中的每列都和主键相关)第二范式在第一范式的基础之上更进一层。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。
订单信息表这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。
这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。
所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。
如下所示。
这样设计，在很大程度上减小了数据库的冗余。
如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。
数据库三大范式通俗解释
数据库三⼤范式通俗解释⼀、三⼤范式通俗解释：（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）修正：学⽣表：学号，姓名，年龄，所在学院；学院表：学院，电话⼀范式就是属性不可分割。
属性是什么？就是表中的字段。
不可分割的意思就按字⾯理解就是最⼩单位，不能再分成更⼩单位了。
这个字段只能是⼀个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合⼀范式。
不过能不能分割并没有绝对的答案，看需求，也就是看你的设计⽬标⽽定。
举例：学⽣信息组成学⽣信息表，有姓名、年龄、性别、学号等信息组成。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库的一二三范式
数据库的一二三范式是关系数据库设计中的重要概念，它们是用来规范数据库表的结构，确保数据的一致性和完整性。
本文将分别介绍一二三范式的定义和应用。
一范式（1NF）：消除重复的数据
一范式要求数据库表的每个字段都是原子性的，即不可再分。
也就是说，一个字段不能包含多个值。
如果一个字段需要包含多个值，就需要将其拆分成多个独立的字段。
这样可以避免数据冗余和更新异常。
例如，我们有一个学生表，其中的一个字段是“课程”，如果一个学生选修了多门课程，我们可以将“课程”字段拆分成多个字段，比如“课程1”，“课程2”等。
二范式（2NF）：消除非主属性对主键的部分依赖
二范式要求数据库表中的非主属性都完全依赖于主键，而不是依赖于主键的一部分。
如果一个表存在非主属性对主键的部分依赖，就需要将其拆分成多个表，以消除数据冗余和更新异常。
例如，我们有一个订单表，其中的字段有“订单号”、“产品名称”、“产品价格”和“产品数量”。
订单号是主键，产品名称、产品价格和产品数量都依赖于订单号。
但是，产品名称和产品价格
之间存在函数依赖关系，即产品名称确定了产品价格。
为了满足二范式，我们可以将产品名称和产品价格拆分成一个独立的表。
三范式（3NF）：消除传递依赖
三范式要求数据库表中的非主属性不依赖于其他非主属性，而是直接依赖于主键。
如果一个表存在传递依赖，就需要将其拆分成多个表，以消除数据冗余和更新异常。
例如，我们有一个员工表，其中的字段有“员工号”、“员工姓名”、“部门号”和“部门名称”。
员工号是主键，员工姓名依赖于员工号，部门名称依赖于部门号。
但是，员工姓名和部门名称之间存在传递依赖，即员工号确定了部门号，部门号确定了部门名称。
为了满足三范式，我们可以将部门名称拆分成一个独立的表。
总结：
数据库的一二三范式是关系数据库设计中的基本规范，用于规范数据库表的结构，保证数据的一致性和完整性。
一范式消除重复的数据，二范式消除非主属性对主键的部分依赖，三范式消除传递依赖。
通过遵循这些范式，可以设计出高效、可靠的数据库结构。
当然，范式并不是银弹，有时候为了提高查询性能或满足特定需求，可能需要违反范式的原则。
在实际应用中，需要根据具体情况进行权衡和选择。
但是，在大多数情况下，遵循一二三范式是设计关系数据库的良好实践，可以提高数据管理和查询的效率，减少数据冗
余和更新异常的风险。
通过本文的介绍，相信读者对数据库的一二三范式有了更加清晰的理解。
在实际的数据库设计和开发过程中，遵循范式的原则可以帮助我们设计出高效、可靠的数据库结构，提高数据管理和查询的效率。
同时，我们也要注意在特定情况下适度违反范式的原则，以满足实际需求。