关系型数据库设计范式
关系数据库 范式
关系数据库范式
关系数据库范式是一种用于设计关系数据库的规则和标准，以确保数据的一致性、完
整性和有效性。主要目的是减少数据冗余和数据维护的复杂性，从而提高数据库的性能和
可靠性。
在关系数据库中，范式共有6个阶段，分别为第一范式（1NF）、第二范式（2NF）、
第三范式（3NF）、巴斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
第一范式（1NF）：属性不可分
第一范式指任何一个关系模式的所有属性都是不可分的原子值，也就是属性的值都不
能再细分成更小的部分。
例如，一个表中的地址字段，可以将其拆分为街道、城市、州和邮政编码等多个部分，但是在1NF中，这些部分都必须被当做单独的属性来存储。
第二范式（2NF）：满足1NF的基础上，消除部分依赖
第二范式指任何非主键属性都必须完全依赖于主键，也就是非主键属性不能只依赖于
主键的一部分。
例如，一个订单表中的商品名称、商品价格和商品数量，都必须依赖于唯一的订单编
号（主键），而不能只依赖于日期等其他属性。如果存在部分依赖，需要对表进行拆分。
例如，一个客户和订单表中，一个客户可以下多个订单，但是每个订单只能对应一个
客户。如果将客户的联系方式和收货地址存储在订单表中，就会出现多值依赖的问题。因此，需要对表进行拆分。
第五范式（5NF）：尽量避免冗余
第五范式指关系模式中的数据不能通过拆分为更小的关系模式来避免冗余数据。
例如，一个图书馆书籍表中，如果将每个书籍作者的个人信息存储在作者表中，就会
出现多次重复的数据。因此，需要将重复的数据存储在单独的表中，并通过关联方式进行
关系数据库的规范化之第一范式、第二范式、第三范式以及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）删除异常此处对该四个缺点不进⾏详细描述
关系型数据库设计原则与方法
关系型数据库设计原则与方法
关系型数据库设计是一种常见的数据库设计方法，它的设计原则和方法可以用于设计和优化关系型数据库模式。本文将介绍关系型数据库设计的五个基本原则和一些常用的方法，以帮助您更好地进行数据库设计和优化。
第一原则：数据分离原则
数据分离原则是指将不同的数据类型分开存储，不混杂在同一个表中。这个原则主要是考虑到数据的规范性和易维护性。每个数据类型都应该有自己的表，通过相关字段建立关联，并通过外键实现关系。这种设计方式使数据库的结构更清晰、规范，也方便日后对数据更新和查询。
第二原则：范式设计原则
范式设计原则是关系型数据库设计中的核心概念。它主要是通过分解数据，将重复的数据避免在表中出现，减少冗余和更新异常。范式的级别分为一到五级，分别用1NF、2NF、3NF、BCNF、4NF和5NF表示。一般来说，我们在设计数据库时应尽可能遵循更高级别的范式，以减少数据冗余和保证数据的一致性。
第三原则：主键设计原则
主键是一种唯一标识数据记录的方式，它在关系型数据库中非常重要。主键的设计要符合以下要求：
1. 唯一性：每个记录的主键值是唯一的，确保数据的完整性和一致性。
2. 稳定性：主键的值应该是稳定不变的，不能频繁修改。
3. 简洁性：主键的值应该是简洁的，便于查询和索引。
常见的主键类型包括自增主键，UUID，日期时间等。
第四原则：索引设计原则
索引在关系型数据库中起着加速查询和提高性能的作用。但是过多或不恰当的
索引设计可能会导致数据库性能下降。索引的设计原则包括：
1.覆盖索引：将索引包含需要查询的字段，减少数据库访问次数。
简述数据库设计3个范式的含义
数据库设计是指按照特定的规范和要求，对数据库的数据存储和管理进行规划和设计的过程。数据库设计的三个范式是指数据库设计中的基本规范，其中第一范式（1NF）、第二范式（2NF）和第三范式（3NF）分别规定了数据库中的数据应该满足的标准和要求。下面我们将简要介绍数据库设计的三个范式的含义。
一、第一范式（1NF）
1. 第一范式是指数据库表中的所有字段都是不可再分的最小单元，即每个数据项都是不可再分的，不能再被分割为更小的数据项。
2. 数据库表中的每一列都是单一的值，不可再分。
3. 所有的字段都应该是原子性的，即不能再分。
4. 如果数据库表中的字段不满足第一范式的要求，就需要进行适当的调整和修改，使之满足第一范式的要求。
二、第二范式（2NF）
1. 第二范式是指数据库表中的所有非主属性都完全依赖于全部主键。
2. 所谓主属性是指唯一标识一个记录的属性，而非主属性是指与主键
相关的其他属性。
3. 如果一个表中的某些字段与主键没有直接关系，而是依赖于其他字段，则需要将这些字段拆分到另一个表中。
4. 通过将非主属性与主键分离，可以避免数据冗余和更新异常。
5. 第二范式要求数据库表中的数据项应该是唯一的，不可再分，且完
全依赖于全部主键。
三、第三范式（3NF）
1. 第三范式是指数据库表中的所有字段都不依赖于其他非主字段。
2. 也就是说，一个表中的字段之间应该相互独立，不应该存在字段之
间的传递依赖关系。
3. 如果一个字段依赖于其他非主字段，则应该将其拆分到另一张表中，以避免数据冗余和更新异常。
4. 第三范式要求数据库表中的字段之间应该是独立的，不应该存在传
数据库关系模式范式
数据库关系模式范式
关系模型满⾜的确定约束条件称为范式，根据约束条件级别不同从低到⾼分为以下六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，⼜称完美范式）。六种范式⼀种⽐⼀种更加严格，满⾜某⼀种范式也要满⾜其前⾯所有范式。
越⾼的范式数据库冗余越⼩，⼀般数据库设计达到3NF就⾜够了。3NF的关系模型已经能消除冗余和各种异常情况，得到⽐较满意的效果。
第⼀范式（1NF）通俗的讲就是⽆重复的域。
例：表A(b,c,d,d) 属性d有重复则不满⾜第⼀范式。删除重复属性表A(b,c,d)，则满⾜。
第⼆范式（2NF）在第⼆范式的基础上，属性完全依赖主键。
学号，姓名，年龄，课程名，学分，成绩），这张表的主键是学号，但是成绩属性不能通过主键直接取得，同时依赖于课程名。所以不符合属性完全依赖主键要求，所以不例：学⽣表（学号
满⾜第⼆范式。
学号，课程名
课程名，成绩）即可。
课程名，学分）选课表（学号
学号，姓名，年龄）课程表（课程名
上述表要改成：学⽣表（学号
第三范式（3NF）在第⼆范式的基础上，任何⾮主属性不依赖于其它⾮主属性，即任何⾮主属性不得传递依赖于主属性。
学号，姓名，年龄，专业名，专业介绍），课程介绍是依赖于⾮主属性课程名，这样会造成数据冗余，所以不符合第三范式。
例：学⽣表（学号
学号，姓名，年龄，专业名）专业表（专业名
专业名，专业介绍）
上述表改成：学⽣表（学号
范式的优点主要是减少数据冗余，节约存储空间，来加快数据库操作的速度。但有时候完全规范的数据库会造成需要更多的连接，从⽽影响到查询速度。
数据库设计中的四个范式
数据库设计中的四个范式
在创建⼀个数据库的过程中，必须依照⼀定的准则，这些准则被称为范式，从第⼀到第六共六个范式，⼀般数据库设计只要遵循第⼀范式，第⼆范式，和第三范式就⾜够了。满⾜这些规范的数据库是简洁的、结构明晰的，同时，不会发⽣插⼊（insert）、删除（delete）和更新（update）操作异常。反之则是乱七⼋糟，不仅给数据库的编程⼈员制造⿇烦，⽽且⾯⽬可憎，可能存储了⼤量不需要的冗余信息。
I、关系数据库设计范式介绍
1.1 第⼀范式（1NF）⽆重复的列
所谓第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项，同⼀列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。在第⼀范式（1NF）中表的每⼀⾏只包含⼀个实例的信息。简⽽⾔之，第⼀范式就是⽆重复的列。
说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
笔者⽈：就是在⼀个不需要设⽴主键就能表中保证每⼀⾏都具有唯⼀性。不设⽴主键就能保证⾏唯⼀性的表就是第⼀范式。
1.2 第⼆范式（2NF）属性完全依赖于主键
第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。第⼆范式
（2NF）要求数据库表中的每个实例或⾏必须可以被惟⼀地区分。为实现区分通常需要为表加上⼀个列，以存储各个实例的惟⼀标识。例如员⼯信息表中加上了员⼯编号（emp_id）列，因为每个员⼯的员⼯编号是惟⼀的，因此每个员⼯可以被惟⼀区分。这个惟⼀属性列被称为主关键字或主键、主码。
数据库三大范式详解
数据库三大范式详解
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（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选作主键。（该主键的添加时在ER设计时添加，不是建库是随意添加）
数据库管理系统中的关系模型与范式
数据库管理系统中的关系模型与范式数据库管理系统（Database Management System，简称DBMS）是
一种用于管理和组织数据库的软件系统。在数据库设计中，关系模型
和范式是非常重要的概念。关系模型是描述数据之间关系和约束的理
论基础，范式则是用来规范关系的组织结构，以提高数据库的性能和
可维护性。
一、关系模型（Relational Model）
关系模型是由埃德加·科德提出的一种描述数据之间关系的理论模型。它采用了二维表格的形式，将数据组织为若干个表（关系），每个表
由若干个属性（列）组成，每行记录表示一个实体（元组）。
关系模型中的关系以关系键（Primary Key）来标识，它是用于唯一
标识一条记录的属性或属性组合。关系还可以通过外键（Foreign Key）来建立表与表之间的联系，从而形成数据库的整体结构。
二、数据库范式（Database Normalization）
数据库范式是用来规范关系的组织结构，以减少数据冗余、提高数
据库性能和减少数据更新异常的一种方法。目前，已经定义了一系列
的范式，例如第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
1. 第一范式（1NF）要求关系中的每个属性都是不可再分的基本数
据项，即属性不能再分为更小的数据项。同时，每个属性的取值都是
不可重复的，保证了每个属性的原子性和唯一性。
2. 第二范式（2NF）要求关系中的非键属性必须完全依赖于整个关
系的键，而不能依赖于键的一部分。通过将非键属性分割成新的关系，可以消除部分数据冗余。
3. 第三范式（3NF）要求关系中的非键属性必须直接依赖于关系的键，而不能依赖于其他非键属性。通过进一步分解关系，可以消除更
详解第一范式、第二范式、第三范式、BCNF范式
详解第⼀范式、第⼆范式、第三范式、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中的设计：
数据库范式例题
数据库范式例题
范式是一种关系型数据库设计的规范，它是通过对表结构进行优化来消除冗余数据、提高数据存储和操作的效率的。常见的数据库范式有1NF、2NF、3NF等。
以下是一个例题：
假设我们有一个学生信息表，包含以下字段：
- 学生编号（Student_ID）
- 姓名（Name）
- 性别（Gender）
- 年龄（Age）
- 班级编号（Class_ID）
- 班级名称（Class_Name）
- 班主任姓名（Teacher_Name）
这个表中存在冗余数据，比如班级编号、班级名称和班主任姓名都与班级相关，而不是与学生本身相关。因此，可以使用范式将这个表优化为更好的结构。
首先，我们可以使用第一范式（1NF）来消除重复的数据，把表分成两个表：学生表和班级表。
学生表包含以下字段：
- 学生编号（Student_ID）
- 姓名（Name）
- 性别（Gender）
- 年龄（Age）
- 班级编号（Class_ID）
班级表包含以下字段：
- 班级编号（Class_ID）
- 班级名称（Class_Name）
- 班主任姓名（Teacher_Name）
接下来，我们可以使用第二范式（2NF）来消除部分依赖，即确保每个非主键字段完全依赖于主键。在学生表中，班级名称和班主任姓名都只与班级相关，因此我们可以把它们从学生表中移除，放到班级表中。
最后，我们使用第三范式（3NF）来消除传递依赖，即确保每个非主键字段都不依赖于其他非主键字段。在班级表中，班主任姓名只与班级编号相关，而不是与班级名称相关，因此我们可以把班主任姓名从班级表中移到另一个表中。
数据库四范式
数据库四范式
一、引言
数据库设计是构建一个高效、可靠的数据库系统的重要步骤。为了确保数据库的数据一致性、完整性和可维护性，数据库设计需要遵循一定的规范和范式。本文将介绍数据库设计中的四个范式，即第一范式、第二范式、第三范式和BCNF范式，并详细阐述每个范式的定义、特点和应用场景。
二、第一范式（1NF）
第一范式是数据库设计中最基本的范式，它要求数据库中的每个属性都是原子的，即不可再分。具体来说，每个属性不能包含多个值或多个属性。
例如，一个存储员工信息的表，每个员工可能有多个电话号码。若将电话号码作为一个属性，那么该属性就不符合第一范式。正确的做法是将电话号码拆分成多个属性，每个属性只存储一个电话号码。第一范式的优点是数据结构清晰，易于维护和查询。但由于要求属性为原子性，可能会导致数据冗余和查询效率低下。
三、第二范式（2NF）
第二范式在第一范式的基础上，进一步要求非主属性完全依赖于主键。即数据库中的每个非主属性都必须完全依赖于主键，而不能部分依赖于主键。
例如，一个存储订单信息的表，主键是订单号和商品编号。若在该表中添加了一个非主属性“商品名称”，该属性只与商品编号有关，而与订单号无关。这样的设计就不符合第二范式。正确的做法是将商品名称作为一个单独的实体，与订单表通过商品编号进行关联。
第二范式的优点是消除了部分依赖，减少了数据冗余，提高了数据存储和查询的效率。但可能会导致表之间的关联查询增多，增加了数据库的复杂度。
四、第三范式（3NF）
第三范式在第二范式的基础上，进一步要求非主属性之间不存在传递依赖。即数据库中的每个非主属性都只依赖于主键，而不依赖于其他非主属性。
数据库设计基础知识关系数据库设计范式和冗余处理
数据库设计基础知识关系数据库设计范式和
冗余处理
数据库设计基础知识：关系数据库设计范式和冗余处理
数据库是现代信息系统中的重要组成部分，它用于存储和管理大量
的数据，保证数据的可靠性和高效性。在数据库设计中，关系数据库
设计范式和冗余处理是两个重要的方面。本文将对这两个主题展开讨论。
一、关系数据库设计范式
关系数据库设计范式是指在关系数据库中对数据进行合理分解和组
织的规范。它的目的是消除数据冗余、提高数据存储和查询效率、确
保数据的一致性和完整性。常见的关系数据库设计范式有三范式（3NF）和BC范式（BCNF）。
1. 第一范式（1NF）：要求数据表中的每个字段都是原子性的，即
不可再分解的属性。例如，一个学生表中的姓名字段应该是原子性的，而不是将姓名拆分成姓和名两部分。
2. 第二范式（2NF）：在满足1NF的基础上，要求表中的非主键字
段完全依赖于主键。也就是说，如果一个表的主键是学生ID，那么其
他字段（如姓名、年龄、学校）必须完全依赖于学生ID，而不能部分
依赖。
3. 第三范式（3NF）：在满足2NF的基础上，要求表中的非主键字
段之间不存在传递依赖关系。简单说，就是要消除非主键字段之间的
冗余。
4. BC范式（BCNF）：在满足3NF的基础上，要求表中的每个函
数依赖关系都是自主的。也就是说，对于表中的每个函数依赖关系
A→B，要求A是该表的一个超键。
通过合理地应用关系数据库设计范式，可以提高数据库的规范性和
性能，从而更好地满足用户的需求。
二、冗余处理
冗余是指在数据库中存储了重复的数据，它不仅浪费存储空间，还
数据库设计范式
数据库设计范式
数据库设计范式是指在关系数据库中，通过一定的规则和标准来设计和组织数据库表结构，以保证数据的一致性、完整性和可靠性。在数据库设计中，范式分为一至六个级别，依次递增，每个级别都有特定的规则和要求。本文将介绍和讨论数据库设计范式的概念、各个级别的要求和特点。
一、第一范式（1NF）
第一范式是数据库设计的最基本要求，它要求数据库中的每个属性具有原子性，即属性不能再分解为更小的单元。这意味着每个属性的值都是不可再分的简单类型，不可再细分的部分。这样可以避免数据冗余和重复，提高数据的存储效率和查询效率。
二、第二范式（2NF）
第二范式要求数据库中的每个非主属性都要完全依赖于主键，而不能依赖于主键的一部分。也就是说，表中的每个属性都必须与完整的候选键相关，而不是部分相关。这样可以消除非主属性之间的冗余和数据依赖关系，提高数据库的数据一致性和查询性能。
三、第三范式（3NF）
第三范式要求数据库中的每个非主属性都不传递依赖于主键，即非主属性之间不能相互依赖。如果一个非主属性既依赖于主键，又依赖于另一个非主属性，就会造成数据冗余和更新异常。通过将这种依赖
关系分解成独立的关系表，可以消除冗余、提高数据的一致性和查询
性能。
四、BC范式（BCNF）
BC范式是在第三范式的基础上引入了关键依赖的概念。关键依赖
是指在一个关系表中，如果存在A->B的函数依赖，其中B不是候选键的一部分，那么称关系表不满足BC范式。为了消除关键依赖，可以将关系表进行拆分，建立新的关系表，以保证数据的一致性和更新效率。
五、第四范式（4NF）
怎么判断一二三范式例题
怎么判断一二三范式例题
在关系型数据库设计中，范式是指对关系模式进行规范化的过程。通过范式化可以消除数据冗余，提高数据的有效性和可靠性。
常见的范式有三种：第一范式（1NF）、第二范式（2NF）和第三
范式（3NF）。
二、如何判断一二三范式
1. 第一范式
第一范式是指所有的属性都是原子性的，即属性不可再分。例如，一个学生的姓名和年龄应分成两个属性，而不是一个属性。
2. 第二范式
第二范式是指每个非主属性都完全依赖于主键，而不是部分依赖。例如，如果一个订单编号与订单日期、客户编号、客户姓名、产品编号、产品名称都有关系，那么应将订单编号作为主键，将客户编号和产品编号作为外键，分别与客户和产品表关联。
3. 第三范式
第三范式是指每个非主属性都不依赖于其他非主属性。例如，如果一个员工表中包含员工号、员工姓名、部门号、部门名称、工资等属性，那么应该将部门号和部门名称作为单独的部门表，避免数据冗余。
三、例题
1. 判断是否符合第一范式
一个订单表包含订单号、客户姓名、客户电话、产品名称、产品
单价、购买数量、订单总价。该表是否符合第一范式？
答：该表不符合第一范式，因为客户姓名和客户电话应该分成两个属性。
2. 判断是否符合第二范式
一个员工表包含员工号、员工姓名、部门名称、部门地址、工资等属性。该表是否符合第二范式？
答：该表不符合第二范式，因为部门名称和部门地址与部门号有关系，应该将部门名称和部门地址分成一个单独的部门表。
3. 判断是否符合第三范式
一个订单表包含订单号、客户姓名、产品名称、产品单价、购买数量、订单总价、客户地址等属性。该表是否符合第三范式？
关系数据库中的范式
函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定 属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y
完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属 性组 X 包含超过一个属性的话），X ‘ → Y 不成立，那么我们称 Y 对于 X 完 全函数依赖，记作
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？ ·删除某个系中所有的学生记录 该系的信息不会丢失。——有改进 ·插入一个尚无学生的新系的信息。 因为系表与学生表目前是独立的两张表，所以不影响。——有改进 ·数据冗余更加少了。——有改进
·对于选课表，符合3NF的要求，之前已经分析过了。
根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的 部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的 要求。判断的方法是：
第一步：找出数据表中所有的码。 第二步：根据第一步所得到的码，找出所有的主属性。 第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。 第四步：查看是否存在非主属性对码的部分函数依赖。
所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。
·对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数， 学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在 非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。
数据结构-范式
关系数据库设计之基本规则－－范式构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。3.4.1 第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。3.4.2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。3.4.3 第三范式（3NF）满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关系型数据库设计范式
设计关系型数据库时，为使数据库结构合理，需遵从不同规范，这些规范被称为范式。范式越高，数据库的冗余度就越低。
目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF)和第五范式（5NF，又称完美范式）。
关系型数据库的最低要求是满足第一范式。一般来讲，数据库满足到第三范式就行了。第一范式（1NF）无重复的列
数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性。
在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
第二范式（2NF）属性完全依赖于主键
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
当存在多个主键的时候，才会发生不符合第二范式的情况。比如现在有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式。
如果存在不符合第二范式的情况，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
第三范式（3NF）属性不能传递依赖于主属性（属性不依赖于其它非主键属性）第三范式（3NF）是在第二范式（2NF）的基础上建立起来的，即满足第三范式（3NF）必须先满足第二范式（2NF）。
如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。
第一范式举例
在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS 中设计出不符合第一范式的数据库都是不可能的。
下面举例说明。
例如在某个学生的“电话”属性中填入了“1585858588 025-********”，那么就违反了第一范式。学生电话属性违反了原子性，它还可以再分，分成手机和座机两个属性。
第二范式举例
我们把（学号、姓名、年龄、性别、电话、系别、系办地址、系办电话、课程、学分、成绩）
这些信息放到一个表中，其中“学生学号”和“课程”两个属性是主键。
这样不符合第二范式，出现了属性依赖于部分主键的情况（比如”姓名“只依赖于”学号“，和“课程”属性无关）。
那么违反了第二范式有什么问题呢？下面来分析一下：
数据冗余：同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，“姓名”和“年龄”就重复了m-1次。
更新异常：1）若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
2）假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。
但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
解决方案：
分成三个表：
学生：Student（学号，姓名，年龄，性别，电话，系别，系办地址、系办电话）
课程：Course（课程，学分）
选课关系：SelectCourse（学号，课程，成绩）
第三范式举例
继续看上面改善过了的关系结构。由于Student表只有一个主键“学号”，所以存在如下决定关系：
（学号）→ （姓名，年龄，性别，电话，系别，系办地址、系办电话）
但是还存在下面的决定关系：
（学号）→ (系别）→（系办地点，系办电话）
即存在非关键字段"系办地点"、"系办电话"对关键字段"学号"的传递依赖。它也会存在数据冗余、更新异常、插入异常和删除异常的情况（这里不作分析，可以参照第二范式的分析）。
解决方案：
继续把学生表分成两个表：
学生：（学号，姓名，年龄，性别，电话，系别）
系别：（系别，系办地址，系办电话）