高级数据库系统设计及其应用答案.docx
- 文档编号:6848375
- 上传时间:2023-01-11
- 格式:DOCX
- 页数:78
- 大小:633.29KB
高级数据库系统设计及其应用答案.docx
《高级数据库系统设计及其应用答案.docx》由会员分享,可在线阅读,更多相关《高级数据库系统设计及其应用答案.docx(78页珍藏版)》请在冰豆网上搜索。
高级数据库系统设计及其应用答案
第一章数据库系统导论
1.1简要回答以下问题。
(1)说明数据抽象表示通常需要从哪些方面进行描述?
它与数据模型有何关系?
(2)对比逻辑数据模型与物理数据模型,说明它们的区别与联系。
(3)简述DBMS在现代计算机软件中的地位和作用。
(4)与直接采用一组操作系统文件来管理大量数据相比,采用DBMS来管理大量数据有何优势?
列出OS文件处理系统与OS的主要不同点。
(5)列举一些你所知道的、不适合用数据库作为数据管理主要解决方案的应用场合。
(6)解释外部模式、内部模式和概念模式之间的差异。
这些不同模式层是如何与逻辑数据独立性以及物理数据独立性的概念相关联的?
为什么说逻辑数据的独立性很重要?
(7)什么是DBMS的5大基本功能?
对每类基本功能,如果未实现,将会引发什么问题?
(8)在后面几个概念中,哪个在信息表示中起重要的作用?
1)数据定义语言;2)数据操纵语言;3)缓冲区管理器;4)数据模型。
答:
(1)数据抽象表示通常要从三方面进行描述:
结构特征,行为特征和约束特征。
结构特征:
通常需引入一组严格定义的概念或基本结构类型,并借助一定的表示法或模型语言来描述。
行为特征:
反映系统的操纵部分,即系统与外界的相互作用,描述系统在外界作用下的状态改变方式。
约束特征:
指为保证建模系统有意义,在系统各成份之间或状态量间必须保持的一些依存或者依赖规定。
一般通过引入一组约束规则来表达。
数据模型的定义:
数据模型是一组可精确、抽象描述数据如何表示(包括描述数据类型结构、数据关系和数据约束等数据结构化部分)的概念集,并可选地包括一组描述数据如何操纵的操作方法集。
通过系统知识的抽象表示,我们可以建立数据模型,进而研究问题。
(2)逻辑数据模型介于概念和物理两种数据模型之间。
它是数据库系统的主要工作模型,故常被简称为数据模型。
逻辑数据模型的典型代表包括关系模型、面向对象模型和对象-关系数据模型。
早期数据库系统中使用的层次模型和网状模型也属于逻辑数据模型。
低级数据模型(物理数据模型)。
所提供的概念描述了数据如何在计算机上存储的具体细节。
除了DB系统专家外,一般DB用户通常很少关注物理数据模型。
由于物理数据模型对应各DBMS底层实现部分,没有、也不需要有统一的标准实现,因此,没有专门典型命名的物理数据模型。
可见,逻辑数据模型较物理数据模型更为高层。
同时逻辑数据模型也要通过物理数据模型来进行各DBMS底层的实现。
(3)随着数据数量和共享数据用户数目的增长,DBMS已逐渐变为计算机系统不可或缺的一种重要工具,成为现代计算机信息系统和应用系统开发的核心技术。
我们可以利用DBMS的特性,以一种健壮且高效的方式来管理数据。
(4)利用DBMS管理数据,至少具有以下方面优势:
1.数据独立性
2.数据存储的有效性
3.数据共享
4.数据的完整性和安全性
5.并发存取和崩溃恢复
6.减小应用开发时间。
(5)当在某些实时应用――只有几个严格定义的关键操作,必须用高效风格的代码来实现时,DBMS性能可能不能满足其要求。
另一种不使用DBMS的原因可能是,应用可能需要以DBMS不支持的方式来查询数据。
例如,关系DBMS不支持对文本数据的灵活处理。
如果特殊的数据操作或性能是应用的核心,则应用也可能选择不使用DBMS,特别是当应用并不关心灵活查询、安全性、并发存取和崩溃恢复等性能时。
(6)概念(逻辑)模式,用数据模型概念描述数据。
内部(物理)模式,指出额外的数据存储细节,描述逻辑模式中的关系如何存储在二级存储器上。
外模式,每个外模式通常由一个或多个逻辑模式中的关系和视图构成。
外模式提供逻辑数据独立性,概念模式提供物理数据独立性。
通过提供数据的抽象视图,DBMS可以很好隔离应用代码与数据的表示和存储细节。
(7)1.安全设施
2.并发控制
3.崩溃恢复
4.视图机制
5.查询语言
安全设施保证数据不被他人盗用。
并发控制允许多个用户同时进行操作。
崩溃恢复可以使DB在崩溃的情况下恢复数据。
视图机制使得DB更加直观,利于操作。
查询语言可供查询DB中的数据,并构建视图机制。
(8)数据定义语言,因为它是用来描述外模式和逻辑模式的。
1.2列举你所知道的逻辑数据模型,并概要说明其特点。
(1)关系数据模型。
关系模型只能表达平面的数据结构,不能表达复杂的对象结构,缺乏语义表达能力。
(2)ODMG对象模型。
ODMG对象模型可直接表达任意复杂对象(不象关系模型,需将复杂对象展开为多个平面表来表示),可以显式声明对象类型之间的关系,并显式指定对象类型允许的操作。
(3)XML数据模型。
半结构化的逻辑模型。
它是一个基于树结构、且移植了XML规范各种不同细节和特性的数据表达模型,包含有节点、原子值和顺序信息等数据表示方法。
1.3列举你所知道的概念数据模型,并概要说明其特点。
(1)E-R模型。
它是一种基于图形表达的模型。
(2)EER模型。
是ER模型的扩展模型。
它在ER模型的基础上,扩展了以下概念:
1.类、超类/子类(ISA)关系、特化与泛化关系、ISA关系层次结构。
2.UNION子类或类别。
多值属性和复合结构属性。
(3)UML模型。
UML是一种基于OO范型的建模语言,它定义了一个用于建模的概念框架――用符号表示概念、用连接符号(路径)表示概念间的联系。
UML常用于对软件系统进行描述和可视化构造,允许基于不同的视点,建立描述系统体系结构的各种视图。
1.4给出5个过程化编程语言和2个非过程化编程语言,那种更容易学?
过程化编程语言:
VB,Pascal,C,C++,JSP
非过程化编程语言:
SQL,还少一个
1.5参考图1.2,简要描述DBMS实现的体系结构。
如果你的OS升级了,增加了一些支持OS文件的新函数(例如,强制一些字节序列到磁盘),那么,DBMS的那些层需要重写,以便充分利用OS的新增特性?
查询赋值引擎,包括解析器,操作符赋值器,优化器,计划执行器。
并发控制,包括事务管理器和封锁管理器。
另外还有,文件与存取方法、缓冲区管理器、磁盘空间管理器、以及恢复管理。
磁盘空间管理受到影响,同时缓冲区管理也会受到影响。
1.6简要描述五层DBMS体系结构中,各层的主要功能和核心数据结构。
(1)逻辑层(L5)是非过程化的存取层,提供表、视图等逻辑数据结构,支持采用独立于存取路径、存取过程的声明性语言(如SQL),进行数据存取。
该层将对用户查询表达进行解析和编译处理,产生初步的逻辑查询计划;利用数据存储信息,位于该层的查询优化器可将初步逻辑查询计划改写为一个高效的可执行计划。
辅助映射元数据:
逻辑模式描述
(2)导航层(L4)主要实现逻辑对象/记录集的导航存取。
在这个接口中,用户或高层模块通过使用各种扫描方式(如table-scan、index-scan),或通过各种赋值操作符,在层次结构或网络的逻辑记录集中导航。
为能支持排序、连接等高级操作,本层还应具有对记录集进行动态排序的能力。
辅助映射元数据:
逻辑和物理模式描述
(3)记录和存取路径管理层(L3),主要实现逻辑记录/对象到物理记录/对象的映射。
本层中仍能看到低层的逻辑磁盘页,必须提供聚集设施和维护所有物理对象表示(即记录、字段等在页内的表示),以及维护像B+树、散列、内部页链表或页目录这样的存取路径结构。
本层对整个DMBS系统性能有至关重要的影响,特别是当需要处理聚集选项,或需要实现可适应基于工作集(workload)预测制导的灵活存取路径时。
辅助映射元数据:
堆文件的页链表或目录项表、DB-键映射表(索引文件)
(4)传播控制层(L2)。
该层利用一个被称为DB缓冲池的专用主存区处理逻辑磁盘页读写,缓冲池被按页大小划分为一个个页槽(或称为页面框frame)。
借助传播控制层,可为主存与辅存间传送DB被修改页提供更大的自由度,以有效减少实际的物理磁盘I/O次数。
本层的DBMS组件被称为缓冲区管理器。
专门负责管理这个DB缓冲池,包括将指定逻辑磁盘页读入到DB缓冲池的特定位置中,或将缓冲池中的一些被修改页写回逻辑磁盘中。
辅助映射元数据:
DB缓冲池管理的相关辅助数据结构
(5)最底层(L1),被称为磁盘空间管理层。
操作对象为永久存储介质上的位模式数据,通常需要与操作系统(OS)文件管理子系统协同工作。
该层的主要目标是:
实现“逻辑”磁盘页到实际磁盘块的映射,即实现以页为单位的逻辑磁盘。
具体来说,就是要实现隐藏下层硬件(包括OS文件管理)细节,支持以页(page)为单位的数据存储,允许高层软件认为DB数据是一系列以页为单位的磁盘数据集。
辅助映射元数据:
线性逻辑磁盘页序列、磁盘自由块链表,或磁盘块使用位图表等
1.7从系统性能等因素考虑,你认为应适当增加还是减少DBMS系统的分层数?
为什么?
减少。
能够减少层与层间的接口。
查询预处理准备应尽可能的向下层推进,因为这种方式产生的存取代码往往比解释型查询更有效。
在这种方式下,额外的准备代价(有时可能延长查询响应时间)可以被快速分摊,特别是当存取大记录集的时候。
1.8从系统设计,尤其是系统可扩展性、可维护性等方面考虑,你认为应适当增加还是减少DBMS系统的分层数?
为什么?
增加。
增加分层数可减少各层实现的复杂度,且有利于系统的升级演化。
第二章关系数据模型与关系型数据库
2.1描述术语关系(relation)、关系模式和关系实例的区别与联系。
关系模型将数据库表示为一组“关系(relation)”的集合。
每个关系好比一个具有多个行(row)和多个列(column)的二维值表(table)。
每个关系含两部分信息:
关系模式(relationschema)和关系实例(relationinstance)。
关系模式相当于表头,而关系实例则相当于表体。
2.2描述术语数据库、数据库模式、数据库实例、数据库状态的内涵,并给出它们的形式定义。
数据库为包含一组数据的集合。
数据库模式表示存储数据的内涵。
数据库实例为数据库中存储的数据。
数据库状态的内涵表示某一刻数据库的外延。
2.3对一个给定的关系而言,候选键、主键或超键有何不同?
试解释它们之间的区别与联系。
对于关系R,如果R的某个属性子集对R的任一元组都有不同取值,我们就说该属性子集能唯一标识关系R的每个元组,该属性子集也被认为是关系R的一个超键。
没有冗余属性的超键称为候选键。
在所有可用的候选键中,DB设计者可将其中一个指定为主键。
候选键是超键的一部分,而主键又是候选键的一部分。
2.4什么是外键约束和引用完整性约束?
为什么这样的约束很重要?
引用完整性约束:
当某关系元组引用另一个关系中元组时,只能引用已经存在的元组。
外键约束:
如果关系模式R1的属性子集FK满足以下两个条件,那么,就称该FK是R1引用了或指向关系R2的外键:
(1)FK中的属性与R2的主键PK有相同的域;
(2)对关系R1中的任一元组t1,FK值要么为NULL,要么为关系R2中某元组的PK值。
当存储在一关系中的信息与存储在另一关系中的信息有联系时,为保持数据间的一致性,当一个关系被修改,要求另一个关系也必须被检查甚至做相应修改。
2.5关于关系模型,简要回答以下问题。
(1)说明关系模型的地位、作用和基本核心概念集。
(2)关系模型能表达哪些类型约束?
这些约束如何在关系模式定义中体现?
(3)从SQL查询书写者的角度看,关系模型有否提供逻辑数据和物理数据的独立性?
答:
(1)关系模型:
数据表示简单直观,且有坚实的数学基础;可基于这种简单结构,构造灵活、复杂的数据查询。
关系模型基本核心概念:
属性域,关系模式,关系实例(关系状态)。
(2)域约束,键约束、NULL属性和实体完整性约束,引用完整性约束。
关系模式代表关系的内涵。
关系模式给出了关系的名字,并为关系的每个属性(字段)规定了域约束。
(3)从SQL查询书写者的角度看,关系模型提供了逻辑数据和物理数据的独立性。
2.6考虑图2.1中的Students关系实例。
(1)假设这个实例是合法的,那么,根据这个实例,你能推理出哪个属性或哪个属性组不是候选键的一部分?
(2)假设这个实例是合法的,那么,根据这个实例,你能推理出哪个属性或哪个属性组是候选键?
答:
(1)name,sex,birthdate,class,department
(2)sid,idcard
2.7外连接操作扩展了自然连接操作,使得参与连接的关系元组能在连接结果集中保持。
描述应如何扩展一般θ连接,使得左、右或两边关系元组能出现在θ连接的结果集中。
外连接将不匹配的元组也加入到结果当中,而一般θ连接只由匹配的元组对组成。
所以如果需要左右或两边关系元组能出现不匹配元组的结果,可将一般θ连接中不可匹配的元组筛选出来放在结果中,然后除去连接的键和主键以外,其他赋值为NULL。
2.8给出至少两点理由,说明我们可能会选择定义一个视图。
首先,从安全的角度考虑,我们可能更希望各用户只看到与其有关的哪些数据。
其次,我们可能也希望能针对不同的用户,分别创建不同的个性化关系子集,以便能更好地匹配特定用户需要,使他们能以特定的视角来观察他们所感兴趣的数据子集。
2.9说明当我们需要针对视图表达直接进行更新操作时,可能出现的问题。
基于视图的修改通常是不被直接支持的。
基于视图名表达的更新,必须被等效转换为对DB中相关实关系的修改。
可能出现的问题为:
若不物化视图,则当实例数据很大时,或实例数据分散在网络不同DB服务器上时,针对视图查询的响应时间可能会很长。
若物化视图,则需要付出额外的存储代价,同时,为保持物化视图与其相关实关系的一致性,当相关实关系的实例数据变化时,我们还必须及时更新物化视图
2.10列出两个需要在DB中引入null值的理由。
当实际的列值不知道时,或者在刚插入元组不知道时,需要有null值来替代。
同时null还可以来替代结果unknown的情况。
2.11令有关系模式R=(A,B,C)和S=(D,E,F),并假设有关系实例r(R)和s(S)。
给出与下列关系代数查询等价的元组关系演算表达和SQL表达。
(1)ΠA(r)
(2)σB=17(r)
(3)r×s
(4)ΠA,F(σC=D(r×s))
答:
(1){P|∃r1∈r(r1.A)}SELECTr.AFROMr
(2){P|∃r1∈r(r1.B=17)}SELECTr.BFROMrWHEREr.B=17
(3){P|∃r1∈r∃s1∈s(r×s)}SELECTr.*FROMr,sWHEREr×s
(4){P|∃r1∈r∃s1∈s(Q=r×s^Q.C=D^Q.A^Q.F)SELECTs.As.FFROMr,sWHEREr×sANDr.C=D
2.12令有关系模式R=(A,B,C),并假设r1,r2都是基于关系模式R的实例。
给出与下列关系代数查询等价的域关系演算表达式和SQL表达式。
(1)ΠA(r1)
(2)σB=17(r1)
(3)r1∩r2
(4)r1∩r2
(5)r1-r2
(6)ΠA,B(r1)⋈ΠB,C(r2)
答:
(2){|∃A,B,C(∈r1(r.B=17))}SELECTr.BFROMrWHEREr.B=17
(3){|∃A,B,C(∈r1^∈r2)}SELECTr1.*FROMr1r2WHEREr1.A=r2.AANDr1.B=r2.BANDr1.C=r2.C
(4)
(5){|∃A,B,C(∈r1^∉r2)}SELECTr1.*FROMr1,r2WHEREr1.A<>r2.AANDr1.B<>r2.BANDr1.C<>r2.C
(6){|∃A,B,C(∈r1^∈r2)}SELECTr1.Ar1.Br2.Br2.CFROMr1,r2WHEREr1.B=r2.B
2.13令R=(A,B)和S=(A,C)是关系模式,而r(R)和s(S)是关系实例。
写出与以下域关系演算表达等价的关系-代数表达。
答:
(1)Πa(σb=17(r))
(2)ΠA,B(r)⋈ΠB,C(s)
(3)Πa(Πb(r)⋈Πc(σd(s)))
2.14考虑SQL查询:
SELECTp.a1FROMp,r1,r2WHEREp.a1=r1.a1ORp.a1=r2.a1。
在什么条件下,这个查询选择值p.a1不是在r1,就是在r2?
仔细检查r1或r2可能为空的情况。
r1和r2均非空。
2.15描述我们将选择使用嵌入SQL,而不单独使用SQL的情况或单独使用通用编程语言的情况。
当需要更大灵活性,或需要表达一些复杂查询,或需要更友好用户界面时,我们需要借助通用编程语言,来构建高级DB应用。
其中,一种方法是直接嵌入SQL命令到通用程序编程语言,另一种方法,则是应用通过存取DB关口的API函数库(如ODBC或JDBC)来操纵数据库。
2.16关于宿主语言中嵌入SQL,简要回答下列问题。
(1)说明在宿主语言的嵌入SQL语境下,存在的阻抗不匹配问题。
(2)说明为什么需要引入光标。
(3)解释下列与光标创建相关的术语选项:
updatability、sensitivity和scrollability.
(4)给出一个嵌入SQL不足以解决问题,需要动态SQL应用的应用场景实例。
答:
(1)SQL以记录集为操作对象,而宿主语言一般不支持记录集类型。
(2)通过引入光标(cursor)机制可以解决阻抗不匹配的问题。
我们可声明一个查询结果集或一个关系为一个光标;对已声明的光标,可通过执行打开OPEN操作进行赋值;然后,再用FETCH语句顺序取出光标行进行处理;处理结束后关闭(CLOSE)光标。
(3)如果希望对光标行进行修改,并让修改结果更新到DB中,则应选用FORUPDATE子句。
如果指定了关键字INSENSITIVE,则光标相当于对结果集元组的一个私有复制,不受其它事务影响。
若未指定INSENSITIVE(缺省),其它事务可能在光标赋值后未关闭前,修改某些光标行对应的原关系数据。
如果指定了关键字SCROLL,则光标是可滚动的
(4)若程序希望在运行时执行不同的、临时指定的SQL语句。
比如,某些图形前端应用需接受来自用户提交的任何SQL命令,检索事先无法预知的数据集。
2.17采用如下不同技术,分别写一个可独立运行的小程序,计算sailors关系表中所有水手年龄的均方差。
(1)采用基于C语言的嵌入SQL命令。
(2)采用ODBC技术。
(3)采用JDBC1.0。
(4)采用JDBC2.0或更高版本。
略
第三章数据库设计
3.1简要描述为一个企业建立数据库应用需要的几大基本步骤。
DB设计过程大体上可划分为六个步骤”
(1)需求分析
(2)概念DB设计。
利用需求分析获得的信息,建立DB数据的一个抽象描述。
这一步通常利用ER/EER模型,或其它高级数据概念模型(如UML类图),来实现。
(3)逻辑DB设计。
转换DB概念设计模式到指定DBMS逻辑模式。
若只考虑RDBMS,则最终希望获得的是关系数据库模式。
(4)模式细化。
分析关系数据库模式的关系集,检查潜在问题并进行优化。
与需求分析和概念设计的主观性特点不同,细化可得到强有力的规范理论支持。
(5)物理DB设计。
考虑我们必须支持DB的一些典型预期负荷,并以此为基础进一步求精DB设计,确保它能满足预期的性能要求。
这个步骤可能包括为一些表建立索引和指定聚集存储方式等。
(6)安全设计
3.2关于ER模型,简要回答以下问题。
(1)说明ER模型的地位、作用和基本核心概念集。
(2)ER中图能表达哪些类型约束?
这些约束在关系模型中都能表达吗?
答:
(1)实体-关系模型(Entity-Relationmodel),简称ER模型,是一种非常流行的概念数据模型,允许我们从“实体(对象)及其相互关系”的角度,描述现实世界,尽可能忠实地对各类数据进行建模。
基本核心概念集:
键,关系,关系类型,关系集。
(2)关系集(关系类型)通常可带一定的约束,简称关系约束。
关系约束主要包括基数词约束、键约束和参与约束三类。
当需要建立两个关系集间的关联时,ER图可能不能清晰表达。
3.3若有一个汽车保险公司,它的每个顾客可能拥有一辆或多辆汽车,每辆汽车可能关联0次或多次事故记录。
请构造一个描述此场景数据概念模式的E-R图。
3.4对大学数据库中,针对以下各种情况,画出描述教授(Professors)讲授(Teachs)课程(Courses)关系的ER图。
(1)教授们可能在几个学期讲授同一门课程,每学期上课都必须被记录;
(2)教授们可能在几个学期讲授同一门课程,只需记录最近一个学期的上课情况;
(3)每个教授必须讲授几门课程;
(4)每个教授只且必须讲授一门课程;
(5)每个教授只且必须讲授一门课程;每门课程都必须有人讲授。
答:
(1)
(2)
(3)
(4)
(5)
3.5考虑一个简单版的“大学数据库”,它包括以下一组实体集,每个实体集需要的描述属性已在其后
括号内注明。
●教授,Professors(ssn/name/age/rank/specialty研究专业);
●项目,Projects(proj-id/sponsor_name/starting_date/ending_date/budget);
●研究生,Graduates(ssn/name/age/degree-program);
●系,Departments(did,name,office)。
假定在这些实体集之间存在以下的相互联系:
●每个教授挂靠在(Works_in)一个系。
●每个研究生有一个主修(Majors)专业系。
●每个系有且必须有一名系主任,由一名教授担任,负责管理(Runs)该系的事务工作。
●每个项目由一名教授负责(Managed_by),多名教授可能参与(Works_on)同一项目的工作,每个教授允许负责或参与多个项目。
●一个项目组中可能有多名研究生参与,当然,一个研究生也允许同时参与多个项目工作。
●在一个项目组中,必须给每个研究生指定一名教授,以督导(Supervises)该学生的项目工作(同时参与多个项目的研究生,可能会有多个督导老师)。
试针对以上描述的大学数据库,画出一个能反映其概念模式的ER图。
答:
3.6映射习题3.3、3.4、3.5的E-R图到关系模式。
答:
1)3.3:
CREATTABLEGuarantee(ssnINTEGER,
cidCH
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 高级 数据库 系统 设计 及其 应用 答案