数据库设计
作者：互联网
目录
一、数据库设计概述
1、数据库设计内容
- 解决数据的抽象、数据的表达和数据的存储等问题
- 设计出满足应用要求，简洁、高效、规范合理的数据库
- 得到在DBMS中存储的数据库的逻辑结构和物理结构
2、数据库设计方法
- 根据经验进行直观设计
- 运用软件工程的思想进行规范设计
- 用计算机进行辅助设计
- 使用设计工具软件自动进行设计
3、规范设计法
- 需求分析
- 概念设计：用E-R模型设计数据库的概念模型
- 逻辑设计：用关系规范化理论设计数据库模式
- 物理设计
4、数据库设计阶段
| 任务 | 方法 | |
| 需求分析 | 1、分析用户以及应用系统的数据需求 2、明确在数据库中需要存储和管理的数据 3、明确用户对数据的安全性和完整性方面的需求 4、用户的存储权限的设置 | 采取结构化系统分析和设计技术
|
| 概念结构设计 | 借助概念模型，表达数据抽象的结果，得到独立于具体的DBMS的概念模型 | 1、E-R模型 2、UML统一建模语言 3、IDEF1x方法 |
| 逻辑结构设计 | 对于关系模型，将概念模型转换为关系数据库模式 | 1、遵循转换规则 2、运用关系规范化理论 |
| 物理结构设计 | 1、定义数据库模式 2、确定适合应用环境的存储结构和存储方法 | 用数据定义语言 |
| 数据库实施 | 1、建立数据库 2、进行数据库编程 3、组织数据入库 4、测试数据库 | |
| 数据库运行维护 | 1、对数据库进行评估 2、完善数据库
|
二、数据库概念结构设计
1、引言
2、概念结构设计步骤
- 抽取实体与实体的属性并绘制实体的E-R图
- 确定实体间的联系，以及发生联系后产生的属性特征，绘制联系的E-R图
- 组合实体与联系的E-R图，构造应用系统的完整E-R图
设计思考1：对象抽象为实体集还是属性？
- 对需要进一步描述的对象，并需要处理该对象与其他实体间的联系，将对象抽象为实体
- 若对象只用来描述另一个实体，将对象抽象为属性
设计思考2：多个实体间的联系设计为二元联系还是多元联系？
- 基于一个联系的语义描述，以及涉及的实体，确定是二元联系还是多元联系
- 在多元联系中，若用户只需要考虑两两实体间的联系，可考虑采用多个二元联系来实现
设计思考3：设计为实体的属性还是联系的属性？
- 实体的属性：实体的内在特征
- 联系上的属性：
描述因联系发生而需要记录、存储的信息
其值会随着联系的产生而出现，也会随着联系的消失而消失
3、概念结构设计方法
（1） 集成过程中存在的结构冲突
同一对象的抽象结果不同——抽象为实体
同一实体的属性组成不同——合并属性
实体间的联系不同——统一联系名和类型：属性名统一和合并属性
（2）集成过程中存在冗余的属性或联系
通过其他属性的值可以推导出其值的属性
通过其他实体间的联系可以推导出来的两个实体间的联系
————去除冗余
三、数据库逻辑结构设计
1、实体的转换
一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的关键字就是关系的主键
2、实体间联系的转换
- 联系的类型有1:1、1:n、m:n，每种类型都有相应的转换规则
- 联系可单独转换为一个关系模式，也可不单独转换为一个关系模式
- 在关系模式中，应体现相关实体的关联性，以及联系本身的属性
3、1:1联系的转换
（1）联系单独转换为一个关系模式
- 关系模式的属性由参与联系的各实体的关键字以及该联系本身的属性构成
- 每个实体的关键字均可作为该关系模式的主键
- 每个实体的关键字均为该关系模式的外键
（2）联系不单独对应一关系模式
- 在任意一端实体所对应的关系模式中增加联系本身的属性以及另一端实体的关键字
- 主键仍为原关系模式的主键
- 另一端实体的关键字为该关系模式的外键
4、1：n联系的转换
（1）联系单独转换为一个关系模式
- 关系模式的属性由参与联系的各实体的关键字以及该联系本身的属性构成
- 主键为n端实体的关键字
- 每个实体的关键字均为该关系模式的外键
（2）联系不单独对应一关系模式
- 在n端实体所对应的关系模式中增加联系本身的属性以及1端实体的关键字
- 原关系模式的主键不变
- 1端实体的关键字为该关系模式的外键
5、m:n联系的转换
（1）联系单独转换为一个关系模式
- 关系模式的属性由参与联系的各实体的关键字以及联系本身的属性构成
- 各实体的关键字属性组合构成主键
- 每个实体的关键字均为该关系模式的外键
6、多元联系的转换
- 只有一个多端实体，按1:n联系的转换规则进行转换，可单独转换为一个关系模式；也可不单独转换为一个关系模式
- 有多个多端实体，按m:n联系的转换规则进行转换，需转换为一个单独的关系模式
7、子实体和ISA联系的转换
- 子实体单独转换为一个关系模式，关系模式的属性由超类实体的关键字和子实体本身的属性构成
- 超类实体的关键字作关系模式的主键
- 超类实体的关键字作为关系模式的外键
8、弱实体和依赖联系的转换
- 弱实体单独转换为一个关系模式，关系模式的属性由常规实体的关键字和弱实体本身的属性构成
- 常规实体与弱实体的关键组组合构成主键
- 常规实体的关键字作为关系模式的外键
9、逻辑结构设计原则
- 按转换规则将E-R图中的实体和联系转换为关系模式，遵循的是“一事一地”的模式设计原则
- 数据库模式中每个关系描述的信息单一，仅描述一个实体或实体之间的一种联系
10、关系模式的优化
关系模式的优化是为提高数据库应用系统的性能，根据应用需求适当修改，调整关系模式的结构
- 以关系规范化理论为指导，根据范式要求，将关系模式规范化为3NF或BCNF
- 对关系模式进行合并，减少关系的连接操作对系统查询性能的影响
并不是规范化程度越高的关系模式就越优
对低于BCNF的关系模式，不执行更新操作，则不会产生实际影响
规范化程度需要权衡查询响应时间和更新操作问题两者的利弊
四、数据库物理结构设计
1、数据库的物理结构设计解决的问题
- 数据库存储结构设计：解决数据文件中记录的存储信息，使应用所要访问的记录尽量存储在同一磁盘块上，对磁盘的I/O操作次数最少
- 数据库存取方法设计：解决如何尽快找到所需记录，找到记录所在磁盘块的磁盘I/O操作次数最少
2、定义数据库模式结构
用SQL定义关系数据库三级模式结构
- 库名称、库文件名称
- 库中表的名称，表中各属性的名称及数据类型
- 视图名称及其属性名称
- 索引名称
3、定义内模式
- 索引是DBMS所采用的主要存取方法，DBMS可基于索引制定优化查询计划，提高数据查询的效率
- 索引的创建可确定数据文件的存储结构
4、物理结构设计策略
- 通过改变存储结构，提高存取效率
- 通过完善数据布局，减少访问磁盘的I/O操作的次数
- 有效利用多磁盘驱动器的并发存取能力，加快存取数据的速度
5、总结
五、本讲小结
数据库设计是基于应用系统需求分析中对数据的需求，解决数据的抽象、数据的表达和数据的存储等问题，其目标是设计出一个满足应用要求，简洁、高效、规范合理的数据库。最终得到能在DBMS中存储的数据库的逻辑结构和物理结构。
数据库设计方法从早期根据经验进行直观设计，到运用软件工程的思想进行规范化设计，已发展到用计算机进行辅助设计，和使用设计工具软件自动进行设计。
以基于E-R模型的规范设计方法为基础，通常将数据库设计分为需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施、数据库的运行、维护阶段等六个阶段。
需求分析是整个数据库设计的基础，主要来准确了解与分析用户以及应用系统的数据需求，明确在数据库中需要存储和管理哪些数据，明确用户对数据的安全性和完整性方面的需求，以及用户的存取权限的设置等。
概念结构设计是整个数据库设计的关键。在需求分析的基础上，需要借助概念模型，如E-R模型，来表达数据抽象的结果，得到一个独立于具体的DBMS的概念模型。
逻辑结构设计把概念结构设计得到的概念模型转换为选定的DBMS支持的数据模型所对应的数据库模式，如关系数据库模式，并对其进行优化。
物理结构设计为逻辑结构设计得到的数据库模式，利用选定的DBMS支持的数据定义语言描述数据库的三级模式结构，确定适合应用环境的存储结构和存取方法。
数据库实施阶段，在具体的DBMS上，实现物理结构设计的结果，建立数据库，进行数据库编程，组织数据入库，并进行测试操作等。
对正式投入使用的数据库，在系统运行过程中需要不断地对其进行评估与完善。
数据库设计是上述六个阶段的不断反复迭代，逐步求精的过程。数据库设计同时伴随着数据库系统应用软件的设计，在设计过程中需要把两者加以结合，相互完善。
标签：联系,数据库,实体,模式,设计,结构设计,属性 来源： https://blog.csdn.net/L_zhai/article/details/118650439