XML和数据库

最新推荐文章于 2023-03-17 00:43:52 发布

as good as well

最新推荐文章于 2023-03-17 00:43:52 发布

阅读量1.1k

点赞数

分类专栏： server&amp

本文链接：https://blog.csdn.net/liangshoulong/article/details/76695730

版权

server&amp 专栏收录该内容

72 篇文章 0 订阅

订阅专栏

XML和数据库

摘要

近年来，随着软硬件的发展，为新一代数据库技术的发展奠定了物质基础，同时也为数据库技术提出了许多新的要求。同时，W 3C 制定的XML规范也为数据库技术提供了有力的支持。当前，业界最关心的几个话题就是：分布数据库的管理和通信；大型数据库的知识发现和数据挖掘；掌上设备的轻量数据库管理系统。这这些，都和XML技术有着紧密的联系。

在本文中，介绍了关系型数据库理论、XML理论、XML和数据库、以及分布环境下数据同步技术的现状。

关键字

关系数据库 XML

一．引言

当前，数据库技术的应用无所不在。近年来，随着软、硬件的发展，为新一代数据库技术的发展奠定了物质技术基础。尤为引人注目的是：光盘、磁盘组、高性能微处理器芯片、光纤、高速传输网、大规模并行处理技术、人工智能、逻辑程序设计、面向对象的程序设计、发放系统和标准化以及多媒体技术的发展和推广。这些新技术与数据库的广泛应用相结合，形成了当代数据库几个有代表性的新方向：分布式数据库系统、面向对象的数据库管理系统、演绎数据库和知识库、数据仓库和数据挖掘。这些方向引起了学术界和技术领域人员的广泛兴趣，有巨大的实用价值。

W 3C 制定的XML规范给计算机各个领域带来了很大的冲击，数据库领域也不例外。当今，XML和数据库的联系紧密，在新版的ORACLE以及MicroSoft SQL Server 2000里都凸现出了XML技术的身影。并且，Software AG公司也推出了世界上第一个原生的XML Information Server——Tamino。Tamino号称是一个完全XML的数据库，比传统的数据库的查询速度快10倍。

随着网络化的发展，对于数据管理提出了新的要求，出现了许多新的技术，而这些新技术几乎都是与XML技术机密结合的。比如：

l 分布数据的处理，各大主要的DBMS提供商都充分考虑了这个要求并对此提供了支持，并且引入XML技术作为其中间件或者数据库产品。现今，有许多这样的产品。

l 对于大型数据库，知识发现和数据挖掘为决策支持提供了可能。基于XML的知识发现和数据挖掘也是当今的热点问题。

l 当今，个性化的要求非常大，PDA、掌上电脑、手机上的个性化服务需求巨大。在这种设备上的信息管理也是一个有着巨大生命力的方向，在这些掌上设备上的DBMS要求必须是轻量的，最好维持在 1M 以下，传统的DBMS不适应这种需求。

二． XML技术

三．数据库技术

四． XML和数据库

4.1 XML是数据库吗？

"XML是数据库吗?"在严格意义上将，如果"XML"是指XML文档时，答案是"否"。尽管XML文档包含了数据，但是如果没有其他的软件来处理这些数据，它对于数据库的意义和其他文本文件没有什么区别。

如果在更为宽泛一些的意义上将，当"XML是指XML文档以及所有相关的XML的工具和技术时，答案则是"是"。之所以肯定是由于XML提供了许多数据库中所需要的部分:存储(XML文档),结构(DTD, XML schema语言),查询语言(XQL, XML-QL, QUILT等), 编程接口(SAX, DOM),等等。不过...XML还缺少很多在真实的数据库中所必备的内容: 有效的存储、索引、安全、交易、数据完备性、多用户访问、触发、多文档查询等。

因此如果在数据量一般、用户较少、性能要求不高的环境下可以把XML当作数据库来使用；而在大多产品的环境中，要求有许多的用户使用、需要严格的数据完整性并且对性能有很高的要求，XML就不能胜任了。而且，考虑到象dBase和Access等数据库既便宜又十分易用，因此甚至在第一种情况下XML都很少有理由充当数据库的角色。

4.2 数据和文档的对比

在选择数据库时，最重要的判断因素可能是你是利用数据库来保存数据还是保存文档。如果你想保存数据，你需要的数据库主要是面向数据存储(例如关系型数据库或者面向对象型数据库)以及在数据库和XML文档之间相互转换。从另一个角度来将，如果你想存储文档，你需要一个专门设计用来存储文件的内容管理系统。

虽然你可以自己把文件保存在关系数据库或面向对象数据库中，可是你常会发现你的工作是在重复内容管理系统的功能。类似的，虽然一个内容管理系统通常是建立在面向对象数据库或关系数据库之上，但要是把一个内容管理系统当做数据库来使用就可能非常的令人困绕。

你需要存储数据还是文档，答案常常取决于你的XML文档。原因是XML文件分为两大类：以数据为中心和以文档为中心

4.2.1 以数据为中心的文件

以数据为中心的文件的特点是结构相当规范、数据颗粒度好(也就是说，数据中最小的独立单元是PCDATA元素或者是属性)、很少或者没有混合内容。其中同层次元素和PCDATA的出现顺序并不重要。典型的例子是，XML文档包含了销售定单、飞行安排、餐馆菜单等等。数据为中心的文档常被用于机器的使用，这时XML可能是多余的---它仅仅是数据传输的手段而已。

例如，下面的销售定单的文档就是以数据为中心的：

            ABC Industries

            
   
   
    
    
     
     123 Main St
    
    
   
   .

IL

Turkey wrench:

Stainless steel, one-piece construction,

lifetime guarantee.

               9.95

Stuffing separator:

Aluminum, one-year guarantee.

               13.27

在XML的世界中，许多内容丰富的文档实际上都是数据为中心的。我们以显示图书信息的Amazon.com网站为例。虽然这个页面是相当巨大的文本，但是这个文本的结构是高度规范的，其中许多的部分对任何的书本描述页面都是相同的，并且特点页面中的各部分的大小都是有限的。也就是说，该页面可以通过一个简单的、数据为中心的XML文档来建立，其中包含了从数据库中检索得到的文本信息以及一个XSL样式表。通常，目前任何通过在模板中填充数据库数据而动态构造HTML页面的网站都可以被上面介绍的用以数据为中心的XML文档和一个或者多个的XSL样式表方式替代。

例如，我们来看下面的租房(Lease)文档:

      ABC Industries agrees to lease the property at

123 Main St. , Chicago , IL

 from XYZ

      Properties for a term of not less than 18 at a cost of 1000.

可以从下面的XML文档和简单的样式表得到:

      ABC Industries

123 Main St. , Chicago , IL

      XYZ Properties

4.2.2 以文档为中心的文件

以文档为中心的文档的特点是:结构不规范、数据颗粒度更大(即，最小的独立数据单元是包含有混合内容的元素或者就是整个XML文档)以及含有大量的混合内容。其中相同层次的元素和PCDATA出现顺序是非常重要的。典型的例子是书、电子邮件、广告以及大多数XHTML文档。以文档为中心的文档是用于人的使用。

例如，下面的产品描述文档就是以文档为中心：

   Full Fabrication Labs, Inc.

   Like a monkey wrench, but not as big.

   The turkey wrench, which comes in both right- and

   left-handed versions (skyhook optional), is made of the finest

   stainless steel. The Readi-grip rubberized handle quickly adapts

   to your hands, even in the greasiest situations. Adjustment is

   possible through a variety of custom dials.

   You can:

   Order your own turkey wrench

   Read more about wrenches

   Download the catalog

   The turkey wrench costs just $19.99 and, if you

   order now, comes with a hand-crafted shrimp hammer as a

bonus gift.

4.2.3 数据、文档和数据库

在现实情况中，以数据为中心的文件和文档为中心的文件之间的区别并不是很严格。例如，一个以数据为中心的文件(如一张发票)，也有可能包含粗颗粒度、不规则的数据(如发票的描述部分)。而一个以文档为中心文件(如用户手册)也可能包含有良好颗粒度、规则的结构化数据(通常是元数据),例如作者和修订日期。除此之外，让你的文档具有以数据为中心或者以文档为中心的特点有助于你判断是关心数据还是文档，这也将决定你需要采用什么样的系统。

要存储或检索数据，你可以使用一个数据库(通常是关系型、面向对象型或者是层次型)和中间件(字带或者是采用第三方)，你也可以使用XML服务器(即创建分布式应用的平台，例如利用XML进行数据传输的电子商务应用)。要保存文档，你将需要一个内容管理系统或者是一致性的DOM实现系统。

4.3存储和检索数据

在以数据为中心的文档中的数据内容可能来自数据库(此时你想把数据导出为XML格式)，也可能是XML文档(此时你想把数据存储在数据库中)。前者的例子是在关系型数据库中存储的大量现有数据(或称遗产数据);后者的例子是将数据作为XML发布在Web中，而且你想要在你的数据库中进行存储以进行更多的处理。如此，根据你的需求，你可能需要将XML文档转移到数据库的软件，也可能需要从数据库转移到XML文档的软件，或者两者都支持。

4.3.1 转移数据

将数据存储在数据库中时，经常需要丢弃大量与文档有关的信息，例如文档名称和DTD，同时还有其物理结构，例如实体的定义和使用、属性值和同层元素的顺序、二进制数据的存储方式(是Base64编码、是未析实体或他方式)、字符数据段和其他的编码信息。类似的，当从数据库中检索数据时，生成的XML文档结果除了非预定义实体lt(<"),gt(">"), amp("&"), apos("'"), quot(""")不包含任何CDATA或实体引用。而同层元素和属性的出现顺序也常常就是从数据库中返回的数据的次序。

尽管一开始有些让你吃惊，但是这常常是合理的。例如，假设你需要用XML作为数据格式把一张销售从一个数据库中转移到另一个数据库中。在这种情况下，在XML文档中并不关心销售单的编号是保存在销售单的日期的前面还是后面，也不用关心是否将顾客的名称保存在字符数据(CDATA)段还是作为一个外部实体，或者直接当成一个PCDATA。最重要的在于相关的数据是从第一个数据库转移到第二个数据库中。这样，这个数据传输软件就需要考虑数据的层次结构(该结构将销售单的有关进行进行了分组)，而其他则不必过多考虑。

忽略文档信息以及其物理结构的后果之一是文档的"逆反回归"的不一致效应，即将一个文档的数据存储在数据库中，然后根据这些数据重新组织成新的文档。而即便是根据标准格式处理，得到的也常常是和前面不同的文档。这是否可以接受要取决于你的需求，而且也将影响到你对数据库和数据传输中间件的选择。

4.3.2 从文档结构到数据库结构的映射

为了在XML和数据库之间传输数据，需要在文档结构和数据库结构之间进行相互的映射。这样的映射通常分为两大类: 模板驱动和模式驱动。

1. 模板驱动的映射

在以模板驱动的映射中,没有预先定义文档结构和数据库结构之间的映射关系，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。例如，考虑下面的模板(注意该模板并不适用任何实际的产品)，在<SelectStmt>元素中内嵌了SELECT语句：

<?xml version="1.0"?>

<Intro>The following flights have available seats:</Intro>

<SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>

<Conclude>We hope one of these meets your needs</Conclude>

</FlightInfo>

当数据传输中间件处理到该文档时,每个SELECT语句都将被各自的执行结果所替换，得到下面的XML格式:

<?xml version="1.0"?>

<Intro>The following flights have available seats:</Intro>

<Row>

</Row>

...

</Flights>

<Conclude>We hope one of these meets your needs</Conclude>

</FlightInfo>

这种以模板驱动的映射可以相当的灵活。例如,有些产品可以允许你在任何结果集合中替换你想要的内容(包括在SELECT中使用参数),而不是象上面的例子中简单地格式化结果。另外它还支持使用编程来进行构造，例如循环和条件判断结构。还有一些还支持SELECT语句的参数化，例如通过HTTP来传递参数。

目前，以模板驱动的映射只支持从一个关系型数据库转换成XML文档的情况。

2. 模型驱动的映射

在以模型驱动的映射中,利用XML文档结构对应的数据模型显式或隐式地将映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多地转换工作。由于将数据从数据库转换成XML的结果依照了单个模型, 因此通常在这种方式下通常结合XSL来提供模板驱动的系统中所具有的灵活性。

在XML文档中的数据视图通常有两种模型:表格模型和特定数据对象模型。有时候也可能会出现其他的模型。例如，通过采用ID和IDREF属性，一个XML文档可以用来一个指定的图形。不过，很多现有的中间件并不支持这些模型。

l 表格模型

许多中间件软件包都采用表格模型在XML和关系型数据库之间进行转换。它把XML的模型看成是一个单独的表格或者是一系列的表格。也就是说，XML的文档的结构和下面的例子相类似，其中在单个表格的情况下，<database>并不出现:

<table>

<row>

...

</row>

...

</table>

...

</database>

其中的术语"table"可理解为单个的结果集(当从数据库向XML中转换数据时)，或者是一个单独的表格或可更新的视图(当从XML向数据库转换数据时)。如果数据需要来自多个结果集(当数据来自数据库中时)或者与仅仅表达成一系列表格的集合(当转换数据到数据库时)相比，XML的文档包含有更深层次的嵌套元素，那么类似的转换几乎是不可能的。

l 特定数据对象模型

XML文档中第二种普遍的数据模型是特定数据对象的树型结构。在该模型中,元素类型通常对应对象，而XML中的内容模型、属性和PCDATA则对应对象的属性。这种模型直接映射成面向对象的数据库和层次型数据库，当然借助于传统的对象-关系映射技术和SQL 3对象视图也可以映射成关系数据库。要注意的是，这种模型并不是文档对象模型(DOM)。DOM是对文档本身进行建模，而不是对文档中的数据。

例如，上面的销售定单文档就可以看作是由五个类所组成的树型结构。如下面的视图所示，包括Orders, SalesOrder, Customer, Line和Part类:

Orders

SalesOrder

/ | Customer Line Line

| |

Part Part

当把一个XML文档建模为一棵特定数据对象树时，就没有必要要求元素一定要对应于对象。例如，如果一个元素只包含PCDATA，如销售定单文档中的CustName元素，它可以当作一个属性进行处理，因此属性只包含单一的、标量型数值。类似的，有时将混合元素或元素内容模型化成属性也是非常有用的。一个现成的例子就是在销售定单文档中对Description元素的处理：尽管它在XHTML的格式中有混合内容，但是将Description元素看作单个的属性会更有用些，因为它的组成部分本身并没有什么意义。

4.2.3 数据类型、空值、字符集和其他

l 数据类型

XML不支持任何有实际意义的数据类型。除了未析实体，所有XML文档中的数据都被当成文本来对待，即便它能够用其他的数据类型(如日期或者整数)来表示。通常，数据转换中间件将把XML文档中的文本转换成其它数据库中的数据类型，反之亦然。然而，特定的数据类型所识别的文本格式是有限制的，例如受到提供的JDBC Driver所支持的数据类型的限制。在这些众多的数据类型中，日期类型通常会导致麻烦。不同国际地区的数字格式的差异也可能产生问题。

l 二进制数据

通常有两种方法将二进制数据保存到XML文档中的：未析实体和Base64编码处理(一种MIME编码方法，可以将二进制数据映射成US-ASCII的子集)。对于关系型数据库，这两种方法都可能存在问题，因为从数据库中保存和检索二进制数据的规则非常的严格，这样对会导致中间件出现问题。

另外，并没有一种标准的符号用来说明一个XML文档中的元素包含有Base64编码数据，从而使得中间件可能根本就不能够识别这种编码。最后，在存储数据到数据库时，可能会忽略与未析实体或Base64编码元素相关的符号。所以，如果对你而言二进制数据非常重要的话，请务必要确认你的中间件是否支持二进制数据。

l 空值

在数据库世界中，空值(null)数据意味着数据不存在值。但是这与一个值为0的数字或长度为0的字符串有很大的区别。例如，假设你的数据来自一个气象站，如果气象站的温度计出了毛病读不出温度值，那么你的数据库中将存储一个null值而不是一个0。显然，值为0完全是另外一回事了。

XML中空值概念的支持可以通过设置可选的元素类型或属性来实现。如果元素类型或属性值为null，XML只要在文档不包含该元素或者属性就可以了。但是对数据库而言，空的元素或包含0长度字符串的属性并不是空值null：它们的值为长度为0的字符串。

当在XML文档和数据库结构之间相互映射过程中，你必须特别注意那些可选的元素类型或属性是否对应于数据库中的空值项。如果不这么做的话，很可能出现插入错误(当将数据转换到数据库中时)或者无效文档错误(当将数据从数据库读出时)。

因为同样要用符号空值，XML中相对与数据库而言更为灵活。具体来讲，许多XML用户很可能包含空字符串的空元素或属性是空值。这个时候你必须考虑如何选择合适的中间件来解决这个问题。一些中间件可以让用户选择在XML文档中定义用什么来组成空值。

l 字符集

根据定义，除了一些控制字符，XML文档能够包含任何的Unicode字符。但是不幸的是，许多数据库都限制或则不支持Unicode，而且需要一些特殊的配置才能够处理非ASCII编码的字符数据。如果你的数据包含了非ASCII字符，那么务必要核实你的数据库和中间件是否能够处理这些字符。

l 处理指令

处理指令并不属于XML文档中的“数据”部分，因此目前许多中间件可能不能正常的处理。问题是，尤其是在将XML文档结构严格映射成数据库结构时，处理指令通常是很难处理的，因为它们可以虚拟地出现在文档的任何位置。因此，中间件就很难判断将它们保存到什么位置以及在什么时候检索读取出来。如果处理指令和文档的循环回复("round-tripping")对你而言是非常重要的话，就务必检查你的中间件是如解决这个问题的。

4.2.4 数据库的结构生成DTD及其互逆过程

在XML文档和数据库之间转换数据时，一个普遍问题是：如何从数据库的结构(Schema)生成XML的DTD,如果从XML的DTD产生数据库的结构。简而言之，这是非常直接的操作，但是产生的结果通常离许多用户的期望值还有一些距离。

(还要注意这通常是一次性操作，而大多数应用，尤其是所有的垂直性应用都结合了已知的DTD和关系型Schema的集合。显而易见的特例是在关系数据库中存储随机XML文档或者将关系型数据发布为XML文档的工具;而在后面的情况中，DTD的作用并不明显。)

对于元素类型中每个有单一数值的属性和只包含有PCDATA内容的子元素类型在该ta ble中新建立一列（字段）。如果子元素类型或则属性是可选的，让该字段允许为空。对于每个有多值的属性或则多仅含有PCDATA内容的子元素类型，再建立一个分开的 table来保存他们的值，通过它们的父表的主关键字连接到父表。对于每个子元素，这些子元素本身还有元素或则混合内容，使用父表中的关键字将父元素表连接到子元素表中。而下面则是一个从关系数据库的结构生成XML文档的过程（简化过的）：对每个table，新建一个元素。对表中的每列，建立一个属性或则只含PCDATA的子元素对每个包含有在主键/外键关键字关系中主键值的列，新建一个子元素。

例如，下面的过程(经简化）说明了如何从一个DTD生成一个关系型结构:

对于每种包含元素或者混合内容的元素类型，新建一个表格和一个主键字段。

对于每个包含混合内容的元素类型，创建一个单独的表格，其中存放未析数据，通过父元素主键链接到父表格。

对于此元素类型的每个单值属性和只包含未析数据内容、只出现一次的子元素，在该表格中创建一个字段。如果元素类型或者属性是可选的，可以让设置该字段为空值。

对于每个多值属性和多次出现的子元素，创建一个单独的表格来存储数值，并且通过父元素主键链接到父表格。

对每个有元素或者混合内容的子元素，通过父元素主键将父元素表格和子元素表格相连接。

下面的过程(经简化)说明了如何从一个关系型的结构生成一个DTD:

对于每个表格，新建一个元素；

对于表格中的每个字段，新建一个属性或者是只包含未析数据的子元素；

对于每个表格字段中提供主键的主键/外键的关系都新建一个子元素。

不幸的是，这些过程还存在着一些缺陷。例如，DTD中没有方法预先准确地规定数据类型或者字段长度。

因为任何的预先定义(例如通过读取一个示例文档)在读取其它“类型”的文档或者其他文档中包含有超过字长内容的文档时就会产生错误。(长久之策是使用XML schema文档的数据类型。)简单来说，当从一关系型结构生成DTD时，是没有办法预先判断子元素“应该”出现的顺序或者字段(如数据库内部的行标识)是否该进行完全转换。在以上两种情况中都可能产生命名的冲突。

尽管有这样那样的缺陷，但是这些方法仍然能够很好地奠定在关系型结构和DTD之间互相转换的起点。

4.3 存储和检索文档

4.4 Tamino——第一个完全XML的DBMS

Tamino 是世界上第一个原生的 XML Information Server；是一个支持 Web 的完整数据管理系统，提供资料交换和应用程序整合的环境；也是一项能将企业资料转换为 Internet 对象的技术。 Tamino 建立了高度可靠、扩充性且开放的环境。Tamino快速、强韧、高度可扩展性，以开放标准为架构。Tamino Information Server架构包含：

l X-Port:作为整合Web服务器，X-Port将Tamino直接连到网际网络，不需要拟写Script或Servlet。Tamino对象可以经由URL直接存取。透过Tamino数据对应服务，甚至像Adabas或RDBMS的传统数据都可以转换为Internet对象。X-Port支持HTTP V1.0和V1.1。

l X-Machine技术:X-Machine技术让与商务程序相关的数据对象可以用它们原来的格式进行储存和存取。Tamino支持具有XLL连接服务、XSL样式表和XQL查询语言子集，以及XML命名空间的XML V1.0标准。

l SQL引擎:为支持结构化数据及为SQL架构的应用程序服务。数据对应:数据对应包含系统数据，像DTD、关系式结构描述等。它描述了XML项目如何对应到原生的XML储存区、SQL储存区，或经由X-Node对应到外部数据来源。

l X-Node:X-Node让使用者得以存取散布于多个异质和分散式的数据来源的商务数据，还可包含储存在数据库、档案系统中的数据、或由信息传递系统（甚至超出公司IT的范围）所提供的数据。

l Tamino SDK:Tamino SDK提供应用程序设计人员建立Tamino架构之电子商务应用程序的必需接口。透过传统URL地址直接存取XML对象。Tamino实现XQL查询语言的子集以供复杂查询使用。对于SQL架构和面向对象的应用程序，Tamino提供了像OLEDB、ODBC、JDBC和DCOM的接口。Tamino支持W 3C 的文件对象模型（DOM）建议第一级，可提供像DOM对象的XML文件给客户端。使应用程序得以存取、分析并修改文件项目。DOM在服务器上的实现如同Tamino客户端的应用程序发展接口（API）；实现成果可支持小的客户端。

五．分布环境下数据同步的实现

5.1 分布式数据存储

5.1.1 数据复制

数据复制是指在多个站点上维护数据库的备份，其主要目的是提高分布式数据库系统的可用性、可靠性或访问性能。

数据复制的定义为：系统维护一个关系的几个完全相同的副本（拷贝），各个副本存储在不同的节点上，这就是数据复制。

5.1.2 数据分片

数据分片就是将关系划分为几个片段，各个片段存储在不同的节点上。对于一个关系进行分片可以有两种不同的模式：水平分片和垂直分片。综合水平分片和垂直分片，还可以对一个关系进行混合分片。

水平分片就是将关系的每个元组分到一个或多个片段中来对关系进行划分。

垂直分片就是利用某种方式对一种关系r的模式R进行分解来对关系进行划分。

5.1.3 SQL Server 7.0中的复制技术

a. 服务器角色

l 出版者(publisher)：主要是原始数据的提供者，它负责向分发者提供提取数据的服务

l 分发者（distributor）：负责分发数据库，并把复制数据从分发数据库复制到定购者，分发者和出版者可以是同一台服务器，也可以是两台独立的机器。

l 定购者（subscriber）：是实际数据的使用者，它从分发者那里取得数据，对数据的操作一般是只读的，但是如果选择了即时更新定购者（Immediate-updating Subscribers）选项，定购者也可以修改数据。

b. 复制类型

l 事务型的复制（Transaction）：此种类型的复制，出版者的数据修改所产生的事务日志会被即时地复制到定购者，定购者利用事务日志修改自己的数据。

l 快照型的复制（Snapshot）：，此种类型的复制向定购者提供某一时刻出版者数据的快照并将它们全部复制到定购者。

l 合并型的复制（merge）：对于这种类型的复制，定购者离线修改数据，再在一定的时候把所作的修改写回出版者。当多个定购者的修改发生冲突时，将由优先权原则决定最终修改结果。

c. 复制方式
根据不同情况，可以有推（push）和拉（pull）两种方式来实现各种复制类型。

5.2 分布式事务

5.2.1 事务的定义和特性

事务是访问并可能更新各种数据项的一个程序执行单元，在数据库关系系统（DBMS）中通常使用begin transaction和end transaction语句来界定。事务由事务开始与事务结束之间执行的全体操作组成。

为了保证数据完整性，事务的特性如下（简写为ACID）：

l 原子性：事务的所有操作在数据库中要么正确反映出来要么全部不反映。

l 一致性：事务的隔离执行（即没有并发执行的其他事务）保持数据库的一致性。

l 隔离性：尽管多个事务可以并发执行，但系统保证每个事务都感觉不到其他事务在并发地执行。

l 持久性：一个事务成功完成后，即使系统可能出现故障。该事务对数据库地改变必须是永久地。

5.2.2 分布事务系统结构

分布事务是访问和更新多个节点上地数据库地事务。因为可能由多个节点参与执行，保证分布事务地ACID特性要复杂地多。每个节点都要有自己地局部事务管理器，其功能是保证该节点上执行地事务的ACID特性。各个事务管理器互相协作执行全局事务。其中，每个事务管理器要负责：

l 维护一个用于恢复的日志。

l 参与适当的并发控制，以协调在该节点上执行的事务的并发执行。

l 启动事务的执行

l 将事务分裂为一些子事务，并将这些子事务分派到恰当的节点上去执行。

l 协调事务的终止，其结果是事务在所有节点上都提交和事务在所有节点上都终止。

5.2.3 提交协议

为了保证原子性，执行事务T的所有节点都必须在T执行的最终结果上取得一致。T必须要么在所有节点上都提交，要么在所有节点上都中止。为了保证这一特性，T的事务协调器必须执行一个提交协议：

l 两阶段提交

l 三阶段提交

5.3 多数据库系统

近年来，开发了许多新的数据库应用系统，它们需要来自多个先前存在于多个数据库中的数据，这些先前存在的数据库位于一个异构的硬件及软件环境集合中。操纵异构数据库中的信息需要在已有数据库系统之上增加一个软件层——多数据库系统。这些局部的数据库系统可能采用不同的逻辑模型以及数据定义和数据操纵语言，而且可能在并发控制和事务管理机制上存在差别。多数据库系统造成逻辑上数据库集成的假象，而不需要将数据库在物理上集成。

在多数据库系统，要实现：

l 数据的一致视图

各个DBMS可能使用不同的数据模型，也就是说，有的DBMS可能采用关系模型，而有的DBMS可能采用网状模型或层次模型。由于多数据库系统会提供单一集成的数据库系统的假象，因此必须使用一个共同的数据模型，一般我们选择关系模型，并将SQL作为共同的查询语言，这里主要面临的问题为：

a．不同字符集。

b．浮点表示不同

c．不同语言

d．其他

l 事务管理

多数据系统支持两类事务：

a．局部事务

b．全局事务

为了实现局部事务和全局事务的一致性，提供以下方法：