上半年数据库系统工程师考试真题及答案下午卷.docx
- 文档编号:26561283
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:22
- 大小:171.14KB
上半年数据库系统工程师考试真题及答案下午卷.docx
《上半年数据库系统工程师考试真题及答案下午卷.docx》由会员分享,可在线阅读,更多相关《上半年数据库系统工程师考试真题及答案下午卷.docx(22页珍藏版)》请在冰豆网上搜索。
上半年数据库系统工程师考试真题及答案下午卷
2011上半年数据库系统工程师考试真题及答案-下午卷
试题一
某医院欲开发病人监控系统。
该系统通过各种设备监控病人的生命特征,并在生命特征异常时向医生和护理人员报警。
该系统的主要功能如下:
(1)本地监控:
泄期获取病人的生命特征,如体温、血压、心率等数据。
(2)格式化生命特征:
对病人的各项重要生命特征数据进行格式化,然后存入日志文件并检查生命特征。
(3)检査生命特征:
将格式化后的生命特征与生命特征范鬧文件中预设的正常范羽进行比较。
如果超岀了预设范用,系统就发送一条警告信息给医生和护理人员。
(4)维护生命特征范困:
医生在必要时(如,新的研究结果出现时)添加或更新生命特征值的正常范围。
G)提取报告:
在医生或护理人员请求病人生命特征报告时,从日志文件中获取病人生命特征生成特征报告,并返回给请求者。
(6)生成病历:
根据日志文件中的生命特征,医生对病人的病情进行描述,形成病历存入病历文件。
(7)查询病历:
根据医生的病历查询请求,査询病历文件,给医生返回病历报告。
(8)生成治疗意见:
根据日志文件中的生命特征和病历,医生给出治疗意见,如处方等,并存入治疗意见文件。
(9)查询治疗意见:
医生和护理人员查询治疗意见,据此对病人进行治疗。
现采用结构化方法对病人监控系统进行分析与设汁,获得如图1-1所示的顶层数据流图和图
1-2所示的0层数据流图。
图1-1顶层数据流圉
图1-20层
【问题1】
使用说明中的词语,给出图1-1中的实体E1-E3的名称匚
E1:
病人E2:
护理人员E3:
医生
本问题考查顶层DFD.顶层DFD—般用来确怎系统边界,将待开发系统看作一个加工,因此图中只有唯一的一个处理和一些外部实体,以及这两者之间的输入输出数据流。
题目要求根据描述来确泄图中的外部实体。
分析题目中的描述,并结合已经在顶层数据流图中给出的数据流进行分析。
从中可以看出,与系统的交互者包括病人、医生和医护人员。
苴中,本地监控定期获取病人的生命特征,病人是生命特征数据来源,医生和护理人员会得到相关报告的结果,如请求病人生命特征报告,并获得相关报告。
医生还需要在必要时添加或更新生命特征范風对应图1-1中数据流和实体的对应关系,可知E1为病人,E2为护理人员,E3为医生❾
【问题2】
使用说明中的词语,给出图1-2中的数据存储D1-D4的名称。
D1:
生命特征范用文件D2:
H志文件
D3:
病历文件D4:
治疗意见文件
解析:
本问题考査0层DFD中数据存储的确左。
根据说明中的描述:
(2)格式化生命特征:
对病人的各项重要生命特征数据进行格式化,然后存入日志文件并检查生命特征(4)维护生命特征范用:
医生在必要时(如,新的研究结果出现时)添加或更新生命特征值的正常范国:
(6)生成病历:
根据日志文件中的生命特征,医生对病人的病情进行描述,形成病历存入病历文件:
(8)生成治疗意见:
根為日志文件中的生命特征和病历,医生给出治疗意见,如处方等,并存入治疗意见文件。
因此,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)一个案件自立案到结案的整个过程由一位法官和一位律师负责,一个案件通常经过一次
到多次审理。
【问题1】
假设案件编号唯一标识一个案件,且立案日期小于等于结案日期。
请将如下创建案件关系的SQL语句的空缺部分补充完整匚
案件类型VARCHAF(lO),案件捕述VARCHAR(200).
立案日期DATE,
REFERENCES被告(被告编号厂
REFERENCES律师(律师编号).
<6)(b)r
(£>DEFAULT
(a)PRIMARYKEY或NOTNULLUNIQUE
⑹REFERENCES职工(职工编号)
(c)CHECKVALUESIN('待处理','审理中’,'结案','撤销’)
(d)CHECK(立案日期<=结案日期)本问题考査SQL中的数据左义语言DDL和完整性约束匚完整性约束包括三类:
实体完整性.参照完整性和用户立义的完整性。
实体完整性约束规疋关系的主属性不能取空值,关系模型中以主码作为唯一性标识;参照完整性约束规定若属性(或属性组)A是关系R上的主码,B是关系S上的外码,A与B相对应(来自相同的域),则B取值为空或者来自于R上的某个A的值:
用户立义的完整性约束是针对具体的数据库应用而左义的,它反映该应用所涉及的数据必须满足用户立义的语义要求。
(a)考查实体完整性约束,案件编号是案件关系模式的主码,用关键字PRIMARYKEY或者YOTNULLUNIQUE表示。
(b)考査参照完整性约束,主审法官属性参照职工关系模式中的职工编号属性,由于这两个属性名称不同,因此用REFERENCES职工(职工编号)表示,此处不能省略职工编号。
(c)、(d)考查用户定义的完整性约束。
(c)是在状态属性上泄义列级约束,用CHECKVALUESIN('待处理’,’审理中’,’结案’,’撤销’)表示。
(d)在立案日期和结案日期上立义约束,用CHECK(立案日期<=结案日期)表示。
【问题2】
请完成下列査询的SQL语句。
(1)査询当前待处理的诉讼案件,显示案件的案件编号、立案日期、被告姓名、被告地址、案件描述、律师姓名和主审法官姓名。
SELECT案件编乐立案日期,被告•姓名.AS被吿姓名.地址入S被告地址,案件描述.律师.姓
名AS律师姓名.(e)
FROM(f)
WHERE耒件■被告■被告•被告編号AND案件•律师■祁师,律师编号AND
3;
(2)査询2009年立案的各类案件数,并按案件数降序排序。
(日期格式举例:
2009年1月1日表示为01-JAN-2009,2009年12月31日表示为31-DEC-2009)
SELECT类負count(>)AS窠件数
FROM案件
WHERE(h)d
GROUPBY英型
;
(3)查询立案次数超过5次的被告姓名和地址。
SELECT姓名"地址,count(•)
FROM案件,被告
WHERE⑴d
GROUPBY(k)<1
(1)7
(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
⑶(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】
当插入一个审理记录时.检查案件的状态,若状态为“未处理S则将其修改为“审理
中S下而是用触发器实现该需求的SQL语句,请将空缺部分补充完整.
CREATETRIGGER审^TRIGGERAFTER(m)OH飓
REFERENCINGDMrowASnrow
FOREACH:
tew
WHEN、未处理・■(SELECT状态
FROM案件
WHERE案件编号-nrow.^件偏号)
BEGIN
UPDATE案件(n)d
WHERE(o)l
END
(m)INSERT(n)SET状态二'审理中’(o)案件编号二nrow•案件编号
本问题考査触发器。
触发器是一个能由系统自动执行对数据库修改的语句。
一个触发器由事件、条件和动态三部分组成:
事件即对数据库的插入、删除和修改等操作。
触发器在这些事件发生时,将开始工作:
条件是指触发器将测试条件是否成立,若成立就执行相应的动作,否则就什么也不做;动态是指若触发器测试满足预立的条件,那么就由数据库管理系统执行这些动作。
本题首先定义触发器的事件,即对审理关系模式插入后激活触发器。
接下来左义触发器的动作,即修改案件关系模式的状态为“审理中”,测试条件为若该案件原来状态为''待处理”,需要关联的两个关系模式是案件和审理。
试题三
【说明】
某服装销售公司拟开发一套服装采购管理系统,以方便对服装采购和库存进行管理。
【需求分析】
(1)采购系统需要维护服装信息及服装在仓库中的存放情况。
系统按服装的销售种类记录服装信息。
服装信息主要包括:
服装编码、服装描述、服装类型、销售价格、尺码和而料,其中,服装类型为销售分类,服装按销售分类编码。
仓库信息主要包括:
仓库编码、仓库位置、仓库容量和库管员。
系统记录库管员的库管员编码、姓名和级别。
一个库管员可以管理多个仓库,每个仓库有一需库管员。
一个仓库中可以存放多类服装,一类服装可能存放在多个仓库中。
(2)当库管员发现有一类或者多类服装缺货时,需要生成采购订单。
一个采购订单可以包含多类服装。
每类服装可由多个不同的供应商供应,但具有相同的服装编码。
采购订单主要记录订单编码、订货日期和应到货日期,并需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
(3)系统需记录每类服装的各个供应商信息和供应情况。
供应商信息包括:
供应商编码、供应商爼称、地址、企业法人和联系电话。
供应情况记录供应商所供应服装的服装类型和服装质量等级。
一个供应商可以供应多类服装,一类服装可由多个供应商供应。
库管员根据入库时的服装质量情况,设泄或修改每个供应商所供应的每类服装的服装质量等级,用以作为后续采购服装时,选择供应商的参考标准。
【概念模型设计】
根据需求阶段收集的信息,设汁的实体联系图(不完整)如图3-1所示。
K3-1实体联系圈
【逻辑结构设计】
根据概念模型设il•阶段完成的实体联系图,得出如下关系模式(不完整):
库管员(_
(1)
•姓名,级别)
仓库倍息(
⑵
仓库位賈.仓库容量)
服装(服装编码,
服装描述,
服装类型,尺码.面料,销書价格)
供应商(
(3)
供应商名称,地址,联系电话,企业法人)
供应惜况(
(4)
服装质母等级》
采购订单(
⑸
)
采购订单明细C
(6〉
>
【问题1】
补充图3-1中的联系和联系的类型。
本问题考查数据库的概念结构设汁,题目要求补充完整实体联系图中的联系和联系的类型。
根据题目的需求描述可知.一个库管员可以管理多个仓库,每个仓库有一需库管员。
所以,仓库实体和库管员实体之间存在“管理”联系,联系的类型为多对一(*:
l)o根据题目的需求描述可知,一个仓库中可以存放多类服装,一类服装可能存放在多个仓库中。
所以,仓库实体和服装实体之间存在“存放”联系,联系的类型为多对多(*:
*)o根据题目的需求描述可知.一个采购订单可以包含多类服装,每类服装可由多个不同的供应商供应。
所以.采购订单实体与服装实体和供应商实体三者之间存在“采购”联系.三者之间联系的类型为多对多对多(*:
*:
*)。
根据题目的需求描述可知,一个供应商可以供应多类服装,一类服装可由多个供应商供应。
所以,供应商实体和服装实体之间存在“供应”联系,联系的类型为多对多(*:
*)0
【问题2】
根据图3-1,将逻辑结构设计阶段生成的关系模式中的空
(1)〜(6)补充完整。
对所有关系模式,用下划线指岀各关系模式的主键匚
(1)仓库编码,库管员编码
(2)供应商编码,服装编码
(3)订单编码,订货日期,应到货日期
(4)订单编码,服装编码,供应商编码,数虽,采购价格
解析:
根据实体联系图和需求描述,仓库信息主要包括:
仓库编码、仓库位置、仓库容呈和库管员。
对于“仓库信息”关系模式,由于仓库实体与库管员实体有多对一联系,需记录对应的库管员,并且需补充属性仓库编码。
因此,“仓库信息”关系模式,需补充属性“仓库编码”和“库管员编码”。
根据实体联系图和需求描述,供应商信息包括:
供应商编码、供应商名称、地址、企业法人和联系电话。
所以,对于“供应商”关系模式,需补充属性“供应商编码”。
根据实体联系图和需求描述,“供应情况”关系模式需记录供应商和服装的多对多联系,即一个供应商可以供应多类服装,一类服装可由多个供应商供应。
所以,对于“供应商”关系模式,需补充属性“供应商编码”和“服装编码”。
根摇实体联系图和需求描述,采购订单主要记录订单编码、订货日期和应到货日期。
所以,对于''采购订单”关系模式需补充属性:
订单编码,订货日期,应到货日期。
由于采购订单还需详细记录所采购的每类服装的数量、采购价格和对应的多个供应商。
因此,“采购订单明细”关系模式,需记录采购订单实体与服装实体和供应商实体三者之间存在的多对多对多联系。
对于“采购订单明细”关系模式,需补充属性“订单编码,服装编码,供应商编码,数呈,采购价格”。
【问题3】
如果库管员左期需要轮流对所有仓库中的服装质量进行抽查,对每个仓库中的每一类被抽査服装需要记录一条抽查结果,并且需要记录抽査的时间和负责抽查的库管员。
请根据该要求,对图3-1进行修改,画岀修改后的实体间联系和联系的类型。
解析:
本问题考查的是数据库的概念结构设汁,根据新增的需求增加实体联系图中的实体的联系和联系的类型。
根据问题描述,多个库管员需对每个仓库中的每一类被抽查服装记录一条抽査结果。
则须在库管员实体与仓库实体和服装实体三者之间的存在“抽査”联系,联系的类型是多对多对多(*:
*:
*)o
试题四
某学校拟开发一套校友捐赠管理系统,以便对校友的捐赠资金进行管理。
【需求分析】
校友可以向学校提出捐赠申请,说明捐赠的金额、捐赠类型和使用方式。
捐赠类型包括一次性捐赠和周期性捐赠。
捐赠的使用方式分为两种:
一种用于资助个人,即受益人为多名学生或老师,主要用于奖学金、奖教金和助学金等;列一种用于资助捐赠项目,即资助已有的捐赠项目和设立新的捐赠项目,主要用于改善教学设施、实验室建设和设备购买等。
捐赠项目由捐赠理事建立,一个捐赠项目可以涉及多个受益单位,每个单位在该项目中有确定的受益比例。
由捐赠理事为项目中的每个单位指左一个项目负责人,并指左每个单位受益比例。
每个单位的受益比例是指在一个捐赠项目中的每个单位所应得的金额占该捐赠项目总受益金额的比例。
一个捐赠项目可以由多个捐赠来资助,一个捐赠也可以资助多个捐赠项目。
由捐赠理事将一个捐赠的捐赠金额分配给所资助的多个捐赠项目,并指泄给每个捐赠项目的具体的捐赠金额。
初步设讣了校友捐赠信息数据库,其关系模式如图4-1所示。
挖友信見(较友壊号.姓名.工作険位.积务,瞬系.班级.入学年份.身份证号)
搁倉馆息(捐葩揭号・摘昭枚友・血时何・描魁金捐81吳型•使屈方式・受益
人・受益人斫在单位・受衣人类型・受益罰处使用说明)
搞!
»项目(项目妁号・项目名祢.屈止时阿)
须目受益惰况(瓒目编号,受益申位•仇贾人,爱益比例.坍耐绘号,项目受益僉颔)
團4】校友描馬信息数锯库关系棋式
关系模式的主要属性、含义及约束如表4-1所示。
表4U主要属性、含义及約東
倔性
含义和约東箓件
项目編号
唯一标识某个掴赠项目倍息
受益人
捐贈的受益人名称
受益人类型
分为:
孕生、敦师
受益金额
毎个受益人具体得到的牺贈金额
既益比例
捎昭项目中毎个描聘单位应得到的项目ffi昭总金额的比例
项目受益金额
从一个捐《r中分配给一个摘昭项同的具体金额
【问题1】
对关系“校友信息S请回答以下问题:
(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(项目编号,捐赠编号,项目受益金额)
本问题考査的是第四范式。
根据“项目受益情况”关系模式可知,其码为:
项目编号,受益单位,捐赠编号。
而又存在
部分函数依赖:
项目编号,受益单位一受益比例
项目编号,捐赠编号一项目受益金额
项目编号一一受益单位,受益比例
项目编号一捐赠编号,项目受益金额
同时,可以根据第四范式的要求:
不允许有非平凡且非函数依赖的多值依赖。
而在'‘项目受益情况”关系模式中存在如下的多值依赖:
项目编号一-受益单位,受益比例
项目编号一-捐赠编号,项目受益金额
因此,“项目受益情况”关系模式
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 上半年 数据库 系统 工程师 考试 答案 下午