数据库设计那些事——第2章 逻辑设计

2-1 ER图

逻辑设计是做什么的

1. 将需求转化为数据库的逻辑模型
2. 通过ER图的形式对逻辑模型进行展示
3. 与所选用的具体的DBMS系统无关

名词解释

关系：一个关系对应通常所说的一张表。
元组：表中的一行即为一个元组。
属性：表中的一列即为一个属性；每一个属性都有一个名称，称为属性名。
候选码：表中的某个属性组，它可以唯一确定一个元组。
主码：一个关系有多个候选码，选定其中一个为主码。
域：属性的取值范围。
分量：元组中的一个属性值。

ER图例说明

矩形：表示实体集，矩形内写实体集的名字
菱形：表示联系集
椭圆：表示实体的属性
线段：将属性连接到实体集，或将实体集连接到联系集

实例演示

2-2 设计范式概要

什么是数据库设计范式

常见数据库设计范式包括：
第一范式，第二范式，第三范式及BC范式
当然还有第四及第五范式，不过这里我们会把重点放到前三个范式上，这也是目前我们大多数数据库设计所要遵循的范式。

数据操作异常及数据冗余

• 操作异常
  • 插入异常：如果某个实体随着另一个实体的存在而存在，即缺少某个实体时无法表示这个实体，那么这个表就存在插入异常。
  • 更新异常：如果更改表所对应的某个实体实例的单独属性时，需要将多行更新，那么就说这个表存在更新异常。
  • 删除异常：如果删除表的某一行来反映某实体实例，失效时导致另一个不同实体实例信息丢失，那么这个表就存在删除异常。
• 数据冗余：是指相同的数据在多个地方存在，或者说表中的某个列可以由其他列计算得到，这样就说表中存在着数据冗余。

2-3 第一范式

第一范式(1NF)：数据库表中的所有字段都是单一属性，不可再分的。这个单一属性是由基本的数据类型所构成的，如整数，浮点数，字符串，等；换句话说，第一范式要求数据库中的表都是二维表。

2-4 第二范式

第二范式(2NF)：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。
部分函数依赖是指存在着组合关键字中的某一关键字决定非关键字的情况。
换句话说，所有单关键字段的表都符合第二范式。

由于供应商和商品之间是多对多的关系，所以只有使用商品名称和供应商名称才可以唯一标识出一件商品。也就是商品名称和供应商名称是一组组和关键字。
上表中存在以下的部分函数依赖关系
(商品名称) --> (价格，描述，重量，商品有效期)
(供应商名称) --> (供应商电话)
存在的问题：1.插入异常2.删除异常3.更新异常4.数据冗余

2-5 第三范式

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

存在以下传递函数依赖关系：
(商品名称)-->(分类)-->(分类描述)
也就是说存在非关键字段“分类描述”对关键字段“商品名称”的传递函数依赖。
存在问题：(分类，分类描述)对于每一个商品都会进行记录，所以存在着数据冗余。同时也存在数据的插入，更新及删除异常。

2-6 BC范式

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

假定：供应商联系人只能受雇于一家供应商，每家供应商可以供应多个商品，则存在如下决定关系：
(供应商，商品ID) --> (联系人，商品数量)
(联系人，商品ID) --> (供应商，商品数量)
存在下列关系因此不符合BCNF要求：
(供应商) -> (供应商联系人)
(供应商联系人) -> (供应商)
并且存在数据操作异常及数据冗余

慕课 数据库设计那些事 视频