数据库设计之逻辑设计
逻辑设计
1：将需求转化成数据库的逻辑模型
2：通过ER图的型式对逻辑模型进行展示
3：同所选用的具体的DBMS系统无关
名词解释
关系：一个关系对应通常所说的一张表
元组：表中的一行即为一个元组
属性：表中的一列即为一个属性，每一个属性都有一个名称，称为属性名
候选码：表中的某个属性组，它可以唯一确定一个元组
主码：一个关系有多个候选码，选定其中一个为主码
域：属性的取值范围
分量：元组中的一个属性值
ER图例说明
矩形：表示实体集，矩形内写实体集的名字
菱形：表示联系集
椭圆：表示实体的属性
线段：将属性连接到实体集，或将实体集连接到联系集
数据操作异常及数据冗余
插入异常：如果某实体随着另一个实体的存在而存在，即缺少某个实体时无法表示这个实体，那么这个表就存在插入异常。
更新异常：如果更改表所对应的某个实体实例的单独属性时，需要将多行更新，那么就说这个表存在更新异常。
删除异常：如果删除表的某一行来反映某实体实例，失效时导致另一个不同实体实例信息丢失，那么这个表中就存在删除异常。
注意：若一个表中存在插入异常，那它肯定存在删除异常和更新异常。
数据冗余：是指相同的数据在多个地方存在，或者说表中的某个列可以由其他列计算得到，这样就说表中存在数据冗余。
第一范式
定义：数据库表中的所有字段都是单一属性，不可再分的。这个单一属性是由基本的数据类型所构成的，如整数，浮点数，字符串等，换句话说，第一范式要求数据库中的表都是二维表。(二维表就是由行和列组成的表)
第二范式
定义：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。
部分函数依赖是指存在着组合关键字中的某一关键字决定非关键字的情况。
换句话说：所有单关键字的表都符合第二范式。
修改后的
存在的问题：插入异常，删除异常，更新异常，数据冗余
通俗解释
完全依赖：表中只有一个关键字(即主键)，其他属性的增删改查的时候定位到这一行都是依赖此关键字的。
第二范式：只能有一个主键，不能有复合主键，可以就满足了第二范式。
由于供应商和商品之间是多对多的关系，所以只有使用商品名称和供应商名称才可以唯一标识出一件商品，也就是商品名称和供应商名称是一组组合关键字。
上表中存在以下的部分函数依赖关系
(商品名称)—>(价格，描述，重量，商品有效期)
(供应商名称)—>(供应商电话)
第三范式
定义：第三范式是在第二范式的基础上定义的，如果数据表中不存在非关键字段，对任意候选关键字段的传递函数依赖则符合第三范式。
存在问题：
(分类，分类描述)对于每一个商品都会进行记录，所以存在数据冗余，同时也会存在数据deep插入、更新及删除异常。
数据库设计三范式：
1NF：列不可分就满足1NF了。
2NF：不存在部分依赖，比如 (A,B)C。（消除非主属性对主属性的传递依赖，即完全依赖于主键）
3NF：不存在传递依赖，比如ABC。（在2NF基础上消除了传递依赖）
BC范式
定义：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系
存在下列关系因此不符合BCNF要求：
(供应商)—>(供应商联系人)
(供应商联系人)—>(供应商)
并且存在数据操作异常及数据冗余
总结
第一，二，三范式解决的是非主属性的关系。BC 范式解决的是主属性的关系；
第一范式：就是原子性，字段不可再分割，（列属性不能在细分为子列）
第二范式：就是完全依赖，没有部分依赖；【非主属性不能依赖于主键的一部分，要完全依赖于主键（主键是复合键）】
第三范式：没有传递函数依赖。【非主属性之间的依赖】
BC范式： 解决部分主键依赖于非主键部分（复合关键字之间也不能存在函数依赖关系）。