本文是作者黄钰朝的学习笔记，详细介绍了数据库设计的四个阶段：需求分析、概念模型设计、逻辑模型设计和物理模型设计，涵盖数据库设计规范如范式理论，并讨论了数据库关系建模及各种图表的重要性。通过学习，作者认识到数据库设计的规范化流程，包括从ER图到物理模型的逐步构建过程。
文章目录
作者信息
作者：黄钰朝
邮箱：kobe524348@gmail.com
日期：2019年7月12日
前言
今天学习的内容是数据库设计，包括理解数据库三大范式，概念模型和物理模型的区别，根据“大学教务管理系统”这一背景完成数据库设计文档。
主要学习：数据库设计的各个阶段，数据库设计的范式，数据库建模，相关的ER图，用例图，数据流图，系统流程图，数据字典，物理模型图等图表。
一.数据库设计的四个阶段
1.1 需求分析
分析用户活动，确定系统边界，描述系统中数据的流动，确定系统的功能
使用到：
- 数据流图
- 数据字典
1.2 概念模型设计
将系统中的数据抽象为实体，属性和联系的模型
使用到：
- ER图
1.3 逻辑模型设计
将概念模型具体化为DBMS支持的关系模型
1.4 物理模型设计
选择具体的物理存储方法，目标数据库和实施方案
使用到：
- 数据库表
二.数据库设计的规范
2.1 第一范式（原子性）
第一范式是要求每一列都是不可分割的，比如一个订单有多个商品，如果都写在一行记录里，那么商品一栏就有多个数据，也就是说，商品这一列已经不是不可分割的了，应该分成多行，让每行都是这个订单对应其中一个商品，这样就是一行记录只记一件事，每一列也就不可分割。
2.2 第二范式（消除部分依赖）
在满足第一范式的基础上，第二范式要求消除部分依赖，这是针对使用联合主键的情况，如果已经满足第一范式，又只有一个主键，那么自动满足第二范式。
如果使用了联合主键，那么第二范式要求，所有非主键的字段都要依赖于联合主键，而不能只依赖于主键中的部分字段。
比如假设有一张表使用订单id和商品id作为联合主键，那么如果表中还有商品名称，商品价格这些只依赖于商品id而与订单id无关的字段，就属于只依赖于部分主键的情况，要使其满足第二范式，应当将商品名称，商品价格这些对主键部分依赖的字段分离出去，否则如果很多订单都是买同一个商品，那么这个商品名称和商品价格就会在多行记录中重复出现，而且，如果要添加一个新的商品，那么由于没有订单信息，导致无法插入这张表，就非常荒诞了。
部分依赖带来以下问题：
- 数据重复
- 修改时要同时修改多处地方
- 可能导致无法插入需要保存的数据，如上面例子中的商品信息
2.3 第三范式（消除传递依赖）
在满足第一，第二范式的基础上，第三范式要求消除传递依赖。
传递依赖就是指，一个字段与主键不存在依赖关系，只是通过另外一个字段间接依赖主键。例如商品价格依赖于商品id，商品id依赖于主键订单id，那么商品价格对主键就是传递依赖。
第三范式要求不要把对主键间接依赖的字段放在表中。比如订单表中只要记商品id，剩下的商品的相关信息全部都分离出去。
传递依赖带来的问题和部分依赖相同。
2.4 BC范式
BC范式要求联合主键之间不能存在依赖关系
三.数据库关系建模
3.1 概念模型
概念模型就是在需求分析的基础上，抽象出来的实体，属性和关系。概念模型使用ER图来表示。
3.2 逻辑模型
逻辑模型时概念模型的具体化，需要将概念模型中的实体联系转化为关系模型。
3.3 物理模型
物理模型时逻辑模型的具体实现，需要选择目标数据库，使用具体的开发工具将表建立起来。
四.数据库设计文档的图表
PS:这些图表省略了具体定义和规范，直接放了自己的作业，而且可能画得并不规范
4.1 ER图
4.2 用例图
4.3 数据流图
4.4 系统流程图
4.5 数据字典
4.6 物理模型图
五.总结
之前做考核时设计数据库，都是看完需求文档，画一个思维导图，把各个功能模块划分一下，然后分析有哪些数据需要保存，要建哪些表，心里面构思一下各个表之间的主外键关系，就直接在mysql上开始建表，没有这些建立模型，画图的过程，到后面写考核报告的时候，完全干的就是逆向工程，看着数据表把ER图逆向画出来，看着自己实现的功能重新逆向一次需求分析，整个流程，很不规范，完全的“民间做法”。
现在学完了数据库设计，才知道数据库设计的整个流程，学到那些用例图，数据流图，系统流程图，才发现自己之前在草稿纸上分析的东西，是有一个标准的定义和规范的图表来描述的。而且这些数据模型的建立和实施，是有一个由概念到逻辑，再到物理的一步步具体化的过程，而不是直接从数据库建表开始。
今天的主要收获是自己动手画图的过程和导师指出问题然后纠错的过程中的体会，难以具体描述，略。
扫一扫
311
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
