上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析.docx
《上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析.docx》由会员分享，可在线阅读，更多相关《上半年下午 数据库工程师 试题及答案与解析软考考试真题案例分析.docx（21页珍藏版）》请在冰豆网上搜索。
上半年下午数据库工程师试题及答案与解析软考考试真题案例分析
2013年上半年下午数据库工程师考试试题-
案例分析-答案与解析
试题一（共15分）
阅读下列说明和图，回答问题1至问题4，将解答填入答题纸的对应栏内。
【说明】
某慈善机构欲开发一个募捐系统，以跟踪记录为事业或项目向目标群体进行募捐而组织的集体性活动。
该系统的主要功能如下所述。
（1）管理志愿者。
根据募捐任务给志愿者发送加入邀请、邀请跟进、工作任务；管理志愿者提供的邀请响应、志愿者信息、工作时长、工作结果等。
（2）确定募捐需求和收集所募捐赠（资金及物品）。
根据需求提出募捐任务、活动请求和捐赠请求，获取所募集的资金和物品。
（3）组织募捐活动。
根据活动请求，确定活动时间范围。
根据活动时间，搜索场馆，即：
向场馆发送场馆可用性请求，获得场馆可用性。
然后根据活动时间和地点推广募捐活动，根据相应的活动信息举办活动，从募款机构获取资金并向其发放赠品。
获取和处理捐赠，根据捐赠请求，提供所募集的捐赠；处理与捐赠人之间的交互，即:
录入捐赠人信息，处理后存入捐赠人信息表；从捐赠人信息表中查询捐赠人信息，向捐赠人发送募捐请求，并将已联系的捐赠人存入已联系的捐赠人表。
根据捐赠请求进行募集，募得捐赠后，将捐赠记录存入捐赠表；对捐赠记录进行处理后，存入已处理捐赠表，向捐赠人发送致谢函。
根据己联系的捐赠人和捐赠记录进行跟进，将捐赠跟进情况发送给捐赠人。
现采用结构化方法对募捐系统进行分析与设计，获得如图1-1、1-2和1-3所示分层数据流图。
【问题1】
使用说明中的词语，给出图1-1中的实体E1〜E4的名称。
【参考答案】
E1、志愿者
E2、捐赠人
E3、募款机构
E4、场馆
【答案解析】
DFD是一种便于用户理解、分析系统数据流程的图形化建模工具，是系统逻辑模型的重要组成部分。
顶层DFD—般用来确定系统边界，将待开发系统看作一个大的加工（处理），然后根据系统从哪些外部实体接收数据流，以及系统将数据流发送到哪些外部实体，建模出的顶层图中只有唯一的一个加工和一些外部实体，以及这两者之间的输入输出数据流。
0层DFD在顶层确定的系统外部实体以及与外部实体的输入输出数据流的基础上，将顶层DFD中的加工分解成多个加工，识别这些加工的输入输出数据流，使得所有顶层DFD中的输入数据流，经过这些加工之后变换成顶层DFD的输出数据流。
根据0层DFD中的加工的复杂程度进一步建模加工的内容。
.
在建分层DFD时，根据需求情况可以将数据存储建模在不同层次的DFD中，注意在绘制下层数据流图时要保持父图与子图平衡。
父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名称上相同，或者父图中的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流。
【问题2】
在建模DFD时，需要对有些复杂加工（处理）进行进一步精化，图1-2为图1-1中处理3的进一步细化的1层数据流图，图1-3为图1-2中3.1进一步细化的2层数据流图。
补全图1-2中加工Pl、P2和P3的名称和图1-2与图1-3中缺少的数据流。
【参考答案】
P1、确定活动时间范围
P2、搜索场馆
P3、推广募捐活动
数据流名称
起点
终点
所募集资金
3.5或举办活动并募集资金
2
活动请求
2
3.2或确定活动时间范围
捐赠请求
2
3.1.3募集
所募集捐赠
3.1.3或募集
2
或
所募集资金
3.1.3或募集
2
所募集无票
3.1.3或募集
2
注：
数据流没有次序要求：
表中2处可以是“确定募捐需求收集所募捐曾”
【答案解析】
本题考查分层DFD的加工分解，以及父图与子图的平衡。
图1-2中对图1-1的加工3进行进一步分解，根据说明（3）中对加工3的描述对图1-2进行分析。
首先需要确定活动时间范围，其输入数据流是活动请求，输出流为活动时间。
然后是搜索场馆，其输入流为活动时间，输出活动时间和地点，同时向场馆发送的场馆可用性请求和获得的场馆可用性分别作为输入和输出数据流。
在确定活动时间和地点的基础上推广募捐活动，活动时间和地点是其输入流，活动信息作为其输出流，流向举办活动并募集资金，从募款机构获取资金并向其发放赠品，加工2收集募得的资金和物品，因此3.5还需要将所募集资金作为输出流。
获取和处理捐赠（资金和物品）时以捐赠请求作为其输入流，输出流为所募集的捐赠，因为既有资金又有物品，而从募款机构募得的只有资金，将图1-1中加工3流向加工2的数据流，分为所募集资金和所募集物品，而3.5的输出流中只有所募集资金。
因此，P1为确定活动时间范围，P2为搜索场馆，P3为推广募捐活动。
图1-2中缺失了从2到3.3的活动时间和从3.5到2的所募集资金这两条數据流。
题目给出处理和捐赠人之间的交互进一步描述，对3.1进一步建模下层数据流图（图1-3）。
分解加工3.1，确定相关数据流。
其中根据加工2的捐赠请求进行募集，所募捐赠需要返回给加工2。
【问题3】
使用说明中的词语，给出图1-3中的数据存储D1〜D4的名称。
【参考答案】
D1、捐赠人信息表D2:
已联系的捐赠人表
D3、捐赠表D4:
已处理捐赠表
【答案分析】
本问题考查2层DFD中数据存储的确定。
本案例中，数据存储的描述都是在这一部分描述给出，所以数据存储建模在此层体现。
对应说明可知，D1为捐赠人信息表，D2为以联系的捐赠人表，D3为捐赠表，D4为已处理捐赠表。
试题二
某航空公司要开发一个订票信息处理系统，该系统的部分关系模式如下：
航班（航班编号，航空公司，起飞地，起飞时间，目的地，到达时间，票价）折扣（航班编号，开始日期，结束日期，折扣）
旅客（身份证号,姓名，性别，出生日期，电话，VIP折扣）
购票（购票单号，身份证号，航班编号，搭乘日期，购票金额）
有关关系模式的属性及相关说明如下：
（1）航班表中的起飞时间和到达时间不包含日期，同一航班不会在一天出现两次及两次以上；
（2）各航空公司会根据旅客出行淡旺季适时调整机票的折扣，旅客购买机票的购票金额计算公式为：
票价X折扣XVIP折扣，其中旅客的VIP折扣与该旅客已购买过的机票的购票金额总和相关，在旅客每次购票后被修改。
VIP折扣值的计算由函数float_vipvalue（char[18]身份证号）完成。
根据以上描述，回答下列问题。
【问题1】
请将如下创建购票关系的SQL语句的空缺部分补充完整，要求指定关系的主键、外键，以及购票金额大于零的约束。
CREATE TABLE购票（
购票单号CHAR（15）（a）
身份证号CHAR（18）,
航班编号CHAR （6）,
搭乘日期DATE,
购票金额FLOAT（b）
（c）
（d）
）;
【参考答案】
（a）、PRIMARYKEY（或NOTNULLUNIQUE）
（b）、CHECK（购票金额>0）
（c）、FOREIGNKEY（身份证号）REFERENCES旅客（身份证号）
（d）、FOREIGNKEY（航班编号）REFERENCES航班（航班编号）
【答案解析】
本问题考查SQL中的数据定义语言DDL和完整性约束。
根据题意，已经用CREATE语句来定义购票关系模式的基本结构，需要补充主键、外键和相应的约束。
指定主键的方式有两种:
PRIMARYKEY作为列级约束（仅适应于主键为单属性时）;PRIMARYKEY（〈主键>）作为表级约束。
指定外键的语法为：
FOREIGNKEY（<外键>），REFERENCES〈被参照关系>（主键）。
CHECK约束的语法为：
CHECK（<谓词>）。
购票关系中，主键为购票单号，身份证号和航班编号为外键，分别参照旅客关系中的身份证号和航班关系中的航班编号。
【问题2】
（1）身份证号为210000196006189999的客户购买了2013年2月18日CA5302航班的机票，购票单号由系统自动生成。
下面的SQL语句将上述购票信息加入系统中，请将空缺部分补充完整。
INSERTINTO购票（购票单号，身份证号，航班编号，搭乘日期，购票金额）
SELECT‘201303105555’，‘210000196006189999’，‘CA5302’，‘2013/2/18’，
FROM航班，折扣，旅客
WHERE（f）AND航班.航班编号=‘CA5302’AND
AND‘2013/2/18’BETWEEN折扣.开始日期AND折扣.结束日期
AND旅客.身份证号=‘210000196006189999’；
（2）需要用触发器来实现VIP折扣的修改，调用函数vip_value（）来实现。
请将如下SQL语句的空缺部分补充完整。
CREATETRIGGERVIP_TRGAFTER（g）ON（h）
REFERENCINGnewrowASnrow
FOREACHrow
BEGIN
UPDATE旅客
SET（i）
WHEREQ）;
END
【参考答案】
（1）
（e）、票价*折扣*VIP折扣
（f）、航班.航班编号=折扣.航班编号
（2）
（g）、INSERT
（h）、购票
（i）、VIP折扣=vip_value（nrow•身份证号）
（j）、旅客.身份证号=nrow.身份证号
【答案解析】
（1）本问题考查INSERT语句的使用。
可以将查询结果集插入到基本表中，本题要求完成的包括购票金额的计算表达式和子查询中的条件部分。
（2）本问题考查触发器的定义。
需补充的部分涉及到触发器所在的表、触发动作（INSERT/UPDATE/DELETE）及执行代码部分。
触发器应由购票表中的INSERT指令所触发，执行代码中要修改的是旅客表中的VIP折扣值，应根据购票表中的新记录，找出对应的旅客表的记录（身份证号相等）进行修改
【问题3】
请将如下SQL语句的空缺部分补充完整。
（1）查询搭乘日期在2012年1月1日至2012年12月31日之间，且合计购票金额大于等于10000元的所有旅客的身份证号、姓名和购票金额总和，并按购票金额总和降序输出。
SELECT旅客.身份证号，姓名，SUM（购票金额）
FROM旅客，购票
WHERE（k）
GROUPBYO）
ORDERBY（m）;
（2）经过中转的航班与相同始发地和目的地的直达航班相比，会享受更低的折扣。
查询从广州到北京，经过一次中转的所有航班对，输出广州到中转地的航班编号、中转地和中转地到北京的航班编号。
SELECT（n）
FROM航班航班1，航班航班2
WHERE（o）;
【参考答案】
（1）
（k）旅客.身份证号=购票.身份证号AND
搭乘日期BETWEEN‘2012/1/1’AND‘2012/12/31’
（l）旅客•身份证号，姓名HAVINGSUM（购票金额）>=10000
（m）SUM（购票金额）DESC
（2）
（n）航班1.航班编号，航班1.目的地，航班2.航班编号
（o）航班1.起飞地=‘广州’AND航班2.目的地=‘北京’AND
航班1.目的地=航班2.起飞地
【参考答案】
（1）本问题考查一个较完整的查询语句，包括的知识点有多表查询、聚集函数、分组、筛选组和排序查询结果。
WHERE条件中应给出两个表的关联关系和日期条件；GROUPBY应按照身份证号进行分组，用组内购票金额总和大于等于10000作筛选组，ORDERBY以SUM（购票金额）进行降序输出。
（2）本问题考查连接查询，涉及到别名的使用、连接条件和选择条件及输出。
试题三
某电视台拟开发一套信息管理系统，以方便对全台的员工、栏目、广告和演播厅等进行管理。
【需求分析】
（1）系统需要维护全台员工的详细信息、栏目信息、广告信息和演播厅信息等。
员工的信息主要包括工号、姓名、性别、出生日期、电话和住址等，栏目信息主要包括栏目名称、播出时间和时长等，广告信息主要包括广告编号、价格等，演播厅信息包括房间号、房间面积等。
（2）电视台根据调度单来协调各档栏目、演播厅和场务。
一销售档栏目只会占用一个演播厅，但会使用多名场务来进行演出协调。
演播厅和场务可以被多个栏目循环使用。
（3）电视台根据栏目来插播广告。
每档栏目可以插播多条广告，每条广告也可以在多档栏目插播。
（4）一档栏目可以有多个主持人，但一名主持人只能主持一档栏目。
（5）一名编辑人员可以编辑多条广告，一条广告只能由一名编辑人员编辑。
【概念模型设计】
根据需求阶段收集的信息设计的实体联系图（不完整）如图3-1所示。
【逻辑结构设计】
根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）:
演播厅（房间号，房间面积）
栏目（栏目名称，播出时间，时长）
广告（广告编号，销售价格，
（1））
员工（玉量，姓名，性别，出生日期，电话，住址）
主持人（主持人工号，
（2））
插播单（（3），播出时间）
调度单（（4））
【问题1】
补充图3-1中的联系和联系的类型。
【参考答案】
【答案解析】
本问题考查数据库的概念结构设计，题目要求补充完整实体联系图中的联系和联系的类型。
根据题目的需求描述可知，一个栏目可以插播多条广告，而多条广告也可以在多个栏目中播放，因此栏目和广告之间存在“插播”联系，联系的类型为多对多（*:
*，或m:
n）。
根据题目的需求描述可知，一个栏目可以有多个主持人，而一个主持人只能主持一档栏目，因此栏目和主持人之间存在“主持”联系，联系的类型为一对多（1:
*，或l:
n）。
根据题目的需求描述可知，一个栏目需要使用多名场务来进行演出协调，场务可以被多个栏目循环使用，因此演播厅、栏目和场务之间存在“调度”联系，联系的类型为1对多对多（1:
*:
*，或l:
m:
n）。
【问题2】
根据图3-1,将逻辑结构设计阶段生成的关系模式中的空
（1）〜（4）补充完整，并用下划线指出
（1）〜（4）所在关系模式的主键。
【参考答案】
广告（广告编号，销售价格，编辑人员工号）
主持人（主持人工号,栏目名称）
插播单（栏5名称，广告编号，播出时间）
调度单（栏目名称，房间号，场务工号）
【答案解析】
根据实体联系图和需求描述，广告记录广告编号、销售价格和编辑人员工号。
所以，对于“广告”关系模式，需补充属性“广告编号”。
广告编号为广告的主键。
根据实体联系图和需求描述，主持人记录主持人工号和所属的栏目名称。
所以，对于“主持人”关系模式，需补充属性“主持人工号”。
主持人丁号为主持人的主键。
根据实体联系图和需求描述，插播单需要记录栏目名称、广告编号和播出的时间。
所以，对于“插播单”关系模式，需补充属性“栏目名称”和“广告编号”。
栏目名称和广告编号联合作为插播单的主键。
根据实体联系图和需求描述，调度单需要记录栏目名称、房间号和参与的场务工号。
所以，对于“调度单”关系模式，需补充属性“栏目名称”、“房间号”和“场务工号”。
栏目名称、房间号和场务工号联合作为插播单的主键。
【问题3】
现需要记录广告商信息，增加广告商实体。
一个广告商可以提供多条广告，一条广告只由一个广告商提供。
请根据该要求，对图3-1进行修改，画出修改后的实体间联系和联系的类型。
【参考答案】
说明：
*填写为01和1!
均可，参见下页图。
【答案解析】
根据问题描述，一个广告商可以提供多条广告，一条广告只由一个广告商提供。
则须在广告商实体和广告实体之间存在“提供”联系，联系的类型为1对多（1:
*，或l:
n）。
试题四
某水果零售超市拟开发一套信息系统，对超市的顾客、水果、员工、采购和销售信息进行管理。
【需求分析】
（1）水果零售超市实行会员制，顾客需具有会员资格才能进行购物，顾客需持所在单位出具的证明信才能办理会员资格，每位顾客具有唯一编号。
（2）超市将采购员和导购员分成若干个小组，每组人员负责指定的若干种水果的采购和导购。
每名采购员可采购指定给该组购买的水果；每名导购员都可对顾客选购的本组内的各种水果进行计价和包装，并分别贴上打印条码。
（3）顾客选购水果并计价完毕后进行结算，生成结算单。
结算单包括流水号、购买的各种水果信息和顾客信息等，每张结算单具有唯一的流水号。
（4）超市在月底根据结算单对导购员进行绩效考核，根据采购情况对采购员进行考核，同时也根据结算单对顾客消费情况进行会员积分。
初步设计的数据库关系模式如图4-1所示。
图4-1数据库关系模式关系模式的主要属性，含义及约束如表4-1所示。
表4-1主要属性，含义及约束
【问题1】
对关系模式“顾客”，请冋答以下问题：
（1）给出所有候选键。
（2）该关系模式可达到第几范式，用60字以内文字简要叙述理由。
【参考答案】
（1）顾客编号，身份证号
（2）可以达到第二范式。
理由：
“顾客”关系模式中，存在以下函数依赖：
单位名称—单位地址，单位电话
存在非主属性对键的传递依赖，所以“顾客”关系模式可以达到第二范式，但不满足第三范式。
【答案解析】
本问题考查非主属性和第三范式。
根据“顾客”关系模式可知，“顾客编号”和“身份证号”都是顾客的决定因素，因此都是候选键的属性。
根据第三范式的要求：
每一个非主属性既不部分依赖于码，也不传递依赖于码。
“顾客”关系模式中，存在以下函数依赖：
单位名称—单位地址，单位电话
存在非主属性对键的传递依赖，所以“顾客”关系模式可以达到第二范式，但不满足第三范式。
【问题2】
对关系模式“结算单”，请回答以下问题：
（1）用100字以内文字简要说明它会产生什么问题。
（2）将其分解为第三范式，分解后的关系名依次为：
结算单1，结算单2,…。
并用下划线标注分解后的各关系模式的主键。
【参考答案】
（1）根据“结算单”关系模式，可知其键为（流水号，条码），而又存在部分函数依赖：
条码—水果名称，销售单价，数量，金额，导购员编号
根据第二范式的要求：
不存在非主属性对键的部分依赖。
所以“结算单”关系模式不满足第二范式，会造成：
插入异常、删除异常和修改异常。
（2）对“结算单”关系模式进行分解后的关系模式及主键如下：
结算单1（流水号，条码）
结算单2（流水号，顾客编号）
结算单3（腿，水果名称，销售单价，数量，金额，导购员编号）
【答案解析】
本问题考查第二范式和第三范式。
根据“结算单”关系模式，可知其键为（流水号，条码），而又存在部分函数依赖:
条码―水果名称，销售单价，数量，金额，导购员编号。
根据第二范式的要求：
不存在非主属性对键的部分依赖。
所以“结算单”关系模式不满足第二范式，会造成：
插入异常、删除异常和修改异常。
存在部分函数依赖，因此对“结算单”关系模式进行分解后的关系模式及主键如下:
结算单1（流水号，条码）
结算单2（流水号，顾客编号）
结算单3（查M，水果名称，销售单价，数量，金额，导购员编号）
其中：
“结算单1”关系的流水号和条码两个属性联合作为主键；
“结算单2”关系的函数依赖为：
流水号—顾客编号“结算单3”关系的函数依赖为：
条码—水果名称，销售单价，数量，金额，导购员编号
这三个关系的每一个非主属性既不部分依赖于码，也不传递依赖于码，因此属于第三范式的要求。
【问题3】
对关系模式“职责”，请回答以下问题：
（1）它是否是第四范式，用100字以内文字叙述理由。
（2）将其分解为第四范式，分解后的关系名依次为：
职责1，职责2,…。
【参考答案】
（1）不属于第四范式。
根据“职责”关系模式可知：
其键为（水果名称，采购员编号，导购员编号），而存在多值依赖：
水果名称――采购员编号
水果名称——导购员编号
根据第四范式的要求，不允许存在非平凡的多值依赖。
因此，“职责”关系模式不满足第四范式。
（2）对“职责”关系模式进行分解后的关系模式如下：
职责1（水果名称，采购员编号）
职责2（水果名称，导购员编号）
【答案解析】
本问题考查第四范式。
根据“职责”关系模式可知：
其键为（水果名称，采购员编号，导购员编号），而存在多值依赖：
水果名称――采购员编号水果名称――导购员编号
根据第四范式的要求，不允许存在非平凡的多值依赖。
因此，“职责”关系模式不满足第四范式。
对“职责”关系模式进行分解后的关系模式如下：
职责1（水果名称，采购员编号）
职责1（水果名称，导购员编号）
这两个关系不存在多值依赖，因此满足第四范式的要求。
试题五
某连锁酒店提供网上预订房间业务，流程如下：
（1）客户查询指定日期内所有类别的空余房间数，系统显示空房表（日期，房间类别，数量）中的信息；
（2）客户输入预订的起始日期和结束日期、房间类别和数量，并提交；
（3）系统将用户提交的信息写入预订表（身份证号，起始日期，结束日期，房间类别，数量），并修改空房表的相关数据。
针对上述业务流程，回答下列问题。
【问题1】
如果两个用户同时查询相同日期和房间类别的空房数量，得到的空房数量为1，并且这两个用户又同时要求预订，可能会产生什么结果，请用100字以内文字简要叙述。
【参考答案】
同时预订时，可能会产生一个客户订不到或者把同一房订给两个客户。
【答案解析】
本问题是典型的并发冲突问题。
两个用户同时查询相同日期和房间类别的空房数量，得到的空房数量为1，并且这两个用户又同时要求预订。
预订的执行逻辑是用空房数量减去要预订的数量后，将值写入空房表。
会造成丢失修改的不一致性。
【问题2】
引入如下伪指令：
将预订过程作为一个事务，将查询和修改空房表的操作分别记为R（A）和W（A，x），插入预订表的操作记为W（B，a），其中x代表空余房间数，a代表预订房间数。
则事务的伪指令序列为：
x=R（A），W（A，x-a），W（B,a）。
在并发操作的情况下，若客户1、客户2同时预订相同类别的房间时，可能出现的执行序列为：
xl=R（A），x2=R（A）,W（A,xl-al）,W（Bl,al）,W（A,x2-a2）,W（B2，a2）。
（1）此时会出现什么问题，请用100字以内文字简要叙述。
（2）为了解决上述问题，引入共享锁指令SLock（X）和独占锁指令XLock（X）对数据X进行加锁，解锁指令UnloCk（X）对数据X进行解锁，请补充上述执行序列，使其满足2PL协议，不产生死锁且持有锁的时间最短。
【参考答案】
（1）出现问题：
丢失修改，客户1预订al数量房间后，对空房数量的修改被T2的修改覆盖，造成数据不一致。
（2）XLOCK（A）,xl=R（A）,W（A,xl-al）,XLOCK（B）,UNLOCK（A）,W（Bl,al）,UNLOCK（B）,XLOCK（A）,x2=R（A）,W（A,x2-a2）,XLOCK（B）,UNLOCK（A）,W（B2,a2）,UNLOCK（B。
【答案解析】
本题考查对并发事务调度的理解。
调度出现的执行序列为：
xl=R（A），x2=R（A）,W（A,xl-al）,W（B1,al）,W（A,x2-a2）,W（B2,a2）„表明两个用户读到了相同的空房数量（xl=X2）,再减去自己的订房数后写入空房表，并分别写入各自的订房记录。
客户]对空房数的修改随后会被客户2的修改所覆盖，造成丢失修改的不一致性。
按2PL协议的规定，每个事务中的加解锁指令不能交替出现。
若使其不产生死锁，则不能出现锁竞争，持有锁的时间最短，应即时释放锁。
【问题3】
下面是实现预订业务的程序，请补全空缺处的代码。
其中主变量:
Cid，:
Bdate,：
Edate,:
Rtype,:
Num分别代表身份证号，起始日期，结束日期，房间类
升级会员 