数据库范式

什么是数据库范式？ 关系数据库的设计规范。不同的规范要求被称为不同的范式，越高的范式数据库冗余越小。 作用？ 减少数据库中数据冗余的过程； 数据库范式 1、第一范式（1NF）： 在关系模式R中，当且仅当所有属性只包含原子值，即每个分量都是不可再分的数据项，则称R满足1NF。 例如表所示的教师职称情况关系就不满足1NF。原因在于，该关系模式中的“高级职称人数”不是一个原子属性，若将其拆分为“教授”和“副教授”两个属性，则就满足1NF。 系名称 高级职称人数 教授 副教授 计算机系 1 2 电子系 3 4 2、第二范式（2NF）： 满足1NF的关系模式会有许多重复值，修改数据可能引起疏漏。为了消除这种数据冗余和避免更新数据的遗漏，需要使用更加规范的2NF。当且仅当关系模式满足1NF，且每个非键属性（既不属于任何候选键的属性，也称为非主属性）完全依赖于候选键时，则称R满足2NF。 例如，有选课关系模式SC(Sno,Cno,Grade,Credit)，其中(Sno,Cno)->Grade,Cno->Credit。因此，SC的候选键为(Sno,Cno)。这样Cno->Credit就构成了Credit对候选键(Sno,Cno)的部分函数依赖。因此，SC不满足2NF。若要将SC转化为2NF，可以将它拆分为SC1(Sno,Cno,Grade)和SC2(Cno,Grade)。 3、第三范式（3NF）

ps：数据库三范式是层层递进的关系 一.数据库第一范式，数据列的原子性，即每一个数据列都应该具有唯一性，场景（1.电话--》如果需求是要公司电话和家庭电话则不符合标准.。 2.物品名称1，物品名称2--》数据列意义重复，应该变为物品名称） 二.数据库第二范式,每一个数据列都应该依赖于主键而存在，（oderid,productid,quntity,productname(1,2联合主键)--》第3列依赖于主键，但第4列只依赖于第2列，所以不符合，所以应该分成两张表（oderid,productid,quntity）（productid,productname）） 三.数据库第三范式,不能存在传递依赖的情况，（oderid,productid,productname(1为主键)--》第3列直接依赖于第2列，间接依赖于主键，虽然符合第二范式，但注意，这里的依赖是间接的！ 来源： CSDN 作者： houxinhong 链接： https://blog.csdn.net/houxinhong/article/details/104129110

数据库设计的范式 范式顾名思义，即 设计数据库时需要遵循的一些规范 。要遵循后边的范式要求，必须遵循前面所有范式的要求。设计关系数据库时，遵从不同的规范要求，设计出合理的关系数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高范式数据库冗余越小。 目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（SNF，又称完美范式） 对于一般的项目，满足前三项就可以了。下面具体介绍前面三项。 1.第一范式（1NF） 每一列都是不可分割的原子数据项 怎么去理解呢？其实不难，简单来说就是，必须是一个能存进去数据库的数据表。 2.第二范式（2NF） 在1NF基础上，非码属性必须完全依赖候选码（在1NF基础上消除非主属性对主码的部分函数依赖） 相关概念： 函数依赖：A–>B,如果通过A属性（属性组）的值，可以唯一确定B属性的值。则称B依赖于A 完全函数依赖：A–>B,如果A是一个属性组，则B属性值的确定依赖于A属性组中所有的属性值。 部分函数依赖： A–>B,如果A是一个属性组，则B属性值的确定只需依赖于A属性组中其中一些的属性值。 传递函数依赖：A–>B,B–>C=>A–>C。如果通过A属性（属性组）的值，可以唯一确定B属性的值，通过B属性（属性组）的值，可以唯一确定C属性的值

关系型数据库三个范式 相关概念 候选关键字 ： ​ 二维表中，能够惟一确定记录的一个字段或几个字段的组合被称为“超关键字”。“超关键字”虽然能唯一确定记录，但是它所包含的字段可能是有多余的。 如果一个超关键字去掉其中任何一个字段后不再能唯一地确定记录，则称它为 候选关键字。候选关键字既能唯一地确定记录，它包含的字段又是最精炼的。也就是说候选关键字是最简单的超关键字。 主关键字(primary key) ： ​ 是表中的一个或多个字段，它的值用于唯一地标识表中的某一条记录。 比如在一张成绩表中，有字段：学号，科目，成绩，任课老师。 学号+科目+任何其他字段就是超关键字，但是如果去掉学号或者科目中的一个就无法确定成绩，所以学号和科目是两个候选关键字。 只有知道了学号和科目你才能确定一条记录，所以学号和科目两个字段组成了主关键字 部分函数依赖 ​ 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。 ​ 举个例子：学生基本信息表R中（学号，身份证号，姓名）当然学号属性取值是唯一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）； 完全函数依赖 ​ 设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y

简单的说， 第一范式就是原子性，字段不可再分割； 第二范式就是属性完全依赖于主键，没有部分依赖； 第三范式就是没有传递依赖，属性不依赖于其它非主属性。 (1) 第一范式（1NF） 1NF的定义为：符合1NF的关系中的每个属性都不可再分。 下表所示的情况，就不符合1NF的要求。 1NF是所有关系型数据库的最基本要求，也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如下表所示： (2) 第二范式（2NF） 2NF的定义为：在1NF的基础之上，消除了非主属性对于码的部分函数依赖。 例如： 对于下仅仅符合1NF的下表 仍会存在一些问题： 数据冗余过大： 学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次 插入异常: 假如学校3月份新建了一个系，等到8月份才招生，那么无法将系名与系主任的数据单独地添加到数据表中去 删除异常: 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了 修改异常: 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据 改进后如下： (3) 第三范式（3NF） 3NF的定义为：在2NF的基础之上，消除了非主属性对于码的传递函数依赖。 仅仅符合2NF的要求，很多情况下还是不够的，原因在于仍然存在非主属性(系主任)对于码(学号)的传递函数依赖。改进后如下： 改进

文章来源:微信公众号-Java蚂蚁-数据库三范式是什么？ 什么是范式？ 简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。 什么是三大范式？ 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依 赖于主键，而不能只依赖于主键的一部分。 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖 于非主键列 B，非主键列 B 依赖于主键的情况。注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性 如何理解三大范式？ 第一范式（1NF）： 1)、每一列属性都是不可再分的属性值，确保每一列的原子性 2)、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据 如果需求说要按哪个省哪个市分类，那么显然第一个表格是不容易满足需求的，也不符合第一范式。 第二范式（2NF）： 每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。 一个人同时买几件商品，就会出来一个订单号多条数据，这样子客户都是重复的

数据库设计器 1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 (3) 演绎性。由基本表与代码表中的数据

在学习数据设计的时候,N种专业术语，看的头疼。但又不能不学，所以只好把它们整理整理出来，好让自己对它们有一个更深的理解。特别是对三范式（Normal Formal）的理解。 三范式指的是第一（1NF)、第二(2NF)和第三范式(3NF),其作用： 解决数据冗余，为数据有效性检查，提高存储效率考虑。 在了解三范式之前，我们先来弄清楚这几个概念（键、函数依赖以及其类型）： 一、关键码（键）： 由一个或多个属性组成，在实际使用中，有下列几种： 超键：在关系中能唯一标识元组的属性集称为关系模式的超键。 注意 : （属性集，说明可以是多个） 候选键：不含有多余属性的超键 主键：用户选作记录标识的候选键 这三个的关系，用数学关系可以做如下表示： 举例：一张学生信息表 问：超键是？ 答曰：学号唯一，是超键；姓名唯一，是超键；（学号，年龄）唯一，是超键；（学号、姓名、年龄）唯一，也是超键。 —— 从这里我们就可以看出，超键的组合是唯一的，但不可能是最小唯一的。 问：候选键是？ 答曰： 学号，唯一且没有多余的属性；姓名，唯一且没有多余的属性。 问：主键是？ 答曰：既可以选择学号，也可以选择姓名（前提是规定没有重名的）作为主键，所以主键是选中的一个候选键。 数据库设计的目的主要是为了解决数据冗余，对数据进行有效的管理。那么引起数据冗余的主要原因是什么呢？ 答曰：数据依赖。 什么是数据依赖

一、第一范式 1NF是对属性的 原子性 ，要求属性具有原子性，不可再分解； 表：字段1、 字段2(字段2.1、字段2.2)、字段3 ...... 如学生（学号，姓名，性别，出生年月日），如果认为最后一列还可以再分成（出生年，出生月，出生日），它就不是一范式了，否则就是； 二、第二范式 2NF是对记录的 惟一性 ，要求记录有惟一标识，即实体的惟一性，即不存在部分依赖； 表：学号、课程号、姓名、学分; 这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里 学分依赖课程号 ， 姓名依赖与学号 ，所以不符合二范式。 可能会存在问题： 数据冗余: ，每条记录都含有相同信息； 删除异常： 删除所有学生成绩，就把课程信息全删除了； 插入异常： 学生未选课，无法记录进数据库； 更新异常： 调整课程学分，所有行都调整。 正确做法: 学生： Student (学号, 姓名)； 课程： Course (课程号, 学分)； 选课关系： StudentCourse (学号, 课程号, 成绩)。 三、第三范式 3NF是对字段的 冗余性 ，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖； 表: 学号, 姓名, 年龄, 学院名称, 学院电话 因为存在 依赖传递 : (学号) → (学生)→(所在学院) → (学院电话) 。 可能会存在问题： 数据冗余:

复习下数据库的范式。 第一范式 第一范式列不能再分。如一张表里有一个字段是高级职称，但是在高校里高级职称包括副教授和教授，这属于可分的，所以不符合第一范式。 第二范式 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。 如果关系模型R为第一范式，并且R中的每一个非主属性完全函数依赖于R的某个候选键，则称R为第二范式模式(如果A是关系模式R的候选键的一个属性，则称A是R的主属性，否则称A是R的非主属性)。 例如，在 选课关系表(学号，课程号，成绩，学分) ，关键字为组合关键字 (学号，课程号) ，但由于非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是完全依赖，因此此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：学生表(学号，课程号，分数)和课程表(课程号，学分)，新关系通过学生表中的外关键字课程号联系，在需要时进行连接。 完全函数依赖 定义：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。 比如通过学号->姓名 部分函数依赖 定义：设X,Y是关系R的两个属性集合，存在X→Y，若X