同构和异构数据库
同构分布式数据库：所有站点都使用共同的数据库管理系统软件，它们彼此了解，合作处理用户的需求。本地的站点放弃了作为其自治权一部分的更改模式或者数据库管理系统软件的权利。
异构分布式数据库：不同的站点具有不同的模式和不同的数据库管理系统软件。站点之间并不了解，在事务处理过程中，它们仅仅为合作提供有限的功能。模式的差别经常是查询处理中的主要问题，软件的差别成为访问多站点事务处理的障碍。
我们主要讨论同构分布式数据库。
分布式数据存储
在分布式数据库存储一个关系的方法：
- 复制：系统维护关系的几个完全相同的副本，各个副本存储在不同的站点。
- 分片：系统把关系分为几个片，各片存储在不同的站点上。
- 分片和复制的组合：一个关系划分为多个片，每个片有几个副本。
数据复制
如果关系r被复制，则在两个或两个以上的站点存在关系r的副本。最极端情况下采用全复制，这是每个站点都存有副本，优缺点：
- 可用性：当包含关系r的站点之一发生故障时，关系r可以在另一个站点找到。
- 增加的并行度：几个站点可以并行地处理涉及关系r的查询
- 增加的更新开销:系统必须保证关系r的所有副本是一致的，否则可能产生错误的计算。因此，只要r更新，更新就必须传播到包含其副本的所有站点。
数据分片
对一个关系分片有两种模式：
- 水平分片：将r的每个元组分到一个或多个片来对关系进行划分，水平划分通常用于把元组保留在它们最常用的站点上以减少数据的传输。
- 垂直分片：对关系r的模式R进行划分
透明性
分布式数据库系统的用户不需要知道数据的物理位置，或者如何访问某个特定本地站点的数据。该特点称为数据透明性，可以有以下形式：
- 分片透明性
- 复制透明性
- 位置透明性
数据项必须有为唯一的名字，在分布式数据库中，我们必须保证两个站点没有对不同数据项使用相同的名字。
解决方法：
- 将所有名字都在*名字服务器注册。
但这样名字服务器可能成为性能的瓶颈，并且如果名字服务器崩溃，分布式系统的站点不可能允许下去。
- 要求每个站点都将其站点标识符作为前缀加到该站点所产生的所有名字上。为了实现位置透明性，用户可以用简单的名字来引用数据项，而简单名字被本地系统翻译为完整的名字，这样，用户不需要了解数据项的真实物理位置。
分布式事务
- 局部事务：仅访问和更新一个局部数据库数据的事务；可以用集中式数据库系统的方法来保证ACID特征。
- 全局事务：访问和更新多个数据库中数据的事务；保证ACID更加复杂。
系统结构
每个站点都有自己的局部事务管理器，保证在该站点执行的事务的ACID特性。各个事务管理器协调执行全局事务。
其中每个站点包括两个子系统：
- 事务管理器：管理那些访问存储在一个局部站点中数据的事务的执行。这样的事务既可以是局部事务，也可以是全局事务。
- 维护一个用于恢复的日志
- 参与适当的并发控制机制，协调在该站点执行的事务的并发执行
- 事务协调器：协调该站点上发起的各个不同事务（全局或局部事务）。
- 启动事务的执行
- 将事务分裂为一些子事务，并将这些子事务分派到恰当的站点去执行
- 协调事务的终止，其结果可以是事务在所有站点上都提交或事务在所有站点上都中止
系统故障模式
基本故障类型包括：
- 站点故障
- 消息丢失
- 通信链路故障
- 网络分割
分布式系统总是可能发生消息的丢失或损坏，系统采用TCP/IP协议来处理这样的错误。如果两个站点A和B不直接相连，消息必须通过一系列的通信链路从一个站点到两一个。如果有一条链路故障，则通过该链路传送的消息必须重新路由。在某些情况下，故障可能导致某些站点之间没有连接。如果一个系统分成了两个彼此无任何连接的称为分区的子系统，我们说该系统被分割。
提交协议
两阶段提交协议（2PC）是最简单且使用最广泛的提交协议之一。
两阶段提交
考虑一个从站点Si发起的事务T，并设Si的事务协调器是Ci。
提交协议
当T完成执行时（即执行T的所有站点都通知Ci已完成了T的执行），Ci启动2PC协议。
- 阶段一：Ci将记录<prepare T>加到日志中，并强制日志写入稳定存储器中。接着它将一条prepare T消息发送到执行T的所有站点上。当收到这样一条消息时，其他所有站点上事务管理器确定是否愿意提交T中属于它的那部分。如果不，事务管理器将<no T>加到日志中，并通过向Ci发送一条abort T消息进行响应。如果是，事务管理器把就<ready T>加到日志中，并将日志强制写入稳定存储器中，然后事务管理器通过向Ci发送一条ready T消息作为回答。
- 阶段二：当Ci收到所有站点对prepare T消息的回答时，或者当prepare T消息发送后一个预定的时间间隔过去，Ci就可以确定是否将事务T提交还是中止。如果Ci收到所有ready T消息，事务T提交，否则中止。根据结论不同，将记录<commit T>或记录<abort T>加到日志中，并将日志强制写入稳定存储器中。此后，协调器向所有参与站点发送消息commit T或消息abort T 。当其他所有站点收到后，将此消息记录日志。
在向协调器发送ready T消息之前，执行T的站点可以在任何时候无条件中止。一旦ready T消息发出，则站点上的事务称为就绪状态。由于事务的提交需要全体一致，只要有一个站点回答abort T，事务T的命运就决定了。由于作为协调器的站点Si是执行T的站点之一，协调器可以单方面将T中止。
故障处理
- 参与站点的故障。如果协调器Ci检测到某个站点发生了故障，将采取如下：如果该站点在用ready T消息回答Ci之前发生故障，则协调器假定该站点用abort T回答。如果是之后，则协调器忽略该故障。如果参与站点Sk从故障中恢复，必须检查日志，看看故障发生时正在执行的事务的状态。
- 日志中包含<commit T>记录，站点执行redo(T)
- 日志中包含<abort T>记录，站点执行undo(T)
- 日志中包含<ready T>记录，站点必须询问Ci以确定T的最终结果。结果Ci仍在工作，它就发现Sk关于T是提交还是中止的信息。如果T已提交，Sk执行redo(T)；否则，Sk执行undo(T)。如果Ci停止工作，Sk必须试图从别的站点发现T的最终结果。通过向系统中所有站点发送querystatus T 消息来进行。站点收到这样一条消息，必须查阅其日志来看T是否在该站点执行过，如果是，还要看一看T是否提交。然后再把查询结果告诉Sk。如果每个站点都没有恰当的信息，那么Sk既不能提交也不能中止T，关于T的决定需要推迟到Sk能得到所需信息为止。因此，Sk会定期向其他站点发送querystatus 消息。
- 日志中没有包含关于T的控制记录(abort,commit,ready)。因此，Sk在响应来自Ci的prepare T消息前发生了故障。根据上面算法，Ci必然中止T，因此Sk必须执行undo(T)。
- 协调器的故障。如果协调器在为事务T执行提交协议的过程中发生故障，那么，必须由参与的站点来决定事务T的最终结果。
- 如果某个活跃站点的日志中包含<commit T>记录，则T必须被提交。
- 如果某个活跃站点的日志中包含<abort T>记录，则T必须被中止。
- 如果某个活跃站点的日志中不包含<ready T>记录，则发生故障的协调器不可能已经将T提交。但是可能协调器已经决定中止T而不是提交。
- 如果上述情况不成立，则所有活跃站点都有<ready T>，但此外没有别的控制记录。由于协调器已经发生故障，不等到协调器恢复，就不可能站点是否已经做出决定，或者做了决定是什么。因此，活跃站点必须等待Ci恢复。这是，别的事务可能*等待T，数据项在发生故障的站点不能获得，在活跃的站点也不能获得，称为阻塞问题。
- 网络分割
- 协调器和它所有参与者在同一分区。故障对提交协议没有影响。
- 协调器与它所有参与者在不同分区。从其中一个分区的站点的角度看，就好象其他分区中的站点发生了故障一样。不在协调器所位于的分区的站点只需要执行处理协调器故障的协议。协调器以及与协调器在同一分区的站点遵循平常的提交协议，而认为其他分区的站点发生了故障。
2PC的主要缺陷在于协调器可能导致阻塞。
恢复与并发控制
当故障站点重启后，恢复过程必须对疑问事务进行特殊对待：疑问事务时发现有<readyＴ＞日志记录，但未发现其他控制记录的事务。在有可能发生阻塞的情况下，恢复算法通常提供对在日志中记载*信息的支持，这时所写的日志记录不再是<ready T>，而是<ready T,L>，其中L是写入日志记录时事务T持有的所有的写锁的列表。恢复时，对所有疑问事务T而言，在执行局部恢复动作后，日志记录的写锁必须重新获取。
当所有疑问事务的锁重新获取后，即使在疑问事务的提交-中止状态确定前，该站点的事务就可以开始。疑问事务的提交或回滚与新事务的执行时并发的。
三阶段提交
3PC协议是对2PC的扩展，它在某种条件下可以避免阻塞问题。特别是，它假设没有网络分割发生，至多有k个参与的站点发生故障，这里的k是某个预定义的值。在假设下，协议加入额外的第三阶段避免阻塞。在该阶段，多个站点涉及提交的决定。协调器不是在持久存储中直接记录提交的决定，而是首先保证至少有k个其他的站点知道它将提交事务。如果协调器故障，剩下的站点首先选择一个新的协调器。新的协调器从剩下站点中检查协议的状态，如果协调器已经决定提交，那么其他k个被通知的站点至少有一个没有故障而同意提交决定。如果某个站点站点旧的协调器提交，那么新的协调器重新开始第三阶段。否则中止事务。
3PC在网络分割下同样会导致阻塞，并且由于其开销大没有被广泛使用。
事务处理的可选模型
持久消息：该模式将一个事务变成在不同的数据库运行的多个部分。如果发生该消息的事务提交，则持久消息保证传送给接收者仅仅一次，如果该事务中止，则持久消息保证不被传送。但可以消除阻塞。
持久消息的实现，持久消息在下面的协议中可以在不可靠的信息传递架构之上实现，这可能丢失消息或者把消息传送多次：
- 发送站点协议：当事务希望发送一个持久消息时，写一个包含在特殊关系messages to send中的消息的记录来代替直接发送消息。这个消息被赋予唯一的消息标识符。
消息传送进程监控关系，当发现新消息，它将消息发送到目的地。通常数据库并发控制机制保证系统进程只在写消息的事务提交之后才能读取消息。如果事务中止，通常的恢复机制将从关系中删除消息。
消息传送进程在它收到目的站点的确认后才从关系中删除消息，如果没有收到，将在一段时间后重新发送直到确认。万一发生永久故障，系统将在一段时间后决定不再传送，然后调用应用程序提供的异常处理代码处理故障。
- 接受站点协议：当站点收到一个持久消息时，它运行一个事务将消息加入到特殊的关系received_messages中，前提是没有相同的消息标识符出现在该关系中。在事务提交后，或者消息已经出现关系中时，接受站点向发送站点发回一个确认。
在许多消息系统中，随机的消息延迟很少发生但有可能发生。因此，为了安全，消息不会从received_messages中删除。删除消息将无法检测重复传送。但这导致特殊关系received_messages的无限增长。可以为每个消息赋予一个时间戳，如果一个接受的消息的时间戳比截止期旧，则消息丢弃。记录在特殊关系中的所有比截止期旧的消息都可以删除。
分布式数据库的并发控制
*协议
假设共享与排他两种*模式的存在。
单一锁管理器方式
在单一锁管理器下，系统维护位于选定的单一站点(如Si)上的单一锁管理器。所有加锁和解锁请求都在站点Si处理。
- 实现简单
- 死锁处理简单
- 站点Si可能成为瓶颈
- 脆弱性
分布式锁管理器
每个站点维护一个本地锁管理器，来处理存储在该站点上的数据项的加锁和解锁请求。
- 实现简单
- 减轻协调器成为瓶颈的程度
- 死锁处理更加复杂
- 全局死锁的可能
在数据项有副本时的*可选方法：
- 主副本：在系统使用复制的情况下，选择一个副本作为主副本。对每个数据项Q而言，Q的主副本必定位于一个确定的站点上，我们称为Q的主站点。
- 多数协议：如果数据项Q在n个不同的站点上被复制，则加锁请求消息必须传送到存储Q的n个站点的一半以上的站点上。每个锁管理器都要确定所是否被立即授予。事务只有在成功获得Q的多数副本上的锁后才开始Q的操作。
- 能处理站点故障的情况
- 实现更加复杂
- 死锁处理复杂
- 有偏协议：与多数协议的区别是共享锁请求受到的待遇比排他锁请求受到的待遇优越。当事务需要申请数据项Q上的共享锁时，只需要向包含Q的副本的一个站点的锁管理器请求Q的锁。要申请排他锁时，要向所有包含数据项Q的站点请求。
- 开销比多数协议小
- 死锁处理复杂
- 法定人数同意协议：分派给每一个站点一个非负的权。它为数据项x的读写操作分配两个整数，即读法定人数Qr和写法定人数Qw。它们必须满足下面条件，其中S是x所在的所有站点的总权重：Qr+Qw>S and 2*Qw>S . 为了执行读操作，必须*足够的副本，使它们总权重大于Qr。为了执行写操作，使总权重大于Qw。
- 降低读和写的代价
- 能子啊站点故障下工作
时间戳
产生时间戳的两种方法：
- 集中在一个站点分发时间戳，可以用逻辑计数器或自己的本地时钟
- 分布在每个站点，每个站点用逻辑计数器或本地时钟产生一个唯一的局部时间戳。通过将唯一的局部时间戳和唯一的站点标识符连接起来，可以得到唯一的全局时间戳。
弱一致性复制
在主从复制下，数据库允许在主站点更新，并自动将更新传播到其他站的副本。事务可以读其他站点上的副本，但是不允许对它们更新。
这种复制的重要特性是事务在远程站点上不能得到锁，为了保证运行在副本站点上看到一致的数据库视图，副本应该反映主站点上数据的事务一致性快照。副本应该反映按串行化顺序排列的先于某个事务的事务所做的更新，而不应反映按串行化顺序排在该事务之后的事务所做的更新。
数据库可能配置成在主站点发生更新之后，马上将更新传播到其他站点，或者只是周期性地传播。
主从复制对于分发消息特别有。
在多主副本更新的情况下，更新允许在数据项的任何副本进行，并且自动传播到所有副本。这种模式是用于管理分布式数据库副本的基本模式。事务更新本地的副本，系统透明地更新其他副本。
更新副本的方法是以两阶段提交来实现立即更新或使用有偏协议作为并发控制技术。
许多数据库提供一种“延迟传播”将更新传播到其他站点。以延迟传播为基础的模式运行事务处理（包括更新）即使在站点断开网络时仍能进行，因此提高了可用性。在使用延迟传播时，以下两种方法通常使用：
- 在副本上的更新转化为在主站点上的更新，然后延迟传播到所有副本。
- 更新在任何副本上执行，并传播到所有其他站点。
死锁处理
如果允许死锁发生并依赖于死锁检测，则分布式系统中的主要问题就是决定如何维护等待图。处理这个问题的技术要求每个站点维护一个局部等待图。
在集中死锁检测的方法中，系统在一个单独站点构造和维护一个全局等待图。
可用性
- 高可用性：数据库在任何时候能工作
- 健壮性：必须在多种不同类型故障发生时仍能工作。能检测故障，重构系统以继续计算，以及在处理器或链路修复后能进行恢复。
链路故障征兆：通过某链路的一个消息进行多次重传，却得不到确认。
- 在站点间使用多条链路
网络分割征兆：网络试图为此消息寻找另一条路径，却无法找到。
区分网络链路故障和站点故障时不可能的，任何重构模式必须涉及成能够在网络分割情况下正确运行：
- 两个甚至更多*服务器在不同的分区中选出
- 不止一个分区更新某个被复制的数据项
基于多数的方法
每一个数据对象都存储它的一个版本号来检测它最后一次写入的时间。每当一个事务写一个对象的时候要以如下方式更新版本号：
- 如果数据对象a复制到n个不同的站点，那么一个锁请求消息必须发送到存储a的n个站点的一半以上。事务直到获得a的大多数副本的锁后才对a操作
- 读操作检查所有已经加锁的副本，读取具有最高版本号的值。写操作和读操作一样，也要读所有的副本来找到最高版本号。新的版本号比最高的版本号多1.
在事务处理期间的故障也可以容忍。
读一个、写锁有可用的方法
将单位权授予所有站点来实施有偏协议：设读的法定人数为1，设置写的法定人数为n（所以站点）。在这种情况下，不需要使用版本号。但是，主要容纳数据项的一个站点发生故障，对该数据项的写操作就不能进行。
为了使发生意外故障工作能够进行，我们使用读一个、写所有可用的协议。这样，事务管理器就不等待故障站点恢复而继续工作。
在可能发生网络分割的情况下，使用读一个、写所有可用的模式会导致不一致性。
站点重建
将修复的站点或链路重建到系统必须小心。故障站点恢复后，必须发起一个过程来更新其系统表，使之能反映该站点停止工作后发生的变化。
一个简单的方法是故障站点重新连入后，暂时让整个系统停止，但是，在大多数应用中不可行。使用一些技术可以在对任意数据项授予读或写锁前，站点必须确保它已经更新称为最新的数据项。如果一个故障链路恢复，两个或更多分区就能重新连接起来。由于网络分割限制了部分站点或所有站点可允许的操作，应该将链路的恢复迅速通知所有站点。
与远程备份比较
使用远程备份系统时，操作在单一站点上执行，只有数据和日志记录复制到其他站点。特别地，远程备份系统有助于避免两阶段提交及其导致的开销。同时，事务只需和主站点联系，避免了在多个站点运行事务代码的开销。另一方面，通过具有多个可用副本并使用多数协议，复制可以提供更高的可用性。
协调器的选择
备份协调器是一个可以在完成其他任务同时，还在本地维护足够信息，使它可以在分布式系统带来最小限度干扰的情况下担负起协调器角色的站点。所有直接发给协调器的消息都会被协调器及其备份收到。协调器和它的备份区别在于，备份不会采取任何影响其他站点的动作，这些动作由真实的协调器进行。
备份方法优点在于它能立即将处理继续下去的能力。避免了分布式系统从协调器故障恢复所需的大量延迟。其缺点在于协调器任务的重复执行带来的开销。
在缺少指定的的备份协调器或者为了处理多种故障时候，可以由那些活跃站点动态地选出新的协调器。选举算法可以使站点以分散的方式选出一个站点作为新的协调器。算法要求系统中每个活跃站点对应一个唯一的标识号。
用于选举的威逼算法：设站点Si的标识号为i。同时假设所选出的协调器总具有最大标识号的站点。当协调器故障时，算法必须选出具有最大标识号的活跃站点。该算法将高号码发送到系统的每个站点。另外，该必须提供一种能使从故障中恢复的站点辨认出当前协调器的机制。
假设站点Si发出的请求在预定时间T内没有得到协调器的回答，这时假设协调器发生故障，Si视图选举自己作为新协调器的站点。站点Si给每个据偶更大标识符的站点发一条选举信息。接着Si等待一个时间间隔T，等这些站点的任何一个回复，如果在时间站点T内没有收到，就假设具有大于i的号码的所有站点都发生故障，于是选举自己，并给具有小于i的标识号的所有站点发消息通知新协调器的站点。如果Si收到回答，就开始一个时间间隔T’来接收通知自己一个具有更大标识号的站点已被选中的消息。如果Si在T’时间内没有收到消息，就假设具有更大标识号的站点发生了故障，站点Si重新开始算法的执行。
当故障站点恢复后，马上开始执行相同算法。如果没有具有更大标识号的活跃站点，恢复后的站点就强迫具有较小数字的所有站点让自己成为协调器站点。如果出现网络分割，威逼算法在各分区选举出一个分离协调器。
分布式查询处理
代价：
- 磁盘访问量
- 数据在网络上的传输代价
- 通过在几个站点并行地处理查询的一部分，可能得到的性能收益。
查询转换
考虑一个查询“找出关系r上所有元组”，关系r可能被分片，复制，也可能既被分片也被复制。如果关系r被复制，我们就需要对副本进行选择。如果所有副本都没有分片，我们就选择使用传输代价最小的副本。但是如果被分片了，需要进行连接算法或并算法来重构关系r。
简单的连接处理
假设三个关系连接，三个关系既没复制又没分片，且关系r存储在站点S1上，关系s存储在站点S2上，关系k存储在站点S3上。设S1表示提出查询的站点，系统需要在站点S1产生结果。三个策略：
- 将三个关系的副本都送到站点S1。然后本地连接
- 将关系r的一个副本送到站点S2，在S2上计算temp1=r ⋈ s 。将temp1从S2送到S3，在S3计算temp2=temp1 ⋈ k。最后将结果temp2送到S1
- 设计与上一个策略类似的策略，只是交换S1，S2，S3的角色。
没有一个策略是最好的。
半连接策略
我们假设希望计算表达式r1 ⋈ r2，其中r1和r2分布存储在站点S1和S2上。令r1和r2的模式分别为R1和R2。假设希望在站点S1上得到结果。如果r2中有许多元组不能和r1中的任何元组相连接，那么把r2送到S1会使我们必须传输对结果无贡献的元组。
一个可能的策略：
- 在S1上计算temp<-II R1^R2(r1) //将在r1上的r1和r2的属性交集投影到temp上
- 将temp1从S1送到S2
- 在S2上计算temp2<-r2 ⋈ temp1
- 将temp2从S2送到S1
- 在S1上计算r1 ⋈ temp2
当r2中有相对很少的元组对连接有用时，这个策略你优势明显。
利用并行性的连接策略
一个连接：r1 ⋈ r2 ⋈ r3 ⋈ r4 .
- 将r1送到S2并在S2上计算r1 ⋈ r2，同时将r3送到S4并在S4上计算r3 ⋈ r4.在r1⋈r2计算过程中，站点S2就可以把已经计算出的元组送到S1，而不需要等到整个连接计算完。同样地S4也一样。
- 一旦(r1⋈r2)和(r3⋈r4)的元组到达S1，就可以计算(r1⋈r2)⋈(r3⋈r4)
异构分布式数据库
操纵位于异构分布式数据库中的信息需要在已有数据库系统上增加一个软件层。此软件层称为多数据库系统。这些局部的数据库系统可能采用不同的逻辑模型以及数据定义语言和操纵语言，可能在并发控制和事务管理机制上存在差别。多数据库系统构造了逻辑数据库集成的一个虚拟。
将异构系统完全集成为一个同构分布式数据库比较困难：
- 技术上的困难
- 组织上的困难
由于这些原因，多数据库系统带来的显著优势超出了开销。
数据的统一视图
由于多数据库系统应该要虚拟单一的、集成的数据库系统，必须使用一个公共数据模型。我们一般选择关系模型，并将SQL作为公共查询语言。
模式集成不是数据定义语言之间简单的直接转换。同一属性名可能出现不同的局部数据库但具有不同的意义，某一系统的数据类型可能在另一个系统不被支持，数据的物理表示不同，浮点表示不同，语义层不同。
这些区别必须正确记录到公共全局概念模式中，必须提供转换函数。
查询处理
一些问题：
- 给定一个在全局模式上的查询，该查询需要翻译成每个运行查询的站点上的本地模式上的查询。查询结果必须重新翻译回全局模式。
通过对每个数据源写包装可以简化任务，包装提供一种全局模式下的本地数据的视图。包装也将全局模式的查询翻译成本地模式的查询，并将执行结果翻译返回到全局模式。包装可以由个别站点提供，也可以分开作为多数据库系统的一部分。甚至用于非关系型数据源提供关系视图，如网页、平面文件、层次和网状数据库以及目录系统。
- 有些数据源可能只提供有限的查询能力
- 回答一个查询需要访问多个站点
- 在异构数据库中的全局查询优化困难
中介系统是指集成多个异构数据源，提供数据的一个集成的全局视图，并提供在全局视图上的查询工具的系统。不会干扰事务处理。
目录系统
目录是关于一些类别的对象的信息列表。视为一个特殊形式的数据库，其中信息按照一种分层的形式组织，这种分层形式类型于文件系统中文件组织方式。目录可以分布到多个站点，提供对各个站点的自治。包含到其他目录的指点，有助于建立集成视图，借此查询发送到单个目录，在所有相关目录中透明地执行。
目录访问协议
轻便目录访问协议（LDAP）使用最广泛。
为何使用特殊的协议用于访问目录信息：
- 目录访问协议是迎合有限类型的数据访问的简化协议。它们与数据库访问协议并行发张。
- 目录系统用一种分级的方式提供一个简单的命名对象的机制，可用于分布式目录系统指示每个目录服务器上存储了何种信息。
目录也可以用于验证用户身份。
LDAP
通常目录系统作为一个或多个服务器实现，它可以为多个客户服务。客户通过使用由目录系统定义的应用程序接口与目录服务器通信。目录访问协议也定义了数据模型和访问控制。
LDAP数据模型
在LOAP目录上存储的是类似于对象的条目。每个条目必须有可区别名称，它唯一地标识了这个条目。DN是由相对可区别名称（RDN）序列组成。
条目也有属性，LDAP提供二进制、字符串和时间类型，还有为电话号码设计的tel类型，为地址设计的PostalAddress类型。与关系模型中属性不同，这里属性默认为多值。
LDAP允许定义带有属性名和类型的对象类，可以使用继承，可以指定条目属于一个或多个对象类。定义条目所属的一个最明确对象类是不必要的。
条目按照它们可区别名称组织成一个目录信息树。树中叶级条目通常表示特定对象。一个结点的孩子具有一个包含父结点所有RDN的DN，和一个或多个附加的RDN。
条目的可区别名称不必存储到条目中；系统可遍历条目的DIT，收集RDN=value成分以产生完整的DN的方式来产生一个条目的DN。
条目可以有多个DN。
数据操纵
LDAP定义了一个用于执行数据的定义和操纵的网络协议。LDAP的用户可以使用应用程序设计接口或者使用工具来执行数据的定义和操纵。LDAP也定义了一种LDAP数据交换格式（LDIF），用于存储和交换信息。
LDAP查询机制简单，只有选择和投影，而没有连接。查询必须指定以下几点：
- 一个基（即DIT的一个结点），通过给出其可区别名称。
- 一个搜索条件，可以是各个属性上的条件的布尔组合。支持相等条件、通配符匹配和近似相等条件。
- 一个范围，可以就是基或基和它的孩子
- 要返回的属性
- 结果和资源消耗的数目限制
分布式目录树
一个组织机构信息可以分成多个DIT，其中每个DIT存储某些条目的信息。DIT的前缀是RDN=value对的序列，可用于识别DIT存储了什么信息，这些对连接到其余的由遍历从条目到根结点的路径所产生的可区别名称上。
在DIT中的结点可能包含指向另一个结点的引用。