数据库逻辑结构设计方法（一文看懂数据库设计之逻辑设计）

数据库逻辑设计是从事数据库应用设计、开发、运行维护等各方面工作的一个重要的基础性工作。根据不同业务和应用需求，确定并遵循数据库逻辑设计原则，例如按照第三范式开展逻辑设计，不仅能满足减少数据冗余、保证数据一致性和完整性、易扩展性和伸缩性等需求，也是保障系统高性能的一个重要基础。

1、全表扫描案例

从一个案例来看，例如查询“喜欢语文的所有学生”

--由于%号这里肯定是走了全表扫描 select id,name,hobby from student where hobby like '%语文%'；

2、原因

select id,name,hobby from student; ID NAME HOBBY --------------------- 1 小明 语文，数学 2 小红 英语，语文，数学 3 小林 英语，语文

可以看到如果是这么设计表的话，把学生的爱好都塞在一个字段HOBBY中，那么查询条件只能写成like '%语文%'。这里的根本原因是该表设计不符合规范化设计理论，从而导致了全表扫描。这里我们就可以看出逻辑设计的重要性了。

1、概念总结

1）将需求转化成数据库的逻辑模型

2）通过ER图的型式对逻辑模型进行展示

3）同所选用的具体的DBMS系统无关

2、名词解释

关系：一个关系对应通常所说的一张表

元组：表中的一行即为一个元组

修改后的：

通俗解释:

完全依赖：表中只有一个关键字(即主键)，其他属性的增删改查的时候定位到这一行都是依赖此关键字的。

第二范式：只能有一个主键，不能有复合主键，可以就满足了第二范式。

由于供应商和商品之间是多对多的关系，所以只有使用商品名称和供应商名称才可以唯一标识出一件商品，也就是商品名称和供应商名称是一组组合关键字。

上表中存在以下的部分函数依赖关系

(商品名称)—>(价格，描述，重量，商品有效期) (供应商名称)—>(供应商电话)

3、第三范式（没有一个非唯一标识属性依赖于另一个非唯一标识属性）

定义：第三范式是在第二范式的基础上定义的，如果数据表中不存在非关键字段，对任意候选关键字段的传递函数依赖则符合第三范式。

存在问题：

(分类，分类描述)对于每一个商品都会进行记录，所以存在数据冗余，同时也会存在数据deep插入、更新及删除异常。

4、BC范式

定义：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系

存在下列关系因此不符合BCNF要求：

(供应商)—>(供应商联系人) (供应商联系人)—>(供应商)

并且存在数据操作异常及数据冗余

第一，二，三范式解决的是非主属性的关系。BC 范式解决的是主属性的关系；

第一范式：就是原子性，字段不可再分割，（列属性不能在细分为子列）

第二范式：就是完全依赖，没有部分依赖；(非主属性不能依赖于主键的一部分，要完全依赖于主键（主键是复合键）)

第三范式：没有传递函数依赖。(非主属性之间的依赖)

BC范式： 解决部分主键依赖于非主键部分（复合关键字之间也不能存在函数依赖关系）。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~