上半年数据库系统工程师考试真题及答案下午卷.docx
《上半年数据库系统工程师考试真题及答案下午卷.docx》由会员分享，可在线阅读，更多相关《上半年数据库系统工程师考试真题及答案下午卷.docx（19页珍藏版）》请在冰豆网上搜索。
上半年数据库系统工程师考试真题及答案下午卷
2011上半年数据库系统工程师考试真题及答案-下午卷
试题一
某医院欲开发病人监控系统。
该系统通过各种设备监控病人的生命特征，并在生命特征异常时向医生和护理人员报警。
该系统的主要功能如下：
（1）本地监控：
定期获取病人的生命特征，如体温、血压、心率等数据。
（2）格式化生命特征：
对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征。
（3）检查生命特征：
将格式化后的生命特征与生命特征范围文件中预设的正常范围进行比较。
如果超出了预设范围，系统就发送一条警告信息给医生和护理人员。
（4）维护生命特征范围：
医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围。
（5）提取报告：
在医生或护理人员请求病人生命特征报告时，从日志文件中获取病人生命特征生成特征报告，并返回给请求者。
（6）生成病历：
根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。
（7）查询病历：
根据医生的病历查询请求，查询病历文件，给医生返回病历报告。
（8）生成治疗意见：
根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。
（9）查询治疗意见：
医生和护理人员查询治疗意见，据此对病人进行治疗。
现采用结构化方法对病人监控系统进行分析与设计，获得如图1-1所示的顶层数据流图和图1-2所示的0层数据流图。
【问题1】
使用说明中的词语，给出图1-1中的实体E1〜E3的名称。
E1：
病人E2:
护理人员E3:
医生
本问题考查顶层DFD。
顶层DFD—般用来确定系统边界，将待开发系统看作一个加工，因此图中只有唯一的一个处理和一些外部实体，以及这两者之间的输入输出数据流。
题目要求根据描述来确定图中的外部实体。
分析题目中的描述，并结合已经在顶层数据流图中给出的数据流进行分析。
从中可以看出，与系统的交互者包括病人、医生和医护人员。
其中，本地监控定期获取病人的生命特征，病人是生命特征数据来源，医生和护理人员会得到相关报告的结果，如请求病人生命特征报告，并获得相关报告。
医生还需要在必要时添加或更新生命特征范围。
对应图1-1中数据流和实体的对应关系，可知E1为病人，E2为护理人员，E3为医生。
【问题2】
使用说明中的词语，给出图1-2中的数据存储D1〜D4的名称。
D1：
生命特征范围文件D2:
日志文件
D3：
病历文件D4:
治疗意见文件
解析：
本问题考查0层DFD中数据存储的确定。
根据说明中的描述：
（2）格式化生命特征：
对病人的各项重要生命特征数据进行格式化，然后存入日志文件并检查生命特征（4）维护生命特征范围：
医生在必要时（如，新的研究结果出现时）添加或更新生命特征值的正常范围；（6）生成病历：
根据日志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件；（8）生成治疗意见：
根据日志文件中的生命特征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件。
因此，D1为生命特征范围文件，D2为日志文件，D3为病例文件，D4为治疗意见文件。
【问题3】
图1-2中缺失了4条数据流，使用说明、图1-1和图1-2中的术语，给出数据流的名称及其起点和终点。
解析：
本问题考查0层DFD中缺失的处理和数据流。
从说明中的描述及图1-2可知，本地监控之后要对重要生命特征存储日志文件进行格式化，所以在本地监控和格式化生命特征之间缺少了数据流重要生命特征；检查生命特征是对格式化后的生命特征进行检查，所以在格式化生命特征和检查生命特征之间缺少了数据流格式化后的生命特征；根据曰志文件中的生命特征，医生对病人的病情进行描述，形成病历存入病历文件。
【问题4】
说明实体E1和E2之前可否有数据流，并解释其原因。
E1和E3之间不可以有数据流，因为数据流的起点和终点中必须有一个是加工（处理）。
解析：
本问题考查绘制DFD时的注意事项。
在DFD中，每条数据流的起点和终点之一必须是加工（处理）。
本题中，医生和护理人员根据查询到的治疗意见对病人进行治疗属于系统之外的行为，所以两个实体之间不可以有数据流。
试题二
某法院要开发一个诉讼案件信息处理系统，该信息系统的部分关系模式如下：
职工（职工编号，姓名，岗位）
律师（律师编号，姓名）
被告（被告编号，姓名，地址）
案件（案件编号，案件类型，案件描述，被告，律师，主审法官，立案日期，状态，结案日期，结案摘要）
审理（审理编号，案件编号，审理日期，摘要）
有关关系模式的属性及相关说明如下：
（1）职工关系模式的岗位有“法官”、“书记员”和“其他”。
（2）诉讼立案后，即在案件关系中插入一条相应记录。
案件关系模式的状态有“待处理”、“审理中”、“结案”和“撤销”，一个案件开始立案时其案件状态为“待处理”。
（3）案件关系模式的案件类型有“偷窃”、“纵火”等。
（4）一个案件自立案到结案的整个过程由一位法官和一位律师负责，一个案件通常经过一次到多次审理。
【问题1】
假设案件编号唯一标识一个案件，且立案日期小于等于结案日期。
请将如下创建案件关系的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（立案日期<=结案日期）表示。
【问题2】
请完成下列查询的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'或者立案日期>='01-JAN-2009'AND立案日期<='31-DEC-2009，
（i）ORDERBY案件数DESC
（3）（j）案件.被告=被告.被告编号
（k）姓名，地址
（l）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）考查对查询结果进行分组，并指定满足条件的分组才能输出。
（j）处考核两个关系模式的连接关系，应填“案件.被告=被告.被告编号”；（k）处考核分组，此处填“姓名，地址”，不能仅填姓名或者地址；
（1）处考核分组条件，用HAVING关键字，应填“HAVINGcount（*）>5”。
【问题3】
当插入一个审理记录时，检查案件的状态，若状态为“未处理”，则将其修改为“审理中”。
下面是用触发器实现该需求的SQL语句，请将空缺部分补充完整.
（m）INSERT（n）SET状态='审理中'（o）案件编号=nrow.案件编号
本问题考查触发器。
触发器是一个能由系统自动执行对数据库修改的语句。
一个触发器由事件、条件和动态三部分组成：
事件即对数据库的插入、删除和修改等操作。
触发器在这些事件发生时，将开始工作；条件是指触发器将测试条件是否成立，若成立就执行相应的动作，否则就什么也不做；动态是指若触发器测试满足预定的条件，那么就由数据库管理系统执行这些动作。
本题首先定义触发器的事件，即对审理关系模式插入后激活触发器。
接下来定义触发器的动作，即修改案件关系模式的状态为“审理中”，测试条件为若该案件原来状态为“待处理”，需要关联的两个关系模式是案件和审理。
试题三
【说明】
某服装销售公司拟开发一套服装采购管理系统，以方便对服装采购和库存进行管理。
【需求分析】
（1）采购系统需要维护服装信息及服装在仓库中的存放情况。
系统按服装的销售种类记录服装信息。
服装信息主要包括：
服装编码、服装描述、服装类型、销售价格、尺码和面料，其中，服装类型为销售分类，服装按销售分类编码。
仓库信息主要包括：
仓库编码、仓库位置、仓库容量和库管员。
系统记录库管员的库管员编码、姓名和级别。
一个库管员可以管理多个仓库，每个仓库有一名库管员。
一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。
（2）当库管员发现有一类或者多类服装缺货时，需要生成采购订单。
一个采购订单可以包含多类服装。
每类服装可由多个不同的供应商供应，但具有相同的服装编码。
采购订单主要记录订单编码、订货日期和应到货日期，并需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
（3）系统需记录每类服装的各个供应商信息和供应情况。
供应商信息包括：
供应商编码、供应商名称、地址、企业法人和联系电话。
供应情况记录供应商所供应服装的服装类型和服装质量等级。
一个供应商可以供应多类服装，一类服装可由多个供应商供应。
库管员根据入库时的服装质量情况，设定或修改每个供应商所供应的每类服装的服装质量等级，用以作为后续采购服装时，选择供应商的参考标准。
【概念模型设计】
根据需求阶段收集的信息，设计的实体联系图（不完整）如图3-1所示。
【逻辑结构设计】
根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）：
【问题1】
补充图3-1中的联系和联系的类型。
本问题考查数据库的概念结构设计，题目要求补充完整实体联系图中的联系和联系的类型。
根据题目的需求描述可知，一个库管员可以管理多个仓库，每个仓库有一名库管员。
所以，仓库实体和库管员实体之间存在“管理”联系，联系的类型为多对一（*:
1）。
根据题目的需求描述可知，一个仓库中可以存放多类服装，一类服装可能存放在多个仓库中。
所以，仓库实体和服装实体之间存在“存放”联系，联系的类型为多对多（*:
*）。
根据题目的需求描述可知，一个采购订单可以包含多类服装，每类服装可由多个不同的供应商供应。
所以，采购订单实体与服装实体和供应商实体三者之间存在“采购”联系，三者之间联系的类型为多对多对多（*:
*:
*）。
根据题目的需求描述可知，一个供应商可以供应多类服装，一类服装可由多个供应商供应。
所以，供应商实体和服装实体之间存在“供应”联系，联系的类型为多对多（*:
*）。
【问题2】
根据图3-1，将逻辑结构设计阶段生成的关系模式中的空
（1）〜（6）补充完整。
对所有关系模式，用下划线指出各关系模式的主键。
（1）仓库编码，库管员编码
（2）供应商编码，服装编码
（3）订单编码，订货日期，应到货日期
（4）订单编码，服装编码，供应商编码，数量，采购价格
解析：
根据实体联系图和需求描述，仓库信息主要包括：
仓库编码、仓库位置、仓库容量和库管员。
对于“仓库信息”关系模式，由于仓库实体与库管员实体有多对一联系，需记录对应的库管员，并且需补充属性仓库编码。
因此，“仓库信息”关系模式，需补充属性“仓库编码”和“库管员编码”。
根据实体联系图和需求描述，供应商信息包括：
供应商编码、供应商名称、地址、企业法人和联系电话。
所以，对于“供应商”关系模式，需补充属性“供应商编码”。
根据实体联系图和需求描述，“供应情况”关系模式需记录供应商和服装的多对多联系，即一个供应商可以供应多类服装，一类服装可由多个供应商供应。
所以，对于“供应商”关系模式，需补充属性“供应商编码”和“服装编码”。
根据实体联系图和需求描述，采购订单主要记录订单编码、订货日期和应到货日期。
所以，对于“采购订单”关系模式需补充属性：
订单编码，订货日期，应到货日期。
由于采购订单还需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
因此，“采购订单明细”关系模式，需记录采购订单实体与服装实体和供应商实体三者之间存在的多对多对多联系。
对于“采购订单明细”关系模式，需补充属性“订单编码，服装编码，供应商编码，数量，采购价格”。
【问题3】
如果库管员定期需要轮流对所有仓库中的服装质量进行抽查，对每个仓库中的每一类被抽查服装需要记录一条抽查结果，并且需要记录抽查的时间和负责抽查的库管员。
请根据该要求，对图3-1进行修改，画出修改后的实体间联系和联系的类型。
解析：
本问题考查的是数据库的概念结构设计，根据新增的需求增加实体联系图中的实体的联系和联系的类型。
根据问题描述，多个库管员需对每个仓库中的每一类被抽查服装记录一条抽査结果。
则须在库管员实体与仓库实体和服装实体三者之间的存在“抽査”联系，联系的类型是多对多对多（*:
*:
*）。
试题四
某学校拟开发一套校友捐赠管理系统，以便对校友的捐赠资金进行管理。
【需求分析】
校友可以向学校提出捐赠申请，说明捐赠的金额、捐赠类型和使用方式。
捐赠类型包括一次性捐赠和周期性捐赠。
捐赠的使用方式分为两种：
一种用于资助个人，即受益人为多名学生或老师，主要用于奖学金、奖教金和助学金等；另一种用于资助捐赠项目，即资助已有的捐赠项目和设立新的捐赠项目，主要用于改善教学设施、实验室建设和设备购买等。
捐赠项目由捐赠理事建立，一个捐赠项目可以涉及多个受益单位，每个单位在该项目中有确定的受益比例。
由捐赠理事为项目中的每个单位指定一个项目负责人，并指定每个单位受益比例。
每个单位的受益比例是指在一个捐赠项目中的每个单位所应得的金额占该捐赠项目总受益金额的比例。
一个捐赠项目可以由多个捐赠来资助，一个捐赠也可以资助多个捐赠项目。
由捐赠理事将一个捐赠的捐赠金额分配给所资助的多个捐赠项目，并指定给每个捐赠项目的具体的捐赠金额。
初步设计了校友捐赠信息数据库，其关系模式如图4-1所示。
关系模式的主要属性、含义及约束如表4-1所示。
【问题1】
对关系“校友信息”，请回答以下问题：
（1）列举出所有候选键的属性。
（2）关系“校友信息”可达到第几范式，用60字以内文字简要叙述理由。
（1）“校友编号”和“身份证号”。
（2）“校友信息”关系模式可以达到第二范式，不满足第三范式。
由于“校友信息”关系模式的主键是“校友编号”，但又包含函数依赖：
班级一院系，入学年份
不满足第三范式的要求，即存在非主属性对码的传递依赖。
解析：
本问题考查非主属性和第三范式。
根据“校友信息”关系模式可知，“校友编号”和“身份证号”都是校友信息的决定因素，因此都是候选键的属性。
根据第三范式的要求：
每一个非主属性既不部分依赖于码也不传递依赖于码。
根据“校友信息”关系模式，其中存在以下函数依赖：
班级一院系，入学年份
而由于“校友信息”关系模式的主键是“校友编号”，因而，存在非主属性对码的传递依赖。
所以，“校友信息”关系模式可以达到第二范式，但不满足第三范式。
【问题2】
对关系“捐赠信息”，请回答以下问题：
（1）针对“捐赠信息”关系，用100字以内文字简要说明会产生什么问题。
（2）把“捐赠信息”分解为第三范式，分解后的关系名依次为：
捐赠信息1，捐赠信息2，……
（3）列出“捐赠信息”关系修正后的各关系模式的主键。
（1）“捐赠信息”关系不满足第二范式，即非主属性不完全依赖于码。
（2）会造成：
插入异常、删除异常和修改复杂（或修改异常）。
（3）分解后的关系模式如下：
捐赠信息1（捐赠编号，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）捐赠信息2（受益人身份证号，受益人姓名，受益人所在单位，受益人类型）
捐赠信息3（捐赠编号，受益人身份证号，受益金额，使用说明）
（1）修正后的主键如下：
捐赠信息1（捐赠编号，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）
捐赠信息2（受益人身份证号，受益人姓名，受益人所在单位，受益人类型）
捐赠信息3（捐赠编号，受益人身份证号，受益金额，使用说明）
解析：
本问题考査第二范式和第三范式。
根据第三范式的要求：
非主属性不完全依赖于码。
根据“捐赠信息”关系模式，可知其码为（捐赠编号，受益人身份证号），而又存在部分函数依赖：
捐赠编号一捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式。
受益人身份证号一受益人姓名，受益人所在单位，受益人类型。
所以，捐赠信息”关系不满足第二范式，会造成：
插入异常、删除异常和修改复杂（或修改异常）。
因为存在部分函数依赖，因此对“捐赠信息”进行分解，分解后的关系模式如下：
捐赠信息1（捐赠编号，捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式）
捐赠信息2（受益人身份证号，受益人姓名，受益人所在单位，受益人类型）
捐赠信息3（捐赠编号，受益人身份证号，受益金额，使用说明）
其中，
“捐赠信息1”关系的函数依赖为：
捐赠编号一捐赠校友，捐赠时间，捐赠金额，捐赠类型，使用方式。
“捐赠信息2”关系的函数依赖为：
受益人身份证号一受益人姓名，受益人所在单位，受益人类型。
“捐赠信息3”关系的函数依赖为：
捐赠编号，受益人身份证号一受益金额，使用说明。
这三个关系中的每一个非主属性既不部分依赖于码也不传递依赖于码，因此满足第三范式的要求。
【问题3】
对关系“项目受益情况”，请回答以下问题：
（1）关系“项目受益情况”是不是第四范式，用100字以内文字叙述理由。
（2）把“项目受益情况”分解为第四范式，分解后的关系名依次为：
项目受益情况1，项目受益情况2，……
（1）“项目受益情况”关系模式，不满足第四范式。
（2）分解后的关系模式如下：
项目受益情况1（项目编号，受益单位，受益比例）
项目受益情况2（项目编号，捐赠编号，项目受益金额）
本问题考查的是第四范式。
根据“项目受益情况”关系模式可知，其码为：
项目编号，受益单位，捐赠编号。
而又存在部分函数依赖：
项目编号，受益单位一受益比例
项目编号，捐赠编号一项目受益金额
项目编号→→受益单位，受益比例
项目编号→→捐赠编号，项目受益金额
同时，可以根据第四范式的要求：
不允许有非平凡且非函数依赖的多值依赖。
而在“项目受益情况”关系模式中存在如下的多值依赖：
项目编号→→受益单位，受益比例
项目编号→→捐赠编号，项目受益金额
因此，“项目受益情况”关系模式不满足第四范式。
因为存在多值依赖，因此对“项目受益情况”进行分解，分解后的关系模式如下：
项目受益情况1（项目编号，受益单位，受益比例）
项目受益情况2（项目编号，捐赠编号，项目受益金额）
其中：
“项目受益情况1”关系的函数依赖为：
项目编号，受益单位一受益比例。
“项目受益情况2”关系的函数依赖为：
项目编号，捐赠编号一项目受益金额。
这两个关系不存在多值依赖，因此满足第四范式的要求。
试题五
某网上商品销售系统的业务流程如下：
（1）将客户的订单记录（订单号，客户ID，商品ID，购买数量）写入订单表；
（2）将库存表（商品ID，库存量）中订购商品的库存量减去该商品的购买数量。
针对上述业务流程，完成下列问题：
【问题1】
假设库存量有大于等于0的约束，可能出现如下情况：
当订单记录写入订单表后，修改库存表时因违法约束而无法执行，应如何处理？
（100字以内）
将写订单记录和修改库存表作为一个完整的事务来处理，当修改库存表无法执行时，回滚事务，则会撤销写入的订单记录，数据库保持一致。
解析：
本问题考查事务的基本概念。
对于现实中的一项业务，相对应的数据库更新操作应作为一个完整的事务，要么全做要么全不做。
销售业务对应的写入订单记录和更新库存表应作为一个事务，当出现故障（违反约束）而无法完成时，应回滚事务。
【问题2】
引入如下伪指令：
将商品A的订单记录插入订单表记为I（A）;读取商品A的库存量到变量x，记为x=I（A）;变量x值写入商品A中的库存量，记为W（A,x）。
则客户i的销售业务伪指令序列为：
Ii（A），xi=Ri（A），xi=xi-ai，Wi（A,xi）.其中ai为商品的购买数量。
假设当前库存量足够，不考虑发生修改后库存量小于0的情况。
若客户1、客户2同时购买同一种商品时，可能出现的执行序列为：
I1（A），I2（A），x1=R1（A）,x2=R2（A）,x1=x1-a1,W1（A,x1），x2=x2-a2,W2（A,x2）。
（1）此时会出现什么问题？
（100字以内）
（2）为了解决上述问题，引入共享锁指令SLock（A）和独占锁指令XLock（A）对数据A进行加锁，解锁指令Unlock（A）对数据A进行解锁，客户i的加锁指令用SLock,（A）表示，其他类同。
插入订单表的操作不需要引入锁指令。
请补充上述执行序列，使其满足2PL协议，并使持有锁的时间最短。
（1）出现问题：
客户1购买后写入的库存量值被覆盖，库存量不能体现客户1已购买，属于丢失修改造成的数据库不一致性。
（2）重写后的序列：
解析：
本问题考査对事务并发控制的相关知识的理解掌握。
若对并发事务的指令交叉执行不加以干涉，就会相互干扰，破坏事务的隔离性，造成数据库的不一致。
并发事务产的三种不一致性为丢失修改、不可重复读和读脏数据。
本例中客户1对库存量的修改被客户2的修改覆盖，出现丢失修改不一致性。
为保证可串行化调度，在事务执行过程中引入相应指令进行控制，即两段锁协议（2PL）,对数据读之前先加读锁，写前加
升级会员 