目录
- 前言
- 第12章 软件系统分析与设计
- 12.2 数据库分析与设计
- 12.2.1 数据库设计的策略与步骤
- 12.2.2 需求分析
- 12.2.3 概念结构设计
- 12.2.4 逻辑结构设计
- 12.2.5 数据库的物理设计
- 结语
前言
在备考软件设计师中级考试的过程中,我遇到了些许挑战,也收获了宝贵的经验。为了帮助其他同样正在为这门考试(证书)奋斗的朋友们,我决定将我的笔记整理出来,与大家分享。这些笔记不仅包含了书本上的知识,还加入了我对重点和难点的个人理解以及考试技巧,力求帮助大家更加高效地复习。我希望这份笔记能够成为你备考路上的一份支持,也祝愿你在考试中取得理想的成绩????????????
如果有写的不好或者需要改进的地方,恳请在评论区指正!????????????
请结合第九章一起阅读,第九章数据库技术基础,因为此篇考点,归纳为数据库技术基础。
第12章 软件系统分析与设计
12.2 数据库分析与设计
12.2.1 数据库设计的策略与步骤
- 数据库设计的策略
- 数据库设计的步骤
- 用户需求分析。数据库设计人员采用一定的辅助工具对应用对象的功能、性能和限制等要求所进行的科学分析。
- 概念设计。概念结构设计是对信息分析和定义,如视图模型化、视图分析和汇总。该阶段对应用对象精确地进行抽象和概括,以形成独立于计算机系统的企业信息模型。描述概念模型较理想的是采用 E-R方法。
- 逻辑设计。关系规范化在数据库设计的
逻辑设计
阶段进行。将抽象的概念模型转化为与选用的 DBMS 产品所支持的数据模型相符合的逻辑模型,它是物理设计的基础,包括模式初始设计、子模式设计、应用程序设计、模式评价以及模式求精。 - 物理设计。逻辑模型在计算机中的具体实现方案。当各阶段发现不能满足用户需求时,均需返回到前面适当的阶段,进行必要的修正。如此经过不断地迭代和求精,直到各种性能均能满足用户的需求为止。
12.2.2 需求分析
需求分析是在项目确定之后,用户和设计人员对数据库应用系统所要涉及的内容(数据)和功能(行为)的整理和描述,是以用户的角度来认识系统。这一过程是后续开发的基础,以后的逻辑设计和物理设计以及应用程序的设计都会以此为依据。
-
需求分析的任务、目标及方法
- 信息要求。
- 处理要求。
- 系统要求。
需求分析阶段的工作以及形成的相关文档(作为概念结构设计阶段的依据)如图12-7所示。
-
需求分析阶段的文档
需求调查所得到的数据可能是零碎的、局部的,分析师和设计人员必须进一步分析和表达用户的需求,建立需求说明文档、数据字典和数据流程图。将需求调查文档化,文档既要被用户所理解,又要方便数据库的概念结构设计。
需求分析阶段的成果是系统需求说明书,主要包括数据流图、数据字典、各种说明性表格、统计输出表和系统功能结构图等。系统需求说明书是以后设计、开发、测试和验收等过程的重要依据。关于需求分析的详细过程请参见第5.3节****
12.2.3 概念结构设计
-
概念结构设计策略与方法
-
用E-R方法建立概念模型
E-R 图的设计要依照上述的抽象机制,对需求分析阶段所得到的数据进行分类、聚集和概括,确定实体、属性和联系。概念结构的具体工作步骤包括选择局部应用、逐一设计分 E-R图和 E-R 图合并,如图12-8所示。- 选择局部应用。
- 逐一设计E-R图。
- E-R图合并。
- 属性冲突。同一属性可能会存在于不同的分E-R图,由于设计人员不同或是出发点不同,对属性的类型、取值范围和数据单位等可能会不一致,这些属性对应的数据将来只能以一种形式在计算机中存储,这就需要在设计阶段进行统一。
- 命名冲突。相同意义的属性在不同的分 E-R 图上有着不同的命名,或是名称相同的属性在不同的分 E-R 图中代表着不同的意义,这些也要进行统一
- 结构冲突。同一实体在不同的分 E-R 图中有不同的属性,同一对象在某一分E-R 图中被抽象为实体,而在另一分 E-R图中又被抽象为属性,需要统一。
12.2.4 逻辑结构设计
-
E-R图关系模型的转换
- 实体向关系模式的转换
将E-R 图中的实体逐一转换成为一个关系模式,实体名对应关系模式的名称,实体的属性转换成关系模式的属性,实体标识符就是关系的码(键)。 - 联系向关系模式的转换
- 一对一联系的转换。一对一联系有两种方式向关系模式进行转换。一种方式是将联系转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性包括该联系所关联的两个实体的码及联系的属性,关系的码取自任一方实体的码;【常用】另一种方式是将联系归并到关联的两个实体的任一方,给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可,归并后的实体码保持不变。
- 一对多联系的转换。一对多联系有两种方式向关系模式进行转换。【不用】一种方式是将联系转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性取该联系所关联的两个实体的码及联系的属性,关系的码是多方实体的码;【常用】另一种方式是将联系归并到关联的两个实体的多方,给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可,归并后的多方实体码保持不变。
- 多对多联系的转换。多对多联系只能转换成一个独立的关系模式,关系模式的名称取联系的名称,关系模式的属性取该联系所关联的两个多方实体的码及联系的属性,关系的码是多方实体的码构成的属性组。
- 实体向关系模式的转换
-
关系模式的规范化
- 根据语义确定个关系模式的数据依赖。
- 根据数据依赖确定关系模式的范式。
- 如果关系模式不符合要求,要根据关系模式的分解算法对其进行分解,达到3NF、BCNF或4NF。
- 关系模式的评价及修正。
-
确定完整性约束
根据规范化理论确定了关系模式之后,还要对关系模式加以约束,包括数据项的约束、表级约束及表间约束,可以参照 SQL 标准来确定不同的约束,如检查约束、主码约束和参照完整性约束,以保证数据的正确性。 -
用户视图的确定
确定了整个系统的关系模式之后,还要根据数据流图及用户信息建立视图模式,提高数据的安全性和独立性。
(1) 根据数据流图确定处理使用的视图。数据流图是某项业务的处理,使用了部分数据,这些数据可能要跨越不同的关系模式,建立该业务的视图,可以降低应用程序的复杂性,并提高数据的独立性。
(2)根据用户类别确定不同用户使用的视图。不同的用户可以处理的数据可能只是整个系统的部分数据,而确定关系模式时并没有考虑这一因素,如学校的学生管理,不同的院系只能访问和处理自己的学生信息,这就需要建立针对不同院系的视图达到这一要求,这样可以在一定程度上提高数据的安全性。
12.2.5 数据库的物理设计
数据库系统实现是离不开具体的计算机的,在实现数据库逻辑结构设计之后,就要确定数据库在计算机中的具体存储。数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于给定的计算机系统。为一个给定的逻辑数据模型设计一个最适合应用要求的物理结构的过程,就是数据库的物理设计。
在数据库的物理结构中,数据的基本单位是记录,记录是以文件的形式存储的,一条存储记录就对应着关系模式中的一条逻辑记录。在文件中还要存储记录的结构,如各字段长度、记录长度等,增加必要的指针及存储特征的描述。
数据库的物理设计是离不开具体的DBMS 的,不同DBMS 对物理文件存取方式的支持不同,设计人员必须充分了解所用 DBMS 的内部特征,根据系统的处理要求和数据的特点来确定物理结构。数据库的物理设计工作过程如图12-10所示。
结语
这份笔记由我在备考软件设计师中级考试的过程中编写,包含了我对知识点的理解与总结。如果您觉得这份笔记对您有帮助,并希望分享给更多的人,我十分乐意。但请在转载时务必注明出处,以尊重作者的劳动成果,感谢您的理解与支持
。
在此特别强调,本人编写笔记的所需部分资源均源于网络公开资源,旨在为大家提供一个学习和交流的内容,未经原作者授权,如若不慎侵犯您的合法权益,请您立即通过有效联系方式通知我,并附上相关证明材料
。一旦核实无误,我将在第一时间删除涉事资源,全力保障您的合法权利不受损害。
- 每篇一句:“为了未来好一点,此刻苦一点有什么。”
- 如果觉得对您有用,请点个赞或者收藏鼓励我持续更新吧!
- 恭喜您,已挑战成功第12关,请前往下午题进行挑战吧【整理中……】