数据库系统工程师历年真题答案解析Word格式.docx

数据库系统工程师历年真题答案解析Word格式.docx

《数据库系统工程师历年真题答案解析Word格式.docx》由会员分享，可在线阅读，更多相关《数据库系统工程师历年真题答案解析Word格式.docx（20页珍藏版）》请在冰豆网上搜索。

（24）

（39）

（54）

（69）

（10）

（25）

（40）

（55）

（70）

（11）

（26）

（41）

（56）

（71）

（12）

（27）

（42）

（57）

（72）

（13）

（28）

（43）

（58）

（73）

（14）

（29）

（44）

（59）

（74）

（15）

（30）

（45）

（60）

（75）

下午试题参考答案

试题一

[问题1]解答

　　起点：

读者文件终点；

登记读者信息或3

处理查询请求或2终点：

读者文件

[问候2]解答

　　起点；

图书目录文件终点：

图书信息查询或2.2

借书文件终点：

读者信息查询或2.1

借书文件终点；

[问题3]解答

（1）[入库单｜借书单｜还书单｜注销单]

（2）分类目录号+书名+作者+价格+数量+购书日期

试题二

　　（a）PRIMARYKEY

　　（b）FOREIGNKEY（负贵人代码）REFERENCES职工

　　（c）FOREIGNKEY（部门号）REFERENCES部门

　　（d）月工资>

=500AND月工资<

=5000

　　（e）coumt（*）,Sum（月工资）,Avg（月工资）

　　（f）Croupby部门号

[问题2]解答

（1）该行不能插入“职工”关系，它违反了实体完整性中主码必须唯一区分关系中的每一个属性。

（2）该行可以插入“职工”关系，尽管部门号、电话和办公室为空，但是它表示该雇员没有分配到某个部门。

　　（3）该行不能插入“职工”关系，它违反了参照完整性。

因为6在关系“部门’中不存在。

　　此间考查的是对视图定义的掌握。

（1）和

（2）都不能更新，因为使用分组合聚集函数定义的视图是不可更新的。

　　（3）不一定，视子查询的返回值而定，（4）和（5）允许查询。

[问题4]解答

　　此间考察的是查询效率的问题。

在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。

（1）对于外层的职工关系E中的每一个元组，都要对内层的整个职工关系M进行检索，因此查询效率不高。

（2）解答一

　　改正后的SQL语句使用了临时表：

　　　SelectMax（月工资）as最高工资，部门号intoTempfrom职工

　　　　Groupby部门号

　　　Select职工号from职工,Temp

　　　　where月工资=最高工资and职工．部门号=Temp.部门号

　　解答二

　　　Select职工号from职工，（SelectMax（月工资）as最高工资，部门号

　　　Groupby部门号）asdepMax

　　　　where月工资=最高工资and职工.部门号=depMax.部门号

[问题5]解答

　　此问主要考察在查询中注意where子句中使用索引的问题。

　　　Select姓名，年龄，月工资from职工

　　　　where年龄>

45；

　　　union

　　　　where年龄月工资<

1000；

试题三

[问题1]解答

　　商品（商品编号，商品名称，供应商，单价）

　　直销商品（商品编号，生产批号，消费期限）

　　库存商品（商品编号，折扣率）

　　销售详单（销售流水号，商品编码，数量，金额，收银员，时间）

　　销售日汇总（日期，商品编码，数量）

　　存货表（商品编码，数量）

　　进货表（送货号码，商品编码，数量，日期）

　　商品（商品编码，商品名称，供应商，单价）

　　1．采用商品信息集中存储在中心数据库中，则在销售前台的每笔计费中，都必须从中心数据库提取商品名称和单价，增加网络的负载，在业务繁忙时直接影响到前台的销售效率；

同时，如果发生网络故障，则该POS机不能工作。

采用这种方式，对商品库的更新，如引入新的商品和修改商品价格，会及时体现在前台的销售业务中。

　　2．采用商品信息存储在中心数据库中，各Pos机存储商品表的备份，POS机直接从本地读取商品信息，减少了网络的负载，可以提高交易的效率；

同时即使有短时间的网络故障，也不影响该POS机的正常使用，只有当存在商品信息变更时才需要与中心数据库同步。

　　采用这种方式，必须在每次商品信息变更时同步各POS机的数据。

　　1．对销售详单做如下的修改，增加积分卡号属性。

　　销售详单（销售流水号，商品编号，数量，金额，收银员，时间，积分卡号）

　　2．加积分卡关系：

积分卡（积分卡号，累积消费金额，积分点）

试题四

（1）“航班”关系模式的候选键为（航班名，飞行日期），非键属性为；

航空公司名称，出发地点，出发时间，目的地，到达时间。

（2）“航班”是属于1NF的。

因为非主属性航空公司名称，出发地点，目的地不完全函数依赖于候选键（航班名，飞行日期）。

　　该关系模式存在如下函数依赖：

　　航班名→航空公司名称，出发地点，目的地；

　　（航班名，飞行日期）→出发时间，到达时间。

　　参考答案1

（1）在题中给出的“旅客”关系中，不同的团队会有相同的旅客编号，所以，旅客编号不能作为候选键，如果同一旅客不同时间参加不同的团队将导致“身份证号无法确定关系中的每一个元组，所以“身份证号”也不能作为候选键。

为此，需要增加一个“团队编号”的属性。

又由于{（身份证号，团队编号）→旅客编号；

（旅客编号，团队编号）→身份证号；

身份证号一（姓名，联系方法，出生日期，性别）}，所以该关系模式存在部分函数依赖，导致旅客参加多少次团队，其姓名等信息将重复多少次。

（2）候选键：

（身份证号，团队编号）和（旅客编号，团队编号）

　　（3）“旅客”分解为第三范式如下所示：

　旅客1（身份证号，姓名，联系方法，出生日期，性别） 

　旅客2（旅客编号，身份证号，团队编号）

　　参考答案2

（1）在题中给出的“旅客”关系中，不同的团队会有相同的旅客编号，所以，旅客编号不能作为候选键，如果同一旅客不同时间参加不同的团队将导致“身份证号”无法确定关系中的每一个元组，所以“身份证号”也不能作为候选键。

为此，可以通过修改“旅客编号”属性的定义加以解决，旅客编号由“团队编号+队内编号”来解决。

这时关系的候选键为“旅客编号”，该关系模式存在传递依赖，导致旅客参加多少次团队，其姓名等信息将重复多少次。

（2）候选键；

旅客编号。

　旅客2（旅客编号，身份证号）

（1）旅程编号→→旅客编号，旅程编号→→{搭乘日期，航班名}

（2）在“搭乘航班”关系中，存在着非平凡的多值依赖，旅程编号→旅客编号，旅程编号→→{搭乘日期，航班名}，而该关系模式的候选键为（旅程编号，旅客编号，搭乘日期，航班名），所以，根据第四范式的定义，该关系模式BCNP不是第四范式。

　　（3）把分解成第四范式的结果，用与图4-1所示的关系模式的形式表示出来。

　搭乘航班1（旅程编号，旅客编号）

　搭乘航班2（旅程编号，航班名，搭乘日期）

2005年上半年数据库系统工程试题答案

上午答案

（1）

C

（16）

B

（31）

A

（46）

（61）

（2）

D

（17）

（32）

（47）

（62）

（3）

（18）

（33）

（48）

（63）

（4）

（19）

（34）

（49）

（64）

（5）

（20）

（35）

（50）

（65）

（6）

（21）

（36）

（51）

（66）

（7）

（22）

（37）

（52）

（67）

（8）

（23）

（38）

（53）

（68）

（9）

（24）

（39）

（54）

（69）

（10）

（25）

（40）

（55）

（70）

（11）

（26）

（41）

（56）

（71）

（12）

（27）

（42）

（57）

（72）

（13）

（28）

（43）

（58）

（73）

（14）

（29）

（44）

（59）

（74）

（15）

（30）

（45）

（60）

（75）

下午答案

[问题1]

（1）起点：

学生住宿服务系统终点：

房主

数据流名：

费用信息或交纳的费用或费用

（2）起点：

房屋文件终点：

查询房屋　或　4

[问题2]

　　房主文件和学生文件

[问题3]

　　姓名+现住址+电话号码+出生日期+性别

　（a）PRIMARYKEY仓库号

　（b）PRIMARYKEY　或　NOT　NULL　UNIQUE

　（c）CHAR（4）

　（d）FOREIGNKEY仓库号PEFERENCES仓库（仓库号）

　（e）原材料

　（f）GROUPBY仓库号

　　　　HAVINGSUM（数量）>

=ANY（SELECTSUM（数量）

　　　　　　　　　　　　　　　　　　　　FROM原材料

　　　　　　　　　　　　　　　　GROUPBY仓库号）

　（g）*或编号，名称，数量，储备量，仓库号

　（h）INSERT，DELETE，UPDATE

　（i）raws_in_wh01

　（j）SELECT

　（k）原材料

[问题4]

　（l）UPDATE，INSERT

　（m）nrow.编号

　（n）nrow.存储量*3

[问题5]

　　存在问题：

触发器程序判定某一原材料"

数量"

是否小于其存储量时，是按照当前记录的"

来判定的，当一种原材料存储在多个仓库时，这样判定是错误的，应根据该原材料在各仓库的存储总量来判定。

应将触发器程序的WHEN子句条件修改为：

　　WHENnrow.储备量>

（SELECTSUM（数量）

　　　　　　　　　　　　　　　FROM原材料

　　　　　　　　　　　　　　　WHERE编号=（SELECT编号

　　　　　　　　　　　　　　　　　　　　　　　FROMnrow）

　　　　　　　　　　　　　　　GROUPBY编号）

（a）

　（b）个人编号，岗位，最低薪水，登记日期

　（c）企业编号，岗位，专业，学历，薪水，备注，登记日期

　（d）个人编号，姓名，性别，出生日期，身份证号，毕业院校，专业，学历，证书名称，联系电话，电子邮件，个人简历及特长

　（e）证书名称，证书编号

　　企业（企业编号，企业名称，联系人，联系电话，地址，企业网址，电子邮件，企业简介）

　　求职意向（个人编号，岗位，最低薪水，登记日期）

　　岗位需求（企业编号，岗位，专业，学历，薪水，备注，登记日期）

　　人才（个人编号，姓名，性别，出生日期，身份证号，毕业院校，专业，学历，证书名称，联系电话，电子邮件，个人简历及特长）

　　证书（证书名称，证书编号）

　　此处的"

需求"

是"

岗位"

、"

企业"

和"

人才"

三个实体之间的联系，而事实上只有人才被聘用之后三者之间才产生联系。

本系统解决的是人才的求职和企业的岗位需求，人才与企业之间没有直接的联系。

　　建立企业的登录信息表，包含用户名和密码，记录企业的用户名和密码，将对本企业的基本信息的修改权限赋予企业的用户名，企业工作人员通过输入用户名和密码，经过服务器将其与登录信息表中记录的该企业的用户名和密码进行验证后，合法用户才有权限修改企业的信息。

　　部门（部门代码，部门名，起始年月，终止年月，办公室，办公电话）

　　F1={部门代码→（部门名，起始年月，终止年月），部门代码→办公室，办公室→办公电话}

　　等级（等级代码，等级名，年月，小时工资）

　　F2={等级代码→等级名，（等级代码，年月）→小时工资}

　　项目（项目代码，项目名，部门代码，起始年月日，结束年月日，项目主管）

　　F3={项目代码→（项目名，部门代码，起始年月日，结束年月日，项目主管）}

　　工作计划（项目代码，职员代码，年月，工作时间）

　　F4={（项目代码，职员代码，年月）→工作时间}

（1）职务（职务代码，职务名，等级代码）

（2）工作业绩（项目代码，职员代码，年月日，工作时间）

（1）部门关系模式属于2范式，该关系模式存冗余问题，因为某部门有多少个办公室，部门代码、部门名、起始年月、终止年月就要重复多少次。

　　为了解决这个问题可将模式分解，分解后的关系模式为：

　　部门_A（部门代码，部门名，起始年月，终止年月）

　　部门_B（部门代码，办公室，办公电话）

（2）SELECT职员代码，职员名，年月，工作时间*小时工资AS月工资

　　　　FROM职员，职务，等级，月工作业绩

　　　　WHERE职员.职务代码=职务.职务代码AND

　　　　　　　职务.等级代码=等级.等级代码AND

　　　　　　　等级.年月=月工作业绩.年月AND

　　　　　　　职员.职员代码=月工作业绩.职员代码

2006年上半年数据库系统工程师试题答案

　　外部实体：

（选课）学生、（任课）老师

　　数据存储：

作业成绩统计文件

（1）（选课）学生

（2）（选课）学生

　（3）（选课）学生

　（4）（选课）学生

　（5）作业成绩

　（6）DB

　（7）作业成绩统计文件

　（8）作业成绩

　（9）（任课）老师

　（10）DB

　（11）作业

　（12）选课）学生

　（13）（任课）老师

　　错误1：

外部实体A和B之间不能存在数据流。

　　错误2：

外部实体A和数据存储H之间不能存在数据流。

　　错误3：

加工2的输入/输出数据流名字相同

　　错误4：

加工4只有输入没有输出

　　错误5：

加工5只有输出，没有输入。

　（a）NOTNULLUNIQUE

　（b）CHECK（VALUEIN（'

男'

，'

女'

））

　（c）FOREIGNKEY（客户号）REFERENCES客户（客户号）

　（d）查询一次订购（或购买）产品号为02的数量大于10的客户号

　（e）π客户号（订单?

σ产品号='

02'

^数量>

10（订单明细））

　（f）可以优化。

优化的SQL语句为：

　SELECT客户号

　FROM订单

　WHERE订单号IN

　（SELECT订单号

　　FROM订单明细

　　WHERE产品号='

02'

AND数量>

10）

　（g）SUM（金额）AS总额

　（h）GROUPBY客户.客户号

　（i）ORDERBY总额DESC

（1）CREATEVIEW客户产品AS（

　　　　SELECT客户号，产品号

　　　　FROM订单，订单明细

　　　　WHERE订单明细.订单号=订单.订单号）

（2）（j）NOTEXISTS 

　　　（k）客户号='

01'

ANDNOTEXISTS

　　　（l）客户产品1.客户号=客户产品3.客户号AND客户产品2.产品号=客户产品3.产品号

　　采用数据库管理系统的触发器机制。

对产品关系定义一个触发器，在订单明细中的记录插入或更新之后，该触发器被激活，根据订单明细中订购的产品及数量，减少产品关系中对应产品的库存量。

（1）n

（2）m

　（3）l

　（4）n　或　m

　（a）读者ID，图书ID

[问题3]

关系模式

主键

外键

读者

读者ID

／

书目

ISBN号

图书

图书ID

借还记录

读者ID，图书ID，借书时间

读者ID，图书ID

　　补充联系"

预约"

，修补后的实体联系图

　　增加新的关系模式：

　　　预约登记（读者ID，ISBN号，预约时间，预约期限，图书ID）

　　　主键：

（读者ID，ISBN号，预约时间）

　　　外键：

读者ID，ISBN号，图书ID

　　投保单：

（投保书号，受益人身份证号码）

　　客户信息：

客户号

　　缴费记录：

（投保书号，缴费月份）

　　险种信息：

险种名称

　　投保单关系模式的函数依赖：

　　　F1=（投保书号，受益人身份证号码）→（投保人客户号，被保人客户号，险种名称，受益顺序，业务员姓名，业务员联系方式，投保日期）

　　　F2=投保书号→（投保人客户号，被保人客户号，险种名称，业务员姓名，业务员联系方式，投保日期）

　　　F3=受益人身份证号码→身故受益人姓名

　　　F4=业务员姓名→业务员联系方式

（1）投保单关系模式存在更新异常。

该关系模式存在冗余数据，修改数据时可能会引起修改异常，例如当业务员的联系方式发生变化时，他所负责的每一个投保单里面的业务员联系方式必须更新，如果部分更新，部分不更新，则会产生修改（更新）异常；

当一个业务员还没有任何投保单时，他的数据将不能插入数据库，即存在插入异常；

当一个投保单记录删除了之后，对应的业务员信息也丢失了，即存在删除异常。

（2）投保单关系模式存在多值依赖，一个特定的投保单对应多个受益人。

　　投保单关系模式属于1范围（或1NF），该关系模式存在数据冗余。

例如一个业务员的姓名、联系方式属性与其负责的投保单数量一样多。

在具有多个受益人的一个投保单中，投保单的诸多属性存储多次。

关系模式还存在上题所说的更新异常和多值依赖。

其函数依赖存在非主属性部分依赖于码，故不屑于2范式（或2NF）。

　　将投保单关系模式进行如下模式分解：

　　　投保单（投保书号，投保人客户号，被保人客户号，险种名称，业务员号，投保日期）

　　　受益人信息（受益人号，受益人姓名，受益人身份证号码）

　　　业务员信息（业务员号，业务员姓名，业务员联系方式）

　　　投保-受益信息（投保书号，受益人号，收益人顺序）

　　上述模式分解后，能保证在每个关系模式中，属性间无非平凡且非函数依赖的多值依赖，故达到了4范式（或4NF）。

　　增加如下关系模式即可满足需求：

　　提成信息（总金额，提成比例）

　　其中总金额属性描述一个金额范围，提成比例表示对应该范围的提成比例。

用户查询投保单关系模式，获得业务员每月的保单总金额，再在提成信息关系模式中查询对应的提成比例，即可计算出业务员的月奖金。

试题五

　　事务的可串行调度。

多个事务的并发执行是正确的，尚且仅当其结果与按某一次序串行执行它们时的结果相同。

　　此调度是一个可串行化的调度，所以是一个正确的调度。

　　T1，T2，T3，T4

　　两段锁协议。

把事务分为两个阶段，第一阶段是获得封锁，但不能解锁；

第二个阶段是解除封锁，不能申