文章目录
4.3 数据库设计过程
- 基本内容
- 数据库设计过程与设计方法
- E-R图 / IDEF1X 向关系模型的转换
- 不正确数据库设计引发的问题及其解决
- 重点与难点
- 理解数据库设计的四个过程
- 理解不正确数据库设计引发的问题，为数据库理论的学习奠定问题基础
- 理解不正确数据库设计引发的问题，提升数据建模与数据库设计能力。
4.3.1 数据库设计的四个过程
-
需求分析 —— 收集需求和理解需求，“源”
-
概念数据库设计 —— 建立概念模型，“E-R图 / IDEF1x图”
-
逻辑数据库设计 —— 建立逻辑模型，“关系模式” 包括全局模式和用户模式（外模式）
表的定义、表中数据项的定义、表中数据示例…
-
物理数据库设计 —— 建立物理模型，“Create Table” 包括物理数据组织等，依赖于具体的DBMS
4.3.2 数据库设计过程之需求分析
-
需求分析概述
-
目标
理解企业、理解企业业务过程与数据处理流程、理解数据处理的性能需求。
-
提交物：需求分析报告
-
使以下内容清楚
- 企业的部门-岗位划分：不同岗位负责的各种日常管理信息表 / 报表
- 形成各种报表的基础数据表
- 各种数据表之间的处理关系 (What - How)
- 围绕数据表的业务处理关系 (Who - When - Where)
- 尚未实施但未来可能实施的需求
-
形成数据库设计的 ”源“ 清单和 ”属性“ 清单以及相关的详细描述，尤其是注意 业务规则 与 属性处理规则
-
结合数据流图等辅助分析与理解
-
-
“源”清单
注意收集和理解：
- 业务规则及其在表的处理方面的体现
- 不仅报表、单据是源，企业的查询需求与管理需求等也是源
-
“属性”清单
注意命名
- 命名要规范，并且要含义明确
- 尤其要注意类似于“数量”这样的多含义属性，比如“计划数量”，”采购数量“等
-
”属性“定义表
注意：准确理解对属性的业务规则，尤其是约束规则
例如：成绩只能取“优、良、中、及格、不及格”这五个值，工资只能升不能降等
-
小结
4.3.3 数据库设计过程之概念数据库设计
-
概念数据库设计概述
-
目标
进一步深入理解企业，对信息源进行抽象，发现信息（属性）之间的内在本质联系，这些联系可能隐藏于需求分析得到的信息员中。
-
提交物：概念数据库设计报告
-
使以下内容清楚
- 各种实体的发现、划分和定义
- 各种实体属性的发现、分析和定义
- 各种实体联系的发现、分析和定义
- 外部视图（模式）和概念视图（模式）的定义
-
用统一的表达方法，如 E-R模型 / IDEF1X模型给出描述；不仅绘画出来而且绘画正确。
用规范的数据模型表达，有助于更好的理解需求。
-
-
概念数据库设计的两种设计思路
先局部后全局
先全局后局部
-
局部E-R模式设计
-
-
全局E-R模式设计
-
全局E-R模式优化
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3N2WnVwA-1593838235995)(C:\Users\10030\AppData\Roaming\Typora\typora-user-images\image-20200704112703701.png)]-
-
-
概念数据库设计的可能冲突
-
属性冲突
- 属性域的冲突：属性的类型、取值范围不同
- 属性取值单位冲突
-
结果冲突
-
同一对象在不同应用中的抽象不同
如职工在某应用中是实体，在另一应用中则抽象为属性
-
同一实体在不同E-R图中属性组成不同
-
实体之间的联系在不同E-R图中呈现不同的类型
-
-
命名冲突
- 同名异义：不同意义的对象具有相同的名字
- 异名同义：同一意义的对象具有不同的名字
-
-
相关结果性内容示意
-
绘制不同层级的E-R图/IDEF1x图：实体级图、键级图及完整图
-
“实体”清单
-
“实体”定义表
注意：实体的规范化与非规范化的折中，并注意非规范化的处理要求
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ctAnxMYm-1593838235996)(C:\Users\10030\AppData\Roaming\Typora\typora-user-images\image-20200704113311868.png)]
-
“实体-联系”矩阵
-
“实体-属性”矩阵
-
-
小结
4.3.4 数据库设计过程之逻辑数据库设计
逻辑数据库设计概念
-
目标
用指定DBMS要求模式描述方法，给出概念数据库的模式描述。
-
提交物：逻辑数据库设计报告
-
使一下内容清楚
- 将E-R/IDEF1X转换成逻辑模式
- 遵循关系范式的设计原则
- 也要注意折中，但折中时需要提示应用开发者或 使用者可能存在的问题
- 外模式和概念模式的定义
-
用关系模型、网状模型或层次模型规定的模式描述方法进行描述
E-R图 / IDEF1X图向关系模式的转换 I
-
E-R图（Chen方法）
-
关系模式（Schema）
简记为
-
基本转换规则
-
实体 - 属性 - 关键字的转换
-
E-R图的 实体 转换为 关系
-
E-R图的 属性 转换为 关系的属性
-
E-R图的 关键字 转换为 关系的关键字
-
示例
-
-
复合属性的转换
-
将每个分量属性作为复合属性所在实体的属性
-
或者，将复合属性本身作为所在实体的属性
-
示例
-
-
多值属性的转换
- 将多值属性与所在实体的关键字一起组成一个新的关系
-
-
联系的转换
-
一对一联系
若联系双方均部分参与(0…1)，则将联系定义为一个新的关系，属性为参与双方的关键字属性
若联系一方全部参与(1…1) ，则将联系另一方的关键字作为全部参与一方关系的属性
-
一对多联系
将单方参与实体的关键字作为多方参与实体对应关系的属性
-
多对多联系
将联系定义为新的关系，属性为参与双方实体的关键字
-
-
弱实体的转换
所对应关系的关键字由弱实体本身的区分属性再加上所依赖的强实体的关键字构成
-
泛化与具体化实体的转换
-
高层实体(泛化实体)和低层实体(具体化实体)分别转为不同的关系
-
低层实体所对应的关系包括高层实体的关键字
-
如果泛化实体实例是具体化实体实例的全部，即一个高层实体实例至少属于一个低层实体，则可以不为高层实体建立关系，低层实体所对应的关系包括上层实体的所有属性
-
-
多元联系的转换
- 多元联系可以通过继承参与联系的各个实体的关键字而形成新的关系
- 这些继承过来的关键字可作为新关系的关键字
- 也可以新增一个区分属性作为关键字
- 注意这两种转换的差异
- 多元联系更需注意分析参与联系的实体的最小基数和最大基数
- 如是否允许参与联系的多实体中有一个或多个实体不参与？
- 多元联系可以转换为多个二元联系进行处理
-
只需关注实体转换成关系，而联系则无需关注
- IDEF1X图只需将实体转换成关系模式即可，而其联系的信息已经融入相关实体的关系描述中了
- 对IDEF1X图的分类联系，可以如E-R图中的泛化和具体化一样进行相关的处理；
- 对IDEF1X图的复合属性和多值属性，则如前面一样进行相关的处理
-
E-R图 / IDEF1X图向关系模式的转换 II
不正确设计数据库会引发什么问题
-
插入异常：
当一名新同学入学时，尚未指定系，则因系的有关信息不完整，便无法输入到数据库中，如上图所示。
-
删除异常：
当四系所有同学被删除后，则四系的有关信息则随之丢失
-
如何避免
-
什么是规范的数据库设计
- 数据库设计理论
- 数据依赖理论
- 关系范式理论
- 模式分解理论
- 数据库设计理论
小结
4.3.5 数据库设计过程之物理数据库设计
-
物理数据库设计概念
-
目标：
结合指定DBMS物理数据库管理方法，给出概念 数据库的物理模式描述。
-
提交物：物理数据库设计报告
-
使以下内容清楚：
- DBMS选型
- 确定数据库的存储结构，文件类型：如定长文件、 不定长文件；堆文件、散列文件或B-Tree文件等
- 用Triggers, 设计一些完整性控制约束
- 确定数据库的高效访问方式(索引访问，直接访问……)
- 评估和设置磁盘空间需求
- 设计用户视图及访问控制规则，以进行安全性控制
- 建立索引
- 设计使数据库运行达到最佳效率的一些措施
- 设计备份Backup和恢复Recovery的步骤
-
理解Oracle、Sybase或其他DBMS的物理数据库管理 方式，这是数据库管理员(DBA)的基本责任。
-
-
小结