Mysql入门学习第六章

第六章 数据库设计

学到这里，mysql对表的增删改查我们都能够写出来了，接下来在分享一些数据库设计方面的内容，这部分也是面试爱问的内容，当然答案不是固定的，每个人的阅历不同，可能也会交出不同的见解，而且面试官不爱听生硬的概念，更乐意去听那种现实项目中的实现，本章仅分享基本概念，不需要硬背，最好结合自己的数据库表设计去表达，这样也不会产生过多的记忆压力。

一、三范式

注：设计只是一种思想一种理念，我们按照规范的设计方式设计数据库对我们来说有好处，但绝对不是说一定要严格遵守，三范式能极大的减少数据冗余，但是相对编写sql而言是增加了难度的，所以所有好的设计都是要权衡利弊的，要对编码难度，存储大小，执行效率等多方面进行综合考量，但是在学习初期最好紧紧的遵循三范式，在后续的编码中体会和总结自己的经验。

设计数据库表的时候所依据的规范，共三个规范：

• 第一范式：要求有主键，并且要求每一个字段原子性不可再分
• 第二范式：要求所有非主键字段完全依赖主键，不能产生部分依赖
• 第三范式：所有非主键字段和主键字段之间不能产生传递依赖

1、第一范式

数据库表中不能出现重复记录，每个字段是原子性的不能再分

不符合第一范式的实例：

学生编号	学生姓名	联系方式
1001	白杰	bj@qq.com,18565987896
1002	杨春旺	ycw@qq.com,13659874598
1003	张志伟	zzw@qq.com,12598745698

解决方案

学生编号	学生姓名	邮箱地址	联系电话
1001	白杰	bj@qq.com	18565987896
1002	杨春旺	ycw@qq.com	13659874598
1003	张志伟	zzw@qq.com	12598745698
不符合第一范式的实例，不是说他错哈：
必须有主键，这是数据库设计的最基本要求，主要采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利可能就采用一个字段。

关于第一范式，每一行必须唯一，也就是每个表必须有主键，这是数据库设计的最基本要求，主要采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利可能就采用一个字段

2、第二范式

第二范式是建立在第一范式基础上的，另外要求所有非主键字段完全依赖主键，不能产生部分依赖

不符合第二范式的案例：

其中学生编号和课程编号为联合主键

以上虽然确定了主键，但此表会出现大量的数据冗余，出现冗余的原因在于，学生信息部分依赖了主键的一个字段学生编号，和课程id没有毛线关系。同时课程的信息只是依赖课程id，和学生id没有毛线关系。只有成绩一个字段完全依赖主键的两个部分，这就是第二范式部分依赖。
解决方案：

学生表：学生编号为主键

如果一个表是单一主键，那么它就是复合第二范式，部分依赖和主键有关系

以上是典型的“多对多”设计

3、第三范式

建立在第二范式基础上的，非主键字段不能传递依赖于主键字段（不要产生传递依赖）

不满足第三范式的例子：

其中学生编号是主键

何为传递依赖？

专业编号依赖学生编号，因为该学生学的就是这个专业啊。但是专业名称和学生其实没多大关系，专业名称依赖于专业编号。这就叫传递依赖，就是某一个字段不直接依赖主键，而是依赖 依赖主键的另一个字段。

解决方法：

学生表，学生编号为主键：

学生编号为主键：

以上设计是典型的一对多的设计，一存储在一张表中，多存储在一张表中，在多的那张表中添加外键指向一的一方。

二、常见表关系
1、一对一 用的不多
一个表和另一张表存在的关系是一对一，此种设计不常用，因为此种关系经常会将多张表合并为一张表。

举例：

学生信息表可以分为基本信息表和详细信息表。

可能有这种需求，需要给个某个账户对学生表的操作，但是有些私密信息又不能暴露，就可以拆分。

第一种方案：分两张表存储，共享主键
第二种方案：分两张表存储，外键唯一

2、一对多
第三范式的例子

两张表 外键建在多的一方

分两张表存储，在多的一方添加外键，
这个外键字段引用一的一方中的主键字段

3、多对多
第二范式的例子

分三张表存储，在学生表中存储学生信息，在课程表中存储课程信息，
在成绩表中存储学生和课程的关系信息

记住三范式 仅仅是规范 一种设计理念 可遵守可不遵守 要参考自己的项目去设计表 不要
被该要求局限到。
学到这里mysql的入门课程也完成了 完结散花，接下来会进入到mysql进阶的部分。