上半年数据库系统工程师考试真题及答案下午卷2.docx
- 文档编号:9773027
- 上传时间:2023-02-06
- 格式:DOCX
- 页数:19
- 大小:532.17KB
上半年数据库系统工程师考试真题及答案下午卷2.docx
《上半年数据库系统工程师考试真题及答案下午卷2.docx》由会员分享,可在线阅读,更多相关《上半年数据库系统工程师考试真题及答案下午卷2.docx(19页珍藏版)》请在冰豆网上搜索。
上半年数据库系统工程师考试真题及答案下午卷2
2022上半年数据库系统工程师考试真题及答案-下午卷
试题一
某医院欲开发病人监控系统。
该系统通过各种设备监控病人的生命特征,并在生命特征异常时向医生和护理人员报警。
该系统的主要功能如下:
(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)査询2022年立案的各类案件数,并按案件数降序排序。
〔日期格式举例:
2022年1月1日表示为01-JAN-2022,2022年12月31日表示为31-DEC-2022〕
(3)查询立案次数超过5次的被告姓名和地址。
(1)(e)职工.姓名AS主审法官姓名
(f)案件,被告,律师,职工〔关系形式的顺序无关〕
(g)案件.主审法官=职工.职工编号
(2)(h)立案日期BETWEEN'01-JAN-2022'AND'31-DEC-2022'或者立案日期>='01-JAN-2022'AND立案日期<='31-DEC-2022,
(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-2022'AND'31-DEC-2022'〞或者“立案日期>='01-JAN-2022'AND立案日期<='31-DEC-2022'〞;(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),
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 上半年 数据库 系统 工程师 考试 答案 下午
![提示](https://static.bdocx.com/images/bang_tan.gif)