目录数据库是一种专用的数据库，其中以层次化的组织方式存 储信息集合并且每条信息具有相同或者类似的属性。目录数据库通 常可以用于名称服务、用户注册、白页(White Page)查找等应用中。 例如，在电话目录数据库中包括有一系列按照字母顺序的名称(人 名或者组织名称)，每个名称项中均具有地址、电话号码等属性。
对于目录数据库来说，其设计是面向阅读的。因此，目录数据 库在查找操作方面通常具有较高的吞吐量和较低的延迟等待。而且， 为了提高目录数据库查找操作的性能，还开发出各种技术来对查找 操作的执行进行改进。相对于目录数据库的查找操作而言，目录数 据库的修改条目名称操作则具有较差的性能。虽然对于目录数据库 的主要操作是查找操作，然而在某些应用(例如DNS路由、用户鉴 权、电信用户管理系统等)中，对目录数据库执行修改条目名称操 作的比例会高达20％。
在普通目录服务器中，修改条目名称操作的等待延迟要比查找 操作的等待延迟高几十倍，而且由于修改条目名称操作的较差性能 使得吞吐量显著下降。因此，虽然在目录服务器中执行修改条目名 称操作的比例较低，但是其性能对于服务器的性能会产生巨大的负 面影响。
轻型目录访问协议(LDAP)是一种用于访问在线目录服务的协 议。在LDAP/X.500specification中定义了如下的操作：
·Search：{BaseDN，Scope，Filter，Attributes}
·ModRDN：{Entry，NewRDN，DelOldRDN，NewSuperior}
·Add/Delete/Update Attributes
其中，ModRDN(修改相对识别名)操作包括对RDN重新命名的操 作和迁移操作。关于LDAP/X.500specification的更多内容可以参见 因特网工程任务组(IETF)定义的、名为“Lightweight Directory Access Protocol(v3)”的RFC 2251。在本文中将该规范通过参考引入于 此。
LDAP目录可以使用各种存储机制来实现，例如通过平坦文件、 b-tree包、关系数据库等来实现。上述大多数的机制利用了识别名到 标识的(DN2ID)、标识到条目(ID2ENTRY)、属性/索引等设计 来将分层化数据模型转换到类关系数据模型。正是由于这些设计的 缘故，使得修改条目名称操作变得异常缓慢，特别是对目录条目的 识别名进行的修改(ModRDN)。
表1-1
  识别名到标识(DN2ID)   (本节点)DN-＞ID   (下一级节点)DN-＞ID列表(IDL)   (子树节点)DN-＞ID列表(IDL)
表1-2
索引(INDEX) 值(Value) ID列表(IDL)
表1-3
  标识到条目(ID2ENTRY)   ID   条目(ENTRY)
表1-1、1-2、1-3示意性的示出了OpenLDAP BDB的实现方式。 在采用DN2ID设计的OpenLDAP BDB实现中，Search操作仅需要 在DN2ID表中进行一次DB Read(DB读取)。而在ModRDN操作 中，对子树重新命名操作而言，要对DN2ID表和ID2ENTRY表进行 n次的DB Write(DB写)；对于子树迁移操作而言，要对DN2ID 表进行p+q+n次的DB Write并且对ID2ENTRY表进行n次的DB Write，其中n表示所涉及的子树条目的个数，p、q分别表示迁移前 和迁移后祖先条目的个数。
表2-1
  相对识别名到标识(RDN2ID)   相对识别名(RDN)   父节点(Parent)
表2-2
 索引(INDEX)  值(Value)  ID列表(IDL)
表2-3
  标识到条目(ID2ENTRY)   ID   条目(ENTRY)
表2-1、2-2、2-3示意性的示出了OpenLDAP HDB的实现方式。 在OpenLDAP HDB的实现方式中，针对ModRDN操作进行了设计 上的改进，使得对子树重新命名操作而言，仅需要对RDN2ID表进 行一次DB Write和对ID2ENTRY表进行n次DB Write；对子树迁移 操作而言，仅需要对RDN2ID表进行一次DB Write和对ID2ENTRY 表进行n次DB Write。然而，这种有利于修改条目名称操作的设计 使得Search操作的性能大幅下降，需要O(log2N)的复杂度来定位基 准DN的DN2ID表，还进行昂贵的对于子树ID列表的递归查找。
可见，在通常的目录数据库中，修改条目名称操作的性能要远 逊于查找操作的性能，修改条目名称操作较低的工作效率和较差的 性能在某些应用中会显著影响整个目录服务器的工作效率和运转性 能。而在针对修改条目名称操作进行改进的OpenLDAP实现设计中， 会显著影响查找操作的性能，从而也不能获得优良的目录服务器的 工作效率和运转性能。

为了解决现有技术中存在的问题，本发明提出一种能够提高目 录服务器中修改条目名称操作的性能的机制，其中允许对一段预定 时间内的所有修改条目名称操作进行异步地处理，并且不对查找操 作的性能产生影响，从而提高整个目录服务器的工作效率和运转性 能。
根据本发明的第一方面，提供一种用于在目录数据库中执行修改 条目名称操作的方法。该方法包括以下步骤：响应于修改条目名称 操作请求，依据修改条目名称操作请求修改条目映射信息，其中每 条条目映射信息用于表示修改前条目名称信息和修改后条目名称信 息的对应关系；当满足预先设定的对目录数据库进行更新的条件时， 依据各条条目映射信息异步地执行所对应的条目名称修改操作。
根据本发明的第二方面，提供一种目录服务器。一种目录服务器 包括：目录数据库存储装置，用于存储目录数据库；操作处理装置， 对目录数据库的操作请求进行处理；条目映射信息存储装置，用于 存储条目映射信息，其中每条条目映射信息用于表示修改前条目名 称信息和修改后条目名称信息的对应关系；条目映射维护与处理装 置，用于响应于修改条目名称操作请求，依据修改条目名称操作请 求修改条目映射信息，以及用于当满足预先设定的对目录数据库进 行更新的条件时，向操作处理装置提供条目映射信息，以便依据各 条条目映射信息异步地执行所对应的条目名称修改操作。
根据本发明的第三方面，提供一种计算机程序产品，用于执行根 据本发明的用于在目录数据库中执行修改条目名称操作的方法。
通过本发明，目录服务器在接收到用户的修改条目名称操作请 求时，并不实时地执行修改条目名称的操作，而是暂时记录相应的 条目映射信息，并且异步地对目录数据库执行实际地多次修改条目 名称操作。这样，可以利用特定时段，例如目录服务器工作负载较 低的时段等，对修改条目名称操作进行集中的执行。本发明并未旨 在改进每次修改条目名称操作的性能，而是通过异步地并且集中地 执行多个修改条目名称操作，提高整个目录数据库工作效率和运转 性能。
结合附图阅读本发明实施方式的详细描述后，本发明的其它特 点和优点将变得更加清楚。

为了对本发明实施例的特征和优点进行详细说明，将参照以下 附图。如果可能的话，在附图和描述中使用相同或者类似的参考标 号以指代相同或者类似的部分。其中：
图1示出了根据本发明一个实施例的对目录数据库操作进行处 理的流程图；
图2示意性示出了一个目录数据库的示例；
图3示出了根据本发明一个实施例的对目录数据库的重命名操 作进行处理的流程图；
图4示出了根据本发明一个实施例的对目录数据库的迁移操作 进行处理的流程图；
图5示出了根据本发明一个实施例的对目录数据库的查找操作 进行处理的流程图，其中图5A示出了根据本发明的实施例利用条目 映射数据对查找操作请求进行处理的过程，图5B示出了执行查找操 作的过程；
图6示意性示出了根据本发明一个实施例的目录服务器的框图；
图7示意性示出了其中可以实现根据本发明的实施例的计算设 备。

以下根据附图详细说明本发明的实施例。
图1示出了根据本发明一个实施例的对目录数据库操作进行处 理的流程图。
如图1所示，在步骤S100中，该流程开始。
在步骤S102中，目录服务器接收对目录数据库的操作请求。例 如，可以通过目录服务器的网络接口通过网络接收来自用户的操作 请求。
根据LDAP/X.500specification，所请求的操作可能包括：查找 操作Search：{BaseDN，Scope，Filter，Attributes}；修改条目名称操作 ModRDN：{Entry，NewRDN，DelOldRDN，NewSuperior}；对于条目属 性的操作例如，添加/删除/更新属性等。由于对于条目属性的操作可 以分解为查找操作和对于查找结果条目属性的操作，因此对于条目 属性的操作的处理可以看到对于查找操作的处理。在本文中不再对 其进行专门的描述。
由此，在步骤S102中，接收对目录数据库的操作请求，并确定 操作请求的类型。当接收到的操作请求为修改条目名称操作请求时， 该处理继续执行步骤S104至S110，对修改条目名称操作进行处理； 当接收到的操作请求为查找操作请求时，该处理继续执行步骤S112 至S118，对查找操作进行处理。
在步骤S104中，根据修改条目名称操作请求的内容修改条目映 射数据，例如条目映射表(在下文中以条目映射表为例进行说明)。 该条目映射表记录有修改前旧标识名和修改后的新标识名的映射信 息。可以理解，可以采用各种不同的形式来记录修改前后条目映射 的信息。目录服务器在接收到修改条目名称操作请求时，并不直接 同步地更新目录数据库，而是将修改前后条目映射的信息以某种形 式保存起来。
表3
 修改后名称   修改前名称   标志  (修改前DN或者RDN)   (修改前DN)   (操作性质、   当前状态等)
表3示出一种示例性的条目映射表。该条目映射表至少包括表 示执行修改条目名称操作前条目标识名信息的修改前名称域和表示 执行修改条目名称操作后条目标识名信息的修改后名称域。可选地， 为了易于对该条目映射表进行操作和维护，该条目映射表还可以包 括标志域，用于对相应记录所表示的修改条目名称操作的性质(例 如，该修改条目名称操作为重命名操作/迁移操作)和该记录的状态 进行标识。
在步骤S106中，确定当前是否需要根据条目映射数据修改目录 数据库。取决于各种不同的应用，可以设定具体修改条件来执行上 述确定。例如，可以预先确定某一时段来作为修改条件，比如在晚 间12:00以后进行修改，或者可以预先确定某一修改工作量阈值来 作为修改条件，当达到该修改工作量阈值时，则执行对目录数据库 的修改。
特别地，根据本发明的一种有利的实现方式，可以设定如果条 目映射表中已经存在与当前请求的修改条目名称操作所涉及的条目 相对应的记录，则确定需要根据当前条目映射数据修改目录数据库。 例如，当条目映射表中已经一条记录表示对某一条目进行迁移操作， 当前又请求对同一条目或者该条目的祖先节点或者该条目的子孙节 点进行重命名，则此时可确定当前需要强制依据条目映射表中现有 的记录对目录数据库进行更新，从而删除已更新的条目。这样能够 有效地降低利用条目映射表对目录数据库进行查找操作和利用条目 映射表对目录数据库进行异步更新的复杂度。需要指出的是，由于 在目录数据库中涉及同一条目的多次修改条目名称操作发生的概率 很低，因此这样的对目录数据库进行异步修改的条件，并不会使目 录服务器在短时间内频繁对目录数据库进行更新，从而也不会造成 目录服务器工作效率的下降。
如果确定结果为“否”，则返回步骤S 102，继续接收对于目录 数据库的操作请求。如果确定结果为“是”，则该处理继续执行步 骤S108。
在步骤S108中，按照条目映射表中的记录来修改该目录数据库。 此时，条目映射表中可以保存有多条记录，目录服务器根据目录数 据库的实现方式来集中修改相应的条目。
在步骤S110中，删除条目映射表中已经执行过目录数据库修改 条目名称操作的相应映射记录。
在步骤S112中，根据查找操作请求的内容搜索条目映射表。
在步骤S114中，确定是否搜索到与该查找请求相应的映射记录。
如果确定结果为“是”，则执行步骤S 116；如果确定结果为“否”， 则执行步骤S118。
在步骤S116中，参照条目映射表的相应记录查找目录数据库。 由于在条目映射表中存在与该查找操作请求相应的映射记录，也就 是说，之前曾请求对当前查找的条目进行修改条目名称操作，而此 时目录数据库还未按照该请求执行修改条目名称操作。因此，按照 条目映射表的记录可以找到修改前的条目识别名，从而完成对目录 数据库的查找。
在步骤S118中，按照所接收的查找操作请求直接查找目录数据 库。
在步骤S120中，确定处理是否结束。
如果确定结果为“否”，处理返回步骤S102，继续接收对目录 数据库的操作请求；如果确定结果为“是”，则该处理继续执行步 骤S122。
在步骤S122中，该处理结束。
以下结合具体的示例，进一步详细描述根据本发明实施例的对目 录数据库的两种修改条目名称操作(即重命名操作、迁移操作)和 查找操作所进行的处理。
图2示意性示出了一个目录数据库的示例。其中，利用层次化的 结构图描述了该目录数据库所记录的某公司的组织结构。
如图2所示，该目录数据分为六个层次，每一个节点代表目录数 据库中的一个条目，在节点中示出了该条目的相对识别名RDN和识 别名DN。节点E200为根条目，其下存在多个节点，即条目E201、 E202、E203等，它们每个代表不同的国家(C)，如E202的相对识 别名为C＝CN，而其识别名由于其为根条目的孩子节点所以也为 C＝CN。节点E201具有多个子节点，即条目E204、E205等，它们 每个代表不同的组织(O)，如条目E204的相对识别名为O＝A，而 其识别名为O＝A，C＝CN。类似地，节点E204具有多个子节点，即 条目E206、E207，E208等，它们每个代表不同的部门(D)；节点 E207具有多个子节点，即条目E210、E211、E212等，它们每个代 表不同的组别(G)；节点E211具有多个子节点，即条目E213、E214、 E215等，它们每个代表不同的身份(ID)。节点E214具有一个子 节点，即E216，其代表一个用户身份(UID)。
图3示出了根据本发明一个实施例的目录数据库的重命名操作 进行处理的流程图。其中，作为一个示例，目录数据库采用了 OpenLDAP BDB的实现方式(参见表1-1、1-2、1-3)。
如图3所示，在步骤S300中，用户需要对图2所示的目录数据 库进行重命名的修改条目名称操作，例如将条目E207的相对识别名 从“D＝市场”改为“D＝市场1”。用户输入包括NewRDN和DelOldRDN 等参数的重命名操作请求，则该处理开始。
在步骤S302中，在DN2ID表中和例如表3的条目映射表的修改 后名称域中搜索重命名后的DN。这样做的原因在于，在目录数据库 中不能存在DN相同的条目。在同步执行修改条目名称操作的现有 技术中，只需要对DN2ID表进行搜索；而在根据本发明的实施例中， 由于条目映射表中保存有与执行过修改条目名称操作的条目有关的 信息，因此也需要搜索条目映射表以确定重命名后条目DN的有效 性。需要指出的是，如果条目映射表针对重命名操作在修改后名称 域中仅存储修改后的RDN(如表4所示)，则还需要恢复包括该修 改后RDN的修改后的DN来进行上述搜索处理。
在步骤S306中，确定是否搜索到相同的DN。
如果确定结果为“是”，则该处理继续执行S304；如果确定结 果为“否”，则该处理继续执行S308。
在步骤S304中，返回出错信息，例如通过目录服务器的网络接 口经由网络向进行该修改请求的用户发送消息的方式来实现。然后， 处理继续执行步骤S318。
在步骤S308中，在条目映射表的修改前名称域中搜索请求重名 名前的DN(原DN)。
在步骤S310中，确定是否搜索到相同的DN。
如果确定结果为“是”，意味着之前已经请求对该请求重命名的 条目进行修改条目名称操作，虽然此时尚未对目录数据库实际执行 该修改条目名称操作，则该处理继续执行步骤S304，返回出错信息。 如果确定结果为“否“，意味着之前未曾对该请求重命名的条目进 行修改条目名称操作，则该处理继续执行步骤S312。
在步骤S312中，向条目映射表添加新的映射记录。例如，如表 4所示，此时可以向条目映射表添加如下新的映射记录。
表4
  修改后名称   修改前名称   标志   D＝市场1   D＝市场，O＝A，C＝CN   0   …   …   …
在表4中，修改后名称域仅记录了重命名后的RDN，并且可选 地，将标志域设置成“0”来表示该条记录对应于重命名操作。在其 他实施例中，也可以在修改后名称域中记录重命名后的DN，来表示 执行修改条目名称操作前条目标识名信息。
在步骤S314中，返回修改成功信息，例如通过目录服务器的网 络接口经由网络向进行该修改请求的用户发送消息的方式来实现。
在步骤S316中，返回修改成功信息，例如通过目录服务器的网 络接口经由网络向进行该修改请求的用户发送消息的方式来实现。
在步骤S318中，该处理结束。
图4示出了根据本发明一个实施例的对目录数据库的迁移操作 进行处理的流程图。其中，作为一个示例，目录数据库采用了 OpenLDAP BDB的实现方式(参见表1-1、1-2、1-3)。
如图4所示，在步骤S400中，用户需要对图2所示的目录数据 库进行迁移的修改条目名称操作，例如将条目E214迁移到新的父节 点E210。用户输入包括NewSuperior等参数的迁移操作请求，则该 处理开始。
在步骤S402中，在DN2ID表中和例如表3的条目映射表的修改 后名称域中搜索迁移后的DN。这样做的原因在于，在目录数据库中 不能存在DN相同的条目。在同步执行修改条目名称操作的现有技 术中，只需要对DN2ID表进行搜索；而在根据本发明的实施例中， 由于条目映射表中保存有与执行过修改条目名称操作的条目有关的 信息，因此也需要搜索条目映射表以确定迁移后条目DN的有效性。 需要指出的是，如果条目映射表针对重命名操作在修改后名称域中 仅存储修改后的RDN(如表4所示)，则还需要恢复包括该修改后 RDN的修改后的DN来进行上述搜索处理。
在步骤S406中，确定是否搜索到相同的DN。
如果确定结果为“是”，则该处理继续执行S404；如果确定结 果为“否”，则该处理继续执行S408。
在步骤S404中，返回出错信息，例如通过目录服务器的网络接 口经由网络向进行该修改请求的用户发送消息的方式来实现。然后， 处理继续执行步骤S420。
在步骤S408中，在条目映射表的修改前名称域中搜索请求迁移 前的DN(原DN)。类似地，如果条目映射表针对重命名操作在修 改后名称域中仅存储修改后的RDN(如表4所示)，则还需要恢复 包括该修改后RDN的修改后的DN来进行上述搜索处理。
在步骤S410中，确定是否搜索到相同的DN。
如果确定结果为“是”，意味着之前已经请求对该请求迁移的条 目进行修改条目名称操作，虽然此时尚未对目录数据库实际执行该 修改条目名称操作，则该处理继续执行步骤S404，返回出错信息。 如果确定结果为“否”，意味着之前未曾对该请求迁移的条目进行 修改条目名称操作，则该处理继续执行步骤S412。
在步骤S412中，向条目映射表添加新的映射记录。例如，如表 5所示，此时可以向条目映射表添加如下新的映射记录。
表5
修改后名称     修改前名称   标志 ID＝22，G＝1，D＝市场，O＝A，C＝CN ID＝22，G＝2，D＝市场，O＝A，C＝CN 1 …     …   …
其中，可选地将标志域设置成“1”来表示该条记录对应于迁移 操作。
在步骤S416中，返回修改成功信息，例如通过目录服务器的网 络接口经由网络向进行该修改请求的用户发送消息的方式来实现。
在步骤S418中，该处理结束。
需要指出的是，图3和图4所示的流程是基于一种特定条目映射 表配置，正如结合图1中描述的条目映射表那样。在这种条目映射 表配置中，设定了如果条目映射表中已经存在与当前请求的修改条 目名称操作所涉及的条目相对应的记录，则确定需要根据当前条目 映射数据修改目录数据库。通过这样的条目映射表配置，能够显著 降低利用条目映射表对目录数据库进行查找操作和利用条目映射表 对目录数据库进行异步更新的复杂度。当然，可以理解，如果不采 用这种特定的条目映射表配置，相应的对重命名操作和迁移操作的 处理将会变得比图3和图4所示流程更加复杂。
图5示出了根据本发明一个实施例的对目录数据库的查找操作 进行处理的流程图。其中，图5A示出了根据本发明的实施例利用条 目映射数据对查找操作请求进行处理的过程；图5B示出了基于 OpenLDAP BDB的实现方式执行查找操作的过程。
如图5所示，在步骤S500中，用户需要对图2的目录数据库进 行查找操作。在此之前，已经对该目录数据库进行了修改条目名称 操作，但尚未依据条目映射表对目录数据库进行更新。用户输入包 括参数BaseDN，Filter，Scope，Attributes等参数的查找操作，则该处 理开始。
步骤S502至步骤S510用于对处理所请求查找的BaseDN之前曾 被请求过重命名操作的情况。
在步骤S502中，在条目映射表修改后名称域中，针对重命名操 作的记录搜索输入BaseDN的所有组成，以便确定之前是否曾对该 BaseDN中的任何组成进行过重命名操作。
在步骤S506中，确定是否搜索到相应记录。
如果确定结果为“是”，意味着之前曾请求对该BaseDN中的一 个或多个组件进行重命名操作而此时尚未对目录数据库实际执行该 重命名操作，则该处理继续执行步骤S508。如果确定结果为“否”， 意味着之前未曾请求对该BaseDN中的一个或多个组件进行重命名 操作，则该处理继续执行步骤S512。
在步骤S508中，确定所搜索到的记录是否锁定。例如，在结合 表6所描述的示例中，记录当标志域的值非“2”时，即可确定该记 录未锁定。
如果确定结果为“是”，则该处理执行步骤S504。如果确定结 果“否”，则该处理执行步骤S510。
在步骤S504中，由于所搜索到的记录由于正在进行数据库更新 而被锁定，因此拒绝执行查找并返回错误信息，例如通过目录服务 器的网络接口经由网络向进行该修改请求的用户发送消息的方式来 实现。
在步骤S510中，按照条目映射表修改前名称域来生成新的 BaseDN。也即将查找请求中的BaseDN的对应的组成映射为搜索到 记录的映射表修改前名称域的内容。这样，就能在尚未针对这些重 命名操作进行相应更新的目录数据库中查找到所需的条目。
在步骤S512中，在条目映射表修改后名称域中搜索该查找请求 中BaseDN，以便确定是否存在之前曾进行过迁移操作的条目与所请 求的BaseDN相匹配。
在步骤S514中，确定是否搜索到记录。
如果确定结果为“否”，意味着在条目映射表中没有与所查找 的条目相关的记录，则该处理转入A处继续执行。如果确定结果为 “是”，意味着之前曾请求对该请求查找的BaseDN或其祖先节点(条 目)进行迁移操作而此时尚未对目录数据库实际执行该迁移操作。
在步骤S516中，确定所搜索到的记录是否锁定。
如果确定结果为“是”，则该处理执行步骤S504。如果确定结 果“否”，则该处理执行步骤S518或S520。
当条目映射表修改后名称域中的标识名与该查找请求中的 BaseDN部分匹配(即BaseDN与该标识名从右至左的一个子串相同) 时，意味着之前曾请求对该查找操作的BaseDN的祖先节点(条目) 进行迁移操作，则在步骤S518中，按照条目映射表的修改前名称域 中的标识名添加新的BaseDN，即此时执行查找操作的BaseDN的值 包括：原查找操作请求中的BaseDN和条目映射表的修改前名称域中 的标识名。从而，保证在执行查找操作时能够同时对该相应条目迁 移前后的子树均进行查找。
当条目映射表修改后名称域中的标识名与该查找请求中的 BaseDN完全匹配(即该标识名与该BaseDN相同或者该标识名与该 BaseDN从右至左的一个子串相同)时，意味着之前曾请求对该请求 查找的BaseDN节点(条目)进行迁移操作或者之前曾请求对该请求 查找的BaseDN的子孙节点(条目)进行迁移操作，则在步骤S520 中，按照条目映射表的修改前名称域中的标识名更新将用于查找操 作的BaseDN。即若此时该标识名与该BaseDN相同，则将查找操作 的BaseDN的值更新为条目映射表的修改前名称域中的标识名；若该 标识名与该BaseDN从右至左的一个子串相同，则将查找操作的 BaseDN中的相应子串更新为条目映射表的修改前名称域中的标识 名。从而，能够在执行查找操作时对该相应条目迁移前的子树进行 查找。
在步骤S518和S520之后，则该处理转入A处继续执行。
举例来说，若当前条目映射表如表4所示，查找请求的参数为： BaseDN：“G＝2，D＝市场1，O＝A，C＝CN”；Filter：略；Scope：子树 搜索；Attributes：未指定，则依据图5A所示流程处理后，生成的新 BaseDN为“G＝2，D＝市场，O＝A，C＝CN”。
若当前条目映射表如表5所示，查找请求的参数为：BaseDN： “G＝1，D＝市场，O＝A，C＝CN”；Filter：略；Scope：子树搜索；Attributes： 未指定，则依据图5A所示流程处理后，生成的新BaseDN为：“G＝1，D＝ 市场，O＝A，C＝CN”和“ID＝22，G＝2，D＝市场，O＝A，C＝CN”(当前记录 部分匹配)；查找请求的参数为：BaseDN：“ID＝22，G＝1，D＝市 场，O＝A，C＝CN”；Filter：略；Scope：子树搜索；Attributes：未指定， 则依据图5A所示流程处理后，生成的新BaseDN为：“ID＝22，G＝2，D＝ 市场，O＝A，C＝CN”(当前记录完全匹配)；查找请求的参数为： BaseDN：“ID221，ID＝22，G＝1，D＝市场，O＝A，C＝CN”；Filter：略；Scope： 子树搜索；Attributes：未指定，则依据图5A所示流程处理后，生成 的新BaseDN为：“ID＝221，ID＝22，G＝2，D＝市场，O＝A，C＝CN”(当前 记录完全匹配)。
标识A之后的处理过程在图5B中示出，其中以OpenLDAP BDB 的实现方式为例描述了依据经过处理的BaseDN执行查找操作的过 程。为了清楚和简略起见，在以下描述中所称的BaseDN是经过图 5A的流程所处理后的BaseDN，也即在步骤S510、步骤S518、步骤 S520所更新的新BaseDN，以及步骤S514判断为否时的输入查找操 作的原BaseDN。
如图5B所示，在步骤S522中，在DN2ID表中找到对应的BaseDN 的IDL 1。
在步骤S524中，应用过滤器获得IDL2。
在步骤S526中，将IDL1和IDL2进行“与”操作，以获得最终 的IDL。
在步骤S528中，确定最终IDL是否为空。
如果确定结果为“是”，则该处理继续执行步骤S534。如果确 定结果为“否”，则该处理继续执行步骤S530至S532。
在步骤S534中，返回搜索结果为空，例如通过目录服务器的网 络接口经由网络向进行该修改请求的用户发送消息的方式来实现。
在步骤S530中，在ID2ENTRY表中依据IDL获得所要查找的 最终条目。
在步骤S532中，返回最终条目的所需属性，例如通过目录服务 器的网络接口经由网络向进行该修改请求的用户发送消息的方式来 实现。
在步骤S536中，该处理结束。
需要指出的是，图3至图5是针对前述的条目映射表的具体配 置而设计的处理流程，因此并不是涵盖本发明所有实施例的通用处 理流程。本领域的技术人员可以依据具体需求设计出表示条目映射 信息的其他不同的配置形式，并基于这些表示条目映射信息的不同 配置形式对图3至图5中的处理步骤进行修改、增加或者省略。
此外，图3至图5的处理流程是基于目录数据库OpenLDAP BDB 的实现方式的。但是，可以理解，本发明的实现并不依赖于目录数 据库的具体实现方式，也就是说，本发明的各种实施例能够有效地 适用于各种目录数据库实现方式，提高目录数据库修改条目名称操 作的性能。
图6示意性示出了根据本发明一个实施例的目录服务器的框图。
在图6中，参考标号600表示根据本发明一个实施例的目录服 务器；参考标号602表示用于存储目录数据库的目录数据库存储装 置；参考标号604表示用于对目录数据库的操作请求进行处理的操 作处理装置；参考标号606表示用于与网络进行通信以便向用户发 送或者从用户处接收操作请求的网络接口；参考标号608表示条目 映射维护与处理装置；参考标号610表示用于存储修改条目名称操 作前后条目映射信息的条目映射数据存储装置。
如图6所示，目录服务器600接收对目录数据库的操作请求。 例如，可以目录服务器600可以通过网络接口606通过网络接收来 自用户的操作请求。
当网络接口606接收到的操作请求为修改条目名称操作请求时， 条目映射维护与处理装置608根据修改条目名称操作请求的内容修 改存储在条目映射数据存储装置610中的条目映射数据。特别地， 在一个示例中，该条目映射数据存储装置610可以存储有如参考表3 所描述的条目映射表。在修改条目名称操作请求为重命名操作请求 的情况下，条目映射维护与处理装置608例如可以执行如图3所示 的处理流程，来更新条目映射数据存储装置610中的条目映射表。 在修改条目名称操作请求为迁移操作请求的情况下，条目映射维护 与处理装置608例如可以执行如图4所示的处理流程，来更新条目 映射数据存储装置610中的条目映射表。
条目映射维护与处理装置608依据预先设定的修改条件确定当 前是否需要根据条目映射数据库存储装置610中的条目映射数据来 修改存储在目录数据库存储装置602中的目录数据库。取决于各种 不同的应用，可以设定具体条件来执行上述确定。例如，可以预先 确定某一时段，比如在晚间12:00以后进行修改，或者可以预先确 定某一修改工作量阈值，当达到该修改工作量阈值时，则执行对目 录数据库的修改。特别地，根据本发明的一种有利的实现方式，可 以设定如果条目映射表中已经存在与当前请求的修改条目名称操作 所涉及的条目相对应的记录，则确定需要根据当前条目映射数据修 改目录数据库。
如果条目映射维护与处理装置608确定满足预先确定的修改条 件，则条目映射数据存储装置610中的条目映射数据提供给操作处 理装置604。该操作处理装置604根据目录数据库的实现方式来集中 修改相应的条目。修改执行完毕后，条目映射维护与处理装置608 删除条目映射数据存储装置610中存储的相应数据。
当网络接口606接收到的操作请求为查找操作请求时，条目映射 维护与处理装置608根据查找操作请求的内容搜索条目映射数据存 储装置610中存储的条目映射数据，并且确定是否搜索到与该查找 请求相应的映射数据。如果搜索到确定与该查找请求相应的映射数 据，则将其提供给操作处理装置604。操作处理装置604参照条目映 射数据的相应数据查找目录数据库。特别地，在一个示例中，条目 映射维护与处理装置608例如可以依据图5A所示的流程依据条目映 射数据存储装置610中所存储的条目映射数据确定新的查找操作参 数BaseDN，然后将其提供给操作处理装置604。操作处理装置604 例如可以根据图5B的处理流程在目录数据库存储装置602中的目录 数据库中找到相应查找结果，并通过网络接口606将该查找结果返 回给用户。
图7示意性示出了可以实现根据本发明的实施例的计算设备。
图7中所示的计算机系统包括CPU(中央处理单元)701、RAM(随 机存取存储器)702、ROM(只读存储器)703、系统总线704，硬盘控 制器705、键盘控制器706、串行接口控制器707、并行接口控制器 708、显示器控制器709、硬盘710、键盘711、串行外部设备712、 并行外部设备713和显示器714。在这些部件中，与系统总线704 相连的有CPU 701、RAM 702、ROM 703、硬盘控制器705、键盘控 制器706，串行接口控制器707，并行接口控制器708和显示器控制 器709。硬盘710与硬盘控制器705相连，键盘711与键盘控制器 706相连，串行外部设备712与串行接口控制器707相连，并行外部 设备713与并行接口控制器708相连，以及显示器714与显示器控 制器709相连。
图7中每个部件的功能在本技术领域内都是众所周知的，并且图 7所示的结构也是常规的。这种结构不仅用于个人计算机，而且用于 手持设备，如Palm PC、PDA(个人数据助理)、移动电话等等。在 不同的应用中，例如用于实现包含有根据本发明的客户端模块的用 户终端或者包含有根据本发明的网络应用服务器的服务器主机时， 可以向图7中所示的结构添加某些部件，或者图7中的某些部件可 以被省略。图7中所示的整个系统由通常作为软件存储在硬盘710 中、或者存储在EPROM或者其它非易失性存储器中的计算机可读 指令控制。软件也可从网络(图中未示出)下载。或者存储在硬盘 710中，或者从网络下载的软件可被加载到RAM 702中，并由CPU 701执行，以便完成由软件确定的功能。
尽管图7中描述的计算机系统能够支持根据本发明的提供网络 内容以供脱机使用的方案，但是该计算机系统只是计算机系统的一 个例子。本领域的熟练技术人员可以理解，许多其它计算机系统设 计也能实现本发明的实施例。
本发明还可以实现为例如由图7所示计算机系统所使用的计算 机程序产品，其可以包含有用于实现根据本发明的提供网络内容以 供脱机使用的网络应用服务器的代码；其还可以包含有用于实现根 据本发明的用于获取网络内容以供脱机使用的客户端模块的代码。 在使用之前，可以把代码存储在其它计算机系统的存储器中，例如， 存储在硬盘或诸如光盘或软盘的可移动的存储器中，或者经由因特 网或其它计算机网络进行下载。
虽然结合附图描述了本发明的实施方式，但是本领域技术人员可 以在所附权利要求的范围内做出各种变形或修改。