JP2001014328A - データベースシステムとそこで用いるディレクトリデータ構造 - Google Patents

Abstract

(57)【要約】 【課題】２レコードを関連付ける情報であるリンクを、
別個のリンクへ変換可能なデータベースシステムを提供
する。 【解決手段】少なくとも１以上のレコードに関する情
報、及びレコード間の関連を表すリンクを格納する手段
を備えたデータベースを有し、異種のオブジェクトを表
すレコード間のリンクである異種リンクが、前記格納手
段によって前記データベースに格納されているデータベ
ースシステムであって、前記格納手段を用いて同種のオ
ブジェクトを表す複数のレコード間のリンクである同種
リンクを格納し、異種リンクによりリンクされた２レコ
ードそれぞれに関して、同種リンクによるリンク対象レ
コードを特定することで、或る異種リンクを別個の異種
リンクへ変換するリンク変換手段を有する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークに接
続された複数の情報処理装置から成るデータベースシス
テムに関する。

【０００２】

【従来の技術】データベースシステムは、例えば、企業
内及び企業間、または自治体などでの情報システムにお
ける、氏名、電話番号などの個人情報や人事情報の管理
に、また、生産現場での部品管理などに広く用いられて
いる。個人情報や人事情報の管理に用いられるデータベ
ースシステムの一つとして、ディレクトリサービスを提
供するディレクトリシステムが挙げられる。ディレクト
リサービスとは、電子メールの送信相手の姓名等から電
子メールの宛先を検索できるサービスであり、電子メー
ルシステムにおける電子的な電話帳機能として利用され
ている。ディレクトリサービスに関する標準として、Ｃ
ＣＩＴＴの勧告であるＸ．５００（ＩＳＯ９５９４）が
挙げられる。Ｘ．５００は、ディレクトリサービスをク
ライアント−サーバ型の分散システム・アーキテクチャ
として規定しており、クライアント−サーバ間の通信プ
ロトコルとしてＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎ
ｔｅｒｃｏｎｎｅｃｔｉｏｎ）の７レイヤ構造に従った
ＤＡＰ（Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏ
ｃｏｌ）を定めている。

【０００３】Ｘ．５００準拠のディレクトリサービス
は、木構造（ディレクトリツリー）として階層管理され
たデータモデルを有する。木の枝葉に相当する個所に
は、ディレクトリエントリが配置される。このディレク
トリエントリは、データベースにおけるレコードに相当
する。各々のエントリは、同一の親エントリを持つエン
トリ間で一意である相対名称（ＲＤＮ：Relative Disti
nguished Name）と、ディレクトリツリーの根（ルー
ト）からの経路を示すＲＤＮの列である名称（ＤＮ：Di
stinguished Name）で一意に識別される。

【０００４】各々のエントリはユーザのメールアドレス
に加え、姓名、電話番号、ＦＡＸ番号、写真等、様々な
情報を属性として記憶可能である。属性のうち、相対名
称に使用されるものを名前付け属性と呼ぶ。例えば、国
エントリ、会社エントリ、組織エントリ、及びユーザエ
ントリの名前付け属性には、それぞれｃ（ｃｏｕｎｔｒ
ｙ）、ｏ（ｏｒｇａｎｉｚａｔｉｏｎ）、ｏｕ（ｏｒｇ
ａｎｉｚａｔｉｏｎａｌＵｎｉｔ）、及びｃｎ（ｃｏｍ
ｍｏｎＮａｍｅ）が使用される事が多い。従って、例え
ば日本の会社であるＡＢＣ会社の総務部を表すエントリ
の名称は、「ｏｕ＝総務部，ｏ＝ＡＢＣ会社，ｃ＝日
本」となる。また、エントリは、必ず１つ以上のオブジ
ェクトクラスに属する。ここで、オブジェクトクラスと
は、或るエントリに存在しなければならない必須の属
性、及び存在しても良い属性の集合を定義する。このオ
ブジェクトクラス定義とディレクトリツリーの定義をあ
わせ、ディレクトリスキーマと呼ぶ。

【０００５】一方、インターネットにおける標準化機関
であるＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉ
ｎｇ Ｔａｓｋ Ｆｏｒｃｅ）は、ＴＣＰ／ＩＰスタック
上で動作するディレクトリ・クライアント−サーバ間プ
ロトコルとして「ＬＤＡＰ：Ｌｉｇｈｔ Ｗｅｉｇｈｔ
Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ
（ＲＦＣ２２５１）」を標準化した。ＬＤＡＰは、ＯＳ
Ｉスタック上で動作するＤＡＰに比べて軽量であること
が大きな利点である。最近の企業内、或いは企業間に跨
る大規模情報システムにおいては、電子メールシステム
やグループウェアなどの複数のアプリケーションを導入
している事が多く、システム管理者は新入社員の入社や
人事異動が発生する度に、複数のアプリケーションへユ
ーザ登録を行なう必要があり、その運用負荷は膨大なも
のであった。

【０００６】このような問題を解決する技術として、Ａ
Ｃａｈｎｅｒｓ Ｐｕｂｌｉｃａｔｉｏｎ社の「ＤＡＴ
ＡＭＡＴＩＯＮ」（１９９６年５月１日号）の４８頁か
ら５４頁にて紹介されているようなメタディレクトリ技
術が挙げられる。メタディレクトリ技術とは、複数アプ
リケーションのユーザ情報をディレクトリサービスに登
録し、ユーザ情報の更新を全てディレクトリサービスに
対して行なうようにする事で、ユーザ情報の管理を一元
化するものである。

【０００７】また、大規模情報システムにおいて実際に
稼動しているアプリケーションの多くは、ユーザ情報を
独自のデータベースを用いて、独自の形式で登録、管理
している。そのため、メタディレクトリ技術は、ディレ
クトリサービスに対して行われた更新を自動的にアプリ
ケーションのデータベースへ反映させる事により、ディ
レクトリサービスに登録されているユーザ情報と、各ア
プリケーションのデータベースに登録されているユーザ
情報との同期をとるディレクトリ同期技術と組み合わさ
れるのが一般的である。

【０００８】図２に、上記のようなメタディレクトリ技
術で用いられるディレクトリデータの一般的な論理構造
を示す。ディレクトリデータ１００は、共通ディレクト
リ１０１と、固有ディレクトリ１０１’から構成され
る。まず固有ディレクトリ１０１’は、ディレクトリサ
ーバにてアプリケーションのデータを一元管理可能なよ
うに、各アプリケーションが扱うデータ１１０のコピー
を登録したものである。固有ディレクトリ１０１’内の
エントリ、すなわち固有エントリの種類には、ユーザ情
報を登録する固有ユーザエントリ１０２’、組織情報を
登録する固有組織エントリ１０３’、グループ情報を登
録する固有グループエントリ１０６’などがある。ま
た、複数のアプリケーションのデータをメタディレクト
リシステムにて一元管理する場合、固有ディレクトリも
複数存在する。

【０００９】ここで、アプリケーションのデータには、
氏名や電話番号など、複数のアプリケーションが共通に
扱っている情報がある。そこでメタディレクトリ技術で
は、全アプリケーションに共通な情報を登録する共通デ
ィレクトリ１０１をディレクトリデータ１００に設け、
共通ディレクトリ１０１のデータが更新された時に、そ
の更新を各アプリケーションの固有ディレクトリへ反映
させる。このような処理を行なう事により、複数アプリ
ケーションに共通な情報の一元管理が可能となり、シス
テム管理者の管理負担を大幅に軽減可能である。

【００１０】共通ディレクトリ１０１内のエントリ、す
なわち共通エントリの種類には、ユーザ情報を登録する
共通ユーザエントリ１０２、組織情報を登録する共通組
織エントリ１０３、グループ情報を登録する共通グルー
プエントリ１０６などがある。これらの共通エントリ
は、ＣＣＩＴＴ勧告であるＸ．５２１や「Ａ Ｓｕｍｍ
ａｒｙ ｏｆ ｔｈｅ Ｘ．５００（９６） Ｕｓｅｒ Ｓ
ｃｈｅｍａ ｆｏｒ ｕｓｅ ｗｉｔｈ ＬＤＡＰｖ３（Ｒ
ＦＣ２２５６）」で定義されている標準的なディレクト
リスキーマに従って登録される。Ｘ．５２１は、組織階
層を図２に示したようにディレクトリツリーで表現する
ことを規定している。

【００１１】さらに、共通エントリから固有エントリへ
のリンク１０５により、２エントリが同一のユーザ、組
織に対応している事を表す。ここでリンクとは２エント
リ間を関連付ける情報の事を指し、共通エントリと固有
エントリの間のリンクを同種リンクと呼ぶ。一般に、リ
ンクは関連するエントリの名称を保持する属性として実
装する。その属性をリンク属性と呼び、エントリへリン
ク属性を追加する事でディレクトリデータへリンクを格
納する。また、リンクによって関連付けられた２エント
リの内、リンク属性を持つエントリをリンク元エント
リ、他方のエントリをリンク先エントリと呼ぶ。図２で
は「経理課」エントリから「Ａｃｃｏｕｎｔｉｎｇ」エ
ントリへの同種リンクを記述しているが、実際は全ての
共通エントリから固有エントリへ同種リンクが格納され
る。固有ディレクトリが複数存在する場合は、上記同種
リンクも各々複数存在する。

【００１２】ここで、共通ディレクトリから固有ディレ
クトリへの同期を行なう際、共通ディレクトリと固有デ
ィレクトリのデータ構造は異なっているため、共通ディ
レクトリのデータをそのまま固有ディレクトリへ登録す
る事ができない。例えば、共通ディレクトリでは名前情
報を姓と名という別の属性として登録、管理するのに対
して、固有ディレクトリでは氏名という一つの属性とし
て登録、管理する場合がある。そこで、共通ディレクト
リのデータを、固有ディレクトリのデータへ変換する、
或いはその逆を行なう事が必要である。このような変換
をスキーマ変換と呼ぶ。

【００１３】共通エントリの属性から固有エントリの属
性を生成する、従来のスキーマ変換の例を図３に示す。
共通ユーザエントリ１０２から固有ユーザエントリ１０
２’へのスキーマ変換を行なう場合、共通ユーザエント
リ１０２のｃｎ（ＣｏｍｍｏｎＮａｍｅ：一般名）から
固有ユーザエントリ１０２’のｎａｍｅＪＰ（日本語氏
名）への変換は単純な文字列のコピーによって実行され
る。また、共通ユーザエントリ１０２のｓｎ（ＳｕｒＮ
ａｍｅ：姓）とｇｉｖｅｎＮａｍｅ（名）の組から固有
ユーザエントリ１０２’のｎａｍｅ（英語氏名）への変
換は文字列の結合によって実行される。共通ユーザエン
トリ１０２のｌｉｎｋは同種リンク属性であり、固有ユ
ーザエントリ１０２’の名称を値として持つ。同種リン
ク属性はスキーマ変換の対象外である。このように、従
来のスキーマ変換は文字列操作を用いて属性値の変換を
行なっていた。

【００１４】

【発明が解決しようとする課題】ところで前出のＸ．５
２１は、グループに所属するメンバは、グループエント
リからユーザエントリへのリンクを用いて表す事を規定
している。例えば図２において、ユーザ「山田太郎」が
グループ「ＥＦＧ開発プロジェクト」のメンバである場
合、共通ディレクトリ１０１では、「ＥＦＧ開発プロジ
ェクト」エントリ１０６から「山田太郎」エントリ１０
８へのリンク１０７を用いて、固有ディレクトリ１０
１’では、「ＥＦＧ−Ｐｒｏｊｅｃｔ」エントリ１０
６’から「ＴａｒｏｕＹａｍａｄａ」エントリ１０８’
へのリンク１０７’を用いてメンバ関係を表す。上記の
ような、異種オブジェクトを表す２エントリを関連付け
るリンクを、同種リンクとは区別して異種リンクと呼
ぶ。図３で挙げた例では、共通グループエントリ１０６
や固有グループエントリ１０６’のｍｅｍｂｅｒ属性
が、メンバ関係を表す異種リンク属性である。

【００１５】ここで、共通エントリの名称と固有エント
リの名称は、異なるデータから構成されるため、共通エ
ントリの異種リンク属性から固有エントリの異種リンク
属性への変換は文字列操作だけでは行なえない。つま
り、従来のスキーマ変換は異種リンク属性の変換に対応
しておらず、システム管理者は共通ディレクトリの異種
リンク属性と固有ディレクトリの異種リンク属性を個別
に管理する必要があった。

【００１６】そのため、人事異動、組織改正、新入社員
入社時などに、システム管理者は、同一内容のメンバ情
報の更新作業を複数アプリケーションに対して個別に実
行しなければならなかった。例えば、グループのメンバ
情報を管理しているアプリケーションを運用している企
業のシステム管理者は、人事異動が発生する度、まず共
通ディレクトリに登録されているメンバ情報を更新し、
次にそれと同様の作業を固有ディレクトリに対しても行
なう必要があった。更に具体的には、図２のＡＢＣ会社
を例にとると、「山田太郎」が人事異動に伴い「ＥＦＧ
開発プロジェクト」から外れる時、まず共通ディレクト
リの異種リンク１０７を削除し、次に固有ディレクトリ
の異種リンク１０７’を削除する必要があった。更に、
メンバ情報のように異種リンクで表現される情報は、ユ
ーザの上長情報や装置の所有者情報など多岐に渡るた
め、従来のスキーマ変換はシステム管理者の運用負荷を
軽減する技術として充分な機能を備えているとはいえな
かった。

【００１７】また、組織階層をディレクトリツリーで表
現するディレクトリデータ構造には、人事異動時にユー
ザエントリの削除と追加という２つの操作が必要である
ためディレクトリサーバへの負荷が高く、加えてそれら
の操作の間に停電等の障害が発生した場合、削除したデ
ータの回復が困難であるという問題がある。特に、他の
事業所に組織毎移動する場合には、その組織に所属する
全ユーザエントリの削除、追加が必要であり、上記の問
題が深刻なものとなる。更に上記の問題が生じるため、
従来のメタディレクトリ技術は、組織階層変更の同期に
対応していなかった。そのため、共通ディレクトリの組
織階層の変更は、自動的には固有ディレクトリへ反映さ
れず、同様の組織階層変更作業を共通ディレクトリと固
有ディレクトリの両方に対して行なう必要があった。

【００１８】このような課題は、企業内、或いは企業間
に跨る大規模情報システムにおける電子メールシステム
やグループウェアなどの複数のアプリケーションを使用
している環境に限られるものではなく、大規模なデータ
ベースシステムを導入している一般的な環境に発生する
ものである。 本発明の第一の目的は、データベースシステムにおいて
複数のアプリケーションが稼働している環境におけるデ
ータベースの一元的な管理を容易にする技術と、それを
用いたデータベースシステムを提供することである。 具体的には、ディレクトリシステムにおいて、複数のア
プリケーションが稼働している環境におけるディレクト
リデータの一元的な管理を容易にする技術と、それを用
いたディレクトリシステムを提供することである。 さらに具体的には、ユーザの所属組織やグループのメン
バ等の異種リンクで表現されたデータの管理負荷を軽減
可能なスキーマ変換方法と、それを用いたディレクトリ
システムとを提供することである。本発明の第二の目的
は、第一の目的を達成するに適したディレクトリデータ
構造を提供することにある。

【００１９】

【課題を解決するための手段】上記の第一の目的を達成
するため、本発明は、少なくとも１以上のレコードに関
する情報、及びレコード間の関連を表すリンクを格納す
る手段を備え、異種のオブジェクトを表すレコード間の
リンクである異種リンクが、前記格納手段によって前記
データベースに格納されているデータベースシステムに
おいて、前記格納手段を用いて、同種のオブジェクトを
表す複数レコード間のリンクである同種リンクを格納
し、異種リンクによりリンクされた複数レコードそれぞ
れに関して、同種リンクによるリンク対象レコードを特
定する事で、或る異種リンクを別個の異種リンクへ変換
するリンク変換手段を有する事を特徴とするデータベー
スシステムを提供する。

【００２０】かかるデータベースシステムにより、少な
くとも１以上のアプリケーションが扱う情報を格納する
レコードと、全アプリケーションに共通の情報を格納す
るレコードが前記データベースに格納されている場合、
共通情報を格納するレコード間の異種リンクの更新を、
アプリケーション情報を格納するレコード間の異種リン
クへ自動的に反映する事が可能となり、複数のアプリケ
ーションが異種リンクを登録、管理する場合において
も、システム管理者は共通情報の異種リンクのみメンテ
ナンスすればよく、異種リンクの管理負荷を大幅に削減
可能となる。

【００２１】また、第二の目的を達成するため、本発明
は、アプリケーションデータをディレクトリサーバにて
登録、管理する際のディレクトリデータ構造であって、
ディレクトリデータが、アプリケーションが扱うデータ
を登録するディレクトリツリーと、全アプリケーション
に共通なデータを登録するディレクトリツリーから構成
され、同種のオブジェクトを表す異ディレクトリツリー
のエントリ同士が、リンクによって関連付けられ、更
に、あるディレクトリツリー内での各エントリ間の関係
を、リンクを用いて表現するデータ構造を提供する。デ
ィレクトリツリーを使わず、リンクを用いたデータ構造
を提供する。

【００２２】このデータ構造により、たとえば、ユーザ
の所属組織の変更を、ユーザエントリの変更操作で行な
う事ができ、大規模な人事異動や組織改正が発生した時
の、ディレクトリサーバの負荷を低減する事が可能とな
る。また、前記スキーマ変換手段と組み合わせて用いる
事で、複数のアプリケーションツリーに所属関係を表す
異種リンクが登録されている場合においても、システム
管理者は共通データを登録するディレクトリツリーの、
所属関係を表す異種リンクのみメンテナンスすればよ
く、所属組織情報の管理負荷を大幅に削減可能となる。

【００２３】

【発明の実施の形態】以下、本発明の実施例について図
面を用いて説明する。以下の図中、同一の部分には同一
の符号を付加する。尚、本実施例においては、本発明を
適用するデータベースとしてディレクトリサービスを例
にとり説明するが、本発明は、例えばリレーショナルデ
ータベース管理システム等、様々なデータベースに適用
可能である。本発明のデータベースは、あるエントリデ
ータを、スキーマの異なるエントリデータへ変換するも
のであり、特に、異なるディレクトリツリー間での異種
リンクの変換が可能であるという特徴を持つ。以降の実
施例では、リンクを関連付けるエントリの名称を保持す
る属性として実装するものとする。但し、名称ではなく
ＩＤ番号を用いてリンクを表現する場合も本発明は有効
である。

【００２４】図１は、本発明を適用したスキーマ変換部
の機能構造である。スキーマ変換部１は、スキーマ変換
制御部２、文字列操作部３、リンク変換部４、リンク記
憶領域６、ディレクトリアクセス部７を有している。ス
キーマ変換制御部２は、入力された変換元エントリデー
タに対して、文字列操作部３、リンク変換部４を呼び出
すことでスキーマ変換を実行し、その結果である変換先
エントリデータを出力する。文字列操作部３は、単純コ
ピーや結合などの文字列操作を実行する。リンク変換部
４は、変換元エントリが属しているディレクトリツリー
における異種リンク属性を、変換先エントリが属してい
るディレクトリツリーにおける異種リンク属性へ変換す
る。ディレクトリアクセス部７は、ディレクトリサーバ
に対して検索要求を発行する。リンク記憶領域６は、同
種リンクのリンク元エントリとリンク先エントリの名称
を一時的に記憶する領域である。この領域は、ディレク
トリデータの初期登録などのバッチ処理時に、ディレク
トリサーバへの同一の検索要求を重複して発行しないよ
うにする事で、バッチ処理の所要時間を短縮するために
使用される。

【００２５】第一の実施例は、図１のようなスキーマ変
換部１をディレクトリサーバに組み込んだメタディレク
トリシステムである。第一の実施例について、図４から
図１２と図２３、図２４、図２６、図２７、図２９を用
いて説明する。図４は、第一の実施例であるメタディレ
クトリシステムの機能構成であり、ＬＡＮなどのネット
ワーク３０で、ディレクトリサーバ１０、ディレクトリ
クライアント４０、アプリケーションサーバ５０が接続
されている。ディレクトリサーバ１０は、ディレクトリ
データ１００をデータベース（ＤＢ）１１に記憶し、ア
プリケーションサーバ５０は、アプリケーションデータ
１１０をＤＢ５１に記憶する。

【００２６】ディレクトリサーバ１０は、ディレクトリ
クライアント４０やアプリケーションサーバ５０との間
で通信処理を実行する通信制御部２４、受信したアクセ
ス要求を解析するプロトコル解析部２６、受信したアク
セス要求に従いＤＢ１１を検索、更新するＤＢ制御部２
５、受信したアクセス要求が追加、変更、名称変更、削
除要求の何れかであった場合、ディレクトリ同期処理を
行なうディレクトリ同期部２０を有している。さらにデ
ィレクトリサーバ１０は、スキーマ変換規則を記述する
スキーマ変換規則ファイル２８、前記スキーマ変換規則
ファイル２８の読み込みと書き込みを行なうファイルア
クセス部２７、ユーザによるキー入力やディスプレイへ
の表示を制御するユーザインターフェース制御部２９を
有している。

【００２７】ディレクトリ同期部２０は、共通ディレク
トリ１０１、固有ディレクトリ１０１’、及びアプリケ
ーションデータ１１０の同期をとる。そのために、共通
ディレクトリ１０１の更新を固有ディレクトリ１０１’
とアプリケーションデータ１１０へ反映する処理と、固
有ディレクトリ１０１’の更新をアプリケーションデー
タ１１０と共通ディレクトリ１０１へ反映する処理を行
なう。

【００２８】ディレクトリ同期部２０は、プロトコル解
析部２６からエントリ更新内容を取得し、各部の呼び出
しを行う同期処理制御部２１、図１で説明したスキーマ
変換部１、ＤＢ制御部２５に対してディレクトリデータ
１００の更新、検索要求を発行するディレクトリアクセ
ス部２２、アプリケーションデータ１１０を更新するア
プリケーションアクセス部２３を有している。アプリケ
ーションアクセス部２３は、同期対象となるアプリケー
ションに依存した手段を用いて、アプリケーションデー
タの更新処理を行う。

【００２９】図５は、本実施例のディレクトリサーバ１
０のシステム構成である。

【００３０】ディレクトリサーバ１０は、中央演算装置
ＣＰＵ１４、ハードディスク等の2次記憶装置（以下、
磁気ディスクという）１８、主記憶装置メモリ(以下、
主メモリという)１２、バス１３、表示装置などの出力
装置（以下、ディスプレイという）１５、入力装置(以
下、キーボード１７、マウス１６という)から構成され
る。

【００３１】図４のＤＢ１１は、ディレクトリデータ１
００を磁気ディスク１８上のファイルとして格納する。
また、スキーマ変換規則ファイル２８も、磁気ディスク
１８に格納される。主メモリ１２には、通信制御プログ
ラム２４、ＤＢ制御プログラム２５、プロトコル解析プ
ログラム２６、ディレクトリ同期プログラム２０、ファ
イルアクセスプログラム２７、ユーザインターフェース
プログラム２９が格納される。ディレクトリ同期プログ
ラム２０はさらに、スキーマ変換プログラム１、同期処
理制御プログラム２１、ディレクトリアクセスプログラ
ム２２、アプリケーションアクセスプログラム２３から
構成される。これらのプログラムは、あらかじめ、また
は可搬型記録媒体からの読み込み、またはサーバ１０が
接続されたネットワークに接続された他のサーバからの
ダウンロードにより、磁気ディスク１８に格納され、必
要に応じて主メモリ１２に転送された後、ＣＰＵ１４で
実行される。本実施例のディレクトリクライアント４
０、及びアプリケーションサーバ５０のシステム構成は
従来のものと同様である。

【００３２】次に、本実施例におけるスキーマ変換規則
ファイル２８を、図２４を用いて説明する。４００は、
スキーマ変換規則ファイル２８の情報記述方法であり、
変換先属性名４０２、文字列のコピーや結合、リンク変
換などのスキーマ変換の方法を指定する変換種別４０
３、変換元属性名４０４をカンマで区切って列挙したも
のである。文字列の結合などに対応するため、変換元属
性名４０４は複数指定可能である。２つ以上のスキーマ
変換規則を定義する場合は、各々を別の行に記述する。
スキーマ変換規則ファイル２８の定義例として、図３で
示したスキーマ変換を行なうためのスキーマ変換規則フ
ァイルを４０１に示す。

【００３３】次に、スキーマ変換規則ファイル２８の作
成操作例を、所属組織へのリンク変換を例にとり説明す
る。図２３の３２０は、ディレクトリデータ１００にお
ける組織階層の表現方法の設定画面表示例であり、ユー
ザはディレクトリサーバ１０のディスプレイ１５、キー
ボード１７、マウス１６等を用いて各パラメータを設定
する。組織階層の表現方法として、ＣＣＩＴＴ勧告Ｘ．
５２１で推奨されているようにディレクトリツリーを用
いる方法と、本発明の特徴である異種リンクを用いる方
法から選択できるものする。

【００３４】画面３２０は、組織階層の表現方法とし
て、ディレクトリツリーを用いる事を指示するボタン３
２１、リンクを用いる事を指示するボタン３２２、共通
ディレクトリ１０１における、所属関係を表すリンク属
性の名称を入力する領域３２３、固有ディレクトリ１０
１’における、所属関係を表すリンク属性の名称を入力
する領域３２４、組織階層の設定を指示するボタン３２
５、そして操作をキャンセルするためのボタン３２６か
ら成る。ボタン３２１と３２２は、どちらか一方を押す
事ができる。また、領域３２３、３２４への入力は、ボ
タン３２２が押された時に行なえる。

【００３５】画面３２０において、ボタン３２２が押さ
れ、かつ領域３２３、３２４に有効な属性名が入力され
ている状態でボタン３２５が押された場合、ユーザイン
ターフェース制御部が領域３２３、３２４に入力された
属性名を基に、スキーマ変換規則ファイル２８に、図２
４の４０１の最後の行に示したような所属組織リンク変
換を行なうスキーマ変換規則を書き込む。一方、ボタン
３２１が押された状態でボタン３２５が押された場合、
スキーマ変換規則ファイル２８には何も書き込まれな
い。

【００３６】ここで、もし所属関係を表すリンク属性の
名称が固定である場合は、領域３２３、３２４は必要な
い。

【００３７】図６は、本実施例において用いるデータ構
造である。最初に、リンク記憶領域６は、ディレクトリ
サーバの検索による取得した同種リンクのリンク元エン
トリとリンク先エントリの名称を一時的に記憶する領域
である。この領域は、ディレクトリサーバへの同一の検
索要求を重複して発行しないようにする事で、バッチ処
理の所要時間を短縮するために使用される。リンク記憶
領域６は、一度読み込んだ同種リンクによるエントリの
対応情報を記憶するリンク記憶テーブル２１０と、リン
ク記憶テーブル２１０を使用するか否かを指定するリン
ク記憶フラグ２１５から構成される。

【００３８】リンク記憶テーブル２１０は、共通エント
リの名称２１１と、その共通エントリと同種リンクによ
ってリンクされた固有エントリの名称２１２から構成さ
れる。リンク記憶テーブル２１０は配列構造を成し、複
数のレコードを格納可能である。例として、図２の「経
理課」エントリ１０３に関するリンク記憶テーブル２１
０の情報例を２１３に示す。本実施例では、リンク記憶
フラグ２１５には、「０」か「１」が格納され、それぞ
れ「リンク記憶テーブルを使用しない」、「リンク記憶
テーブルを使用する」旨を表すものとする。エントリ更
新内容６０は、ディレクトリデータ１００が更新された
時、プロトコル解析部２６がディレクトリ同期部２０
へ、その更新内容を渡す時に用いられるデータ構造であ
る。エントリ更新内容６０は、更新されたエントリの名
称６１、そのエントリに対する更新種別６２、そのエン
トリの属性に対する更新内容配列６３から構成される。
エントリ更新種別６２は、追加、変更、名称変更、削除
のいずれかである。属性更新内容配列６３は、次に説明
する属性更新内容７０の配列である。例として、図２の
「鈴木一郎」エントリ１０２が共通ディレクトリ１０１
へ追加された時のエントリ更新内容６０の情報例を６４
に示す。

【００３９】次に、属性更新内容７０は、ディレクトリ
同期部２０がスキーマ変換部１へ変換元エントリの属性
を渡す時、及びスキーマ変換部１がディレクトリ同期部
２０へスキーマ変換後の属性を渡す時に用いられるデー
タ構造である。属性更新内容７０は、更新された属性の
属性名７１、その属性に対する更新の種別７２、その属
性の属性値配列７３から構成される。属性更新種別７２
は、追加、置換、削除のいずれかである。例として、図
２の「鈴木一郎」エントリ１０２が共通ディレクトリ１
０１へ追加された時のエントリ更新内容６０の内、ｓｎ
に関する属性更新内容７０の情報例を７４に示す。

【００４０】図２９は、本実施例におけるディレクトリ
データのデータ構造である。以下で、図２との相違点に
ついて説明する。ユーザの所属組織はユーザエントリか
ら組織エントリへのリンクを用いて表す。例えば図２９
において、ユーザ「鈴木一郎」が「経理課」に所属して
いる場合、共通ディレクトリ１０１では、「鈴木一郎」
エントリ１０２から「経理課」エントリ１０３への異種
リンク１０４を用いて、固有ディレクトリ１０１’で
は、「ＩｃｈｉｒｏＳｕｚｕｋｉ」エントリ１０２’か
ら「Ａｃｃｏｕｎｔｉｎｇ」エントリ１０３’への異種
リンク１０４’を用いて所属関係を表す。同様にユーザ
「山田太郎」が「経理課」に所属している事を異種リン
ク１０９、及び異種リンク１０９’を用いて示す。同様
に、部と課の関係のような組織同士の所属関係も、共通
組織エントリ１０３間のリンクを用いて表す。また、組
織階層の最上位にあたるエントリは異種リンク属性を持
たない。例えば図２９において、ＡＢＣ会社の各部を組
織階層の最上位とする場合、総務部エントリは異種リン
ク属性を持たない。

【００４１】本発明は、例えば異種リンク１０４と異種
リンク１０４’を相互に変換可能とするデータベースシ
ステムを提供する。更に、同種のオブジェクトのデータ
を一括して取得する際の検索を高速化するために、オブ
ジェクトの種類毎にコンテナエントリを設けるのが一般
的である。例えば、共通ユーザエントリ１０２はコンテ
ナエントリ（図２９の「従業員情報」エントリ）直下に
全エントリが配置される。共通組織エントリ１０３、共
通グループエントリ１０６に関しても同様である。ま
た、固有ユーザエントリ１０２’もコンテナエントリ
（図２９の「Ｐｅｏｐｌｅ」エントリ）直下に全エント
リが配置される。固有組織エントリ１０３’、固有グル
ープエントリ１０６’に関しても同様である。

【００４２】次に、第一の実施例における、メタディレ
クトリシステム全体の処理の流れを、図２６と図２７で
説明する。図２６は、共通エントリを追加した時の処理
シーケンスである。共通エントリを変更、名称変更、削
除した時の処理シーケンスもほぼ同様である。ディレク
トリクライアント４０が発行した共通エントリの追加要
求８０をディレクトリサーバ１０が受信すると、プロト
コル解析部２６のプロトコル解析処理（図７で説明す
る）を経てディレクトリ同期部２０のエントリ追加処理
（図８で説明する）が開始される。まず、ディレクトリ
同期部２０がＤＢ制御部２５へ共通エントリの追加要求
８１を発行する。ＤＢ制御部２５は受信した追加要求８
１に基づきＤＢ１１を更新した後応答を返す。次に、デ
ィレクトリ同期部２０内のモジュールであるスキーマ変
換部１がスキーマ変換処理（図９、１０で説明する）を
実行し、共通エントリの属性を基に固有エントリの属性
を導出する。この時、共通エントリの属性に異種リンク
属性が含まれる場合、スキーマ変換部１内のモジュール
であるリンク変換部４がＤＢ制御部２５に対して検索要
求８２を発行し、その結果を用いて異種リンク属性の変
換を行なう。その後、スキーマ変換の結果に基づき、デ
ィレクトリ同期部２０がＤＢ制御部２５へ固有エントリ
の追加要求８３を発行する。ＤＢ制御部２５は受信した
追加要求８３に基づきＤＢ１１を更新した後応答を返
す。次に、ディレクトリ同期部２０がアプリケーション
サーバ５０に対してエントリの追加要求８４を発行す
る。アプリケーションサーバ５０は受信した追加要求８
４に基づきＤＢ５１を更新し、応答を返す。以上で、エ
ントリ追加処理は終了であり、ディレクトリサーバ１０
はディレクトリクライアント４０に応答を返す。

【００４３】図２７は、固有エントリを追加した時の処
理シーケンスである。固有エントリを変更、名称変更、
削除した時の処理シーケンスもほぼ同様である。 デ
ィレクトリサーバ１０が固有エントリの追加要求８５を
受信し、ディレクトリ同期部２０のエントリ追加処理が
開始されるまでは図２６と同様である。その後、ディレ
クトリ同期部２０がＤＢ制御部２５へ固有エントリの追
加要求８６を発行する。ＤＢ制御部２５は受信した追加
要求８１に基づきＤＢ１１を更新した後応答を返す。次
に、ディレクトリ同期部２０がアプリケーションサーバ
５０に対してエントリの追加要求８７を発行する。アプ
リケーションサーバ５０は受信した追加要求８７に基づ
きＤＢ５１を更新し、応答を返す。次に、スキーマ変換
部１がスキーマ変換処理を実行し、固有エントリの属性
を基に共通エントリの属性を導出する。この時、固有エ
ントリの属性に異種リンク属性が含まれる場合、リンク
変換部４がＤＢ制御部２５に対して検索要求８８を発行
し、その結果を用いて異種リンク属性の変換を行なう。
その後、スキーマ変換の結果に基づき、ディレクトリ同
期部２０がＤＢ制御部２５へ共通エントリの追加要求８
９を発行する。ＤＢ制御部２５は受信した追加要求８９
に基づきＤＢ１１を更新した後応答を返す。以上で、エ
ントリ追加処理は終了であり、ディレクトリサーバ１０
はディレクトリクライアント４０に応答を返す。

【００４４】以下に、第一の実施例のメタディレクトリ
システムの動作を説明する。なお、本実施例ではディレ
クトリサーバ１０に対して単発的に更新要求が発行され
る場合を想定しているため、あらかじめリンク記憶フラ
グ２１５に、「０」（リンク記憶テーブルを使用しな
い）を設定しておく。

【００４５】図７は、プロトコル解析部２６のプロトコ
ル解析に関わる動作を表すフローチャートである。通信
制御部２４がディレクトリクライアント４０からの要求
を受信すると（Ｓ７０１）、プロトコル解析部２６が要
求を解析し、要求種別により処理を分岐する（Ｓ７０２
からＳ７０６）。検索要求である場合は検索処理（Ｓ７
１１）、エントリ追加要求である場合はエントリ追加処
理（Ｓ７１２）、エントリ変更要求である場合はエント
リ変更処理（Ｓ７１３）、エントリ名称変更要求である
場合はエントリ名称変更処理（Ｓ７１４）、エントリ削
除要求である場合はエントリ削除処理（Ｓ７１５）をそ
れぞれ実行する。上記以外の要求については各々に対応
した処理を実行する（Ｓ７１０）。

【００４６】図８は、エントリ追加処理（図７のＳ７１
２）の動作を表すフローチャートである。最初にステッ
プＳ８０１において、ＤＢ制御部２５が、エントリデー
タをＤＢ１１に追加する。次にステップＳ８０２におい
て、同期処理制御部２１がプロトコル解析部２６から、
エントリ更新内容を図６の６０で示した形式で取得す
る。次にステップＳ８０３において、エントリ種別によ
り処理を分岐する。エントリ種別が共通エントリである
か、固有エントリであるかはエントリの名称から判断で
きる。例えばディレクトリデータが図２９のような論理
構造を持つ場合、「ＡＢＣ会社」下のエントリは共通エ
ントリであり、「メールシステムＸＹＺ」下のエントリ
は固有エントリである。

【００４７】エントリ種別が固有エントリである場合、
ステップＳ８０４において、アプリケーションアクセス
部２３が、ステップＳ８０１にて追加されたエントリに
対応する、アプリケーションデータ１１０のエントリの
追加要求をアプリケーションサーバ５０に対して発行す
る。アプリケーションサーバ５０は受信した追加要求に
基づきＤＢ５１を更新し、応答を返す。アプリケーショ
ンアクセス部２３が、アプリケーションサーバ５０から
の応答を受けた後ステップＳ８０５以降の処理を行な
う。

【００４８】次にステップＳ８０５において、スキーマ
変換部１がスキーマ変換処理を行い、固有エントリの属
性を共通エントリの属性へ変換する。次にステップＳ８
０６において、同期処理制御部２１が、共通エントリの
属性から名前付け属性を抜き出し、共通エントリの名称
を組み立てる。次にステップＳ８０７において、同期処
理制御部２１が、共通エントリの属性へ、固有エントリ
への同種リンクを追加する。

【００４９】最後にステップＳ８０８において、ディレ
クトリアクセス部２２が、ＤＢ制御部２５に対して共通
エントリの追加要求を発行し、ＤＢ制御部２５が前記共
通エントリのエントリデータをＤＢ１１に追加する。

【００５０】例えば図２９の「ＩｃｈｉｒｏＳｕｚｕｋ
ｉ」エントリ１０２’が追加された場合、ステップＳ８
０４においてアプリケーションデータ１１０へエントリ
１１１が追加され、ステップＳ８０８において「鈴木一
郎」エントリ１０２が追加される。ステップＳ８０３の
条件分岐にて、エントリ種別が共通エントリである場
合、ステップＳ８１０において、スキーマ変換部１がス
キーマ変換処理を行い、共通エントリの属性を固有エン
トリの属性へ変換する。次にステップＳ８１１におい
て、同期処理制御部２１が、固有エントリの属性から名
前付け属性を抜き出し、固有エントリの名称を組み立て
る。次にステップＳ８１２において、ディレクトリアク
セス部２２が、ＤＢ制御部２５に対して固有エントリの
追加要求を発行し、ＤＢ制御部２５が前記固有エントリ
のエントリデータをＤＢ１１に追加する。

【００５１】最後にステップＳ８１３において、アプリ
ケーションアクセス部２３が、ステップＳ８１２にて追
加された固有エントリに対応する、アプリケーションデ
ータ１１０のエントリの追加要求をアプリケーションサ
ーバ５０に対して発行する。アプリケーションサーバ５
０は受信した追加要求に基づきＤＢ５１を更新し応答を
返す。アプリケーションアクセス部２３が、アプリケー
ションサーバ５０からの応答を受けた後、エントリ追加
処理を終了する。例えば図２９の「鈴木一郎」エントリ
１０２が追加された場合、ステップＳ８１２においてア
プリケーションデータ１１０へエントリ１１１が追加さ
れ、ステップＳ８１３において「ＩｃｈｉｒｏＳｕｚｕ
ｋｉ」エントリ１０２’が追加される。

【００５２】図９は、スキーマ変換部１のスキーマ変換
処理（図８のＳ８０５、Ｓ８１０）の動作を表すフロー
チャートである。最初にステップＳ９０１において、フ
ァイルアクセス部２７がスキーマ変換規則ファイル２８
中の、先頭行のスキーマ変換規則を読み込む。次にステ
ップＳ９０２において、スキーマ変換制御部２が、ディ
レクトリ同期部２１から渡された変換元エントリの属性
更新内容の配列中から、ステップＳ９０１で読み込んだ
スキーマ変換規則の変換元属性名４０４に該当するレコ
ードを取り出す。

【００５３】その後ステップＳ９０３からＳ９０５で、
変換元エントリの属性値を変換先エントリの属性値へ変
換する。まずステップＳ９０３において、ステップＳ９
０１で読み込んだスキーマ変換規則の変換種別４０３に
より処理を分岐する。すなわち、文字列操作を行なう変
換種別の場合は、ステップＳ９０４で文字列操作部３が
文字列操作処理を行なう。一方、リンク変換を行なう変
換種別の場合は、ステップＳ９０５でリンク変換処理を
行なう。最後にステップＳ９０６において、スキーマ変
換制御部２が、変換先エントリの属性更新内容の配列へ
レコードを追加する。追加するレコードの属性名７１は
ステップＳ９０１で読み込んだスキーマ変換規則の変換
先属性名４０２、属性更新種別７２はステップＳ９０２
で取り出したレコードの属性更新種別７２、属性値配列
７３は文字列操作処理やリンク変換処理の結果である。
上記のステップＳ９０１からＳ９０６までの処理を、全
スキーマ変換規則について繰り返す（ステップＳ９０
７）。

【００５４】図１０は、リンク変換部４のリンク変換処
理（図９のＳ９０５）の動作を表すフローチャートであ
る。最初にステップＳ１００１において、リンク記憶フ
ラグ２１５の値によって処理を分岐する。「０」の場
合、ステップＳ１００２以降の処理を行う。「１」の場
合、ステップＳ１０１０において、リンク記憶テーブル
を使用したリンク変換処理を行う。但し、本実施例では
あらかじめ「０」が設定されているため、ステップＳ１
０１０については第四の実施例にて図１３を用いて説明
する。

【００５５】次にステップＳ１００２において、エント
リ種別によって処理を分岐する。エントリ種別が共通エ
ントリの場合、ステップＳ１００３において、ディレク
トリアクセス部７が、変換元の属性値が指すエントリを
検索し、そのエントリの同種リンク属性を取得する。そ
の同種リンク属性の値が変換先の属性値である。このよ
うにして、共通ディレクトリの異種リンク属性を固有デ
ィレクトリの異種リンク属性へ変換する。

【００５６】例えば図２９の、「鈴木一郎」エントリ１
０２から「ＩｃｈｉｒｏＳｕｚｕｋｉ」エントリ１０
２’へのスキーマ変換時の、リンク１０４からリンク１
０４’へのリンク変換処理を説明する。まず、リンク１
０４のリンク先エントリ、すなわち「経理課」エントリ
１０３を検索し、そのエントリの同種リンク１０５を取
得する。この同種リンク１０５の値は、「Ａｃｃｏｕｎ
ｔｉｎｇ」エントリ１０３’の名称であるため、これが
求めるリンク１０４’である。

【００５７】一方、ステップＳ１００２の条件分岐に
て、エントリ種別が固有エントリの場合、ステップＳ１
００５において、ディレクトリアクセス部７が、変換元
の属性値が指すエントリと、同種リンクによりリンクさ
れているエントリを検索し、そのエントリの名称を取得
する。その名称が変換先の属性値である。このようにし
て固有ディレクトリの異種リンク属性を共通ディレクト
リの異種リンク属性へ変換する。

【００５８】例えば図２９の、「ＩｃｈｉｒｏＳｕｚｕ
ｋｉ」エントリ１０２’から「鈴木一郎」エントリ１０
２へのスキーマ変換時の、リンク１０４’からリンク１
０４へのリンク変換処理を説明する。まず、リンク１０
４’のリンク先エントリ、すなわち「Ａｃｃｏｕｎｔｉ
ｎｇ」エントリ１０３’と同種リンク１０５により関連
付けられているエントリを検索する。この検索に「経理
課」エントリ１０３が合致する。そこで、そのエントリ
の名称を取得する。この名称が求めるリンク１０４であ
る。

【００５９】図１１は、エントリ変更処理（図７のＳ７
１３）、及びエントリ名称変更処理（図７のＳ７１４）
の動作を表すフローチャートである。最初にステップＳ
１１０１において、ＤＢ制御部２５がＤＢ１１内の該当
するエントリデータを変更する。次にステップＳ１１０
２において、同期処理制御部２１がプロトコル解析部２
６から、エントリ更新内容を図６の６０で示した形式で
取得する。次にステップＳ１１０３において、エントリ
種別により処理を分岐する。

【００６０】エントリ種別が固有エントリである場合、
ステップＳ１１０４において、アプリケーションアクセ
ス部２３が、ステップＳ１１０１にて変更されたエント
リに対応する、アプリケーションデータ１１０のエント
リの変更要求、或いは名称変更要求をアプリケーション
サーバ５０に対して発行する。アプリケーションサーバ
５０は受信した変更要求、或いは名称変更要求に基づき
ＤＢ５１を更新し応答を返す。アプリケーションアクセ
ス部２３が、アプリケーションサーバ５０からの応答を
受けた後ステップＳ１１０５以降の処理を行なう。

【００６１】次にステップＳ１１０５において、ディレ
クトリアクセス部２２が、現在処理中の固有エントリと
同種リンクにより関連付けられている共通エントリを検
索し、その共通エントリの名称を取得する。次にステッ
プＳ１１０６において、スキーマ変換部１が図９で説明
したスキーマ変換処理を行い、固有エントリのデータを
共通エントリのデータへ変換する。次にステップＳ１１
０７において、スキーマ変換の結果、共通エントリの名
前付け属性を変更する場合、ステップＳ１１０８以降を
実行する。名前付け属性以外の属性を変更する場合、ス
テップＳ１１０９を実行する。

【００６２】ステップＳ１１０８では、ディレクトリア
クセス部２２がＤＢ制御部２５に対して共通エントリの
名称変更要求を発行し、ＤＢ制御部２５が該当するエン
トリデータを変更する。その後、名前付け属性以外の属
性を変更するため、ステップＳ１１０９を実行する。最
後にステップＳ１１０９において、ディレクトリアクセ
ス部２２がＤＢ制御部２５に対して共通エントリの変更
要求を発行し、ＤＢ制御部２５が該当するエントリデー
タを変更する。

【００６３】一方、ステップＳ１１０３の条件分岐に
て、エントリ種別が共通エントリである場合、ステップ
Ｓ１１１０において、ディレクトリアクセス部２２が現
在処理中の共通エントリを検索し、同種リンクを取得す
る。それにより、リンク先の固有エントリの名称を得
る。次にステップＳ１１１１において、スキーマ変換部
１が図９で説明したスキーマ変換処理を行い、共通エン
トリのデータを固有エントリのデータへ変換する。次に
ステップＳ１１１２において、スキーマ変換の結果、固
有エントリの名前付け属性を変更する場合、ステップＳ
１１１３以降を実行する。名前付け属性以外の属性を変
更する場合、ステップＳ１１１５以降を実行する。ステ
ップＳ１１１３では、ディレクトリアクセス部２２がＤ
Ｂ制御部２５に対して、固有エントリの名称変更要求を
発行し、ＤＢ制御部２５が該当するエントリデータを変
更する。次にステップＳ１１１４では、アプリケーショ
ンアクセス部２３が、ステップＳ１１１３にて名称変更
されたエントリに対応する、アプリケーションデータ１
１０のエントリの名称変更要求を、アプリケーションサ
ーバ５０に対して発行する。アプリケーションサーバ５
０は受信した名称変更要求に基づきＤＢ５１を更新し応
答を返す。アプリケーションアクセス部２３が、アプリ
ケーションサーバ５０からの応答を受けた後、名前付け
属性以外の属性を変更するため、ステップＳ１１１５、
Ｓ１１１６を実行する。

【００６４】ステップＳ１１１５では、ディレクトリア
クセス部２２がＤＢ制御部２５に対して、固有エントリ
の変更要求を発行し、ＤＢ制御部２５が該当するエント
リデータを変更する。

【００６５】最後にステップＳ１１１６では、アプリケ
ーションアクセス部２３が、ステップＳ１１１５にて変
更されたエントリに対応する、アプリケーションデータ
１１０のエントリの変更要求を、アプリケーションサー
バ５０に対して発行する。アプリケーションサーバ５０
は受信した変更要求に基づきＤＢ５１を更新し応答を返
す。アプリケーションアクセス部２３が、アプリケーシ
ョンサーバ５０からの応答を受けた後、エントリ変更、
名称変更処理を終了する。

【００６６】図１２は、エントリ削除処理（図７のＳ７
１５）の動作を表すフローチャートである。削除時に注
意すべきなのは、共通エントリがＤＢ１１から削除され
た時点でそのエントリの同種リンク属性が削除される点
である。そこで、共通エントリをＤＢ１１から削除する
前に、同種リンク属性を待避する必要がある。最初にス
テップＳ１２０１において、エントリ種別により処理を
分岐する。エントリ種別が共通エントリである場合、ス
テップＳ１２０２において、ディレクトリアクセス部２
２が前記共通エントリの検索を行ない、同種リンク属性
を取得し、その値（固有エントリの名称）を一時的にメ
モリに待避しておく。エントリ種別が固有エントリであ
る場合はすぐにステップＳ１２０３の処理を実行する。

【００６７】ステップＳ１２０３では、ＤＢ制御部２５
が該当するエントリデータをＤＢ１１から削除する。次
にステップＳ１２０４において、同期処理制御部２１が
プロトコル解析部２６から、エントリ更新内容を図６の
６０で示した形式で取得する。次にステップＳ１２０５
において、エントリ種別により処理を分岐する。エント
リ種別が固有エントリである場合、ステップＳ１２０６
において、アプリケーションアクセス部２３が、ステッ
プＳ１２０３にて削除されたエントリに対応する、アプ
リケーションデータ１１０のエントリの削除要求をアプ
リケーションサーバ５０に対して発行する。アプリケー
ションサーバ５０は受信した削除要求に基づきＤＢ５１
を更新し応答を返す。アプリケーションアクセス部２３
が、アプリケーションサーバ５０からの応答を受けた後
ステップＳ１２０７以降の処理を行なう。

【００６８】次にステップＳ１２０７において、ディレ
クトリアクセス部２２が、現在処理中の固有エントリと
同種リンクにより関連付けられている共通エントリを検
索し、その共通エントリの名称を取得する。最後にステ
ップＳ１２０８において、ディレクトリアクセス部２２
がＤＢ制御部２５へ共通エントリの削除要求を発行し、
ＤＢ制御部２５がＤＢ１１から該当するエントリデータ
を削除する。一方、ステップＳ１２０５の条件分岐に
て、エントリ種別が共通エントリである場合、ステップ
Ｓ１２１０において、ステップＳ１２０２にて待避し
た、リンク先の固有エントリの名称を得る。ステップＳ
１２１１では、ディレクトリアクセス部２２がＤＢ制御
部２５へ固有エントリの削除要求を発行し、ＤＢ制御部
２５がＤＢ１１から該当するエントリデータを削除す
る。最後にステップＳ１２１２において、アプリケーシ
ョンアクセス部２３が、ステップＳ１２１１にて削除さ
れたエントリに対応する、アプリケーションデータ１１
０のエントリの削除要求をアプリケーションサーバ５０
に対して発行する。アプリケーションサーバ５０は受信
した削除要求に基づきＤＢ５１を更新し応答を返す。ア
プリケーションアクセス部２３が、アプリケーションサ
ーバ５０からの応答を受けた後、エントリ削除処理を終
了する。

【００６９】以上で本発明のデータベースシステムの第
一の実施例を説明した。従来のスキーマ変換技術は、変
換元のエントリデータに対して文字列操作を加えて変換
先のエントリデータを生成していたため、異なるディレ
クトリツリー間の異種リンク属性の変換を行なう事がで
きなかった。これに対し本発明は、ディレクトリデータ
の検索を行い同種リンクによって関連付けられたエント
リを特定する事で、従来技術では行なえなかった異種リ
ンク属性の変換を可能にした。本実施例のメタディレク
トリシステムは、ディレクトリサーバにスキーマ変換部
を組み込むため、任意のディレクトリクライアントから
の更新に対して同期処理を実行できるという長所を持
つ。

【００７０】次に、第二の実施例について、図１４から
図２２と図２５、図２８を用いて説明する。但し、第一
の実施例との相違点に限り説明する。本実施例は、図１
のようなスキーマ変換部１をディレクトリクライアント
に組み込んだメタディレクトリシステムである。本実施
例のメタディレクトリシステムは、第一の実施例とは異
なり、ディレクトリクライアントが全てのディレクトリ
エントリの追加、変更、名称変更、削除を行なう。

【００７１】図１４は、本実施例のメタディレクトリシ
ステムの機能構成である。ディレクトリクライアント４
０’は、ディレクトリサーバ１０との間で通信処理を実
行する通信制御部４３、ディレクトリサーバ１０への検
索、更新要求を発行するディレクトリアクセス部４２、
図１で説明したスキーマ変換部１、図４で説明したスキ
ーマ変換規則ファイル２８、ファイルアクセス部２７、
ユーザによるキー入力やディスプレイへの表示を制御す
るユーザインターフェース制御部４１を有している。

【００７２】ディレクトリサーバ１０に組み込まれるデ
ィレクトリ同期部２０’は、図４のディレクトリ同期部
２０とは異なり、同期処理制御部２１、アプリケーショ
ンアクセス部２３を有する。ディレクトリ同期部２０’
は、図２９の固有ディレクトリ１０１’に属するエント
リが更新された時に、それをアプリケーションデータ１
１０に同期する処理を行う。共通ディレクトリと固有デ
ィレクトリの間の同期処理は行なわない。

【００７３】図２５は、本実施例のディレクトリクライ
アント４０’のシステム構成である。ディレクトリクラ
イアント４０’は、中央演算装置ＣＰＵ１４、磁気ディ
スク１８、主メモリ１２、バス１３、ディスプレイ１
５、キーボード１７、マウス１６から構成される。磁気
ディスク１８には、スキーマ変換規則ファイル２８が格
納される。主メモリ１２には、通信制御プログラム４
３、ディレクトリアクセスプログラム４２、スキーマ変
換プログラム１、ファイルアクセスプログラム２７、ユ
ーザインターフェースプログラム４１が格納される。こ
れらのプログラムは、可搬型記録媒体からの読み込み、
またはサーバ１０が接続されたネットワークに接続され
た他のサーバからのダウンロードにより、磁気ディスク
１８に格納され、必要に応じて主メモリ１２に転送され
た後、ＣＰＵ１４で実行される。

【００７４】本実施例のディレクトリサーバ１０のシス
テム構成は、ディレクトリ同期プログラム２０が同期処
理制御プログラム２１とアプリケーションアクセスプロ
グラム２３から構成される点、及び磁気ディスク１８に
はディレクトリデータ１００が格納される点を除けば、
図５で示した第一の実施例と同様である。

【００７５】次に、第二の実施例における、メタディレ
クトリシステム全体の処理の流れを、図２８で説明す
る。図２８は、エントリを追加する時の処理シーケンス
である。エントリを変更、名称変更、削除する時の処理
シーケンスもほぼ同様である。ディレクトリクライアン
ト４０’のエントリ追加処理（図１５で説明する）で
は、まずユーザが共通エントリと固有エントリのデータ
を入力し終えた後エントリの追加を指示するのを待つ。
ここで、スキーマ変換部１がスキーマ変換処理を実行
し、共通エントリの属性を基に固有エントリの属性を導
出し、ユーザが同一内容のデータを再度入力しなくても
済むようにする。この時、共通エントリの属性に異種リ
ンク属性が含まれる場合、リンク変換部４がディレクト
リサーバ１０に対して検索要求９０を発行し、その結果
を用いて異種リンク属性の変換を行なう。この後ユーザ
からエントリの追加が指示されたら、ディレクトリクラ
イアント４０’はディレクトリサーバ１０に対して、ま
ず共通エントリの追加要求９１を発行する。ディレクト
リサーバ１０は受信した追加要求９１に基づきＤＢ１１
を更新した後応答を返す。次に、ディレクトリクライア
ント４０’はディレクトリサーバ１０に対して固有エン
トリの追加要求９２を発行する。ディレクトリサーバ１
０は受信した追加要求９２に基づきＤＢ１１を更新す
る。その後、ディレクトリサーバ１０はアプリケーショ
ンサーバ５０に対してエントリの追加要求９３を発行す
る。アプリケーションサーバ５０は受信した追加要求９
３に基づきＤＢ５１を更新し、応答を返す。その応答を
受け取ったディレクトリサーバ１０はディレクトリクラ
イアント４０’に応答を返す。以上で、ディレクトリク
ライアント４０’のエントリ追加処理は終了する。な
お、本実施例でも、第一の実施例と同様に、あらかじめ
リンク記憶フラグ２１５に、「０」を設定しておく。

【００７６】図１５は、ディレクトリクライアント４
０’のエントリ追加処理の動作を表すフローチャートで
ある。最初にステップＳ１５０１において、ユーザイン
ターフェース制御部４１が、これから追加する共通エン
トリの所属組織をユーザが指定するのを待つ。

【００７７】図２１は、ユーザが上記の指定を行なうた
めの画面表示例である。画面３００は、共通ディレクト
リ１０１を組織階層に従ったディレクトリツリーで表示
する領域３０１、領域３０１にて選択した組織に所属し
ているユーザの一覧とその属性を表示する領域３０２
（図２１は「営業課」が選択されている時の画面例であ
る）、当該画面を閉じるボタン３０５、領域３０１にて
選択した組織にユーザを追加するボタン３０６、領域３
０１にて選択したユーザを変更するボタン３０７、領域
３０１にて選択したユーザを削除するボタン３０８から
構成される。所属組織が選択され、ボタン３０６が押下
されたら、ステップＳ１５０２以降の処理を行う。ステ
ップＳ１５０２では、ユーザインターフェース制御部４
１が、これから追加する共通エントリの属性をユーザが
入力するのを待つ。

【００７８】図２２は、ユーザがエントリの属性入力を
行なうための画面表示例である。画面３１０は、共通エ
ントリの属性入力を行なうための領域３１１、固有エン
トリの属性入力を行なうための領域３１５、領域３１１
に示されている属性以外の属性入力を行なうためのボタ
ン３１４、属性入力を終了しディレクトリデータ１００
に対するエントリ追加を実行するボタン３１２、属性入
力を中断するボタン３１３から構成される。図２２の上
段は、領域３１１を表示する画面例であり、下段は、領
域３１５を表示する画面である。タブ３２０を押下する
と上段から下段へ遷移し、タブ３２１を押下すると下段
から上段へ遷移する。共通エントリの属性が入力され、
タブ３２０が押下されたらステップＳ１５０３以降の処
理を行う。

【００７９】次にステップＳ１５０３において、スキー
マ変換部１が、図９で説明したスキーマ変換処理を行い
共通エントリの属性から固有エントリの属性を生成す
る。次にステップＳ１５０４において、ユーザインター
フェース制御部４１が、固有エントリの属性をユーザが
入力するのを待つ。この時、ステップＳ１５０３のスキ
ーマ変換処理にて生成された属性を画面に表示する。こ
のことで、ユーザが同一の値を二度入力する手間を省く
ことができる。例えば図２２の上段のように、領域３１
１にて名前、姓、名がユーザによって入力された場合、
図２２の下段のように、領域３１５の名前、姓、名には
スキーマ変換処理で生成された値が表示される。固有エ
ントリの属性が入力され、ボタン３１２が押下されたら
ステップＳ１５０５以降の処理を行う。

【００８０】ステップＳ１５０５では、ユーザインター
フェース制御部４１が、共通エントリ、及び固有エント
リの名称を生成する。次にステップＳ１５０６におい
て、ユーザインターフェース制御部４１が、入力された
共通エントリの属性に、同種リンク属性を追加する。同
種リンク属性の値は固有エントリの名称である。最後に
ステップＳ１５０７において、ディレクトリアクセス部
４２が、共通エントリ、及び固有エントリの追加要求を
ディレクトリサーバ１０に対して発行する。ディレクト
リサーバ１０は図１６で示すエントリ追加処理を実行し
た後応答を返す。ディレクトリアクセス部４２がディレ
クトリサーバ１０から応答を受け取った後、エントリ追
加処理を終了する。

【００８１】次に、本実施例のディレクトリサーバ１０
のプロトコル解析処理は図７で説明したものと同様であ
る。

【００８２】図１６は、エントリ追加処理（図７のＳ７
１２）の動作を表すフローチャートである。最初にステ
ップＳ１６０１において、ＤＢ制御部２５がエントリデ
ータをＤＢ１１に追加する。次にステップＳ１６０２に
おいて、同期処理制御部２１がプロトコル制御部２６か
ら、エントリ更新内容を図６の６０で示した形式で取得
する。

【００８３】次に、ステップＳ１６０３において、エン
トリ種別により処理を分岐する。エントリ種別が固有エ
ントリである場合、ステップＳ１６０４において、アプ
リケーションアクセス部２３が、ステップＳ１６０１に
て追加されたエントリに対応する、アプリケーションデ
ータ１１０のエントリの追加要求をアプリケーションサ
ーバ５０に対して発行する。アプリケーションサーバ５
０は受信した追加要求に基づきＤＢ５１を更新し応答を
返す。アプリケーションアクセス部２３が、アプリケー
ションサーバ５０からの応答を受けた後、エントリ追加
処理を終了する。ステップＳ１６０３において、エント
リ種別が共通エントリである場合は何も行なわない。

【００８４】図１７は、ディレクトリクライアント４
０’のエントリ変更、名称変更処理の動作を表すフロー
チャートである。最初にステップＳ１７０１において、
ユーザインターフェース制御部４１が、図２１の画面３
００上で、属性の変更を行なう共通エントリをユーザが
選択するのを待つ。エントリが選択され、ボタン３０７
が押下されたらステップＳ１７０２以降の処理を行う。
次にステップＳ１７０２において、ディレクトリアクセ
ス部４２が、共通エントリを検索し全属性を取得する。
また、ステップＳ１７０３において、ディレクトリアク
セス部４２が、共通エントリと同種リンクにより関連付
けられている固有エントリを検索し全属性を取得する。
次にステップＳ１７０４において、ユーザインターフェ
ース制御部４１が、図２２の画面３１０にステップＳ１
７０２にて検索した属性値を表示し、属性の変更内容を
ユーザが入力するのを待つ。ユーザが変更内容を入力し
終え、タブ３２０が押下されたらステップＳ１７０５以
降の処理を行う。

【００８５】次にステップＳ１７０５において、スキー
マ変換部１が図９で説明したスキーマ変換処理を行な
い、共通エントリの属性を固有エントリの属性へスキー
マ変換する。次にステップＳ１７０６において、ユーザ
インターフェース制御部４１が、ステップＳ１７０３に
て検索した結果に、ステップＳ１７０５のスキーマ変換
を反映した属性値を図２２の画面３１５に表示し、属性
の変更内容をユーザが入力するのを待つ。ユーザが変更
内容を入力し終え、ボタン３１２が押下されたらステッ
プＳ１７０７以降の処理を行う。次にステップＳ１７０
７において、共通エントリの名前付け属性が変更された
か否かにより処理を分岐する。

【００８６】名前付け属性が変更された場合、ステップ
Ｓ１７０８において、ディレクトリアクセス部４２が、
ディレクトリサーバ１０に対して、共通エントリの名称
変更要求を発行する。ディレクトリサーバ１０は図１８
で示すエントリ名称変更処理を実行した後応答を返す。
ディレクトリアクセス部４２がディレクトリサーバ１０
から応答を受け取った後、ステップＳ１７０９以降の処
理を行なう。

【００８７】次にステップＳ１７０９において、ディレ
クトリアクセス部４２が、ディレクトリサーバ１０に対
して、共通エントリの変更要求を発行する。ディレクト
リサーバ１０は図１８で示すエントリ変更処理を実行し
た後応答を返す。ディレクトリアクセス部４２がディレ
クトリサーバ１０から応答を受け取った後、ステップＳ
１７１０以降の処理を行なう。次にステップＳ１７１０
において、固有エントリの名前付け属性が変更されたか
否かにより処理を分岐する。名前付け属性が変更された
場合、ステップＳ１７１１において、ディレクトリアク
セス部４２が、ディレクトリサーバ１０に対して、固有
エントリの名称変更要求を発行する。ディレクトリサー
バ１０はエントリ名称変更処理を実行した後応答を返
す。ディレクトリアクセス部４２がディレクトリサーバ
１０から応答を受け取った後、ステップＳ１７１２の処
理を行なう。次にステップＳ１７１２において、ディレ
クトリアクセス部４２が、ディレクトリサーバ１０に対
して、固有エントリの変更要求を発行する。ディレクト
リサーバ１０はエントリ変更処理を実行した後応答を返
す。ディレクトリアクセス部４２がディレクトリサーバ
１０から応答を受け取った後、エントリ変更、名称変更
処理を終了する。

【００８８】図１８は、エントリ変更処理（図７のＳ７
１３）、エントリ名称変更処理（図７のＳ７１４）のフ
ローチャートである。最初にステップＳ１８０１におい
て、ＤＢ制御部２５が、ＤＢ１１の該当するエントリデ
ータを変更する。次にステップＳ１８０２において、同
期処理制御部２１がプロトコル解析部２６から、エント
リ更新内容を図６の６０で示した形式で取得する。次に
ステップＳ１８０３において、エントリ種別により処理
を分岐する。エントリ種別が固有エントリである場合、
ステップＳ１８０４以降の処理を行なう。エントリ種別
が共通エントリである場合は何も行なわない。次にステ
ップＳ１８０４において、エントリ更新種別により処理
を分岐する。

【００８９】エントリ更新種別が名称変更の場合、ステ
ップＳ１８０６において、アプリケーションアクセス部
２３が、ステップＳ１８０１にて変更されたエントリに
対応する、アプリケーションデータ１１０のエントリの
名称変更要求を、アプリケーションサーバ５０に対して
発行する。アプリケーションサーバ５０は受信した名称
変更要求に基づきＤＢ５１を更新し応答を返す。アプリ
ケーションアクセス部２３が、アプリケーションサーバ
５０からの応答を受けた後、エントリ変更、名称変更処
理を終了する。

【００９０】エントリ更新種別が変更の場合、ステップ
Ｓ１８０５において、アプリケーションアクセス部２３
が、ステップＳ１８０１にて変更されたエントリに対応
する、アプリケーションデータ１１０のエントリの変更
要求を、アプリケーションサーバ５０に対して発行す
る。アプリケーションサーバ５０は受信した変更要求に
基づきＤＢ５１を更新し応答を返す。アプリケーション
アクセス部２３が、アプリケーションサーバ５０からの
応答を受けた後、エントリ変更、名称変更処理を終了す
る。

【００９１】図１９は、ディレクトリクライアント４
０’のエントリ削除処理の動作を表すフローチャートで
ある。最初に、ステップＳ１９０１において、ユーザイ
ンターフェース制御部４１が、図２１の画面３００上
で、これから削除する共通エントリをユーザが選択さ
れ、ボタン３０８が押下されるのを待つ。ボタン３０８
が押下されたらステップＳ１９０２以降の処理を行う。
ステップＳ１９０２において、ディレクトリアクセス部
４２が選択された共通エントリを検索し、同種リンク属
性を取得する。この処理によって、削除する共通エント
リと同種リンクにより関連付けられている固有エントリ
の名称が取得できる。

【００９２】次にステップＳ１９０３において、ディレ
クトリアクセス部４２が共通エントリの削除要求をディ
レクトリサーバ１０に対して発行する。ディレクトリサ
ーバ１０は図２０で示すエントリ削除処理を実行した後
応答を返す。ディレクトリアクセス部４２がディレクト
リサーバ１０から応答を受け取った後、ステップＳ１９
０４の処理を行なう。最後にステップＳ１９０４におい
て、ディレクトリアクセス部４２が固有エントリの削除
要求をディレクトリサーバ１０に対して発行する。ディ
レクトリサーバ１０はエントリ削除処理を実行した後応
答を返す。ディレクトリアクセス部４２がディレクトリ
サーバ１０から応答を受け取った後、エントリ削除処理
を終了する。

【００９３】図２０は、エントリ削除処理（図７のＳ７
１５）の動作を表すフローチャートである。最初にステ
ップＳ２００１において、ＤＢ制御部２５が、ＤＢ１１
の該当するエントリデータを削除する。次にステップＳ
２００２において、同期処理制御部２１が、プロトコル
解析部２６から、エントリ更新内容を図６の６０で示し
た形式で取得する。次に、ステップＳ２００３におい
て、エントリ種別により処理を分岐する。

【００９４】エントリ種別が固有エントリである場合、
ステップＳ２００４において、アプリケーションアクセ
ス部２３が、ステップＳ２００１にて削除されたエント
リに対応する、アプリケーションデータ１１０のエント
リの削除要求を、アプリケーションサーバ５０に対して
発行する。アプリケーションサーバ５０は受信した削除
要求に基づきＤＢ５１を更新し応答を返す。アプリケー
ションアクセス部２３が、アプリケーションサーバ５０
からの応答を受けた後、エントリ削除処理を終了する。
ステップＳ２００３において、エントリ種別が共通エン
トリである場合、何も行なわずエントリ削除処理を終了
する。

【００９５】以上説明した第二の実施例によると、ディ
レクトリ同期部をディレクトリクライアントに持たせる
事で、ディレクトリサーバの負荷を軽減する事が可能と
なる。また、第一の実施例のメタディレクトリシステム
は、共通エントリと固有エントリの必須属性が一致する
事が必要であったが、第二の実施例のメタディレクトリ
システムは、属性入力画面（図２２）上で、ユーザが足
りない属性を追加入力可能にする事で、必須属性が一致
しない場合にも適用できる。

【００９６】次に、本発明の第三の実施例を説明する。
第一の実施例では、ディレクトリサーバにスキーマ変換
部を持たせ、第二の実施例では、ディレクトリクライア
ントにスキーマ変換部を持たせた。本実施例では、ディ
レクトリサーバとディレクトリクライアントの両方にス
キーマ変換部を持たせる。そして、以下のようにエント
リ更新種別毎に役割を分担させる。

【００９７】エントリ追加時のスキーマ変換はディレク
トリクライアント側が担当する事で、必須属性が一致し
ない場合に適用可能であるようにする。エントリ追加
時、ディレクトリ同期部は共通ディレクトリと固有ディ
レクトリの同期処理は行なわず、固有ディレクトリとア
プリケーションデータとの同期処理を行なう。エントリ
変更時のスキーマ変換はディレクトリサーバ側が担当
し、任意のディレクトリクライアントからの変更要求に
対して同期処理が実行されるようにする。エントリ削除
時は、ディレクトリクライアントが共通エントリと固有
エントリの両方を削除する事で、ディレクトリ同期部が
同種リンクを待避する必要がないようにする。

【００９８】このようにエントリ追加に関するスキーマ
変換をディレクトリクライアント側で行なう事で、共通
エントリと固有エントリの必須属性が一致しないような
より広範なスキーマに対応可能となる。一方、エントリ
変更に関するスキーマ変換はディレクトリサーバ側で行
なう事で、エンドユーザが、自分のユーザ情報のメンテ
ナンスを、従来のディレクトリクライアントを用いて行
なう事が可能となり、かつ、共通ディレクトリの参照、
更新を行なう従来のアプリケーションをそのまま使用で
きる。

【００９９】次に、本発明の第四の実施例を説明する。
本実施例は、第一の実施例と同様のシステム構成を持つ
メタディレクトリシステムであり、複数エントリを一括
して追加する場合などのバッチ処理を対象にするもので
ある。このようなバッチ処理を行なう例として、新入社
員が入社した時や、メタディレクトリシステムの初期導
入時にアプリケーションデータ１１０を一括してディレ
クトリデータ１００に追加する時が挙げられる。本実施
例ではあらかじめ、リンク記憶フラグ２１５に、「１」
を設定しておく。これにより、同一の組織に所属するユ
ーザのリンク変換処理において、ディレクトリサーバ１
０へ重複した検索要求を発行する事を防ぎ、スキーマ変
換処理に要する時間を短縮できる。

【０１００】本実施例における、エントリの追加、変
更、名称変更、削除処理のフローチャートは第一の実施
例と同様である。但し、図１０のステップＳ１００１の
条件分岐にて、ステップＳ１０１０が実行されるのが相
違点である。そのため、ここでは図１３を用いて、ステ
ップＳ１０１０の、リンク記憶テーブル使用時のリンク
変換処理を説明する。最初にステップＳ１３０１におい
て、変換元エントリのエントリ種別により処理を分岐す
る。エントリ種別が共通エントリの場合、まずステップ
Ｓ１３０２において、リンク変換部４が、変換元の属性
値（変換元エントリが持つ異種リンク属性の値）と共通
エントリの名称２１１が合致するレコードを、リンク記
憶テーブル２１０から検索する。

【０１０１】次にステップＳ１３０３において、ステッ
プＳ１３０２で実行された検索処理の結果、合致するレ
コードの有無により処理を分岐する。

【０１０２】合致するレコードが存在した場合、変換先
の属性値は、合致したレコードの固有エントリの名称２
１２である（Ｓ１３０４）。合致するレコードが存在し
なかった場合、ステップＳ１３０５において、ディレク
トリアクセス部４２が、変換元の属性値の指すエントリ
を検索し同種リンク属性を取得する。この時取得した同
種リンク属性の値が、変換先の属性値である（Ｓ１３０
６）。最後にステップＳ１３０７において、リンク変換
部４がリンク記憶テーブル２１０へ新規レコードを追加
する。この時、共通エントリの名称２１１には変換元の
属性値を登録し、固有エントリの名称２１２には、ステ
ップＳ１３０６で実行した検索の結果取得した同種リン
ク属性の値を登録する。

【０１０３】一方、ステップＳ１３０１の条件分岐に
て、エントリ種別が固有エントリであった場合、まずス
テップＳ１３１０において、リンク変換部４が、変換元
の属性値（変換元エントリが持つ異種リンク属性の値）
と固有エントリの名称２１２が一致するレコードを、リ
ンク記憶テーブル２１０から検索する。次にステップＳ
１３１１において、ステップＳ１３１０で実行された検
索処理の結果、合致するレコードの有無により処理を分
岐する。合致するレコードが存在した場合、変換先の属
性値は、合致したレコードの共通エントリの名称２１１
である（Ｓ１３１２）。合致するレコードが存在しなか
った場合、ステップＳ１３１３において、ディレクトリ
アクセス部４２が、変換元の属性値が指すエントリへ同
種リンクによりリンクしている共通エントリを検索し、
その名称を取得する。この時取得した名称が、変換先の
属性値である（Ｓ１３１４）。

【０１０４】最後にステップＳ１３１５において、リン
ク変換部４がリンク記憶テーブル２１０へ新規レコード
を追加する。この時、共通エントリの名称２１１には検
索の結果取得した名称を登録し、固有エントリの名称２
１２には、変換元の属性値を登録する。

【０１０５】またバッチ処理終了後、ディレクトリクラ
イアント４０によって同種リンクが変更される可能性が
あるため、バッチ処理が終了した時点で、スキーマ変換
制御部２がリンク記憶テーブル２１０の全レコードを削
除しておく。

【０１０６】以上説明した第四の実施例によると、一度
取得したリンク情報をスキーマ変換部の内部に保持して
おく事で、ディレクトリデータの一括登録のようなバッ
チ処理に要する時間を短縮可能である。

【０１０７】また、第二の実施例で説明したメタディレ
クトリシステムにおいて、バッチ処理に適用可能なよう
に、第四の実施例で説明したリンク記憶テーブル２１０
を用いることも可能である。ディレクトリデータの初期
構築時、アプリケーションデータ１１０を基に作成した
固有ディレクトリから、一括して共通ディレクトリを作
成するディレクトリクライアントに特に効果がある。

【０１０８】本発明のデータベースシステムによれば、
或る異種リンクを別個の異種リンクへ変換するリンク変
換手段を備える事により、異種リンクに対する更新を別
の異種リンクへ自動的に反映可能となる。その結果、シ
ステム管理者はリンク管理作業を一元化でき、リンク管
理負荷を大幅に削減可能となる。例えば、ユーザの所属
組織情報を異種リンクを用いて管理するアプリケーショ
ンが二つ以上運用されている情報システムにおいて人事
異動が発生した時、システム管理者は一ユーザにつき一
つの所属組織情報を更新するだけで済むようになる。

【０１０９】

【発明の効果】本発明によれば、複数のデータベースに
存在し互いに関連を持つレコードの一元管理が可能とな
り、特に大規模なレコードのデータ変更の際などもシス
テム管理者の負荷を軽減できる。

【図面の簡単な説明】

【図１】本発明の機能構成である。

【図２】従来のディレクトリデータのデータ構造であ
る。

【図３】従来技術のスキーマ変換例である。

【図４】第一の実施例の機能構成である。

【図５】第一の実施例のシステム構成である。

【図６】本発明のリンク記憶領域、エントリ更新内容、
属性更新内容の説明図である。

【図７】第一の実施例のプロトコル解析に関わる動作の
説明図である。

【図８】第一の実施例のエントリ追加に関わる動作の説
明図である。

【図９】本発明のスキーマ変換に関わる動作の説明図で
ある。

【図１０】本発明のリンク変換に関わる動作の説明図で
ある。

【図１１】第一の実施例のエントリ変更、名称変更に関
わる動作の説明図である。

【図１２】第一の実施例のエントリ削除に関わる動作の
説明図である。

【図１３】本発明の、リンク記憶テーブル使用時のリン
ク変換に関わる動作の説明図である。

【図１４】第二の実施例の機能構成である。

【図１５】第二の実施例のディレクトリクライアントに
おける、エントリ追加に関わる動作の説明図である。

【図１６】第二の実施例のディレクトリサーバにおけ
る、エントリ追加に関わる動作の説明図である。

【図１７】第二の実施例のディレクトリクライアントに
おける、エントリ変更、名称変更に関わる動作の説明図
である。

【図１８】第二の実施例のディレクトリサーバにおけ
る、エントリ変更、名称変更に関わる動作の説明図であ
る。

【図１９】第二の実施例のディレクトリクライアントに
おける、エントリ削除に関わる動作の説明図である。

【図２０】第二の実施例のディレクトリサーバにおけ
る、エントリ削除に関わる動作の説明図である。

【図２１】ディレクトリクライアントの更新エントリ選
択時の画面表示例である。

【図２２】ディレクトリクライアントのエントリデータ
編集時の画面表示例である。

【図２３】ディレクトリデータにおける、組織階層の表
現方法設定時の画面表示例である。

【図２４】スキーマ変換規則ファイルの表記形式、及び
一例である。

【図２５】第二の実施例のシステム構成である。

【図２６】第一の実施例の共通エントリ追加処理におけ
る処理シーケンスである。

【図２７】第一の実施例の固有エントリ追加処理におけ
る処理シーケンスである。

【図２８】第二の実施例のエントリ追加処理における処
理シーケンスである。

【図２９】本発明のディレクトリデータのデータ構造で
ある。

【符号の説明】

１…スキーマ変換部、 ２…スキーマ変換制御部、 ３…文字列操作部、 ４…リンク変換部、 ６…リンク記憶領域、 ７…ディレクトリアクセス部 １００…ディレクトリデータ １０１…共通ディレクトリ １０１’…固有ディレクトリ １０２…共通ユーザエントリ １０２’…固有ユーザエントリ １０３…共通組織エントリ １０３’…固有組織エントリ １０４…所属関係を表す異種リンク １０４’…所属関係を表す異種リンク １０５…同種リンク。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 平島 陽子 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 川上 順彦 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 由井 仁 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B075 ND35 ND36 NR03 PP02 PP03 PP12 PP13 PQ02 5B082 BA13 EA01 EA07 EA09 GA02 GC04 HA08

Claims (8)

【特許請求の範囲】
1. 【請求項１】第１のオブジェクトを表す第１のレコード
   と、第２のオブジェクトを表す第２のレコードと、前記
   第１のレコードと、前記第２のレコード間とを関連付け
   るリンクである第１の異種リンクとを格納している第１
   のデータベースと、 前記第１のオブジェクトを表す第３のレコードと、前記
   第２のオブジェクトを表す第４のレコードを記憶する第
   ２のデータベースと、 前記第１の異種リンクと、前記第１のレコードと第３の
   レコードとを関連付けるリンクである第１の同種リンク
   と、前記第２のレコードと第４のレコードとを関連付け
   るリンクである第２の同種リンクから、前記第３のレコ
   ードと、第４のレコード間を関連付けるリンクである第
   ２の異種リンクへの変換を行うリンク変換手段を有する
   ことを特徴とするデータベースシステム。
2. 【請求項２】請求項１に記載のデータベースシステムに
   おいて、前記リンク変換手段は、 前記第１のレコードと前記第１の同種リンクとを用いて
   前記第３のレコードを特定し、 前記第1のレコードと前記第１の異種リンクとを用いて
   前記第2のレコードを特定し、 前記第２のレコードと前記第２の同種リンクとを用いて
   前記第４のレコードを特定し、 前記第２の異種リンクへの変換を行なうことを特徴とす
   るデータベースシステム。
3. 【請求項３】請求項２に記載のデータベースシステムに
   おいて、前記リンク変換手段は、 前記第１の同種リンクによりリンクされている前記第３
   のレコードと、前記第２の同種リンクによりリンクされ
   ている前記第４のレコードを、前記第２のデータベース
   を検索することにより特定することを特徴とするデータ
   ベースシステム。
4. 【請求項４】請求項３に記載のデータベースシステムに
   おいて、さらに、 前記第2のデータベースを検索することで特定した、同
   種リンクによりリンクされている複数レコードの対応関
   係を記憶するリンク情報記憶手段を有し、 前記リンク変換手段は、前記同種リンクによりリンクさ
   れているレコードを特定する際に、 前記リンク情報記憶手段が記憶した、同種リンクによる
   複数レコードの対応関係を参照することを特徴とするデ
   ータベースシステム。
5. 【請求項５】ディレクトリサーバが管理するアプリケー
   ションデータのディレクトリデータ構造であって、 ディレクトリデータが、アプリケーションが扱うデータ
   を登録する固有ディレクトリツリーと、全アプリケーシ
   ョンに共通なデータを登録する共通ディレクトリツリー
   と、 同種のオブジェクトを表す前記それぞれのディレクトリ
   ツリー中のエントリ同士とを関連づける同種リンクと、 ユーザを表すエントリから所属組織を表すエントリへの
   所属関係を表現する第1の異種リンクを備えることを特
   徴とするディレクトリデータ構造。
6. 【請求項６】請求項５に記載のディレクトリデータ構造
   において、 組織を表すエントリから上位の組織を表すエントリへの
   組織階層を表現する第2の異種リンクを備えることを特
   徴とするディレクトリデータ構造。
7. 【請求項７】請求項５または６に記載のディレクトリデ
   ータ構造において、 エントリの属性に、他のエントリの名称を格納すること
   により、複数エントリ間の異種リンクを表現することを
   特徴とするディレクトリデータ構造。
8. 【請求項８】請求項５または６に記載のディレクトリデ
   ータ構造において、 各エントリは、各エントリ自身が属するディレクトリ内
   において、各エントリ自身を一意に識別する情報を格納
   する第１の属性と、 他のエントリが持つ当該他のエントリ自身を一意に識別
   する情報を格納する第２の属性とを備え、 前記第１と第２の属性により前記異種リンクを表現する
   ことを特徴とするディレクトリデータ構造。