上半年数据库系统工程师考试下午真题及解析1.docx
《上半年数据库系统工程师考试下午真题及解析1.docx》由会员分享，可在线阅读，更多相关《上半年数据库系统工程师考试下午真题及解析1.docx（8页珍藏版）》请在冰豆网上搜索。
上半年数据库系统工程师考试下午真题及解析1
2011上半年数据库系统工程师考试下午真题及解析
（1）
《五年高考三年模拟》相当于高考“武功秘籍”中的《九阴真经》。
海量的题库，对真题详尽的解析，备受老师和学生的追捧。
可见，真题是应对考试的上好资料，下面希赛软考学院为你整理了2011上半年数据库系统工程师考试下午真题及解析，助你修炼出一身“绝技”，应对来年的数据库系统工程师考试。
试题一
阅读下列说明和图，回答问题1至问题4，将解答填入对应栏内。
[说明]
某医院欲开发病人监控系统。
该系统通过各种设备监控病人的生命特征，并在生命特征异常时向医生和护理人员报警。
该系统的主要功能如下：
1、本地监控：
定期获取病人的生命特征，如体温、血压、心率等数据。
2、格式化生命特征：
对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征。
3、检查生命特征：
将格式化后的生命特征与生命特征范围文件中预设的正常范围进行比较。
如果超出了预设范围，系统就发送一条警告信息给医生和护理人员。
4、维护生命特征范围：
医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围。
5、提取报告：
在医生或护理人员请求病人生命特征报告时，从日志文件中获取病人生命特征生成特征报告，并返回给请求者。
6、生成病历：
根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。
7、查询病历：
根据医生的病历查询请求，查询病历文件，给医生返回病历报告。
8、生成治疗意见：
根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。
9、查询治疗意见：
医生和护理人员查询治疗意见，据此对病人进行治疗。
现采用结构化方法对病人监控系统进行分析与设计，获得如图1—1所示的项层数据流图和图1-2所示的0层数据流图。
1、使用说明中的词语，给出图1-1中的实体E1～E3的名称。
2、使用说明中的词语，给出图1-2中的数据存储D1～D4的名称。
3、图1-2中缺失了4条数据流，使用说明、图1-1和图1-2中的术语，给出数据流的名称及其起点和终点。
4、说明实体E1和E3之间可否有数据流，并解释其原因。
参考答案及解析
1、E1：
病人E2：
护理人员E3：
医生
本题考查数据流图（DFD）应用于采用结构化方法进行系统分析与设计，是比较传统的题目，要求考生细心分析题目中所描述的内容。
DFD是一种便于用户理解、分析系统数据流程的图形化建模工具，是系统逻辑模型的重要组成部分。
本问题考查项层DFD。
顶层DFD一般用来确定系统边界，将待开发系统看作一个加工，因此图中只有唯一的一个处理和一些外部实体，以及这两者之间的输入输出数据流。
题目要求根据描述来确定图中的外部实体。
分析题目中的描述，并结合已经在顶层数据流图中给出的数据流进行分析。
从中可以看出，与系统的交互者包括病人、医生和医护人员。
其中，本地监控定期获取病人的生命特征，病人是生命特征数据来源，医生和护理人员会得到相关报告的结果，如请求病人生命特征报告，并获得相关报告。
医生还需要在必要时添加或更新生命特征范围。
对应图10中数据流和实体的对应关系，可知E1为病人，E2为护理人员，E3为医生。
2、D1：
生命特征范围文件D2：
日志文件D3：
病历文件D4：
治疗意见文件。
本问题考查0层DFD中数据存储的确定。
根据说明中的描述：
（2）格式化生命特征：
对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征；（4）维护生命特征范围：
医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围；（6）生成病历：
根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件；（8）生成治疗意见：
根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。
因此，D1为生命特征范围文件，D2为日志文件，D3为病例文件，D4为治疗意见文件。
3.
本问题考查0层DFD中缺失的处理和数据流。
从说明中的描述及图1-2可知，本地监控之后要对重要生命特征存储日志文件进行格式化，所以在本地监控和格式化生命特征之间缺少了数据流重要生命特征；检查生命特征是对格式化后的生命特征进行检查，所以在格式化生命特征和检查生命特征之间缺少了数据流格式化后的生命特征；根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。
4、E1和E3之间不可以有数据流，因为数据流的起点和终点中必须有一个是加工（处理）。
本问题考查绘制DFD时的注意事项。
在DFD中，每条数据流的起点和终点之一必须是加工（处理）。
本题中，医生和护理人员根据查询到的治疗意见对病人进行治疗属于系统之外的行为，所以两个实体之间不可以有数据流。
试题二
阅读下列说明，回答问题1至问题3，将解答填入对应栏内。
[说明]
某法院要开发一个诉讼案件信息处理系统，该信息系统的部分关系模式如下：
职工（职工编号，姓名，岗位）律师（律师编号，姓名）
被告（被告编号，姓名，地址）
案件（案件编号，案件类型，案件描述，被告，律师，主审法官，立案日期，状态，结案日期，结案摘要）
审理（审理编号，案件编号，审理日期，摘要）有关关系模式的属性及相关说明如下：
（1）职工关系模式的岗位有“法官”、“书记员”和“其他”。
（2）诉讼立案后，即在案件关系中插入一条相应记录。
案件关系模式的状态有“待处理”、“审理中”、“结案”和“撤销”，一个案件开始立案时其案件状态为“待处理”。
（3）案件关系模式的案件类型有“偷窃”、“纵火”等。
（4）一个案件自立案到结案的整个过程由一位法官和一位律师负责，一个案件通常经过一次到多次审理。
假设案件编号唯一标识一个案件，且立案日期小于等于结案日期。
请将如下创建案件关系的SQL语句的空缺部分补充完整。
CREATETABLE案件（
案件编号CHAR5（a）,
案件类型VARCHAR6,
案件描述VARCHAR7,
立案日期DATE,
被告VARCHAR5REFERENCES被告（被告编号）,
律师VARCHAR5REFERENCES律师（律师编号）,
主审法官VARCHAR5（b）,
状态VARCHAR5（c）DEFAULT'待处理',
结案日期DATE,
结案摘要VARCHAR7,
d.
};
请完成下列查询的SQL语句。
9、查询当前待处理的诉讼案件，显示案件的案件编号、立案日期、被告姓名、被告地址、案件描述、律师姓名和主审法官姓名。
SELECT案件编号,立案日期,被告.姓名，AS被告姓名,地址AS被告地址,案件描述,律师.姓名AS律师姓名,（e）
FROM（f）
WHERE案件.被告=被告.被告编号AND案件.律师=律师.律师编号AND
（g）;
10、查询2009年立案的各类案件数，并按案件数降序排序。
（日期格式举例：
2009年1月1日表示为01-JAN-2009，2009年12月31日表示为31-DEC-2009）
SELECT类型，
count（*）AS案件数
FROM案件
WHERE（h）d
GROUPBY类型
（i）;
11、查询立案次数超过5次的被告姓名和地址。
SELECT姓名,地址,count（*）
FROM案件,被告
WHERE（j）d
GROUPBY（k）d
（l）;
当插入一个审理记录时，检查案件的状态，若状态为“未处理”，则将其修改为“审理中”。
下面是用触发器实现该需求的SQL语句，请将空缺部分补充完整。
CREATETRIGGER审理TRIGGERAFTER（m）ON审理
REFERENCINGnewrowASnrow
FOREACHrow
WHEN'未处理'=（SELECT状态
FROM案件
WHERE案件编号=nrow.案件编号）
BEGIN
UPDATE案件（n）d
WHERE（o）;
END
参考答案及解析
5、PRIMARYKEY或NOTNULLUNIQUE
6、REFERENCES职工（职工编号）
7、CHECKVALUESIN（'待处理'，'审理中'，'结案'，'撤销'）
8、CHECK（立案日期＜=结案日期）
本题考查SQL语言，是比较传统的题目，要求考生细心分析题目中所描述的内容。
本问题考查SQL中的数据定义语言DDL和完整性约束。
完整性约束包括三类：
实体完整性、参照完整性和用户定义的完整性。
实体完整性约束规定关系的主属性不能取空值，关系模型中以主码作为唯一性标识；参照完整性约束规定若属性（或属性组）A是关系R上的主码，B是关系S上的外码，A与B相对应（来自相同的域），则B取值为空或者来自于R上的某个A的值；用户定义的完整性约束是针对具体的数据库应用而定义的，它反映该应用所涉及的数据必须满足用户定义的语义要求。
（a）考查实体完整性约束，案件编号是案件关系模式的主码，用关键字PRIMARYKEY或者NOTNULLUNIOUE表示。
（b）考查参照完整性约束，主审法官属性参照职工关系模式中的职工编号属性，由于这两个属性名称不同，因此用REFERENCES职工（职工编号）表示，此处不能省略职工编号。
（c）、（d）考查用户定义的完整性约束。
（c）是在状态属性上定义列级约束，用CHECKVALUESIN（'待处理'，'审理中'，'结案'，'撤销'）表示。
（d）在立案日期和结案日期上定义约束，用CHECK（立案日期＜=结案日期）表示。
9、姓名AS主审法官姓名
10、案件，被告，律师，职工（关系模式的顺序无关）
11、主审法官=职工.职工编号
12、立案日期BETWEEN'01-JAN-2009'AND'31-DEC-2009'或者立案日期＞='01-JAN-2009'AND立案日期＜='31-DEC-2009'
13、ORDERBY案件数DESC
14、被告=被告.被告编号
15、姓名，地址
16、HAVINGcount（*）＞5
本问题考查SQL中的数据操作语言DML。
（1）考查别名和连接查询条件。
（e）处考核别名定义，用AS关键字，且别名根据题干给出，应填“职工．姓名AS主审法官姓名”；（f）处考查该查询涉及到的关系模式，此处应涉及到案件、被告、律师和职工4个关系模式，在FROM子句中关系模式是顺序无关的；（g）处考核案件关系模式和职工关系模式的连接条件，即“案件.主审法官=职工.职工编号”。
（2）考查日期属性并对查询结果进行分组和排序。
（h）处主要考核日期作为条件属性的语法，题干中已经给出日期格式的提示。
在两个日期之间的时间的语法可以用BETWEEN…AND…，也可以用＞…＜=，因此，此处可以填“立案日期BETWEEN'01-JAN-2009'AND'31-DEC-2009'"或者“立案日期＞='01-JAN-2009'AND立案日期＜='31-DEC.2009'"；（i）处考核查询结果的排序，用“ORDERBY案件数DESC”表示，其中的DESC关键字不能省略。
在ORDERBY子句中，若不用表示升序的关键字ASC或表示降序的关键字DESC表示，则默认为升序排序。
（3）考查对查询结果进行分组，并指定满足条件的分组才能输出。
（i）处考核两个关系模式的连接关系，应填“案件.被告=被告.被告编号”；（k）处考核分组，此处填“姓名，地址”，不能仅填姓名或者地址；
（1）处考核分组条件，用HAVING关键字，应填“HAVINGcount（*）＞5”。
17、INSERT18、SET状态='审理中'19、案件编号=nrow案件编号本问题考查触发器。
触发器是一个能由系统自动执行对数据库修改的语句。
一个触发器由事件、条件和动态三部分组成：
事件即对数据库的插入、删除和修改等操作。
触发器在这些事件发生时，将开始工作；条件是指触发器将测试条件是否成立，若成立就执行相应的动作，否则就什么也不做；动态是指若触发器测试满足预定的条件，那么就由数据库管理系统执行这些动作。
本题首先定义触发器的事件，即对审理。
试题三
阅读下列说明，回答问题1至问题3，将解答填入对应栏内。
[说明]
某服装销售公司拟开发一套服装采购管理系统，以方便对服装采购和库存进行管理。
[需求分析]
20、采购系统需要维护服装信息及服装在仓库中的存放情况。
系统按服装的销售种类记录服装信息。
服装信息主要包括：
服装编码、服装描述、服装类型、销售价格、尺码和面料，其中，服装类型为销售分类，服装按销售分类编码。
仓库信息主要包括：
仓库编码、仓库位置、仓库容量和库管员。
系统记录库管员的库管员编码、姓名和级别。
一个库管员可以管理多个仓库，每个仓库有一名库管员。
一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。
21、当库管员发现有一类或者多类服装缺货时，需要生成采购订单。
一个采购订单可以包含多类服装。
每类服装可由多个不同的供应商供应，但具有相同的服装编码。
采购订单主要记录订单编码、订货日期和应到货日期，并需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
22、系统需记录每类服装的各个供应商信息和供应情况。
供应商信息包括：
供应商编码、供应商名称、地址、企业法人和联系电话。
供应情况记录供应商所供应服装的服装类型和服装质量等级。
一个供应商可以供应多类服装，一类服装可由多个供应商供应。
库管员根据入库时的服装质量情况，设定或修改每个供应商所供应的每类服装的服装质量等级，用以作为后续采购服装时，选择供应商的参考标准。
[概念模型设计]
根据需求阶段收集的信息，设计的实体联系图（不完整）如图3-1所示。
[逻辑结构设计]
根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）：
库管员（20，姓名，级别）
仓库信息（21，仓库位置，仓库容量）
服装（服装编码，服装描述，服装类型，尺码，面料，销售价格）
供应商（22，供应商名称，地址，联系电话，企业法人）
供应情况（23，服装质量等级）
采购订单（24）
采购订单明细（25）
20、补充图3-1中的联系和联系的类型。
21、根据图3-1，将逻辑结构设计阶段生成的关系模式中的空
（1）～（6）补充完整。
对所有关系模式，用下划线指出各关系模式的主键。
22、如果库管员定期需要轮流对所有仓库中的服装质量进行抽查，对每个仓库中的每一类被抽查服装需要记录一条抽查结果，并且需要记录抽查的时间和负责抽查的库管员。
请根据该要求，对图3-1进行修改，画出修改后的实体间联系和联系的类型。
参考答案及解析
20
本题考查数据库设计，属于比较传统的题目，考查点也与往年类似。
本问题考查数据库的概念结构设计，题目要求补充完整实体联系图中的联系和联系的类型。
根据题目的需求描述可知，一个库管员可以管理多个仓库，每个仓库有一名库管员。
所以，仓库实体和库管员实体之间存在“管理”联系，联系的类型为多对一（*:
1）。
根据题目的需求描述可知，一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。
所以，仓库实体和服装实体之间存在“存放”联系，联系的类型为多对多（*:
*）。
根据题目的需求描述可知，一个采购订单可以包含多类服装，每类服装可由多个不同的供应商供应。
所以，采购订单实体与服装实体和供应商实体三者之间存在“采购”联系，三者之间联系的类型为多对多对多（*:
*:
*）。
根据题目的需求描述可知，一个供应商可以供应多类服装，一类服装可由多个供应商供应。
所以，供应商实体和服装实体之间存在“供应”联系，联系的类型为多对多（*:
*）。
21、
（1）仓库编码，库管员编码
（2）供应商编码，服装编码
（3）订单编码，订货日期，应到货日期
（4）订单编码，服装编码，供应商编码，数量，采购价格
本问题考查数据库的逻辑结构设计，题目要求补充完整各关系模式，并给出各关系模式的主键。
根据实体联系图和需求描述，系统记录库管员的库编码、姓名和级别。
所以，对于“库管员”关系模式，需补充属性“库管员编码”。
根据实体联系图和需求描述，仓库信息主要包括：
仓库编码、仓库位置、仓库容量和库管员。
对于“仓库信息”关系模式，由于仓库实体与库管员实体有多对一联系，需记录对应的库管员，并且需补充属性——仓库编码。
因此，“仓库信息”关系模式，需补充属性“仓库编码”和“库管员编码”。
根据实体联系图和需求描述，供应商信息包括：
供应商编码、供应商名称、地址、企业法人和联系电话。
所以，对于“供应商”关系模式，需补充属性“供应商编码”。
根据实体联系图和需求描述，“供应情况”关系模式需记录供应商和服装的多对多联系，即一个供应商可以供应多类服装，一类服装可由多个供应商供应。
所以，对于“供应商”关系模式，需补充属性“供应商编码”和“服装编码”。
根据实体联系图和需求描述，采购订单主要记录订单编码、订货日期和应到货日期。
所以，对于“采购订单”关系模式需补充属性：
订单编码，订货日期，应到货日期。
由于采购订单还需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
因此，“采购订单明细”关系模式，需记录采购订单实体与服装实体和供应商实体三者之间存在的多对多对多联系。
对于“采购订单明细”关系模式，需补充属性“订单编码，服装编码，供应商编码，数量，采购价格”。
22、
本问题考查的是数据库的概念结构设计，根据新增的需求增加实体联系图中的实体的联系和联系的类型。
根据问题描述，多个库管员需对每个仓库中的每一类被抽查服装记录一条抽查结果。
则须在库管员实体与仓库实体和服装实体三者之间的存在“抽查”联系，联系的类型是多对多对多（*:
*:
*）。
升级会员 