第二范式

第一范式：每个列不可拆分 第二范式：在第一范式上，非主键列完全依赖主键，而不能依赖主键一部分 第三范式：在第二范式上，非主键列只能依赖主键，不依赖其他非主键 设计数据库结构，尽量遵守3范式。考虑性能等问题，可以不严格遵守。 来源： https://www.cnblogs.com/ivy-xu/p/12540145.html

1、什么是范式？ 范式就是在设计数据库表的时候，可以遵循的规范。范式分为：第一范式、第二范式、第三范式、其他更高级的范式。 2、第一范式（1NF） 是指在关系模式数据中，要求所有的字段都应该具有原子性，不可再分。如下图所示： 每个学生的相关信息都不能再拆分。但是当修改张三到MySQLo2的时候，因为有两个张三，不知道具体该是那个张三。 缺点：不能唯一的标识某一条记录 3、第二范式（2NF） 第二范式要求数据库表中的每一个实例或记录必须可以被唯一的区分，简而言之就是给表一个主键字段。 第二范式是为了解决第一范式的缺点应运而生的。即满足第二范式必须先满足第一范式。 缺点：对重复存储数据不做约束（即班级、班主任） 4、第三范式（3NF） 第三范式要求一个表中不能有关联属性信息，数据与数据的关联性通过主外键相联系。 第三范式是第二范式的一个子集。即满足第三范式必须先满足第二范式。 如下图：以下学生都在同一个班级里，都是同一个班主任。 如下图：通过外键将学生信息和班级信息联系在一起。（ 外键的值：是另一个表的主键 ） 练习题： 1、下面创建学生表student的SQL语句，正确的是？ A create table student( id int primary key auto_increment,name varchar(10), sex tinyint(1) default 1 ) B

文章目录 第一范式（1 NF） 第二范式（2 NF） 第三范式（3 NF） 第一范式（1 NF） 数据表中所有的字段都是不可分割的原子值 不满足第一范式，一般通过拆列解决 若字段值还可以继续拆分开，显然就不满足第一范式，如有一个列字段中存了“湖北省武汉市xxx地区”，这样不满足第一范式，我们需要拆开为几列，当然开发中我们不一定非要满足第一范式，有时候开发时会发现不拆比拆开更好 第二范式（2 NF） 在满足第一范式的前提下，要求除了主键外的每一列都完全依赖于主键，否则不满足第二范式 不满足第二范式，一般通过拆表解决 打个比方，联合主键时候，其他非主键字段其实只依赖于联合主键中的一个列，这样是不满足第二范式的 第三范式（3 NF） 在满足第二范式的前提下，要求表中除了主键意外，其他列不能有传递依赖 可以通过拆表来解决 打个比方，学生表，主键为学号，表中还有身份证号，这样学生姓名还依赖于身份账号，这样就是传递依赖，不满足第三范式 来源： CSDN 作者： abcnull 链接： https://blog.csdn.net/abcnull/article/details/104758806

1. 数据库约束 1.约束类型 NOT NULL - 指示某列不能存储 NULL 值。 UNIQUE - 保证某列的每行必须有唯一的值。 DEFAULT - 规定没有给列赋值时的默认值。 PRIMARY KEY - NOT NULL 和 UNIQUE 的结合。确保某列（或两个列多个列的结合）有唯一标识，有助于更容易更快速地找到表中的一个特定的记录。 FOREIGN KEY - 保证一个表中的数据匹配另一个表中的值的参照完整性。 CHECK - 保证列中的值符合指定的条件。对于MySQL数据库，对CHECK子句进行分析，但是忽略CHECK子句。 用例： #创建学生表 DROP TABLE IF EXISTS student ; CREATE TABLE student ( id INT NOT NULL PRIMARY KEY auto_increment , #NULL可以为空 #NOT NULL 不为空 #PRIMARY KEY 主键约束 #对于整数类型的主键，自增长auto_increment插入数据对应字段不给值时，使用最大值+1 sn INT UNIQUE , #UNIQUE 唯一约束 name VARCHAR ( 20 ) DEFAULT 'unkown' , #DEFAULT默认值 qq_mail VARCHAR ( 20 ) ) ; 2.FOREIGN KEY

第一范式 　　定义表：属性分割 第二范式 　　分表：各自依赖自己主键 第三范式 　　关联：主键关联 数据库中的范式有第一范式(1NF),第二范式(2NF),第三范式(3NF),巴斯-科德范式(BCNF),第四范式(4NF),第五范式(5NF)(又称完美范式) 第一范式----数据库中的表(所有字段值)都是不可分割的原子数据项。 第二范式----数据库表中的每一列都和主键相关，而不能只和主键的某一部分相关。也就是说 一个表中只能只能包含一个，不能把多种数据保存在同一个表中。 第三范式----数据库表中每一列数据都和主键直接相关，不能间接相关。 降低数据的冗余度。。。。。。 转自---- Ruthless 数据库设计三大范式 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市

1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 UserInfo(ID,Name,Age,LinkTel,Province,City,Address)

0.参考文献： http://www.cnblogs.com/xwdreamer/archive/2012/05/17/2506039.html 1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 一张学生表Student(stuNo,stuName,age,age,sex)是不符合第一范式的，因为有重复列age属性。去除重复列age以后的Student(stuNo,stuName,age,sex)是符合第一范式的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 　　第二范式

关系型数据库三个范式 相关概念 候选关键字 ： ​ 二维表中，能够惟一确定记录的一个字段或几个字段的组合被称为“超关键字”。“超关键字”虽然能唯一确定记录，但是它所包含的字段可能是有多余的。 如果一个超关键字去掉其中任何一个字段后不再能唯一地确定记录，则称它为 候选关键字。候选关键字既能唯一地确定记录，它包含的字段又是最精炼的。也就是说候选关键字是最简单的超关键字。 主关键字(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

一、第一范式 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