数据库逻辑设计


数据库设计
数据库逻辑设计
数据库物理设计
数据库维护和优化

逻辑设计是做什么的

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

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

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

所谓的逻辑设计就是根据需求分析之所了解到的应用中所需要存储的数据类型来建立数据库的逻辑模型的这么一个过程。所谓的逻辑模型是在任何数据库管理系统中都是通用的。

ER图就是实体关系模型
ER图中的概念:
关系:一个关系对应通常所说的一张表。
元组:表中的一行即为一个元组。
属性:表中的一列即为一个属性;每一个属性都有一个名称,称为属性名。
候选码:表中的某个属性组,他可以唯一确定一个元组。
主码:一个关系有多个候选码,选定其中一个为主码。
域:属性的取值范围。
分量:元组中的一个属性值。


逻辑设计规范

由于在逻辑设计中对同一个实体的存储方式可以有多种不同的设计,比如用户和购物车在这个实体,我们可以把购物车和用户信息存储在统一张表中,也可以分开去存储。这两种存储方式哪种更好一些,就要通过数据库设计的一些规范去进行选择,这也是数据设计的范式

数据库设计范式

如果我们符合这些范式的数据库设计就可以设计出简洁高效且结构清晰的数据库设计,同时可以避免数据库的插入更新和删除异常,也可以最大限度的避免数据库的冗余。同样如果比符合这种规范式的设计,那么可能就会存在数据的更新插入的异常,也可能会存在大量的数据冗余,这样就对数据库的使用造成很大的不便。

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

数据操作异常及数据冗余


可以看出如果一个表存在插入异常,那么必定也会存在删除异常和更新异常

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

如果数据库设计中存在大量的操作异常和数据冗余那么我们这个设计就是不符合数据库范式要求的,同时在使用中会给我们数据库的使用造成很大的不便,比如我们在插入和更新的时候可能会更新到其他并不应该更新的或者并不该删除的数据,而数据存在大量冗余会对我们数据一致性的维护造成很大的不便,有时候会漏掉某一个表的维护的话,那么就会造成数据一致性的异常。

第一范式

第一范式是在所有数据库范式中最简单的一种范式,也就是说我们最容易遵守的一种范式。


单一属性是指基本的数据类型所构成的,如整型、浮点型、字符串等等。

二维表指的是都是由行和列组成的表

在大多数数据库管理系统中都是不可能创建出第二个表这种结构的,这样的结构不符合数据库设计第一范式

第二范式


部分函数依赖指的是如果表中的关键字是组合关键字,是由两个或者两个以上的字段来标识这一行数据的,那么这个关键字就称之为组合关键字。而如果非关键字段对这个组合关键字中的某一个字段存在依赖关系这就称之为部分函数依赖。换句话说,如果这个表中是单关键字的那么他就是一定符合第二范式要求的。

下面看一个例子:

这样不符合第二范式的设计会出现下面问题:

如何解决这种问题,我们要对不符合第二范式的表进行拆分:

第三范式

例子:


BC范式

BC范式是对第三范式的扩展

例如表可以根据供应商和商品id为在组合关键字来唯一标识表中的每一行记录,同时可以以供应商联系人和商品id来唯一标识一行记录。
这两种标识方式的依赖关系是供应商和商品id决定了联系人和商品数量。
联系人和商品id可以决定供应商和商品数量。所以有两种组合关键字的选择。
这两组组合关键字又存在这样的关系:


供应商决定了供应商联系人
供应商联系人也可以决定供应商,因为一个供应商联系人之可以受雇于一家供应商,所以存在了这种相互依赖的关系,因此不符合BC范式
改进:


文章作者: 拾年
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 拾年 !
评论
 上一篇
数据库物理设计 数据库物理设计
数据库设计数据库逻辑设计数据库物理设计数据库维护和优化 物理设计要做什么 选择合适的数据库管理系统 定义数据库、表及字段的命名规范。 根据所选的DBMS系统选择合适的字段类型。 反范式化指的是在逻辑设计中已经确立好的非常规范的数据库结构模型
2020-05-11
下一篇 
单例设计模式 单例设计模式
单例模式定义保证一个类只有一个实例, 并且提供一个全局访问点 什么样的场景下需要使用单例?重量级的对象, 不需要多个实例.如线程池, 或者数据库的连接池. 我们希望我们直接从连接池里面拿连接就可以了, 而不是每次请求都去创建一个对应的连
2020-04-19
  目录