1. 数据库三范式
1.1 第一范式 1NF
比如设计一个电商收货地址数据库，问题在于不利于数据的一些统计，比如需要统计“辽宁省”的订单。
| 收货人 | 地址 |
|---|---|
| 赵四 | 中国辽宁省铁岭市象牙山村xx组xx号 |
| 趙四 | 中國遼寧省鐵嶺市象牙山村xx組xx號 |
| 特朗普 | 美国华盛顿特区白宫 |
1NF指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
修改为
| 收货人 | 收货国家 | 收货省 | 收货市 | 详细地址 |
|---|---|---|---|---|
| 赵四 | 中国 | 辽宁省 | 铁岭市 | 象牙山村xx组xx号 |
| 特朗普 | 美国 | 华盛顿特区 | 白宫 |
1.2 第二范式 2NF
比如设计一个记录学生考试成绩和选修课程的数据库
1. 学生表
| 学生ID | 学生姓名 |
|---|---|
| 101 | 赵四 |
| 102 | 刘能 |
2. 课程表
| 课程ID | 课程名 |
|---|---|
| K901 | Java |
| K902 | 数据库设计 |
| K903 | 程序员的删库和跑路 |
3. 学生选课表
| 学生ID | 课程ID | 考试分数 | 课程学分 |
|---|---|---|---|
| 101 | K901 | 88 | 3 |
| 101 | K902 | 50 | 0 |
| 102 | K901 | 98 | 3 |
| 102 | K902 | 60 | 3 |
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
上述问题：K903这门课无人选课，数据库中没有记录它的学分。学生选课表中的主键是由学生ID和课程ID组成的联合主键。课程学分在表中只依赖于课程ID，不是完全依赖于联合主键
修改后
1. 学生表
| 学生ID | 学生姓名 |
|---|---|
| 101 | 赵四 |
| 102 | 刘能 |
2. 课程表
| 课程ID | 课程名 | 课程学分 |
|---|---|---|
| K901 | Java | 3 |
| K902 | 数据库设计 | 3 |
| K903 | 程序员的删库和跑路 | 3 |
3. 学生选课表
| 学生ID | 课程ID | 考试分数 |
|---|---|---|
| 101 | K901 | 88 |
| 101 | K902 | 50 |
| 102 | K901 | 98 |
| 102 | K902 | 60 |
1.3 第三范式 3NF
比如设计学生和班级数据库
| 学生ID | 学生姓名 | 学生所在班级ID | 班级名称 |
|---|---|---|---|
| 101 | 赵四 | B01 | 研发一班 |
| 102 | 刘能 | B01 | 研发一班 |
第三范式就是属性不依赖于其它非主属性，消除的是传递性的依赖关系
产生问题：B02（研发二班）暂时没有学生，在数据库中没有它的数据。B01班级有多个学生，数据会记录多次。
班级名称不直接依赖于主键学生ID，它是通过学生所在班级ID进行传递依赖。
修改后
| 学生ID | 学生姓名 | 学生所在班级ID |
|---|---|---|
| 101 | 赵四 | B01 |
| 102 | 刘能 | B01 |
| 班级ID | 班级名称 |
|---|---|
| B01 | 研发一班 |
| B02 | 研发二班 |
2. 关系型实体关系
2.1 一对一关系
电商数据库设计中的商品介绍，商品介绍可能因为数据量较大，影响整个表的查询速度，而且它还不常用，将其独立放入一张表中。两张表通过同一个主键ID进行关联
商品表
| 商品ID | 商品名称 |
|---|---|
| 101 | iPhone56 |
| 102 | iPhone57 |
商品详情表
| 商品ID | 商品介绍 |
|---|---|
| 101 | iPhone56是全新一代.....此处省略N字 |
| 102 | iPhone57是最新一代.....此处省略N字 |
2.2 多对一关系和一对多关系
比较常见的数据库关系，参照EMP-DEPT的关系理解
学生表
| 学生ID | 学生姓名 | 学生所在班级ID |
|---|---|---|
| 101 | 赵四 | B01 |
| 102 | 刘能 | B01 |
班级表
| 班级ID | 班级名称 |
|---|---|
| B01 | 研发一班 |
| B02 | 研发二班 |
关系图
2.3 多对多关系
较常见的数据库关系，参照学生-课程理解
1. 学生表
| 学生ID | 学生姓名 |
|---|---|
| 101 | 赵四 |
| 102 | 刘能 |
2. 课程表
| 课程ID | 课程名 | 课程学分 |
|---|---|---|
| K901 | Java | 3 |
| K902 | 数据库设计 | 3 |
| K903 | 程序员的删库和跑路 | 3 |
3. 学生选课表
| 学生ID | 课程ID | 考试分数 |
|---|---|---|
| 101 | K901 | 88 |
| 101 | K902 | 50 |
| 102 | K901 | 98 |
| 102 | K902 | 60 |
多对多关系分析
关系型数据库中不能直接体现多对多关系，通过将多对多关系拆解成两对多对一关系
将多对多关系拆解成两对多对一关系
3. 设计技巧
3.1 主键
主键尽量不使用有实际意义的数据。主键一旦发生改变对数据的影响非常大
3.2 实体
实体性质的表，应该有一个flag的int型的列，用于表示删除，1-有效 其余的数字就是被删除。在数据库表操作中不做真正的delete操作
3.3 创建时间
实体性质的表，在创建一条记录时应该记录该数据的创建时间
网友评论