Student1(sno,class,sname) Student2(sname,sex,birth,major,dno,cno,grade) 按C1、C2准则转换将一元操作下移。
Пsname
,grade
|
? sname?sname
Student1(sno,class,sname) δdno?\1\
|
Student2(sname,sex,birth,major,dno,cno,grade)
1.4. 设数据项x,y存放在S1场地，u,v存放在S2场地，有分布式事务T1和T2,T1
在S1场地的操作为R1(x)W1(x)R1(y)W1(y),T2在S1场地的操作为R2(x)R2(y)W2(y);T1在S2场地上的操作作为R1(u)R1(v)W1(u),T2在S2场地上的操作作为W2(u)R2(v)W2(v)。对下述2种情况，各举出一种可能的局部历程（H1和H2），并说明理由。
串行调度 数据项x,y 数据项u,v Time Site S1 Site S2 | T1 T2 T1 T2 | R1(x) R1(u) | W1(x) R1(v) | R1(y) W1(u) | W1(y) | R2(x) W2(u) | R2(y) R2(v) ↓ W2(y) W2(v) T1 < T2
1.4.1.局部分别是可串行化，而全局是不可串行化的
数据项x,y 数据项u,v
Time Site S1 Site S2
| T1 T2 T1 T2 | R1(x) W2(u) | W1(x) R1(u) R2(v) | R1(y) R2(x) W2(v) | W1(y) R1(v) | R2(y) W1(u) | W2(y) ↓
T1S1 < T2S1 T2S2 < T1S2 T1、T2的所有子事务在每个站点都是可串行执行的。但
根据2PL协议事务T1在没有获得对v的锁之前是不会释放y的锁，而T2在没有获得y的锁之前是不会释放v的锁，T1和T2发生了死锁，故T1和T2之间在全局上是不可串行化的。
1.4.2.局部和全局都是可串行化的。要求按照严格的2PL协议，加上适当的加锁和解
锁命令，（注意，用rl(x)表示加读锁，wl(x)表示加对x加写锁，ul(x)表示解锁）
全局事务在全局范围内是可串行化的，必须是全局事务的所有子事务在每个局部站点上
的可串行性在调度表中出现的顺序必须相同。即TiA 数据项x,y 数据项u,v Time Site S1 Site S2 | T1 T2 T1 T2 | rl1(x) rl1(u) | R1(x) RL2(x) R1(u) wl2(u) | wl1(x) wait rl1(v) wait | rl1(y) . R1(v) . | R1(y) . wl1(u) . | W1(y) w1(u) . | U1(x) . u1(u) | U1(y) . u1(v) | rl2(x) wl2(u) | R2(x) w2(u) | rl2(y) rl2(v) | R2(y) r2(v) | wl2(y) wl2(v) | W2(y) w2(v) | U2(x) u2(u) | U2(y) u2(v) ↓ 1.5. 试述面向对象的数据库系统中页面服务器和对象服务器两种Client/Server体系结构的主要特点, 基于页面服务的体系结构可分为两种： 一种是基于 page to object 的服务体系结构，这种体系结构的特点是数据传输单位是页面，在客户方缓冲页面和对象，其优点是服务器的性能大大的提高了，而且在客户和服务器之间数据传输较少，其缺点方法不能在服务器上运行；另一种体系结构是基于page to page 服务器体系结构，这种体系结构与前面的体系结构非常相似，差别是客户 方仅缓冲页面但不缓冲对象。 基于对象服务器(OS object server)的OODBMS体系结构的特点是客户器与服务器间的数据传输单位是对象，其优点是方法在对象服务器上运行且客户方和服务器方均可进行查询处理，但这种体系结构的缺点是数据传输量可能比较大，而服务器仍然是一个系统性能的瓶颈。 2. 九九年春季试题 2.1.DBMS解决了信息处理技术中的哪些挑战？ 关系数据库的基本理论已经成熟，但各大公司在关系数据库管理系统(RDBMS)的实现和产品开发中，都遇到了一系列技术问题，主要是在数据库的规模愈来愈大，数据库的结构愈来愈复杂，又有愈来愈多的用户共享数据库的情况下，如何保障数据的完整性(Integrity)、安全性(Security)、并行性(Concurrency)，以及一旦出现故障后，数据库如何实现从故障中恢复(Recovery)。这些问题如果不能圆满解决，无论哪个公司的数据库产品都无法进入实用，最终不能被用户所接受。正是在解决这些重大的技术问题，促使了DBMS发展和成熟。 目前，DBMS解决上述问题的主要技术手段和方法如下：把对数据库的操作划分为称作\事务\的原子单位，对1个事务内的操作，实行\or not\的方针，即\要么全做，要么全不做\。用户在对数据库发出操作请求时，系统对有关的不同程度的数据元素(字段、记录或文件)\加锁\；操作完成后再\解锁\。对数据库的任何更新分两阶段提交(2PL)。建立系统运行日志(log)，以便在出错时与数据库的备份(backup)一起将数据库恢复到出错前的正常状态。 上述及其他各种方法可总称为\事务处理技术\technique)。事务处理技术虽然诞生于数据库研究，但对于分布式系统，client/server结构中的数据管理与通信，对于容错和高可靠性系统，同样具有重要的意义。 2.2.在关系数据库应用设计中，为什么要对数据库模式进行规范化？ 关系数据库的设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。关系模型是数学化的、用二维表格数据描述各实体之间的联系的这么一种模型；它是所有的关系模式、属性名和关键字的汇集，是关系模式描述的对象。简单的说关系模式是指一个关系的属性名表，即“二维表”的“表框架”。关系模式的设计是关系模型设计的灵魂。所以，关系模式的设计是关系数据库设计核心的核心。 关系模式的设计直接决定着关系数据库的性能。目前，在指导关系模式的设计中规范化(normalization)设计占有主导地位，它是在数据库几十年的长期发展中产生并成熟的。但近年来这一领域出现了一种新的趋势，一种称为“非规范化”(denormalization)的关系模式设计引起业界的关注并已在一定的范围内得到应用。对这一新的设计思想，各方反应迥然不同褒贬不一，从而在相关的理论界掀起了一场不大不小的规范化与非规范化之争。本文简单介绍了规范化与非规范化设计的基本思想，综述了正反双方争论的要点，供参考。 一、 规范化设计 关系模式规范化设计的基本思想是通过对关系模式进行分解，用一组等价的关系子模式来代替原有的关系模式，消除数据依赖(包括函数依赖和多值依赖)中不合理的部分，使得一个关系仅描述一个实体或者实体间的一种联系。这一过程必须在保证无损连接性、保持函数依赖性的前提下进行，即确保不破坏原有数据的前提下，并可将分解后的 关系通过自然联接恢复到原有的关系。 具体地说，规范化设计的过程就是按不同的范式，将一个二维表不断地分解成多个二维表并建立表之间的关联，最终达到一个表唯一描述一个实体或者实体间的一种联系的目标。目前遵循的主要范式包括1NF、2NF、3NF、BCNF、4NF和5NF等几种；在工程中3NF、BCNF应用得最广泛，推荐采用3NF作为标准。 规范化设计的优点包括可有效地消除数据冗余，理顺数据的从属关系，保持数据库的完整性，增强数据库的稳定性、伸缩性、适应性。通常认为规范化设计存在的主要问题是增加了查询时的连接“库表”的运算，导致计算机时间、空间、系统及运行效率的损失。在大多数情况下，这一问题可通过良好的索引设计等方法得到解决。 二、 非规范化设计 非规范化设计的基本思想是，现实世界并不总是依从于某一完美的数学化的关系模式。强制性地对事物进行规范化设计，形式上显得简单化，内容上趋于复杂化，更重要的是导致数据库运行效率的减低。非规范化要求适当地降低甚至抛弃关系模式的范式，不再要求一个表唯一描述一个实体或者实体间的一种联系。其主要目的在于提高数据库的运行效率。 非规范化处理的主要技术包括增加冗余或派生列，对表进行合并、分割或增加重复表。一般认为，在下列情况下可以考虑进行非规范化处理：(1)大量频繁的查询过程所涉及的表,都需要进行连接的时候；(2) 主要的应用程序在执行时要将表连接起来进行查询的情况下；(3)对数据的计算需要临时表或进行复杂的查询时。 非规范化设计的主要优点是减少了查询操作所需的连接；减少了外部键和索引的数量；可以预先进行统计计算，提高了查询时的响应速度。非规范化存在的主要问题是增加了数据冗余；影响数据库的完整性；降低了数据更新的速度；增加了存储表所占用的物理空间。其中最重要的是数据库的完整性问题。这一问题一般可通过建立触发器、应用事务逻辑、在适当的时间间隔运行批命令或存储过程等方法得到解决。 三、 规范化与非规范化争论的要点 支持非规范化设计的一方认为，数据库规范化的程度越高，其中表的数量越多，规范化的程度与表的数量直接相关；表的数量越多，表的连接运算也越多；连接运算增多，必然降低数据库执行的速度，影响数据库的性能。只有通过非规范化设计，显著减少表的数量，从而减少对连接运算的依赖，加速数据库执行的速度，才能保证数据库性能的正常发挥。例如目前流行于决策支持系统的非规范化星型模式就远胜于应用规范化设计，是非规范化设计的最好范例。非规范化设计并不意味着混乱和无视规则，它也遵循保护信息完整性等软件工程的基本原则。 支持规范化设计的一方认为，规范化与非规范化只是一个逻辑概念，强调非规范化设计者混淆了逻辑与物理的关系。数据库的性能是由物理水平决定的，即硬件、数据库的大小和物理设计、数据存储和访问的方法、数据库管理系统的优化程度、并发访问的数量等；非规范化设计并未改变数据库的物理水平，因此不可能提高数据库的性能。规范化并不只是为了避免数据冗余，更重要的是为了确保数据库的完整性。非规范化设计的最大问题是难以保证数据库中数据的一致性，存在着破坏数据的危险。此外，非规范化使一个表中存在多个实体，不同实体混合在一起强化了数据库的复杂性，提高了用户理解的难度，并导致描述问题上的困难，增加了正确响应的风险。只有规范化设计才是解决这些问题的根本途径。如果不摒弃非规范化设计理念，为了获得所谓的性能的提高而漠视数据库完整性被破坏的风险，就无法激励 “开发商”去研究真正的完全规范化而高性能的关系数据库管理系统，其后果必然影响数据库的健康发展。 从某种意义上说，数据库的规范化与非规范化设计并不是对立的、非此即彼的关系。也许其中一方会逐渐消亡，也许二者存在一条中间道路可走。认识事物原本存在一个螺 旋式上升的过程。这场争论尚未结束，也无法对最终的结果进行预测。但可以肯定的是，无论结果如何，都将对未来数据库的发展方向产生深远的影响。 2.3.简述ACID特性。 事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这个四个特性也简称为ACID特性。 原子性（Atomicity）:事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做 一致性（Consistency）: 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此，当数据库只包含事务成功提交的结果时，就说数据库处于一致性状态之中。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断了，系统就将此事务中对数据库的所有已经完成的操作全部撤消，滚回到事务开始时的一致状态。 隔离性（Isolation）: 一个事务的执行不能被其他事务干扰，即一个事务的内部操作及其使用的数据对于其他并发事务来说是隔离的。并发执行的各个事务之间不能互相干扰。 持续性（Durability）: 持续性也称永久性（Permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。 事务是恢复和并发控制的基本单位。保证事务ACID特性是事务处理的重要任务。事务ACID特性可能遭到破坏的因素有： 1. 多个事务并行运行时，不同事务的操作交叉执行。 2. 事务在运行过程中被强行停止。 在第一种情况下，数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性。在第二种情况下，数据库管理系统必须保证被强行终止的事务对数据库和其它事务没有任何影响。 这些就是数据库管理系统中恢复机制和并发控制机制的责任。 2.4. 长事务处理有哪些特性，如何解决？ 通常DBMS中采用\锁定-修改-释放\的策略以实现其对多用户并发操作数据库的控制。但这种策略不很适合用于处理地理数据的DBMS。对地理数据的编辑工作，可以几分钟做完，也可能要拖上几个月。这种情形即是所谓\长事务处理\。ArcSDE 8对长事务处理提供了底层的支持。当ArcSDE服务器的一个实例（instance）第一次启动时，就建立了数据库缺省的状态和版本。用户可在此基础上建立公共的或私有的数据版本。用户各自在自己的数据版本上工作，因而无须对多个用户同时访问的数据对象进行锁定。 每个用户都是在直接对数据库进行操作（编辑、修改），但是ArcSDE为其建立了记录所有修改\痕迹\的增量记录，即版本。用户在这个数据版本进行编辑修改时，并不用关心其他用户是不是也在对同一数据进行操作。只有当用户完成了他的（长）事务处理工作时，系统才将其当时的数据版本\合并\到原来的数据版本中去，\冲突\也是在此时再加以处理。系统为用户提供了解决冲突的三种选择：维持原状、否决自己的修改或否决别人的修改。 长事务(long transaction) 的应急之策 事务(transaction)是一个不可分的工作单位, 一个事务中包含的操作要么全部执行,要么全部不执行. 如果数据库中只包含成功事务提交的结果, 则数据库的状态称为\一致状态\为了保证数据库\一致状态\采取如下机制: