分布式数据库教案

一、引言

自80年代以来，数据库技术得到了极大的发展，特别是分布式网络数据库技术的出现，使不同区域的数据得以共享，提高了工作的协调性与效率。

在一些拥有地理分散的子公司的企业中。地理位置的分散造成了业务数据的分散，总公司与各分公司处于不同的城市或城市中的各个地区，在业务上它们除了处理各自的数据，也需要彼此之间进行数据的交换和处理，如何处理分散的数据和集中的管理，曾是困绕数据库开发者多年的难题，分布式数据库系统技术的出现为解决这个问题提供了可能。随着计算机网络技术的发展以及地理上分散的部门、公司、厂商对于数据库应用的需求，数据库技术从单机扩展至网络，对数据的收集、存储、处理和传播由集中式走向分布式、从封闭走向开放已在所难免。

 

二、分布式数据库技术介绍

分布式数据库系统是一个客户/服务器体系结构，其结构如图1。在网络环境中，每个具有多用户处理能力的硬件平台都可以成为服务器，也可成为工作站。多个服务器上的数据库对用户来说图1分布式数据库系统结构，是一个逻辑上的单一数据库整体，数据一致性、完整性及安全性都是对这一逻辑上的单个数据库进行控制的。服务器对共享数据的存取进行管理，而非数据库管理系统的处理操作可以由客户机来完成。

 

用户

网络

DBMS

服务器

DBMS

服务器

DBMS

服务器

用户

用户

 

 

 

  

分布式(网络)技术与数据库技术的结合，是在逻辑上属于同一系统，但在物理上分散在计算机网络连接的多个场地(节点)的一组数据集。从概念上讲，分布式数据库是物理上分散在计算机网络各结点上，而逻辑上属于同一个系统的数据集合。

分布式数据库具有数据的分布性和数据库间的协调性两大特点。系统强调结点的自治性而不强调系统的集中控制，且系统应保持数据的分布透明性，使应用程序编写时可完全不考虑数据的分布情况。

分布式数据库系统通过复制使系统具有适当的数据冗余，但可以增加系统的可靠性和可用性；提供局部自治的数据共享和场地之间的协调，从而使系统具有快速的数据处理能力；另外，通过数据库技术与并行处理技术的结合，利用多处理机并行处理产生的规模效益，可提高系统的快速反应能力。

每个场地（结点）上的数据一般用来描述本场地的现实世界，场地局部数据库的数据源和大多数用户(应用)一般均驻留在本场地，即每个场地具有独立处理的能力(场地自治)，可执行局部应用；另外，场地间通过网络通讯也能执行全局应用。对用户来说，一个分布式数据库从逻辑上看，如同集中式数据库一样，用户可在任何一个场地执行全局应用。

在分布式数据库系统中数据独立性概念也同样重要，然而增加了一个新的概念，就是分布式透明性。所谓分布式透明性就是在编写程序时好像数据没有被分布一样，因此把数据进行转移不会影响程序的正确性。

三、传统的数据库于分布式数据库的区别

传统的数据库应用程序经常采用客户机/服务器结构（即C/S结构，如图2），这种结构在技术上已经很成熟了并且应用也很广泛，但这种结构的应用系统有其不足之处。比如当客户数量很多，数据量又都很大的情况下，服务器的负载就会很重，而且重复性工作很多，因为很多客户发出的查询可能完全相同，而查询结果无法共享，即使两个客户发出的请求完全相同也要在服务器上执行两次查询；在客户端存储了具有商业价值的查询算法；数据库服务器负担过重导致效率低下等。

  

而当在服务器和客户机之间再加一个服务器，专门用于存储查询算法和临时查询结果，则问题就得到了很好的解决：一方面不同的客户可以共用临时的查询结果而无须再访问数据库服务器，减轻了服务器的负担；同时在客户端也看不到作为商业机密的查询算法。这也就是分布式系统的工作原理。

分布式系统的出现源于传统的C/S结构的若干弊病，如效率低，安全性差等，结合到数据库方面来说，全球的DNS（域名解析系统 Domain Name System）系统是一个很典型的例子，试想如果把全世界所有的域名都集中到一台服务器中来进行管理，那服务器肯定会因负载过重而无法正常工作，整个互联网也就瘫痪了。（可以画一个寻址DNS服务器的图）

 

与传统式数据库中避免数据冗余不同，数据冗余在分布式系统中被看作是所需要的特性，其原因在于：

首先，如果在需要的节点复制数据，则可以提高局部的应用性。

其次，当某节点发生故障时，可以操作其它节点上的复制数据，因此这可以增加系统的有效性。

但在分布式系统中对最佳冗余度的评价是很复杂的。

 

四、分布式数据库技术设计

数据库设计的原则

从全局应用的角度出发，将这些数据库自下而上构成分布式数据库系统，实现全局数据的完整性和一致性，各场地仍然存放本场地的数据，通过网络对共享池进行操作，对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。该分布式数据库系统可以在对当前机构影响最小的情况下进行扩充，增加新的场地时只需增加一个节点就可以了，同时也使得各处理机之间的相互干扰降到最低。

数据存储

在分布式数据库中，数据存储通过以下三种途径实现：

①复制：系统维护关系的几个完全相同的副本，这些副本存储在不同的结点上。

②分片：关系被划分为几个片段，各个片段存储在不同的结点上。

③复制+分片：关系被划分为几个片段，系统为每个片段维护几个副本。

因为各数据库之间存在一定的数据冗余，又存在着差异，我们使用了复制+分片的方式进行数据存储。

数据分片

在分布式数据库系统中，将关系分片，有利于按用户需求组织数据的分布，目前的分片方式有水平分片、垂直分片、导出分片、混合分片等四种。我们可以根据不同的数据关系采用了不同的分片方式。

数据同步

数据同步方式则根据系统需求使用事务复制（transaction replication）和合并复制(merge replication)两种，由于场地只存放本场地的数据，数据管理和分析功能是由网络共享池的数据库服务器来实现的，各场地只需将更新的数据保存到共享池的数据库即可，我们使用事务复制进行业务数据的同步，把场地的数据库作为出版者和分发者，共享池的数据库作为订阅者，对各场地的数据建立快照代理，并在分发数据库中记录同步状态的信息。每一个使用事务复制的场地数据库均有自己的日志读取代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直接推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布代理运行在分发者上并与订阅者相连。

事务复制可以支持两种类型的对象复制：表和存储过程。在出版者中定义数据库中的部分或全部的数据，选择多个存储过程作为复制。当场地的数据发生更新时，日志读取代理将即时的把更新信息推到共享池的数据库中。基于存储过程的复制使应用具有更好的性能，可以大大减少网络的通讯量。事务性日志使用事务日志来监视文章中的数据改变。

合并复制作为一种从出版者向订购者分发数据方法允许出版者和订购者对出版数据进行修改，而不管订购者与出版者是相互连接或是断开，然后当所有（或部分）节点相连时便合并发生在各个节点的变化。在合并复制中，每个节点都独立完成属于自己的任务，不像事务复制和快照复制那样订购者与出版者之间要相互连接，完全不必要连接到其他节点，也不必使用MS DTC来实现两阶段提交就可以在多个节点进行修改，只是在某一时刻才将该节点与其他节点相连（此时的其他节点并不一定指所有其他节点）。

然后将所发生的数据变化复制到这些相连接节点的数据库中。

以下即为该系统的设计框图：

 

 

图 4

 

■分布式事务处理  利用分布式技术实现事务处理和查询

分布式数据库系统中数据的分布导致事务具有了分布性。一个全局事务的执行被划分为在许多场地上子事务的执行。

分布式事务要能够在多个服务器上执行，我们使用MS DTC作为事务管理器来协调各个服务器对事务的处理操作，为了减少网络故障对分布式事务处理的影响，避免分布式事务造成不同服务器间数据的不一致，X/Open XA规范将分布式事务的处理过程规定为两个阶段，即准备阶段和提交阶段，就是常说的两阶段提交。

在进行分布式事务处理时，我们首先在服务器端用Transact SQL脚本程序BEGIN DISTRIBUTED TRANSACTION语句启动一个分布式事务，将该服务器作为分布式事务管理服务器，然后脚本程序对连接服务器执行分布式查询或远程服务器上的存储过程，分布式事务管理服务器会自动调用MS DTC，使远程服务器参加分布式事务处理。当脚本程序执行COMMIT TRANSACTION、COMMIT WORK、ROLLBACK TRANSACTION或ROLLBACK WORK语句时，分布式事务管理服务器将再次调用MS DTC，用它来管理两阶段提交进程，使连接服务器和远程服务器提交或回滚事务。例如在保险业务系统中，如果总公司数据库管理系统发现该客户是交叉投保，则需将该保单插入拒保记录表中，同时在对应的营业分支机构的数据库中将该保单的状态设为无效。我们在营业分支机构的数据库（DBServer1）中建立存储过程update_policy更新保单状态，在总公司数据库服务器（DBServer）上执行以下脚本程序，启动一个分布式事务insert_reject：
USE business
GO
BEGIN DISTRIBUTED TRANSACTION
INSERT reject
VALUES(policy_id, insurance_no,business_date,customer_id,customer_name…)
EXECUTE DBServer1.business.dbo.update_policy
COMMIT TRANSACTION
GO
　　系统执行insert_reject事务向DBServer中的reject表插入一条记录，同时更新对应的分支机构数据库中的保单表status字段，该事务使系统数据的完整性得到了保证。

■      分布式查询

分布式数据库系统中数据的分布导致查询也具有了分布性，分布式查询可能针对异类的OLE DB 或 ODBC 数据源。SQL Server 支持分布式查询，即包括来自两个或更多服务器数据的查询，支持服务器间的检索、更新和游标，并使用 Microsoft Distributed Transaction Coordinator (MS DTC) 保证节点间事务语义，维护服务器间的安全。

在系统设计的过程中，为了减少网络通讯量，我们根据应用的功能已将数据关系进行分片存放在各数据库中，因此大部分的应用是面向局部数据库的操作，但全局性的查询仍需要多个数据库的数据支持。在业务人员的管理模块中，由于各分支机构对其业务人员进行直接管理，且管理制度都有差异，我们将业务人员信息存放在分支机构的数据库中，通过联合分布式查询对公司所属的所有业务员进行登记；在客户管理模块中，我们根据来源将客户信息分别存放在业务数据库服务器的传统客户表和Web数据库服务器的网络客户表中，通过联合分布式查询才能对公司所属的所有业务员和客户进行登记，下面以年度的业务员查询为例介绍联合分布式查询的方法：

SELECT　 emp.emp_name, emp.emp_id，emp.emp_gender…
FROM　 DBServer1.business.dbo.employee AS emp
WHERE　 date between '01/01/2000' and '12/31/2000'
UNION
SELECT　 emp.emp_name, emp.emp_id，emp.emp_gender…
FROM　 DBServer2.business.dbo.employee AS emp
WHERE　 date between '01/01/2000' and '12/31/2000'

五、分布式数据库开发实例（参考上海交通大学CIM所开发的SIPM系统资料）

SIPM是一个面向工艺设计师和工艺过程管理的集成化CAPP系统，具有强大的工艺设计、工艺设计过程管理、工艺签审、工艺版本管理、管理用工艺文件自动生成等功能。

由于我们主要介绍分布式数据库，所以就其信息传输过程进行论述。

其在数据处理的特点，批量单向发布信息由工艺任务进展情况监测程序触发实现数据交换，一旦工艺发布且网络传送许可，就一次性传送所有工艺信息；而及时信息需进行实时交换，由于信息存放在各场地的分散的数据库中(不仅是物理上而且是逻辑上)，采用主动激发应用程序非常困难，故采用了公用数据区被动激发的方法，即在分散的数据库上开辟公用数据区，需及时交换的信息动态地对公用数据区的内容进行更新，应用程序动态扫描各公用数据区的更新情况，一旦发现有新数据就立即对其进行分类处理并更新公用数据区的状态。

为了能实现以上的目标，采用了基于客户机/服务器的计算环境分布式数据库系统，各场地的客户机通过远程过程调用(RPC)以SQL形式请求服务程序提供服务，服务器执行所需的处理，然后将结果返回给客户机，客户机和服务器之间通过局域网实现无缝协同计算；在整个系统中，各局域网之间采用TCP/IP协议通讯，通过数据复制技术、两阶段递交协议等来确保分布在网络各个场地上的同构或异构数据的一致性、完整性和可用性。

为了便于应用系统的扩展及数据交换，可采用层次递阶控制型信息集成方式，见图5。结构BOM、工艺BOM、企业基础数据等子系统间交换数据存放在企业中心数据库中(企业中心数据库中的信息经过重新整理分类，更具有完整性)；各子系统间的信息交换通过数据存取控制接口向企业中心数据库发送和读取实现；各子系统可以再通过层次递阶控制结构实现信息交换。数据存取接口可以通过程序控制或通过数据属性的方式来实现(如有效性控制可以通过程序比较文件的时间，也可以在数据库中增加时间戳字段等方法来实现)。这种方式降低了各子系统之间接口的复杂性，增强了整个集成方案的可扩充性；数据的交换集中在各子系统与中心数据库之间，提高了系统集成的可靠性；数据交换的功能在企业中心数据库与各子系统间进行，企业中心数据库所在的服务器分担大部分数据交换所需的计算时间，可减少子系统对数据交换的被动响应。

 

 

 

图 5

六、结论

   引入分布式数据库技术后，有效的解决了数据分散和集中管理的矛盾，实现了数据的共享和交换。事实证明，分布式技术在远程数据管理中具有不可替代的作用，且其前景越来越被看好。