JP2003036190A - アンドゥ処理システム及びアンドゥ処理方法 - Google Patents

Abstract

(57)【要約】 【課題】同じ主キー、又は、ディレクトリに対して同じ
エントリ又は属性に対する変更が複数存在しても、最初
のデータのみを保存するため、差分データを節約するこ
とができる。しかも、データの更新時刻を必要としない
ので処理時間を短縮することができ、他のクライアント
がいつでもデータを参照及び更新することができるよう
にする。 【解決手段】クライアントが使用するデータが表形式で
格納されるリレーショナルデータベースと、差分情報を
格納するアンドゥ情報格納部と、アンドゥ可能か否かの
フラグを格納するアンドゥモード格納部と、データ処理
を実行するデータ処理部とを有し、差分情報は、表が定
義された時点で作成されて格納され、データ処理部は、
クライアントからのコマンドが変更処理であり、かつ、
アンドゥ可能である場合、差分情報を変更して表を更新
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、アンドゥ処理シス
テム及びアンドゥ処理方法に関するものである。

【０００２】

【従来の技術】従来、ネットワーク環境におけるデータ
ベースにおいては、アプリケーションが利用するデータ
が大規模であり、信頼性、保守性、機密性等が求められ
る場合、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ
Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）が
使用されている。前記ネットワーク環境においては、デ
ータが共有されたり、他のアプリケーションで使用され
たりすることが多い。

【０００３】例えば、複数のエンドユーザが同一のアプ
リケーション、又は、複数のアプリケーションを使用し
て、データを操作したり検索を行ったりする。この場
合、ＲＤＢＭＳによって、トランザクション（ｔｒａｎ
ｓａｃｔｉｏｎ）と呼ばれるデータの読み書きの実行処
理単位に基づいてデータを管理することによって、デー
タベースが誤って操作されないようにする。そして、前
記トランザクションは原子的性質を持つため、前記トラ
ンザクションがデータベースに対して一連の操作を行う
場合、該操作が全て行われるか、又は、該操作が全く行
われないかのどちらかである。

【０００４】そして、前記各トランザクションはｃｏｍ
ｍｉｔを実行することによって処理が完結される。完結
されたトランザクションがデータベースに対して行った
更新内容はデータベースに反映される。

【０００５】また、前記各トランザクションをアンドゥ
（ｕｎｄｏ）する場合、ｒｏｌｌｂａｃｋを実行する。
これにより、アンドゥされたトランザクションがデータ
ベースに対して行った更新内容は全て取り消される。

【０００６】

【発明が解決しようとする課題】しかしながら、前記従
来のリレーショナルデータベースのようなデータベース
においては、アンドゥする場合、実行中のトランザクシ
ョンによって更新されたデータは、ｃｏｍｍｉｔ又はｒ
ｏｌｌｂａｃｋが実行されるまで、他のトランザクショ
ンによって読み書きすることができないので、トランザ
クションを実行するための操作に時間がかかってしま
う。

【０００７】このため、リレーショナルデータベースの
処理効率を向上させるためには、トランザクションの実
行時間を短縮することが必要である。

【０００８】本発明は、前記従来のリレーショナルデー
タベースにおけるアンドゥ処理方法の問題点を解決し
て、同じ主キー、又は、ディレクトリに対して、同じエ
ントリ又は属性に対する変更が複数存在しても、最初の
データのみを保存するため、差分データを節約すること
ができ、しかも、データの更新時間を必要としないので
処理時間を短縮することができ、他のクライアントがい
つでもデータを参照及び更新することができるアンドゥ
処理システム及びアンドゥ処理方法を提供することを目
的とする。

【０００９】

【課題を解決するための手段】そのために、本発明のア
ンドゥ処理システムにおいては、クライアントが使用す
るデータが表形式で格納されるリレーショナルデータベ
ースと、差分情報を格納するアンドゥ情報格納部と、ア
ンドゥ可能か否かのフラグを格納するアンドゥモード格
納部と、データ処理を実行するデータ処理部とを有し、
前記差分情報は、表が定義された時点で作成されて格納
され、前記データ処理部は、クライアントからのコマン
ドが変更処理であり、かつ、アンドゥ可能である場合、
前記差分情報を変更して前記表を更新する。

【００１０】本発明の他のアンドゥ処理システムにおい
ては、さらに、前記クライアントからのコマンドを受け
付け、応答を返す通信制御部を有する。

【００１１】本発明の更に他のアンドゥ処理システムに
おいては、さらに、前記アンドゥ情報格納部は、前記差
分情報として、エントリ差分表及び属性差分表を格納す
る。

【００１２】本発明の更に他のアンドゥ処理システムに
おいては、さらに、前記アンドゥ情報格納部は、最初の
差分情報のみを格納する。

【００１３】本発明の更に他のアンドゥ処理システムに
おいては、さらに、ディレクトリ情報ツリーを格納する
ディレクトリサーバ内に構築される。

【００１４】本発明のアンドゥ処理方法においては、ク
ライアントが使用するデータをリレーショナルデータベ
ースに表形式で格納し、表が定義されると、差分情報を
作成してアンドゥ情報格納部に格納し、前記クライアン
トからのコマンドが変更処理であり、かつ、アンドゥ可
能である場合、前記差分情報を変更して前記表を更新す
る。

【００１５】本発明の他のアンドゥ処理方法において
は、さらに、前記差分情報として、エントリ差分表及び
属性差分表をアンドゥ情報格納部に格納する。

【００１６】本発明の更に他のアンドゥ処理方法におい
ては、さらに、最初の差分情報のみを格納する。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照しながら詳細に説明する。

【００１８】図１は本発明の第１の実施の形態における
データ編集システムの構成を示す図である。

【００１９】図において、１０はコンピュータとしての
データ編集システムであり、ＲＤＢＭＳ１１、データ処
理部１２、通信制御部１３、差分データを格納するアン
ドゥ情報格納部１４、アンドゥモード格納部１５を有す
る。ここで、前記データ編集システム１０は、例えば、
ネットワーク環境において利用されるシステムであり、
アプリケーションの利用するデータが大規模であり、信
頼性、保守性、機密性等が求められるシステムである。

【００２０】そして、前記通信制御部１３は、ＡＰ（Ａ
ｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）やユーザによ
るコマンドを、前記データ編集システム１０に通信可能
に接続されたコンピュータとしてのクライアント１６か
ら受け付け、結果を返信する。なお、前記クライアント
１６からのコマンドとして、ｓｔａｒｔ、ｅｎｄ及びｃ
ａｎｃｅｌのコマンドを含む、拡張されたＳＱＬ（Ｓｔ
ｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）コ
マンドが入力されてもよいが、該ＳＱＬコマンドでなく
ても、同等の機能を有する独自のコマンドが入力されて
もよい。

【００２１】ここで、前記ｓｔａｒｔコマンドは、該ｓ
ｔａｒｔコマンドが入力された以降のデータの更新がア
ンドゥの対象となることを指示するコマンドであり、前
記ｅｎｄコマンドは、前記ｓｔａｒｔコマンド以降に更
新されたデータを確定し、アンドゥの対象としないこと
を指示するコマンドであり、また、前記ｃａｎｃｅｌコ
マンドは、前記ｓｔａｒｔコマンド以降に更新されたデ
ータをアンドゥし、前記ｓｔａｒｔコマンド入力時のデ
ータへ復旧させることを指示するコマンドである。

【００２２】そして、前記データ処理部１２は、ｓｔａ
ｒｔコマンド、ｅｎｄコマンド及びｃａｎｃｅｌコマン
ドのそれぞれを解釈し、適当な処理を行い、前記通信制
御部１３を介して、クライアント１６へ応答を返信す
る。

【００２３】また、前記ＲＤＢＭＳ１１上には、クライ
アント１６が使用するデータがリレーショナルデータベ
ースとして構築されている。そして、アンドゥ情報格納
部１４は、実際にはＲＤＢＭＳ１１上に構築され、差分
情報を格納するリレーショナルデータベースとして機能
する。

【００２４】次に、アンドゥ処理の動作について説明す
る。

【００２５】図２は本発明の第１の実施の形態における
社員表の例を示す図、図３は本発明の第１の実施の形態
における部門表の例を示す図、図４は本発明の第１の実
施の形態における図２のアンドゥ情報としての社員差分
表を示す図、図５は本発明の第１の実施の形態における
図３のアンドゥ情報としての部門差分表を示す図、図６
は本発明の第１の実施の形態における通常モードのデー
タ処理部のフローチャートを示す図、図７は本発明の第
１の実施の形態におけるアンドゥ可能モードのデータ処
理部のフローチャートを示す図である。

【００２６】本実施の形態において、クライアント１６
は、図２及び３に示されるようなリレーショナルデータ
ベースを使用している。図において、下線が引かれた属
性は主キーを表す。そして、図２に示される社員表にお
ける所属は、図３に示される部門表の外部キーである。
このとき、アンドゥ情報格納部１４には図２及び３に対
応するアンドゥ情報として、図４及び５に示されるよう
なスキーマ（ｓｃｈｅｍａ）の差分表が格納される。

【００２７】また、該差分表は、ユーザが社員表等の表
を定義した時点において、同じスキーマに変更種別を追
加したスキーマが作成される。そして、ユーザが定義し
た表、すなわち、ユーザ定義の表と同じ属性が主キーで
あるが、外部キーは存在しない。また、差分情報として
は、クライアント１６からのｓｔａｒｔコマンドを受け
付けた以降の更新データを格納し、途中のコマンドにお
いて、ｃｏｍｍｉｔやｒｏｌｌｂａｃｋが混在していて
もよい。

【００２８】ここで、アンドゥ処理方法の例について説
明する。

【００２９】まず、通信制御部１３がクライアント１６
からのコマンドを受け付けると、該コマンドをデータ処
理部１２に送信する。該データ処理部１２はアンドゥモ
ード格納部１５のアンドゥモードを参照して処理を行
う。

【００３０】そして、該アンドゥモードが通常モードの
場合、データ処理部１２は以下の処理を行う。

【００３１】まず、該データ処理部１２はコマンドがｅ
ｎｄまたはｃａｎｃｅｌであるか否かを判断する。前記
コマンドがｅｎｄまたはｃａｎｃｅｌである場合、通信
制御部１３を介してクライアント１６へオペレーション
エラーを送信して処理を終了する。また、コマンドがｅ
ｎｄまたはｃａｎｃｅｌではなくｓｔａｒｔであると判
断すると、アンドゥモードをアンドゥ可能モードに変更
して、アンドゥモード格納部１５に格納する。その結果
を成功として通信制御部１３を介し、クライアント１６
へ送信し、処理を終了する。また、コマンドがｓｔａｒ
ｔではない場合、ＲＤＢＭＳ１１へ、そのままコマンド
を送信し、前記ＲＤＢＭＳ１１は通常のＳＱＬコマンド
の処理を行い、その結果をデータ処理部１２へ返信す
る。

【００３２】また、前記アンドゥモードがアンドゥ可能
モードの場合、データ処理部１２は以下の処理を行う。

【００３３】まず、該データ処理部１２はコマンドがｓ
ｔａｒｔであるか否かを判断する。そして、前記コマン
ドがｓｔａｒｔである場合、通信制御部１３を介してク
ライアント１６へオペレーションエラーを送信して処理
を終了する。

【００３４】また、前記コマンドがｓｔａｒｔでない場
合、さらに、ｃａｎｃｅｌであるか否かを判断する。前
記コマンドがｃａｎｃｅｌである場合、ユーザ定義の表
の参照制約を一時無効にする。そして、前記アンドゥ情
報格納部１４の差分表を参照して、全てのデータの逆操
作をユーザ定義の表に対して行う。

【００３５】ここで、前記逆操作においては、差分表の
変更種別が追加のデータである場合、対応する前記ユー
ザ定義の表から該データを削除する。また、ユーザ定義
の表に前記データが存在しない場合、ＲＤＢＭＳ１１か
らエラーが返信されるが、該エラーは無視される。

【００３６】そして、差分表の変更種別が削除のデータ
である場合、対応する前記ユーザ定義の表に該データを
追加する。また、ユーザ定義の表に既に同じ主キーを持
つ前記データが存在する場合、ＲＤＢＭＳ１１から主キ
ー制約違反のエラーが返されるが、差分表のデータを優
先する。すなわち、ユーザ定義の表のデータを削除し、
差分表のデータを追加する。また、このような逆操作の
順序は、任意であるので、検索順に行えばよい。

【００３７】次に、ユーザ定義の表の参照制約を有効に
する。そして、アンドゥ情報格納部１４の差分表のデー
タを全て削除する。また、アンドゥモードを通常モード
に変更し、前記アンドゥモード格納部１５に格納する。
そして、前記通信制御部１３を介して結果をクライアン
ト１６に送信し、処理を終了する。

【００３８】また、前記コマンドがｃａｎｃｅｌでない
場合、前記ＲＤＢＭＳ１１へ、そのままコマンドを送信
する。すると、前記ＲＤＢＭＳ１１は通常のＳＱＬコマ
ンドの処理を行い、結果をデータ処理部１２へ返信す
る。

【００３９】そして、前記ＲＤＢＭＳ１１においてコマ
ンドの処理が成功したか否かを判断し、処理が成功しな
い場合は、前記通信制御部１３を介して結果をクライア
ント１６に送信し、処理を終了する。また、処理が成功
し、コマンドが変更処理の場合、すなわち、ｉｎｓｅｒ
ｔ、ｄｅｌｅｔｅ及びｕｐｄａｔｅのいずれかのコマン
ドを入力した場合、前記アンドゥ情報格納部１４の差分
表へ差分データを追加する。そして、該差分データを変
更前のデータとして、前記差分データの変更種別がｄｅ
ｌｅｔｅとｕｐｄａｔｅの場合、削除を指定し、ｉｎｓ
ｅｒｔの場合、追加を指定する。

【００４０】また、差分表へ差分データを追加する場
合、既に同じ主キーのデータが存在する時、主キー制約
違反のエラーが前記ＲＤＢＭＳ１１から返信されるが、
前記主キー制約違反のエラーは単に無視される。そし
て、前記通信制御部１３を介して結果をクライアント１
６に送信し、処理を終了する。

【００４１】次に、通常モードにおけるデータ処理部の
フローチャートについて説明する。 ステップＳ１ コマンドがｅｎｄ又はｃａｎｃｅｌであ
るか否かを判断する。ｅｎｄ又はｃａｎｃｅｌである場
合はステップＳ２へ進み、ｅｎｄ又はｃａｎｃｅｌでな
い場合はステップＳ３へ進む。 ステップＳ２ 通信制御部１３を介してクライアント１
６へオペレーションエラーを送信して処理を終了する。 ステップＳ３ コマンドがｓｔａｒｔであるか否かを判
断する。ｓｔａｒｔである場合はステップＳ５に進み、
ｓｔａｒｔでない場合はステップＳ４に進む。 ステップＳ４ ＲＤＢＭＳ１１に、そのままコマンドを
送信する。 ステップＳ５ アンドゥモードをアンドゥ可能モードに
変更して、アンドゥモード格納部１５へ格納する。 ステップＳ６ 通信制御部１３を介して、結果をクライ
アント１６へ送信して処理を終了する。

【００４２】次に、アンドゥ可能モードにおけるデータ
処理部のフローチャートについて説明する。 ステップＳ１１ データ処理部１２はコマンドがｓｔａ
ｒｔであるか否かを判断する。ｓｔａｒｔである場合は
ステップＳ１２に進み、ｓｔａｒｔでない場合はステッ
プＳ１３に進む。 ステップＳ１２ 通信制御部１３を介してクライアント
１６へオペレーションエラーを送信して処理を終了す
る。 ステップＳ１３ コマンドがｃａｎｃｅｌであるか否か
を判断する。ｃａｎｃｅｌである場合はステップＳ１７
に進み、ｃａｎｃｅｌでない場合はステップＳ１４に進
む。 ステップＳ１４ ＲＤＢＭＳ１１へ、そのままコマンド
を送信する。 ステップＳ１５ ＲＤＢＭＳ１１においてコマンドが成
功したか否かを判断する。成功した場合はステップＳ１
６に進み、成功しない場合はステップＳ２２に進む。 ステップＳ１６ コマンドが変更処理の場合、アンドゥ
情報格納部１４の差分表へ差分データを追加する。 ステップＳ１７ ユーザ定義の表の参照制約を一時無効
にする。 ステップＳ１８ アンドゥ情報格納部１４の差分表を参
照して、全てのデータの逆操作をユーザ定義の表に対し
て行う。 ステップＳ１９ ユーザ定義の表の参照制約を有効にす
る。 ステップＳ２０ アンドゥ情報格納部１４の差分表のデ
ータを全て削除する。 ステップＳ２１ アンドゥモードを通常モードに変更
し、アンドゥモード格納部１５に格納する。 ステップＳ２２ 通信制御部１３を介して結果をクライ
アント１６へ送信して処理を終了する。

【００４３】次に、データベースの内容が図２及び３に
示されるものであり、コマンドのシーケンスがクライア
ント１６から入力された場合について説明する。

【００４４】図８は本発明の第１の実施の形態における
社員表の他の例を示す図、図９は本発明の第１の実施の
形態における部門表の他の例を示す図、図１０は本発明
の第１の実施の形態における図８のアンドゥ情報として
の社員差分表を示す図、図１１は本発明の第１の実施の
形態における図９のアンドゥ情報としての部門差分表を
示す図である。

【００４５】ここで、前記コマンドのシーケンスは、 第１コマンド：ｓｔａｒｔ 第２コマンド：ｄｅｌｅｔｅ ｆｒｏｍ 社員表 ｗｈｅｒｅ 社員番号＝’０００５’ 第３コマンド：ｕｐｄａｔｅ 社員表 ｓｅｔ 所属＝’Ｇ６０’ ｗｈｅｒｅ 社員番号＝’００１１’ 第４コマンド：ｉｎｓｅｒｔ ｉｎｔｏ 社員表（社員
番号、社員名、給与、所属） ｖａｌｕｅｓ（’００１４’、’△□’、’４０’、’
Ｇ６０’） 第５コマンド：ｄｅｌｅｔｅ ｆｒｏｍ 部門表 ｗｈｅｒｅ 部門番号＝’Ｇ５０’ 第６コマンド：ｃａｎｃｅｌ である。

【００４６】ここで、前記第５コマンドのｄｅｌｅｔｅ
が入力された後、ユーザ定義の表は、図８及び９に示さ
れるようになっている。また、差分表は、図１０及び１
１のようになっている。続いて、第６コマンドのｃａｎ
ｃｅｌが入力されると、社員表の参照制約を一時無効に
して、差分表の逆操作を行う。

【００４７】該逆操作の順序は任意なので、データ（’
０００５’、’○○’、’６５’、’Ｇ５０’）を追加
することもある。この場合、所属のＧ５０に対応するデ
ータが部門表に含まれていないが、あらかじめ、参照制
約を一時無効にしているので、前記データ（’０００
５’、’○○’、’６５’、’Ｇ５０’）は、エラーと
ならずに、追加される。

【００４８】次に、データ（’００１１’、’△
△’、’５０’、’Ｇ５０’）を復元する。社員表には
既に同じ主キーを持つデータが含まれるので、主キー制
約違反のエラーがＲＤＢＭＳ１１から返信される。した
がって、社員表のデータを削除した後、前記データ（’
００１１’、’△△’、’５０’、’Ｇ５０’）が追加
される。

【００４９】次に、データ（’００１４’、’△
□’、’４０’、’Ｇ６０’）を社員表から削除する。
そして、部門差分表からデータ（’Ｇ５０’、’開発
部’）を検索し、部門表に追加する。

【００５０】最後に、参照制約を有効にして第６コマン
ドのｃａｎｃｅｌの処理が終了する。そして、該ｃａｎ
ｃｅｌの処理が行われた結果、図２及び３に示されるデ
ータに復元される。また、図１０及び１１に示される各
差分表の内容は空になる。

【００５１】次に、データベースの内容が図２及び３に
示されるものであり、コマンドのシーケンスがクライア
ント１６から入力された他の場合について説明する。

【００５２】図１２は本発明の第１の実施の形態におけ
る社員表の更に他の例を示す図、図１３は本発明の第１
の実施の形態における部門表の更に他の例を示す図、図
１４は本発明の第１の実施の形態における図１２のアン
ドゥ情報としての社員差分表を示す図、図１５は本発明
の第１の実施の形態における図１３のアンドゥ情報とし
ての部門差分表を示す図である。

【００５３】ここで、前記コマンドのシーケンスは、 第１コマンド：ｓｔａｒｔ 第２コマンド：ｄｅｌｅｔｅ ｆｒｏｍ 社員表 ｗｈｅｒｅ 社員番号＝’０００５’ 第３コマンド：ｉｎｓｅｒｔ ｉｎｔｏ 社員表（社員
番号、社員名、給与、所属） ｖａｌｕｅｓ（’０００５’、’◇○’、’５５’、’
Ｇ５０’） 第４コマンド：ｉｎｓｅｒｔ ｉｎｔｏ 社員表（社員
番号、社員名、給与、所属） ｖａｌｕｅｓ（’００１４’、’△□’、’４０’、’
Ｇ６０’） 第５コマンド：ｄｅｌｅｔｅ ｆｒｏｍ 社員表 ｗｈｅｒｅ 社員番号＝’００１４’ 第６コマンド：ｃａｎｃｅｌ である。

【００５４】ここで、第３コマンドのｉｎｓｅｒｔを入
力した時に、社員差分表にデータ（’０００５’、’◇
○’、’５５’、’Ｇ５０’）を追加しようとするが、
社員差分表には既に同じ主キーを持つデータが存在する
ので、主キー制約違反になり追加することができない。
しかし、このエラーは単に無視される。

【００５５】同様に、第５コマンドのｄｅｌｅｔｅを入
力した時に、社員差分表にデータ（’００１４’、’△
□’、’４０’、’Ｇ６０’）を追加しようとするが、
社員差分表には既に同じ主キーを持つデータが存在する
ので、主キー制約違反になり追加することができない
が、このエラーも単に無視される。

【００５６】ここで、前記第５コマンドのｄｅｌｅｔｅ
が入力された後、ユーザ定義の表は、図１２及び１３に
示されるようになっている。

【００５７】そして、第６コマンドのｃａｎｃｅｌが入
力されると社員表の参照制約を一時無効にして、差分表
の逆操作を行う。

【００５８】まず、データ（’０００５’、’○
○’、’６５’、’Ｇ５０’）を復元する。この場合、
社員表には既に同じ主キーを持つデータが存在するの
で、主キー制約違反のエラーがＲＤＢＭＳ１１から返信
される。したがって、ユーザ定義の表のデータを削除し
た後、データ（’０００５’、’○○’、’６５’、’
Ｇ５０’）を追加する。

【００５９】次に、データ（’００１４’、’△
□’、’４０’、’Ｇ６０’）を削除しようとするが該
データ（’００１４’、’△□’、’４０’、’Ｇ６
０’）は社員表に存在しないので、エラーがＲＤＢＭＳ
１１から返信されるが前記エラーは単に無視される。

【００６０】最後に、参照制約を有効にして第６コマン
ドのｃａｎｃｅｌの処理が終了する。そして、該ｃａｎ
ｃｅｌの処理が行われた結果、図２及び３に示されるデ
ータに復元される。また、図１４及び１５に示される各
差分表の内容は空になる。

【００６１】このように、本実施の形態において、同じ
主キーに対する変更が複数存在しても、最初のデータの
みが差分表に保存され、かつ、正しく復元される。ま
た、最初のデータのみを保存するので、差分データを節
約することができる。しかも、データの更新時刻を必要
としないので、更新量が膨大になっても、メモリや２次
記憶をそれほど消費することなく、処理時間を短縮する
ことができる。

【００６２】また、ＲＤＢＭＳ１１の機能を活用して同
じ主キーに対する操作であるか否かを判定するので、実
現も容易である。また、個々の操作に対するｃｏｍｍｉ
ｔさえ行っていれば、他のクライアントがいつでもデー
タを参照及び更新することが可能である。

【００６３】次に、本発明の第２の実施の形態について
説明する。なお、前記第１の実施の形態と同じ構成を有
するもの及び同じ動作については、その説明を省略す
る。

【００６４】図１６は本発明の第２の実施の形態におけ
るディレクトリサーバの構成を示す図である。

【００６５】図において、２０はコンピュータとしての
ディレクトリサーバであり、アンドゥ情報格納部２１、
ＲＤＢＭＳ２２、ディレクトリ制御部２３、通信制御部
２４、ディレクトリ情報部２５、データ処理部としての
アンドゥ処理部２６、アンドゥモード格納部２７及びク
ライアント２８を有する。

【００６６】前記ディレクトリサーバ２０は、ディレク
トリ情報ツリー（ｔｒｅｅ）として管理された、開始ア
ドレスとしてのエントリ（ｅｎｔｒｙ）を保持する。そ
れぞれの該エントリは、ＤＮ（Ｄｉｓｔｉｎｇｕｉｓｈ
ｅｄ Ｎａｍｅ：識別名）で一意に特定することができ
る。なお、該ＤＮは、属性型と属性値からなるものであ
り、国、組織、組織単位、名前を特定する。また、ＤＮ
から一部の情報が省略されている時、そこから得ること
ができる前記エントリをＲＤＮ（Ｒｅｌａｔｉｖｅ Ｄ
ｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ：相対識別名）と
言う。

【００６７】次に、本実施の形態におけるディレクトリ
サーバ２０の動作について説明する。

【００６８】図１７は本発明の第２の実施の形態におけ
るＬＤＡＰの追加操作の構文を示す図、図１８は本発明
の第２の実施の形態におけるＬＤＡＰの削除操作の構文
を示す図、図１９は本発明の第２の実施の形態における
ＬＤＡＰの変更操作の構文を示す図、図２０は本発明の
第２の実施の形態におけるＬＤＡＰのＲＤＮ変更操作の
構文を示す図、図２１は本発明の第２の実施の形態にお
けるＬＤＡＰの拡張操作と拡張応答の構文を示す図、図
２２は本発明の第２の実施の形態におけるエントリ差分
表を示す図、図２３は本発明の第２の実施の形態におけ
る属性差分表を示す図である。

【００６９】まず、前記ディレクトリサーバ２０は、ク
ライアント２８からコマンドとしてのＬＤＡＰ（Ｌｉｇ
ｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ
Ｐｒｏｔｏｃｏｌ）の要求を受け付ける。

【００７０】ここで、前記ＬＤＡＰとは、ＲＦＣ（Ｒｅ
ｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ）１７７７によっ
て定められたディレクトリサービスにアクセスするため
の標準的なＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏ
ｌ）であり、要求としてディレクトリにおけるエントリ
の検索、追加、削除、変更、ＲＤＮの変更、サブディレ
クトリ情報ツリーの移動等のほかに拡張操作が規定され
ている。

【００７１】なお、該拡張操作はプライベートな操作を
拡張するために設けられており、その応答は拡張応答と
して規定されている。また、図２１に示されるように、
前記拡張操作としてのＥｘｔｅｎｄｅｄ Ｒｅｑｕｅｓ
ｔ、及び、拡張応答としてのＥｘｔｅｎｄｅｄ Ｒｅｓ
ｐｏｎｓｅの構文が規定されている。

【００７２】そして、図１７に示されるようなＬＤＡＰ
の追加操作の構文において、ｅｎｔｒｙは追加する上位
のエントリの識別名である。また、ａｔｔｒｉｂｕｔｅ
ｓは追加するエントリの属性型と属性値のリストであ
り、オブジェクトクラス、ＲＤＮ、必須属性が必ず含ま
れる。なお、指定のエントリが既に存在すればエラーに
なる。

【００７３】そして、図１８に示されるようなＬＤＡＰ
の削除操作の構文においては、削除するエントリの識別
名を指定する。

【００７４】また、図１９に示されるようなＬＤＡＰの
変更操作の構文においては、ｏｂｊｅｃｔは変更するエ
ントリの識別名、ｍｏｄｉｆｉｃａｔｉｏｎはそのエン
トリで行う操作のリストを示す。そして、該操作はａｄ
ｄ、ｄｅｌｅｔｅ及びｒｅｐｌａｃｅのいずれかであ
り、リストの順に実行される。

【００７５】まず、ａｄｄは指定の属性に指定の属性値
を追加する。そして、指定の属性がない場合は該属性を
作成する。次に、ｄｅｌｅｔｅは指定の属性から指定の
属性値を削除する。そして、属性値の指定がない場合は
全ての属性値を削除する。最後に、ｒｅｐｌａｃｅは指
定の属性の全既存属性値を指定の属性値に置き換える。
そして、指定の属性がない場合は該属性を作成する。ま
た、属性値の指定がない場合、既存の属性を削除する
が、該既存の属性が存在しなければ単に無視する。

【００７６】そして、図２０に示されるようなＬＤＡＰ
のＲＤＮの変更操作の構文において、ｅｎｔｒｙは変更
を行うエントリの識別名、ｎｅｗｒｄｎはエントリの更
新後の相対識別名、ｄｅｌｅｔｅｏｌｄｒｄｎは更新前
の相対識別名に使われている属性値をエントリの属性値
として残すか否かのフラグ、ｎｅｗＳｕｐｅｒｉｏｒ
は、存在するならば、直接上位におけるエントリの識別
名を表す。

【００７７】また、前記通信制御部２４は、前記ＡＰや
ユーザによるクライアント２８からの要求を受け付け、
結果を返信する。また、前記クライアント２８からの要
求として、拡張されたＬＤＡＰの要求を入力することが
できる。なお、実際には、ＬＤＡＰの要求でなく、同等
の操作をすることができる独自の要求であってもよい。

【００７８】本実施の形態においては、前記拡張操作で
ｓｔａｒｔ、ｅｎｄ及びｃａｎｃｅｌを定義する。ま
た、図２１に示されるように、ＥｘｔｅｎｄｅｄＲｅｑ
ｕｅｓｔは、ｒｅｑｕｅｓｔＮａｍｅとｒｅｑｕｅｓｔ
Ｖａｌｕｅとから成る。ここで、前記ｒｅｑｕｅｓｔＮ
ａｍｅは一意な要求識別子であり、ｓｔａｒｔ、ｅｎｄ
及びｃａｎｃｅｌに相当する一意な識別子を割り当て
る。また、前記ｒｅｑｕｅｓｔＶａｌｕｅは存在しなく
てもよい任意の項目であり、本実施の形態においては、
前記項目は存在しない。

【００７９】ここで、前記ｓｔａｒｔ要求は、該ｓｔａ
ｒｔ要求が入力された以降のデータの更新がアンドゥの
対象となることを指示する要求である。

【００８０】また、ｅｎｄ要求は、前記ｓｔａｒｔ要求
以降の更新データを確定し、アンドゥの対象とはしない
ことを指示する要求である。

【００８１】そして、ｃａｎｃｅｌ要求は、前記ｓｔａ
ｒｔ要求以降の更新データをアンドゥし、前記ｓｔａｒ
ｔ要求入力時のデータへ復旧することを指示する要求で
ある。

【００８２】ここで、前記アンドゥ処理部２６は、ｓｔ
ａｒｔ、ｅｎｄ及びｃａｎｃｅｌのそれぞれの要求を解
釈し、適当な処理を行って、前記通信制御部２４を介し
て結果をクライアント２８へ送信して処理を終了する。

【００８３】また、前記ディレクトリ制御部２３はＬＤ
ＡＰの要求を受け付けると、前記ディレクトリ情報部２
５にアクセスし、処理を実行する。該ディレクトリ情報
部２５は、ディレクトリ情報ツリーとして管理されたエ
ントリを保持する。

【００８４】そして、アンドゥ情報格納部は２１は、実
際はＲＤＢＭＳ２２上に構築され、差分情報を格納する
リレーショナルデータベースのエントリ差分表及び属性
差分表として表現される。なお、前記エントリ差分表
は、図２２に示されるようなスキーマを持ち、エントリ
のＤＮ及び変更種別から成る。ここで、図において、下
線が引かれたＤＮは主キーを表す。

【００８５】また、前記属性差分表は図２３に示される
ようにスキーマを持ち、エントリのＤＮ、属性、及び属
性値から成る。ここで、図において、下線が引かれたエ
ントリのＤＮと属性は主キーを表す。

【００８６】そして、前記アンドゥモード格納部２７
は、現在の処理がアンドゥの対象にならないことを意味
する通常モードであるか、アンドゥの対象であることを
意味するアンドゥ可能モードのいずれかを示すフラグを
格納する。

【００８７】ここで、アンドゥ処理方法の例について説
明する。

【００８８】図２４は本発明の第２の実施の形態におけ
る通常モードのデータ処理部のフローチャートを示す
図、図２５は本発明の第２の実施の形態におけるアンド
ゥ可能モードのデータ処理部のフローチャートを示す図
である。

【００８９】まず、通信制御部２４がクライアント２８
からの要求を受け付けると、該要求をアンドゥ処理部２
６に送信する。すると、該アンドゥ処理部２６はアンド
ゥモード格納部２７のアンドゥモードを参照して処理を
行う。

【００９０】そして、該アンドゥモードが通常モードの
場合、アンドゥ処理部２６は以下の処理を行う。

【００９１】まず、要求がｅｎｄ又はｃａｎｃｅｌであ
るか否かを判断する。そして、該要求がｅｎｄ又はｃａ
ｎｃｅｌである場合、通信制御部２４を介してクライア
ント２８へオペレーションエラーを送信して処理を終了
する。また、要求がｅｎｄ又はｃａｎｃｅｌではなくｓ
ｔａｒｔであると判断すると、アンドゥモードをアンド
ゥ可能モードに変更して、アンドゥモード格納部２７に
格納する。その結果を成功として通信制御部２４を介
し、クライアント２８へ送信し、処理を終了する。

【００９２】また、要求がｓｔａｒｔではない場合、デ
ィレクトリ制御部２３へ、そのまま要求を送信し、前記
ディレクトリ制御部２３は通常のＬＤＡＰ要求の処理を
行い、その結果をアンドゥ処理部２６へ送信する。

【００９３】また、前記アンドゥモードがアンドゥ可能
モードの場合、アンドゥ処理部２６は以下の処理を行
う。

【００９４】なお、要求がｓｔａｒｔであるか否かを判
断する。前記要求がｓｔａｒｔである場合、通信制御部
２４を介してクライアント２８へオペレーションエラー
を送信して処理を終了する。

【００９５】次に、要求がｓｔａｒｔでない場合、さら
に、要求がｃａｎｃｅｌであるか否かを判断する。

【００９６】そして、前記要求がｃａｎｃｅｌである場
合、アンドゥ情報格納部２１の差分表を参照して、全て
のデータの逆操作にあたるＬＤＡＰ要求をディレクトリ
制御部２３送信する。ここで、前記逆操作は、エントリ
差分表、属性差分表の順に行うが、それぞれの表におけ
る逆操作の順序は任意であるので、検索順に行えばよ
い。

【００９７】まず、エントリ差分表の逆操作は、該エン
トリ差分表を検索し、検索データとして（ＤＮ、”追
加”）が得られた場合、逆操作のＬＤＡＰ要求としてＤ
ｅｌＲｅｑｕｅｓｔ ＤＮをディレクトリ制御部２３へ
送る。そして、エントリ差分表を検索し、検索データと
して（ＤＮ、”削除”）が得られた場合、属性差分表か
ら該当するエントリの属性を検索する。このとき、検索
されたデータは属性差分表からは削除する。または、逆
操作のＬＤＡＰ要求としてＡｄｄＲｅｑｕｅｓｔＤＮか
らＲＤＮを除いた部分である、属性リストをディレクト
リ制御部２３へ送る。

【００９８】いずれの場合も、もし指定のエントリがデ
ィレクトリ情報部２５に存在しなければ、前記ディレク
トリ制御部２３によるＬＤＡＰ要求の処理の結果として
エラーを返信すことになるが、そのエラーは単に無視す
る。

【００９９】また、属性差分表の逆操作は、該属性差分
表を検索し、検索データとして（ＤＮ、Ａ、”ａ”）が
得られたとすると、逆操作のＬＤＡＰ要求としてのＭｏ
ｄｉｆｙＲｅｑｕｅｓｔ ＤＮ（ｒｅｐｌａｃｅ
（Ａ、”ａ”））を前記ディレクトリ制御部２３へ送
る。もし、指定のエントリがディレクトリに存在しない
場合、前記ディレクトリ制御部２３によるＬＤＡＰ要求
処理の結果としてエラーを返信するが、そのエラーは単
に無視する。

【０１００】続いて、アンドゥ情報格納部２１の差分表
のデータを全て削除する。また、アンドゥモードを通常
モードに変更し、アンドゥモード格納部２７に格納す
る。そして、前記通信制御部２４を介して結果をクライ
アント２８に送信し、処理を終了する。

【０１０１】また、前記要求がｃａｎｃｅｌでない場
合、すなわち、通常の要求が入力された場合、前記ディ
レクトリ制御部２３へ、そのまま要求を送信する。前記
ディレクトリ制御部２３は通常のＬＤＡＰ要求の処理を
行い、結果をアンドゥ処理部２６へ送信する。そして、
前記ディレクトリ制御部２３において要求の処理が成功
したか否かを判断し、処理が成功しない場合は前記通信
制御部２４を介して結果をクライアント２８に送信し、
処理を終了する。また、処理が成功し、要求が変更処理
の場合、すなわち、ＡｄｄＲｅｑｕｅｓｔ、ＤｅｌＲｅ
ｑｕｅｓｔ、ＭｏｄｉｆｙＲｅｑｕｅｓｔ、又は、Ｍｏ
ｄｉｆｙＤＮＲｅｑｕｅｓｔのいずれかの要求を入力し
た場合、前記アンドゥ情報格納部２１の差分表へ差分デ
ータを追加する。

【０１０２】ここで、前記要求がＡｄｄＲｅｑｕｅｓｔ
の場合、エントリ差分表へｅｎｔｒｙで指定された上位
エントリのＤＮとａｔｔｒｉｂｕｔｅｓに含まれるＲＤ
Ｎとによって、構成される識別名と変更種別が‘追加’
から成るデータを挿入する。ただし、主キー制約違反が
発生する場合は前記データを挿入しない。なお、属性差
分表へのデータの挿入は行わない。

【０１０３】また、前記要求がＤｅｌＲｅｑｕｅｓｔの
場合、前記エントリ差分表へ、指定のＤＮと変更種別が
‘削除’から成るデータを挿入する。さらに、属性差分
表に、指定のＤＮとそのエントリが保持していた属性
と、属性値から成るデータを挿入する。ただし、主キー
制約違反が発生する場合は前記データを挿入しない。

【０１０４】そして、前記要求がＭｏｄｉｆｙＲｅｑｕ
ｅｓｔの場合、前記エントリ差分表へのデータの挿入は
行わない。前記属性差分表へｏｂｊｅｃｔで指定される
エントリのＤＮとｍｏｄｉｆｉｃａｔｉｏｎで指定され
る属性とその属性の変更前の属性値から成るデータを挿
入する。ただし、主キー制約違反が発生する場合は前記
データを挿入しない。

【０１０５】また、前記要求がＭｏｄｉｆｙＤＮＲｅｑ
ｕｅｓｔの場合、前記エントリ差分表へ、ｅｎｔｒｙで
指定されるエントリのＤＮと変更種別が‘削除’から成
るデータを挿入する。また、ｅｎｔｒｙ、ｎｅｗｒｄｎ
及びｎｅｗＳｕｐｅｒｉｏｒのいずれかで指定されるエ
ントリのＤＮと変更種別が‘追加’から成るデータを挿
入する。ただし、主キー制約違反が発生する場合には、
前記データを挿入しない。

【０１０６】例えば、ｅｎｔｒｙが”Ａ＝ａ、Ｂ＝ｂ、
Ｃ＝ｃ”、ｎｅｗｒｄｎが”Ｄ＝ｄ”、ｎｅｗＳｕｐｅ
ｒｉｏｒが存在しない場合、（”Ａ＝ａ、Ｂ＝ｂ、Ｃ＝
ｃ”、削除）、（”Ａ＝ａ、Ｂ＝ｂ、Ｄ＝ｄ”、”追
加”）を挿入する。また、ｅｎｔｒｙが”Ａ＝ａ、Ｂ＝
ｂ、Ｃ＝ｃ”、ｎｅｗｒｄｎが”Ｄ＝ｄ”、ｎｅｗＳｕ
ｐｅｒｉｏｒが”Ａ＝ａ、Ｅ＝ｅ”の場合、（”Ａ＝
ａ、Ｂ＝ｂ、Ｃ＝ｃ”、削除）、（”Ａ＝ａ、Ｅ＝ｅ、
Ｄ＝ｄ”、”追加”）を挿入する。

【０１０７】次に、前記属性差分表へｅｎｔｒｙで指定
されるエントリのＤＮとそのエントリが保持していた属
性と属性値から成るデータを挿入する。ただし、主キー
制約違反が発生する場合は前記データを挿入しない。

【０１０８】続いて、通信制御部２４を介してクライア
ント２８へオペレーションエラーを送信して処理を終了
する。

【０１０９】次に、通常モードにおけるデータ処理部の
フローチャートについて説明する。 ステップＳ３１ 要求がｅｎｄ又はｃａｎｃｅｌである
か否かを判断する。ｅｎｄ又はｃａｎｃｅｌである場合
はステップＳ３２へ進み、ｅｎｄ又はｃａｎｃｅｌでな
い場合はステップＳ３３へ進む。 ステップＳ３２ 通信制御部２４を介してクライアント
２８へオペレーションエラーを送信して処理を終了す
る。 ステップＳ３３ 要求がｓｔａｒｔであるか否かを判断
する。ｓｔａｒｔである場合はステップＳ３５に進み、
ｓｔａｒｔでない場合はステップＳ３４に進む。 ステップＳ３４ ディレクトリ制御部２３へ、そのまま
要求を送信する。 ステップＳ３５ アンドゥモードをアンドゥ可能モード
に変更して、アンドゥモード格納部２７へ格納する。 ステップＳ３６ 通信制御部２４を介して結果をクライ
アント２８へ送信して処理を終了する。

【０１１０】次に、アンドゥ可能モードにおけるデータ
処理部のフローチャートについて説明する。 ステップＳ４１ 要求がｓｔａｒｔであるか否かを判断
する。ｓｔａｒｔである場合はステップＳ４２に進み、
ｓｔａｒｔでない場合はステップＳ４３に進む。 ステップＳ４２ 通信制御部２４を介してクライアント
２８へオペレーションエラーを送信して処理を終了す
る。 ステップＳ４３ 要求がｃａｎｃｅｌであるか否かを判
断する。ｃａｎｃｅｌである場合はステップＳ４７に進
み、ｃａｎｃｅｌでない場合はステップＳ４４に進む。 ステップＳ４４ ディレクトリ制御部２３へ、そのまま
要求を送信する。 ステップＳ４５ ディレクトリ制御部２３において要求
の処理が成功したか否かを判断する。成功した場合はス
テップＳ４６に進み、成功しない場合はステップＳ５０
に進む。 ステップＳ４６ 要求が変更処理の場合、アンドゥ情報
格納部２１の差分表へ差分データを追加する。 ステップＳ４７ 前記アンドゥ情報格納部２１の差分表
を参照して、全てのデータの逆操作にあたるＬＤＡＰ要
求を前記ディレクトリ制御部２３へ送信する。 ステップＳ４８ 前記アンドゥ情報格納部２１の差分表
のデータを全て削除する。 ステップＳ４９ アンドゥモードを通常モードに変更
し、アンドゥモード格納部２７に格納する。 ステップＳ５０ 通信制御部２４を介して結果をクライ
アント２８へ送信して処理を終了する。

【０１１１】次に、本実施の形態における属性値を変更
する動作について説明する。

【０１１２】図２６は本発明の第２の実施の形態におけ
るディレクトリ情報ツリーを示す図、図２７は本発明の
第２の実施の形態における変更操作後のディレクトリ情
報ツリーを示す図、図２８は本発明の第２の実施の形態
における属性差分表を示す図である。

【０１１３】まず、ディレクトリ情報ツリーが図２６に
示されるものであり、以下の要求のシーケンスがクライ
アント２８から入力された場合について説明する。

【０１１４】この場合、前記要求のシーケンスは、 第１要求：ｓｔａｒｔ 第２要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部、一般名＝△□一郎”、（ａｄｄ（内線番号、”２３
４”）） 第３要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部、一般名＝△□一郎”、（ｒｅｐｌａｃｅ（内線番
号、”１１１”）） 第４要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部、一般名＝△□一郎”、（ｄｅｌｅｔｅ（住所、”千
葉”）） 第５要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部、一般名＝△□一郎”、（ａｄｄ（住所、”横
浜”）） 第６要求：ｃａｎｃｅｌ である。

【０１１５】ここで、第３要求入力時において、属性差
分表に第２要求のデータ（”国名＝ＪＰ、地域名＝東
京、組織名＝ＡＢＣ、組織単位名＝営業部、一般名＝△
□一郎”、内線番号、”２３４”）を追加しようとする
が、既に同じ主キーのデータが前記属性差分表に存在す
るため、主キー制約違反になり、追加することができな
い。しかし、このエラーは単に無視される。

【０１１６】また、第５要求入力時においても、同様の
エラーが発生するが単に無視され、前記属性差分表に前
記データは追加されない。そして、第５要求入力後のデ
ィレクトリ情報ツリーは図２７に示されるようになって
おり、属性差分表は図２８に示されるようになってい
る。この時、エントリ差分表は空のままである。

【０１１７】続いて、第６要求のｃａｎｃｅｌが入力さ
れると、差分表の逆操作を行う。ここで、該逆操作の順
序は、任意であるが、まず、（”国名＝ＪＰ、地域名＝
東京、組織名＝ＡＢＣ、組織単位名＝営業部、一般名＝
△□一郎”、内線番号、ｎｕｌｌ）に置き換える。その
ために、ＬＤＡＰの要求として、ＭｏｄｉｆｙＲｅｑｕ
ｅｓｔ ”国名＝ＪＰ、地域名＝東京、組織名＝ＡＢ
Ｃ、組織単位名＝営業部、一般名＝△□一郎”、（ｒｅ
ｐｌａｃｅ（内線番号、ｎｕｌｌ））を発行する。

【０１１８】次に、（国名＝ＪＰ、地域名＝東京、組織
名＝ＡＢＣ、組織単位名＝営業部、一般名＝△□一
郎’、住所、千葉）に置き換える。そのために、ＬＤＡ
Ｐの要求として、ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名
＝ＪＰ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝
営業部、一般名＝△□一郎”、（ｒｅｐｌａｃｅ（住
所、”千葉”））を発行する。

【０１１９】最後に、差分表の内容を全て削除してｃａ
ｎｃｅｌ処理が終了する。そして、ｃａｎｃｅｌの結
果、図２６に示されるディレクトリ情報ツリーに復元す
ることができることがわかる。

【０１２０】このように、同じエントリの同じ属性に対
して複数の変更が存在する場合、最初のデータのみが差
分表に保存されるが、正しく復元される。

【０１２１】次に、本実施の形態におけるエントリを変
更する動作について説明する。

【０１２２】図２９は本発明の第２の実施の形態におけ
る他の変更操作後のディレクトリ情報ツリーを示す図、
図３０は本発明の第２の実施の形態におけるエントリ差
分表を示す図、図３１は本発明の第２の実施の形態にお
ける他の属性差分表を示す図である。

【０１２３】まず、ディレクトリ情報ツリーが図２６に
示されるものであり、以下の要求のシーケンスがクライ
アント２８から入力された場合について説明する。

【０１２４】この場合、前記要求のシーケンスは、 第１要求：ｓｔａｒｔ 第２要求：ＡｄｄＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域
名＝東京、組織名＝ＡＢＣ、組織単位名＝営業部””一
般名＝×△次郎、オブジェクトクラス＝人、姓＝×△、
住所＝大宮” 第３要求：ＤｅｌＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域
名＝東京、組織名＝ＡＢＣ、組織単位名＝営業部、一般
名＝×△次郎” 第４要求：ＡｄｄＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域
名＝東京、組織名＝ＡＢＣ、組織単位名＝営業部””一
般名＝×△次郎、オブジェクトクラス＝人、姓＝×△、
住所＝浦和、内線番号＝４５６” 第５要求：ｃａｎｃｅｌ である。

【０１２５】ここで、第３要求入力時において、エント
リ差分表にデータ（”国名＝ＪＰ、地域名＝東京、組織
名＝ＡＢＣ、組織単位名＝営業部、一般名＝△□一
郎”、削除）を追加しようとするが、既に同じ主キーの
データが前記エントリ差分表に存在するため、主キー制
約違反になり、追加することができない。しかし、この
エラーは単に無視される。

【０１２６】また、第４要求入力時においては、前記エ
ントリ差分表にデータ（”国名＝ＪＰ、地域名＝東京、
組織名＝ＡＢＣ、組織単位名＝営業部、一般名＝×△次
郎”、追加）を追加しようとするが、既に同じ主キーの
データが前記エントリ差分表に存在するため、主キー制
約違反になり、追加することができない。しかし、この
エラーは単に無視される。

【０１２７】そして、第４要求入力後のディレクトリ情
報ツリーは図２９に示されるようになっており、エント
リ差分表は図３０に示されるようになっており、また、
属性差分表は図３１に示されるようになっている。

【０１２８】続いて、第５要求のｃａｎｃｅｌが入力さ
れると、差分表の逆操作を行う。ここで、該逆操作は、
まず、エントリ差分表のデータから行われ、（”国名＝
ＪＰ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営
業部、一般名＝×△次郎”）を削除する。そのために、
ＬＤＡＰの要求としてＤｅｌＲｅｑｕｅｓｔ ”国名＝
ＪＰ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営
業部、一般名＝×△次郎”を発行する。

【０１２９】次に、属性差分のデータに基づいて、属性
の逆操作を行う。まず、（”国名＝ＪＰ、地域名＝東
京、組織名＝ＡＢＣ、組織単位名＝営業部、一般名＝×
△次郎”、”オブジェクトクラス”、”人”）へ置き換
える。そのために、ＬＤＡＰの要求として、Ｍｏｄｉｆ
ｙＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域名＝東京、組織
名＝ＡＢＣ、組織単位名＝営業部、一般名＝×△次郎”
（ｒｅｐｌａｃｅ（オブジェクトクラス、”人”））を
発行する。

【０１３０】これは、既にエントリがないためエラーと
なるが、単に無視する。また、一般名、姓、住所の属性
についても同様のエラ−が発生するが全て無視する。

【０１３１】最後に、差分表の内容を全て削除してｃａ
ｎｃｅｌ処理が終了する。そして、ｃａｎｃｅｌの結
果、図２６に示されるディレクトリ情報ツリーに復元す
ることができることがわかる。

【０１３２】このように、同じエントリの追加、削除が
複数回なされている場合、最初のデータのみが差分表に
保存されるが、正しく復元される。

【０１３３】次に、本実施の形態におけるディレクトリ
と属性の変更が混在する場合の動作について説明する。

【０１３４】図３２は本発明の第２の実施の形態におけ
る第１要求処理後のディレクトリ情報ツリーを示す図、
図３３は本発明の第２の実施の形態における第５要求処
理後のディレクトリ情報ツリーを示す図、図３４は本発
明の第２の実施の形態における他のエントリ差分表を示
す図、図３５は本発明の第２の実施の形態における更に
他の属性差分表を示す図である。

【０１３５】まず、ディレクトリ情報ツリーが図２６に
示されるものであり、以下の要求のシーケンスがクライ
アント２８から入力された場合について説明する。

【０１３６】この場合、前記要求のシーケンスは、 第１要求：ＡｄｄＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域
名＝東京、組織名＝ＡＢＣ、組織単位名＝営業部””一
般名＝○×礼子、オブジェクトクラス＝人、姓＝○×、
内線番号＝２２２” 第２要求：ｓｔａｒｔ 第３要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部、一般名＝○×礼子”、（ｒｅｐｌａｃｅ（内線番
号、”３３３”）） 第４要求：ＭｏｄｉｆｙＤＮＲｅｑｕｅｓｔ ”国名＝
ＪＰ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営
業部、一般名＝○×礼子”、”一般名＝□◇礼子”、ｔ
ｒｕｅ、”国名＝ＪＰ、地域名＝東京、組織名＝ＡＢ
Ｃ、組織単位名＝開発部” 第５要求：ＭｏｄｉｆｙＲｅｑｕｅｓｔ ”国名＝Ｊ
Ｐ、地域名＝東京、組織名＝ＡＢＣ、組織単位名＝開発
部、一般名＝□◇礼子”、（ａｄｄ（姓、”□◇”） 第６要求：ｃａｎｃｅｌ である。

【０１３７】ここで、第１要求入力後のディレクトリ情
報ツリーは図３２に示されるようになっており、前記第
１要求は、第２要求のｓｔａｒｔの前であるので、ｃａ
ｎｃｅｌ処理の対象にはならない。したがって、第３要
求〜第５要求までがｃａｎｃｅｌ処理の対象になる。

【０１３８】そして、第４要求入力時に、属性差分表に
データ（”国名＝ＪＰ、地域名＝東京、組織名＝ＡＢ
Ｃ、組織単位名＝営業部、一般名＝○×礼子”、内線番
号、”３３３”）を追加しようとすると、既に同じ主キ
ーのデータが前記エントリ差分表に存在するため、主キ
ー制約違反になり、追加することができない。しかし、
このエラーは単に無視される。

【０１３９】次に、第５要求入力後において、ディレク
トリ情報ツリーは図３３に示されるようになっており、
エントリ差分表は図３４に示されるようになっており、
また、属性差分表は図３５に示されるようになってい
る。

【０１４０】続いて、第６要求のｃａｎｃｅｌが入力さ
れると、差分表の逆操作を行う。該逆操作は、まず、エ
ントリ差分表のデータから行われ、（‘国名＝ＪＰ、地
域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業部、一
般名＝○×礼子’）を追加する。そのために、属性差分
表から該当するエントリの属性を検索した後、ＬＤＡＰ
の要求として、ＡｄｄＲｅｑｕｅｓｔ ”国名＝ＪＰ、
地域名＝東京、組織名＝ＡＢＣ、組織単位名＝営業
部””内線番号＝２２２、オブジェクトクラス＝人、一
般名＝○×礼子、姓＝○×”を発行する。また、検索し
たデータは属性差分表から削除する。

【０１４１】さらに、（”国名＝ＪＰ、地域名＝東京、
組織名＝ＡＢＣ、組織単位名＝開発部、一般名＝□◇礼
子”）を削除する。そのために、ＬＤＡＰの要求とし
て、ＤｅｌＲｅｑｕｅｓｔ ”国名＝ＪＰ、地域名＝東
京、組織名＝ＡＢＣ、組織単位名＝開発部、一般名＝□
◇礼子”を発行する。

【０１４２】次に、属性差分表のデータに基づいて、属
性の逆操作を行う。まず、（”国名＝ＪＰ、地域名＝東
京、組織名＝ＡＢＣ、組織単位名＝営業部、一般名＝□
◇礼子”、姓、”○×”）に置き換える。そのために、
ＬＤＡＰの要求として、ＭｏｄｉｆｙＲｅｑｕｅｓｔ
”国名＝ＪＰ、地域名＝東京、組織名＝ＡＢＣ、組織
単位名＝開発部、一般名＝□◇礼子”、（ｒｅｐｌａｃ
ｅ（姓、”○×”））を発行する。これは、既にエント
リがないためエラーとなるが単に無視する。

【０１４３】最後に、差分表の内容を全て削除してｃａ
ｎｃｅｌ処理が終了する。そして、ｃａｎｃｅｌの結
果、図２８に示されるディレクトリ情報ツリーに復元す
ることができることがわかる。

【０１４４】このように、本実施の形態においては、デ
ィレクトリに対して同じエントリ又は属性に対する変更
が複数存在しても、最初のデータのみを保存するので、
差分データを節約することができる。しかも、データの
更新時間を必要としないので更新量が膨大になっても、
メモリや２次記憶をそれほど消費することなく、処理時
間を短縮することができる。

【０１４５】また、ＲＤＢＭＳ２２の機能を活用して同
じ主キーに対する操作かどうかを判定するので、実現も
容易である。さらに、他のクライアント２８がいつでも
データを参照及び更新することが可能である。

【０１４６】なお、本発明は前記実施の形態に限定され
るものではなく、本発明の趣旨に基づいて種々変形させ
ることが可能であり、それらを本発明の範囲から排除す
るものではない。

【０１４７】

【発明の効果】以上詳細に説明したように、本発明によ
れば、アンドゥ処理システムにおいては、クライアント
が使用するデータが表形式で格納されるリレーショナル
データベースと、差分情報を格納するアンドゥ情報格納
部と、アンドゥ可能か否かのフラグを格納するアンドゥ
モード格納部と、データ処理を実行するデータ処理部と
を有し、前記差分情報は、表が定義された時点で作成さ
れて格納され、前記データ処理部は、クライアントから
のコマンドが変更処理であり、かつ、アンドゥ可能であ
る場合、前記差分情報を変更して前記表を更新する。

【０１４８】また、本発明によれば、アンドゥ処理方法
においては、クライアントが使用するデータをリレーシ
ョナルデータベースに表形式で格納し、表が定義される
と、差分情報を作成してアンドゥ情報格納部に格納し、
前記クライアントからのコマンドが変更処理であり、か
つ、アンドゥ可能である場合、前記差分情報を変更して
前記表を更新する。

【０１４９】この場合、同じ主キーに対する変更が複数
存在しても、最初のデータのみを保存するので差分デー
タを節約することができる。しかも、データの更新時刻
を必要としないので更新量が膨大になっても、メモリや
２次記憶をそれほど消費することなく、処理時間を短縮
することができる。また、他のクライアントがいつでも
データを参照及び更新することが可能である。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態におけるデータ編集
システムの構成を示す図である。

【図２】本発明の第１の実施の形態における社員表の例
を示す図である。

【図３】本発明の第１の実施の形態における部門表の例
を示す図である。

【図４】本発明の第１の実施の形態における図２のアン
ドゥ情報としての社員差分表を示す図である。

【図５】本発明の第１の実施の形態における図３のアン
ドゥ情報としての部門差分表を示す図である。

【図６】本発明の第１の実施の形態における通常モード
のデータ処理部のフローチャートを示す図である。

【図７】本発明の第１の実施の形態におけるアンドゥ可
能モードのデータ処理部のフローチャートを示す図であ
る。

【図８】本発明の第１の実施の形態における社員表の他
の例を示す図である。

【図９】本発明の第１の実施の形態における部門表の他
の例を示す図である。

【図１０】本発明の第１の実施の形態における図８のア
ンドゥ情報としての社員差分表を示す図である。

【図１１】本発明の第１の実施の形態における図９のア
ンドゥ情報としての部門差分表を示す図である。

【図１２】本発明の第１の実施の形態における社員表の
更に他の例を示す図である。

【図１３】本発明の第１の実施の形態における部門表の
更に他の例を示す図である。

【図１４】本発明の第１の実施の形態における図１２の
アンドゥ情報としての社員差分表を示す図である。

【図１５】本発明の第１の実施の形態における図１３の
アンドゥ情報としての部門差分表を示す図である。

【図１６】本発明の第２の実施の形態におけるディレク
トリサーバの構成を示す図である。

【図１７】本発明の第２の実施の形態におけるＬＤＡＰ
の追加操作の構文を示す図である。

【図１８】本発明の第２の実施の形態におけるＬＤＡＰ
の削除操作の構文を示す図である。

【図１９】本発明の第２の実施の形態におけるＬＤＡＰ
の変更操作の構文を示す図である。

【図２０】本発明の第２の実施の形態におけるＬＤＡＰ
のＲＤＮ変更操作の構文を示す図である。

【図２１】本発明の第２の実施の形態におけるＬＤＡＰ
の拡張操作と拡張応答の構文を示す図である。

【図２２】本発明の第２の実施の形態におけるエントリ
差分表を示す図である。

【図２３】本発明の第２の実施の形態における属性差分
表を示す図である。

【図２４】本発明の第２の実施の形態における通常モー
ドのデータ処理部のフローチャートを示す図である。

【図２５】本発明の第２の実施の形態におけるアンドゥ
可能モードのデータ処理部のフローチャートを示す図で
ある。

【図２６】本発明の第２の実施の形態におけるディレク
トリ情報ツリーを示す図である。

【図２７】本発明の第２の実施の形態における変更操作
後のディレクトリ情報ツリーを示す図である。

【図２８】本発明の第２の実施の形態における属性差分
表を示す図である。

【図２９】本発明の第２の実施の形態における他の変更
操作後のディレクトリ情報ツリーを示す図である。

【図３０】本発明の第２の実施の形態におけるエントリ
差分表を示す図である。

【図３１】本発明の第２の実施の形態における他の属性
差分表を示す図である。

【図３２】本発明の第２の実施の形態における第１要求
処理後のディレクトリ情報ツリーを示す図である。

【図３３】本発明の第２の実施の形態における第５要求
処理後のディレクトリ情報ツリーを示す図である。

【図３４】本発明の第２の実施の形態における他のエン
トリ差分表を示す図である。

【図３５】本発明の第２の実施の形態における更に他の
属性差分表を示す図である。

【符号の説明】

１２ データ処理部 １３、２４ 通信制御部 １４、２１ アンドゥ情報格納部 １５、２７ アンドゥモード格納部 １６、２８ クライアント ２０ ディレクトリサーバ ２６ アンドゥ処理部

Claims (8)

【特許請求の範囲】
1. 【請求項１】 （ａ）クライアントが使用するデータが
   表形式で格納されるリレーショナルデータベースと、
   （ｂ）差分情報を格納するアンドゥ情報格納部と、
   （ｃ）アンドゥ可能か否かのフラグを格納するアンドゥ
   モード格納部と、（ｄ）データ処理を実行するデータ処
   理部とを有し、（ｅ）前記差分情報は、表が定義された
   時点で作成されて格納され、（ｆ）前記データ処理部
   は、クライアントからのコマンドが変更処理であり、か
   つ、アンドゥ可能である場合、前記差分情報を変更して
   前記表を更新することを特徴とするアンドゥ処理システ
   ム。
2. 【請求項２】 前記クライアントからのコマンドを受け
   付け、応答を返す通信制御部を有する請求項１に記載の
   アンドゥ処理システム。
3. 【請求項３】 前記アンドゥ情報格納部は、前記差分情
   報として、エントリ差分表及び属性差分表を格納する請
   求項１又は２に記載のアンドゥ処理システム。
4. 【請求項４】 前記アンドゥ情報格納部は、最初の差分
   情報のみを格納する請求項１〜３のいずれか１項に記載
   のアンドゥ処理システム。
5. 【請求項５】 ディレクトリ情報ツリーを格納するディ
   レクトリサーバ内に構築される請求項１〜４のいずれか
   １項に記載のアンドゥ処理システム。
6. 【請求項６】 （ａ）クライアントが使用するデータを
   リレーショナルデータベースに表形式で格納し、（ｂ）
   表が定義されると、差分情報を作成してアンドゥ情報格
   納部に格納し、（ｃ）前記クライアントからのコマンド
   が変更処理であり、かつ、アンドゥ可能である場合、前
   記差分情報を変更して前記表を更新することを特徴とす
   るアンドゥ処理方法。
7. 【請求項７】 前記差分情報として、エントリ差分表及
   び属性差分表をアンドゥ情報格納部に格納する請求項６
   に記載のアンドゥ処理方法。
8. 【請求項８】 最初の差分情報のみを格納する請求項６
   又は７に記載のアンドゥ処理方法。