数据库考试题答案全集.docx
《数据库考试题答案全集.docx》由会员分享，可在线阅读，更多相关《数据库考试题答案全集.docx（17页珍藏版）》请在冰豆网上搜索。
数据库考试题答案全集
1．回答以下问题：
（1）什么是E-R图：
实体-联系是基于对现实世界的这样一种认识：
现实世界是由一组称为实体的基本对象以及这些对象之间的联系构成的。
实体是现实世界中可区别于其他对象的一个“事件”或一个“物体”，例如，每个人是一个实体，每个银行账户也是一个实体。
实体要通过它的属性集合来描述。
联系是实体间的相互关联。
E-R图可以表达现实世界中实体和实体之间的联系。
图中有以下元素构成：
矩形：
代表实体集。
椭圆：
代表属性。
菱形：
代表实体集间的联系。
线段：
将属性和实体集相联或将实体集于联系相连。
双椭圆：
表示多值属性。
虚椭圆：
表示派生属性。
双线：
表示一个实体全部参与到联系集中。
（2）什么是数据库系统设计的参照完整性约束？
参照完整性约束：
“参照”需要完整的，这个约束叫“参照完整性约束”
令关系r1（R1）和r2（R2）的主码分别为K1和K2。
称R2的子集a为参照关系r1中K1的外码，是要求对r2中任意元组t2，均存在r1中元组t1使得t1[K1]=t2[a]。
这种要求成为参照完整性约束，也叫外码约束。
保证一个关系中给定属性集上的取值也在另一关系的某一属性集的取值中出现，从而保证当授权用户对数据库做修改时不会破坏数据的一致性。
外键码约束又称参照完整性约束，用来限定本表外键码字段列值与相关表主键码字段列值的匹配，即保证相关数据的一致性。
（3）什么是事务的并发控制?
事务是构成单一逻辑工作单元的操作集合。
无论有无故障，数据库系统必须保证事务的正确执行——或者执行整个事务或者属于该事务的操作一个也不执行。
数据库系统必须控制事务的并发执行，保证数据库处于一致的状态。
把并发的多个事务转化成可串行的事务就是事务的并发控制。
并发控制机制的目标是获得高度的并发性，同时保证所产生的调度是冲突或视图可串行化的，并且是无级联的。
采取的方法有：
各种封锁协议、时间戳排序机制、有效性检查技术、多版本机制。
（4）什么是触发器？
触发器：
它是一条语句，当一定条件满足时，它自动执行，对数据库进行修改。
（5）什么是关系数据库系统的规范化设计？
关系数据库系统的规范化设计：
它要求数据库设计满足第一范式，如果不能设计到满足第三范式的情况下，允许存在一定的冗余。
这种情况称之为PC范式。
首先必须要符合,无损连接和保持依赖,最好可以达到BCNF如果不能达到,可允许存在少量冗余以满足3NF
（6）什么是事务处理？
事务处理主要是事务的并发控制，使系统中的多个事务并行执行，同时保证可串行化，提高系统的利用率。
无论有无故障，数据库系统必须保证事务的正确执行——或者执行整个事务或者属于该事务的操作一个也不执行。
数据库系统必须控制事务的并发执行，保证数据库处于一致的状态。
把并发的多个事务转化成可串行的事务就是事务的并发控制。
（7）什么是数据定义语言，数据操纵语言？
数据定义语言（DDL）：
是一种特殊语言，用来定义数据库模式。
Ddl语言的编译结果是产生数据字典或数据目录（存储在一个特殊文件中的一系列表）。
数据操纵语言（DML）：
使用户可以访问和操纵由适当的数据模式组织起来的数据。
通常有两类：
过程化的数据操纵语言：
它要求用户指定需要什么数据以及如何获得这些数据。
非过程化的数据操纵语言：
只要求用户指定需要什么数据，而不必指明如何获得这些数据。
（8）什么是数据库系统的ACID特性？
（事务概念）
原子性：
对外部世界来说，事务的发生是不可分割的，要么全执行，要么全不执行。
一致性：
事务的处理不会破坏系统的恒定。
独立性：
并发的事务之间不会互相干扰。
持久性：
一旦一个事务处理提交，它的结果将永久保存。
（9）集中式数据库和分布式数据库各有什么优缺点？
中式数据库系统中的数据存放在一个地方，便于存取、查询。
而分布式数据库的数据存在于多个地方，其可以实现数据的高度共享，提高数据系统的可靠性、可用性。
但是同时也给存取、查询带来很多困难。
需要更多的开发代价，程序错误存在更大的可能性，以及增大的处理开销。
2．在数据库应用系统中，从传统的C/S结构发展为MIDAS结构时，试回答下面问题：
（1）解释什么是多层分布式体系结构？
一般采用传统的C/S结构，在C/S结构中，通常由客户端机器执行应用程序，然后连接到后端数据库服务器中存取应用系统需要的数据。
（2）C/S结构和MIDAS结构的主要区别是什么？
C/S：
客户机/服务器结构
数据存放于专门的数据服务器，数据服务器置于局域网，数据对局域网中的用户共享，数据的处理分担在客户机与服务器上，可以有效地利用局域网的网络资源。
特点是数据共享性高、投资成本较小（可以利用现有的局域网加以改造）、速度快、数据安全性高。
MIDAS（Multi-tierDistributedApplicationServices）：
多层分布式应用服务
多层数据库技术作为数据库应用中的一个新兴技术，是在单层数据库（本地数据库）技术、两层数据库（客户机/服务器机构）技术的基础上发展起来的。
使用多层数据库结构的应用程序，可以通过局域网甚至Internet和其他用户共享数据和网络信息。
多层数据库技术的优点可以概括为两点：
一是集中化的商业逻辑；另一个是客户程序的运行环境可以十分广泛。
多层结构应用体系应运而生，即在传统的二层C/S模型中放入应用程序服务器。
应用程序服务器简单地说就是一个包含企业逻辑的应用程序，开发人员以一种特定的组件形态，如MicrosoftCOM/DCOM,CORBA对象，或EnterpriseJAVABean等，封装企业逻辑的程序代码，这种经过封装，能够执行特定企业功能的对象被称为“企业对象”，把这些企业对象分发到应用程序服务器中，开发人员在开发应用程序时就可以使用这些企业对象提供的服务。
多层结构的典型是三层结构，其基本思想是把用户界面与企业逻辑分离。
整体结构如图二所示。
客户端应用程序服务器远程数据库服务器
（提供用户界面）（包含企业逻辑）（Oracle,MSQL,Sybase等DBMS）
3.设关系模式fdctds_schema（Department_name,Customer_name,Tax），其关系fdctds如表所示：
Department_name
Customer_name
Tax
青山
A1
15.08
江岸
A2
24.00
青山
A3
17.56
青山
A4
25.00
江岸
A5
46.00
如果对数据水平分片，产生二个片断：
fdctds1=σDepartment_name=”青山”（fdctds）
fdctds2=σDepartment_name=”江岸”（fdctds）
试写出对“青山”和“江岸”的查询转换表达式并说明其意义。
解：
6department-name=”青山”（fdctds）
fdctds定义为fdctds=fdctds1Ufdctds2
因为”青山”只涉及fdctds1
所以可以优化得:
6department-name=’青山”（fdctds1）U￠
所谓查询转换，是指提出一个查询后，根据分布式数据库被复制、分片或复制分片的具体情况重构关系并优化查询。
现假定关系account被水平分片如下：
现用户要查询δbranch—name=“Hillside”（account）
因为account被定义为account1∪account2
由名字翻译模式产生的表达式为：
δbranch—name=“Hillside”（account1∪account2）
查询优化：
δbranch—name=“Hillside”（account1）∪δbranch—name=“Hillside”（account2）
只涉及1只涉及2
∴只在上H节点求值∴只在V节点求值。
考虑到
由定义得出
这是一个空集，因在“H”节点上，没有“V”
∴优化结果为只查询
δbranch—name=“Hillside”（account1）∪φ
这就是查询转换的结果
4．有关系r和s，计算r∞s
A
B
C
1
2
3
5
6
4
3
5
6
1
3
2
7
8
9
2
6
7
C
D
E
3
4
5
3
6
8
2
3
2
1
4
2
1
2
3
解得：
A
B
C
D
E
1
2
3
4
5
1
2
3
6
8
5
6
4
3
5
6
1
3
2
3
2
7
8
9
2
6
7
1
4
2
1
2
3
5.有关系r和s，计算r∞s
C
D
E
1
2
1
5
6
2
3
5
6
1
3
2
7
8
9
2
6
7
E
F
G
3
4
5
3
6
8
2
3
2
1
4
2
1
2
3
解得：
C
D
E
F
G
1
2
1
4
2
1
2
1
2
3
5
6
2
3
2
1
3
2
3
2
6.一个具有继承性的银行系统例子如图所示：
Person
Employeecustomer
Officertellersecretary
其中：
officer_schema=（name,address,officer-number,expense-account-number,start-date,salary）;
teller_schema=（name,address,hour-per-week,station-number,start-date,salary）;
secretary_schema=（name,address,hour-per-week,manager,start-date,salary）;
customer_schema=（name,address,credt-rating）;
要求：
（1）用C++伪码写出图示类的层次定义。
（2）如果teller和secretary可分为full-time-teller和part-time-secretary，用多重继承关系统来定义以上例子，并画出它的类的树形结构图。
（3）试用面向对象数据库的观点解释例子中的实体、关系、模式、属性。
实体是现实世界中可区别于其他对象的事件或物体如本例中的人、客户员工等。
一个对象对应于一个实体。
属性是实体集中每个成员具有的描述性性质如人具有属性名、地址。
变量对应属性
关系（关系实例）：
对应于程序设计语言中变量的值的概念，关系模式由属性序列对应的域组成。
作为关系实例的例子，customer关系的的模式为：
customer_schema=（name,address,credt-rating）;
7.一个系统的E-R图如图5-1所示，其中某个实体的E-R图如图5-2所示。
注：
下图只列出了卖方表的E—R图，其它表的E—R类似。
图5-2
要求：
将它设计成为一个多层分布式结构的房地产交易应用系统，请按你自已的理解为其写一个总体设计方案（主要包括：
数据库设计；应用系统结构设计，主要企业对象和程序模块设计等）。
总体设计方案：
✧面向Internet/Intranet用户的功能模块：
✓登陆、注销、注册；
✓输入所要卖房子的信息（包括证件、介绍信息）及个人意见；
✓输入对查询后所相中的房子的要求；
✓修改自已已经在信息查询系统中提交的信息；
✓查看法院查封房屋；
✓与部门联系。
✧面向政府部门内部处理的功能模块：
✓业务员自已录入信息；
✓网上交易处理；
✓法院查封房屋录入；
✓自动显示屏设置；
✓安全设置；
✓卖、买方信息打印；
✓数据维护；
✓留言信息查看与录入。
基于MIDAS结构的多媒体房地产交易系统的功能模块：
✧登陆、注销、重新登陆；
✧数据录入与修改；
✧法院查封查看；
✧数据查询与处理；
✧统计打印；
✧系统设置；
✧系统维护；
✧数据备份与恢复；
✧网络通信；
✧帮助、退出；
根据房地产局的要求以及我们对此系统的研究分析，我们将设计分为以下几部分：
@对于交易系统能够提供一个统一的录入功能，对于信息发布系统提供客户与业务员不一致的录入功能，信息发布系统的数据要确保在交易系统中能得到转移，做到操作的一体化，不要重复的录入工作；
@提供一个安全的操作环境，对于授予了不同权限的人只能做已经授权了的事情，各个层次的人提供不同的操作界面，由系统根据登陆情况自动完成；
@提供一个对数据的查询的功能，以此满足任意条件下的查询，并能将查询得到的数据进行如打印、修改、删除、保存到另一存储介质以便以后恢复用等功能；
@提供对数据的完整性、一致性的检验，提供对数据的备份、恢复的功能；
@提供一个统一打印接口，能够进行选择打印；
@能够对多媒体信息进行验证，以确定其真正的存储格式，能够对多媒体信息进行任意的浏览，查看与存储；
@提供对历史数据的重新复查、检验，并能复查与原始数据的一致性。
@对于信息发布系统提供一个自动显示屏的发布功能，以满足房地产交易大厅的信息发布。
总体设计的原则
@可行性和适应性
系统要保证技术上的可行性和经济上的可能性，并要有对于今后经济体制改革的适应性。
@实用性和经济性
系统建设应始终贯彻面向应用，注重实效的方针，坚持实用、经济的原则，尽可能地做到边建设、边应用、边收效、边发展。
@先进性和成熟性
系统设计既要采用先进的概念、技术和方法，又要注意结构、设备、工具的相对成熟。
不但能反映当今的先进水平，而且具有发展潜力，能保证在未来若干年内占主导地位，并能顺利地过渡到下一代技术。
@开放性和标准性
为了满足系统所选用的技术和设备的协同运行能力、系统投资的长期效应以及系统功能不断扩展的需求，必须追求系统的开放性。
所谓“开放性”，即是所采用的标准和规范是厂商中立或者说是与厂商无关的。
具体地说，就是在遵循统一的国际标准或工业标准的前提下，允许用不同厂商的产品来相互替换，这种替换包括整个系统及其组成部件。
@可靠性和稳定性
在考虑技术先进性和开放性的同时，还应从系统结构、技术措施、设备性能、系统管理、厂商技术支持及维修能力等方面着手，确保系统运行的可靠性和稳定性，达到最大的平均无故障时间。
@安全性和保密性
在系统设计中，既考虑信息资源的充分共享，更要注意信息的保护和隔离，因此，系统应分别针对不同的应用和不同的网络通讯环境，采取不同的措施，包括系统安全机制、数据存取的权限控制等。
@可扩展性和易维护性
为了适应系统变化的要求，必须充分考虑以最简便的方法、最低的投资，实现系统的扩展和维护。
系统总体框架
系统在硬件这方面要求：
+IIS服务器：
完成Internet/Intranet用户对发布信息的请求；
+DNS服务器：
完成域名解析。
+应用程序服务器：
为客户端系统请求提供服务，运行与处理企业法则，并将返回结果返回给客户端。
+客户端：
信息发布系统要求具备IE5.0以上版本；交易系统能够安装交易系统客户端程序，为业务员操作提供友好的用户界面。
Oracle服务器：
对所有的数据进行管理，为应用程序服务器提供服务。
实现与应程序服务器的通信。
数据库设计：
包括数据库的结构设计、表结构设计、软件选择。
数据库的总体结构
应用系统应选用符合SQL标准的、支持分布式处理且能方便有效地与其他数据库系统之间互相存取信息的关系型数据库系统，作为系统中数据库主体，并支持多层体系结构以及Intranet结构。
对于数据库的选型，其原则是：
B支持大数据量存储
B支持多媒体数据存储
B支持事务处理
B支持存储过程、远过程调用（RPC）、触发器（Trigger）、规则（Rule）等保证数据一致性与完整性的功能
B支持实时备份
B高可靠性、高安全性，提供完整灵活的管理机制
B提供高效的数据库应用开发工具
B提供数据库系统性能监控和管理工具
B跨平台
结合上述原则以及房产地产局在今后的发展状况，我们选用当前流行的Oracle数据库，其版本为Oracle8.i。
针对我们的系统要求，我们建立二个数据库，一个为WFDC，另一个为FDC；其中WFDC为房地产信息发布系统的数据库，FDC为房地产交易系统的数据库。
在表空间方面我们创建六个表空间，分别为系统表空间、回滚表空间、临时表空间、用户表空间、数据表空间、索引表空间。
具体命名设置如下表：
房地产信息发布系统
房地产交易系统
表空间名
文件名
表空间名
文件名
Indx
Indx1Wfdc.Ora
Indx
Indx1Fdc.Ora
Rbs
Rbs1Wfdc.Ora
Rbs
Rbs1Fdc.Ora
System
Sys1Wfdc.Ora
System
Sys1Fdc.Ora
Temporary
Tmp1Wfdc.Ora
Temporary
Tmp1Fdc.Ora
Usr
Usr1Wfdc.Ora
Usr
Usr1Fdc.Ora
上述各表空间的存储参数设置如下：
表空间名
Initialsize
NextSize
Pctincrease
Minimum
MinExtents
Limted
Indx
128
10
10
0
1
30
Rbs
256
50
10
0
1
30
System
128
10
10
0
1
30
Temporary
256
50
10
0
1
30
Usr
256
50
10
0
1
50
为了方便程序以后的跨数据库平台的移置，我们没有设置数据库存储过程、触发器，而是编写程序解决这些问题，由于与数据库本身的联系很少，因此我们在以后更换其它数据库平台时很方便。
在机器硬件方面，我们让一台机器安装Oracle服务器版，并在上面安装上面的二个数据库，在编写程序时，所有的客户端安装Oracle的客户机版，用于与服务器上Oracle的连接。
在这里我们将概念模型转化为关系模型：
卖方信息（交易编号、姓名或单位名称、单位性质、住址、代理人、工作单位、联系电话、身份证、备注、传真、电子邮件、其它联系方式）
买方信息（交易编号、姓名或单位名称、单位性质、住址、代理人、工作单位、联系电话、身份证、备注、传真、电子邮件、其它联系方式）
房屋信息（交易编号、房屋座落、结构等级、层次、建成年代、产别、房屋用途、产权来源、东、南、西、北、户型、土地转让面积、占有面积、房屋建筑面积、用地面积、土地等级、配偶意见、承租户意见、共有人意见、住户安排、备注、平米价格）
交易过程（交易编号、房成交价、评估产价、重置产价、土地成交价、评估地价、土地原价、出让建筑面积、交易性质、交易类型、契纸字号、立契时间、罚款、工本费、其它、现场评估意见、业务员姓名、法定交易编号）
税费计算（交易编号、交换差价、契税折扣、契税、审核费折扣、审核费、营业税折扣、营业税、营业附加税折扣、营业附加税、勘估费折扣、勘估费、印花税折扣、印花税、土地收益金折扣、土地收益金标准、土地收益金总额、房屋交易规费合计、评估房地价合计、税费总计）
证件信息（产权证明证件、路径、说明、备注、证件名称、证件类型）
介绍信息（信息介绍索引、路径、类型、说明、备注）
应用系统结构设计：
包括整个系统提供的功能模块、模块间构架。
主要企业对象：
用E-R图、对象的概念表述主要的对象、实体、属性、方法。
程序模块设计：
根据系统要实现的功能分工程序模块。
8．一个分布式数据库系统，如果要保证原子性，执行事务T的所有节点都必须在T执行的最终结果上取得一致，T要么在所有节点上都提交，要么在所有节点上都中止。
为了保证这一特性，可采用一个2PC提交协议。
试详细说明2PC提交协议的处理过程以及故障处理过程。
解：
2PC提交协议：
设事务T在Si发起，Si的协调器为Ci
①提交协议：
当T完成时（即没有T时），启动2PC协议。
阶段1：
·Ci将记录写入日志→并将消息prepareT发给执行T所有节点。
·节点上TM确定是否提交,回答N,TM将记录写入日志,向Ci发消息abortT
Y,TM将记录写入日志,向Ci发消息readyT
阶段2：
·Ci收到所有节点<消息>写入日志→提交将消息commitT发给执行T所有节点;
决定是否提交将commitT写入日志
→不提交将消息abortT发给执行T所有节点;
将abortT写入日志
·所有节点上TM正式提交,完成后向Ci发消息,Ci收到消息将写入日志.
②故障处理：
*考虑节点故障
节点发生故障，系统等待节点故障恢复，恢复后必须检查自己的日志，可能有四种情况：
·日志中包含，∴该节点执行redo（T）重提交
·日志中包含，∴该节点执行undo（T）回滚
Ci是，该节点redo（T）
·日志中包含，则要询问来确定{
Ci是，该节点undo（T）
·日志中包含，没有T的控制记录（以上三种都不得没有），即节点在回答Ci的prepareT消息之前就坏了，执行undo（T）
*考虑协调器故障：
协调器故障，只有由参与节点来决定T的命运，四种情况：
·某个活跃节点日志中有记录，redo（T）。
·某个活跃节点日志中有记录，undo（T）。
·某个活跃节点日志中有记录，则协调器故障时还没有提交，undo（T）。
·以上都不是，只有等协调器恢复后再决定，——这就发生阻塞现象。
升级会员 