14.数据库的设计以及三大范式

1.为什么需要设计

当数据库比较复杂的时候，就需要进行数据库的设计了

糟糕的数据库设计：

• 数据冗余（数据字段重复），浪费空间
• 数据库插入删除都十分麻烦（物理外键）
• 程序的性能差

良好的数据库设计：

• 节省内存空间
• 保证数据的完整性
• 方便系统开发

软件开发中关于数据库的设计

• 分析需求：分析业务和需要处理的数据库的需求
• 概要设计：设计关系图 E-R 图

2.数据库设计的规范（三大范式）

为什么需要数据规范化/p>

• 信息重复
• 更新异常
• 插入异常
• 删除异常

三大范式

• 第一范式：所有属性都是基本的，不可再分

对于一个关系模式R<U,F > 中的所有属性都是基本的，不可再分的，则R是第一范式；

• 简单来说就是一张表中的的任何属性不能再分为一一张表，即不能表中有表。
• 例如一张表 学生（Sno学号，Cno课程号，Grede成绩，Sdept系别，Sloc宿舍楼号），其每一个属性都不可再分。它就属于1NF。

• 第二范式：非主属性完全依赖于主键

对于一个关系模式R<U,F>∈1NF，且其任意一个非主属性完全依赖于主键，则关系模式R∈2NF。

作用：

• 用于消除1NF中的部分依赖
• 在1NF中 存在几种依赖的情况，其中（Sdept）部分依赖于（Sno，Cno），（Sloc）部分依赖于（Sno，Cno），这样在进行数据操作时容易产生异常，且数据冗余度大。

其中，成绩Grade由主键决定，但系别Sdept和宿舍楼Sloc只需要由学号Sno决定即可，所以存在非主属性Sdept和Sloc部分依赖主键（Sno,Cno）

由1NF分解得两张表SC，SL，它们的非主属性都完全依赖对应的主键，因此SC，SL∈2NF

• 第三范式：任何非主属性不依赖其他非主属性

对于一个关系模式R<U,F>∈2NF，其任何非主属性不依赖其他非主属性

• 用于消除2NF中的传递依赖
• 在2NF中的SL表中，对数据进行添加较大时（添加一个系下的多个学生信息），会发现Sdept和Sloc属性存在大量重复，或者某个系还没有学生时，主属性Sno就为空，这显然是不符合要求的。
  （每个系只用存一次对应的宿舍楼即可）

在这个表中，若某个系搬迁宿舍楼，只需要将Sdept对应的Sloc修改即可，即Sloc是依赖Sdept的，而Sdept是依赖Sno的，Sloc不是Sdept的子集，Sdept也不是Sno的子集，因此Sloc传递依赖Sno

SL分解后的两个表SD和DL中只存在一个一个非主属性，因此无法对另外的非主属性形成依赖，因此SD,SL,SC∈3NF。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树设计优化反范式设计31260 人正在系统学习中

来源：JohnGea