今天接触了数据库中的三范式，觉得非常有意义，所以记录下来。
第一范式：所谓的第一范式（1NF）就是指数据库中的每一列都是不可分割的基本的数据项，同一个列中不能有多个多个值，即实体中不能有多个值或者有重复的值。第一范式的满足条件是：数据库中的所有字段都是不能分解的原子值。
如果不满足第一范式则不能称之为关系数据库，第一范式为了是数据库没有重复的列。
Ps：事物原子性指的是包含的程序作为数据库的逻辑工作单位，要么一起执行，要么全不执行
编号 |
地址 |
1 |
中国上海 |
2. |
美国拉斯维加斯 |
3 |
日本京都 |
上面的表不满足第一范式，应该把数据库中的表尽可能的细分。
编号 |
国家 |
城市 |
1 |
中国 |
上海 |
2 |
美国 |
拉斯维加斯 |
3 |
日本 |
京都 |
第二范式（2NF）： 第二范式是在第一范式的基础上建立起来的，即满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
订单编号 |
客户姓名 |
含有主食 |
菜品名称 |
份数 |
价格 |
联系方式 |
0001 |
小赵 |
是 |
番茄炒蛋 |
1 |
10 |
10086 |
0002 |
小天 |
否 |
东坡肉 |
2 |
60 |
10000 |
0003 |
小李 |
是 |
红烧茄子 |
3 |
50 |
10010 |
上面这个表显然满足第一范式，但是不满足第二范式，因为包含了客户信息和订单详情两种关系。这种关系数据库执行后会有下面的后果：
1. 数据亢余
2. 更新异常
3. 插入异常
4. 删除异常
其实很好理解，如果增加一列，但是表中并没有让你增加的顺序，造成数据的丢失。而且由于无关数据的原因，造成执行SQL命令的缓慢。
第三范式（3nf）
分割后的表如图：
客户信息确认表
订单编号 |
客户姓名 |
联系方式 |
0001 |
小赵 |
10086 |
0002 |
小天 |
10000 |
0003 |
小李 |
10010 |
订单信息确认表
订单编号 |
菜品名称 |
含有主食 |
份数 |
价格 |
0001 |
番茄炒蛋 |
是 |
1 |
10 |
0002 |
东坡肉 |
否 |
2 |
60 |
0003 |
红烧茄子 |
是 |
3 |
50 |
第三范式（3nf）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A→ B → C"的决定关系，则C传递函数依赖于A。通俗点来说：第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。每一列数据都和主键直接相关，不能间接相关。
