一范式就是属性不可分割。属性是什么？就是表中的字段。
不可分割的意思就按字面理解就是最小单位，不能再分成更小单位了。
这个字段只能是一个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合一范式。
不过能不能分割并没有绝对的答案，看需求，也就是看你的设计目标而定。
举例：
学生信息组成学生信息表，有姓名、年龄、性别、学号等信息组成。
姓名不可拆分吧？所以可以作为该表的一个字段。
但我要说这个表要在国外使用呢？人家姓和名要分开，都有特别的意义，所以姓名字段是可拆分的，分为姓字段和名字段。
简单来说，一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定。
二范式就是要有主键，要求其他字段都依赖于主键。
为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键。
其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的。
如果有同学不理解依赖这个词，可以勉强用“相关”这个词代替，也就是说其他字段必须和它们的主键相关。因为不相关的东西不应该放在一行记录里。
举例：
学生信息组成学生表，姓名可以做主键么？
不能！因为同名的话，就不唯一了，所以需要学号这样的唯一编码才行。
那么其他字段依赖于主键是什么意思？
就是“张三”同学的年龄和性别等字段，不能存储别人的年龄性别，必须是他自己的，因为张三的学号信息就决定了，这行记录归张三所有，不能给无关人员使用。
三范式就是要消除传递依赖，方便理解，可以看做是“消除冗余”。
消除冗余应该比较好理解一些，就是各种信息只在一个地方存储，不出现在多张表中。
比如说大学分了很多系（中文系、英语系、计算机系……），这个系别管理表信息有以下字段组成：
系编号，系主任，系简介，系架构。
那么再回到学生信息表，张三同学的年龄、性别、学号都有了，我能不能把他的系编号，系主任、系简介也一起存着？
如果你问三范式，当然不行，因为三范式不同意。
因为系编号，系主任、系简介已经存在系别管理表中，你再存入学生信息表，就是冗余了。
三范式中说的传递依赖，就出现了。
这个时候学生信息表中，系主任信息是不是依赖于系编号了？而这个表的主键可是学号啊！
所以按照三范式，处理这个问题的时候，学生表就只能增加一个系编号字段。
这样既能根据系编号找到系别信息，又避免了冗余存储的问题。
所谓的范式，是用来学习参考的，设计的时候根据情况，未必一定要遵守，切记。
复习了一下数据库的五个范式，这里不用公式，用尽可能少的术语说说理解。
之所以使用范式，往往是设计不规范的数据库表可能造成大量的数据冗余，也可能在发生插入、删除、修改操作后出现各种各样的不合理的问题。
1）1NF（第一范式）： 数据库表的每一列都是不可分割的基本数据项。 如“电话号码”这个属性可以继续被分割为“办公电话”、“手机号码”等属性，在第一范式的语义下不应该被作为单独的一列出现。
2）2NF（第二范式）：必须先满足第一范式。 数据库表中的每一行必须可以被唯一的区分，即每一行中有一个唯一标识将这行与其他行区分出来，这个唯一标识就是我们常说的主键。在2NF的语义下，所有非主键的字段都要依赖主键。比如在学生表中我们用学生id作为主键，那么当我们需要查询一个学生的时候，通过他的id号应该可以唯一地定位到这个学生，会并且只会查出一行。
3）3NF（第三范式）：必须先满足第二范式。非主键字段都与主键字段有直接依赖关系，不存在传递依赖。可以理解为非主键字段只依赖主键字段，而不依赖其它的非主键字段。
比如员工表的字段构成为：员工id（主键），姓名，性别，年龄，所属部门，部门经理姓名，部门电话。
这里所有的非主键字段并不是直接依赖于主键“员工id”， 可以看到“部门经理姓名”和“部门电话”这两个属性依赖于“所属部门”，而“所属部门”又依赖于主键“员工id”，这就是传递依赖，这里可将该员工表的表结构改成：员工id（主键），姓名，性别，年龄，部门名称
单独提出部门表结构为：部门名称（主键），部门经理id ，部门电话
4）BCNF ：第三范式的扩展和加强。
这里用网上看到的一个例子：
表结构： 仓库id 管理员id 物品id 物品数量
其中管理员和仓库的关系是一对一，仓库和物品的关系是一对多；
这个设计符合第一、二、三范式，即每列不可分割、主键唯一且不存在传递依赖；
可看到依赖关系有管理员id 依赖 仓库id， 物品id 依赖 仓库id。 即存在主键到主键再到非主键的传递依赖关系。
这里的主要问题是，仓库id和管理员id这两个关键字段之间的关系被耦合到每一个实例中了，这导致：
a) 表中没有数据的时候，无法描述仓库和管理员之间的关系
b) 一个仓库的管理员替换后，表中所有含有该仓库的实例中的管理员id都要被修改
解决办法是将二者的关系提出来单独建表。
则原表结构改为：仓库id 物品id 物品数量
增加表的结构： 仓库id 管理员id
这样 仓库和管理员的关系 及 仓库和物品的关系 就解耦合了。
5）4NF（第四范式）：必须先满足第三范式。简单来说就是将表中的多值属性拆分出来，分别建表。
比如在用户表中有一个非主键字段“电话号码”，某一行实例的“电话号码”内容可能是手机号码，可能是座机号码，也可能是多个内容的直接组合（如“电影”属性中填“动作，喜剧，科幻”）， 这就是多值属性。
例：
用户表包含一个多值字段“爱好”，某个实例内容可能为：
用户id 姓名 爱好
1 John 足球、游泳、植物大战僵尸
这种情况可以再单独拆出一个爱好表，如下：
字段： 用户id 爱好
实例： 1 足球
实例： 1 游泳
实例： 1 植物大战僵尸
实例： 2 乒乓球
实例： 3 野外求生
在网上看到一种方案是直接加一个字段来约束多值属性内容，如下：
字段： 用户id 电话类别 电话号码
实例： 1 手机 12345678
实例： 2 家庭座机 020-123456
实例： 3 手机 22345678
这种设计不符合第三范式，电话类别这个属性和主键是没有依赖关系的，它仅仅用来约束电话号码的内容。 优点是较上述解决办法可以减少多表查询的开销。
范式是人们在具体的业务场景中遇到问题逐渐总结出来的通用解决思路，在实际开发中如果并不常用到某些范式，可能只是问题和数据的规模还没达到。
【如何更好的区分三大范式】
第 一范式和第二范式在于有没有分出两张表，第二范式是说一张表中包含了所种不同的实体属性，那么要必须分成多张表， 第三范式是要求已经分成了多张表，那么一张表中只能有另一张表中的id（主键），而不能有其他的任何信息（其他的信息一律用主键在另一表查询）。
【数据库五大约束】
- Primary KEY:设置主键约束；
- UNIQUE：设置唯一性约束，不能有重复值；
- DEFAULT 默认值约束，height DOUBLE(3,2)DEFAULT 1.2 height不输入是默认为1,2
- NOT NULL：设置非空约束，该字段不能为空；
- 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;