2023年7月27日发(作者:)
数据库设计之逻辑设计逻辑设计
1:将需求转化成数据库的逻辑模型
2:通过ER图的型式对逻辑模型进⾏展⽰
3:同所选⽤的具体的DBMS系统⽆关名词解释关系:⼀个关系对应通常所说的⼀张表
元组:表中的⼀⾏即为⼀个元组
属性:表中的⼀列即为⼀个属性,每⼀个属性都有⼀个名称,称为属性名
候选码:表中的某个属性组,它可以唯⼀确定⼀个元组
主码:⼀个关系有多个候选码,选定其中⼀个为主码
域:属性的取值范围
分量:元组中的⼀个属性值ER图例说明矩形:表⽰实体集,矩形内写实体集的名字
菱形:表⽰联系集
椭圆:表⽰实体的属性
线段:将属性连接到实体集,或将实体集连接到联系集数据操作异常及数据冗余插⼊异常:如果某实体随着另⼀个实体的存在⽽存在,即缺少某个实体时⽆法表⽰这个实体,那么这个表就存在插⼊异常。
更新异常:如果更改表所对应的某个实体实例的单独属性时,需要将多⾏更新,那么就说这个表存在更新异常。
删除异常:如果删除表的某⼀⾏来反映某实体实例,失效时导致另⼀个不同实体实例信息丢失,那么这个表中就存在删除异常。注意:若⼀个表中存在插⼊异常,那它肯定存在删除异常和更新异常。数据冗余:是指相同的数据在多个地⽅存在,或者说表中的某个列可以由其他列计算得到,这样就说表中存在数据冗余。第⼀范式
定义:数据库表中的所有字段都是单⼀属性,不可再分的。这个单⼀属性是由基本的数据类型所构成的,如整数,浮点数,字符串等,换句话说,第⼀范式要求数据库中的表都是⼆维表。(⼆维表就是由⾏和列组成的表) 第⼆范式
定义:数据库的表中不存在⾮关键字段对任⼀候选关键字段的部分函数依赖。
部分函数依赖是指存在着组合关键字中的某⼀关键字决定⾮关键字的情况。
换句话说:所有单关键字的表都符合第⼆范式。
修改后的
存在的问题:插⼊异常,删除异常,更新异常,数据冗余通俗解释
完全依赖:表中只有⼀个关键字(即主键),其他属性的增删改查的时候定位到这⼀⾏都是依赖此关键字的。
第⼆范式:只能有⼀个主键,不能有复合主键,可以就满⾜了第⼆范式。由于供应商和商品之间是多对多的关系,所以只有使⽤商品名称和供应商名称才可以唯⼀标识出⼀件商品,也就是商品名称和供应商名称是⼀组组合关键字。
上表中存在以下的部分函数依赖关系
(商品名称)—>(价格,描述,重量,商品有效期)
(供应商名称)—>(供应商电话)第三范式
定义:第三范式是在第⼆范式的基础上定义的,如果数据表中不存在⾮关键字段,对任意候选关键字段的传递函数依赖则符合第三范式。 存在问题:
(分类,分类描述)对于每⼀个商品都会进⾏记录,所以存在数据冗余,同时也会存在数据deep插⼊、更新及删除异常。
数据库设计三范式:
1NF:列不可分就满⾜1NF了。2NF:不存在部分依赖,⽐如 (A,B)C。(消除⾮主属性对主属性的传递依赖,即完全依赖于主键)3NF:不存在传递依赖,⽐如ABC。(在2NF基础上消除了传递依赖)BC范式
定义:在第三范式的基础上,数据库表中如果不存在任何字段对任⼀候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字,则复合关键字之间也不能存在函数依赖关系 存在下列关系因此不符合BCNF要求:
(供应商)—>(供应商联系⼈)
(供应商联系⼈)—>(供应商)
并且存在数据操作异常及数据冗余
总结
第⼀,⼆,三范式解决的是⾮主属性的关系。BC 范式解决的是主属性的关系;第⼀范式:就是原⼦性,字段不可再分割,(列属性不能在细分为⼦列)
第⼆范式:就是完全依赖,没有部分依赖;【⾮主属性不能依赖于主键的⼀部分,要完全依赖于主键(主键是复合键)】
第三范式:没有传递函数依赖。【⾮主属性之间的依赖】
BC范式: 解决部分主键依赖于⾮主键部分(复合关键字之间也不能存在函数依赖关系)。参考视频:
发布者:admin,转转请注明出处:http://www.yc00.com/web/1690432564a349079.html
评论列表(0条)