- 一、三范式
- 第一范式
- 第二范式
- 第三范式
- 二、常见表关系
- 1. 一对一 (用的不多)
- 2. 一对多
- 3. 多对多
注：设计只是一种思想、一种理念，我们按照规范的设计方式设计数据库对我们来说有好处，但绝对不是说一定要严格遵守，三范式能极大的减少数据冗余，但是相对编写sql而言是增加了难度的，所以所有好的设计都是要权衡利弊的，要对编码难度，存储大小，执行效率等多方面进行综合考量，但是在学习初期最好紧紧的遵循三范式，在后续的编码中体会和总结自己的经验。
设计数据库表的时候所依据的规范，共三个规范：
第一范式第一范式：要求有主键，并且要求每一个字段原子性不可再分
第二范式：要求所有非主键字段完全依赖主键，不能产生部分依赖
第三范式：所有非主键字段和主键字段之间不能产生传递依赖
数据库表中不能出现重复记录，每个字段是原子性的不能再分
不符合第一范式的实例：
解决方案
不符合第一范式的实例，不是说他错哈：
解决方案：
必须有主键，这是数据库设计的最基本要求，主要采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利可能就采用一个字段。
关于第一范式，每一行必须唯一，也就是每个表必须有主键，这是数据库设计的最基本要求，主要采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利可能就采用一个字段。
第二范式第二范式是建立在第一范式基础上的，另外要求所有非主键字段完全依赖主键，不能产生部分依赖
不符合第二范式的案例：
以上虽然确定了主键，但此表会出现大量的数据冗余，出现冗余的原因在于，学生信息部分依赖了主键的一个字段学生编号，和课程id没有毛线关系。同时课程的信息只是依赖课程id，和学生id没有毛线关系。只有成绩一个字段完全依赖主键的两个部分，这就是第二范式部分依赖。
解决方案：
学生表：学生编号为主键
课程表：课程编号为主键
成绩表：学生编号和课程编号为联合主键
如果一个表是单一主键，那么它就是复合第二范式，部分依赖和主键有关系
以上是典型的“多对多”设计
第三范式建立在第二范式基础上的，非主键字段不能传递依赖于主键字段（不要产生传递依赖）
不满足第三范式的例子：
其中学生编号是主键
何为传递依赖
专业编号依赖学生编号，应为该学生学的就是这个专业啊。但是专业名称和学生其实没多大关系，专业名称依赖于专业编号。这就叫传递依赖，就是某一个字段不直接依赖主键，而是依赖 依赖主键的另一个字段。
解决方法：
学生表，学生编号为主键：
学生编号为主键：
专业表，专业编号为主键：
以上设计是典型的一对多的设计，一存储在一张表中，多存储在一张表中，在多的那张表中添加外键指向一的一方。
二、常见表关系 1. 一对一 (用的不多)一个表和另一张表存在的关系是一对一，此种设计不常用，应为此种关系经常会将多张表合并为一张表。
举例：
学生信息表可以分为基本信息表，和详细信息表。
可能有这种需求，需要给个某个账户对学生表的 *** 作，但是有些私密信息又不能暴露，就可以拆分。
2. 一对多第一种方案：分两张表存储，共享主键
第二种方案：分两张表存储，外键唯一
第三范式的例子
两张表 外键建在多的一方
3. 多对多分两张表存储，在多的一方添加外键，
这个外键字段引用一的一方中的主键字段
第二范式的例子
分三张表存储，在学生表中存储学生信息，在课程表中存储课程信息，
在成绩表中存储学生和课程的关系信息
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）