上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析Word文档格式.docx

上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析Word文档格式.docx

《上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析Word文档格式.docx》由会员分享，可在线阅读，更多相关《上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析Word文档格式.docx（16页珍藏版）》请在冰豆网上搜索。

根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。

（7）查询病历：

根据医生的病历查询请求，查询病历文件，给医生返回病历报告。

（8）生成治疗意见：

根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。

（9）查询治疗意见：

医生和护理人员查询治疗意见，据此对病人进行治疗。

现采用结构化方法对病人监控系统进行分析与设计，获得如图1-1所示的顶层数据流图和图1-2所示的0层数据流图。

【问题1】

使用说明中的词语，给出图1-1中的实体E1〜E3的名称。

【参考答案】

E1、病人

E2、护理人员

E3、医生

【试题分析】

顶层DFD—般用来确定系统边界，将待开发系统看作一个加工，因此图中只有唯一的一个处理和一些外部实体，以及这两者之间的输入输出数据流。

题目要求根据描述来确定图中的外部实体。

分析题目中的描述，并结合已经在顶层数据流图中给出的数据流进行分析。

从中可以看出，与系统的交互者包括病人、医生和医护人员。

其中，本地监控定期获取病人的生命特征，病人是生命特征数据来源，医生和护理人员会得到相关报告的结果，如请求病人生命特征报告，并获得相关报告。

医生还需要在必要时添加或更新生命特征范围。

对应图1-1中数据流和实体的对应关系，可知E1为病人，E2为护理人员，E3为医生。

【问题2】

使用说明中的词语，给出图1-2中的数据存储D1〜D4的名称。

D1、生命特征范围文件

D2、日志文件

D3、病历文件

D4、治疗意见文件

【答案解析】

本问题考查0层DFD中数据存储的确定。

根据说明中的描述：

对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征（4）维护生命特征范围：

医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围；

根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件；

因此，D1为生命特征范围文件，D2为日志文件，D3为病例文件，D4为治疗意见文件。

【问题3】

图1-2中缺失了4条数据流，使用说明、图1-1和图1-2中的术语，给出数据流的名称及其起点和终点。

数据流名称

起点

终点

重要生命特征

本地监控

格式化生命特征

格式化后的生命特征

检查生命特征

病例

生成病历

D3或病历（）

生命特征

D2或日志（文件）

本问题考查0层DFD中缺失的处理和数据流。

从说明中的描述及图1-2可知，本地监控之后要对重要生命特征存储日志文件进行格式化，所以在本地监控和格式化生命特征之间缺少了数据流重要生命特征；

检查生命特征是对格式化后的生命特征进行检查，所以在格式化生命特征和检查生命特征之间缺少了数据流格式化后的生命特征；

根据曰志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。

【问题4】

说明实体E1和E2之前可否有数据流，并解释其原因。

E1和E3之间不可以有数据流，因为数据流的起点和终点中必须有一个是加工（处理）。

解析：

本问题考查绘制DFD时的注意事项。

在DFD中，每条数据流的起点和终点之一必须是加工（处理）。

本题中，医生和护理人员根据查询到的治疗意见对病人进行治疗属于系统之外的行为，所以两个实体之间不可以有数据流。

试题二

某法院要开发一个诉讼案件信息处理系统，该信息系统的部分关系模式如下：

职工（职工编号，姓名，岗位）

律师（律师编号，姓名）

被告（被告编号，姓名，地址）

案件（案件编号，案件类型，案件描述，被告，律师，主审法官，立案日期，状态，结案日期，结案摘要）

审理（审理编号，案件编号，审理日期，摘要）

有关关系模式的属性及相关说明如下：

（1）职工关系模式的岗位有“法官”、“书记员”和“其他”。

（2）诉讼立案后，即在案件关系中插入一条相应记录。

案件关系模式的状态有“待处理”、“审理中”、“结案”和“撤销”，一个案件开始立案时其案件状态为“待处理”。

（3）案件关系模式的案件类型有“偷窃”、“纵火”等。

（4）一个案件自立案到结案的整个过程由一位法官和一位律师负责，一个案件通常经过一次到多次审理。

假设案件编号唯一标识一个案件，且立案日期小于等于结案日期。

请将如下创建案件关系的SQL语句的空缺部分补充完整。

（a）、PRIMARYKEY或NOTNULLUNIQUE

（b）、REFERENCES职工（职工编号）

（c）、CHECKVALUESIN（'

待处理'

'

审理中'

结案'

撤销'

）

（d）、CHECK（立案日期<

=结案日期）

本问题考查SQL中的数据定义语言DDL和完整性约束。

完整性约束包括三类：

实体完整性、参照完整性和用户定义的完整性。

实体完整性约束规定关系的主属性不能取空值，关系模型中以主码作为唯一性标识；

参照完整性约束规定若属性（或属性组）A是关系R上的主码，B是关系S上的外码，A与B相对应（来自相同的域），则B取值为空或者来自于R上的某个A的值；

用户定义的完整性约束是针对具体的数据库应用而定义的，它反映该应用所涉及的数据必须满足用户定义的语义要求。

（a）考查实体完整性约束，案件编号是案件关系模式的主码，用关键字PRIMARYKEY或者NOTNULLUNIQUE表示。

（b）考查参照完整性约束，主审法官属性参照职工关系模式中的职工编号属性，由于这两个属性名称不同，因此用REFERENCES职工（职工编号）表示，此处不能省略职工编号。

（c）、（d）考查用户定义的完整性约束。

（c）是在状态属性上定义列级约束，用CHECKVALUESIN（'

，'

）表示。

（d）在立案日期和结案日期上定义约束，用CHECK（立案日期<

=结案日期）表示。

请完成下列查询的SQL语句。

（1）查询当前待处理的诉讼案件，显示案件的案件编号、立案日期、被告姓名、被告地址、案件描述、律师姓名和主审法官姓名。

（2）査询2009年立案的各类案件数，并按案件数降序排序。

（日期格式举例：

2009年1月1日表示为01-JAN-2009,2009年12月31日表示为31-DEC-2009）

（3）查询立案次数超过5次的被告姓名和地址。

（1）：

（e）、职工.姓名AS主审法官姓名

（f）、案件，被告，律师，职工（关系模式的顺序无关）

（g）、案件.主审法官=职工.职工编号

（2）：

（h）、立案日期BETWEEN'

01-JAN-2009'

AND'

31-DEC-2009'

或者立案日期>

='

AND立案日期<

31-DEC-2009，

（i）、ORDERBY案件数DESC

（3）、（j）案件.被告=被告.被告编号

（k）、姓名，地址

（l）、HAVINGcount（*）>

5

（1）考查别名和连接查询条件。

（e）处考核别名定义，用AS关键字，且别名根据题干给出，应填“职工.姓名AS主审法官姓名”；

（f）处考查该查询涉及到的关系模式，此处应涉及到案件、被告、律师和职工4个关系模式，在FROM子句中关系模式是顺序无关的；

（g）处考核案件关系模式和职工关系模式的连接条件，即“案件.主审法官=职工.职工编号”。

（2）考查日期属性并对査询结果进行分组和排序。

（h）处主要考核日期作为条件属性的语法，题干中已经给出日期格式的提示。

在两个日期之间的时间的语法可以用BETWEEN…AND…，也可以用>

=…<

=，因此，此处可以填“立案日期BETWEEN'

”或者“立案日期>

AND立案日期<

='

”；

（i）处考核查询结果的排序，用“ORDERBY案件数DESC”表示，其中的DESC关键字不能省略。

在ORDERBY子句中，若不用表示升序的关键字ASC或表示降序的关键字DESC表示，则默认为升序排序。

（3）考查对查询结果进行分组，并指定满足条件的分组才能输出。

（j）处考核两个关系模式的连接关系，应填“案件.被告=被告.被告编号”；

（k）处考核分组，此处填“姓名，地址”，不能仅填姓名或者地址；

（1）处考核分组条件，用HAVING关键字，应填“HAVINGcount（*）>

5”。

当插入一个审理记录时，检查案件的状态，若状态为“未处理”，则将其修改为“审理中”。

下面是用触发器实现该需求的SQL语句，请将空缺部分补充完整.

（m）、INSERT

（n）、SET状态='

（o）、案件编号=nrow.案件编号

触发器是一个能由系统自动执行对数据库修改的语句。

一个触发器由事件、条件和动态三部分组成：

事件即对数据库的插入、删除和修改等操作。

触发器在这些事件发生时，将开始工作；

条件是指触发器将测试条件是否成立，若成立就执行相应的动作，否则就什么也不做；

动态是指若触发器测试满足预定的条件，那么就由数据库管理系统执行这些动作。

本题首先定义触发器的事件，即对审理关系模式插入后激活触发器。

接下来定义触发器的动作，即修改案件关系模式的状态为“审理中”，测试条件为若该案件原来状态为“待处理”，需要关联的两个关系模式是案件和审理。

试题三

【说明】

某服装销售公司拟开发一套服装采购管理系统，以方便对服装采购和库存进行管理。

【需求分析】

（1）采购系统需要维护服装信息及服装在仓库中的存放情况。

系统按服装的销售种类记录服装信息。

服装信息主要包括：

服装编码、服装描述、服装类型、销售价格、尺码和面料，其中，服装类型为销售分类，服装按销售分类编码。

仓库信息主要包括：

仓库编码、仓库位置、仓库容量和库管员。

系统记录库管员的库管员编码、姓名和级别。

一个库管员可以管理多个仓库，每个仓库有一名库管员。

一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。

（2）当库管员发现有一类或者多类服装缺货时，需要生成采购订单。

一个采购订单可以包含多类服装。

每类服装可由多个不同的供应商供应，但具有相同的服装编码。

采购订单主要记录订单编码、订货日期和应到货日期，并需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。

（3）系统需记录每类服装的各个供应商信息和供应情况。

供应商信息包括：

供应商编码、供应商名称、地址、企业法人和联系电话。

供应情况记录供应商所供应服装的服装类型和服装质量等级。

一个供应商可以供应多类服装，一类服装可由