第3讲总第13讲数据库设计过程

发表于 2019-12-03 更新于 2019-12-17 分类于数据库系统，中 Waline：本文字数： 6.9k 阅读时长 ≈ 6 分钟

数据库设计的四个过程
数据库设计过程之需求分析
需求分析
相关结果性内容
"源"清单
"属性"清单
"属性"定义表
数据库设计过程之概念数据库设计
(1)概念数据库设计
(2)概念数据库设计的两种设计思路
先局部后全局
先全局后局部
局部E-R模式设计
全局E-R模式设计
(3)概念数据库设计的可能冲突
消除冲突
全局E-R模式优化
(4)相关结果性内容示意
绘制不同层级的E-R图/IDEF1x图
实体级图
键级图
完整图
"实体"清单
"实体"定义表
"实体-联系"矩阵
"实体-属性"矩阵
(5)小结
数据库设计过程之逻辑数据库设计
(1)逻辑数据库设计
(2)E-R图向关系模式的转换
E-R图(Chen方法)
关系模式(Schema)
基本转换规则: 实体-属性-关键字的转换
示例
基本转换规则:复合属性的转换
示例
基本转换规则:多值属性的转换
示例
基本转换规则:联系的转换
一对一联系
部分参与
全部参与
一对多联系
多对多联系
基本转换规则:弱实体的转换
基本转换规则:泛化与具体化实体的转换
权衡
方案1
方案2
基本转换规则:多元联系的转换
2型转换示例
(3)IDEF1X图向关系模式转换
(4)不正确设计数据库会引发的问题
冗余
非受控冗余
受控冗余
删除异常
插入异常
如何避免数据库出现不一致的问题
当数据库设计满足规范时
当数据库设计不满足规范性
数据库设计理论
数据依赖理论
关系范式理论
模式分解理论
小结
数据库设计过程
逻辑数据库设计步骤
数据库设计过程之物理数据库设计
小结

数据库设计的四个过程

需求分析
- 收集需求和理解需求,”源”
概念数据库设计
- 建立概念模型,”E-R图/IDEF1x图”
逻辑数据库设计
- 建立逻辑模型,”关系模式”包括全局模式和用户模式(外模式)
- 表的定义;
- 表中数据项的定义
- 表中数据示例(测试用例)
物理数据库设计
- 建立物理模型,包括物理数据组织等,依赖于具体的DBMS.
- 相关命令:Create Table,Create Index

数据库设计过程之需求分析

需求分析

目标:理解企业、理解企业业务过程与数据处理流程、理解数据处理的性能需求
提交物:需求分析报告
使以下内容清楚:
- 企业的部门-岗位划分:不同岗位负责的各种日常管理信息表/报表
- 形成各种报表的基础数据表
- 各种数据表之间的处理关系(What–How)
- 围绕数据表的业务处理关系(Who—When–Where)
- 尚未实施但未来可能实施的需求
- 形成数据库设计的"源"清单和"属性"清单以及相关的详细描述,尤其是注意业务规则与属性处理规则
- 结合数据流图等辅助分析与理解

数据库设计过程之概念数据库设计

(1)概念数据库设计

目标:进一步深入理解企业,对信息源进行抽象,发现信息(属性)之间的内在本质联系,这些本质联系可能隐藏于需求分析得到的信息源中。
提交物:概念数据库设计报告
使以下内容清楚:
- 各种实体的发现、划分和定义
- 各种实体属性的发现、分析和定义
- 各种实体联系的发现、分析和定义
- 外部视图(模式)和概念视图(模式)的定义
用统一的表达方法,如E-R模型/IDEF1X模型给出描述;不仅绘制出来,而且绘制正确;

用规范的数据模型表达,有助于更好的理解需求
数据模型不仅是自己理解而且要让相关人员理解

(2)概念数据库设计的两种设计思路

先局部后全局
先全局后局部

先局部后全局

需求调研/用户不完整的局部需求
设计外部模式或视图
外部模式或视图
合并视图
设计概念数据库模式
概念数据库模式

先全局后局部

需求调研/用户不完整的局部需求
合并局部需求
设计概念数据库模式
概念数据库模式
设计外部模式或视图
外部模式或视图

局部E-R模式设计

需求分析的”源”
确定局部结构范围
实体定义
联系定义
属性分配
全局E-R模式设计

全局E-R模式设计

局部E-R模式
确定公共实体类型
合并两个局部E-R模式
检查并消除冲突
还有未合并的局部模式?如果有,则转到第3步,如果没有则继续下一步
全局E-R模式优化

(3)概念数据库设计的可能冲突

消除冲突

属性冲突
- 属性域的冲突:属性的类型、取值范围不同
  - 如不同学校的学号编码方式不同
- 属性取值单位冲突
  - 如重量分别采用磅、千克
结构冲突
- 同一对象在不同应用中的抽象不同
  - 如职工在某应用中是实体,在另一应用中则抽象为属性
- 同一实体在不同E-R图中属性组成不同
- 实体之间的联系在不同E-R图中呈现不同的类型
命名冲突
- 同名异义:不同意义的对象具有相同的名字
- 异名同义:同一意义的对象具有不同的名字

全局E-R模式优化

全局E-R模式
合并实体类型
消除冗余属性
消除冗余联系
逻辑数据库设计

(4)相关结果性内容示意

绘制不同层级的E-R图/IDEF1x图

实体级图、键级图及完整图:

实体级图

以实体为建模单位的IDEF1x图

键级图

以实体为建模单位并且标注键属性的IDEF1x图

完整图

以实体为建模单位并且标注所有属性的IDEF1x图

“实体”清单

“实体”定义表

“实体-联系”矩阵

有联系的实体之间会有继承属性

“实体-属性”矩阵

注释:O:实体的占有属性,I:实体的继承属性(通常就是外键),K:实体的主键属性

(5)小结

依据需求分析报告
识别实体与联系
绘制E-R图/IDEF1x图用图表达业务规则
定义实体、联系及实体的属性构成,这部分最重要的是消除冲突
形成并提交概念数据库设计报告

需求分析
概念数据库设计<-当前阶段
逻辑数据库设计
物理数据库设计

数据库设计过程之逻辑数据库设计

(1)逻辑数据库设计

目标:用指定DBMS要求的模式描述方法,给出概念数据库的逻辑模式描述。
提交物:逻辑数据库设计报告
使以下内容清楚:
- 将E-R/IDEF1X转换成逻辑模式
- 遵循关系范式的设计原则
- 也要注意折中,但折中时需要提示应用开发者或
- 使用者可能存在的问题
- 外模式和概念模式的定义
用关系模型、网状模型或层次模型规定的模式描述方法进行描述

(2)E-R图向关系模式的转换

E-R图(Chen方法)

关系模式(Schema)

$$
R(A_1:D_1,A_2:D_2,…,A_n:D_n)
$$
其中

$R$为关系模式的名称
$A_n$为关系模式的属性
$D_n$为属性$A_n$的取值范围(域)

简记为:
$$
R(A_1,A_2,…,A_n)
$$

基本转换规则: 实体-属性-关键字的转换

示例

$图书(\underline{书号},书名,出版日期,出版社)$
$读者(\underline{借书证号} ,姓名,年龄,性别,家庭住址)$
$书架(\underline{书架号,房间号} )$

基本转换规则:复合属性的转换

将每个分量属性作为复合属性所在实体的属性
或者将复合属性本身作为所在实体的属性

示例

$学生(\underline{学号}, 姓名, 年, 月, 日)$
或者
$学生(\underline{学号}, 出生日期, 姓名)$

基本转换规则:多值属性的转换

将多值属性与所在实体的关键字一起组成一个新的关系

示例

$学生(\underline{学号},姓名)$
$选课(\underline{学号,所选课程号})$

基本转换规则:联系的转换

一对一联系

部分参与

若联系双方均部分参与(0..1)，则将联系定义为一个新的关系，属性为参与双方的关键字属性

$职工(\underline{职工号},…)$
$配偶(\underline{丈夫职工号},\underline{妻子职工号})$

全部参与

若联系一方全部参与(1..1) ，则将联系另一方的关键字作为全部参与一方关系的属性

$职工(\underline{职工号}, …)$
$部门(\underline{部门号}, 部门名, 职工号)$

一对多联系

将单方参与实体的关键字作为多方参与实体对应关系的属性
多方实体继承单方实体的主关键字作为属性

$教师(\underline{教工号}, …)$
$学生(\underline{学生号},学生名,班主任教工号)$

$职工(\underline{职工号}，职工名，部门号，领导职工号)$

多对多联系

将联系定义为新的关系，属性为参与双方实体的关键字

$学生(\underline{学生号}, …)$
$课程(\underline{课程号}, …)$
$选修(\underline{学生号}, \underline{课程号}, 成绩)$

$零件(\underline{零件号}, …)$
$构成(\underline{父零件号},\underline{子零件号}, …)$

基本转换规则:弱实体的转换

所对应关系的关键字由弱实体本身的区分属性再加上所依赖的强实体的关键字构成

$产品(\underline{产品名},价格,\underline{公司名})$
弱实体集(从属实体)与强实体集(独立实体)之间的联系已经在弱实体集所对应的关系中表示出来了

基本转换规则:泛化与具体化实体的转换

高层实体(泛化实体)和低层实体(具体化实体)分别转为不同的关系
低层实体所对应的关系包括高层实体的关键字

$学生(\underline{学号},姓名)$
$本科生(\underline{学号},军训)$
$研究生(\underline{学号},论文)$

如果泛化实体实例是具体化实体实例的全部，即一个高层实体实例至少属于一个低层实体，则可以不为高层实体建立关系，低层实体所对应的关系包括上层实体的所有属性

学生(姓名,学号) //如果概括是全部的,无须创建”学生”关系
$本科生(姓名,\underline{学号},军训)$
$研究生(姓名,\underline{学号},论文)$

权衡

如何转换如下的E-R图

方案1

$person(\underline{name}, street, city)$
$customer(\underline{name}, credit-rating)$
$employee(\underline{name}, salary)$
缺点:查询employee的地址需要访问两个表(employee,和person)

方案2

$person(\underline{name}, street, city)$
$customer(\underline{name}, street, city, credit-rating)$
$employee(\underline{name}, street, city, salary)$
如果泛化实体实例是具体化实体实例的全部,无须创建person表
缺点:如果一个人既是顾客又是员工,那么他的新将存储两次

基本转换规则:多元联系的转换

多元联系可以通过继承参与联系的各个实体的关键字而形成新的关系
这些继承过来的关键字可作为新关系的关键字
也可以新增一个区分属性作为关键字
注意这两种转换的差异
多元联系更需注意分析参与联系的实体的最小基数和最大基数,如是否允许参与联系的多实体中有一个或多个实体不参与?
多元联系可以转换为多个二元联系进行处理

1型转换:$供应(\underline{工程项目号},\underline{供货商号},\underline{零件号},数量)$
2型转换:$供应(\underline{条目号},工程项目号,供货商号,零件号,数量)$

对于新增一个区分属性的2型转换,工程项目号,供货商号,零件号这些由于都是非主属性,所以可以为空

2型转换示例

可以得到如下关系模式

(3)IDEF1X图向关系模式转换

基本转换规则:只需关注实体转换成关系,而联系则无需关注

IDEF1X图只需将实体转换成关系模式即可，而其联系的信息已经融入相关实体的关系描述中了
对IDEF1X图的分类联系，可以如E-R图中的泛化和具体化一样进行相关的处理；
对IDEF1X图的复合属性和多值属性，则如前面一样进行相关的处理

(4)不正确设计数据库会引发的问题

冗余

冗余:数据库中存在大量冗余

非受控冗余

非受控冗余
非受控冗余问题:
- 当数据发生改变时,冗余的数据不会被数据库自动更新,需要数据库的用户来更新。
- 例如郑东这个老师,职称升级为教授时,需要修改多条记录,容易出错

受控冗余

如Table中的外键(继承其他Table中的键值),外键可以自动更新.

将上面的关系拆如下分成两个关系,虽然还是有冗余,但是要修改老师职称的话,只需要修改一条记录即可.

删除异常

删除异常:当四系所有同学被删除后,则四系的有关信息则随之丢失。如上图所示.

插入异常

示例1:
如上图所示,当一名新同学入学时,尚未指定系,则因系的有关信息不完整,便无法输入到数据库中,
示例2:

如何避免数据库出现不一致的问题

当数据库设计满足规范时

由DBMS或数据库本身来保证

当数据库设计不满足规范性

由使用者或应用程序员使用过程中加以注意

数据库设计理论

数据依赖理论

函数依赖
部分函数依赖/完全函数依赖
传递函数依赖
多值依赖
联结依赖

关系范式理论

1NF
2NF
3NF
BCNF
4NF
5NF

模式分解理论

无损连接分解
保持依赖分解

小结

数据库设计过程

需求分析
概念数据库设计
逻辑数据库设计<—当前位置
物理数据库设计

逻辑数据库设计步骤

依据概念数据库设计报告
将E-R图/IDEF1x图转换为关系模型
使用数据库设计理论检查逻辑数据库设计的正确性
定义全局模式和外模式
形成并提交逻辑数据库设计报告

数据库设计过程之物理数据库设计

目标:结合指定DBMS物理数据库管理方法,给出概念数据库的物理模式描述。
提交物:物理数据库设计报告
使以下内容清楚：
DBMS选型
- 确定数据库的存储结构，文件类型：如定长文件、不定长文件；堆文件、散列文件或B-Tree文件等
- 用Triggers, 设计一些完整性控制约束
- 确定数据库的高效访问方式(索引访问，直接访问……)
- 评估和设置磁盘空间需求
- 设计用户视图及访问控制规则，以进行安全性控制
- 建立索引
- 设计使数据库运行达到最佳效率的一些措施
- 设计备份Backup和恢复Recovery的步骤
理解Oracle、Sybase或其他DBMS的物理数据库管理方式,这是数据库管理员(DBA)的基本责任。

物理数据库设计与具体的数据库管理系统(Oracle,MySQL)相关

小结

依据逻辑数据库设计报告
利用具体DBMS，创建数据库/表
确定物理存储方式与存储空间
创建索引、视图等
形成并提交物理数据库设计报告

这阶段需要的知识:

数据库管理系统的实现技术—数据库存储与索引技术，查询实现与优化技术等
数据库系统理论 + 具体数据库管理系统软件产品相关的知识