数据库表设计原则

关系型数据库表设计

• 一对一

• 一对多

​ 如：用户-商品：没有关系； 用户-订单：一对多的关系；商品-订单：多对多

一对一和一对多是在子表增加一列关联父表的主键

• 多对多：加入一张中间表，如商品表，订单表，再加上一个订单内容表（中间表）

关系型数据库范式

优点：

减少数据冗余（主要）

清除异常（插入、更新、删除）

让数据组织更和谐

第一范式（1NF）

每一列保持原子特性，列都是基本数据项，不能够再进行分割

第二范式（2NF）

属性完全依赖于主键——主要针对联合主键；

非主属性完全依赖于主关键字，如果不是完全依赖于主键，应该拆分为新实体，设计成一对多实体关系。

如：选课关系表SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，

（学号，课程名称）是联合主键，但是学分只和课程名有关，相当于只依赖于联合主键其中一个字段，不符合第二范式，应该修改为

学生表(学号，姓名，年龄)

课程表(课程id，课程名，学分)

选课情况表（学号，课程id，成绩），中间表

这样可以减少数据冗余（一门课的课程名和学分只要存一次）和清除异常

第三范式

属性不依赖于其他非主属性

示例：学生关系表为Student（学号， 姓名， 年龄， 所在学院， 学院地点， 学院电话），学号是主键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系。

一般关系型数据库满足第三范式即可。

范式越高越好吗？

应用的范式越高，表越多。表多会带来很多问题：

1、 查询时需要连接多个表，增加了SQL查询的复杂度

2 、查询时需要连接多个表，降低了数据库查询性能

因此，并不是应用的范式越高越好，视实际情况而定。第三范式已经很大程度上减少了数据冗余，并且基本预防了数据插入异常，更新异常，和删除异常了。