JPH10505690A

JPH10505690A - Ｘ．５００システムおよび方法

Info

Publication number: JPH10505690A
Application number: JP8508362A
Authority: JP
Inventors: ハンスハーベイ，リチャード
Original assignee: データクラフトテクノロジーズプロプライエタリーリミテッド
Priority date: 1994-09-01
Filing date: 1995-08-30
Publication date: 1998-06-02
Also published as: US20030213316A1; EP0777883A4; US20020169767A1; EP1313037B1; EP1313037A2; WO1996007147A1; US20030191759A1; EP1313038A3; US7634513B2; US6052681A; US7620623B2; EP1313038A2; ES2204962T3; US20060020613A1; US20030105749A1; US20030208478A1; EP1313039A3; DE69530595T2; EP0777883A1; EP1313039B1

Abstract

(57)【要約】本発明はＳＱＬ製品を使用してＸ．５００を実施する上での問題を解決するものである。本願はＸ．５００サービスを行うよう、リレーショナルデータベースにＸ．５００を使用すること、データベースのデザインおよびデータベースの使用法を開示するものである。特にこの開示はＲＤＢＭＳ（リレーショナルデータベースマネージメントシステム）を使用する実施例に関するものである。ここに開示された発明はサービスのモデル化に基づいて固定された組の照会／サービスを使用して任意データを処理することにある。別の発明はＸ．５００サービスを満足するようリレーショナル照会を使用してディスクをベースとするモデルを実現することにあり、ＲＤＢＭＳの利点を利用できるようにするものである。更に、本発明は秒以下の速度で実行でき、データベースのサイズ、ＤＩＴの形状、データのタイプ、エリアスを含むサービスの複雑さによって比較的影響されないＳＱＬをベースとするＸ．５００アプリケーションを提供するものである。

Description

【発明の詳細な説明】Ｘ．５００システムおよび方法分野本発明は、Ｘ．５００サービスを実行するのにリレーショナルデータベース、データベースデザインおよびデータベースの利用にＸ．５００を適用することに関する。特に本発明は、ＲＤＢＭＳ（リレーショナルデータベースマネージメントシステム）を使用する実行法に関する。本発明はデータベースアプリケーションのテーブル構造および作動方法にも関する。従来技術Ｘ．５００は電子ディレクトリのための国際規格「ＣＣＩＴＴ８９」である。これら規格は極めてフレキシブルで汎用性のあるディレクトリのサービス、プロトコルおよび情報モデルを定めており、Ｘ．５００はデータがかなり固定的（例えば電話番号帳）であるが、（例えば組織または国内で）配布する必要があり、拡張性があり（例えば店舗名、住所、仕事の肩書、装置等）、オブジェクト指向であり（すなわちデータに関する規則を実行するよう）、および／または遠隔地からアクセスする必要がある場合の情報システムに適用できる。リレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）（ＲＤＢＭＳ）はデータを記憶し、操作するためのアプリケーション用の設備を提供する。これらのシステムによって得られる多数の特徴の一部として、データの完全性、一貫性、同時性、インデクシング機構、照会の最適化、リカバリー、ロールバック、安全性が挙げられる。これらのシステムは性能のチューニング、インポート／イクスポート、バックアップ、監査およびアプリケーション開発のための多くのツールも提供する。ＲＤＢＭＳはデータの最も大規模なマネージャーのうちの好ましい選択案である。このシステムは容易に利用でき、信頼性が高く、有効なマネージメントツール多くを含むことが知られている。ＲＤＢＭＳを導入した大きなベースが存在しているので、これらシステムを作動させるのに現在では専門家が多数おり、人および方法に多大な投資がなされており、よってデータマネージャーはこれを使用して新しいシステムを得ることを期待している。ほとんどのリレーショナルデータベース製品は工業規格ＳＱＬ（構造化照会言語）をサポートしている。複雑なデータアイテムを任意に処理するためのデータの拡張性および能力を提供するオブジェクト指向システムへの動きもある。更に多くの会社および政府部門は相互接続されていない多数のデータベースアプリケーションを有しており、データベースアプリケーションがそれらのデータを統合し、それらデータの管理を簡略化できるようにする解決案をデータマネージャが求めている。Ｘ．５００およびそれに関連する規格は、これを達成できるようにするフレームワークおよびある程度の機能性を提供するものである。Ｘ．５００が国際規格であるという事実は、会社間および異なる国の間でデータを接続できることを意味している。従って、課題は現在のＳＱＬ製品の安定性、耐久性、携帯性およびコスト有効性と組み合わせたリレーショナルシステムに固有のスケーラビリティおよび性能を達成できるよう、データマネージャーのニーズを解決し、ＳＱＬ製品を使用しながらオブジェクト指向システムのすべてのフレキシビリティを備えたＸ．５００を実行することにある。これまでにかなりの時間にわたって上記課題を解決する試みが多数なされてきた。しかしながら、いずれの試みも市場に商業的に受け入れられることが証明された製品を生み出すことはなく、よって、市場では長い間解決したいというニーズがある。図１は、１９９４年４月付ＧＯＳＩＰＮｅｗｓ版第４号（出典：オープンシステムのためのセンターによりオーストラリア内で配布された「インターオペラビリティプロダクト」）からのアブストラクトを示し、このアブストラクトは現在利用できるＸ．５００製品をリストアップしている。これら製品のいずれも基礎データ憶手段としてＳＱＬデータベースを使用しておらず、従って、いずれの製品もＳＱＬＲＤＢＭＳを使用してＸ．５００を実行したいという市場のニーズを解決することに成功していない。ＩＦＩＰＷＧ６．６インターナショナルシンポジウム議事録（ＩＳＢＮ：０４４４８８９１６７）は、「Ｘ．５００ディレクトリシステムエージェントのためのリレーショナルデータベースデザイン」と題する、フランソワ・ペルチョンド、クノ・ランツおよびベルナード・プラットナー両氏により提供された論文を発行している。多くの従来のシステムと同じように、この論文に開示されているディレクトリシステムは、特にデータベースが比較的広範である場合、比較的作動が遅く、Ｘ．５００の実行、例えばエリアス、サブサーチおよびエントリー情報の点で不完全である。Ｃ・Ｍ・Ｒ・レウング氏による、１９９１年８月２２〜２４日のＩＲＥＥ議事録ＩＳＢＮ：０９０９３９４２５３には別の試みが開示されている。この文献では１つのエントリーテーブルが各ディレクトリオブジェクトに関する詳細な情報を保持するようなデータベース方式を開示しているが、これもＸ．５００を実行する上で不完全である。この方法は、多数の教科書および当業者の知識、例えばＪ・ランボー外による「オブジェクト指向モデリングおよびデザイン」（ＩＳＢＮ：０−１３−６３００５４−５）によって疑問視されており、この論文のパラグラフ１７．３．８には「１つのテーブルにすべてのエンティティを挿入することはリレーショナルデータベースデザインに対する良好なアプローチとはならない」と明瞭に述べられている。発明の概要本発明の課題は、ＳＱＬまたはその他のリレーショナル言語をサポートするＲＤＢＭＳ内でＸ．５００を実行する上での問題を解決することにある。本願はＳＱＬまたは他のリレーショナル言語をサポートするＲＤＢＭＳにおけるＸ．５００規格を実行することに関連する多数の発明を開示せんとするものである。本発明の範囲は請求の範囲および本明細書にアウトラインが述べられている。本明細書では出願時にはＳＱＬは最も普及したリレーショナル言語であり、リレーショナル言語の１つのフォームしかないが、本発明の意図はＳＱＬ以外の他のフォームのリレーショナル言語に適用せんとするものである。これら発明は次の見出しと関連付けることができる。１．基本的デザイン２．概念的デザイン３．概念的方法４．論理的デザイン５．論理的方法６．物理的デザイン７．実行例Ｘ．５００規格はディレクトリをどのように実行すべきかを定めているわけでなく、その能力およびふるまいを定めているにすぎない。実行の問題を解決する１つのキーは、任意のデータを演算できる固定された組のサービス（すなわち追加、変更、サーチ等）をＸ．５００が定義するよう実現することにある。従来技術に関連した問題は、リレーショナル理論モデル化をデータモデル化アプローチからサービスモデル化アプローチへ反転するように記述できるユニークなアプローチによって解消できることが、これまでに判っている。すなわち固定された組のデータに対する任意の照会を処理する問題から、固定された組の照会／サービスを使用する任意のデータを処理する現在のアプローチへ反転する方法である。（各データタイプの代わりに）各サービスをモデル化し、（各データタイプとの関係の代わりに）各サービスとの関係を定義する。Ｘ．５００サービスを満足するようにリレーショナル照会を使用するサービスのモデル化の実行により、ＲＤＢＭＳの利点が得られる。このアプローチの利点は多数あり、その概要は図３に示されている。これら利点の一部として次のものが挙げられる。・スタート時間が比較的速いこと。・メモリ常駐システムに対するメモリ条件を低減できること。・任意のＳＱＬデータベース上でＸ．５００をベースとすることができ、よって現在のマネージングシステムにおける製品、専門家および手順に対する投資が無駄とならないようにできること。・サイズと比較的無関係に、かつデータタイプの複雑さとは比較的無関係に性能が達成できること。・どのデータタイプも包括的に処理され、どのデータタイプもインデックスを有し、インデックス化の結果、メモリ内にディレクトリの大部分をキャッシングすることなく、ディレクトリを効率的にサーチできるようになること。・１つの特定の照会を満足するのに１つのインデックスしか利用できない従来技術と異なり、大部分の情報をメモリにシステム的に集中キャッシングし、サーチすること。・種々の対照化シーケンスを有し得る異なる言語（例えばスペイン語、ヘブライ語および漢字）をサポートできること。シングル、ダブルまたはその他のバイトのキャラクターの組をサポートできること。・Ｉ／Ｏを最小にし、Ｉ／Ｏを効率的に検索するのにディスクをベースとするモデルを使用すること。・複雑なＸ．５００サーチをサービスできること。・性能および耐久性と妥協することなく、これまで可能であったサイズよりもより大きいサイズのＸ．５００データベースを構築できること。このデータベースは小さくしたり大きくしたりできる（２５万個、１００万個またはそれ以上の数のエントリー）。・最適なテーブルデザインによりディスクスペースの無駄を最小にできること。・リレーショナルデータベースの開発に年間延べ何百人も削減でき、高性能アプリケーション開発のために証明済みの信頼性、完全性、安全性およびツールを備えた、工業的に強力なデータベースを使用できること。このようなユニークなアプローチに基づき、下記の説明では現在のＸ．５００システムの概略を略図で示す図２Ａおよび２Ｂを参照し、順に多数の発明を詳細に説明する。ここに開示するテーブルおよびコラム、名称、コラムおよび数値の順は概観するために任意に示したものである。ここに開示したコラムの数は好ましい作動可能な条件を示す。追加されたコラムは本明細書で意図するテーブルの用途を変えるものではない。１．基本的デザインＸ．５００の従来の実行の試みではＸ．５００の条件および機能性とＳＱＬとの間の比較的基本的な構造および作動上の差を克服できなかった。Ｘ．５００規格は性質上特殊な構造となっているが、一方、ＳＱＬはリレーショナル構造のテーブルに対して演算するよう設計されている。代表的なリレーショナルデータベースアプリケーションに対するデータの性質は周知となっている。すなわちテーブルは多数のコラムから成り、各コラムは特定のデータタイプに関するデータを含む（表Ｂ１参照）。記憶できる異なるデータのタイプはテーブルのコラムに限定される。データのタイプはデータベースによってサポートされるタイプ（例えばストリング、数字、金額、日付）に限定される。データベースはデータベース自体によっては理解されないが、アプリケーションによっては理解できるフォームのデータ、例えば２進データも記憶できる。新しいデータのタイプ（例えば携帯電話番号）を追加する必要がある場合には表に新しいコラムを追加しなければならない。これによりデータのテーブルの変更を実行することが容易でないという問題が生じる。更に、新しいデータのタイプがあまり使用されていない場合（組織の１％よりも少ない場合）、かなり冗長なデータ記憶システムが生じることとなる。表Ｂ２を参照のこと。基本的にはＸ．５００の使用における発明は、雇用者番号名前年令給料と記載される従来のＸ．５００の属性をタイプシンタックス値として表示することにより、拡張性を克服することにある。後者の表示は拡張可能な表示になり、よってＳＱＬによる実行に適合している。後者の表示はメタデータとして知られており、このメタデータの「値」は２進とすることができる。上記基本デザインに基づく別の解決方法は、この基本デザインをＸ．５００に適応させることである。この適応化は基本デザインにオブジェクトネームおよびペアレントネームを追加するプロパティテーブルを設けることによって実現されている。これまで示した実行法により、次のような別の利点が得られる。ａ．フィルターの複雑さから独立していること。すなわち開示した実行法はＳＱＬ内に設けられた照会オプティマイザーを利用できるので、本発明を実施する各プロプリエタリデータベース内で照会オプティマイザーをレプリケートする必要はない。ｂ．サイズから独立していること。すなわち開示した実行方法は能力を拡大できる。ｃ．ツリーの深さと独立していること。開示した実行方法は階層的な比較の可能性を有している。ｄ．高性能であること。タイプコラムにインデックスを追加する場合、各タイプごとにインデックスを付ける。２．概念的デザイン従来技術はＸ．５００の条件である拡張性のための構造となっていなく、オブジェクト指向ではなく、階層的でもないので、Ｘ．５００を実行する上で困難であった。この問題は、プロパティテーブルを機能的に分解し、よって概念的デザインと称されるものを創ることにより１つのフォームで解決される。概念的デザインは次のうちの少なくとも１つを提供することにある。１．テーブルに行を加えることにより、このテーブル内に新しい属性のタイプを定義できるようにすることにより、拡張性を解決した属性テーブル。２．各オブジェクト内に属性を定めるオブジェクトテーブル。３．オブジェクト間の関係を定める階層テーブル。別の発明ではこの問題は図２Ａおよび２Ｂに記載されている表に従うテーブル構造を設けることによって解決される。更に別の発明は、オブジェクトテーブルの値のコラムを正規の値および未処理の値のコラムと置換するためのシステムを現在のＸ．５００に設け、および／または階層テーブル内のＲＤＮコラムを正規ネームおよび未処理ネームコラムと置換することによりデータトレランスの問題を解決することにある。更にエリアスを収容する上での従来技術の問題は、階層テーブル内にエリアスのコラムを設けることにより現在のＸ．５００システムで解決される。このエリアスのコラムはそのエントリーがエリアスであることを示すようフラグが付けられる。エリアスコラムをエリアスコラムおよびＡ−ＥＩＤコラムと置換することによって更に精密にできる。Ａ−ＥＩＤはエリアスがどこをポイントしているかについての情報を提供するものである。階層テーブル内のペアレントコラムを、ペアレントコラムおよびパスコラムと置換することによって更に精密にできる。このパスコラムはＸ．５００サーチを実行する上での問題をエリアスおよびサブツリーで解決するものである。このパスは次の少なくとも２つのユニークな性質を有する。ａ）階層内の絶対的位置を決定すること、およびｂ）そのプリフィックスによりエントリーが所定のサブツリー内にあるかどうかを判断するのに使用される。３．概念的方法次の詳細な説明には、下記のことを含む概念的デザインに質問を行う多数のユニークな方法が開示されている。ａ）ＳＱＬステートメントのシーケンス内にＸ．５００サービスをマッピングすること、ｂ）サーチストラテジーとはパスまたはペアレントコラムを使用してサーチエリア上でフィルタを使用することであり、および／または、ｃ）Ａ−ＥＩＤコラムにおいてエリアスポイントをどこにキャッシュするかをナビゲーションする間に、エリアスを処理する際、ｄ）サーチ中にエリアスを処理する際にサーチが必要なツリーのエリアを決めるベースオブジェクトのユニークな組を探し、ツリーの各エリアに対し上記ｂ）を適用する。別の発明は、Ｘ．５００オブジェクトＩＤからＡＩＤを探すための入力データに対し属性テーブルを使用し、データベースから読み出された出力データに対してはこの逆を行うことにより実施される。更に、区分入力される名前に対しては、この名前は適当なＥＩＤにナビゲートされ、Ｘ．５００が必要とするように各サーチが実行される。更に、サーチに対しシングルパス分解によりパスコラムを使ってフィルタおよびサブツリーサーチを行うことができる。１つの方法は、任意のサブツリーに対し任意のフィルタを同時に適用するよう、パスフィールドを使用することである。エリアスの複雑さはユニークに分解されたサブツリーに対し上記方法を適用することによって処理される。更に別のユニークな方法は、各エントリーのパスをストリングとして記憶することである。次に、各パスにペアレントエントリーのパスをプリフィックスとして付ける。このことはサーチサービスにおけるフィルターに対して有効である。４．論理デザイン論理デザインはＸ．５００サービスコンポーネントを独立させる実施による概念的デザインのサービス分解に基づくものである。これから得られる利点は次のとおりである。１．多くのテーブルを設けるにつれ、テーブルごとのインデックスの数が減少する。主要インデックスが最も効率的（速度、サイズ）であり、二次的インデックスは大きなオーバーヘッド（速度、サイズ）を有し得る。２．テーブル内のデータをクラスター状にできる。主要キー（記憶構造）の結果としてクラスターが生じ、よってディスク上でそのキーの回りにデータを編成できる。例えばサーチテーブルに対しては姓名をクラスター状にできる。３．マネージメント--より小さいテーブルは管理が容易であり、すなわちより速くインデックスを更新し、統計を集め、監査し、バックアップできる等である。４．Ｉ／Ｏが少なくなる--行が少なくなることによりスピードが改善され、このことはページ当たりの行が多くなり、よってより少数のＩ／Ｏを演算できる。５．論理的方法次の詳細な説明には論理的デザインテーブルに質問する多数のユニークな方法が開示されている。更に、１つの方法として属性テーブルをキャッシングする方法がある。従って、（初期ローディングを除けば）データベースにはＳＱＬステートメントが出されない。本Ｘ．５００システムではメモリ内で変換を実行する。これにより実質的な速度上の利点が得られる。更に、データベースのロールバックを回避する有効化がメモリ内で実行される。このようなロールバックは時間とシステムを費やすものである。更に、任意フィルターに対しダナミックなＳＱＬ等価体が構築される。これによりＸ．５００サーチ内で任意の複雑性が可能となる。サーチ結果に対しても本システムはＳＱＬのセットオリエンテーション照会を利用し、一括行処理を回避する。従って、サーチ結果をメモリ内でパラレルに組み立てることができる。６．物理的デザインコラム幅およびキーサイズの制限を克服し、スペースの最適化を達成するために、新しいテーブルおよび新しいコラムが導入される。次のテキストは次に概要を述べる発明の実施例を開示するものである。１．基本デザイン図２Ａを参照すると、基本デザインはリレーショナルテーブル内でＸ．５００の拡張性のあるオブジェクト指向の階層的性質を示す基本的問題を解決するものである。このセクションでは、下記の表１に示されるように単一のテーブルによって基本テーブルデザインを表示できることが（例をもって）開示される。この章および次の章全体では各テーブル内のすべてのコラム名およびそれらの位置は任意である。意図は、これらが何を含み、どう使用するかを定義するものである。１．１拡張性代表的なリレーショナルデータベースアプリケーションに対しデータの性質は周知である。表は多数のコラムから成り、各コラムは特定のデータタイプに関連するデータを含む（表１．１ａ）この表自体が記述的である。データアイテム間の関係は同じ列内に含まれることによって暗示される（このことがリレーショナル理論の基礎である）。しかしながら、異なるデータタイプの数はテーブルのコラムの数に限定されているので、上記アプローチには拡張性がない。新しいデータタイプ（例えば移動電話番号）を追加する必要がある場合、テーブルに新しいコラムを加えなければならない（表１．１ｂ）。このテーブルにアクセスするアプリケーションはこれに明瞭な照会をするのに更新する必要がある。実際には別の問題もある。新しいデータのタイプがよく使用されない場合（例えば組織のうちの１％より少ない者しか携帯電話をもっていない場合）、テーブルは空欄が増すこととなる（すなわちある人が携帯電話をもっていない場合、列／コラムの入力は空欄となる）。更にデータベースのタイプはデータベースによってサポートされているタイプ（例えばストリング、数値、金額、日付等）に限定される。解決案は、データのタイプを包括的なものとして取り扱うことである。本発明は任意の属性（例えばＸＯＭ［X/Open Object Management］ＡＰＩ［Applicatio n Programing Interface］）をタイプとシンタックスと値との組み合わせとして示す方法を採用するものである（表１．１ｃ参照）。１．２オブジェクト指向Ｘ．５００は任意の数の属性を含むことができるオブジェクト（人、組織等）を定義する。テーブル内には多くのオブジェクトを記載しなければならないので、各オブジェクトを区別するようなメカニズムが必要である。この目的のため、テーブルにはオブジェクト名のコラムが追加される（表１．２ａ参照）。上記方法は任意の数の属性をエントリー内に割り当て（関連づけできるようにする）。これら属性は任意の複雑さとすることができる（例えばマルチラインの郵便の宛て先を処理できる）。コラムの数が固定されている場合、アプリケーションを再定義することなく任意のオブジェクトに新しい属性を追加できる。新しい属性を追加する場合、エントリーを読み出すアプリケーションは追加の列を取り戻す。１．３階層的階層的システムを表示する方法（例えばパーツイクスプロージョン）は親子の組み合わせを使用することである（表１．３ａ参照）。Ｘ．５００はそのオブジェクトを階層的となるように定義する。オブジェクト間の関係はツリー構造であり、ここでは各オブジェクトはペアレントのオブジェクトを有し、各ペアレントは０またはそれ以上の子を有し得る。この関係はペアレントオブジェクトのネームを記憶するのに使用されるペアレントネームのコラムを加えることにより、一般的ＰＲＯＰＥＲＴＹテーブルに示すことができる。ツリーのルート部にはペアレントがないことに留意されたい。従って、Chris およびAlana の両者がデータクラフト社で働き、データクラフト社がルートのチャイルドである場合、Chris とAlana はデータクラフト社のチャイルドであり、データクラフト社はChris とAlana のペアレントであるということができる。２．概念的デザインセクション１において、単一プロパティテーブルによってＸ．５００の拡張性のある、オブジェクト指向の階層的性質を示すことができる（表２ａを参照のこと）。図２Ａを参照すると、このセクションでは下記に示す３つの表（例えば表２ｂおよび表２ａ参照）を使用することによってＸ．５００の機能全体を表示できることが判る。この概念的デザインはリレーショナルテーブル内で完全なＸ．５００機能を実行することにより主要な問題を解決するものである。主な各デザインの問題が示される際に、この解決案を示すよう例が示される。２．１機能上の分解プロパティテーブル（図２Ａ）は、好ましくは次のようなＸ．５００の階層的な、オブジェクト指向の拡張性のある性質を表す別個の表に分解できる。すなわち、・オブジェクト間の構造的な関係を決める階層テーブル・各オブジェクト内の属性値を定めるオブジェクトテーブル・異なる属性タイプを定める属性テーブルである。これらテーブルは機能的分解と称されるプロセスから得られる。テーブル間の関係を相関化する問題を解決するために、任意の数値識別子が導入される。ＥＩＤすなわちエントリー識別子は各オブジェクトと、その階層情報とを相関化する。ＡＩＤすなわち属性識別子はオブジェクトテーブル内の各値と、その属性情報とを相関化するものである。プロパティテーブル内の繰り返されるグループ（タイプ−シンタックスおよびオブジェクトネーム−ペアレントネーム）は既に除かれているので、このデザインは極めて効率的であると考えられる。また、ＳＱＬでは接続コラムは簡単な整数となる。２．２Ｘ．５００属性Ｘ．５００属性はエンドシステム間でデータを伝送する際に変換されるプロトコル識別子を有する。これら識別子は国際的に定義され、OBJECT IDENTIFIERS（オブジェクト識別子）と称される（例えば２．５．４．４は姓名のストリングを示す）。従って、Ｘ．５００オブジェクト識別子と内部属性識別子との変換を行えるように、属性テーブルにオブジェクト識別子のコラムを加えることができる。更に、Ｘ．５００により属性は任意の数の値を有することができる（例えば移動電話の番号を第２の電話の番号と扱うことができる）。したがって、オブジェクトテーブル内の属性内の値を識別するように、値識別子すなわちＶＩＤが導入される。２．３Ｘ．５００ネームＸ．５００では各エントリーはエントリーをネーミングするために１つ以上の属性値（区分値）を使用する。区分値にフラグを付けるため、オブジェクトテーブルに区分用コラムが追加される。これら区分値は組み合わされてエントリーの名称を定める相対的な区分ネーム（ＲＤＮ）を形成する。階層テーブル内のネームコラムはこのＲＤＮを記憶する。これによりオブジェクトテーブル内の区分値からＲＤＮを構成する必要をなくす最適化がなされる。１つのエントリーはルート部から下方の先行者のＲＤＮおよびオブジェクト自体のＲＤＮから成る区分ネーム（ＤＮ）により一義的にネーミングされる。改良点は、ツリー内のエントリーの絶対的位置をＥＩＤのリストとして定義する階層テーブルへパスコラムを加えることである。パスは次の３つの重要な性質を有する。１）ＤＮを高速で構成できる（ＥＤＩリストはＲＤＮのすべてを定義する）。２）高速サブツリーサーチを可能にする（概念的方法を参照）。３）ＤＮから独立している（ＤＮ内のＲＤＮはパスに影響することなくネーミングできる）。２．４Ｘ．５００エリアスＸ．５００はエリアス（別名）の概念を有する。エリアスオブジェクトは別のエントリーを有効にポイントするので、そのエントリーのための別のネームを提供する。従って、階層テーブルにはエントリーフラグが付けられる。ナビゲーション中にエリアスが発見されると（すなわち供給されたＤＮがエリアスを含むと）、オブジェクトテーブルからエリアス値を読み取らなければならない。このエリアスのＤＮは元のエントリーのナビゲーションを続けることができる前にエリアスがポイントする点まで分解しなければならない。改良点は、エリアスがポイントする場所を記憶するようにエリアスのついたＥＩＤコラムすなわちＡＥＩＤを使用することである。これによりエリアスによって繰り返しナビゲートすることが不要となる。２．５Ｘ．５００データトレランスどのＸ．５００属性も（国際的に定義された）シンタックスを有する。Ｘ．５００属性シンタックスは各属性をどのように処理すべきかを定義する。すべてのストリング状のシンタックス（例えばプリント可能なもの、数値等）では、不要なスペースは無視すべきであるとされる。あるシンタックスではケースは重要でなく（例えばケース無視ストリングおよびケース無視リスト）、よってネーム「 Chris Masters」、「Chris MASTERS」および「ChRisMaSTeRS」は同一であると考える。比較をするため（例えば特定の値のサーチのため）、正規化されたフォーム（例えば「CHRIS MASTERS」を形成するためにシンタックス基礎区を適用できる。データベース内にこの正規化されたフォームが記憶されていれば、入力フォームのバリエーションを効果的に除く（ＳＱＬを使用する際に必要な）正確なマッチングを使用できる。データベース内には正規化されたデータと未処理データの双方が記憶される。未処理データは最初に入力した時と全く同じフォーマットでユーザーがデータを検索するのに必要である。従って、階層テーブル内のName（ネーム）コラムはNa meRaw（未処理ネーム）となり、NameNorm（正規ネーム）コラムが追加される。同じように、オブジェクトテーブル内のValue（値）コラムはValueRaw（未処理値）コラムとなり、ValueNorm（正規値）コラムが追加される。３．概念的方法この章では、基本的なＸ．５００サービスを照会し、Ｘ．５００サービスおよびその複雑性を実行するのに表３ａまたは図２Ａに示された概念的テーブルデザインがどのように充分であるかを示す。これらサービスを示すのに表３ｂに示された階層の例が使用される。フローチャート内の各ネームはデータベース内のオブジェクトエントリーを示す。三角形はエリアスエントリーを示し、点線はエリアスエントリーと、これがポイントするオブジェクトとの間を示す。各エントリー横の数字はエントリーＥＩＤである。この例において、エントリー１は「Datacraft」の値を備えたＲＤＮを有し、エントリー１１は「Sales」の値を備えたＲＤＮを有し、エントリー２０は「Net work Products」の値を備えたＲＤＮを有し、エントリー３１は「Arana Morgan 」の値を備えたＲＤＮを有し、エントリー３１のＤＮはＲＤＮのシーケンスすなわち「Datacraft」「Sales」「Network Products」「Arana Morgan」から成る。エリアスエントリー「Datacraft/Networks」はエントリー「Datacraft」、「S ales」、「Network Products」をポイントする。このエントリーへナビゲーションする際にナビゲートプロセスがエリアスエントリーを探し、エリアスによりポイントされたオブジェクトのＤＮを探し、ルート部からオブジェクトエントリーにナビゲートし、２０のＥＩＤおよび１．１１．２０のパスへ戻る。下記にサンプルテーブルを示すが、このテーブルはデータをどのように記憶するかを示している。階層テーブル（表３ｃ）は階層の例のためのエントリーをどのように記憶するかを示している。属性テーブル（表３ｅ）は「Datacraft/Sale s/Network Products/Chris Masters」に含まれる属性を示す。オブジェクトテーブル（表３ｄ）はこれら属性の値をどのように記憶するかを示す。区分ネームサンプルのオブジェクトテーブル（表３ｄ）に示されたエントリーに対し属性、共通ネームおよび姓名のうちの２つが区分値（またはネーミング値）であり、これらネームは組み合わされて入力のためのＲＤＮを形成する。このＲＤＮは階層テーブル内に記憶される。多値属性Ｘ．５００では属性が多値となることを許容している。属性に対する値を区別するのにＶＩＤコラムが使用されている。サンプルのオブジェクトテーブルでは電話番号属性が多値となっている。３．１ＳＱＬへのマッピングサービス３．１．１属性のタイプおよび値Ｘ．５００サービスによって供給されるデータはオブジェクトＩＤおよびそれに関連する値のリストとして供給される。これらデータはＸ．５００アプリケーションによって使用できるよう（属性テーブルを使用する）ＡＩＤおよび（オブジェクトテーブルを使用する）正規化された値に変換しなければならない。データベースはＡＩＤおよび未処理の値をリターンし、これら値はＸ．５００の結果内のオブジェクトＩＤおよびそれに関連する値に変換しなければならない。３．１．２ナビゲーション各Ｘ．５００サービスはＸ．５００アプリケーションによって使用するためのＥＩＤで変換される区分ネームを供給する。アプリケーションがサービスを処理すると、アプリケーションは１つ以上のＥＩＤをリターンする。これらＥＩＤはＸ．５００の結果における区分ネームに変換することができる。全てのＸ．５００サービスはディレクトリのツリーをナビゲーションすることに依存している。特定のエントリーにナビゲーションするために次の方法が実行される。・エントリーのためのＤＮが与えられるとＤＮ内の最初のＲＤＮに等しいＲＤＮを有する階層テーブル内のエントリーを探す。・ＥＩＤを記憶する。・ＤＮ内の次のＲＤＮに等しいＲＤＮおよび記憶されたＥＩＤに等しいペアレントを有するエントリーを探す。例：「Datacraft/Sales/Network Products/Peter Evans」へナビゲートする。この結果、多数の選択ステートメントが生じ、各々のリターンされたＥＩＤは次のステートメント内のPARENTの値として使用される。 PARENT＝０およびＲＤＮ＝DATA CRAFTの場合 HIERARCHY からＥＩＤを選択する PARENT＝１およびＲＤＮ＝SALES の場合 HIERARCHY からＥＩＤを選択する PARENT＝１１およびＲＤＮ＝NETWORK PRODUCTSの場合 HIERARCHY からＥＩＤを選択する PARENT＝２０およびＲＤＮ＝PETER EVANS の場合 HIERARCHY からＥＩＤを選択する３．１．３読み出し読み出すべき選択された属性を供給できる。これら属性の値（エントリー内に存在している場合）だけがリターンされる。読み出しオプションとして「Types Only」を選択できる。この場合、値はリターンされない。エントリー内に存在する全てのタイプまたは選択されたタイプはリターンされる。読み出すべきエントリーへナビゲートし、ＥＩＤを記憶し、オブジェクトテーブル内で記憶されたＥＩＤに一致する全ての行の値を読み出す。例：・エントリー「Data craft/HQ/Network Products」を読み出し、全てのタイプおよび値をリターンする。（３．１．２と同じように）エントリーへナビゲートし、次に、ＥＩＤ＝２０であれば OBJECTからＡＩＤ、VALUE RAW を選択する。３．１．４比較比較により一致した結果または一致していない結果をリターンする。未処理の値を入力するが、正規化された値を使用して比較を実行する。必要なエントリーへナビゲートし、ＥＩＤを記憶し、オブジェクトテーブルにおいて記憶されたＥＩＤおよび特定のＡＩＤに一致する全ての行内の一致する値をテストする。例：・電話番号「０３７２７９２５６」と入力「Data craft/Sales/Network Products/Chris Masters」とを比較する。エントリーへナビゲートし、次にＥＩＤ＝３０およびＡＩＤ＝２０およびVALUENORM ＝「０３７２７９４５６」である場合 OBJECTからVALUENORM を選択する。値が選択されれば「一致する」へリターンし、そうでない場合、「一致しない」へリターンする。３．１．５リスト必要なエントリーへナビゲートし、ＥＩＤを記憶し、階層テーブル内で記憶されたＥＩＤに一致するペアレントがを備えた全ての行に対しＲＤＮをリターンする。例：・エントリー「Data craft/Sales」からリストする。エントリーへナビゲートし、次に PARENT＝１１の場合、 HIERARCHY からNAMERAW を選択する。３．１．６エントリーの追加必要なペアレントエントリーへナビゲートし、ペアレントのＥＩＤを記憶し、階層テーブルへ新しいＥＩＤを追加し、新しいエントリー内の値ごとにオブジェクトテーブルへ行を追加する。例：・エントリー「Data craft/Sales/Network Products」の下に新しいエントリーを追加する。エントリーへナビゲートし、次に OBJECT（EID、AID、VID、DISTING、VALUENORM、VALUERAW）内に値（３３、３、１、１、EDWIN MAHER、Edwin Maher）を挿入し、更にHIERARCHY（EID、PARENT、PATH、ALIAS、A＿EID、NAMENORM、NAMERAW 内に値(３３、２０、１．１１．２０．３３．、０、０、EDWIN MAHER、Edwin M aher)を挿入する。３．１．７エントリーの削除必要なエントリーへナビゲートし、エントリーがツリー上のリーフであるかをチェックする（すなわちツリー上に下位のエントリーがないことをチェックする）。ＥＩＤを記憶し、階層テーブルからエントリーを削除する。オブジェクトテーブルにおいて記憶されたＥＩＤに一致する全ての行を削除する。例：・エントリー「Data craft/Sales/Network Products」の下から（ＥＩＤ＝３３を有する）エントリーを削除する。エントリーへナビゲートし、次にＥＩＤ＝３３であれば OBJECTから削除し、ＥＩＤ＝３３であれば HIERARCHY から削除する。３．１．８エントリーの変更必要なエントリーへナビゲートし、ＥＩＤを記憶し、オブジェクトテーブルにおいて記憶されたＥＩＤに行を追加、削除または変更する。例：・エントリー「Data craft/Sales/Network Products/Alana Morgan」を変更する。値−肩書「Branch Manager」を追加する。エントリーへナビゲートし、次にＥＩＤ＝３１であれば、 OBJECTからEID、AID、VID、VALUENORM を選択する。肩書の属性に対してリターンした行を検査する。何もない場合は属性を加えることができ、存在している場合は多値とすることができるが、それ以外の場合、属性をチェックし、多値とすることができれば、既に存在しているかどうかを見なければならない。 OBJECT（EID、AID、VID、DISTING、VALUENORM、VALUERAW）内へ値（３１、１２、１、０、BRANCH MANAGER、Branch Manager）を挿入する。３．１．９ＲＤＮの変更必要なエントリーへナビゲートする。サブツリーの現在レベル内に新しいネーム（ＲＤＮ）が存在していないかどうかチェックする（すなわち新しいＤＮが異なるものであるかどうかをチェックする）。ＥＩＤを記憶し、階層テーブルおよびオブジェクトテーブル内の入力を変更する。例：・エントリー「「Data craft/Sales/Network Products/Chris Masters」のＲＤＮを「Chris Masters」に変更する。 PARENT＝２０ VALUENORM ＝CHRISTINE MASTERS」であれば HIERARCHY からＥＩＤを選択する。エントリーをリターンしない場合には新しいＲＤＮを挿入してもよい。まず古いＲＤＮを区別しない値にセットする。ＥＩＤ＝３０およびVALUENORM ＝「CHRIS」であれば OBJECTを更新し、 DISTING ＝０とセットし、ＥＩＤ＝３０であれば HIERARCHY を更新し、 NAMENORM＝「CHRISTINE MASTERS」とセットし、 NAMERAW ＝「Christine Masters」とし、 OBJECT（EID、AID、VID、DISTING、VALUENORM、VALUERAW）内に値（３０、３、１、１、「CHRISTINE」、「Christine」）を挿入する。３．２サーチストラテジー最も強力で有効なＸ．５００サービスはサーチサービスである。このサーチサービスによってディレクトリインフォメーションツリーの一部（サーチエリア）上に任意複雑フィルタを使用できる。・フィルタとは演算子ＡＮＤ、ＯＲおよびＮＯＴに接続された１つ以上のフィルタアイテムの組み合わせである。例えば姓＝「MASTERS」ＡＮＤ肩書＝「SAL ES MANAGER」である。・サーチエリアとはサーチ範囲によってカバーされるツリー部分のことである（ベース−オブジェクトのみ、ワンレベルまたは全サブツリー）。サーチを分解する１つの技術は、フィルタを適用し、サーチエリア内に一致するエントリーがあるかどうかを見ることである。この場合、全ツリーにフィルタを適用し、フィルタに一致する全ての列に対するＥＩＤをリターンする。次に発見された各ＥＩＤに対し階層を上にとるようステップ状にサーチし、エントリーがベースオブジェクトの下位であるかどうかを見る（すなわちエントリーがベースオブジェクトのペアレント／グランドペアレント／....を有するかどうかを見る。一致する数が多く、サブツリーが小さい場合、このサーチは極めて非効率的である。エリアスはポイントするオブジェクトのペアレントでないので、この技術はエリアスには適合せず、１つのオブジェクトを多数のエリアスがポイントすることもできる。第２のストラテジーはサーチエリア内のすべてのＥＩＤのリストを得て、これらＥＩＤにフィルタを適用することである。元のサーチエリアの外をポイントするエリアスを分解する場合に、エリアスによってポイントされるサブツリーを拡張し、リストにそのサブツリー内のＥＩＤを加える。次に、拡張されたＥＩＤの組にフィルタを適用する。サーチエリアが広い場合、この方法は極めて悪い。改良点は、（上記２つの方法と同じようにシーケンシャルに行う代わりに）サーチエリア用にフィルタを同時に使用することである。この方法はシングルパス分解と称される。この方法は検索される行がフィルタおよびサーチの範囲条件の双方を満たすものであるので、上記２つの方法よりも性能をかなり改善すると考えられる。ワンレベルサーチを実行する時はベースオブジェクトのＥＩＤに等しいペアレントを有する全てのエントリーにフィルタを適用する（例えばペアレント＝２０がエントリー３０、３１、３２にフィルタを適用する場合のサーチである）。サブツリーサーチを実行する場合はパスを使用してサーチエリアを拡張する。各エントリーのパスは数字のストリングである（例えば「１．１０．５０．２２２．」はエントリー２２が５０のペアレント、１０のグランドペアレントおよび１のグレートグランドペアレントを有することを意味する）。エントリーのパスがそのエントリーの下位にある全てのエントリーのパスのプリフィックスであるというユニークな性質を、パスが有する。すなわちエントリーのパスはそのエントリーの下方のサブツリー内の全てのエントリーのパスのプリフィックスを形成する。よってサブツリーサーチを実行する時にはサブツリーのベースオブジェクトを得てベースオブジェクトのパスによってプリフィックスのついたパスを有する全てのエントリーに対してフィルタを適用する（例えば「Sales」の下の全てのエントリーのサーチをするためにPATHLIKE １．１１．％のサーチを行う）。ベースオブジェクトサーチベースオブジェクトへナビゲートし、ＥＩＤを記憶し、オブジェクトテーブルにおいてフィルタ基準が満足する場合の記憶されたＥＩＤ、例えば電話プリフィックス＝「７２７」と一致する行からのノミネートされた値を読み出す。例：・「ベース−オブジェクトオンリー」サーチを使用し、姓＝「MORGAN」を有するエントリーに対するベースオブジェクト「Datacraft/Sales/Network Produc ts」からサーチする。ベースオブジェクトへナビゲートし、ＥＩＤ＝２０およびＡＩＤ＝４およびNAMENORM＝「MORGAN」であればオブジェクトからＡＩＤ、VALUERAWを選択する。ワンレベルサーチベースオブジェクトへナビゲートし、ＥＩＤを記憶し、（階層テーブル内の）記憶されたＥＩＤに一致するペアレントＥＩＤを有し、フィルタ基準（OBJECTテーブル）を満足させる値を有するＥＩＤのリストをリターンする。オブジェクトテーブル内でリターンされたＥＩＤのためのノミネートされた値を読み出す。例：・「ワンレベルオンリー」サーチを使用し、姓＝「MORGAN」を有するエントリーに対するベースオブジェクト「Datacraft/Sales/Network Products」からサーチする。ベースオブジェクトへナビゲートし、 PARENT＝２０およびＡＩＤ＝４およびNAMENORM＝「MORGAN」およびH.EID ＝O.EID の場合、 HIERARCHY H、OBJECT OからH.EID を選択する。次に、リターンされたＥＩＤをEIDLIST へ入れ、［EIDLIST］内にＥＩＤがある場合、 OBJECTからＡＩＤ、VALUERAWを選択する。サブツリーサーチベースオブジェクトへナビゲートし、ＥＩＤを記憶し、ベースオブジェクト（階層テーブル）のパスに類似し、フィルタ基準（OBJECTテーブル）を満足させる値を有するパスを備えた全てのＥＩＤのリストをリターンする。オブジェクトテーブルではリターンされたＥＩＤのためのノミネートされた値を読み出す。例：・「全サブツリー」サーチを使用し、姓＝「MORGAN」を有するエントリーに対するベースオブジェクト「Datacraft/Sales/Network Products」からサーチする。ベースオブジェクトへナビゲートし、 PATH like 「１．１１．２０．％」およびＡＩＤ＝０およびNAMENORM＝「 MORGAN」およびH.EID ＝O.EID の場合、 HIERARCHY H、OBJECT OからH.EID を選択し、次に、リターンされたＥＩＤをEIDLIST へ入れ、［EIDLIST］内にＥＩＤがある場合、 OBJECTからＡＩＤ、VALUERAWを選択する。３．３エリアスおよびナビゲート「ドント−デリファレンス−エリアス」フラグがセットされておらず、サービスが更新サービスでなければ、ナビゲーション中にエリアスを分解する（追加、削除、変更、ＲＤＮ変更）。ナビゲーション中にエリアスが発見されると、このエリアスは分解しなければならない。すなわちエリアスがポイントするオブジェクトを得なければならない。まず、階層テーブルのＡＥＩＤコラムをチェックする。ＡＥＩＤが０であればオブジェクトテーブルからエリアスのポイントするオブジェクトを得て、このオブジェクトをナビゲートしなければならず、この結果得られるＥＩＤをＡＥＩＤコラムに記憶する。これに成功すればパスの残りをナビゲートできる。階層テーブルのＡＥＩＤ内にエリアスのついたオブジェクトのＥＩＤを記憶することにより、エリアスのついたオブジェクトまでのナビゲートを回避できる。特にエリアスのついたオブジェクトが階層の低レベルにある場合、これにより時間が節約できる。３．４エリアスおよびサーチサーチアーギュメント内の（サーチ−エリアス）フラグがセットされている場合、サーチ中にエリアスをデリファレンスする。エリアスをデリファレンスする間のサーチサービスの実行は２ステッププロセスとなる。まずサーチエリアを定義し、次にサーチエリア内のエントリーにフィルタを適用する。サーチサービスの一部としてデリファレンスされたエリアスはフィルタを適用したサーチエリアを拡張できる。これらエリアスはサーチエリアからデリファレンスエリアスが排除されるという点でサーチエリアも制限する。エリアスおよびワンレベルサーチエリアスがワンレベルサーチの一部としてデリファレンスされており、エリアスエントリーが発見される場合、（オブジェクトテーブルまたはＡＥＩＤを使用して）エリアスを分解しなければならない。次にフィルタを適用したサーチエリアにエリアスのついたオブジェクトを加える。エリアスを発見するワンレベルサーチでは、サーチエリアはベースオブジェクトの直接下位のエリアスのないエントリーおよびすべてのデリファレンスエリアスから成る。エリアスおよびサブツリーサーチエリアスが全サブツリーサーチの一部としてデリファレンスされており、エリアスエントリーが発見されれば（オブジェクトテーブルまたはＡＥＩＤを使用して）エリアスを分解し、このＥＩＤが既に処理されたサブツリーの一部でなければこれを別のベースオブジェクトとして処理しなければならない。サーチ中にエリアスをデリファレンスしている時はサブツリージョイン内のエリアスエントリーを探すのに「パス」コラムを使用できる。現在のサブツリーの外をポイントするエリアスエントリーが発見されれば、エントリーによりポイントされるサブツリーもエリアスに対してサーチできる。階層的ツリー構造のプロパティはユニークなベースオブジェクトによって各サブツリーがユニークに表示されるということである（すなわちサブツリーはオーバーラップしない）。サブツリーサーチを実行する際はユニークなサブツリーを定めるベースオブジェクトのリストを作成する。エリアスが発見されない場合、リストは１つのベースオブジェクトしか含まない。処理されているサブツリーの外をポイントするエリアスが発見される場合（１つ以上のベースオブジェクトがエリアスのついたオブジェクトの下位でなく、下位のベースオブジェクトはエリアスのついたオブジェクトで置換される場合）、ベースオブジェクトのリストにエリアスのついたオブジェクトを加える。従って、サーチエリアはベースオブジェクトのうちの１つのパスによりプリフィックスのついたパスを有する非エリアスエントリーから成る。４．論理的デザインＸ．５００の機能を実行するのに概念的デザイン（表４ａを参照）で充分であるが、更に性能を改善できる。データについて仮定をすることができるので、従来のリレーショナルデザインにおいて性能を改善できる。このデータは基本的にはアプリケーションを設計した時に固定される。Ｘ．５００ではどのデータタイプも知られていない。しかしながら、サービスについて仮定することができるので、性能の改善も可能である。これらサービスはＸ．５００アプリケーションを設計した時に知られているものである。図２Ｂを参照すると、（従来のリレーショナルデザインにおける主要データ関係に基づく代わりに）主要サービス関係に基づき各テーブルを編成できることを認識することが、革新的なアプローチである。上記テーブルは下記に示すように、より少数のより効率的なテーブルに分解できることが証明される。４．１サービスの分解ほとんどのＲＤＢＭＳでの現実は、多数のコラムを有する大きなテーブルはコラムのより少数の小さいテーブルと同じようには機能しないということである。この主な理由は、インデクシングのオプション、Ｉ／Ｏの実行およびテーブルマネージメントと共に行うことにある（セクション４．５および４．６参照）。このことが、従来のリレーショナルデザイン技術が主要情報を別個の表に焦点を合わせテーブルの結合（すなわち正規化および部分化技術により第２情報を引き出そうとしている理由である。Ｘ．５００の性能を得る１つの改良技術は、主要サービス関係に関する表を分解し、結合により第２サービスを引き出すことにある。このプロセスをサービスの分解と称す。次の検討を行う。（１）（不要な結合を回避するためには）強力な関係を有するコラムをまとめることが好ましい。（２）所定のコラム内の重要な行の数が他の関連するコラムと無関係の場合、その所定コラムは別のテーブルに対する候補とする。（３）あるコラムが情報（入力）を探すのに使用されるにすぎないか、または結果（出力）をリターンするのに使用されるにすぎない場合、このコラムは自己のテーブルに対する候補となる。（４）１つのキーを２つ以上のサービスに対するキーとして使用する場合、これを主要キーとし、よって自己のテーブル内に入れることが好ましい（各テーブルは１つの主要キーしか有することができない）。（５）キーをユニークとするか、または少なくとも強力（非繰り返し的）とすることが好ましい。表４．１にはコラム利用の第１レベルの分析を示した。上記情報および別の分析から、次のセクションに述べるように、概念的デザインテーブルは多数のより小さいテーブルに分解できる。４．２階層テーブルの分解階層テーブルは次のコラムを含む。階層テーブルはオブジェクトおよびそのペアレント、そのネーム、階層内の絶対的位置に関する情報を含み、それらがエリアスである場合。従って、このテーブルは４つのテーブルすなわちＤＩＴ、ＮＡＭＥ、ＴＲＥＥおよびＡＬＩＡＳに分割できる。所定のチャイルドを探したり、または所定のペアレントを有するエントリーに作用するのに、ペアレント情報を使用する。所定のチャイルド（例えばペアレント＝０、NameNorm＝「DATACRAFT」）を探すことはナビゲーションおよび更新チェック（追加またはＲｄｎ変更前のオブジェクトの存在のチェック）の基礎となる。リストサーチまたはワンレベルサーチの間には所定のペアレントを有するエントリーに対する作用が使用される。従って、ＤＩＴ（ディレクトリ情報ツリー）表はナビゲーションに必要な情報を有するが、そのＲＡＲＥＮＴコラムを他のサービスで使用できるようにする。オブジェクトはその兄弟からその相対的区分ネーム（ＲＤＮ）を介して区別される。ＲＤＮは（所定のペアレントと共に）リストに対し、またはフルの区分ネームの一部としてリターンされる（読み出し、サーチ）。従って、ＮＡＭＥテーブルはＮＡＭＥを戻すのに必要な情報（未処理のＲＤＮ）を有する。ＤＮ（これから未処理のＲＤＮが検索される）を作成し、サーチ中にサブツリーを広げるのに階層内のオブジェクトの絶対的位置が必要である。従って、ＴＲＥＥテーブルはエントリーのパス（ルート部から下方へのＥＩＤのシーケンス）に関する情報を有する。ナビゲート中にエリアスに出会うごとに、繰り返してこれを分解する必要がないように、エリアス情報はキャッシュされる。従って、ＡＬＩＡＳテーブルはＡＬＩＡＳであるエントリーしか含まない。このテーブルはサーチエリア内にエリアスがあるかどうかを判断するのに（ＤＩＴペアレントコラムと組み合わせた）ワンレベルサーチ中、および（パスコラムと組み合わせた）サブツリーサーチの間でも使用される。４．３オブジェクトテーブルの分解オブジェクトテーブルは次のコラムを含む。このオブジェクトテーブルは基本的には特定の値（例えばＡＩＤ＝surname、V alueNorm ＝「HARVEY」）を探したり、値（ＡＩＤ＝surname、ValueRaw＝「Harv ey」）を検索するための情報を含む。従ってこのテーブルは２つのテーブルＳＥＡＲＣＨおよびＥＮＴＲＹに分解できる。サーチサービス内のフィルタを分解するのにサーチテーブルが使用される。このテーブルは比較、変更およびＲＤＮ変更中に値を探すのにも使用される。このサーチテーブルは各エントリーの各属性値のための１つの行を含む。このテーブルには正規化された値しか含まれた。読み出しおよびサーチ時に値をリターンするのにエントリーテーブルが使用される。このエントリーテーブルは各エントリーのための各属性値に対し１つの行を含む。ＲＡＷ（未処理）値はエントリーを追加した時または変更した時に最初に供給された値と全く同じ値である。４．４属性テーブル属性テーブルは基本的には概念的デザインと同じである。入出力Ｘ．５００オブジェクト識別子は内部属性識別子ＡＩＤとの間で変換されるので、「type」フィールドは実際には記述的であるにすぎない。従って、このコラムは記述的フィールドであることを示すのにリネームされたＤＥＳＣとなっている。４．５インデックス選択ＲＤＢＭＳは対応するインデックスを使用して照会を満足させることができるので、ＳＱＬを使用する際の性能を得ることができる。このことは条件（ＳＱＬ内の「where」項）を有するどの照会も、関連するインデックスを有することが好ましい（またはＲＤＢＭＳはテーブルレベルのスキャンに頼らなければならない）ことを意味する。しかしながら、実際のＲＤＭＳでは次のとおりである。・インデックスの数は限られる。・二次的インデックスを維持するのにハイオーバーヘッドとなり得る。・１つの照会を満足するのに複合インデックスが必要となり得る。従って、コラム間で照会を行う場合（例えばタイプ＝surname および値＝SMITH）、タイプおよび値上の別のインデックスによってフルインデックスアクセスとならないことがある。タイプおよび値の双方での複合インデックスが必要となることがある。先のセクションにおけるテーブルを分解する改良点は、テーブル間の主要インデックスの使用を最大にすることである。これにより二次的インデックスの数が減少する（すなわち二次的インデックスは自己のテーブル上で主要インデックスとなる）。下記は論理デザインで使用される６つのテーブルの各々に対するインデックスのリストである。このテーブルデザインは結合を行うことなく多くの照会を処理できることを意味して入るので、性能がかなり改善される。必要と考えられる結合は次のようにリストされる。・リスト（所定のオブジェクト（ＮＡＭＥと結合されたＤＩＴ）の下にＲＡＷ−ＲＤＮをリターンさせるためのもの）・サーチ／サブツリー（（ベースオブジェクトがルートでない場合の）全サブツリー（ＳＥＡＲＣＨと結合したＴＲＥＥ）上のフィルタに一致するＥＩＤを探すためのもの。・サーチ／ワンレベル（ベースオブジェクト（ＳＥＡＲＣＨと結合したＤＩＴ）の下のフィルタワンレベルと一致するＥＩＤを探すためのサーチ。・サーチ／エリアス／サブツリー（サブツリー（ＡＬＩＡＳと結合したＴＲＥＥ）内のすべてのエリアスを探すためのサーチ。・サーチ／エリアス／ワンレベル（所定のオブジェクト（ＡＬＩＡＳと結合したＤＩＴ）の下のすべてのエリアスを探すためのサーチ。ここで、上記結合は第１レベルの結合（すなわち２つのテーブル間の結合）であることに留意されたい。高位の結合を使用しないことが好ましい。４．６入力／出力性能テーブルの数を増す、サービスに基づきテーブルを分解する改良点は、新しいテーブルが断片化されないテーブルよりも小さくなることである。これにより次の理由からＩ／Ｏの数を大幅に削減できる。行のサイズ行内のコラム数を減少することにより行の幅は狭くなる。このことは（１つのディスクＩ／Ｏが１ページの情報をリターンすると仮定する場合）１ページにより多数の行を挿入できることを意味している。一組の行を検索しなければならない場合、下記のクラスター化と組み合わせて１ページ、またはそれより少ない数のページをディスクから実際に読み出さなければならない（例えばオブジェクトの属性を読み出す際にＥＮＴＲＹテーブルにＥＩＤ、ＡＩＤ、ＶＩＤのキーを付ける場合、そのオブジェクトに関連する行のすべては同じページとなる）。クラスター化断片化されたテーブルの各々は、これらテーブルがデータの使用態様に従ってデータをクラスター化できるようにする自己の（独立した）主要キーを有することが好ましい。この主要キーは記憶構造を決めることがある。従って、ＳＥＡＲＣＨテーブルにおいてＡＩＤ、ＮＯＲＭ（すなわちタイプ、値）に主要キーが付けられる場合、ディスクの同じ領域に同じタイプのデータ（例えば姓名）および同様の値（例えばHarvey、Harrison）のすべてがクラスター化される。このことは、サーチ中に類似のデータ、（例えばＨＡＲで始まる姓名）が１つの（または数個の）ディスクページに集められることを意味して入る。行が小さい場合、アクセスすべきディスクページの数は大幅に少なくなる。キャッシングほとんどの業務用ＲＤＭＤＳは頻繁にアクセスするページをキャッシングする能力を有する。テーブルは効果的に入力（例えばＤＩＴテーブルを使用するナビゲーティング）または出力（例えばＥＮＴＲＹテーブルからの情報の検索）されるので、類似のリクエスト（例えばツリーの同じ部分のサーチ）が頻繁に使用されるページをキャッシングする結果を生じさせる。このことは、頻繁に行われる問い合わせにより大きな利点が得られることを意味している。行の大きさを小さくし、クラスター化した結果、ページは情報が集中したものとなるので、キャッシングはより効率的にもなる。マネージメントテーブルが小さい場合は、一般に管理、例えばビューイング、インデックスの作成、統計の収集、監査、バックアップ等が容易となる。５．論理的方法このセクションでは、図２Ｂを参照して論理的デザインテーブルに質問する方法を説明する。本セクション全体では、各Ｘ．５００方法を説明し、図で示す。表５ａはエリアスレファレンスを含む小さい階層ツリーを示す。表５ｂには対応するテーブルの内容が示されている。５．１共通サービスツリーナビゲーションすべてのＸ．５００サービスはディレクトリツリーをナビゲーションすることに依存している。ツリーナビゲーションの目的は、供給された区分ネームに対応するエントリーのＥＩＤを検索することにある。ナビゲーションはツリーのルートから開始し、ＤＮ内のＲＤＮを分解（証明）するまでツリーを下方に進むように続く。このプロセスはツリーウォークとして知られている。ＤＩＴケーブルはツリーナビゲーションに使用される主要テーブルであり、階層ツリーの例を参照すると、ＤＮすなわち「Datacraft/Sales/Network Products /Peter Evans」の分解を行うには次のプロセスを実施する。・PARENT＝０およびRDN ＝「DATACRAFT」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは１である。・PARENT＝１およびRDN ＝「SALES」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは１１である。・PARENT＝１１およびRDN ＝「NETWORK PRODUCTS」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは２０である。・PARENT＝２０およびRDN ＝「PETER EVANS」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは３２である。こうしてＤＮが分解されると、キーＥＩＤ＝３２を使用してエントリーテーブルからオブジェクトに関連する値を得ることができる。エリアスＤＮはエリアスを含むことが多く、このエリアスは効果的に別のＤＮである。ツリーウォークはエリアスが分解されるまで続けることができないので、エリアスはツリーウォーク方法を複雑にする。これによりエリアスに対しては別のツリーウォークが必要となる。例えばＤＮ「Datacraft/Network Products/Peter Eva ns」を検討する。このＤＮを分解する最初の２つの工程は次のとおりとなる。・PARENT＝０およびRDN ＝「DATACRAFT」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは１である。・PARENT＝１およびRDN ＝「NETWORK」を含む行に対し、ＤＩＴテーブルをスキャンする。この行に対するＥＩＤは１０である。この段階で、このエントリーはエリアスであることを発見する。エリアスのＥＩＤがキャッシュされたかどうかを見るようにエリアステーブルをチェックする。このエリアスを分解する試みが最初にされていればエリアステーブル内のＡＥＩＤコラムを０とする。検討のため、これが最初であると仮定する。エリアスを分解するにはエリアスのついたオブジェクトのＤＮを決定しなければならない。これはエリアスエントリーの「aliasedObjectName」属性内に記憶する。このaliasedObjectName は（ＡＴＴＲテーブルからの）ＡＩＤ＝１を有するのでＥＩＤ＝１０およびＡＩＤ＝１であるエントリーテーブル（ＲＡＷ値）からＤＮが得られる。本例では、エントリーのＤＮは「Datacraft/Network Products」である。このＤＮは通常のツリーウォーク技術を使用して完全に分解する。ＥＩＤの値は２０である。この段階で、元のＤＮ内の分解されていないＲＤＮ、すなわち「PETER EVANS 」に対しナビゲーションが続けられる。必要な最終ステップは次のとおりである。・PARENT＝２０およびRDN ＝「PETER EVANS」を含む行に対し、ＤＩＴテーブルをスキャンする。エリアスを一旦分解すれば、これをエリアステーブルに加える（キャッシュ）することができる。このテーブルはエリアスのついたオブジェクトに対するレファレンスＡＥＩＤを含む。上記の例ではＥＩＤが１０のエリアステーブル内のエントリーは２０のＡＥＩＤを有する。エリアスを一旦キャッシュすれば、エリアスを分解するのにツリーウォークは不要である。ディレクトリパスＤＩＴテーブルにオブジェクトを加える際に、ツリーテーブルと称される別のテーブルに対応する行を加える。このテーブルはオブジェクトに対するパスを識別するＥＩＤのリストを記憶する。区分ネームほとんどのサービスはサービス結果内に区分ネームを戻すことを求める。ツリーテーブルからのディレクトリパスを使用するとネームテーブル内に記憶されたＲＡＷＲＤＮ値からＤＮを組み立てることができる。エントリー情報の選択「EntryInformationSelection」（エントリー情報選択）と称されるアーギュメントと共にＸ．５００サービスの多くがリクエストされる。このＥＩＳアーギュメントはエントリー内のどの情報を戻すかを示すのに使用される。基本的にＥＩＳはオプションとして次のものとすることができる。・非情報・選択された属性またはすべての情報に対する属性および値・選択された属性またはすべての属性のみのための値エントリー情報エントリー情報は読み出しおよびサーチのための復帰パラメータである。この情報は常に選択されたエントリーの区分ネームを含み、オプションとしてリクエストのＥＩＳアーギュメントに特定されるような属性および／または値を含む。共通アーギュメントＸ．５００サービスのいずれもサービスリクエスト内の一組の共通アーギュメントをパスする。共通アーギュメントはサービス制御（時間制限およびサイズ制限）、サービスのリクエスト者のＤＮおよび安全情報のような情報を含む。共通結果Ｘ．５００サービスのいくつかはサービス応答内の一組の共通結果をパスする。共通結果は安全パラメータ、サービスの実行者のＤＮおよびエリアスデリファレンスフラグ等のような情報を含む。５．２読み出しサービス読み出し操作は明瞭に識別されたエントリーから情報を抽出するのに使用される。Ｘ．５００の定義方法：・ＤＩＴテーブルを使用してツリーウォークを実行し、必要であればエリアスを分解する。ベースＥＩＤを得る。・ツリーテーブルからＰＡＴＨおよびネームテーブルからのＲＡＷＲＤＮを使用してＤＮを作成。・ＥＩＳが属性または値を特定しない場合、ＤＮを戻す。・ＥＩＳがＡＬＬタイプおよび値を特定する場合、一致ＥＩＤのためのエントリーテーブルからＲＡＷ値を戻す。・ＥＩＳが選択されたタイプおよび値を特定すれば、属性テーブルからＡＩＤを得て一致ＥＩＤに対する選択されたタイプおよび／または値を戻す。例：エントリー「Datacraft/Sales/Network Products/Peter Evans」を読み出す。ＥＩＳを属性Types ＝allAttributes、InfoTypes ＝attributeTypesAndValuesにセットする。ＤＩＴテーブルを使用し、正規化されたＲＤＮの DATACRAFT、SALES、NETWORK PRODUCTS、PETER EVANS に対するＥＩＤの位置１、１１、２０および３２を横断するツリーウォークを実行する。選択されたオブジェクトのＥＩＤは３２である。ＥＩＤ＝３２に対するツリーテーブルからＰＡＴＨを抽出する。このＰＡＴＨは１．１１．２０．３２である。ＥＩＤ１、１１、２０、３２に対するネームテーブル内のＲＡＷ値からＤＮを作成する。各一致ＥＩＤに対しエントリーテーブルおよび属性テーブルを使用し、・属性テーブルからOBJECTIDおよびエントリーテーブルからＡＳＮ．１エンコードされたＲＡＷ値を戻す。 2.5.4.0 ［2.5.6.7］ 2.5.4.3 ［PETER］ 2.5.4.4 ［EVANS］ 2.5.4.9 ［SALESPERSON］ 2.5.4.20 ［(03)727-9454］・ＤＮを戻す。５．３比較サービス（リクエストのアーギュメントとして供給された）値と特定オブジェクトエントリー内の特定の属性タイプの値とを比較するように、比較演算が使用される。Ｘ．５００の定義方法：・ＤＩＴテーブルを使用してツリーウォークを実行し、必要であればエリアスを分解する。ベースオブジェクトのＥＩＤを得る。・属性テーブルから比較すべき属性のＡＩＤを得る。・エントリーテーブルからＥＩＤとＡＩＤが一致する行を選択する。・値を比較する。・ＴＲＵＥまたはＦＡＬＳＥを比較の結果として戻す。・エリアスがデリファレンスされていれば、ツリーテーブルからのパスおよびネームテーブルからのＲＡＷＲＤＮを使用して選択されたオブジェクトのＤＮを戻す。例：「Datacraft/Sales/Network Products/Peter Evans」と「肩書＝[Salesperson ]」の当該属性値確認とを比較する。ツリーウォークを使用して所定のＤＮに対するＥＩＤを得る。選択されたオブジェクトのＥＩＤは３２である。属性テーブルを使用し、肩書に対するＡＩＤすなわちＡＩＤ＝１２を得る。サーチテーブルを使用し、ＥＩＤ＝３２およびＡＩＤ＝１２を有する行を探し、「NORM＝SALESPERSON」のテストをする。このテストの結果に応じてＴＲＵＥまたはＦＡＬＳＥをリターンする。この場合、結果ＴＲＵＥとなる。エリアスはデリファレンスされていないので、エントリーのＤＮはリターンしない。５．４リストサービスリスト演算を用いて明瞭に識別されたエントリーの中間下位のリストを得る。Ｘ．５００の定義方法：・ＤＩＴテーブルを使用してツリーウォークを実行し、必要であればエリアスを分解する。ベースオブジェクトのＥＩＤを得る。・ＤＩＴおよびネームテーブルを使用し、ＡＬＩＡＳフラグをリターンする。ＲＡＷＲＤＮＰＡＲＥＮＴはベースオブジェクトのＥＩＤに等しい。例：ＤＩＴ「Datacraft」に対するリストを実行する。ツリーウォークを使用してＤＮに対するＥＩＤを得る。選択されたオブジェクトのＥＩＤは「１」となる。ＰＡＲＥＮＴ＝１を備えた各ＥＩＤに対し、・ネームテーブルからＲＡＷＲＤＮすなわち[Networks]、[Sales]、[Mark eting]をリターンし、・エリアスフラグすなわちＴＲＵＥ、ＦＡＬＳＥ、ＦＡＬＳＥをリターンする。ツリーウォーク内でエリアスがデリファレンスされない時は、選択されたオブジェクトのＤＮをリターンしない。エリアスエントリー[Networds]がデリファレンスされていないことにも留意されたい。５．５サーチサービスサーチサービスはすべてのＸ．５００サービスのうちで最も複雑なものである。サーチアーギュメントはサーチのスタート場所（ベースオブジェクト）、サーチの範囲（サブセット）、適用条件（フィルタ）およびどんな情報をリターンするか（選択）を示している。更に、エリアスをデリファレンスするかどうかを表示するようフラグがパスされる（サーチエリアス）。サブセットのための可能な値はベースオブジェクト、ワンレベルおよび全サブツリーである。ベースオブジェクトはベースオブジェクト内の属性および値にサーチフィルタが使用されるにすぎないことを表示する。ワンレベルはベースオブジェクトの中間下位にサーチフィルタが使用されることを表示し、全サブツリーはベースオブジェクトおよびその下位のすべてにサーチフィルタが使用されることを表示する。フィルタ条件の簡単な例としては、姓＝「EVANS」または電話番号PRESENT が挙げられる。Ｘ．５００の定義各サーチ範囲のためのサーチ方法は次のようなアウトラインとなる。ベースオブジェクト：・ＤＩＴテーブルを使用し、ツリーウォークを実行し、必要であればエリアスを分解する。ベースオブジェクトのＥＩＤを得る。・選択されたオブジェクトのＥＩＤを備えたサーチテーブル内の属性および値に対しフィルタを使用する。・フィルタ条件が一致すればエントリーテーブルからエントリー情報をリターンする。・エリアスがデリファレンスされればツリーテーブルを使用してＤＮをリターンし、ＰＡＴＨおよびネームテーブルを抽出し、ＤＮを作成する。ワンレベル：・ＤＩＴテーブルを使用し、ツリーウォークを実行し、必要であればエリアスを分解する。ベースオブジェクトのＥＩＤを得る。・ＰＡＲＥＮＴ＝ＥＩＤと共にエリアスが存在するかどうかを見るようにチェックし、存在していればエリアスを分解し、エリアスデリファレンスリストを得る。・サーチおよびＤＩＴテーブルを使用し、フィルタ（属性／値条件）および範囲（選択されたオブジェクトおよびデリファレンスされたエリアスのＰＡＲＥＮＴ＝ＥＩＤ）を使用する。一致ＥＩＤのリストをリターンする。・エリアスがデリファレンスされていれば、ツリーテーブルを使用し、ＤＮをリターンし、ＰＡＴＨおよびネームテーブルを抽出し、ＤＮを作成する。各一致ＥＩＤに対し、・（読み出しサービスごとに）エントリーテーブルを使用してサーチテーブルから得たエントリー情報をリターンする。全サブツリー：・ＤＩＴテーブルを使用し、ツリーウォークを実行し、必要であればエリアスを分解する。ベースオブジェクトのＥＩＤを得る。・選択されたオブジェクトのＰＡＴＨと一致するＰＡＴＨプリフィックスと共にエリアスが存在するかどうかを見るようにチェックする。・発見された各エリアスに対しエリアスが現在のサブツリーの外にポイントしているかどうかをチェックし、そうであればこれまでのステップを繰り返す。一旦すべてのエリアスを分解すれば一組のユニークなベースオブジェクトが（エリアの重なりなしに）発見されることとなる。・サーチおよびツリーテーブルを使用し、フィルタ（属性／値条件）および範囲（選択されたオブジェクトのRATH LIKE PATHプリフィックス）を各ユニークなベースオブジェクトに対し使用する。一致ＥＩＤのリストをリターンする。・ナビゲーション中（サーチ中でない）にエリアスがデリファレンスされていれば、ツリーテーブルを使用し、ＤＮをリターンし、ＰＡＴＨおよびネームテーブルを抽出し、ＤＮを作成する。各一致ＥＩＤに対し、・（読み出しサービスごとに）エントリーテーブルを使用してサーチテーブルから得たエントリー情報をリターンする。例：下記により、ベースオブジェクト「Datacraft/Sales」に対するサーチを実行する。・全サブツリーにセットされた範囲。「姓、サブストリングイニシャル＝Ｍ」のフィルタ（Ｍで始まるすべての姓を探す）。・ＴＲＵＥにセットされたサーチエリアス。・属性Types ＝allAttributes、InfoTypes ＝attributeTypesAndValues にセットされたＥＩＳ。方法：ツリーウォークを使用してベースオブジェクトＤＮに対するＥＩＤを得る。このベースオブジェクトのＥＩＤは１１である。ツリーテーブルからＥＩＤ＝１１すなわち１．１１に対するＰＡＴＨを得る。１．１１で始まるパスを有するエントリー間でエリアスをチェックする。この場合、エリアスは存在しない。属性テーブル内の属性「姓」に対するＡＩＤ、すなわち４を得る。フィルタおよび範囲を同時に適用する。すなわちサーチテーブルを使用してＡＩＤ＝４であるターゲットリストからＥＩＤのリストを得る。値はＰＡＴＨがＬＩＫＥ１．１１．％であるツリーテーブルと結合したＭから始まる。一致するＥＩＤは３０および３１である。各一致するＥＩＤに対しエントリーテーブルおよび属性テーブルを使用し、・属性テーブルからOBJECTIDおよびエントリーテーブルからのＡＳＮ．１エンコードされたＲＡＷ値をリターンする。すなわち、 2.5.4.0, [2.5.6.7], 2.5.4.3, [Chris], 2.5.4.4 [Masters] 2.5.4.9 [Sales Manager] 2.5.4.20 [(03)727-9456] 2.5.4.20 [(018)-042 671] 2.5.4.0 [2.5.6.7] 2.5.4.3 [Alana] 2.5.4.4 [Morgan] 2.5.4.9 [Sales Support] 2.5.4.20 [(03)727-9454] ５．６エントリーサービスの追加 AddEntry（エントリー追加）操作は、リーフエントリー（オブジェクトエントリーまたはエリアスエントリー）をディレクトリ情報ツリーに追加するのに使用される。Ｘ．５００の定義方法：・ＤＩＴテーブルを使用して追加すべきエントリーのペアレント（ペアレントＥＩＤ）へツリーウォークする。・ＤＩＴテーブルを使用し、エントリーが存在しているかどうかチェックする（ＲＤＮ＝新しいＲＤＮおよびペアレント＝ペアレントＥＩＤをチェックする）。・エントリーがなければ新しいＥＩＤを割り当て、エントリーを加える。・ＤＩＴテーブル、ネームテーブル、ツリーテーブル、サーチテーブル、エントリーテーブルおよびエリアスエントリーである場合にはエリアステーブルに挿入する。例：「Datacraft/Marketing」を有するオブジェクトの下に次の属性および値を有するオブジェクトを追加する。姓［Delahunty］共通ネーム［Mary］肩書［Marketing Manager］電話番号［(03)727-9523］ツリーウォークを使用してベースオブジェクトＤＮに対するＥＩＤを得る。ベースオブジェクトのＥＩＤは１２である。ＤＩＴテーブルを使用し、重複エントリーすなわちＰＡＲＥＮＴ＝１２およびＲＤＮ＝「Mary Delahunty」を探す。重複はない。次のテーブルに次の行を加える。５．７エントリー削除サービスエントリー削除操作はディレクトリ情報ツリーからリーフエントリー（オブジェクトエントリーまたはエリアスエントリー）を削除するのに使用される。Ｘ．５００の定義方法：・ＤＩＴテーブルを使用してツリーウォークを実行する。ベースオブジェクトのＥＩＤを得る。・エントリーが存在し、そのエントリーがリーフエントリーである場合には、選択されたオブジェクトの条件ＥＩＤ＝ＥＩＤに対しＤＩＴテーブル、ネームテーブル、ツリーテーブル、サーチテーブル、エントリーテーブル、エリアスエントリーである場合にはエリアステーブルから削除する。例：「Datacraft/Marketing/Mary Delahunty」を備えたオブジェクトを削除する。方法：ツリーウォークを使用してベースオブジェクトＤＮに対するＥＩＤを得る。ベースオブジェクトのＥＩＤは１２である。ＰＡＲＥＮＴ＝２１を有するエントリーがないことをチェックする。ＥＩＤ＝２１の場合、ＤＩＴテーブル、ネームテーブル、ツリーテーブル、サーチテーブルおよびエントリーテーブル（エントリー追加例と称す）に追加されたすべての行を削除する。５．８エントリー変更サービスエントリー変更操作は単一のエントリーに対し次の１つ以上の一連の変更を実行するのに使用される。・新しい属性の追加・属性の削除・属性値の追加・属性値の削除・属性値の交換・エリアスの変更Ｘ．５００の定義方法：・ＤＩＴテーブルを使用してツリーウォークを実行する。選択されたオブジェクトのＥＩＤを得る。選択されたオブジェクトに対し次の１つ以上のアクションを実行する。値の追加、値の削除、属性の追加、属性の削除。各アクションに必要な操作は次のとおりである。値の追加：・属性が存在している場合にはエントリーテーブルおよびサーチテーブルに値を追加する。チェックは、現在の値に対し属性が単一の値であるかチェックすること、二重の値に対しては属性が多値であるかチェックすることである。値の削除：・エントリーテーブルおよびサーチテーブルに対し、値が存在している場合にはこれを削除する。区分値は削除できない。属性の追加：・属性が存在していない場合はエントリーテーブルおよびサーチテーブルに属性値を追加する。属性の削除：・エントリーテーブルおよびサーチテーブルに対し属性が存在している場合にはこれを削除する。ＡＩＤ＝属性およびＥＩＤ＝ベースオブジェクトを備えたすべての値を削除する。ネーミング属性は削除できない。例：次のように変えることによりエントリー「Datacraft/Sales/Network Products /Chris Masters」を変更する。属性および値を削除電話番号 018-042 671 属性および値を変更肩書 Sales Assistant サーチテーブルおよびエントリーテーブルはこれら変更を示す。５．９ＲＤＮ変更サービスＲＤＮ変更操作はディレクトリ情報ツリーからリーフエントリー（オブジェクトエントリーまたはエリアスエントリー）の相対的区分ネームを変更するのに使用される。方法：・ＤＩＴテーブルを使用してツリーウォークを実行する。ベースオブジェクトのＥＩＤおよびペアレントＥＩＤを得る・ＤＩＴテーブルを使用し、等しいエントリーをチェックし、１つ発見された場合にはエラーをリターンする。等しいエントリーはＲＤＮ＝新ＲＤＮおよびＰＡＲＥＮＴ＝ペアレントＥＩＤを有する。・ネームテーブルを使用し、旧ＲＤＮを新ＲＤＮに置換する。・ＤＩＴテーブルを使用し、旧ＲＤＮを新ＲＤＮに置換する。・エントリーテーブルを使用し、新しい値を挿入する。・サーチテーブルを使用し、値＝旧ＲＤＮを探し、ＤＩＳＴＩＮＧを０にセットする。新しい値を挿入する。 deleteOldRDNをＴＲＵＥにセットした場合、ツリーウォーク後の手順は次のとおりとなる。・ＤＩＴテーブルを使用し、同じネームおよびベースＥＩＤに等しくないＥＩＤを有する兄弟をチェックする。・ネームテーブルを使用し、旧ＲＤＮを新ＲＤＮに置換する。・ＤＩＴテーブルを使用し、旧ＲＤＮを新ＲＤＮに置換する。・エントリーテーブルを使用し、旧い値を削除し、新しい値を挿入する。・サーチテーブルを使用し、旧い値を削除し、新しい値を挿入する。例：「Datacraft/Sales/Network Products/Chris Masters」のＲＤＮを変更する。新ＲＤＮは Christine Mastersである。 deleteOldRDNをＦＡＬＳＥにセットする。テーブルの変更は次のとおりとなる。５．１０複雑化何らかのサービスを処理している間にエラー、制限または放棄が生じる場合、処理を中断し、適当なエラーメッセージをリターンする。エラー：各Ｘ．５００サービスは３つの部分、すなわちARGUMENT、RESULTおよびERRORS から成る、上記サービスの説明ではＸ．５００の定義にARGUMENTおよびRESULTが含まれていた。しかしながらエラー条件は種々変わっているので、本明細書ではこれら条件を説明しない。規格および技術の国立研究所（ＮＩＳＴ）の文献である「オープンシステムズの相互接続プロトコルのための安定実施協約：第３版」は、Ｘ．５００規格のためのフルカバーのエラーについて述べている。時間制限およびサイズ制限：時間制限およびサイズ制限はサービスコントロールの一部を形成する。これら制限はオプションとして、ある一定の制限にセットでき、共通アーギュメントに含めることができる。時間制限は最大経過時間（単位：秒）として示し、この時間内にサービスを提供しなければならない。リストおよびサーチに対し適用できるにすぎないサイズ制限はリターンすべきオブジェクトの最大数を示す。いずれかの制限に達すると、エラーが報告される。リストまたはサーチ上で到達する制限に対し、その結果は累積した結果を任意に選択することとなる。放棄：ユーザーが結果に関心がなくなった場合、ディレクトリに質問するオペレーション、すなわち読み出し、比較、リストおよびサーチを放棄操作を使用することによって放棄できる。エリアスおよびサーチ：サーチ中にエリアスに出会い、そのエリアスがディレクトリツリーの別のブランチをポイントしていう場合、エリアスのデリファレンスは次のことを要求する。・ルートエントリーから参照エントリーへナビゲーションすること。・参照エントリーに対し下位のアイテム全てをサーチすること。表５．１０に示される例において、「Telco/Corporate/Data Services」のベースオブジェクトで全サブツリーサーチを実行する場合、エントリー「Mervyn P urvis」およびエリアス「Strategic」がサーチされる。しかしながらStrategic はエントリー「Strategic」およびその下位の全て、すなわち「Alan Bond」、「 Rex Hunt」、「Wayne Carey」および「John Longmire」のサーチを必要とするツリーの異なるブランチをポイントしている。５．１１実施の最適化論理的方法は、性能を高める多数の最適化方法を含む。これら方法のアウトラィンを次に説明する。キャッシング：属性テーブルはキャッシングできる。このことは（属性の初期ローディングとは別に）属性をデコードしたり、またはエンコードする際にデータベースへＳＱＬステートメントを発行する必要はない。本Ｘ．５００システムでは、メモリで属性変換を実行する。これにより速度上のかなりの利点が得られる。有効化：照会の有効化は可能である場合メモリで実行される。これにより時間とシステムを費やすデータベースのロールバックが解消される。例えばエントリーを追加する際にこのエントリーを追加使用とする試みの前に、各属性が有効化される。エラーが発見されればＳＱＬのコールを発行する必要はない。照会処理の最適化：ほとんどのサービスのフォーマットは既知となっているので、静的ＳＱＬステートメントを使用してこのサービスの多くのインスタンスを分解できる。複雑なフィルタを有するサーチのような、より複雑なサービスは、ダイナミックＳＱＬを使用して分解できる。これにより任意の複雑なサーチが実行可能となる。パラレル照会：サーチ結果を処理する際にも本システムは一括行処理を回避するためＳＱＬのセット配列照会を利用する。従って、サーチ結果はメモリ内でパラレルに組み立てることができる。データ記憶装置：未処理データを記憶するテーブルはＡＳＮ．１フォーマットでデータを記憶する。これによりデータベース内外へのデータの有効な転送手段が得られる。データベース技術：照会を分解するのにかかる時間を短縮する機構を提供する照会オプティマイザーを使用することにより、複雑なサービスを更に改善できる。リレーショナルデータベースを使用することによって更にメモリを効率的に使用できるし、多量のメモリを必要とすることなく大きなデータベースを構築できる。Ｘ．５００以外の多くのアプリケーションは性能を得るのにメモリ内で全データベースをキャッシュしている。このような方法は多量のメモリを使用するものであり、スケーラビリティ（伸縮自在性）がない。６．物理的デザイン論理的デザインの物理的変換と称されるプロセスから物理的デザインが得られる。この物理的デザインは論理的デザインの好ましい実施例を示す。図２Ｂおよび下記の表は、ある種の物理的デザインを示す。新しいコラムおよび表には太線でハイライト化されている。上記変更の理由は後述する。６．１効率ＩＮＦＯテーブル：このテーブルはデータベースで使用された最も大きなＥＩＤの値をホールドする。ＩＮＦＯテーブルを含むことによりデータベースで実行される最大ＥＩＤの計算をすることなく、次のＥＩＤを得ることが可能となっている。これによりデータベースへエントリーを加える効率が改善される。最も重要なことは、ＩＮＦＯテーブルを含むことにより多数のＤＳＡが同時にエントリーを追加する際に生じ得る競合の問題が解消されることである。シャドーキー：３つのテーブルはこれまでシャドーキーを追加していた。これらキーとしては、ａ）ＳＥＡＲＣＨテーブルにおけるＮＯＲＭキーコラムｂ）ＤＩＴテーブルにおけるＲＤＮキーコラムｃ）ＴＲＥＥテーブルにおけるＬＥＶ１、ＬＥＶ２、ＬＥＶ３およびＬＥＶ４コラムがある。これらシャドーキーコラムの各々は、より大きなコラムを短くした変形例である。これらキーコラムは各テーブルにおけるインデックスを短縮するために追加されていたものである。これによりインデックスを使用する照会に対する性能が改善され、更に小さいインデックスのほうが大きいインデックスよりもスペースをあまり占めないので、ディスクスペースの利用率も改善される。ＰＡＴＨテーブルにおけるシャドーキーはＰＡＴＨの構造的な性質を利用している。複合キーとすることによりＬＩＫＥ演算子の変わりにＳＱＬ内で正確なマッチングを使用できる。例えば、 WHERE PATH LIKE ’１．１０％’の代わりにWHERE LEV1＝１およびLEV2＝１０....である。ＬＥＶコラムの各々が自分のインデックスを有する場合、サブツリーサーチはベースオブジェクトを使用するだけでよい。すなわち、ＬＥＶ２＝１０である。エントリー１０の下のすべのオブジェクトはＬＥＶ２＝１０を有するからである。ＳＥＮＴＲＹテーブル：属性値のいくつかのタイプは、正規化する必要はない。例えば整数にしたり、ブール値としたり、日付とする必要はない。これらを２回記憶する代わりに(SEA RVH.NORM およびENTRY.RAW)、ＳＥＮＴＲＹテーブルと称されるハイブリッドでは１回で記憶できる。これにより２つのテーブルをサーチし、２つのテーブルから検索するコストの代わりにテーブルサイズを小さくし、記憶効率を増加できる。ＯＣＬＡＳＳテーブル：ほとんどの属性は値が広範に変わる。例えば姓はＡＡＬＤＥＲＳからＺＹＬＡまでの範囲となり、その間の値は大きく異なる。しかしながらオブジェクトクラス（その値は ObjectIdentifiersすなわちＯＩＤである）は、極めて少数の値を有する。すなわち例えば１万人の組織ではディレクトリ内のオブジェクトクラスは組織に対しorganisationalUnitおよびorganisationalPerson（その多くは後者となり得る）となり得る。ＯＣＬＡＳＳテーブルはＯＣＩＤと称されるオブジェクトクラスに対し数値デスクリプタを与える。このＯＣＩＤはＳＥＮＴＲＹテーブルに記憶でき、オブジェクトクラスをサーチまたは検索する時はマッピングが行われる。その他のＬＩＳＴコラムは標準的オブジェクトクラスのコンフィギュレーション情報を記憶する。すなわち属性および敬称されたスーパークラスを含むことができる。６．２ポータビリティＢＬＯＢテーブル：これまでこのテーブルは「二進の大きいオブジェクト」をホールドするのに含まれていた。ＥＮＴＲＹテーブル内の１つの行のエントリーの最大サイズはＲＡＷフィールドの長さによって制限されている。このことはエントリーをフラグメント状にしなければならないことを意味している。フラグメント状にされたエントリーは２つ以上の行を占めるので、特定の行に記憶されているエントリーのフラグメントを表示するのにＶＦＲＡＧフィールドを使用しなければならない。極めて大きな値を記憶するのに２つのオプションがある。ａ）エントリーテーブルへフラグメントフラグを加え、多数のライン上のフラグメントにエントリーを記憶するか、ｂ）エントリーを記憶するようＢＬＯＢテーブルを加え、ＥＮＴＲＹテーブルにＢＬＯＢフラグを加え、ＢＬＯＢにその値が記憶されたことを表示する。第２オプションは多数の利点を有する。第１に、ＢＬＯＢテーブルを含むことによりＥＮＴＲＹテーブルが過度に大きくなるのが防止される。ほとんどのエントリーの長さは数百キャラクターよりも短いので、ＥＮＴＲＹテーブル内のＲＡＷフィールドの長さはそのエントリーの満たすように短縮でき、最大記録サイズに近い値までＢＬＯＢテーブル内のＲＡＷフィールドを増加できる。これにより記憶がより効率的となる。すなわち各テーブルの各コラム内の使用されていないバイトの数が少なくなり、ＢＬＯＢテーブル内の各エントリーに必要なフラグメント数が少なくなる。このことは、各値はＥＮＴＲＹテーブル内に１つのエントリーしか有しないこと、およびＥＮＴＲＹテーブルおよびＳＥＡＲＣＨテーブルが１対１の相関性を維持することを意味する。第２に、ＢＬＯＢテーブルを使用することによりアプリケーションは二進の大きいオブジェクト（例えば６４Ｋの二進コラム）に対するデータベースのサポートを活用できるようになっている。６．３機能的拡張性ＦＬＡＧＳコラム：ＦＬＡＧＳコラムは追加することが好ましい。これらコラムはデザインに拡張性を与えるために加えられていた。新しい機能が必要な場合にはテーブル構造を変えることなくフラグに特定の値を加えることができる。注：ａ）ＳＥＡＲＣＨテーブルではＦＬＡＧＳフィールドにＤＩＳＴＩＮＧフィールドを吸収してもよい。ｂ）ＤＩＴテーブルではＦＬＡＧＳフィールドにＡＬＩＡＳフィールドを吸収してもよい。ＦＬＡＧＳコラムはテーブルの各々に対するサマリー機能を提供することもできる。このことはＦＬＡＧＳフィールドの値をチェックすることによりエントリーの性質をある程度決定できることを意味している。例えばエントリーがリーフである時にはＤＩＴテーブルにフラグをセットできる。ＥＮＴＲＹのチルドレンをチェックすることよりも、このＦＬＡＧＳをチェックすることのほうがより簡単である。７．実現例次にはシステムの性能および能力の一例を示す。本発明は次の開示内容のみに限定されるものでないと理解すべきである。７．１システム全体の利点本発明は従来の実現例よりも改善された性能を提供すると考えられる。性能は下記の方法を含む多くの方法で評価できる。エリアス；サイズ（リレーショナル理論の利用）；複雑性（照会オプティマイザーおよびサーチ方法の利用）；拡張性（メタデータの使用）；および実質的に効率（ディスクをベースとするモデルの使用）および信頼性（ＲＤＢＭＳの使用）を実質的に低下することがない。本発明は上記すべての分野において性能を改善できるという点でユニークであると考えられる。７．２テストの結果下記を目標として本発明の性能のテストを実行した。・ＳＱＬをベースとするＸ．５００アプリケーションが秒以下の速度で作動できることを証明し、Ｘ．５００ＤＳＡアプリケーションを統合ＲＤＢＭＳアプリケーションとして実現し、効率と性能を得ることは不可能であるという、市場において広く信じられている神話をなくすこと。・ＳＱＬをベースとするＸ．５００アプリケーションのデザインが代表的な現在のデザインの限界である１００Ｋのエントリーを越える、特にデータベース用の現行のメモリ常駐スタイルのＸ．５００デザインを凌ぐことができることを証明すること。・広範な種々のサービスおよびデータベースのサイズが要求される際に、上記性能を実証できる構造的組のテストを証明すること。これらテストの結果は次の表７Ａに示されている。７．３テストの結論階層の深さおよび幅が異なる１Ｋ〜２００Ｋのエントリーにおよぶ一組のディレクトリを構築し、対応するテストプランを採用した。一貫性を保証するように多数回テストを実行した。これら結果から次の結論を出すことができる。１．テストにおけるナビゲーションの効果は無視できるものであった。２．テストにおけるエリアスを介したオブジェクトの読み出しは性能上の大きな低下は示さなかった。あるケースにおいて、エリアスを介したオブジェクトの読み出しは実際にオブジェクトを直接読み出すことよりも高速であった。これはエリアスがエリアスエントリーよりもツリー構造内の低い位置にあるオブジェクトを下方にポイントしている時に、必要とされるナビゲーションが少なくなることに起因するものである。３．サーチ結果は正確かつ初期のストリングサーチの双方に対して異なる大きさのディレクトリ内の異なるサイズのサブツリーに対してフラットであった。４．サーチされるエントリーの数のほうが多くても、テストにおける初期サーチおよび正確なフルツリーサーチはそれぞれのサブツリーサーチよりも若干速かった。これはフルツリーサーチはより効率的なＳＱＬを使用できる（テーブルの結合は不要である）ことに起因するものである。５．テストにおけるすべてのサービスは多量のデータをリターンするサーチを除き１秒内で実行できた。しかしながら、エントリー当たりの検索の平均時間は検索されるエントリーの数が増加するにつれて低下した（例えば１０のエントリーに対してはエントリー当たりの検索時間は約５０ミリ秒であり、１００のエントリーではエントリー当たりの検索時間は約２０ミリ秒まで低下した）。６．テストにおけるすべての複雑なサーチは１秒内で実行された。しかしながら、同じように実行できない（ＮＯＴの組み合わせを含むような）不明瞭なサーチも存在し得る。このシステムは（メモリをベースとするシステムでなく）ディスクをベースとするシステムであるので、性能は基本的には実際にリターンすべきエントリー数のみによって決まる。このシステムはサーチの複雑さ、階層の深さ、エントリーごとの属性の数、または照会中に使用される属性のタイプとは比較的無関係である。システムの生きた状態のアプリケーションではキャッシングパラメータをチューニングし、属性の多様性をより広くすることにより達成されるテスト結果を改善することも可能である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．リレーショナルデータベースに対してＸ．５００を実施するようになっている装置。２．リレーショナルデータベースがＳＱＬを使用するＲＤＢＭＳである、請求項１記載の装置。３．Ｘ．５００を実施し、メタデータを使用するデータベースアプリケーション。４．プロパティテーブルによってメタデータが提供される、請求項３記載のデータベースアプリケーション。５．メタデータがデータタイプから比較的独立している、請求項３記載のデータベースアプリケーション。６．メタデータが言語のアルファベットから比較的独立している、請求項３記載のデータベースアプリケーション。７．メタデータが正規化される、請求項３記載のデータベースアプリケーション。８．属性、オブジェクトおよび階層テーブルを含むリレーショナルデータベース。９．１つ以上のデータベース照会にリクエストをマッピングする変換手段と、ＲＤＢＭＳを使用して１つ以上の照会を評価するための評価手段とを含む、データベースアプリケーションによりＸ．５００サービスリクエストを実行するようになっている装置。 10．フィルタおよび範囲を適用する工程を含む、データベースにおけるエリアをサーチする方法。 11．一組のサーチエリアが見つかるまでエリアスを分解することによりサーチエリアを拡張する工程と、サーチエリアの組にフィルタおよび範囲を適用する工程とを含む、エリアスを備えたデータベース内でエリアをサーチする方法。 12．データベースがＸ．５００を利用する、請求項１０または１１記載の方法。 13．１回の分解でフィルタおよび範囲を評価する工程を実行する、請求項１０、１１または１２記載の方法。 14．固定された組の照会／サービスを使用して任意データを処理することを含む、リレーショナルデータベースに対しＸ．５００を実施する方法。 15．データベースがＳＱＬを備えたリレーショナルデータベースである、請求項１４記載の方法。 16．データベースが２５００００またはそれ以上のエントリーを有する、請求項１５記載の方法。 17．プロパティテーブルに対し機能的分解を実施する工程を含む、リレーショナルデータベースでＸ．５００を実施する方法。 18．サービス分解工程を更に含む、請求項１７記載の方法。 19．物理的変換工程を更に含む、請求項１８記載の方法。 20．メタデータを正規化する工程と、データベースに正規化されたメタデータを記憶する工程を含む、データベースのサーチを促進するようデータベースにメタデータを記憶する方法。 21．正規化されたメタデータをインデクシングする工程を更に含む、請求項２０記載の方法。 22．本明細書に開示したような方法。 23．本明細書に開示したような装置またはデバイス。 24．請求項１〜２３のいずれかの装置および／または方法を含むデバイスまたはシステム。