结构化设计
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
8.1 MIS的一般关系模型的设计
关系模型是由关系数据结构、关系操作集合 和关系完整性约束三部分组成。MIS的一般关系 模型的设计是指:在不涉及到任何具体的数据库 管理系统(DBMS)与不考虑任何具体的系统操作 平台与运行环境的情况下,依据结构化系统分析 中得到的实体联系图ERD,设计具有一般通用性 的关系模型。
8.1.2 从ER图导出一般关系模型的基本原则
现以帐务处理(图7.21)和工资核算(图8.16) 的ERD为实例,介绍从ER图导出一般关系模型的四个基 本原则。
部门号
部门名 部 门
部门类型
调来日期
基本工资 职务工资 工龄工资 固定补贴 变 动 工 资 固 定 工 资
所属
主管
任职日期
称谓
“的”
员 工
MIS的总体设计
总体设计,又称概要设计,是以系统分析中得到的新系 统的逻辑模型为依据,着眼于“如何做”,但又不考虑 具体的特定系统平台,从全局一般的视野,来设计MIS 的总体方案。包括从全局实体联系图(ERD)导出数 据的一般关系模型并改进优化之;从数据流图(DFD)及 其数据字典(DD)中的加工说明,导出模块结构图(MSD); 基于可行性研究的初步方案中系统平台构思,依据组织 机构、数据的一般关系模型和MSD设计系统平台总体布 局,得到系统平台总体布局图。 下面8.1-8.4节讨论系统的总体设计。 这里把教材上的1、2两节对调,因为处理功能设计中 要对数据库模型中的一般关系模型中的关系读写数据。
(主管联系)
部门号
主码
部门名
部门类型
主管工号
外码
任职日期
原则4:M:M联系转换成一个独立的关系,被联系实体关 系的主码(作为外来码)和联系本身的属性作为该关系 的属性,被联系实体关系的主码组成其复合主码。 例如,图7.22帐务处理ER图中的分录联系转换为分录关 系关系 注意:如果要保存时间序列数据,则日期、时间属性往 往应加入到主码中。 分录关系
Βιβλιοθήκη Baidu
“的”
家庭 成员
姓名 性别
“的”
生日 电话 职业
工作单位
变动津贴
奖金 应扣款
工 姓名 性别 生日 职务 家庭 邮编 号 地址
图8.16
工资核算的ER图
原则1:ER图中的每一个独立实体变换为一个关系,其 属性变为关系的属性,其主标识变为关系的主码。 例如,图8.16中独立实体“部门”、“职员”分别变为 部门关系、员工关系。
固定工资关系 工号 基本工资 职务工资 工龄工资 固定补贴
外码 主码 变动工资关系
工号 外码 主码 变动津贴 奖金 应扣款
家庭成员关系关系
员工工号 称谓 姓名 性别 生日 职业 外码 主码(复合) 工作单位
原则3:1:M联系通过在“多”实体关系中增加相联系的 “1”实体关系的主码及联系本身的属性来表达。其中 “1”实体主码为外来码。 例如,在员工关系中增加“所属部门号”这个外来 码反映1:M联系所属职员关系。 员工关系
用户评价MIS系统的主要性能指标有 适应性:容易理解,容易改正错误,容易改进,容 易扩充 可靠性:检错、纠错、容错和从故障中恢复的能力 安全性:保密、抗入侵、防病毒、反窃取等能力 工作质量 效益:直接经济效益、间接经济效益和社会效益 工作效率 系统适应性好,容易理解,就便于与用户交流,有 利于用户参与开发与维护,就能提高用户满意度;容易 改正错误,就为系统调试与维护提供了便利,从而节省 系统开发与维护的人力、物力与时间;容易修改就是为 调整其它性能指标创造了有利条件,使其综合性能达到 满意点;容易改进和扩充,就能方便地适应环境或目标 的变化,不断调整各项性能指标,更好地满足用户需求, 有效地延长MIS的生命周期。因此,在系统设计中把系 统适应性摆在突出的位臵。
优化--提高查询效率:可以考虑把两者合并为
“分录日记帐”或称“记帐凭证关系”(下页表), 从而提高查询效率 问题:追加中将必需对“经济业务”信息多次重复 输入,既增加了输入量,又可能产生不一致而破坏了 数据完整性。 问题的解决办法:设计专门的追加(输入)和修改 的应用程序,用“一次输入,多次复制”或“一处修 改就同时修改”的策略,来减少重复输入与修改,保 证不破坏数据完整性。 首先得到规范化程度在3NF及其以上的关系组成的 一般关系模型是主要的,这会使开发维护人员和用户都 容易理解和把握相同全局的数据结构,做到心中有数, 在实现、维护和运行系统时,就不致迷失方向而犯破坏 数据完整性等方面的错误。
部门关系 部门号 主码 员工关系 工号 姓名 性别 生日 职务 家庭地址 邮编 电话 主码 部门名 部门类型
原则2:ER图中的从实体及相应的主从联系变换为一个 关系,从实体的属性加上主实体关系的主码构成这个关 系的属性。如果主从联系是1:1的,则以主实体关系的 主码(作为外来码)为这个关系的主码;如果主从联系 是1:M的,则以主实体关系的主码加上同一主实体个体 联系的不同从实体个体赖以相互区分的属性组,组成该 关系的主码。 例如,图8.16中主实体“员工”与从实体“固定工资”、 “变动工资” 的主从联系是1:1的,转换为以“员工工 号”为主码的“固定工资”关系、“变动工资”关系; 主实体“员工”与从实体”家庭成员“的主从联系是 1:M的,而“称谓”可以把同一个员工的不同家庭成员 区分开来,可以转换为以“员工工号”与“称谓”为复 合主码的“家庭成员”关系。
凭证号 外码 科目名 外码 记帐方向 记帐金额
主码(复合主码)
8.1.3 初始一般关系模型的改进与优化
1.初始一般关系模型的改进--关系规范化 逐一分析模型的这些关系模式中,是否存在部分函 数依赖、传递函数依赖等。确定每个关系模式是否属于 BCNF或3NF,不是则要通过关系模式的分解使之规范化。 2. 一般关系模型的优化--查询/更新分析 规范化程度都属于3NF及其以上的关系组成的关系 模型的基本结构,能消除数据冗余和操纵异常,主要是 有利于数据更新(插入、删除与修改)。 但当一个查询涉及到多个关系中的属性时,必须用 到时空开销大且易出错的连接运算,如果只强调提高规 范化程度而把关系分解得太小,就会得不偿失。
8.2.1
模块结构图设计
一、 处理功能模块化的基本概念
1.模块(Modular) 可以组合、分解和更换的单元,是组成系统、易 于理解的基本单位。在管理信息系统中,任何一个处 理功能都可以看作是一个模块。 一个模块具有输入和输出、功能、内部数据、处 理过程等四个特性。总体设计的任务就是决定系统中 模块间的相互关系和各个模块的输入、输出和功能等 外部特性;详细设计才决定每个模块的内部数据和处 理过程等内部特性。处理过程可以是程序代码(计算 机处理)或操作规程(人工处理)。
8.2 MIS处理功能的总体设计
MIS处理功能的总体设计是要确定,从总体上看, 要完成其信息输入、处理、存取、输出的那些任务, MIS应该“如何做”。其基本思路是:以系统的加工任 务和数据流程为基础,依据系统的DFD及其DD,借助于 一套标准的设计准则与图表工具,通过“自顶向下” 的逐层分解和“自底向上”的反复推敲,把系统功能 划分为多个层次分明,大小适当,任务单一,相对独 立,容易理解和实现的处理单元——模块,并组成模 块结构图,展现出上层模块对下层模块的调用、模块 间的数据交换、数据对系统的输入/输出、模块对数据 存储的读/写。
(属于联系) 工号 姓名 性别 生日职务家庭地址 邮编 电话 所属部号 聘用日期 外码 主码
注: 在1:1联系中,与对方部分个体没有对应个体的实 体称为“零”实体。1:1联系应附加到“零”实体关系 上,即1:1联系应附加到没造成或少造成外码及联系本 身属性空白的实体关系上。例如,把主管工号加到部门 关系而不是把所管部门号加到员工关系上来表达“主管” 联系。 部门关系
二、模块结构图(Modular Structure Diagram) 模块结构图(Modular Structure Diagram, MSD) ,也称控制结构图或系统结构图,简称结构图, 是HIPO图的进一步发展。它不仅表示了系统功能的层次 分解关系,还表示了模块的调用关系及模块之间数据流 与控制流信息的传递关系,以及模块对数据存储的读写 及外部对象间的输入输出关系,是结构化系统设计的一 种重要图表工具。 1.模块的图形表示 一般模块:用矩形表示,模块名写在方框内,如图 8.1(a)所示。 叶模块:不再分解、不再调用别的模块的基本模块, 必要时表示成下横为双线的矩形,如图8.1b)所示。 预定义模块:作为特殊叶模块的公用模块,例如程序 库中的子程序。必要时表示为上下横为双线的矩形, 如图8.1 c)所示。
2.模块的分层与调用 系统由模块以层次结构组成。 逻辑上,上层模块的任务通过调用其下层模块来共 同分担、完成,最下层的是具体工作模块,执行具 体任务。 物理上,子模块是其上层父模块的组成部分。 每个模块有自己独立的任务,只有上级模块的调用 才能执行。 模块之间的通信只限于直接上下级之间。 3.划分模块的基本要求 模块功能简单明确 模块划分按层次进行 模块尽可能独立 模块之间的关系要明确说明
记帐凭证关系
凭证号日期 摘要 业务金额 附件张数 科目码 记帐方向 记帐金额 外码
复合主码
8.1.4 用户一般关系模型的设计
一个数据库应用系统可能涉及到一个组织的许多部 门,有许多用户,包含的数据种类和数据量都很大,联 系也很复杂。一开始很难用一个总体E—R图准确地反映 出它们之间错综复杂的联系。一般从设计各部门的分ER 图入手,每一个分E—R图就是一个用户视图。 用户一般关系模型的设计同样遵循上述导出原则, 从子ER图导出。但必须指明其字段来自全局一般数据模 型的哪个关系,说明记录的选用条件、复合字段与导出 字段的来源与使用的方法。
第八章 结构化 系统设计 (SSD)
MIS的结构化系统设计
结构化系统设计(Structured System Design)遵 循结构化的思想 自顶向下,逐步求精的策略 目标明确,成果规范的阶段 层次清楚,体系严谨的结构 形象直观,清晰易懂的表达 划分为总体设计和详细设计两个阶段。每个阶段都 包括 动态的处理流程设计:处理功能模块化 静态的数据结构设计:数据结构模型化 系统平台的设计:系统平台开放化
总体设计方案是结构化系统分析得到的逻辑模型到 结构化系统设计的详细设计中所得到的具体的物理模型 中间的一个桥梁。 在详细设计中,才完成系统平台的具体软硬件设备 的详细结构和具体选型,并在此基础上,具体地完成模 块的流程设计,数据结构具体实现的构架设计及其所使 用的代码系统设计,得到可以直接安装、建库、编程、 调试直至运行的物理模型。 这样纵横划分当然是为了问题简化,思路清晰。但 在信息系统工程中,结构化系统设计也努力追求动态处 理流程的设计与静态数据结构的设计之间的集成融合, 追求阶段之间的无缝过渡。基本目的是要得到一个令用 户满意的良好的实现方案。
得到规范化程度较高的基本结构后,要进行查询/更新分析。 如果是以更新为主,可以直接用基本结构来建库;如果是以查询 为主,则应适当合并关系,适当降低规范化程度,而减少查询时 的连接运算。
案例分析:帐务处理案例的基本结构有“经济业务” 与“分录”两个关系 查询/更新分析 结帐、制表、查帐等都要多次进行涉及到这两个 关系的查询。 按规定,记帐凭证输入并在审核认定正确后,就 不能再修改,即使后来发现错误,也只能用反向登 记冲平后再将更正的记录重新登入,所以,只有追 加,而没有删除与修改。
8.1.1 一般关系模型设计的基本任务
1.从全局ER图导出一般关系数据模型(全局一般关系 模型):从系统全局ER图构造出各个关系(二维表), 以关系框架(表头:描述记录结构,由属性名、外码、 主码等三行构成)表示,它们构成了全局数据模型。 2.初始一般关系模型的改进与优化: 改进:检查关系模式的规范化,不是BCNF或3NF的, 要通过分解规范化到BCNF或3NF 优化:通过查询/更新分析,对要频繁多关系查询而 又很少更新的关系要适当合并,降低规范化程度而提 高查询效率。 3.导出用户一般关系数据模型(用户视图):从全局 数据模型中,依据各子ER图,抽出一些属性(表栏、数 据项)和满足某些条件的元组(行、记录),加上某些 导出项构成满足具体子系统或模块需要的数据模型。