数据库设计范式：
第一范式：
要求任何一张表必须有主键，每一个字段原子性不可再分，第一范式是最核心，最重要的范式，所有的表的设计都需要满足
举例：
第二范式：
建立在第一范式的基础上，要求所有非主键字段完全依赖主键
以上的表并不满足第一范式。
修改之后：
学生编号和教师编号两个字段联合做主键，复合主键(PK：学生编号+教师编号)，经过修改之后，以上的表满足了第一范式，但是并不满足第二范式，因为”张三依赖1001”,“王老师依赖001”，显然产生了部分依赖，那么产生部分依赖有什么缺点呢？
数据冗余，空间浪费了，“张三”重复了，”王老师”重复了。
为了让上面这张表满足第二范式，我们对其进行修改
使用三张表来表示多对多的关系：
多对多设计技巧：多对多，三张表，关系表两个外键
第三范式：
建立在第二范式的基础上，要求所有非主键字段直接依赖主键，不要产生传递依赖
以上表的设计是描述，班级和学生的关系，很显然是一对多的关系，一个教室中有多个学生。
以上表满足第一范式，因为它包含主键，且也满足第二范式，因为主键不是复合主键，没有产生部分依赖，主键是单一主键，但是并不满足第三范式，因为一年一班依赖01,01依赖1001，产生了传递依赖，不符合第三范式的要求，产生了数据的冗余。
修改如下：
一对多，两张表，多的表加外键
设计数据库表的时候，按照以上的范式进行，可以避免表中数据的冗余，空间的浪费。
数据库设计总结：
一对多，两张表，多的表加外键
多对多，三张表，关系表两个外键
一对一：在实际的开发中，可能存在一张表字段太多，太庞大，这个时候需要拆分
举例：
未拆分的一张表：
拆分成两张之后：
一对一，外键唯一
数据库设计三范式是理论上的，实践和理论有的时候有偏差，最终的目的都是为了满足客户的需求，有的时候会拿冗余换执行速度，因为在sql当中，表和表之间连接次数越多，效率越低(笛卡尔积),有的时候可能会存在冗余，但是为了减少表的连接次数，这样做也是合理的，并且对于开发人员来说，sql语句的编写难度也会降低
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/81386.html
