1NF: 强调列的原子性
- 即列不能够再分成其他几列
第一种表设计:
| userID | userName | sex | age | tel | region |
|---|---|---|---|---|---|
| 1 | 张 | 男 | 22 | 123 | 河南省北京市永旺区 |
| 2 | 李 | 女 | 21 | 456 | 河南省安阳市朝阳区23号 |
| 3 | 六 | 女 | 21 | 456 | 河南省安阳市朝阳区22号 |
注意： 不符合第一范式，region列不具有原子性，可以拆分成省市县
第二种表设计:
| userID | userName | sex | age | tel | province | city | region |
|---|---|---|---|---|---|---|---|
| 1 | 张 | 男 | 22 | 123 | 山东省 | 北京市 | 永旺区 |
| 2 | 李 | 女 | 21 | 456 | 山西省 | 海淀市 | 朝阳区23号 |
| 3 | 六 | 女 | 21 | 456 | 河北省 | 承德市 | 朝阳区253号 |
符合第一范式
2NF: 表中每列与主键相关，而不是和主键的某部分相关（针对联合主键）
- 主键列与非主键列遵循完全函数依赖，也就是完全依赖
例子引入
设计一个订单信息表，订单有多种商品，将订单编号和商品编号作为联合主键
第一种表设计：
错误示范.png
第二种表设计：
正确示范.png
第一种表设计不满足第二范式。
订单编号和商品编号作为联合主键，由于商品名称，单位，价格这几列只与商品编号有关，与订单编号无关，因此与主键（联合主键）无关，违反范式第二原则；
3NF: 确保主键列之间没有传递函数依赖关系。
- 也就是消除传递依赖
例子引入
需求描述：
需要再数据库种存储如下信息：
学生编号
学生卡号
用户ID号
操作员级别
操作日期
操作时间
第一种表设计
| studentNo | cardNo | userID | userLevel | date | time |
|---|---|---|---|---|---|
| 021101 | 1 | Operator | 操作员 | 2011/10/24/ | 11：100 |
不符合第三范式，在表种，一个userID能确定一个userLevel。
userLevel依赖userID, 而 userID 依赖studentNo和cardNo，这样就导致了依赖传递
第二种表设计（符合第三范式）
| studentNo | cardNo | userID | date | time |
|---|---|---|---|---|
| 021101 | 1 | Operator | 2011/10/24/ | 11：100 |
| userID | userLevel |
|---|---|
| Operator | 操作员 |
搬运自stutterr， 侵删，各种侵各种删
