JP5410514B2

JP5410514B2 - Ｘ５００データモデルをリレーショナル・データベースにマッピングするための方法

Info

Publication number: JP5410514B2
Application number: JP2011512116A
Authority: JP
Inventors: ジョゲ，フランソワ; ジャフェット，グイ
Original assignee: アルカテル−ルーセント
Priority date: 2008-06-03
Filing date: 2009-06-03
Publication date: 2014-02-05
Anticipated expiration: 2029-06-03
Also published as: KR20110031931A; KR101573561B1; WO2009147185A1; CN101645092A; US20090300062A1; EP2131293A1; JP2011523750A; US8166075B2; CN101645092B

Description

本発明の技術分野は、データベースの分野である。データベースは、データを保存、変更、検索、分析するために、データを実用的な方法で収集し、編成することが知られている。

データベース編成のいくつかのパラダイムが知られている。データは、オブジェクトの形式で提供され、各オブジェクトは、データの一部で、前記オブジェクトに関連する複数のアトリビュートを集めたものであり、各アトリビュートは、名前またはタイプと、値とを含む。

最も使用されているパラダイムの１つが、リレーショナル・データベースＲＤＢである。リレーショナル・データベースでは、データは、関係とも名付けられた、テーブル内に保存される。列の名前は、アトリビュートの名前であり、各オブジェクトは、テーブル内の行に対応し、前記行は、対応するアトリビュートの値を含む。

リレーショナル・データベースは、よく知られるようになってから久しい。リレーショナル・データベースは、データを保存するための強力な方法であることを証明した。リレーショナル・データベースは、世界中でよく使用されており、そのようなデータベースを管理するために、多くのツールおよびシステムが利用可能である。また、そのようなデータベースおよび関連ツールを作成、管理、または使用するために、多くのデータベース技術者が育成されている。例えば、ＳＱＬ問い合わせ言語がよく知られており、よく使用されている。

しかし、リレーショナル・パラダイムは、構成が複雑なデータを扱う場合に、いくぶん制約的であるように思え、より精巧なセマンテックを用いて前記複雑さを表現するツールを提供するために、新しいパラダイムが開発された。Ｘ５００は、データベース所有者およびユーザの好評を得ることが多い、これらの代替パラダイムの１つである。Ｘ５００は、データベースの編成を記述する場合に、より豊富なシンタックスを可能にする。Ｘ５００は、標準化されている。Ｘ５００は、データベースの管理者が、そのデータの構造を容易に記述することを可能にする、よりユーザ・フレンドリな手法を提供する。ＵＭＬという知られた言語を使用して、Ｘ５００仕様を設計することも可能である。

ＲＤＢ世界およびＸ５００世界はともに、独自の利点を有し、２つの世界から恩恵を得ることができれば有利である。その場合、Ｘ５００データモデルからリレーショナル・データベース・モデルへのマッピングを提供できることが関心事となる。

時間的性能を必要とし、大量のデータを扱う電気通信アプリケーションによって使用されるために、ソリューションが束縛を受けるという事実に由来する他の制約は、直接的なＲＤＢ使用と同等な性能を提供する能力と、全体的なデータベース・サイズの可能な限りの最適化である。

国際公開第９６／０７１４７号（米国特許第６０５２６８１号明細書）は、この問題に対するソリューションを説明している。しかし、Ｘ５００情報が、ＲＤＢテーブルに統合される。これは、データベース・サイズに関して、大きなオーバヘッドを引き起こす。さらに、１つのＸ５００アクセスが、多くのデータベース・アクセスをトリガし、したがって、性能を低下させる。

米国特許出願公開第２００６／０１７３８７３号明細書では、仮想ディレクトリ・サービス（ｖｉｒｔｕａｌｄｉｒｅｃｔｏｒｙｓｅｒｖｉｃｅ）を使用する、階層／リレーショナル変換システム（ｈｉｅｒａｒｃｈｉｃａｌ／ｒｅｌａｔｉｏｎａｌｔｒａｎｓｌａｔｉｏｎｓｙｓｔｅｍ）が説明されている。

米国特許第６８２３３３８号明細書では、Ｘ５００アクセス制御データをリレーショナル・データベースにマッピングするための方法が説明されている。

米国特許第５３３３３１７号明細書では、Ｘ５００データベース内で検索を行う方法が説明されている。

しかし、これらの方法はどれも、与えられた制約のすべてを満たすことはない。

国際公開第９６／０７１４７号（米国特許第６０５２６８１号明細書）米国特許出願公開第２００６／０１７３８７３号明細書米国特許第６８２３３３８号明細書米国特許第５３３３３１７号明細書

本発明は、ＲＤＢのＸ５００モデル・ビューを提供することによって、この問題に対処し、この問題を解決する。データ・オブジェクトを管理する基礎的なＲＤＢに基づいて、オブジェクトがあたかもＸ５００モデルに従って編成されているかのようにオブジェクトをユーザに示す、マッピング・インタフェースが提供される。ユーザは、オブジェクトがあたかもＸ５００オブジェクトであるかのように、オブジェクトにアクセスし、オブジェクトを管理する。その場合、マッピング・システムが、透過的な方法でＲＤＢ管理システムとインタフェースをとるうえで必要なすべてのアクションを提供する。

本発明の主要な独自のアイデアは、データを保存するために、標準的なリレーショナル・データベースを使用または作成し、Ｘ５００モデルの構造に関係する情報を別途保存して有するというものである。そのようにすることで、データベースは、マッピング方法によって修正または影響されず、データベースのサイズは、有用なデータのサイズにのみ依存する。さらに、Ｘ５００エンティティとリレーショナル・データベースのスキーマおよびデータとの間の関係を表す、Ｘ５００モデルとリレーショナル・データベース・モデルとの間のマッピングに関係する情報が提供される。

本発明の目的は、少なくとも１つのエントリと、少なくとも１つのオブジェクトクラスと、ディレクトリ情報ツリー（ｄｉｒｅｃｔｏｒｙｉｎｆｏｒｍａｔｉｏｎｔｒｅｅ）ＤＩＴとを含むＸ５００データモデルであって、エントリが、少なくとも１つのアトリビュートを含み、アトリビュートが、タイプと、値とを含み、前記エントリは、１つのオブジェクトについての情報を集めたものであり、オブジェクトクラスが、前記オブジェクトを記述するエントリ内に存在する前記アトリビュートのタイプを定義するモデルであり、前記ＤＩＴ内の頂点が、エントリであり、各エントリが、識別名（ｄｉｓｔｉｎｇｕｉｓｈｅｄｎａｍｅ）ＤＮを含み、ＤＮが、前記ＤＩＴ内の前記ペアレントのエントリのＤＮと、相対識別名（ｒｅｌａｔｉｖｅｄｉｓｔｉｎｇｕｉｓｈｅｄｎａｍｅ）ＲＤＮとを併せて含み、ＲＤＮが、前記エントリに固有の１つの特別に指名されたアトリビュートを含む、Ｘ５００データモデルを、リレーショナル・テーブルを含むリレーショナル・データベースＲＤＢであって、各テーブルが、いくつかの名付けられた列を含み、これらの列のいくつかが、オブジェクトデータを一意的に識別する値を含む主キー（ｐｒｉｍａｒｙｋｅｙ）であり、オブジェクトデータが、行内に保存される、ＲＤＢに、マッピングするための、コンピュータ・システムにおける、方法であって、
各々がそのアトリビュートからなるリストを含む、オブジェクトクラスを構築するステップと、
各々がそのタイプを含む、アトリビュートを構築するステップと、
可変値がすべて除去されたＲＤＮである、スタティックＲＤＮのみを含むＤＮである、スタティックＤＮ（ｓｔａｔｉｃＤＮ）ＳＤＮのみを含むスタティック・ディレクトリ情報ツリー（ｓｔａｔｉｃｄｉｒｅｃｔｏｒｙｉｎｆｏｒｍａｔｉｏｎｔｒｅｅ）ＳＤＩＴを構築するステップと、
Ｘ５００データをＲＤＢにマッピングするステップであって、
Ｘ５００オブジェクトクラスをＲＤＢテーブルに、
Ｘ５００アトリビュートをＲＤＢテーブルの列に
関連付け、前記テーブルの列の名前を前記Ｘ５００アトリビュートとともに、前記アトリビュートをポイントするアドレスとして保存することによって、マッピングするステップと
を含む方法である。

本発明の別の特徴によれば、オブジェクトクラスを構築するステップ、アトリビュートを構築するステップ、およびスタティック・ディレクトリ情報ツリーを構築するステップは、Ｘ５００仕様から前記要素をそれぞれ抽出することによって行われる。

本発明の別の特徴によれば、オブジェクトクラスを構築するステップ、アトリビュートを構築するステップ、およびスタティック・ディレクトリ情報ツリーを構築するステップは、ＲＤＢの分析からこれらの要素を生成することによって行われる。

本発明の別の特徴によれば、ＲＤＢにマッピングされるＸ５００の、エントリのＤＮによって定義されるエントリに対するアクセス／リクエスト、個別にはアトリビュートが属するエントリのＤＮと前記アトリビュートとによって定義されるエントリのアトリビュートに対するアクセス／リクエストは、
すべての可変値を前記ＤＮから除去することによって、前記エントリのＤＮからスタティックＤＮＳＤＮを構築するステップと、
スタティックＤＩＴＳＤＩＴをフェッチして、一致するスタティックＤＮを見出すステップと、
前記一致するスタティックＤＮのアトリビュートから、前記エントリのアトリビュートのすべてに対応する、個別には前記アトリビュートに対応する、テーブルの列のマッピング・アドレスを抽出するステップと、
前記マッピング・アドレスを含むＲＤＢリクエストを作成するステップと、
リクエストを実行するステップと、
前記リクエストの結果を取得するステップと
を含む。

本発明の他の特徴、詳細、および利点は、図面に関連する、これ以降で行われる詳細な例示的説明からより明らかになろう。

マッピング方法のＵＭＬ図である。Ｘ５００モデルの編成のＵＭＬ図である。許容される／許容されないトポロジの例を示す図である。Ｘ５００ＤＩＴの階層的編成を示す図である。ＲＤＢの一例を示す図である。ＤＩＴの一例を示す図である。Ｘ５００モデルを示す、処理の一例を示す図である。エントリ用に生成されたＸＭＬコードを示す、処理の一例を示す図である。図８ａの続きを示す図であるマッピング情報用のＸＭＬコードを示す、処理の一例を示す図である。ＲＤＢテーブル生成用のＸＭＬコードを示す、処理の一例を示す図である。エントリを生成し、データベースにデータを入力するためのＸＭＬコードを示す、処理の一例を示す図である。第１のクエリのサンプルを示す、処理の一例を示す図である。第２のクエリのサンプルを示す、処理の一例を示す図である。

最初に、Ｘ５００モデルの特徴が説明される。Ｘ５００モデルは、ディレクトリ情報ベース（ｄｉｒｅｃｔｏｒｙｉｎｆｏｒｍａｔｉｏｎｂａｓｅ）ＤＩＢに基づいている。ＤＩＢおよびその構造は、ＩＴＵ−Ｔ勧告Ｘ５０１−ＩＳＯ／ＩＥＣ９５９４−２において定義されている。本発明を理解可能にするため、これ以下で、Ｘ５００の主要な特徴が説明される。

ＤＩＢは、オブジェクトについての情報から構成される。ＤＩＢは、（ディレクトリ）エントリから構成され、エントリの各々は、１つのオブジェクトについての情報の集まりから成る。各エントリは、アトリビュートから構成される。各アトリビュートは、タイプと、１つの値とを有する。ＤＩＢのエントリは、ディレクトリ情報ツリーＤＩＴという、ツリーの形に配列され、ツリーの頂点が、エントリを表す。ツリー内のより高位の（ルートにより近い）エントリは、しばしば国または組織などのオブジェクトを表し、ツリー内のより低位のエントリは、人々またはアプリケーション・プロセスを表す。

例えば、エントリ｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓ，ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒ｝は、地域（Ｌｏｃａｌｉｔｙ）という地理的アトリビュートを有する、アプリケーション・エンティティ「ＬａｓｅｒＰｒｉｎｔｅｒ」を識別する。前記エントリは、４つのアトリビュートから構成される。第１のアトリビュートＣ＝ＧＢは、間を「＝」記号でつないで、ＣというタイプがＧＢという値を有することを示しており、オブジェクトの（国を表す）Ｃについて通知する。

図３は、ＤＩＴの異なるトポロジを示している。ＤＩＴは、上３つの構成１、２、３によって示されるように、ツリー構造をとらなければならない。下２つの構成４、５は、ツリー構造をとっておらず、ＤＩＴでは有効な構成ではない。

図４は、多くの頂点／エントリ７を含む、ＤＩＴ６の一例を示している。エントリ７が、複数のアトリビュート８を含む様子が詳細に示されている。さらに、アトリビュート８が、タイプ９／値１０の組から構成される様子も詳細に示されている。

すべてのエントリ７は、エントリ７を一意的に曖昧さを残さずに識別する、識別名ＤＮを有する。識別名ＤＮのこれらの特性は、情報のツリー構造から引き出される。エントリ７の識別名ＤＮは、その上位エントリの識別名ＤＮと、相対ＲＮまたはＲＤＮとも呼ばれる、エントリ７に属する特別に指名されたアトリビュート値（識別値）とを併せて構成される。エントリ７のアドレスとも呼ばれる識別名ＤＮは、与えられたＤＮ記述から開始して、ＤＮをインスタンス化（構築）または分析（抽出）する能力を提供する。

図５は、ＤＩＴ６の一例を提供している。例示的なエントリ｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓ，ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒ｝は、ツリーの右端最下部に配置されている。エントリの特別に指名されたアトリビュート値は、アトリビュートＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒである。そのため、ＲＤＮは、ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒに等しい。ツリーのルートに向かって遡りながら、一連の上位エントリのＲＤＮを追加していくことによって、前記エントリのＤＮを構築することができる。その場合、１つレベルを上がると、Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓが追加される。さらに１つレベルを上がると、Ｌ＝Ｗｉｎｓｌｏｗが追加される。最後に、ルートに到る最終のレベルにおいて、Ｃ＝ＧＢが追加され、前記エントリの完全なＤＮ：｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓ，ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒ｝が、すべての連続するＲＤＮの合併として提供される。

ディレクトリは、ＤＩＢが、時間とともに変更にさらされても、適切な形式を保つことを保証するために、１組のルールを強制する。ディレクトリ・スキーマ（Ｄｉｒｅｃｔｏｒｙｓｃｈｅｍａ）として知られるこれらのルールは、エントリが、そのオブジェクトクラスにとって誤ったタイプのアトリビュートを有すること、アトリビュート値が、アトリビュート・タイプにとって誤った形式をとること、さらにはエントリが、誤ったクラスの下位エントリを有することを防止する。

ＤＩＴ６は、データベース内のオブジェクトについてのすべての構造的および階層的情報を含む。ＤＩＴ６は、エントリ７のインスタンスをアドレスするために使用される、ＤＮまたはＤＮ記述のシンタックスである、データベースのアドレッシング・スキームである。そのアドレッシング・スキームでは、エントリ７の間に階層的編成が存在する。

Ｘ５００モデルは、特定のエントリ７内に存在するアトリビュート８のタイプ９についての情報も含む。これらのアトリビュートのタイプは、エントリ７が記述するオブジェクトのクラスに依存する。オブジェクトクラスは、与えられたエントリ７内に存在する前記アトリビュートのタイプを定義するモデルである。オブジェクトクラスは、機能的に一緒に結合されるアトリビュート８の論理グルーピングを表し、アトリビュート８のこのグループ内における論理的制約を表すように定義される。ＤＩＴを定義するＤＮに加えて与えられる、オブジェクトクラスの仕様が、エントリ７の構築を可能にする。エントリ７は、１つまたは複数のオブジェクトクラスのインスタンス化、すなわち、オブジェクトクラスによって与えられるアプリケーション・スキーマに準拠した１組のアトリビュート８である。

一例として、以下の行は、２つの例示的なオブジェクトクラスを定義する。

ObjectClass="AuthorIdentity" Attributes="name,country"
ObjectClass="BookDescription" Attributes="title,publisherId""

第１のオブジェクトクラスＡｕｔｈｏｒＩｄｅｎｔｉｔｙは、ｎａｍｅおよびｃｏｕｎｔｒｙの２つのアトリビュートを含む。著者エントリのインスタンス化は、オブジェクトクラスＡｕｔｈｏｒＩｄｅｎｔｉｔｙを有利に使用することができる。前記著者の著書目録を扱う場合、前記著者によって書かれた本の各々をインスタンス化するために、オブジェクトクラスＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎを使用することができる。

例えば、名前：｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓ，ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒ｝は、アプリケーション・エンティティ「ＬａｓｅｒＰｒｉｎｔｅｒ」を識別し、そのエンティティは、その識別名内に地域という地理的アトリビュートを有する。その名前が｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，ＣＮ＝ＪｏｈｎＪｏｎｅｓ｝である、住人ＪｏｈｎＪｏｎｅｓも、その識別名内に同じ地理的アトリビュートを有する。その場合、地理的アトリビュートをオブジェクトクラスにすると有利なことがある。

図２は、Ｘ５００モデルの構成と、様々なエンティティ間の関係とからなるＵＭＬ図を提供している。

Ｘ５００モデルにおいてアドレス可能なエンティティは、エントリ７と、エントリ内のアトリビュート８である。オブジェクトクラスは、そのようにアドレス可能ではない。オブジェクトクラスは、機能的に一緒に結合されるアトリビュートの論理グルーピングと、アトリビュート８のこのグループ内における論理的制約（必須、任意）を表すにすぎない。

次に、リレーショナル・データベースＲＤＢの特徴が説明される。図５は、そのようなＲＤＢのサンプルを示している。リレーショナル・データベース・モデルは、以下の基本概念に基づいており、すなわち、データは、関係の集まりとして提示され、各関係は、テーブル１１として表され、列１４は、それらのタイトル１３によって表されるアトリビュートであり、行１５が、オブジェクトに相当する。すべてのテーブル１１は、各オブジェクトを一意的に識別する「キー」として一緒に採用された、１組のアトリビュート１３を有する。

図５のサンプルは、ＲＤＢとして編成され、著者、書名、出版社、および著者＿書名というタイトル１２によって表される４つのテーブル１１を備える、データベースを示している。オブジェクトは、行１５内に配置される。例えば、書名テーブル１１のオブジェクト／行１５は、列タイトル１３として示される５つのアトリビュート１３を含む。書名テーブル１１の第４の行１５は、その値が「ＢＵ７８３２」である、タイプ「ｔｉｔｌｅ＿ｉｄ」のアトリビュート１３を有する。同じ行１５は、その値が「ＳｔｒａｉｇｈｔＴａｌｋＡｂｏｕｔＣｏｍｐｕｔｅｒｓ」である「ｔｉｔｌｅ」アトリビュート、その値が「ｂｕｓｉｎｅｓｓ」である「ｔｙｐｅ」アトリビュート、その値が「１９．９９」である「ｐｒｉｃｅ」アトリビュート、その値が「１３８９」である「ｐｕｂ＿ｉｄ」アトリビュートも有する。

リレーショナル・データベースにおけるキーは、２つの目的を有し、すなわち、キーとして機能する１つまたは複数の列を選択することによってデータベースから情報を迅速に検索し、最終的に情報をキー値によってソートする。データベース管理システムＤＢＭＳは、キーフィールドの内容と対応する行１５のロケーションのみを含むインデックスを生成し、テーブル１１の構造的完全性（ｓｔｒｕｃｔｕｒａｌｉｎｔｅｇｒｉｔｙ）を維持し、重複レコード／オブジェクトおよび列１３内における値の競合などの問題を回避するのに役立てる。

とりわけキーの中でも、主キーは、テーブル１１内のオブジェクトまたは行１５を一意的に識別する。学生テーブルでは、例えば、ｌａｓｔｎａｍｅ＋ｆｉｒｓｔｎａｍｅから構築されたキーは、一意的な識別子を与えることができない（例えば、学校に２人以上のＪａｎｅＤｏｅｓが在籍する場合）。各学生を一意的に識別するため、特別なＳｔｕｄｅｎｔＩＤフィールドを追加して、主キーとして使用することができる。

これは、図５において与えられたリレーショナル・データベースの例においても行われており、著者関係１１の主キーとしてａｕ＿ｉｄ（著者Ｉｄ）を有している。この例では、１７２−３２−１１７６というＩｄを有する新しい著者を挿入しようとする試みは、ａｕ＿ｉｄが主キーであり、すでに顧客１７２−３２−１１７６が存在するので、データベースの設計に違反する。ＤＢＭＳは、完全性制約の違反によってデータベースを不整合にする、そのようなトランザクションを拒絶しなければならない。

外部キー（ｆｏｒｅｉｇｎｋｅｙ）は、関連するテーブル内の主キーの値を表すために、１つのテーブル１１において使用されるキーである。主キーは一意的な値を含まなければならないが、外部キーは重複を有することができる。例えば、学生テーブルにおける主キーとしてｓｔｕｄｅｎｔＩＤを使用する（各学生が一意的なＩＤを有する）場合、ｓｔｕｄｅｎｔＩＤを講義（Ｃｏｕｒｓｅｓ）テーブルにおける外部キーとして使用することができ、各学生は、２つ以上の講義を履修することができるので、講義テーブルにおけるｓｔｕｄｅｎｔＩＤフィールド（しばしばＣｏｕｒｓｅｓ．ｓｔｕｄｅｎｔＩＤと略記される）は、重複値を有する。外部キーは、アトリビュート・セットの値が別の関係における候補キーから引き出されることを強制する、完全性制約である。例えば、図５の例の書名関係１１では、アトリビュートｐｕｂ＿ｉｄは、出版社関係における出版社記述へのアクセスを提供する外部キーである。

Ｘ５００モデルおよびリレーショナル・モデルの特徴についての先の説明から、ＲＤＢはデータを構造化するために関係／テーブルしか提供せず、したがって、Ｘ５００モデルよりも貧弱なシンタックスしか提供しないことが導かれる。Ｘ５００モデルをＲＤＢデータベースにマッピングする場合、第１に、データについての構造情報を提供しなければならず、第２に、Ｘ５００モデルのアドレッシング・エンティティを参照して、オブジェクトをＲＤＢ内のどこに、どのテーブル内に保存するかについてのマッピング情報を提供しなければならない。

ＤＩＴ６は、Ｘ５００エントリ７の階層的編成の静的表現である。ＤＩＴ６は、エントリ７が階層的な方法でどのように編成されなければならないかを定義する。この階層的編成は、各エントリ７のネーミングによって提供される。

Ｘ５００データモデルのすべてのエントリは、識別名ＤＮによって名付けられる。Ｘ５００データモデルは、エントリの階層的ツリーであるＤＩＴ６として編成されるので、各エントリ７は、そのペアレント・エントリとの関連において名付けられる。この名前は、エントリ７のペアレントに関連するので、相対識別名ＲＤＮと呼ばれる。ＤＩＴ６は、Ｘ５００エントリの階層的編成の静的表現である。ＤＩＴ６は、エントリが階層的な方法でどのように編成されなければならないかを定義する。Ｘ５００データモデルの階層的ツリーは、共通のルートを有する。

エントリ７の識別名ＤＮは、エントリ７のＲＤＮと、階層的ツリーのルートへと遡るそのすべての一連のペアレントのＲＤＮとの系列から構成される。ＤＮは、Ｘ５００ツリーの各エントリ７を一意的に識別する。エントリ７のＤＮから、存在するならば、それが含むエントリのＤＮを取り出すことができ、同様の操作を順次繰り返すことができる。この包含関係は、ＤＮによって伝達される唯一の関係である。他の関係をＤＮによって伝達または暗示することはできない。ＤＮは、例えば、文字列表現を使用して符号化することができる。

ＤＮの文字列表現に関する最も重要な制限は、ＲＤＮが多値データであることはできないことである。

その他の点では、出力は、ＲＤＮ系列内の各ＲＤＮを、系列の第１の要素から開始して、最後の要素に向かって進みながら符号化していった文字列から成る。

ＲＤＮ文字列表現は、以下のように、シングルトン（ｓｉｎｇｌｅｔｏｎ）ＡｔｔｒｉｂｕｔｅＴｙｐｅＡｎｄＶａｌｕｅの文字列符号化から成り、
ＡｔｔｒｉｂｕｔｅＴｙｐｅＡｎｄＶａｌｕｅは、ＡｔｔｒｉｂｕｔｅＴｙｐｅの文字列表現の後に等号文字（「＝」、ＡＳＣＩＩ６１）が続き、その後にＡｔｔｒｉｂｕｔｅＶａｌｕｅの文字列表現が続いたものとして符号化される。「，」は、ＲＤＮの間のセパレータとして使用することができる。空白およびピリオドは、以下の例、すなわち、ＣＮ＝ＪｏｈｎＴ．Ｍｉｌｌｓ，Ｏ＝ＣｙｂｅｒＳｙｓｔｅｍＣｏｎｓｕｌｔｉｎｇ，Ｌ＝Ｇｏｔｅｂｏｒｇ，Ｃ＝ＳＥにおけるように、ＲＤＮの合法的な文字シンタックスの一部として使用することができる。

これは、各エントリ７に対する一意的なＤＮを含むＤＮのリストによって、ＤＩＴのツリー構造を記述することを可能にする。これは、扱いに便利な表現である。図７は、ＤＩＴ６と等価な、ＤＮの形式をとるエントリのサンプル・リスティングを含む。この例は、後で詳細に説明される。

ソフトウェア・アプリケーションが、Ｘ５００ビューとリレーショナル・ビューの間のマッピングを任される。前記アプリケーションは、Ｘ５００モデルをＲＤＢにマッピングするのに必要なすべての情報を抽出し、管理する。

このマッピングは、
Ｘ５００オブジェクトクラスがＲＤＢテーブルにマッピングされ、
Ｘ５００アトリビュートがテーブルの列にマッピングされる、
Ｘ５００ビューとリレーショナル・スキーマの間の静的マッピングを含む。

動的マッピングに関して、エントリまたはＤＮによって示されるデータ・オブジェクトのローディングは、対応するテーブルの列内の対応する行／レコードの検索に対応する。エントリまたはアトリビュートの生成または更新または削除を扱う場合、それはそれぞれ、対応するテーブル内の対応する行／レコードの生成または更新または削除に対応する。

Ｘ５００データモデル内の各エントリについて、エントリがマッピングされるリレーショナル・データベース・テーブルのリストばかりでなく、対応するオブジェクトクラスのマッピングも知らなければならない。各オブジェクトクラスのデータがどの列にマッピングされるかを知らなければならない。

エントリがマッピングされるすべてのテーブルにアクセスするために、このエントリのＤＮからキー・アトリビュートの値を推測することもできなければならない。

これらのすべてのマッピング記述は、与えられたエントリに関するリクエストをリレーショナル・データベース・テーブル上で適切な１組のリクエストにマッピングすることを可能にするために必要である。

Ｘ５００データモデルでは、いずれのオブジェクトクラスにおいて定義されたどのアトリビュートも、リレーショナル・データモデルにおけるリレーショナル・テーブルの列名にマッピングされなければならない。

いずれのエントリにおいて定義されたどのオブジェクトクラスも、リレーショナル・データモデルにおけるリレーショナル・テーブルにマッピングされなければならない。

ＤＮシンタックス（ＤＮｓｙｎｔａｘ）ＤＮＳは、与えられたエントリをアドレスするために使用されるＤＮの構造を定義する。ＤＮシンタックスは、エントリがマッピングされる対応するテーブルを見出し、受け取ったＤＮ内のアトリビュートをこれらのテーブルの対応するキー・アトリビュートにマッピングするために、ソフトウェア・アプリケーションによって使用される。

ＤＮシンタックスＤＮＳは、ＲＤＮ記述（相対識別名記述）の系列から構成され、ＲＤＮの各アトリビュートは、適切な場合は、すなわち、ＲＤＮが可変値を有する／変数である場合は、リレーショナル・テーブルのキー・アトリビュートにマッピングされる。

１つのＤＮシンタックスＤＮＳは、唯一のエントリに関連付けられ、１つのエントリは、唯一のＤＮシンタックスを使用して、アドレスされる。

系列の各ＲＤＮ記述は、対応するＲＤＮアトリビュートの名前と、ＲＤＮが定数値、例えば、ＯＵ＝ＣＡＭＥＬなどの編成単位（ｏｒｇａｎｉｓａｔｉｏｎｕｎｉｔ）を有する場合には、その定数の値とを指示するべきである。

さもなければ、適切な場合は、異なるキー・アトリビュートへのマッピングの記述は、キー・アトリビュートに対応する列の名前と、使用するシンタックスまたは言語に応じて必要な場合は、テーブルの名前とを指示する。

ＲＤＮは、以下のいずれか、すなわち、
<RDN attributeName=“Name of a constant attribute: for example “OU””>
<VAL> value of the constant </VAL>
</RDN>

または

<RDN attributeName=“Name of the RDN attribute”
columnName=“Name of the corresponding key attribute of the table”/>
</RDN>

とすることができる。

例としてすでに定義されたＸ５００およびリレーショナル・データモデルに基づいたＤＮ記述の一例が、以下に提供される。

<DNSyntax name="Author_DN">
<RDN attributeName="authorld" columnName="au_id"/>
<RDN attributeName="OU">
<Val>BookshopOnLine</Val>
</RDN>
</DNSyntax>

<DNSyntax name="Title_DN">
<RDN attributeName="isbn" columnName="title_id''/>
<RDN attributeName="OU">
<Val>BookshopOnLine</Val>
</RDN>
</DNSyntax>

<DNSyntax name="Publisher_DN">
<RDN attributeName="publisherld" columnName="pub_id"/>
<RDN attributeName="OU">
<Val>BookshopOnLine</Val>
</RDN>
</DNSyntax>

その場合、定数ＲＤＮと可変ＲＤＮとを区別することが重要に思える。

ＲＤＮは常に、タイプおよび値を有するアトリビュートに対応する。定数ＲＤＮでは、値は定数である。可変ＲＤＮでは、値は変数である。定数ＲＤＮは、例えば、ＯＵまたは編成単位を定義することができる。そのような定数ＲＤＮは、エントリの階層的編成を定義し、ＤＩＴ内に出現する。代わりに、可変ＲＤＮは、エントリをインスタンス化することを可能にし、ＲＤＢモデルにおけるテーブルの列にマッピングされなければならない。

図１は、マッピング・プロセスと、含まれるすべてのエンティティの間の対話のＵＭＬ記述を提供している。

本発明による方法は、
各々がそのアトリビュートからなるリストを含む、オブジェクトクラスを構築するステップと、
各々がそのタイプを含む、アトリビュートを構築するステップと、
可変値がすべて除去されたＲＤＮである、スタティックＲＤＮのみを含むＤＮである、スタティックＤＮＳＤＮのみを含むスタティック・ディレクトリ情報ツリーＳＤＩＴを構築するステップと、
Ｘ５００データをＲＤＢにマッピングするステップであって、
Ｘ５００オブジェクトクラスをＲＤＢテーブルに、
Ｘ５００アトリビュートをＲＤＢテーブルの列に
関連付け、前記テーブルの列の名前を前記Ｘ５００アトリビュートとともに、前記アトリビュートをポイントするアドレスとして保存することによって、マッピングするステップと
を含む。

アトリビュートを構築するステップおよびオブジェクトクラスを構築するステップは、データの類型（ｔｙｐｏｌｏｇｙ）を獲得するうえで重要である。これは一般に、Ｘ５００モデルに存在し、ＲＤＢモデルには存在しない特徴である。

Ｘ５００モデルのみに存在する別の要点は、エントリの階層である。これは、ＤＩＴ６には含まれるが、ＲＤＢビューでは消滅し、その等価物も見出すことができない。エントリの前記階層を獲得する１つの方法は、ＤＩＴ６を保つことである。本発明の重要な特徴は、ＤＩＴ全体ではなく、階層を表す一部のみが保たれることである。有利には、スタティック・ディレクトリ情報ツリーＳＤＩＴのみを保つために、ＤＩＴ６のすべての可変部分を排除することができる。そのようなＳＤＩＴは、可変値がすべて除去されたＲＤＮである、スタティックＲＤＮのみを含むＤＮである、スタティックＤＮＳＤＮのみを含む。その除去の後、異なるエントリはそれらの値が異なるにすぎないので、多数の同一のスタティックＤＮが出現することがある。各々について１つのＳＤＮのみが保たれる。この「静的化（ｓｔａｔｉｆｉｃａｔｉｏｎ）」は、ＳＤＩＴのサイズを大きく減少させる。ＳＤＩＴは、後で説明されるように、データベースへの問い合わせにも適合される。例えば、先の例のＤＮ：｛Ｃ＝ＧＢ，Ｌ＝Ｗｉｎｓｌｏｗ，Ｏ＝ＧｒａｐｈｉｃＳｅｒｖｉｃｅｓ，ＣＮ＝ＬａｓｅｒＰｒｉｎｔｅｒ｝では、このエントリの４つのＲＤＮは可変ＲＤＮであるので、対応するスタティックＤＮは、｛Ｃ＝，Ｌ＝，Ｏ＝，ＣＮ＝｝となる。

その結果、データ・オブジェクトを含むＲＤＢは、類型情報、すなわち、オブジェクトクラスおよびアトリビュートによって、トポロジ／階層情報、すなわち、スタティックＤＩＴによって「増強」される。これらの情報は、問い合わせに対してデータベースをスキャンするために使用することができる。

別の情報もマッピング・アプリケーションによって維持されなければならず、それはマッピング・アドレス自体である。Ｘ５００データは、Ｘ５００オブジェクトクラスをＲＤＢテーブルに関連付けることによって、ＲＤＢにマッピングされる。このことは、後で説明されるように、データベース自体の実装に関して重要である。しかし、Ｘ５００データとＲＤＢデータの間の実際のリンクは、Ｘ５００アトリビュートをＲＤＢテーブルの列にマッピングすることによって維持される。これは、前記テーブルの列の名前を前記Ｘ５００アトリビュートとともに保存することによって実施することができる。その場合、そのような名前は、前記アトリビュートをポイントするアドレスとして使用することができる。有利には、これは、先に構築されたアトリビュート内に、またはスケルトンＳＤＩＴ（ｓｋｅｌｅｔｏｎＳＤＩＴ）内にも保存することができる。

これらすべての要素が定義されると、マッピング・アプリケーションを介して、Ｘ５００データベースとして、基礎的なＲＤＢを見ること、および基礎的なＲＤＢにアクセスすること、ならびにマッピング・アドレスを用いて、２つの世界の要素を結び付けることが可能となる。

そのようなマッピング・アプリケーションに達するには、データベースの来歴に応じて、２つの開始ポイントが存在し得る。

第１の開始ポイントは、請求項３に対応し、すでに構成され、データが入力された既存のＲＤＢを前提とする。既存性を利用するため、ＲＤＢはあるがままに保たれ、Ｘ５００モデルが、Ｘ５００ビューをユーザに提供するために追加されなければならない。

第２の開始ポイントは、請求項２に対応し、既存のＲＤＢではなく、データの既存のＸ５００編成と、ＲＤＢ管理ツールを使用しようという意思を前提とするが、ＲＤＢデータベースは、構築され、データが入力されることになっている。

第２のポイントにおいては、データの編成は、Ｘ５００モデル内に含まれる。前記モデルは、すべての情報、すなわち、オブジェクトクラスと、アトリビュートと、ＤＩＴまたはＳＤＩＴとを提供する。これらの情報は、前記モデルから抽出される必要があるだけである。ＤＩＴにはデータベースの全エントリが「投入」される必要はなく、階層的編成の仕様は、スタティックＤＩＴの形で、データベース作成者によって直接与えられ得ることに留意されたい。ＤＩＴにデータが入力されている場合、すなわち、ＤＩＴが入力済のＸ５００データベースに対応する場合であっても、ＤＩＴを最初に「静的化」することができる。

ＲＤＢは既存ではないので、Ｘ５００編成に合致するようにＲＤＢをあつらえ、将来のマッピングを容易にすることが可能である。その場合、ＲＤＢテーブルは、各オブジェクトクラスに対して生成される。このテーブルの列は、そのアトリビュートのリストによって定義される。その後、オブジェクトクラスに従ってテーブルを生成し、テーブルの名前およびテーブルの列を対応するアトリビュートに保存することによって、マッピングが行われる。

その後、ＲＤＢ直接アクセスを介して直接的に、またはＸ５００ビューを用いるマッピング・アプリケーションを介して、ＲＤＢにデータを入力することができる。入力済のＤＩＴまたはＸ５００完成データベースから開始する場合、すべてのデータが既知の方法で移転されなければならない。

第１のポイントにおいては、すべてが既存のＲＤＢから開始する。問題は、ＲＤＢが類型情報または階層情報をまったく含まないという事実から生じる。その場合、２つの選択肢が、管理者に提供される。

第１の選択肢は、必要とされる情報、すなわち、オブジェクトクラス、アトリビュート、およびＳＤＩＴを、ＲＤＢから自動的に引き出すことから成る。これは、例えば、各テーブルに対するオブジェクトクラス、そのようなテーブルの各列に対するアトリビュート、およびＤＩＴを構築することによって行うことができる。階層情報は、ＲＤＢ内で見出すことができないので、自動的に生成することができない。その場合、スタティックＲＤＢは生成されず、ＳＤＩＴは、ルートを含み、すべてのエントリが前記ルートに直接結合された、１レベルのツリーから成る。

第２の選択肢は、データベースの編成を増強するために、マッピングの機会を利用する。その場合、データベース管理者は、いくつかの階層レベルを追加して、多数の追加されたレベルを有するＳＤＩＴを生成することができる。そのような操作は、データをどのように編成すべきかを知っているオペレータによって手動で行われなければならない。最初はそのような情報が存在しないので、追加されなければならず、すべての一貫性がチェックされなければならない。

それらがどのような方法で獲得されたとしても、今からは、すべてのマッピング情報が利用可能であり、マッピング・アプリケーションが動作する準備ができたと見なせる。そのようなマッピング・アプリケーションは、以下のようにして使用される。

目的は、ユーザにはＸ５００を提供しながら、ＲＤＢ内に保存されたオブジェクトにアクセスすることである。与えられたエントリにアクセスすることを望む前記ユーザは、自らのリクエストのパラメータとして、エントリまたはエントリのアトリビュートを提供する。Ｘ５００ビューを用いてそれを行うため、ユーザはＤＮを提供する。このＤＮは、前記エントリのＤＮであるか、または前記アトリビュートの表示によって完結する、前記アトリビュートが属するエントリのＤＮである。その場合、リクエストは、情報取得（読み取り）リクエスト、または変更（生成、変更、もしくは削除）リクエストとすることができる。ここでの主目的は、リクエストに依存しないマッピングを説明することであるので、これらすべてのリクエストは同等と見なされる。前記マッピング・アプリケーションによって処理されるリクエスト・プロセスは、以下のステップを含む。先と同じ静的化プロセスを適用することによって、すなわち、前記ＤＮのすべての可変値を除去することによって、前記与えられたＤＮから、スタティックＤＮＳＤＮが構築／抽出される。

その後、前記ＳＤＮが、ＳＤＩＴのＳＤＮと比較され、前記ＳＤＩＴのＳＤＮの１つと一致するまで続けられる。前記一致するＳＤＮが与えられると、マッピング・アプリケーションは、前記ＳＤＮに対応するオブジェクトクラスを参照すること、および前記ＳＤＮのアトリビュート、１つのアトリビュートに対応する各可変ＲＤＮを参照することができる。前記アトリビュートの各々とともに、ＲＤＢ内における前記アトリビュートのアドレス（テーブルおよび列）が保存される。アトリビュートに対するリクエストの場合、単一のアドレスが使用される。エントリの場合、前記エントリのすべてのアトリビュートのアドレスが使用される。

前記アドレスに基づいて、マッピング・アプリケーションは、ＲＤＢ管理ツールのＲＤＢ要求言語を使用して、ＲＤＢリクエストを作成する。結果を取得するために、リクエストが前記管理ツールに対してサブミットされる。その後、前記結果をユーザに提示することができる。変更リクエストも、データを取得するのとまったく同じ方法で処理される。その場合、変更は、ＲＤＢ内容を変更／更新するために、同じアドレス機構を使用して処理される。

本発明の範囲を理解するのに役立つように、また本発明の教示を適用した使用法を提供するために、今から、方法のいくつかのステップが、一例に対して適用される。

例は、第２の開始ポイントのケースに対応する。ＲＤＢデータベースは既存ではない。例は、書籍アプリケーションに関する。データベース管理者は、図７のＤＩＴの形に階層ツリーを設計している。ＤＩＴの前記仕様はすでに静的である。前記ＤＩＴは、ルートを含んで、１１個のエントリまたは１１個のスタティックＤＮ、すなわち、ＳｃｈｅｍａＲｏｏｔ、ＡｕｔｈｏｒＲｏｏｔ、Ａｕｔｈｏｒ、Ｗｏｒｋ、Ｂｏｏｋ、ＰｕｂｌｉｓｈｅｒＲｏｏｔ、Ｐｕｂｌｉｓｈｅｒ、ＣｌｉｅｎｔＲｏｏｔ、Ｃｌｉｅｎｔ、Ｏｒｄｅｒｓ、Ｏｒｄｅｒ、ＯｒｄｅｒＤｅｓｃｒｉｐｔｉｏｎ、ＯｒｄｅｒＳｔａｔｕｓに対応する１１個の頂点／リーフを含む。

図７の前記ＤＩＴと等価な、ＸＭＬシンタックスでのテキスト表現が、図８のリストに提供されている。各エントリは、ツリー構造をテキスト上で把握するために、ＲＤＮおよびペアレントＲＤＮを含む。ツリーにおけるのと同様に、例えば、Ｂｏｏｋエントリ内で定義されるＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎなど、アトリビュートおよびそのタイプを定義する、必要なオブジェクトクラスが含まれる。ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎオブジェクトクラスは、２つのアトリビュート、すなわち、文字列型の「ｔｉｔｌｅ」と、整数型の「ｐｕｂｌｉｓｈｅｒＩｄ」とを含む。

Ｘ５００モデルから直接導出されたこのテキスト記述から、マッピング方法が、
ＳＤＮ、ＳＤＩＴの直接的テキスト表現、
エントリ内に含まれるオブジェクトクラス、および
前記オブジェクトクラス／エントリのアトリビュート
を、図９のＸＭＬリストによって示されるように抽出する。

少なくとも１つの可変ＲＤＮを含む５つの頂点／エントリに対応する、５つのスタティックＤＮが抽出される。定数ＲＤＮのみを含むエントリである純粋な定数ＤＮがＳＤＮを生じることに気づかれよう。これらのスタティックＤＮが、ＳＤＩＴを構成する。

初期ツリー内に存在するオブジェクトクラスに対応する、６つのオブジェクトクラスが抽出される。

最後に、初期定義から、１３個のアトリビュートが抽出される。アトリビュートは、それが関係するオブジェクトクラスによって区別される。例えば、「ＡｕｔｈｏｒＩｄｅｎｔｉｔｙ」のアトリビュート「ｎａｍｅ」は、「ＣｌｉｅｎｔＩｄｅｎｔｉｔｙ」のアトリビュート「ｎａｍｅ」から区別される。それらは、それぞれ「ＡｕｔｈｏｒＩｄｅｎｔｉｔｙ．ｎａｍｅ」および「ＣｌｉｅｎｔＩｄｅｎｔｉｔｙ．ｎａｍｅ」と表される。各アトリビュートは、その名前に加えて、タイプによって完成する。

ＲＤＢデータベースは既存ではないので、マッピング・プロセス中に、テーブルを生成することができる。これは、例のテーブルを生成するために使用されるＲＤＢ管理命令（ｍａｎａｇｉｎｇｏｒｄｅｒ）を示した図１０に示されている。これは、自動的に行うことができる簡単な操作である。先に抽出された６つのオブジェクトクラスに対応する、６つのテーブルが生成される。各テーブルは、オブジェクトクラス名をとって名付けられる。テーブルは、「普通」列（“ｏｒｄｉｎａｒｙ” ｃｏｌｕｍｎ）と呼ばれることもある、オブジェクトクラス抽出において識別される各アトリビュートに１つの列を含み、「特別」列（“ｓｐｅｃｉａｌ” ｃｏｌｕｍｎ）と呼ばれることもある、前記オブジェクトクラスをインスタンス化したエントリ／ＤＮ内の各可変ＲＤＮに１つの列も含む。各特別列は、テーブルの主キーであるとして宣言されもする。

例えば、「ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎ」オブジェクトクラスは、アトリビュート「ｔｉｔｌｅ」および「ｐｕｂｌｉｓｈｅｒＩｄ」を含む。２つのスタティックＤＮ、「ＡｕｔｈｏｒＩｄ」および「ＩＳＢＮ」が、オブジェクトクラス「ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎ」を使用する。その場合、４つの列、「ＡｕｔｈｏｒＩｄ」、「ＩＳＢＮ」、「ｔｉｔｌｅ」、および「ｐｕｂｌｉｓｈｅｒＩｄ」を有する、対応する「ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎ」テーブルが生成される。「ｔｉｔｌｅ」および「ｐｕｂｌｉｓｈｅｒＩｄ」は、普通列であり、「ＡｕｔｈｏｒＩｄ」列および「ＩＳＢＮ」列は、そのテーブルの主キーとして宣言されもする特別列である。

前記テーブルを生成した後、１つの最後のステップは、データのマッピング・アドレスを獲得し、保存することである。これは、例えば、各アトリビュート内に、それが出現するテーブルの識別子および列の識別子を保存することによって、マッピング・プロセス中に行われる。例えば、アトリビュート「ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎ．ｔｉｔｌｅ」は、前記アトリビュートを保存するために、ＲＤＢにおいてそれぞれ使用される、テーブルの名前「ＢｏｏｋＤｅｓｃｒｉｐｔｉｏｎ」および列の名前「ｔｉｔｌｅ」をそれぞれ含む、２つのフィールドＴａｂｌｅおよびＣｏｌｕｍｎを含む。これらのフィールド値は、ＲＤＢにおける前記テーブルの内容をアドレスするために使用することができる。

そのとき、ＲＤＢの構造は、データを受け入れる準備ができている。言い換えると、データベースにデータを入力しなければならない。図１１のＸＭＬリストに示されるように、いくつかのエントリ生成が適用される。ここでは、エントリを生成する「ｃｒｅａｔｅＥｎｔｒｙ」およびアトリビュートを定義する「ｓｅｔＡｔｔｒｉｂｕｔｅ」の２種類の命令が使用される。例えば、一連の命令

createEntry
Authorld=BALZAC,OU=Authors,OU=BookshopOnLine
setAttribute AuthorId=BALZAC,
OU=Authors,
OU=BookshopOnLine name="Honore de Balzac"
setAttribute Authorld=BALZAC,
OU=Authors,OU=BookshopOnLine country="FRANCE".

によって、エントリＢＡＬＺＡＣが生成され、その２つのアトリビュートがインスタンス化される。

その後、データベースを使用することができ、例えば、問い合わせを行うことができる。図１２および１３は、データベース・リクエストの２つのサンプルを示している。第１のものは、図１２に見られるように、エントリの読み取りを試みる簡単なリクエストである。そのリクエストは、後ろにＤＮのＡｕｔｈｏｒＩｄ＝ＢＡＬＺＡＣ，ＯＵ＝Ａｕｔｈｏｒｓ，ＯＵ＝ＢｏｏｋｓｈｏｐＯｎＬｉｎｅが続く、命令「ｒｅａｄＥｎｔｒｙ」を使用する。前記ＤＮを受け取ったマッピング・アプリケーションは最初に、可変値「ＢＡＬＺＡＣ」を除去することによって、スタティックＤＮ、すなわち、ＡｕｔｈｏｒＩｄ＝，ＯＵ＝Ａｕｔｈｏｒｓ，ＯＵ＝ＢｏｏｋｓｈｏｐＯｎＬｉｎｅを取り出す。その後、前記ＳＤＮが、スタティックＤＮ（図９のリスト）と比較され、それらのうちの第１のものが一致する。それは、オブジェクトクラス「ＡｕｔｈｏｒＩｄｅｎｔｉｔｙ」を参照し、今度は、そのオブジェクトクラスが、アトリビュート「ｎａｍｅ」および「ｃｏｕｎｔｒｙ」を参照する。対応するアトリビュート記述

Attribute="AuthorIdentity.name" Type="String(16)"
Table="AuthorIdentity" Column="name"
Attribute="AuthorIdentity.country" Type="String(16)"
Table="AuthorIdentity" Column="country"

において、アドレスを見出すことができ、それはそれぞれ、Ｔａｂｌｅ＝“Ａｕｔｈｏｒｌｄｅｎｔｉｔｙ”およびＣｏｌｕｍｎ＝“ｎａｍｅ”と、Ｔａｂｌｅ＝“Ａｕｔｈｏｒｌｄｅｎｔｉｔｙ”およびＣｏｌｕｍｎ＝“ｃｏｕｎｔｒｙ”である。その後、マッピング・アプリケーションは、「ＡｕｔｈｏｒＩｄ」を与えられた主キーと与えられた値の「ＢＡＬＺＡＣ」との照合を試みながら、テーブル「ＡｕｔｈｏｒＩｄｅｎｔｉｔｙ」を検索し、一致した行における列「ｎａｍｅ」および列「ｃｏｕｎｔｒｙ」の内容を取り出すよう指示する、ＲＤＢリクエストを作成することができる。そのようなＲＤＢリクエストは、その後、以下の結果を提供する。

>AuthorId=BALZAC,OU=Authors,OU=BookshopOnLine
>name="Honore de Balzac"
>country="FRANCE"

図１３のＸＭＬリストは、ワイルドカード「＊」を取り入れたリスト・リクエストを有する別の例を示している。

Claims

少なくとも１つのエントリ（７）と少なくとも１つのオブジェクトクラスとディレクトリ情報ツリーＤＩＴ（６）とを含むＸ５００データモデルをリレーショナルデータベースＲＤＢにマッピングする、コンピュータ・システムにおける方法であって、前記エントリ（７）は少なくとも１つのアトリビュート（８）を含み、前記アトリビュート（８）はタイプ（９）と値（１０）とを含み、前記エントリ（７）は１つのオブジェクトについての情報を集めたものであり、オブジェクトクラスは、前記オブジェクトを記述するエントリ（７）内に存在する前記アトリビュート（８）のタイプを定義するモデルであり、前記ＤＩＴ（６）内の頂点がエントリ（７）であり、各エントリ（７）は識別名ＤＮを含み、前記ＤＮは、前記ＤＩＴ（６）内のペアレントのエントリのＤＮと相対識別名ＲＤＮとを併せて含み、ＲＤＮが、前記エントリ（７）に固有の１つの特別に指名されたアトリビュート（８）を含み、前記リレーショナル・データベースＲＤＢはリレーショナル・テーブル（１１）を含み、各テーブル（１１）がいくつかの名付けられた列（１４）を含み、これらの列のいくつかがオブジェクトデータを一意的に識別する値を含む主キーであり、オブジェクトデータが行（１５）内に保存され、前記方法が、
オブジェクトクラスを構築するステップを含み、前記オブジェクトクラスの各々がそのアトリビュート（８）のリストを含み、さらに、
アトリビュート（８）を構築するステップを含み、前記アトリビュートの各々がそのタイプ（９）を含み、さらに、
スタティック・ディレクトリ情報ツリー（ＳＤＩＴ）を構築するステップを含み、前記ＳＤＩＴはスタティックＤＮ（ＳＤＮ）のみを含み、前記ＳＤＮはスタティックＲＤＮのみを含むＤＮであり、前記スタティックＲＤＮは可変値がすべて除去されたＲＤＮとして定義され、さらに、
Ｘ５００データをＲＤＢにマッピングするステップを含み、前記マッピングが、
Ｘ５００オブジェクトクラスをＲＤＢテーブル（１１）に関連付け、そして、
Ｘ５００アトリビュート（８）をＲＤＢテーブルの列（１４）に関連付けて、前記テーブルの列（１４）の名前（１３）を前記Ｘ５００アトリビュート（８）とともに、前記アトリビュート（８）をポイントするアドレスとして保存する、ことによって行われる、
方法。
オブジェクトクラスを構築するステップとアトリビュートを構築するステップとスタティック・ディレクトリ情報ツリーを構築するステップとが、Ｘ５００仕様から、前記オブジェクトクラス、前記アトリビュート（８）、前記スタティック・ディレクトリ情報ツリー（ＳＤＩＴ）をそれぞれ抽出することによって行われる、請求項１に記載の方法。
オブジェクトクラスを構築するステップとアトリビュートを構築するステップとスタティック・ディレクトリ情報ツリーを構築するステップとが、ＲＤＢの分析から、前記オブジェクトクラス、前記アトリビュート（８）、前記スタティック・ディレクトリ情報ツリー（ＳＤＩＴ）を生成することによって行われる、請求項１または２に記載の方法。
ＲＤＢにマッピングされるＸ５００の、エントリ（７）のＤＮによって定義されるエントリ（７）に対するアクセス／リクエスト、個別にはアトリビュート（８）が属するエントリのＤＮと前記アトリビュート（８）とによって定義されるエントリのアトリビュート（８）に対するアクセス／リクエストは、
すべての可変値を前記ＤＮから除去することによって、前記エントリのＤＮからスタティックＤＮ（ＳＤＮ）を構築するステップと、
スタティックＤＩＴ（ＳＤＩＴ）をフェッチして、一致するスタティックＤＮを見出すステップと、
前記一致するスタティックＤＮのアトリビュート（８）から、前記エントリ（７）のアトリビュート（８）のすべてに対応する、個別には前記アトリビュート（８）に対応する、テーブルの列（１４）のマッピング・アドレスを抽出するステップと、
前記マッピング・アドレスを含むＲＤＢリクエストを作成するステップと、
リクエストを実行するステップと、
前記リクエストの結果を取得するステップとを含む、請求項１乃至３のいずれか１項に記載の方法。