数据库设计(二) 设计规范(三大范式、四大特性、四大隔离级别以及解决的三种问题)

一、设计问题

 由于不同的人从不同 的角度考虑问题,设计出的 E-R 就会有着不同的差别,因此要注意以下几个问题

信息重复:表中数据存在重复的信息,或使用相同含义不同字表述的类型,

更新异常:由于冗余的信息在进行更新时未全部进行更新,会导致数据出现错误,称为更新异常

插入异常:无法表示某些信息,如同一个宾馆的标间出现了不同的价格,导致插入时出现异常

删除异常:在删除某一行记录时,导致将房间类型表中的某一类型也删除掉了,称为删除异常

 

二、规范设计 

1、三大范式

在进行数据设计时,制定的一些规则,称为数据库设计范式 ,遵守这些规则将创建出良好的数据库,如经常听到的数据库三大范式

(1)、第一范式

  第一范式(Normal From,1NF)的目标是确保每列的原子性。

  如果每列(或属性)的都是不可再分的最小数据单元(或最小的原子单元)则满足第一范式

如:地址列 可以拆分为国家 ,省,市,县(区),镇,村(街道办事处)等几个 部分 

 

(2)、第二范式

  第二范式(2NF)在第一范式的基础上更近一步,目标是确保表中的每列都和主键相关。

  如果一个关系满足第一范式,并且除了主键以外,其他主键都全部依赖该主键则满足第二范式

如:订单详细表中有(订单详细编码,订单详细名,订单编号,订单名,订单类型,商品编码,商品名,商品单价,商品数量等)

  其中可以看出

  订单详细名 →  订单详细编码

  订单名,订单类型    →   订单编号

  商品名,商品单价,商品数量   →  商品编码

  其中 → 符号代表依赖,由于上述只有部分列依赖于主键,违背了第二 范式 可以对其进行拆分成 订单详细表,订单表,商品表三个表,通过主外键进行相互关联

 

(3)、第三范式

  第三范(3NF)是在第二范式的基础上更近一步,第三范式的目标是确保每列都和主键列直接相关,而不是间接相关

  如果一个关系满足第二范式,并且除了主键以外的其他列都只能依赖主键列,列与列之间不存在相互依赖关系,则满足第三范式

借助数学中的Armstrong 公理来判定,如  A、B、C、D 中是表中的四个列

  其中A 为主键, B →  A(B依赖A),C →  A,D →  A 如果其中还有,B →  C,C →  D 从这两个还可以推导出 B →  D,此时虽然满足第二范式,但是不满足第三范式

  只有 当 A 为主键时,有且只有 B →  A(B依赖A),C →  A,D →  A ,这三个依赖时才满足第三范式。

在现实的话如:商品表中有(商品编号,商品名,商品类型,商品规格,商品单价)

  其中虽然 商品名,商品类型,商品规格,商品单价 都依赖 主键商品编号,但是 商品规格,商品单价 依赖于商品类型

  由于不同类型的商品的 规格 和 单价不同

  因此还可以将其分为商品表和商品类型表,这样才满足第三范式

 

数据库设计(二) 设计规范(三大范式、四大特性、四大隔离级别以及解决的三种问题)

 

 

三、规范化和性能的关系

由于项目对于最终的用户来说,客人最关心的是方便清晰的数据结果,因此在设计数据库时,设计人员和客户对数据库的设计规范化与性能之间存在一定的矛盾。

如上为了满足数据库三大范式, 数据操作性能也随之受到了影响,毕竟查询一个表和查询 多个表的性能是不一样的,因此在实际设计时,既要考虑三大范式,避免数据的冗余和各种数据操作异常;又要考虑数据库的访问性能。可以使用的小操作有:为了减少表之间的连接,提高数据库性能,允许适当的冗余列

如:金额列存在不满足数据库设计的第三范式,因为金额可以通过单价乘以数量得到,但是增加后可以提过数据的处理速度,加快访问速度,便于直观展示,相对而言是一个比较好的冗余(对其形容 比较高级的说法叫以空间换取时间),但是,不要轻易 违反数据库设计的规范化原则。如果处理不好,可能会适得其反,使应用程序运行速度更慢。

 

数据库设计(二) 设计规范(三大范式、四大特性、四大隔离级别以及解决的三种问题)

上一篇:GraphQl in ASP.NET Core


下一篇:Jenkins结合.net平台工具之Msbuild