数据库2—逻辑设计

概念：

1、将需求转化为数据库的逻辑模型

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

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

名词解释：

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

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

属性：表中的一列即为一个属性；每一个属性都有一个名称，称为属性名。

候选码：表中的某个属性组，他可以唯一确定一个元祖

主码：一个关系有多个候选码，选定其中一个为主码

域：属性的取值范围

分量：元祖的一个属性值

ER图例说明：

矩形：表示实体集，矩形内写实体集的名字

菱形：表示联系集

椭圆：表示实体的属性

线段：将属性连接到实体集，或将实体集连接到联系集

设计范式概要：

用户信息和购物车信息一张表

还是用户信息一张表，购物车信息一张表

常见的数据库设计范式包括：

第一范式，第二范式，第三范式及BC范式

这也是目前我们大多数数据库设计索要遵循的范式

数据操作异常及数据冗余

插入异常：如果某实体随另一个实体的存在而存在，即缺少某个实体时无法表示这个实体，那么这个表就存在插入异常

更新异常：如果更改表所对应的某个实体实例的单独属性时，需要将多行更新，那么就说明这个表存在更新异常

删除异常：如果删除表的某一行来反映某实体实例，失效时导致另一个不同实体实例信息丢失，那么这个表中就存在删除异常

数据冗余：是指相同的数据在多个地方存在，或者说表中的某个列可以由其他列计算得到，这样就说明表中存在着数据冗余

第一范式（1NF）

定义：数据库表中所有字段都是单一属性，不可再分的。

这个单一属性是由基本的数据类型所构成的，如整数，浮点数，字符串等

换句话说，第一范式要求数据库中的表都是二维表，不是表中表

第二范式（2NF）

定义：数据库的表中不存在非关键字段对任一候选关键字的部分函数依赖

部分函数依赖是指存在着组合关键字中的某一关键字决定非关键字的情况。

换句话说：所有单关键字段的表都符合第二范式

（以下面的商品表为例来说明2NF）

是由两个关键字段来标识这一行数据的，称之为组合关键字

由于供应商和商品之间是多对多的关系

所以只有使用商品名称和供应商名称才可以唯一标识出一件商品

也就是商品名称和供应商名称是一组组合关键字

上表中存在一下的部分函数依赖

（商品名称）—>（价格，描述，重量，商品有效期）

（供应商名称）—>（供应商电话）

存在的问题：1.插入异常    2.删除异常    3.更新异常    4.数据冗余

第三范式（3NF）

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

存在以下转递函数依赖关系：

（商品名称）—>（分类）—>（分类描述）

也就是说存在非关键字段”分类描述“

对关键字段”商品名称“的传递函数依赖

存在问题：（分类，分类描述）对于每一个商品都会进行记录，所以存在着数据冗余。同时还存在着数据的插入，更新及删除异常

对第三范式的扩展，BC范式：

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

也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系。

（以商品同供应商的关系表来说明BCNF）

假定：供应商联系人只能受雇于一家供应商，每家供应商可以供应多个商品，则存在如下决定关系：

（供应商，商品ID）—>（联系人，商品数量）

（联系人，商品ID）—>（供应商，商品数量）

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

（供应商）—>（供应商联系人）

（供应商联系人）—>（供应商）

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

总结：

1NF：列不可分就满足1NF了。

2NF：不存在部分依赖，比如（A，B）—>C。（消除非主属性对主属性的传递依赖，即完全依赖于主键）

3NF：不存在传递依赖，比如A—>B—>C。（在2NF基础上）