第一范式(1NF)

数据表的每一列都要保持它的原子特性，也就是列不能再被分割。

这张表就不符合第一范式规定的原子性，不符合关系型数据库的基本要求，在关系型数据库中创建这个表的操作就不能成功。不得不将数据表设计为如下形式。

第二范式(2NF)

概率：属性必须完全依赖于主键。

下满这张表不符合第二范式的要求。

缺点

表中的第一行数据都存储了系名、系主任,数据的冗余太大

如果有一个新的系还没有开始找到学生，那么不能讲该系的信息添加到数据表中去，从数据表中看不到该系的存在

如果将某个系的学生信息全部删除，那么这个系在数据表里也就不存在了，但这个系还存在。

如果某个人要转系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据

依赖

在数据表中，属性(属性组)X确定的情况下，能完全退出来属性Y完全依赖于X。

完全依赖

完全依赖是针对于属性组来说，当一组属性X能推出来Y的时候就说Y完全依赖于X。

部分依赖

一组属性X中的其中一个或几个属性能推出Y就说Y部分依赖于X。

结论:当一个第一范式的候选码只有一个属性的时候，那它就是第二范式(2NF)

候选码

当一个属性或者属性组确定的情况下，这张表的其余所有属性就能确定下来，这个属性或者属性组就叫做或候选码。

一张表可以有多个候选码

一般只选一个候选码作为主键

从表中找到两个属性：学号和课程

学号可以推出姓名、系名、系主任。

课程可以推出成绩。

将它们两个设置为联合主键

存在的部分依赖

姓名对学号存在部分依赖

系名对学号存在部分依赖

系主任对学号存在部分依赖

这显然不符合第二范式的要求，做出修改：

表一中分数完全依赖于学号和课程的属性

表二中姓名、系名、系主任完全依赖于学号的属性

第二范式消除了第一范式的部分依赖

第三范式(3NF)

概念:所有的非主属性不依赖于其他的非主属性

传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

在改进后的学生表中：

主属性：学号

非主属性：姓名、系名、系主任

知道系名可以推出系主任，所以非主属性系主任对主属性学号存在传递函数依赖，这不符合非主属性不依赖于其它的非主属性的设计要求。将该数据表改进如下：

第三范式消除了第二范式的传递函数依赖

BC 范式

主属性不能对候选码存在部分函数依赖或者传递函数依赖

这张表不存在部分函数依赖于传递函数依赖，属于第三范式

表中的依赖关系

仓库名—————>管理员

管理员—————>仓库名

物品名—————>数量

主属性：仓库名、管理员、物品名

非主属性：数量

存在的问题

先新添加一个仓库，但尚未存放任何物品，不可以为该仓库指派管理员，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空

某仓库被清空后，该仓库的信息也被清空

当需要更新仓库管理员，该仓库存放了多少物品，就要修改多少条信息。

在这个问题中就是存在了主属性对于候选码的部分依赖，也就是仓库名对于管理员和物品名的部分依赖。

修改为

仓库(仓库名，管理员)

库存(仓库名、物品数、数量)

第四范式(4NF)

消除表中的多值依赖

设R是一个关系模型，D是R上的多值依赖集合。如果D中存在凡多值依赖X->Y时，X必是R的超键，那么称R是第四范式的模式。

例如，职工表(职工编号，职工孩子姓名，职工选修课程)，在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实，例如职工表一(职工编号，职工孩子姓名)，职工表二(职工编号，职工选修课程)，两个表都只有一个多值事实，所以符合第四范式。

优缺点：表的冗余性，提高了多表的联合查询的效率。

范式之间的关系

范式的目的

减小数据的冗余性

提高效率

数  据   库

今天小编来讲一下数据库的相关知识点，数据库的三大特性可谓是：实体属性和关系。

实体：表； 属性：表中的数据(字段)； 关系：表与表之间的关系；

数据库设计三大范式(重点)：

第一范式(1NF)：数据表中的每一列(每个字段)必须是不可拆分的最小单元，也就是确保每一列的原子性；

例如：userInfo：山东省烟台市  131777368781           userAds：山东0省烟台市  userTel：131777368781

第二范式(2NF)：满足1NF后，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情；

例如：订单表只描述订单相关的信息，所以所有字段都必须与订单id相关       产品表只描述产品相关的信息，所以所有字段都必须与产品id相 关；因此不能在一张表中同时出现订单信息与产品信息；如下图所示：

第三范式(3NF)：必须先满足第二范式(2NF)，要求：表中的每一列只与主键直接相关而不是间接相关，(表中的每一列只能依赖于主键)；

例如：订单表中需要有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户id即可，而不能有其他的客户信息。因为其他的客户信息直接关联于用户id，而不是直接与订单id直接相关。

【如何更好的区分三大范式】

第 一范式和第二范式在于有没有分出两张表，第二范式是说一张表中包含了所种不同的实体属性，那么要必须分成多张表， 第三范式是要求已经分成了多张表，那么一张表中只能有另一张表中的id(主键)，而不能有其他的任何信息(其他的信息一律用主键在另一表查询)。

【数据库五大约束】

1.primary KEY:设置主键约束；

2.UNIQUE：设置唯一性约束，不能有重复值；

3.DEFAULT 默认值约束，height DOUBLE(3,2)DEFAULT 1.2 height不输入是默认为1,2

4.NOT NULL：设置非空约束，该字段不能为空；

5.FOREIGN key :设置外键约束。

【主键】

1.主键的注意事项？

主键默认非空，默认唯一性约束，只有主键才能设置自动增长，自动增长一定是主键，主键不一定自动增长；

2.设置主键的方式？

在定义列时设置：ID INT PRIMARY KEY

在列定义完之后设置：primary KEY(id)

【外键】

1.设置外键的注意事项：

只有INNODB的数据库引擎支持外键，修改my.ini文件设置default-storage-engine=INNODB    外键必须与参照列的数据类型必须相同(数值型要求长度和无符号都相同，字符串要求类型相同，长度可以不同)。

2设置外键的语法：

CONSTRAINT 外键名 FOREIGN KEY (外键字段)REFERENCES 参照表 (参照字段)    ON DELETE SET NULL ON UPDATE CASCADE 设置参照完整性

3.外键约束的参照操作？

参照表的完整性操作：当对参照表的参照字段进行删除或更新时，外键表中的外键如何应对；

参照操作可选值：

RESTRICT拒绝参照表删除或更新参照字段；

RESTRICT和NO ACTION相同，但这个指令只在mysql生效;

CASCADE删除或更新参照表的参照字段时，外键表的记录同步删除更新；

SET NULL 删除或更新参照表的参照字段时，外键表的外键设为NULL;

转自：https://www.cnblogs.com/waj6511988/p/7027127.html