系统设计名词解释

要的投资看待；
8.
不必害怕取消和返工；
9.
分而治之；
10.
设计系统时应考录到
增长和变化。
 
11.PIECES
问题解决框架和检查表（书
P52
）
 
12.FAST
（
Framework for the Application of Systems Thinking
）
方法的
8
个阶段
：
1.
范围定义；
2.
问题分析；
3.
需求分析；
4.
逻辑设计；
5.
决策分析；
6.
物理设计和集成；
7.
构造和测试；
8.
安装和发布。
 
13.
系统开发生命周期的
4
个经典阶段
：
1.
项目启动；
2.
系统分析；
3.
系统设计；
4.
系统实现。
 
14.
系统开发的
10
个基本原理是什么？
 
  
答：
1.
让系统用户参与；
2.
使用一套问题解决步骤；
3.
确立开发阶段和开发活
动；
4.
在开发过程中记录文档；
5.
建立标准；
6.
管理过程和项目；
7.
将信息系统
作为重要的投资看待；
8.
不必害怕取消和返工；
9.
分而治之；
10.
设计系统时应
考录到增长和变化。
 
15.
为什么文档在整个开发过程中很重要？（重要）
 
  
答：在大型组织中，系统所有者、用户、分析员、设计人员、和构造人员不断
变化，有些人被提升了，有些人退休了，有些人又重新加入进来。为了促进不断
变化的关联人员之间的有效交流，
文档必须随同整个系统开发工作同时展开。
文
档提高了多个关联人员之间的通信和相互接受程度，
展示了系统的优缺点，
促进
了用户参与度，并在此确保对进度的关联。
 
16.
在
FAST
方法中，以及大多数系统开发方法学中，系统所有者和系统设计人
员不参与需求分析阶段。你认为这样做的原因是什么？
 
  
答：
当系统设计人员和构造人员在没有完全理解业务需求之前就过早的进入技
术方案时，
会过早的关注技术方案，
从而忽略用户的一些需求，
导致用户对新系
统没有真正满足用户需求而抱怨。
 
17
、项目管理工具和技术——
PERT
图和甘特图
 
PERT
图是一种图形化的网络模型，描述一个项目中任务之间的关系。用来在任
务被调度之前的依赖关系。
 
甘特图是一种简单的水平条图，一亿个日历为基准描述项目任务。
 
18
、项目管理软件用来帮助项目经理计划项目，制定进度表，制定预算，监事
进展和费用，生成报告和作出必要的修改。
 
19
、项目管理生命周期中的
8
个主要活动
：
 
1.
协商范围；
2.
确定任务；
3.
估计任务；
4.
说明任务之间的依赖关系；
5.
分配资
源；
6.
指导团队工作；
7.
监督和控制进展；
8.
评估项目结果和经验。
 
20
、什么是项目？
 
   
答：项目是一个（临时的）唯一的、复杂的和关联的具有统一目标或目的并
且必须在特定的时间里、在预算内、按照规格说明要求完成的活动序列。
 
21
、范围蔓延和特征蔓延之间有什么不同？
 
       
答：范围蔓延是指随着项目的进展，对一个信息系统的用户预期和业务需求
不期望的增
  
长。遗憾的是，进度表和预算会受到这两种变化的负面影响。特
征蔓延是指一个开发过程中系统的技术特征不受控制的增长，而没有考虑到季
度和预算。
 
22
、项目管理生命周期中的
8
个主要活动是什么？
 
答：同上“四”
。
 
 

23
、
 
结构化分析主要关注什么内容？
 
答：结构化分析关注数据通过业务和软件过程的流程，又称为
以过程为中心
的
。以过程为中心是指这项技术强调的是信息系统框架中的“过程”构件。
 
24
、
信息工程主要关注什么内容？
 
答：信息工程（
IE
）关注系统中存储的数据结构，而不是过程。又称为
以数
据为中心的
，强调对“知识”
（或数据）需求的分析。
 
24
、
 
系统分析的五个阶段是什么？
 
答：
a.
范围定义，
b.
问题分析，
c.
需求分析，
d.
逻辑设计，
e.
决策分析。
 
25
、
 
用于确定和表示系统的功能需求的流行工具是什么？
 
答：不会啊！
！
！
 
26
、
 
逻辑设计阶段与需求分析阶段有什么不同？
 
   
答：逻辑设计阶段使用系统模型进一步记录业务需求，这些系统模型表示了
数据结构
,
业务过程，数据流和用户接口。从某种意义上说，逻辑设计验证了前
面阶段建立的需求。
逻辑设计阶段通常包括以下业务：
结构化功能需求，
建立功
能需求的原型（可选）
，验证功能需求，定义验收测试用例。
 
        
而需求分析阶段为一个新系统定义业务需求。
需求分析阶段回答这个问题：
“用户需要什么？想从一个系统中得到什么？”这个阶段是任何一个信息系统
成功的关键！在不同的方法学中，需求分析阶段可能被称为
定义阶段
或者
逻辑
设计阶段
。需求分析阶段通常包括以下任务：定义需求，排列需求的优先次序，
修改项目计划，交流需求陈述。
 
27
、
什么是系统需求？
系统需求定义了信息系统必须实现的功能，
或者系统必须
具备的属性或质量。说明信息系统必须实现什么的需求通常称为
功能需

求，
说明信息系统必须具备的属性或质量的需求通常称为
非功能需求
。
 
28
、
如果没有正确的确定系统需求，可能会导致下面的一种或多种情况：
 
      
系统费用可能比计划得多；
系统可能比承诺的时间交付的晚；
系统可能没
有满足用户的预期，
而且这种不满意可能使系统不被采用；
一旦投入运行，
维护和升级系统的费用可能会过高；
系统可能会不可靠，
而且容易产生错
误和死机；团队中
IT
职员的荣誉可能会因为项目失败而蒙受损失，无论
责任在谁，都将被认为是团队的错误。
 
29
、
需求获取包括以下活动
：
a.
发现和分析问题；
b.
获取需求；
c.
归档和分析需
求；
d.
需求管理。
 
30
、
为什么要进行需求管理？
 
   
答：在项目的生命期间，即使需求定义文档已经被批准了，新需求的出现以
及现有需求的改变仍是很常见的。某些研究已经表明，在系统投入运行以前，
有
50%
或者更多的需求将发生变化。
显然，
这对开发团队来说将是一个十分头
痛的问题。为了帮助缓解可能引起的众多问题，进行
需求管理
是必要的
 

31
、
7
种常见的调查研究技术
：
a.
对现有文档，表和数据库进行抽样；
b.
调查和
实地访问；
c.
观察工作环境；
d.
调查表；
e.
面谈；
f.
原型化；
g.
联合需求计划。
 
32
、
调查表有两种格式：
自由格式和固定格式。

自由格式调查表设计成让用户可
以更自由的回答每个问题。

固定格式调查表比较严格，
要求回答者从预先定义
的答案中做出选择。
 
33
、
 
小组工作会议方法的一个例子是联合需求计划（
JRP
）
，其中高度结构化
的小组会议被用
 
来分析问题并定义需求。
 
34
、
 
从现有文档中收集事实时，系统分析员应该检查那些文档？
 

35
、
 
答：

分析员应该找出的第一份文档是组织结构图
。组织结构图提供了该
项目的关键所有者和用户，以及它们之间的组织关系。

除了描述问题的文档
外，通常还包括描述正被研究或设计的业务功能的文档

。
另外，分析员还经
常检查由系统分析员和顾问以前所做的系统研究和设计文档

，
这些文档可能
包括：
 
a.
 
各种类型的流程图和图形。
 
b.
 
项目字典和资料库。
 
c.
 
设计文档，例如输入，输出和数据库。
 
d.
 
程序文档。
 
e.
 
计算机操作手册和培训手册。
 
所有收集到的文档都应该被分析，已确定信息的时效性。
 
35
、什么事联合需求计划（
JRP
）？
 
答：联合需求计划（
JRP
）
，全称
 Joint Requirements Planning
。
其基本思想是通过召开一系列高度结构化的分组会议，
快速地分析问题、
定义需求。它是
JAD
（
Join Application Development
）技术的一个子
集。
JRP
的主要意思是收集需求，而不是对需求进行分析和验证。小组
工作会议方法的一个例子是联合需求计划（
JRP
）
，其中高度结构化的小组会
议被用来分析问题并定义需求。
 
36
、
用力建模的系统概念
     
用力建模主要有两个产物，第一个是用例图，它
以图形化的方式将系统描述成用例、参与者（用户）及其之间的关系
 
37
、什么是以用户为中心的开发，为什么它对系统开发过程的成功很重要
? 
38
、答：
以用户为中心的开发是一个系统开发过程，
该过程基于对关联人员的需
求，以及对开发该系统原因的充分理解之上。
 
因为以用户为中心的开发可以成功的计划、
分析、
设计、
构造和部署一个信
息系统，系统分析员首先必须理解关联人员的需求，以及开发该系统的原因。
 
38
、
 
用例建模使用两个主要的工具——用例图和用例描述。如何使用这两个
工具？它们有什么差别？
 
    
答：用例用一个水平的椭圆表示，一个用例代表了系统的一个单一的目标，
描述为描
 
述此目标的活动和用户交互的一个序列。
 
用例图：图形化的方式将系统描述成用例、参与者（用户）及其之间的
关系。用例图在高层交流了系统必须处理的业务事件的范围。
 
用例描述：填充了每个业务事件，并说明了用户如何同系统交换交换的
细节。
 
39
、
 
用例图包括三个构件。这三个构件是什么？其用途是什么？
 
答：用例图的三个构件包括参与者、用例和关系。
 
    
用例：确定和描述系统功能。
 
    
参与者：发起或者触发系统互动。
 
    
关系
:
绘制以及连接不同种类型的符号。
 
40
、
 
为什么确定参与者是用例建模的第一步？
 
答
:
因为通过关注参与者，
我们可以把重点放在如何使用系统，
而不是如何构
造系统上。关注参与者有助于提炼和进一步定义系统的范围和边界。参与者

也决定了系统需求的完整性。首先确定参与者的一个好处是可以确定日后进
行面谈和观察以及完善用例模型的候选人。而且，当完成用例模型后，这些
参与者可以验证用例。
 
41
、
 
逻辑模型和物理模型之间有什么区别？
 
42
、
 
答：
逻辑模型是按计算机系统的观点对数据建模，
主要用于
DBMS
的实现，
而物理模型是对数据最低层的抽象。
它描述数据在系统内部的表示方式和存
取方法，在磁盘或磁带上存储方式和存取方法，是面向计算机系统的。
为什
么需要创建系统的一个实现相关的模型？
 
43.
什么是实体？是么是实体实例？
 
 
答：
实体
是我们需要收集数据和存储的人、地点、对象、事件或概念的类。
实
体实例
是实体的具体值。
 
44.
什么是基数？举例说明
。
 
 
答：
基数
定义了一个实体相对于另一个关联实体的某个具体值的最小和最大具
体值数量。例如：对应学生的每个实例都必然存在课程的一个实例。
 
对应课程
的每个实例存在许多个学生实例。
 
45
、
系统分析和系统设计基本差别是什么？
 
答：系统设计强调了业务问题，系统设计则专注与系统的技术性或实现方面。
 
46
、
 
有哪些不同的模型驱动方法？
 
答：现代结构化设计、信息工程、原型化、面向对象设计
 
47
、内部构造一个开发项目中进行系统设计包括哪
5
项高层任务？
 
答：
1
、设计应用构架
 
2
、设计系统数据库
 
 
3
、设计系统接口
4
、打包设计说明
 
5
、修改项目计划
 
48
、什么是数据库模式？
 
答：
数据库模式是数据库的结构模型，
它描述了由数据库实现的记录和关系。
 
49.
为什么在一个物理
DFD
中显示的物理过程数量一般都大于逻辑过程数量？
 
 
 
答：因为可能需要增加过程以反映数据的收集、过滤、传递、准备或质量检查
——所有这些都在实现视图中。
而且，
有些逻辑过程可能被分解成多个物理过
程，
以反映由手工实现和由计算机实现的过程部分，
用不同技术实现的过程部
分，或者分布到不同的客户端、服务器或主机的过程部分。最后，最重要的是
物理
DFD
反映了所选的实现策略需要的所有手工工程和计算机过程。
 
50.
物理数据流图表示了什么？
 
答：某个过程的实际实现或系统构造和实现的技术性蓝图。
 
51.
瘦客户端和胖客户端之间有什么区别？
 
答案见上所述。
（名词解释）
 
 
52
、
 
什么是数据库引擎？
 
 
 
 
 
答：
DBMS
的核心经常被称为数据库引擎，
引擎响应专门的命令以创建数据
库结构，然后创建、读取、修改和删除数据库中的记录。
 
53
、
 
什么是关系数据库？
 

 
 
 
 
答：
关系数据库是在一系列二维表中存储数据，
这些表通过外键互相
“关联”
。
每个表（有时称为关系）由命名列（它们是字段或属性）和任意数据的未命
名行构成。
 
54
、
 
解释访问完整性的概念，举一个例子。什么是访问完整性错误？举例说
明，并解释访问完整性错误可能的后果
.
。
 
答：访问完整性就是确保一个表中的一个外键值匹配相关表中的主键值。例
子如下：
INVOICES
表通常包括外键
CUSTOMER 
NUMBER
来“索引回”
CUSTOMER
表中相匹配的主键
CUSTOMER NUMBER
。当一个表中的一个
外键值在相关表中没有匹配的主键值时，
就存在访问完整性错误。
例子如下：
INVOICES
表通常包括外键
CUSTOMER NUMBER
来
“索引回”
CUSTOMER
表中相匹配的主键
CUSTOMER NUMBER
。
如果删除一个
CUSTOMER
记录，
有可能存在某个
INVOICES
记录，
而在
CUSTOMER
表中没有同这个记录的
CUSTOMER NUMBER
字段匹配的记录。
 
计算机生成的输出的分类
：具体见课本
388
页图
15-1 
分布：内部输出（报告）
，回转输出（先外部后内部）
，外部输出（事物）
 
实现方法：打印机，屏幕，零售终端，多媒体（音频或视频）
，电子邮件，
超链接，微缩胶片。

要的投资看待；
8.
不必害怕取消和返工；
9.
分而治之；
10.
设计系统时应考录到
增长和变化。
 
11.PIECES
问题解决框架和检查表（书
P52
）
 
12.FAST
（
Framework for the Application of Systems Thinking
）
方法的
8
个阶段
：
1.
范围定义；
2.
问题分析；
3.
需求分析；
4.
逻辑设计；
5.
决策分析；
6.
物理设计和集成；
7.
构造和测试；
8.
安装和发布。
 
13.
系统开发生命周期的
4
个经典阶段
：
1.
项目启动；
2.
系统分析；
3.
系统设计；
4.
系统实现。
 
14.
系统开发的
10
个基本原理是什么？
 
  
答：
1.
让系统用户参与；
2.
使用一套问题解决步骤；
3.
确立开发阶段和开发活
动；
4.
在开发过程中记录文档；
5.
建立标准；
6.
管理过程和项目；
7.
将信息系统
作为重要的投资看待；
8.
不必害怕取消和返工；
9.
分而治之；
10.
设计系统时应
考录到增长和变化。
 
15.
为什么文档在整个开发过程中很重要？（重要）
 
  
答：在大型组织中，系统所有者、用户、分析员、设计人员、和构造人员不断
变化，有些人被提升了，有些人退休了，有些人又重新加入进来。为了促进不断
变化的关联人员之间的有效交流，
文档必须随同整个系统开发工作同时展开。
文
档提高了多个关联人员之间的通信和相互接受程度，
展示了系统的优缺点，
促进
了用户参与度，并在此确保对进度的关联。
 
16.
在
FAST
方法中，以及大多数系统开发方法学中，系统所有者和系统设计人
员不参与需求分析阶段。你认为这样做的原因是什么？
 
  
答：
当系统设计人员和构造人员在没有完全理解业务需求之前就过早的进入技
术方案时，
会过早的关注技术方案，
从而忽略用户的一些需求，
导致用户对新系
统没有真正满足用户需求而抱怨。
 
17
、项目管理工具和技术——
PERT
图和甘特图
 
PERT
图是一种图形化的网络模型，描述一个项目中任务之间的关系。用来在任
务被调度之前的依赖关系。
 
甘特图是一种简单的水平条图，一亿个日历为基准描述项目任务。
 
18
、项目管理软件用来帮助项目经理计划项目，制定进度表，制定预算，监事
进展和费用，生成报告和作出必要的修改。
 
19
、项目管理生命周期中的
8
个主要活动
：
 
1.
协商范围；
2.
确定任务；
3.
估计任务；
4.
说明任务之间的依赖关系；
5.
分配资
源；
6.
指导团队工作；
7.
监督和控制进展；
8.
评估项目结果和经验。
 
20
、什么是项目？
 
   
答：项目是一个（临时的）唯一的、复杂的和关联的具有统一目标或目的并
且必须在特定的时间里、在预算内、按照规格说明要求完成的活动序列。
 
21
、范围蔓延和特征蔓延之间有什么不同？
 
       
答：范围蔓延是指随着项目的进展，对一个信息系统的用户预期和业务需求
不期望的增
  
长。遗憾的是，进度表和预算会受到这两种变化的负面影响。特
征蔓延是指一个开发过程中系统的技术特征不受控制的增长，而没有考虑到季
度和预算。
 
22
、项目管理生命周期中的
8
个主要活动是什么？
 
答：同上“四”
。
 
 

23
、
 
结构化分析主要关注什么内容？
 
答：结构化分析关注数据通过业务和软件过程的流程，又称为
以过程为中心
的
。以过程为中心是指这项技术强调的是信息系统框架中的“过程”构件。
 
24
、
信息工程主要关注什么内容？
 
答：信息工程（
IE
）关注系统中存储的数据结构，而不是过程。又称为
以数
据为中心的
，强调对“知识”
（或数据）需求的分析。
 
24
、
 
系统分析的五个阶段是什么？
 
答：
a.
范围定义，
b.
问题分析，
c.
需求分析，
d.
逻辑设计，
e.
决策分析。
 
25
、
 
用于确定和表示系统的功能需求的流行工具是什么？
 
答：不会啊！
！
！
 
26
、
 
逻辑设计阶段与需求分析阶段有什么不同？
 
   
答：逻辑设计阶段使用系统模型进一步记录业务需求，这些系统模型表示了
数据结构
,
业务过程，数据流和用户接口。从某种意义上说，逻辑设计验证了前
面阶段建立的需求。
逻辑设计阶段通常包括以下业务：
结构化功能需求，
建立功
能需求的原型（可选）
，验证功能需求，定义验收测试用例。
 
        
而需求分析阶段为一个新系统定义业务需求。
需求分析阶段回答这个问题：
“用户需要什么？想从一个系统中得到什么？”这个阶段是任何一个信息系统
成功的关键！在不同的方法学中，需求分析阶段可能被称为
定义阶段
或者
逻辑
设计阶段
。需求分析阶段通常包括以下任务：定义需求，排列需求的优先次序，
修改项目计划，交流需求陈述。
 
27
、
什么是系统需求？
系统需求定义了信息系统必须实现的功能，
或者系统必须
具备的属性或质量。说明信息系统必须实现什么的需求通常称为
功能需

求，
说明信息系统必须具备的属性或质量的需求通常称为
非功能需求
。
 
28
、
如果没有正确的确定系统需求，可能会导致下面的一种或多种情况：
 
      
系统费用可能比计划得多；
系统可能比承诺的时间交付的晚；
系统可能没
有满足用户的预期，
而且这种不满意可能使系统不被采用；
一旦投入运行，
维护和升级系统的费用可能会过高；
系统可能会不可靠，
而且容易产生错
误和死机；团队中
IT
职员的荣誉可能会因为项目失败而蒙受损失，无论
责任在谁，都将被认为是团队的错误。
 
29
、
需求获取包括以下活动
：
a.
发现和分析问题；
b.
获取需求；
c.
归档和分析需
求；
d.
需求管理。
 
30
、
为什么要进行需求管理？
 
   
答：在项目的生命期间，即使需求定义文档已经被批准了，新需求的出现以
及现有需求的改变仍是很常见的。某些研究已经表明，在系统投入运行以前，
有
50%
或者更多的需求将发生变化。
显然，
这对开发团队来说将是一个十分头
痛的问题。为了帮助缓解可能引起的众多问题，进行
需求管理
是必要的
 

31
、
7
种常见的调查研究技术
：
a.
对现有文档，表和数据库进行抽样；
b.
调查和
实地访问；
c.
观察工作环境；
d.
调查表；
e.
面谈；
f.
原型化；
g.
联合需求计划。
 
32
、
调查表有两种格式：
自由格式和固定格式。

自由格式调查表设计成让用户可
以更自由的回答每个问题。

固定格式调查表比较严格，
要求回答者从预先定义
的答案中做出选择。
 
33
、
 
小组工作会议方法的一个例子是联合需求计划（
JRP
）
，其中高度结构化
的小组会议被用
 
来分析问题并定义需求。
 
34
、
 
从现有文档中收集事实时，系统分析员应该检查那些文档？
 

35
、
 
答：

分析员应该找出的第一份文档是组织结构图
。组织结构图提供了该
项目的关键所有者和用户，以及它们之间的组织关系。

除了描述问题的文档
外，通常还包括描述正被研究或设计的业务功能的文档

。
另外，分析员还经
常检查由系统分析员和顾问以前所做的系统研究和设计文档

，
这些文档可能
包括：
 
a.
 
各种类型的流程图和图形。
 
b.
 
项目字典和资料库。
 
c.
 
设计文档，例如输入，输出和数据库。
 
d.
 
程序文档。
 
e.
 
计算机操作手册和培训手册。
 
所有收集到的文档都应该被分析，已确定信息的时效性。
 
35
、什么事联合需求计划（
JRP
）？
 
答：联合需求计划（
JRP
）
，全称
 Joint Requirements Planning
。
其基本思想是通过召开一系列高度结构化的分组会议，
快速地分析问题、
定义需求。它是
JAD
（
Join Application Development
）技术的一个子
集。
JRP
的主要意思是收集需求，而不是对需求进行分析和验证。小组
工作会议方法的一个例子是联合需求计划（
JRP
）
，其中高度结构化的小组会
议被用来分析问题并定义需求。
 
36
、
用力建模的系统概念
     
用力建模主要有两个产物，第一个是用例图，它
以图形化的方式将系统描述成用例、参与者（用户）及其之间的关系
 
37
、什么是以用户为中心的开发，为什么它对系统开发过程的成功很重要
? 
38
、答：
以用户为中心的开发是一个系统开发过程，
该过程基于对关联人员的需
求，以及对开发该系统原因的充分理解之上。
 
因为以用户为中心的开发可以成功的计划、
分析、
设计、
构造和部署一个信
息系统，系统分析员首先必须理解关联人员的需求，以及开发该系统的原因。
 
38
、
 
用例建模使用两个主要的工具——用例图和用例描述。如何使用这两个
工具？它们有什么差别？
 
    
答：用例用一个水平的椭圆表示，一个用例代表了系统的一个单一的目标，
描述为描
 
述此目标的活动和用户交互的一个序列。
 
用例图：图形化的方式将系统描述成用例、参与者（用户）及其之间的
关系。用例图在高层交流了系统必须处理的业务事件的范围。
 
用例描述：填充了每个业务事件，并说明了用户如何同系统交换交换的
细节。
 
39
、
 
用例图包括三个构件。这三个构件是什么？其用途是什么？
 
答：用例图的三个构件包括参与者、用例和关系。
 
    
用例：确定和描述系统功能。
 
    
参与者：发起或者触发系统互动。
 
    
关系
:
绘制以及连接不同种类型的符号。
 
40
、
 
为什么确定参与者是用例建模的第一步？
 
答
:
因为通过关注参与者，
我们可以把重点放在如何使用系统，
而不是如何构
造系统上。关注参与者有助于提炼和进一步定义系统的范围和边界。参与者

也决定了系统需求的完整性。首先确定参与者的一个好处是可以确定日后进
行面谈和观察以及完善用例模型的候选人。而且，当完成用例模型后，这些
参与者可以验证用例。
 
41
、
 
逻辑模型和物理模型之间有什么区别？
 
42
、
 
答：
逻辑模型是按计算机系统的观点对数据建模，
主要用于
DBMS
的实现，
而物理模型是对数据最低层的抽象。
它描述数据在系统内部的表示方式和存
取方法，在磁盘或磁带上存储方式和存取方法，是面向计算机系统的。
为什
么需要创建系统的一个实现相关的模型？
 
43.
什么是实体？是么是实体实例？
 
 
答：
实体
是我们需要收集数据和存储的人、地点、对象、事件或概念的类。
实
体实例
是实体的具体值。
 
44.
什么是基数？举例说明
。
 
 
答：
基数
定义了一个实体相对于另一个关联实体的某个具体值的最小和最大具
体值数量。例如：对应学生的每个实例都必然存在课程的一个实例。
 
对应课程
的每个实例存在许多个学生实例。
 
45
、
系统分析和系统设计基本差别是什么？
 
答：系统设计强调了业务问题，系统设计则专注与系统的技术性或实现方面。
 
46
、
 
有哪些不同的模型驱动方法？
 
答：现代结构化设计、信息工程、原型化、面向对象设计
 
47
、内部构造一个开发项目中进行系统设计包括哪
5
项高层任务？
 
答：
1
、设计应用构架
 
2
、设计系统数据库
 
 
3
、设计系统接口
4
、打包设计说明
 
5
、修改项目计划
 
48
、什么是数据库模式？
 
答：
数据库模式是数据库的结构模型，
它描述了由数据库实现的记录和关系。
 
49.
为什么在一个物理
DFD
中显示的物理过程数量一般都大于逻辑过程数量？
 
 
 
答：因为可能需要增加过程以反映数据的收集、过滤、传递、准备或质量检查
——所有这些都在实现视图中。
而且，
有些逻辑过程可能被分解成多个物理过
程，
以反映由手工实现和由计算机实现的过程部分，
用不同技术实现的过程部
分，或者分布到不同的客户端、服务器或主机的过程部分。最后，最重要的是
物理
DFD
反映了所选的实现策略需要的所有手工工程和计算机过程。
 
50.
物理数据流图表示了什么？
 
答：某个过程的实际实现或系统构造和实现的技术性蓝图。
 
51.
瘦客户端和胖客户端之间有什么区别？
 
答案见上所述。
（名词解释）
 
 
52
、
 
什么是数据库引擎？
 
 
 
 
 
答：
DBMS
的核心经常被称为数据库引擎，
引擎响应专门的命令以创建数据
库结构，然后创建、读取、修改和删除数据库中的记录。
 
53
、
 
什么是关系数据库？
 

 
 
 
 
答：
关系数据库是在一系列二维表中存储数据，
这些表通过外键互相
“关联”
。
每个表（有时称为关系）由命名列（它们是字段或属性）和任意数据的未命
名行构成。
 
54
、
 
解释访问完整性的概念，举一个例子。什么是访问完整性错误？举例说
明，并解释访问完整性错误可能的后果
.
。
 
答：访问完整性就是确保一个表中的一个外键值匹配相关表中的主键值。例
子如下：
INVOICES
表通常包括外键
CUSTOMER 
NUMBER
来“索引回”
CUSTOMER
表中相匹配的主键
CUSTOMER NUMBER
。当一个表中的一个
外键值在相关表中没有匹配的主键值时，
就存在访问完整性错误。
例子如下：
INVOICES
表通常包括外键
CUSTOMER NUMBER
来
“索引回”
CUSTOMER
表中相匹配的主键
CUSTOMER NUMBER
。
如果删除一个
CUSTOMER
记录，
有可能存在某个
INVOICES
记录，
而在
CUSTOMER
表中没有同这个记录的
CUSTOMER NUMBER
字段匹配的记录。
 
计算机生成的输出的分类
：具体见课本
388
页图
15-1 
分布：内部输出（报告）
，回转输出（先外部后内部）
，外部输出（事物）
 
实现方法：打印机，屏幕，零售终端，多媒体（音频或视频）
，电子邮件，
超链接，微缩胶片。