下面对一些著名的DDBMS的目录体系结构和管理策略作一个简单回顾并进行比较分析，这样才能对DDBMS的典型目录结构有一个具体的和深入的了解。
1.SDD-1
SDD-1是20世纪七八十年代美国国防部委托美国CCA（computer corporation of America）公司设计与开发的一个分布式数据库管理系统。应该说，很多分布式数据库技术的先驱思想来自SDD-1。限于当时的条件，SDD-1系统是在原数字设备公司（DEC公司）的PDP机器和ARPAnet上实现的。
SDD-1采用一种全局式的目录体系结构，它的系统目录是作为逻辑上一致的、单一的表或关系来处理的。像一般的用户数据一样，这张表可以分片和建立副本，目录数据可以在数据模块节点之间分布和重复。如前所述，这样的系统显得统一、规整。为了提高性能，SDD-1允许局部节点暂存远程数据的目录登记项的拷贝，并要求保持它们的最新版本。这就会引起关于高速缓冲存储器（Cache）的同步更新问题。因此，SDD-1的目录数据像用户数据那样存储。
2.Distributed Ingres
Distributed Ingres是第一个关系型数据库管理系统Ingres[1]的分布式版本。Distributed Ingres的目录体系结构是全局的。它把数据对象分为两类：局部关系，它从本地节点上存取；全局关系，它可以从网上的任何节点存取。在网络的每个节点上均需存放每个全局关系的名字和该关系的存储节点等信息。添加或删除一个全局关系，意味着要向全网广播有关该全局关系的名字和存放地点等信息。
3.POREL
POREL系统是联邦德国斯图加特大学设计的一个分布式关系型数据库系统，项目从20世纪70年代末启动，于20世纪80年代初完成。POREL系统的数据对象都是全局性的。该系统将目录划分为长目录和短目录。短目录用于存放一些变化不太频繁的信息，如关系模式的定义、关系数据的分布等。短目录存放于网络的每个节点上，以保证全网的一致性。长目录用于存放一些变化较为频繁的信息，如子关系的基（cardinality）、属性值的分布、存取的路径信息等。长目录存放在相应数据存放的节点上。POREL系统的目录体系结构也是全局的，短目录的变化涉及网上的每一个节点。为了保证短目录的全网一致性，当定义或添加、删除、修改短目录时（相当于“写”目录时）都必须进行全网封锁，这一开销是非常大的，显然会极大地影响系统的使用效率。
4.System R*
System R*是IBM公司San Jose实验室继集中式数据库管理系统System R（其产品化版本演化为DB2）之后研制的一个分布式实验系统，它特别强调节点的自治性。
System R*的分布式目录体系结构要点包含以下几个方面。(www.chuimin.cn)
●每个节点上的目录只存放在该节点上生成的数据对象中，或者存储在该节点的数据对象的目录登记项中。
●若某数据对象未存放在它出生的节点上，则在出生节点的目录中需有该数据对象的一个登记项，用于指示该数据对象的当前存放地点。
●引入数据对象的系统范围名（system wide name，SWN），它是该数据对象在全系统范围内的唯一标识。SWN由以下四个字符串分量组成：
USER@USER-SITE.OBJECT.NAME@OBJECT-SITE
这四个字符串分量分别为用户名（若默认，则指正在进行处理的当前用户）、用户所在节点名（若默认，则指当前节点）、数据对象名（不允许默认）和数据对象的生成节点名（若默认，则指当前节点）。系统范围名（SWN）的格式和语义规定了它允许不同的用户使用同一对象名去访问不同的数据对象，也允许不同的用户使用不同的对象名访问同一数据对象。这样一来，就使得一个现成的数据库节点加入R*中时无须改动它已经使用的数据对象的名字，也无须在全网范围内命名时再进行调整，从而使系统的增长比较简单、顺利。可以看出这种表示方式和后来的Internet命名形态十分相似。
R*的分布式目录体系结构既支持了用户应用的单一系统映像，又能对分布在网上的数据对象进行透明的存取，同时也维护了节点的自治性，使每个节点都能管理并控制它自己的局部数据对象及其目录登记项。
R*提出的分布式目录体系结构有两个目标：其一是向用户提供单一的系统映像，使数据对象在网络的各节点上的分布对用户透明。用户不必顾及所用数据对象的存放地点，也不用考虑它的查询在何处运行。其二是提供节点自治性，对个别节点的加入和退出，对系统的增长提供相当的灵活性、健壮性和稳定性。
值得注意的是，20世纪80年代中期是我国分布式数据库系统研制的高潮，除了CPOREL外，一些著名大学也在研制各自的分布式数据库管理系统，例如东南大学研制的SUNDDB、武汉大学研制的WDDBS-32等。
SUNDDB采用了类似R*的分布式目录体系结构，并进行了改进和修改。
WDDBS-32是武汉大学设计和实现的分布式数据库管理系统。其全局目录/辞典（GD/D）采用全复制式对GD/D进行管理。所谓全复制式，即在每个节点上都保存所有的GD/D信息。这种目录体系结构增加了节点的自治性，但要付出一些存储代价，以及需要维护各节点目录副本的一致性。
有关分布式数据库技术的文章
Oracle公司的OPS环境比一般的（单实例）Oracle环境复杂得多。不同结构下的OPS的实施略有不同。图14.23OPS体系结构为了利用这些特性，需要专业人员合适的设计以及恰当的手工配置。下面对有些关键问题进行简单讨论，讨论中会涉及一些Oracle系统专用的术语，读者可参阅Oracle公司的相关文档。DLM与Oracle进程一起工作并相互通信。DLM相关的初始化参数在每个实例的SGA[12]中分配必要的结构以处理消息机制、封锁与实例相关的Cache管理，这样就为各种Oracle进程操纵提供了基础。......
2023-10-28
查询优化的本地化分层聚焦于将查询转换成本地数据。一个全局关系可以通过应用重构规则来重构，从而导出一个关系代数程序，其操作数是数据片，这个程序称为本地化程序。将分布查询分配到节点上的自然办法是生成查询，让每个全局关系使用本地化程序来代替。这可以看成是在一棵分布查询的算符树上将叶子用与本地化程序对应的子树来替代。数据水平分片关系的连接也可以简化。......
2023-10-28
分布式数据库系统的数据目录的分布可以有以下多种选择。也就是说，首要的问题是，分布式数据库系统中，数据库目录是集中存放还是分散存放。由于目录的管理均借助于整个系统的相关成分的管理，所以系统的设计和开发开销大大下降。......
2023-10-28
与数据库安全系统打交道的人员可以分为两类：数据库管理员和普通用户。DBA要对安全负责，所以他（们）要创建授权规则，定义谁可以使用哪部分数据，以及如何使用。图13.1数据库安全系统由图13.1可知，数据库安全系统里存放着授权规则，在每次数据库存取时强制满足其规则。从完整性方面考虑，数据库安全可以包含以下两方面。1）设计阶段的数据库安全在设计阶段必须关注数据库的安全性。DBA负责处理整个数据库系统里的用户账号和口令。......
2023-10-28
然而，由参考完整性约束指定的级联更新则是一种“人工”垃圾收集的简单形式。在大部分通用操作系统或程序设计语言里，人工垃圾收集不是很成功。因此，分布式基于对象系统的通用性要求能自动收集垃圾。增量垃圾收集的主要困难是，收集器跟踪对象图，程序活跃度会更改对象图的其他部分。分布垃圾收集依赖于分布引证计数或分布跟踪。......
2023-10-28
图3.1软件开发过程数据库设计的过程与软件开发的过程类似。下面先来看一下集中式数据库设计的情况。在分布式数据库系统中，集中式数据库设计的问题依然存在，且有以下两个新的问题需要考虑。这个过程就是确定如何将全局关系划分成水平、垂直或者混合的数据片。数据片的分配，即决定数据片如何映射到物理镜像上，决定如何复制数据片。数据片的分配问题则研究已久，当然，过去研究的则是“文件分配”问题。......
2023-10-28
自1995年以来，基于CORBA软件的企业级应用发展迅猛。CORBA是OMG随着硬件和软件产品的快速增长，针对互操作性的需要而提出的。CORBA 2.0于1994年12月被提出，它定义了不同供应商的ORB怎样才能实现真正的互操作性。图12.4OMA体系结构OMA体系结构主要包括以下几部分。ORB用于发现与该请求对应的对象实现，对所要求的所有机制做出响应，准备好对象实现以响应请求，并完成请求所需要的数据通信。由图12.5可知，客户端通过ORB向对象实现发送请求。......
2023-10-28
前面提及的OPS是Oracle 6.0中引入的，RAC源自OPS，但作为新的产品推出。一个4节点的集群结构如图14.24所示。图14.24一个4节点的集群结构RAC起源于OPS，在Oracle 6.0.35版本中引入。最初只适用于Digital VAX/VMS集群使用Oracle开发的分布式封锁管理器。从Oracle 9.0.1开始，OPS重新改为RAC可选项。在商业上，RAC已是一个完整的新产品。然而在技术上，OPS和RAC的一个重要区别是超高速缓存相关性。OPS里，实例间的块协调由PCM处理。Oracle 8i引入了Cache Fusion PhaseⅠ，部分淘汰了磁盘ping。......
2023-10-28
相关推荐