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