(57)【特許請求の範囲】
【請求項１】
分散コンピューティング環境においてデータストアに格納されたオブジェクトのオブジェクト間関係をコンピュータによって表現する方法であって、
第１のコンピュータが、データストアから属性を有する複数のオブジェクトに対応するデータを受け取ったことに応答して、
前記オブジェクトに対応する仮想オブジェクトを前記属性の値に基づき予め規定されたオブジェクト間関係で階層化するステップと、
前記階層化された仮想オブジェクトの属性の相対属性値分布に基づき判定を行い、前記仮想オブジェクトの属性に論理ドメインプロパティを設定するステップであって、前記オブジェクトが一意の値をとると判定した場合、対応する前記仮想オブジェクトの前記属性に一意ドメインプロパティを設定し、前記属性の値が同一である前記オブジェクトが取り得る値の数が所定の閾値より多い場合、対応する前記仮想オブジェクトの前記属性に位置決めドメインプロパティを設定し、前記属性の値が同一である前記オブジェクトが取り得る値の数が前記閾値以下の場合、対応する前記仮想オブジェクトの前記属性に分類ドメインプロパティを設定するステップと、
前記属性に前記論理ドメインプロパティが設定された前記階層化された仮想オブジェクトからなるデータポリアーキを生成し、該データポリアーキを前記コンピュータのメモリに記憶するステップと、
前記データポリアーキに含まれる前記論理ドメインプロパティの少なくとも一部を含む、少なくとも１つのスキーマを生成するステップと、
第２のコンピュータが、前記第１のコンピュータから前記スキーマを受信し、該スキーマに基づき要求を作成して前記第１のコンピュータに送信し、前記第１のコンピュータから前記要求に対する応答を受信するステップであって、
前記要求が特定の前記属性を指定する要求の場合には、前記指定した属性に関連するオブジェクトの階層化された仮想オブジェクトを前記応答として受信し、
前記要求が表示させる前記属性を指定する要求の場合には、前記指定した属性のみを階層化した仮想オブジェクトを前記応答として受信し、
前記要求が表示させる階層の範囲を指定する要求の場合には、前記指定した階層の範囲内の仮想オブジェクトのみを前記応答として受信する、ステップと
を備えることを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、前記データストアが、ディレクトリまたはデータベースを備えることを特徴とする方法。
【請求項３】
請求項１に記載の方法であって、前記オブジェクトが、複数の属性を有することを特徴とする方法。
【請求項４】
請求項１に記載の方法であって、複数の前記オブジェクトが、同一の前記属性を含むことを特徴とする方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本願は、参照によって本明細書に組み込まれる、２０００年１１月３０日出願の米国仮特許出願第６０／２５０３４４号の恩恵を主張する。
【０００２】
説明される内容は、オブジェクト間関係に関する。具体的には、内容は、オブジェクトの属性の値に基づくオブジェクト間関係の複数階層の動的生成に関する。
【０００３】
【従来の技術】
オブジェクトは、明示的または暗示的なオブジェクト間関係を形成するために、異なるオブジェクトに関してリンクするか、相関させるか、関連付けるか、区別するか、何らかの形でカテゴリ化することができる。たとえば、組織では、人が、通常は、組織内の他人、組織リソース（たとえばプリンタ、ファクシミリなど）、地理的位置、業務編成単位、クラブメンバシップなどとの明示的または暗示的な関係を有する。各々のオブジェクト（すなわち人、他人、リソースなど）間の明示的または暗示的な関係のそれぞれが、各々の階層データ関係を表す。
【０００４】
たとえば、１つの階層データ関係は、特定のリソース（たとえば会社構内の建物、部屋、プリンタなど）にアクセスできる、会社内の人のそれぞれによって表され、リソースが階層のルートノードであり、リソースへのアクセスを有する個人が葉である。もう１つの階層データ関係は、会社の管理構造を構成する個人によって表される。他のオブジェクト間データ関係は、特定の業務編成単位内の個人の階層、特殊なトレーニングを受けた会社内の全従業員などを表すことができる。
【０００５】
【発明が解決しようとする課題】
残念ながら、他のデータの階層内のオブジェクト間関係を表すために、ネットワーク管理者によってある程度までデータストアを構成することができるが、複雑なオブジェクト間関係（たとえば、複数の階層内の単一のオブジェクトを表すものなど）は、従来のデータストア（たとえばディレクトリ、データベースなど）のシステムおよびテクノロジを使用して簡単かつ適切には表現されない。従来のディレクトリには、周知のＸ．５００標準規格およびライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）が含まれる。
【０００６】
従来のデータストアシステムおよびデータストアテクノロジのこの限界を示すために、ディレクトリが、通常は、硬直したデータ命名スキーマおよび柔軟でないディレクトリスキーマを使用してオブジェクト間関係を表すことを検討されたい。ディレクトリ内のオブジェクトまたはノードは、ルートノードを階層の最上部とする単一の階層内で編成される。ルートノードは、名前を有する。ディレクトリ内の他のノードのそれぞれは、ルートノードに対する直接の命名関係に基づいて、各々のノードの階層内に介在するノードのそれぞれに関して、命名される。その結果、親オブジェクトが単一の動作で名前を変更される場合に、その親オブジェクトに従属するか子であるすべてのオブジェクトも、同一の単一の動作で名前を変更される。これは、オブジェクトの完全な「識別名」に、ルートノードの名前までのすべての各親オブジェクトの名が含まれるからである。
【０００７】
オブジェクトの静的な位置またはデータストア内の他の各オブジェクトに関するデータ関係をも表すのが、オブジェクトの完全な識別名である。したがって、オブジェクトの識別名は、単一の階層内のオブジェクト命名をその階層内のオブジェクト間関係と、柔軟でない形でからみ合わせる。このために、データストアのナビゲーションは、オブジェクト間関係を判定し、後に提示するために、最上部から最下部へ、すなわち、ルートオブジェクトから、親オブジェクトへ、さらにすべての従属する子オブジェクトへ、実行しなければならない。
【０００８】
従来のデータストア（たとえばディレクトリ、データベースなど）は、注意深く指定された柔軟でないオブジェクト命名方式に頼って、オブジェクト間関係を識別するので、データストアを構成する管理者は、データストアを構成する時に、オブジェクト間関係の先見的知識を必要とする。さらに、データストアの構成では、データストア内のオブジェクト間関係の正しい表現だけではなく、データストアをナビゲートするために検索エンジンが必要とするヒューリスティックも考慮しなければならない。
【０００９】
さらに困ったことに、弾力性のある（ｅｌａｓｔｉｃ）データ関係は、従来のデータストアのシステムおよび技法を使用しては、簡単に記述、表現、またはナビゲートされない。弾力性のあるデータ関係とは、関係が、任意の時点のオブジェクトを定義するデータから導出されるデータ関係である。これは、経時的に、弾力性のあるデータ関係が動的になる可能性があることを意味する。たとえば、次の、明白でなく、潜在的に弾力性のある、データ関係を検討されたい。ウェブサイトとそのウェブサイトを構成するウェブページ、顧客とその顧客が商人から購入する個性を与えられたサービス、パーソナルコンピュータ（ＰＣ）とＰＣに結合された周辺装置、都市と都市内の行政区、会社と会社の連絡先、従業員と従業員に従属する者、などである。
【００１０】
これらの明白でなく、潜在的に弾力性のあるデータ関係は、簡単には表現されない。というのは、サーフェスオブジェクトと対応するサブオブジェクトとの間の１対１対応をデータストア内で表現する必要がある時に、必ず不可逆的な設計選択を行わなければならないからである（従来の慣例は、ディレクトリ方式変更の深刻な性質に起因して、ディレクトリ方式更新を厳密に制御することである）。ネットワーク管理者は、サブオブジェクトをディレクトリスキーマ内でサーフェスオブジェクトの属性として表現することによって、特定のオブジェクトへのサブオブジェクトの「完全な組込み」を選ぶことができる。もしくは、ネットワーク管理者は、サブオブジェクトコンポーネントについてスキーマ内で別々のオブジェクトを作成し、別々のオブジェクトをサーフェスオブジェクトの下位に位置決めすることによって、各オブジェクトの「完全な区別」を選ぶことができる。
【００１１】
この不可逆的な設計選択を例示するために、特定のネットワークルータに、ルータのバックプレーンに挿入された複数のルータモジュールが含まれると想定されたい。ルータおよびルータモジュールに関する情報は、通常は、１つまたは２つの異なる形（それぞれが、エンティティおよびその各々の他のエンティティに対する関係を表現する方法に同等に不満足に依存する可能性がある）でディレクトリに保管される。設計選択の１つが、ルータおよびその対応するルータモジュールの特徴を、親オブジェクトとしてネットワークルータを表す単一の階層データ構造として表し、対応するルータモジュールの特徴を、親オブジェクトに従属する子オブジェクトとして表すことである。異なる設計選択は、ルータおよびルータの関連するルータモジュールの特徴を、複合属性を有する単一の親オブジェクトとして表すことである。この親オブジェクトは、ルータ（バックプレーン）を表し、複合属性が、ルータによってホストされる各々のルータモジュールを表す。
【００１２】
第１の設計選択を考慮すると、ルータおよびモジュールが構成される方法によっては、バックプレーン上のルータモジュールまたは基板に関する情報の縮小が、非実際的であることがわかる場合がある。これは、ルータのバックプレーンの機能性が、ルータによってホストされるネットワークルータモジュールの機能性と比較して小さい可能性があるからである。それに対して、第２の設計選択を考慮すると、バックプレーンから基板を完全に分離することが、同様に不満足である可能性がある。というのは、ルータが、一般に複数のルータモジュールを含む単一の物理的ルータボックスであるからである。
【００１３】
柔軟性のないディレクトリスキーマを用いてデータ関係を表現するための上で説明した解決策の両方が、実施に時間がかかり、反直観的である。最も単純な設計問題を解決する前に、ディレクトリの形状および命名のセマンティクスに合意しなければならない。したがって、エンティティと、対応するサブエンティティとの間の１対１対応を従来のディレクトリで表現する必要がある時には、必ず、不可逆的で柔軟でない設計選択を、ディレクトリスキーマ内で行わなければならない。
【００１４】
どの設計選択を選択する場合であっても、データストアおよび、オブジェクト間関係に関してデータストア内のオブジェクトをナビゲートし、検索し、表現するのに使用されるツールは、かなり制限されてきた。これは、データストア自体が、オブジェクトの可能な明示的および暗示的なオブジェクト間関係のすべてを表現できないからである。これは、多くのコンピュータプログラマによって、従来のディレクトリでのディレクトリスキーマの最も手におえない問題の１つと見なされる。これは、コンピュータプログラムアプリケーションが、通常は、ディレクトリプラットフォームまたはディレクトリインスタンスにまたがってポータブルでない理由とも見なされる。
【００１５】
さらに困ったことに、情報テクノロジでの最近の開発によって、ネットワーク管理者に、データの異種のデータソース（たとえばデータベース、ディレクトリなど）を単一の論理ディレクトリまたは「メタディレクトリ」に結び合わせる機会が与えられる。そのような異種のデータベースおよびディレクトリには、たとえば、企業ユーザ、有形および無形のリソース、財務情報、会社の電子メールシステム、ネットワークオペレーティングシステムなどに対応する情報が含まれる。
【００１６】
メタディレクトリによって、ネットワーク管理者に、データストアを構成し管理する従来のシステムおよび手順を使用して簡単にまたは適切に記述、表現、ナビゲート、または提示することができない、複雑でしばしば弾力性のあるオブジェクトデータ関係が提示される。データストアを構成するために、管理者（または管理者の一員）の側でかなりの労力が要求される。そのようなオブジェクト間関係（動的であるか否かを問わず）の手動の判定および実装は、人的なエラーおよび見落としの潜在性をはらんでいる。さらに、そのようなディレクトリ構成を実行するのに適当なレベルのそのような知識を有するデータベース管理者は、費用がかかる。
【００１７】
以下で説明する内容は、オブジェクト間関係の表現のこれらおよび他の問題に対処するものである。
【００１８】
【課題を解決するための手段】
本明細書で説明する構成および手順によって、データストア（たとえばディレクトリまたはデータベース）から受け取る情報からデータポリアーキ（ｄａｔａｐｏｌｙａｒｃｈｙ）が動的に生成される。データポリアーキは、オブジェクトの属性の値に基づくオブジェクト間関係の複数階層を表す。これらの複数階層は、オブジェクト命名および所定の静的階層データ構造とは独立の形で生成され、表現される。
【００１９】
【発明の実施の形態】
（概要）
以下の内容は、ディレクトリオブジェクト命名およびオブジェクト間関係が、からみ合わされ、複雑なデータ関係を表現するには非実際的である、単一の静的階層内での複雑な実世界のオブジェクトの提示という従来の概念に代わるものである。具体的に言うと、静的オブジェクト間関係の単一のディレクトリ内でオブジェクト間関係を表現するための識別名という従来の概念が、オブジェクトの属性に基づく複数次元のデータ関係（たとえば単一方向または両方向もしくはその両方の関係）での弾力性のある（非静的）オブジェクト間接続のグラフに置換される。言い換えると、データ関係によって、１つ以上のデータオブジェクトが、オブジェクト間関係の１つ以上の各々の次元またはポリアーキに参加することが確立される。１つ以上のこれらの階層が、交差することができ、オブジェクト間関係の交差する階層が作成される。
【００２０】
オブジェクト属性に基づいて動的に生成されるデータ関係の複数階層は、データポリアーキ内で表現される。具体的に言うと、データポリアーキは、各オブジェクトの各々のデータ属性またはデータ値と、ポリアーキ的データセット内の他のオブジェクトに対応する属性とのこれらの値のさまざまな相互関係とを使用して生成される。データポリアーキ内のオブジェクト間関係は、オブジェクト間関係が任意の時点のオブジェクトによって定義されるデータから導出されるので、弾力性を有することができる。オブジェクト間の関係のパターンは、データ関係の１つ以上の「次元」またはポリアーキ内でオブジェクトを提示することによって明らかになる。そのような関係は、オブジェクトを表現する仮想エンティティ間のオブジェクト間接続を使用して提示される。仮想エンティティは、関心を持たれるオブジェクトに対応し、関心を持たれるオブジェクトに関する情報をさらに得る方法に関する情報を含む、関心を持たれるオブジェクトに関する情報を含み、これを編成する。そのようなオブジェクトを、その関心を具体化する人またはコンピュータプログラムに提示することができる。
【００２１】
データストア内のオブジェクト間関係を表現する従来のシステムおよび手順と異なって、下で説明する構成および手順は、自動化されており、オブジェクト間関係を構成するためにネットワーク管理者からの手動の介入を必要としないという点で、動的である。データポリアーキを動的に生成することによって、オブジェクトデータに基づく複雑なオブジェクト間関係が、スキーマ設計者に柔軟でない設計選択を提示せずに自動的に判定される。
【００２２】
これは、ネットワーク管理者またはコンピュータプログラム（たとえば検索エンジン）が、データストアの生成、ナビゲーション、または検索のために、複雑なオブジェクト間関係の先見的知識を有する必要がないことを意味する。これは、データストア内の各オブジェクトを、各々のオブジェクトに適用されるものと同数の、多数の異なる次元を有するオブジェクト間関係から見ることができることも意味する。さらに、オブジェクトの弾力性のあるデータ関係が変化する際に、データポリアーキによって、これらの変更が自動的に検出され、反映される。
【００２３】
以下の説明では、請求項に記載の要素を組み込んだオブジェクト間関係のポリアーキを表現するディレクトリ方式に基づく構成および手順を示す。その内容は、法定要件を満足するための限定性を有する形で説明される。しかし、説明自体は、本特許の範囲を制限することを意図されていない。そうではなくて、本発明は、他の現在または将来のテクノロジと共に、本明細書に記載の要素と異なる要素または類似する要素の組み合わせを含めるために、請求される内容を他の形でも実施できることが企図されている。
【００２４】
（例示的システム）
図１に、オブジェクトの属性の値に基づいてオブジェクト間関係の複数階層を動的に生成し管理する例示的システム１００を示す。このシステムは、１つ以上の他の任意選択のデータサーバ１０６、１つ以上のデータベース１０８、および１つ以上のクライアントコンピュータ１１０にネットワーク１０４を介して機能的に結合されるデータポリアーキサーバ１０２を含む分散コンピューティング環境を表す。ネットワークへのデータポリアーキサーバの機能的結合は、１つ以上のサーバ設備（たとえば、ウェブファーム−サーバファームの外部のサーバ設備）、企業ポータル（イントラネット）、ローカルエリアネットワーク（ＬＡＮ）、同一位置に配置されたデータストア（たとえばデータベース１０８）などを介して複数の異なる形で行うことができる。
【００２５】
データポリアーキサーバ１０２には、コンピュータ実行可能命令１１６およびデータ１１８を含むメモリ１１４に機能的に結合されたプロセッサ１１２が含まれる。プロセッサは、コンピュータ実行可能命令を取り出し、実行し、そのような実行中にデータを取り出すように構成される。そのようなコンピュータ実行可能命令には、オペレーティングシステム（図示せず）と、オブジェクトの属性の値に基づいてオブジェクト間関係の複数階層を動的に生成し、管理するためのデータポリアーキ管理モジュール１２０が含まれる。これらの動的に生成されるオブジェクト間関係の複数階層は、データポリアーキとも称するポリアーキ的データセット１２２に保管される。データポリアーキ１１８を生成するために、データポリアーキ管理モジュール１２０は、１つ以上の他の任意選択のサーバ１０６またはデータベース１０８からなどの任意の数の異なるデータソースからのデータ（たとえばエクステンシブル・マークアップ言語（ＸＭＬ：Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）データ）を使用する。たとえば、サーバ１０６が、任意の数のさまざまなデータストア（データベース、ディレクトリ、メタディレクトリなど）からデータポリアーキサーバにデータ（たとえば企業ユーザのディレクトリ、リソースのディレクトリ、財政情報、企業電子メールシステムのディレクトリ、ネットワークオペレーティングシステムのディレクトリなど）を供給する。データベース１０８は、構造化データストアまたは非構造化データストアであり、これには、ＸＭＬデータベース、ハイパーテキストマークアップ言語（ＨＴＭＬ）データベース、ＳＱＬサーバデータベース、などのオブジェクト指向データベースが含まれる。
【００２６】
データポリアーキ１２２の生成および管理に応答して、管理モジュール１２０は、それぞれ、関心を持たれる要素のスキーマ（ｅｌｅｍｅｎｔｓ  ｏｆ  ｉｎｔｅｒｅｓｔ  ｓｃｈｅｍａ）１２４の要素の生成および更新を行う。関心を持たれる要素のスキーマによって、任意選択のクライアントコンピュータ１１０が、オブジェクト間関係の各々のポリアーキに関してデータポリアーキ内のオブジェクトを操作でき、表示できる方法が示される。
【００２７】
たとえば、関心を持たれる要素のスキーマ１２４によって、データポリアーキ１２２内の各オブジェクトが、各々のオブジェクトを表現する仮想エンティティ（たとえば図２の仮想オブジェクト２１０を参照されたい）を参照するアドレスとして識別される。これらの仮想エンティティは、アドレスのベクトルまたは配列としてスキーマに保管される。データポリアーキ内のオブジェクトが有することのできる属性の異なるタイプのそれぞれも、さまざまな属性タイプに対してどの種類のインデックスが使用されるかと同様に、スキーマで識別される（データインデックスによって、オブジェクトアクセスが提供される）。属性タイプのそれぞれについて、その定義と共に、それに対応するインデックスを保管することが便利である。この形で、たとえば、誰かが属性について要求する場合に、インデックスが簡単に使用可能になり、属性がとる値のすべてを、非常にすばやく判定することができる（関心を持たれる要素のスキーマは、下で、図３に関してさらに詳細に説明する）。
【００２８】
データポリアーキサーバ１０２は、任意の数のスキーマ１２４を生成することができる。生成されたスキーマのそれぞれは、他のスキーマ１２４によって表現されるオブジェクトから独立に、データポリアーキ１２２内のオブジェクトのさまざまなサブセットへのアクセスを提供することができる。たとえば、第１のスキーマ１２４をネットワーク管理者に配布して、それ以外の場合に他の従業員から保護されるか隠される、プリンタおよびアクセスリストなどのリソースおよび属性へのアクセスを提供することができる。同一の形で、人的資源について、第２のスキーマを社長に配布することができる。第２のスキーマは、社長に、ある特権従業員レコードへのアクセスを与えることができるが、第２のスキーマは、第１のスキーマを介してネットワーク管理者グループが使用可能なリソースに関して、完全に不活動にすることができる。この形で、スキーマ１２４を、組織のリソースへのアクセス制御を提供するように設計することができる。
【００２９】
データポリアーキサーバ１０２は、関心を持たれる要素のスキーマ１２４を１つ以上の任意選択のクライアント１１０に通信する。クライアントコンピュータは、関心を持たれる要素のスキーマによる記述に従ってデータポリアーキ１２２内のオブジェクト間関係を表示するグラフィカルユーザインターフェース（図示せず）をサポートする。データ関係のポリアーキ内のオブジェクトを表示する例示的な構成および手順は、本願の譲受人に譲渡され、参照によって組み込まれる、関連米国特許出願第０９／７２８９３５号明細書、表題「階層ポリアーキ可視化（Ｈｉｅｒａｒｃｈｙ  Ｐｏｌｙａｒｃｈｙ  Ｖｉｓｕａｌｉｚａｔｉｏｎ）」、２０００年１１月２９日出願に記載されている。
【００３０】
データポリアーキ１２２および関心を持たれる要素のスキーマ１２４は、データポリアーキサーバ１０２によって、メモリキャッシュ１１４に１回または複数回複製することができる。例示的なメモリキャッシュを、下で図１４に関して詳細に説明する。ポリアーキ的サーバは、対応するメモリキャッシュからのデータセットのいずれかを操作することができるので、各々のデータセットの必要な個数のコピーを設けることができる。したがって、クライアント１１０がどれほど要求していても、データポリアーキサーバはその要求を満足することができる。
【００３１】
データポリアーキ１２２および関心を持たれる要素のスキーマ１２４が、データポリアーキサーバ１０２によってメモリキャッシュ１１４内に複製される時に、サーバは、オブジェクト間関係の最も新しいまたは現行の表現を表す、信頼すべきストア（図示せず）をメモリ１１４内で維持することができる。そのような信頼すべきストアが有益であるのは、キャッシュが、まさにそれらの性質によって、必ずある程度は古く、キャッシュ内のデータが、最も最近のキャッシュ更新と同程度に「新鮮」またはタイムリーであるに過ぎないからである。これに鑑みて、データポリアーキ１２２に情報を要求するクライアントは、クライアントによって要求されるデータ信頼性またはタイムリーさのレベルを示すことができる。高度なタイムリーさが要求される場合には、サーバ１０２は、データキャッシュからではなく、信頼すべきストアからデータポリアーキにアクセスすることができる。信頼すべきキャッシュへのアクセスの速度は、その各々の実施形態（たとえば、サーバの内部でランダムアクセスメモリで実施されるか、サーバの外部でデータ記憶装置内で実施されるか）に依存する。
【００３２】
（例示的なデータポリアーキ）
図２に、データ内の属性に基づくオブジェクト間関係の複数次元を表す例示的なポリアーキデータセット１２２を示す。データとは、区別することができるものである（たとえば、ディレクトリ、データベースなどで表現された関心を持たれるオブジェクトであるすべてのものをオブジェクトとすることができる）。データセット１２２は、設計者が彼ら自身のカスタマイズされたタグを作成でき、アプリケーション間および組織間のデータの定義、伝送、検証、および解釈を可能にするようにフォーマットされる。たとえば、データフォーマットを、ＸＭＬデータフォーマットとすることができる。
【００３３】
データポリアーキ１２２には、複数の仮想オブジェクトデータフィールド２１０が含まれる。各仮想オブジェクトデータフィールドには、たとえば各々のオブジェクトに関する情報をさらに得る方法に関する情報を含む、各々のオブジェクトに関する情報が含まれ、編成される。具体的に言うと、仮想オブジェクトには、グローバル一意識別子（ＧＵＩＤ）データフィールド２１２と、特定のオブジェクトに適当である場合に、１つ以上の属性データフィールド２１４が含まれる。
【００３４】
ＧＵＩＤ２１２によって、これまたは他のデータポリアーキ１２２内のこのオブジェクトまたは他のオブジェクトに関して仮想オブジェクト（各々のオブジェクトを表す）が識別される。既に述べたように、これらのオブジェクトは、１つ以上の物理的に分散したデータストア内で表現することができ、これらのデータストアは、１つ以上のディレクトリサービスならびに１つ以上のデータポリアーキによって論理的に集中化される。属性データフィールド２１４によって、仮想オブジェクト２１０のすべてのデータ属性またはデータ値が定義される。各属性は、仮想オブジェクトの実際のインスタンスに含めることができる属性に対応する。そのような属性には、たとえば、１つ以上の述部（ｐｒｅｄｉｃａｔｅ）データフィールド２１６、複数のドメインプロパティデータフィールド２１８、および０個以上のサブオブジェクトエンティティ参照２２０が含まれる。
【００３５】
各述部データフィールド２１６は、他のオブジェクトの１つ以上の階層に関する特定のオブジェクトのアクセスまたは提示のための各々の動作を示す（各オブジェクトは、ポリアーキ的データセット１２２内の仮想オブジェクト２１０によって表される）。そのような動作には、１つ以上の別個のタイプの検索（たとえば、線形検索と再帰検索）、データ変換（たとえば、ある階層関係から別の異なる階層関係への）などが含まれる（図１３のブロック１３１８を参照されたい）。
【００３６】
オブジェクトが、サブオブジェクトエンティティ２２０を参照しないことを意味する単純オブジェクトである場合には、述部２１６動作（たとえば、検索、修正、仮想オブジェクト２１０からのものなどの構造から他のオブジェクトの階層内のオブジェクトへのデータ変換）が、関心を持たれる各々のオブジェクトに対応する。しかし、オブジェクトが、１つ以上のサブオブジェクトに対するデータ関係を有することを意味する複合オブジェクトである場合には、述部動作が、オブジェクトまたは１つ以上のサブオブジェクトの組み合わせに対応する。
【００３７】
ドメインプロパティデータフィールド２１８には、物理ドメインプロパティと論理ドメインプロパティが含まれる。物理ドメインプロパティは、データオブジェクトのインデクシングに使用される１組または複数の組の値を示す。物理ドメインプロパティは、データタイプ、データ精度表示、スケール表示、およびヌル可能性（ｎｕｌｌａｂｉｌｉｔｙ）表示を含む物理ドメインプロパティのグループから選択される。ドメインプロパティ２１８の論理ドメインプロパティ態様は、オブジェクトデータ値を特定のドメインに割り当てられるようにすることによって、データポリアーキ１２２の検索およびナビゲーションを容易にする。具体的に言うと、論理ドメインは、データポリアーキ内の他のオブジェクトに関する対応するオブジェクトのアクセスまたは提示のストラテジを示す。たとえば、論理ドメインプロパティには、一意ドメインプロパティ、位置決めドメインプロパティ、および分類ドメインプロパティが含まれる。ポリアーキ的データ関係管理モジュール１１６がオブジェクトの属性に割り当てる特定の１つの論理ドメインプロパティは、データポリアーキ内の他のオブジェクトの同一の属性の他の値に関する、データポリアーキ内の属性の値の相対分布に基づく。
【００３８】
ここで、（ａ）データポリアーキ１２２内の属性がとる値の相対分布と、（ｂ）データ分布によって、どのオブジェクトが各々の次元（階層）、上ノード、および下ノードを表すかが決定される方法とを記述することができる。
【００３９】
（相対属性値分布）
属性が有する値の組は、その属性の論理ドメインの一部である。データポリアーキ１１１内の値の実際の分布（各潜在的な値を含む潜在的なオブジェクトの数に関する）に関して収集される情報も、属性の論理ドメインのプロパティである。属性値の相対分布を判定するために、１つ以上の閾値（たとえば、下閾値と上閾値）を定義して、ポリアーキ内の他のオブジェクトの他の属性に関するデータポリアーキ１２２内の属性の相対分布を判定する。閾値は、データがその中にある比率の誤差を有する可能性がある（たとえば１％の誤差）という前提に基づく（他の統計分析技法を、閾値と組み合わせてまたはその代わりに使用して、オブジェクト属性分布を判定することができる）。
【００４０】
たとえば、オブジェクトが、データポリアーキ１２２にロードされる（たとえば１つ以上のディレクトリサーバまたはデータベースサーバ１０６から）時に、データポリアーキ管理モジュール１２０が、閾値に基づいて各オブジェクトの各々の属性値を検査して、（ａ）どの属性がデータセット内のオブジェクトでの分布に関して実質的に一意であるか、（ｂ）どの属性がオブジェクトの実質的に大きい組にわたって分布するか、および（ｃ）どの属性がデータセット内のオブジェクトの実質的に小さい組にわたって分布するかを判定する。これらの判定は、データがある比率の誤差を有するという前提に基づいて行われる。
【００４１】
あるデータ誤差というこの前提を念頭において、実質的に一意の属性が、必ずしもデータポリアーキ１２２内でのこの種類の唯一の属性ではないことを検討されたい。そうではなくて、属性が、絶対的に一意である場合があり、また、属性が、データセット内の類似する属性の比較的疎な分布に属する場合がある。データセット内のオブジェクトにまたがる分布に関して実質的に一意と判定される属性は、それが他の属性と比較して特徴的であることを示す一意の論理ドメインプロパティを有する。
【００４２】
特徴的である属性によって、ポリアーキ的データセット１２２内の各々の一意の次元を識別することができ、この次元が、相互接続されたグラフの上ノードとして表され、この上ノードが、階層次元を表す。このモデルの内部では、デフォルトポリアーキがフラットである。特徴的でない属性は、データセット内のオブジェクトの実質的に大きい組にまたがって分布するか、その代りに、オブジェクトの実質的に小さい組にまたがって分布する。非特徴的な属性は、次元を定義する属性のよい候補ではない。そうではなくて、そのような分布は、非特徴的な属性が１つ以上の識別された次元に属することを示す。したがって、非特徴的な属性は、属性分布によって識別される少なくとも１つの次元の下ノードとして表される。上ノードポリアーキも、下ノードオブジェクトのすべての値が、実質的に一意の上ノードオブジェクト内で突き止められる時に、発見される。
【００４３】
オブジェクトの実質的に大きい組にまたがって分布する属性は、位置決めドメインプロパティを有する（たとえば、姓は、位置決めドメインプロパティになる可能性がある）。位置決めドメインプロパティを有する属性は、データポリアーキ１２２内のデータオブジェクトの特定の１つに関する検索を絞りこむのに使用される。オブジェクトの実質的に小さい組にまたがって分布する属性は、分類ドメインプロパティを有する。分類ドメインプロパティを有する属性は、検索手順またはナビゲーション手順から、望ましくないオブジェクトをフィルタアウトするのに使用される。
【００４４】
（ジャンプゲート）
ＧＵＩＤなどのサブオブジェクトエンティティ参照２２０は、仮想オブジェクト２１０（すなわち、各々のオブジェクト）が、データポリアーキ１２２内の異なるオブジェクトに対する関係を有するかどうかを示すだけではなく、異なるオブジェクトを参照する（すなわち、仮想オブジェクトに対応する異なるオブジェクトを介して）。具体的に言うと、サブオブジェクト参照によって、異なる関心を持たれるオブジェクトが、仮想オブジェクトデータフィールドのサブオブジェクトとして一意に識別される。このサブオブジェクト参照によって、１つ以上のデータストアにまたがって、異なる関心を持たれるオブジェクトが一意に識別される。
【００４５】
サブオブジェクトを参照する（対応するサブオブジェクトエンティティ参照２２０を介して）仮想オブジェクト２１０が、「ジャンプゲート」である。ジャンプゲートは、ポリアーキ的データセット１２２内の複合オブジェクトと関連するサブオブジェクトとの間の弾力性のあるデータ関係を表す。データポリアーキ内のオブジェクト間データ関係は、１つ以上の単純オブジェクト２１０または複合オブジェクト２１０を用いてモデル化される。オブジェクトが、１つ以上のサブデータ関係を有する場合には、そのような関係は、オブジェクト（または「サーフェスエンティティ」）内で参照されるサブオブジェクト２２０として、またはある次元で別のオブジェクト２１０にリンクされた別のオブジェクト２１０としてのいずれかで表現される。
【００４６】
これを示すために、従業員とその従業員に従属する者が、ディレクトリストア内のオブジェクトとして表される人である場合を検討されたい。データストア管理者は、各人のさまざまな態様に関する微細な粒度の情報を維持することを求める場合がある。サーフェスエンティティ（従業員）内のサブワールド情報（従属する者に関する）を表すために、下の表１に示された表現を使用することができる。
【００４７】
【表１】
0004880152.tif 000002
【００４８】
完全に別個のエンティティで従属する者に関するサブワールド情報を表現するために、Ａｌｉｃｅ  ＤｏｅおよびＳｉｇｍｕｎｄ  Ｄｏｅが、たとえば表２に示されているように独自のＧｌｕｅ  ＩＤ（ＧＵＩＤ２１２）を有する別々のエンティティに分割される。
【００４９】
【表２】
0004880152.tif 000003
【００５０】
「ｐｅｒｓｏｎ（人）」要素が、Ｊｏｈｎの仮想エンティティ内のサブ要素として存在するか、彼ら自体の独立の仮想エンティティ内のルート要素として存在するかにかかわらずに同一であることに留意されたい。これに関して、Ｊｏｈｎ  Ｄｏｅのエンティティを、表３に示されているように縮小することができる。
【００５１】
【表３】
0004880152.tif 000004
【００５２】
表２に示されたエンティティは、「ｄｅｐｅｎｄｅｎｔｓ（従属する者）」次元に沿ってＪｏｈｎに従属する者に関係し、「ｒｅｌａｔｅｄＥｍｐｌｏｙｅｅ（関連従業員）」が、「ジャンプゲートを通過する」ためにＧｌｕｅ  ＩＤに結合される。
【００５３】
この２つの極端の間で、Ｊｏｈｎのノードを内部的に表４に示されるように表現することを想像することができる。
【００５４】
【表４】
0004880152.tif 000005
【００５５】
表４のエンティティを、そのままクライアントに返し、クライアントが、関係するＧｌｕｅ  ＩＤを展開することによってこの情報に追加できるようにすることができる。もしくは、図１のデータポリアーキサーバ１０２などのサーバ自体が、Ｇｌｕｅ  ＩＤを参照解除し、下記のアマルガム（下の表５に示す）を返し、従来のディレクトリ実施形態で明白なジャンプゲート問題に対するこの解決策の弾力性を実証することができる。
【００５６】
【表５】
0004880152.tif 000006
【００５７】
言い換えると、仮想オブジェクト２１０は、（ａ）文字列、整数など、他の要素を参照しない単純オブジェクト（しばしば「単純要素」と称する）、または（ｂ）１つ以上の他の単純要素または複合要素を参照する複合オブジェクト（しばしば「複合要素」と称する）のいずれかとしてモデル化することができる。この形で、ポリアーキ的データセット１２２が、複数の異なる関係表現のいずれについてもいつでも定義することができる、弾力性のあるオブジェクト間データ関係を提供する。
【００５８】
したがって、最も単純な設計問題を解決する前にディレクトリの形状および命名のセマンティクスに合意しなければならない、手におえないスキーマ問題を有する従来の硬直したディレクトリ実施形態と大きく異なって、ジャンプゲートとしてモデル化されるオブジェクト間データ関係に出会った時に、基本的な設計判断は不要である。ポリアーキ的データセット１２２に基づくディレクトリ木の形状および命名は、ポリアーキ的データセットが設計された後であっても、さまざまな弾力性を有するオブジェクト間関係を表すことによって影響されない。さらに、複合オブジェクトに対する更新／修正も、１つ以上の関係するサブオブジェクトに対する対応する更新をもたらす可能性があり、これを、複合オブジェクトを表す特定の次元ではなく１つ以上の異なる次元で表現することができる。
【００５９】
（参照解除された動作に関するデータポリアーキスキーマの最適化）
複数のオブジェクトを、参照解除された次元グループまたは多対多オブジェクトの検索動作およびナビゲーション動作のために第３のオブジェクトに関係させることができる。たとえば、グループへのメンバシップは、メンバとグループの間の関係に関する情報を含むメンバシップエンティティによって表現される。メンバシップエンティティには、グループを識別するｍｅｍｂｅｒＯｆデータフィールドと、グループメンバを識別するｍｅｍｂｅｒＩｓデータフィールドが含まれる。この実施形態では、そのような一意の識別が、各々のＧＵＩＤ２１２を使用することによって達成される。
【００６０】
あるエンティティがグループのメンバであるかどうかを判定するためには、ｍｅｍｂｅｒＩｓがエンティティのＧＵＩＤであり、ｍｅｍｂｅｒＯｆがグループのＧＵＩＤである関係エンティティを検索する。メンバシップ次元は、表６に示されているように定義される。
【００６１】
【表６】
0004880152.tif 000007
【００６２】
この例では、グループのＧＵＩＤ（表６では「ＧｌｕｅＩＤ」と表されている）が実質的に一意なので、このＧＵＩＤによって、グループが上ノードとして識別され、子が、ｍｅｍｂｅｒＯｆ要素にグループのＧＵＩＤをセットされたメンバシップエンティティとして識別される。データセットを介する従来の「ダウン」ナビゲーションでは、メンバシップエンティティが列挙され、これによって、各個々のメンバシップの性質（たとえば特定のメンバシップが満了する時）に関する有用な情報がもたらされる可能性がある。
【００６３】
実際のグループメンバに関する情報を得るためにｍｅｍｂｅｒＩｓ関連付けを使用する、「間接」列挙を実行することも可能である。それを行うには、参照解除にｍｅｍｂｅｒＩｓをセットして、メンバシップ次元内でグループに対する「ダウン」列挙を発行する。この場合、メンバシップエンティティのｍｅｍｂｅｒＩｓが、グループに属する実際のエンティティの参照解除に使用される。したがって、あるエンティティが属するすべてのグループをリストする逆次元を構成することは単純である。この場合、メンバシップエンティティをリストするか、それらを参照解除してグループ自体に関する情報を得ることもできる。
【００６４】
したがって、関心を持たれる要素のスキーマ１２４でグループの逆ポリアーキまたは他の多対多オブジェクト間関係を表現するのに、特殊なスキーマ設計は不要である。
【００６５】
（例示的なデータポリアーキスキーマ）
図３に、クライアントがデータポリアーキ１２２を意味のある形で操作できる方法を示す、図１の例示的なデータポリアーキスキーマ１２４のさらなる態様を示す。このデータポリアーキスキーマを、「関心を持たれる要素の」スキーマとも称する。要素は、オブジェクト属性またはデータ値である。関心を持たれる要素のスキーマ１２４には、データポリアーキに対するクライアント１１０照会を制限するために複数のデータフィールド３１０が含まれる。そのような照会は、図１のデータポリアーキサーバ１０２に通信される。具体的に言うと、そのような照会は、処理のためにポリアーキデータ管理モジュール１２０に通信される。照会は、スキーマ１２４によって表されるオブジェクトの少なくとも１つのサブセットに制限される。
【００６６】
要素３１０は、オブジェクト自体ではなく、データポリアーキ１２２内での分布に関するオブジェクトデータの相対スコープを示すオブジェクト表現（すなわち、図２の仮想オブジェクト２１０）である。上で注記したように、これらの仮想エンティティは、アドレスのベクトルまたは配列としてスキーマに保管される。
【００６７】
データポリアーキ１２２内のオブジェクト２１０が有することができる属性２１４の異なるタイプのそれぞれも、スキーマ内で識別され、それと同時に、さまざまな属性タイプに対してどの種類のインデックスが使用されるかも、スキーマ内で識別される。
【００６８】
要素３１０（たとえばインデックスのタイプ）は、データポリアーキ１２２内の属性がとる値の相対分布に基づいて選択される（属性がとる値の相対分布は、上で図２に関して説明した）。要素３１０には、データポリアーキ１２２内のすべてのオブジェクトに対応する論理ドメインプロパティの少なくとも１つのサブセットが含まれる（論理ドメインプロパティは、上で図２に関して説明した）。要素３１０は、実質的に一意または「特徴的な」論理プロパティインデックスタイプ、位置決め論理プロパティインデックスタイプ、または分類論理プロパティインデックスタイプもしくはこれらの組合せを有する属性を表す。したがって、要素３１０には、特徴的要素３１０−１、位置決め要素３１０−２、および分類要素３１０−３が含まれる。
【００６９】
特徴的要素３１０−１（すなわち、特徴的インデックスタイプ）は、データポリアーキ１２２内の属性の間の次元関係のよい候補であり、たとえば、次元または階層内の上ノードを表す（たとえばＧＵＩＤ、位置、従業員番号、コストセンタなど）一意のオブジェクト（すなわち、特徴的要素によってインデクシングされる属性を有するオブジェクト）によって表される。位置決めインデックスタイプ３１０−３または選択インデックスタイプは、データポリアーキ内でオブジェクトを突き止めるためのよい候補であり、たとえば、姓、建物名、肩書、部屋番号、および類似物などの属性によって表される。性の表示（たとえば男または女）などの分類インデックスタイプを有する属性は、データセット内のオブジェクトの検索でオブジェクトをフィルタリングするためのよい候補である。というのは、分類オブジェクトが、他のインデックスタイプに対応する属性を有するオブジェクトの相対分布と比較して、データポリアーキ内での数が比較的少ないからである。
【００７０】
関心を持たれる要素のスキーマ１２４は、非常にカスタマイズ可能である。たとえば、ネットワーク管理者は、英語、フランス語、中国語などの名前などの自然言語の名前を、関心を持たれる要素のスキーマ１２４内の要素またはオブジェクトに割り当てることができる。さらに、管理者は、ジャンプゲートおよび表１から４に関して詳細に説明したように、リンクされるが別個のエンティティとして保管するためにサブオブジェクトを指定することができる。この形で、図１および２のポリアーキ的データセット１２２内の、そうでなければルートオブジェクトに直接従属するはずのオブジェクトが、スキーマ内で昇格の資格を有するようになる。この機構は、複数次元（ポリアーキ）と共に、弾力性のあるジャンプゲートを作るのに使用される。
【００７１】
表７に、ＸＭＬデータフォーマットでの例示的な関心を持たれる要素のスキーマ１２４を示す。要素３１０の、ＸＭＬ表現以外の他のデータフォーマット表現（たとえば、ＸＭＬの特徴の少なくともサブセットまたはそれより多くの特徴を有する、ＸＭＬの拡張版）が企図されている。このスキーマ表現では、箱に囲まれたテキスト（すなわち、箱の中または直線で囲まれたテキスト）およびセミコロン「；」の後に続くテキストが、対応するコメントを表す。一般に、複数行のコメントは、箱の中に配置される。
【００７２】
【表７】
0004880152.tif 000008
【００７３】
【表８】
0004880152.tif 000009
【００７４】
【表９】
0004880152.tif 000010
【００７５】
【表１０】
0004880152.tif 000011
【００７６】
【表１１】
0004880152.tif 000012
【００７７】
【表１２】
0004880152.tif 000013
【００７８】
【表１３】
0004880152.tif 000014
【００７９】
【表１４】
0004880152.tif 000015
【００８０】
（データポリアーキを動的に生成する例示的な手順）
図４に、オブジェクトの属性の値に基づくオブジェクト間関係の複数階層を生成する例示的な手順４００を示す。データポリアーキ１２２に、複数のオブジェクトが含まれる。この手順は、コンピュータ可読媒体に保管されたコンピュータ実行可能命令としてソフトウェアで実施し、媒体に機能的に結合されたプロセッサによって実行される時に、命令が、図４のブロックに示された動作を実行するものとすることができる。
【００８１】
ブロック４１０で、図１のデータポリアーキサーバ１０２が、Ｘ−５００およびＬＤＡＰに基づく従来のディレクトリサービス、メタディレクトリサービス、データベースなどの、任意の数のデータソースからデータを受け取る。データは、ＸＭＬデータフォーマットなどの複数の異なるデータフォーマットのいずれかで受け取られる。サーバ１０２は、受け取ったデータを、図１のデータポリアーキ管理モジュール１２０に通信する。
【００８２】
ブロック４１２で、データの受取（ブロック４１０）に応答して、データポリアーキ管理モジュール１２０が、受け取ったデータとポリアーキ１２２内に既にあるデータ（存在する場合に）の間のオブジェクト間関係（たとえば単一方向または両方向の関係）を反映するようにデータポリアーキ１２２を生成するか更新する。既に述べたように、これらのオブジェクト間関係は、ポリアーキ内の他のオブジェクトの属性に関する、受け取ったデータの属性に基づいて判定される。具体的に言うと、データポリアーキを生成、構成、または更新するために、管理モジュールは、データポリアーキ内のオブジェクトの属性の相対分布を分析して、０個、１個、または複数の次元のうちで、各オブジェクトがポリアーキ内の他のオブジェクトとのオブジェクト間関係に参加するものがどれであるかを判定する。
【００８３】
これらの動作４１２は、データの受取（ブロック４１０）に自動的にまたは動的に応答し、ネットワーク管理者などの人間のオペレータの介入を必要としない。データポリアーキ１２２内のオブジェクト間関係が、ポリアーキ内のオブジェクトの属性の値に基づいて判定され、表現されるので、これらのオブジェクト間データ関係を、弾力性のあるものとすることができ、これは、それらのオブジェクト間データ関係が、経時的に変化することができることを意味する。属性の値が変化する際に、新しい値に基づくオブジェクト間関係が、受取時に管理モジュール１２０によってポリアーキ内で動的にまたは自動的に表現される。これらの動作４１２は、データポリアーキ内のデータオブジェクトの各々の１つの間のデータ関係の先見的知識から独立に実行される。さらに、データポリアーキ内のオブジェクト間関係が、ポリアーキ内のオブジェクトの属性の値に基づいて判定され、表現されるので、これらの関係は、オブジェクトの識別名から完全に独立に判定され、表現される。
【００８４】
ブロック４１４で、図１のデータポリアーキ管理モジュール１２０が、関心を持たれる要素のスキーマ１２４の生成、構成、または更新を行って（たとえば図１および３を参照されたい）、データポリアーキ１２２を意味のある形で操作、提示、およびナビゲートできる方法を示す。具体的に言うと、図２および３と表７に関して上で説明したように、スキーマによって、データポリアーキ内の要素または属性が、各属性の対応する特徴的特性、位置決め特性、または分類特性と共に示される。スキーマによって、ポリアーキ内の次元も、その次元内のオブジェクトによって含まれる関心を持たれる要素または属性のそれぞれと共に示される。
【００８５】
ブラウザによって、ポリアーキ的データセット１２２の検索、ナビゲート、または部分の表示に使用されるポリアーキ的照会言語（ＰＱＬ）コマンドの例示的セット（関心を持たれる要素のスキーマ１２４に基づく）を、図６から１２に関して下で詳細に説明する。関心を持たれる要素のスキーマ１２４を使用してＰＱＬ要求および応答を式で表す例示的な手順を、図１３に関して下で詳細に説明する。
【００８６】
（例示的ポリアーキ的照会言語要求）
図５に、データポリアーキ内の情報に対応する情報（ポリアーキ的照会言語（ＰＱＬ）応答）を返すようにデータポリアーキサーバ１０２に要求するためにクライアント１１０によって使用される例示的ＰＱＬ照会を示す。そのような照会の受取に応答して、データポリアーキ管理モジュール１２０が、ポリアーキ内のオブジェクトに対応する情報の組を識別し、取り出す。
【００８７】
照会５００および対応するサーバ１０２の応答は、ＸＭＬなどのテキストマークアップ言語を使用して実施される。この構成では、照会およびサーバ応答が、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）でパッケージ化され、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を使用して図１のネットワーク１０４上にポストされる。ＳＯＡＰおよびＨＴＴＰは、ネットワーク通信プロトコルの当業者に周知の通信プロトコルである。
【００８８】
メッセージ５００には、スキーマＩＤ５０２と、１つ以上の図２の属性２１４を指定するための１つ以上のオブジェクト変換パラメータ５１０（以下では、パラメータを、データフィールドとも称する）が含まれる。スキーマＩＤは、特定の関心を持たれる要素のスキーマ１２４を識別するのに使用される。このデータフィールドは、デフォルトスキーマまたは１つのスキーマだけがある場合には任意選択であることを諒解されたい。属性５１０は、データポリアーキ１２２の仮想オブジェクト２１０に対応する（属性には、特徴的属性、位置決め属性、または分類属性が含まれ、これらのそれぞれを、上で図２の論理ドメインプロパティに関して詳細に説明した）。
【００８９】
パラメータ５１０またはデータフィールドは、そのタイプに従って分類され、タイプは、特定の関心を持たれる要素タイプ５１０−１、応答を制限するための関心を持たれる要素修飾子５１０−２、論理修飾子５１０−３、次元インジケータ５１０−４、または次元情報修飾子５１０−５を含むタイプから選択される。メッセージ５００で表現されるデータフィールドの数およびタイプは、メッセージの設計または目的に基づく。
【００９０】
図６に、例示的なＰＱＬ照会５００メッセージと、対応する例示的なＰＱＬ応答６２０とを表示するユーザインターフェース（ＵＩ）６００を示す。具体的には、ＰＱＬ照会に、データポリアーキ１２２の検索を実行するのに用いる特定の属性５１０を指定するための、データポリアーキスキーマ１２４に基づく修飾子パラメータ５１０−１が含まれる。ＵＩには、ＰＱＬメッセージ５００を入力するための第１区域６１０、ＳＯＡＰエンベロープ６１８にパッケージ化され、ＨＴＴＰを介してポストされるＰＱＬメッセージを示す第２区域６１２、およびデータポリアーキ管理モジュール１２０のＰＱＬ応答６２０を示す第３区域６１４が含まれる。ＰＱＬ応答は、ＳＯＡＰエンベロープで返されるものとして図示されているが、応答を、さまざまな他のデータパッケージフォーマットで返すことができる。
【００９１】
この例では、特定の関心を持たれる要素パラメータ５１０−１によって、姓属性「Ｄｏｅ」が指定される。ＰＱＬ応答６２０では、少なくとも２つのオブジェクトと、対応する関心を持たれる要素が返される。各々のＧｌｕｅ  ＩＤによって、各々のオブジェクトが識別され、これは特徴的要素である。第１のオブジェクトは、「Ｊｏｈｎ  Ｄｏｅ」に関係する。第２のオブジェクトは、「Ｊｉｍ  Ｄｏｅ」に関係する。各オブジェクトは、部屋番号（「ｒｏｏｍ  ｎｕｍｂｅｒ」）、ユーザＩＤ（「ｕｉｄ」）、姓（「ｓｎ」）、名（「ｇｉｖｅｎ  ｎａｍｅ」）、建物名（「ｂｕｉｌｄｉｎｇ  ｎａｍｅ」）、肩書（「ｔｉｔｌｅ」）、関係する次元の表示（「ｌｏｃａｔｉｏｎＵｐｎｏｄｅ」）、エンティティマネージャ（「ｍａｎａｇｅｒ」）、コストセンタＩＤ（「ｃｏｓｔ  ｃｅｎｔｅｒ  ｕｐ  ｎｏｄｅ」）などの複数の関心を持たれる要素と共に返された。
【００９２】
特定の関心を持たれる要素によって、データポリアーキ１２２に保管された特定のオブジェクトに対応するＧＵＩＤなどの絶対的に一意の特徴的属性が指定された場合には、サーバ１０２は、その特定のオブジェクトに関するデータポリアーキ１２２に保管された情報のすべてを返す。
【００９３】
図７に、検索の結果を修正するのに用いられる制限属性を指定する、関心を持たれる要素修飾子データフィールド５１０−２を有する例示的ＱＰＬ照会を表示するユーザインターフェース６００を示す。制限属性は、ポリアーキ的データスキーマ１２４によって表されるオブジェクトの組に対応する。関心を持たれる要素修飾子データフィールドによって、サーバに、検索動作に対する応答が、制限属性に関して識別されたデータポリアーキ１２２オブジェクトの提示に制限されることが示される。
【００９４】
この例では、制限属性５１０−２が、普通名（「ｃｎ」）属性および一意識別子属性である。したがって、サーバによって返されるさまざまな人物オブジェクト６２０では、これらの制限属性だけが示される。
【００９５】
図８に、データ関係のポリアーキに関する数学的動作を実行する論理修飾子パラメータ５１０−３を含む例示的なＰＱＬ照会５００のユーザインターフェースを示す。論理修飾子は、変数に基づくデータ関係の１つ以上の階層に対してフィルタリング動作（「ａｎｄ」）、和集合動作（「ｏｒ」）、または排他動作（「ｎｏｔ」）を実行するのに使用される。変数には、図１および３と表７のデータポリアーキスキーマ１２４によって表されるオブジェクト、スキーマによって表されるオブジェクトの階層、またはスキーマによって表されるオブジェクトのポリアーキなどが含まれる。
【００９６】
たとえば、「ａｎｄ」論理修飾子５１０−３は、特定の関心を持たれる要素データフィールド５１０−１に基づく２つのデータストア検索の結果をフィルタリングするのに使用される。第１の特定の関心を持たれる要素データフィールドでは、値が「Ｓｍｉｔｈ」の姓（「ｓｎ」）属性が指定される。第２の特定の関心を持たれる要素データフィールドでは、値が「副社長（ｖｉｃｅ  ｐｒｅｓｉｄｅｎｔ）」の「肩書（ｔｉｔｌｅ）」属性が指定される。したがって、論理修飾子を使用して、各々の検索結果に基づいて結果を狭めるかフィルタリングすることができる。結果は、副社長Ｊｏｈｎ  Ｓｍｉｔｈに対応する、ＰＱＬ応答６２０の単一のオブジェクトである。この照会５００に一致するエンティティ情報の複数の組がディレクトリに保管されている場合には、エンティティのそれぞれが、結果に提示される。
【００９７】
図９に、データストアに保管されたオブジェクトの検索動作に対応する応答をその中で提示する次元を指定するための次元情報インジケータデータフィールド５１０−４を含む、例示的なＰＱＬ照会５００を示すユーザインターフェース６００を示す。この例では、「下（ｕｎｄｅｒ）」パラメータ５１０−４（または「句」）が、フィルタ５１０−３（「＜ａｎｄ＞」）と組み合わされて、「１２３４５６７８９８」という対応する「一意識別子（ｕｎｉｑｕｅ  ｉｄｅｎｔｉｆｉｅｒ）」を有することが示されている、Ｊｏｈｎ  Ｓｍｉｔｈの下の「構造（ａｒｃｈｉｔｅｃｔ）」が検索される（図８のＪｏｈｎ  Ｓｍｉｔｈの一意識別子も参照されたい）。Ｊｏｈｎ  Ｓｍｉｔｈの下の構造に対応する情報が、サーバ１０２からのＰＱＬ応答６２０に提示される（関心を持たれる要素データフィールド５１０−２が、検索の結果に提示される要素の数を制限するのに使用される方法に留意されたい）。
【００９８】
図１０に、次元情報修飾子データフィールド５１０−５を有するＰＱＬ照会５００を示すユーザインターフェース６００を示す。次元情報修飾子によって、ポリアーキ的スキーマ内の複合オブジェクトと１つ以上の異なる表現されたオブジェクトの間のデータ関係を提示するための特定の方向および特定の深さが指定される。方向は、１つ以上の（「＊」などのワイルドカード指示を使用する場合はすべてのオブジェクト）異なるオブジェクトが、複合オブジェクトのサブオブジェクトであるかどうかを示す。次元情報修飾子では、ＳＩＢＬＩＮＧＳ（兄弟）＝’ｔｒｕｅ’を指定して、現在のオブジェクトと同一の親を有するすべてのオブジェクトを返さなければならないことを示すこともできる。
【００９９】
この例では、次元情報修飾子５１０−５が、第１レベルの従属する者１０１０に対応する情報６２０をデータストアから取り出すのに使用される。これは、ジャンプゲートである。というのは、Ｊｏｈｎ  Ｓｍｉｔｈに従属する者１０１０が、Ｊｏｈｎ  Ｓｍｉｔｈのオブジェクト定義６２０の態様として提示されるからである。
【０１００】
図１１は、特定の属性と、データ関係の２つのポリアーキの間の後続の交差とに関するＰＱＬ照会５００でのフィルタパラメータの使用を示す、ユーザインターフェース６００のブロック図である。この例では、２つの次元５１０−４（たとえば、「マネージメント（ｍａｎａｇｅｍｅｎｔ）」次元と「オフィスの位置（ｏｆｆｉｃｅ  ｌｏｃａｔｉｏｎ）」次元）が、交差され、「構造（ａｒｃｈｉｔｅｃｔ）」の「肩書（ｔｉｔｌｅ）」属性に基づいてフィルタリングされる５１０−３。検索結果６２０に、その照会に一致する、データストア内の特定のオブジェクトが示される。
【０１０１】
図１２に、データ関係の２つのポリアーキ５１０−４の間のフィルタ（「ａｎｄ」）５１０−３および和集合（「ｏｒ」）５１０−３を指定するＰＱＬ５００を示すユーザインターフェース６００が示されている。この例では、フィルタおよび和集合が、論理修飾子である。和集合属性は、「マネージメント（ｍａｎａｇｅｍｅｎｔ）」次元および「オフィスの位置（ｏｆｆｉｃｅ  ｌｏｃａｔｉｏｎ）」次元に適用される。フィルタでは、「構造（ａｒｃｈｉｔｅｃｔ）」の「肩書（ｔｉｔｌｅ）」属性が指定され、これは、２つの階層の和集合に適用される。検索結果６２０に、この照会に一致する、データストア内の特定のオブジェクトが示される。
【０１０２】
（ポリアーキ的データセットを管理する例示的手順）
図１３に、データポリアーキ１２２内のデータを管理する例示的な手順１３００を示す。ブロック１３１０で、ポリアーキ的データ管理モジュール１２０が、関心を持たれる要素のスキーマ１２４をクライアント１１０に通信する。関心を持たれる要素のスキーマ１２４によって、クライアントに、クライアントが意味のある形でデータポリアーキ内のオブジェクトのアクセス、操作、および提示を行える方法が示される。
【０１０３】
ブロック１３１２で、ポリアーキ的データ管理モジュール１２０が、通信されたデータポリアーキスキーマ（ブロック１３１０）に基づくＰＱＬメッセージ５００を受け取る。この要求では、関心を持たれる１つ以上の属性が識別されるだけではなく、関心を持たれるデータ関係も識別される。この要求は、図１のポリアーキ的データセット１２２内のデータオブジェクト群の１データオブジェクトに対応する。
【０１０４】
受け取られたＰＱＬメッセージ５００は、（ａ）データオブジェクトのデフォルト検索オブジェクトを見つける動作、（ｂ）データオブジェクト群のうちで特定の名前に対応するオブジェクトを突き止める動作、（ｃ）データオブジェクト群の１特定のオブジェクトに対応するデータ関係のデフォルト階層を得る動作、（ｄ）データオブジェクト群の１特定のオブジェクトに対応するデータ関係の特定の階層を得る動作、（ｅ）データオブジェクト群の１特定のオブジェクトに対応するデータ関係の複数の階層の少なくとも１つのサブセットを識別する動作、（ｆ）データオブジェクト群の１特定のオブジェクトに対応するデータ関係の複数階層を得る動作、などの任意の組み合わせを含む１つ以上の動作に対応するものとすることができる。
【０１０５】
ブロック１３１４で、データポリアーキ管理モジュール１２０が、物理アクセスストラテジ（たとえば単純スキャン、再帰スキャンなど）を判定して、要求に対応するデータをデータポリアーキ１２２から識別する。この判定は、要求（ブロック１３１２）に基づき、要求は、クライアント１１０に通信された（ブロック１３１０）スキーマ１２４に基づく。既に注記したように、スキーマは、クライアントに、データポリアーキの可能な内容に対応する情報を与えるだけではなく、関心を持たれるいずれかのオブジェクトに関係する可能性があるデータ関係の可能なポリアーキを記述した情報も含む（たとえば、表７に示された「＜Ｄｉｍｅｎｓｉｏｎ（次元）＞」インジケータを参照されたい）。
【０１０６】
たとえば、クライアント要求（すなわちＰＱＬメッセージ５００）が、絶対的に一意の特徴的属性（たとえばＧＵＩＤおよびそのＧＵＩＤに対応する普通名）を除く、オブジェクトに関係する関心を持たれる要素のすべてをフィルタアウトするように設計される場合に、データポリアーキ１２２の単純スキャンが、関心を持たれる特徴的オブジェクトに関する情報に関する検索の効率的な技法であることを考慮されたい。
【０１０７】
しかし、要求５００で、複合オブジェクト（すなわちジャンプゲート）に関して複数のサブオブジェクトを提示しなければならず、その後、結果を、１つ以上のサブオブジェクトに直交する複合オブジェクトに対応する情報の次元の和集合によって後に修正しなければならないことを示すこともできる。この場合には、データポリアーキ１２２の再帰スキャンが、関心を持たれるオブジェクトおよびオブジェクト間関係に関する情報の検索に効率的な技法である。
【０１０８】
この形で、関心を持たれる属性およびデータ関係を識別するＰＱＬ要求メッセージ５００が、そのような属性およびデータ関係についてデータポリアーキ１２２を検索する最適化された物理アクセスストラテジも提供する。
【０１０９】
ブロック１３１６で、データポリアーキ管理モジュール１２０が、判定された物理アクセスストラテジ（ブロック１３１４）に基づいて、ポリアーキからデータにアクセスする。アクセスされるデータは、複数の異なる形態をとることができる。たとえば、アクセスされるデータは、データオブジェクトとポリアーキ内の他のオブジェクトの間のオブジェクト間関係のいずれからも独立とすることができる。さらに、アクセスされるオブジェクトが、ポリアーキ内の１つ以上の異なるデータオブジェクトとのオブジェクト間関係の１つ以上の階層に参加することができる。この場合には、アクセスされるオブジェクトおよび１つ以上の異なるオブジェクトに、類似する属性が含まれる。上で述べたように、これらのオブジェクト間関係は、１つ以上の次元でお互いに関して直交するものとすることができる。
【０１１０】
ブロック１３１８で、ポリアーキ的データ管理モジュール１２０が、クライアント１１０への発行のために、アクセスされたデータを変換する。具体的に言うと、アクセスされたデータは、データの要求に使用された（ブロック１３１２）特定のＰＱＬメッセージ５００の要件に基づいて変換される。たとえば、メッセージで、特定の次元に関してオブジェクトが示される場合に、アクセスされたデータの暗示的および明示的なオブジェクト間関係が、特定の次元に基づいて階層に組み立てられる。
【０１１１】
たとえば、アクセスされたデータオブジェクトは、アクセスされたデータに、データオブジェクトの１つ以上のサブオブジェクトに関係するデータオブジェクトの複合オブジェクトが含まれる時に、ジャンプゲートを表す。この場合には、複合オブジェクトが、独立のサーフェスエンティティとして変換または表現される。１つ以上のサブオブジェクトのそれぞれが、サーフェスエンティティに独立の形で各々の別々のエンティティとして記述される。その後、１つ以上のサブオブジェクトが、サーフェスエンティティ内で変換または参照されて、複合オブジェクトと１つ以上のサブオブジェクトの間の関係が示される。参照は、すべてのオブジェクト命名または複合オブジェクトと１つ以上のサブオブジェクトの間の階層データ関係から独立である。
【０１１２】
もう１つの例では、アクセスされたデータに、１つ以上のサブオブジェクトに関係する、ポリアーキ内のデータオブジェクトのうちの第１オブジェクトが含まれる。第１オブジェクトは、独立のサーフェスエンティティとして変換または表現される。１つ以上のサブオブジェクトのそれぞれが、サーフェスエンティティから独立の形で各々の別々のエンティティとして記述される。その後、各々のリンクが、第１オブジェクトを参照するために、１つ以上のサブオブジェクトのそれぞれに含められる。この形で、前の例のように、データが変換されて、対応するＰＱＬメッセージ５００で示される、関心を持たれる関係が表現される。
【０１１３】
ブロック１３２０で、データポリアーキ管理モジュール１２０が、変換されたデータ（ブロック１３１８）をクライアントに発行または通信する。
【０１１４】
（例示的なコンピューティング環境）
図１４に、図１の例示的なデータポリアーキサーバ１０２を実施できる適するコンピューティング環境１４００の例を示す。この例示的なコンピューティング環境は、適するコンピューティング環境の１例にすぎず、例示的なデータポリアーキサーバ１０２、サーバ１０６、またはクライアント１１０の使用または機能性の範囲に関する制限を暗示することは意図されていない。コンピューティング環境１４００が、例示的なコンピューティング環境１４００に図示された構成要素のいずれかまたはその組合せに関する依存性または要件を有すると解釈してもならない。
【０１１５】
コンピュータ１４０２は、多数の他の汎用のまたは特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成と共に作動可能である。例示的なコンピュータ１４０２と共に使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限されない。
【０１１６】
例示的なコンピュータ１４０２を、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。例示的なコンピュータ１４０２は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することができる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。
【０１１７】
図１４からわかるように、コンピューティング環境１４００には、コンピュータ１４０２の形の汎用コンピューティングデバイスが含まれる。コンピュータ１４０２の構成要素には、１つ以上のプロセッサまたは処理ユニット１４１２、システムメモリ１４１４、および、システムメモリ１４１４を含むさまざまなシステム構成要素をプロセッサ１４１２に結合するバス１４１６を含めることができるが、これに制限されない。
【０１１８】
バス１４１６は、メモリバスまたはメモリコントローラ、周辺バス、加速されたグラフィック・ポート（ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）、および、さまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む、複数のタイプのバス構造のいずれかの１つ以上を表す。制限ではなく例として、そのようなアーキテクチャには、インダストリ・スタンダード・アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダード・アソシエーション（ＶＥＳＡ：Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、および、メザニンバスとも称するペリフェラル・コンポーネント・インターコネクト（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。
【０１１９】
サーバ１４０２には、通常は、さまざまなコンピュータ可読媒体が含まれる。そのような媒体は、コンピュータ１４０２によってアクセス可能なすべての使用可能な媒体とすることができ、これには、揮発性媒体および不揮発性媒体と、取外し可能媒体および取外し不能媒体の両方が含まれる。
【０１２０】
図１４では、システムメモリ１４１４に、ランダムアクセスメモリ（ＲＡＭ）１４２０などの揮発性メモリ、または読取専用メモリ（ＲＯＭ）１４１８などの不揮発性メモリ、もしくはその両方の形の、コンピュータ可読媒体が含まれる。起動中などにコンピュータ１４０２内の要素の間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２２が、ＲＯＭ１４１８に保管される。ＲＡＭ１４２０には、通常は、プロセッサ１４１２によって即座にアクセス可能または現在操作されているデータまたはプログラムモジュールが含まれる。
【０１２１】
コンピュータ１４０２には、さらに、他の取外し可能／取外し不能、揮発性／不揮発性のコンピュータ記憶媒体を含めることができる。例のみとして、図１４に、取外し不能で不揮発性の磁気媒体（図示せず。通常は「ハードドライブ」と呼ばれる）を読み書きするためのハードディスクドライブ１４２４、取外し可能で不揮発性の磁気ディスク１４２８（たとえば「フロッピディスク」）を読み書きするための磁気ディスクドライブ１４２６、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光学媒体などの取外し可能で不揮発性の光ディスク１４３２を読み書きするための光ディスクドライブ１４３０が示されている。ハードディスクドライブ１４２４、磁気ディスクドライブ１４２６、および光ディスクドライブ１４３０は、それぞれ、１つ以上のインターフェース１４３４によってバス１４１６に接続される。
【０１２２】
ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、およびコンピュータ１４０２用の他のデータの不揮発性記憶域を提供する。本明細書に記載の例示的環境ではハードディスク、取外し可能磁気ディスク１４２８、および取外し可能光ディスク１４３２を使用するが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）および類似物などの、コンピュータによってアクセス可能であるデータを保管することができる他のタイプのコンピュータ可読媒体も、例示的オペレーティング環境内で使用可能であることを、当業者は諒解するであろう。
【０１２３】
複数のプログラムモジュール１４４０を、ハードディスク、磁気ディスク１４２８、光ディスク１４３２、ＲＯＭ１４１８、またはＲＡＭ１４２０に保管することができ、このプログラムモジュールには、制約ではなく例として、オペレーティングシステム１４３８、１つ以上のアプリケーションプログラム１４４０、他のプログラムモジュール１４４２、およびプログラムデータ１４４４が含まれる。
【０１２４】
そのようなオペレーティングシステム１４３８、１つ以上のアプリケーションプログラム１４４０（たとえばポリアーキデータ管理モジュール１２０）、他のプログラムモジュール１４４２、およびプログラムデータ１４４４（たとえばデータポリアーキ１２２および関心を持たれる要素のスキーマ１２４）のそれぞれ、またはそれらのある組合せに、図１の例示的なデータポリアーキサーバ１０２の実施形態を含めることができる。具体的に言うと、これらのそれぞれに、下記のためにデータポリアーキサーバ１０２の実施形態を含めることができる。
【０１２５】
（ａ）オブジェクトの属性値に基づくデータポリアーキ１２２の動的な生成、管理、および更新、
（ｂ）データポリアーキ内のオブジェクトをさまざまなオブジェクト間関係内で意味のある形で提示でき操作できる方法を示す、関心を持たれる要素のスキーマを生成するための、属性の相対分布に基づくデータポリアーキの分析、
（ｃ）関心を持たれる要素のスキーマ１２４のクライアント１１０への通信、
（ｄ）スキーマに基づく照会（たとえばＰＱＬメッセージ５００）の受取に応答する、ポリアーキ的データセット１２２から要求されたデータにアクセスするための物理アクセスストラテジの判定、
（ｅ）照会要求に基づくデータのアクセスおよび変換、および
（ｆ）応答としてのクライアントへの変換されたデータの発行。
【０１２６】
ユーザは、キーボード１４４６およびポインティングデバイス１４４８（「マウス」など）などの任意選択の入力装置を介して、コンピュータ１４０２にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、シリアルポート、スキャナ、および類似物を含めることができる。これらおよび他の入力装置は、バス１４１６に結合されるユーザ入力インターフェース１４５０を介して処理ユニット１４１２に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェース構造およびバス構造によって接続することができる。
【０１２７】
任意選択のモニタ１４５２または他のタイプの表示装置も、ビデオアダプタ１４５４などのインターフェースを介してバス１４１６に結合される。モニタのほかに、パーソナルコンピュータには、通常は、出力周辺インターフェース１４５５を介して接続することができる、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）が含まれる。
【０１２８】
コンピュータ１４０２は、リモートサーバ／コンピュータ１４６２（たとえばデータサーバ１０６）などの１つ以上のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１４６２には、コンピュータ１４０２に関して本明細書で説明する要素および特徴の多くまたはすべてを含めることができる。
【０１２９】
図１４に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１４５７および一般的な広域ネットワーク（ＷＡＮ）１４５９である。そのようなネットワーク環境は、オフィス、企業内コンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。ＬＡＮネットワーキング環境で使用される時に、コンピュータ１４０２は、ネットワークインターフェースまたはネットワークアダプタ１４６６を介してＬＡＮ１４５７に接続される。ＷＡＮネットワーキング環境で使用される時に、コンピュータには、通常、ＷＡＮ１４５９を介する通信を確立するための、モデム１４５８または他の手段が含まれる。モデムは、内蔵または外付けとすることができるが、ユーザ入力インターフェース１４５０または他の適当な機構を介してシステムバス１４１６に接続することができる。
【０１３０】
図１４には、インターネットを介するＷＡＮの特定の実施形態が図示されている。コンピュータ１４０２には、通常、インターネット１４６０を介する通信を確立するための、モデム１４５８または他の手段が含まれる。モデムは、内蔵または外付けとすることができるが、インターフェース１４５０を介してバス１４１６に接続される。
【０１３１】
ネットワーク化された環境では、コンピュータ１４０２に関して図示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。制限ではなく例として、図１４に、リモートコンピュータ１４６２のメモリデバイスに常駐するリモートアプリケーションプログラム１４６９を示す。図示され説明されたネットワーク接続が、例示的であり、コンピュータ間の通信リンクを確立する他の手段を使用できることを諒解されたい。
【０１３２】
（コンピュータ可読媒体）
例示的なコンピュータ１０２の実施形態を、ある形のコンピュータ可読媒体に保管するか、それにまたがって伝送することができる。コンピュータ可読媒体は、コンピュータによってアクセス可能なすべての使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、「コンピュータ記憶媒体」および「通信媒体」を含めることができる。
【０１３３】
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の保管のためのあらゆる方法またはテクノロジで実施された、揮発性および不揮発性の、取外し可能および取外し不能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、もしくは、所望の情報を保管するのに使用でき、コンピュータによってアクセスできる他のすべての媒体が含まれるが、これに制限されない。
【０１３４】
「通信媒体」は、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号で、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施する。通信媒体には、すべての情報配布媒体も含まれる。
【０１３５】
用語「変調されたデータ信号」は、信号内に情報をエンコードする形でその特性の１つ以上をセットされるか変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組み合わせも、コンピュータ可読媒体の範囲に含まれる。
【０１３６】
（結論）
説明した構成および手順によって、単一の静的階層内でオブジェクト間関係を表現する識別名という従来の概念が置換される。具体的に言うと、説明した構成および手順によって、これらの従来の概念が、オブジェクトの属性に基づくデータ関係の複数次元でのオブジェクト間接続の動的に生成されるグラフに置換される。この形で、複雑な実世界のオブジェクトが、特定のオブジェクト自体に関して、特定のオブジェクトに関係する分解されたサブエンティティまたはサブオブジェクトの組に関して表現される。これらのオブジェクト間関係は、データポリアーキ１２２内の関心を持たれる要素にアクセスするために生成されたデータポリアーキスキーマ１２４を使用して管理され、ナビゲートされる。
【０１３７】
データ関係のポリアーキを生成し管理するための、説明した内容は、構造的特徴または方法論的動作に固有の言語で説明されたが、請求項で定義される主題が、必ずしも説明された特定の特徴または動作に制限されないことを理解されたい。そうではなく、特定の特徴およびステップは、請求される本発明を実施する好ましい形態として開示されたものである。
【０１３８】
【発明の効果】
本発明によれば、オブジェクト属性値に基づくオブジェクト間関係の複数階層の動的生成が提供される。
【図面の簡単な説明】
【図１】オブジェクトの属性の値に基づいてオブジェクト間関係の複数階層を動的に生成し管理する例示的システムを示す図である。
【図２】オブジェクトの属性の値に基づく動的に生成されるオブジェクト間関係の複数階層を表す例示的なポリアーキデータ構造を示す図である。
【図３】図２のデータポリアーキを意味のある形で作成し、アクセスし、操作する方法を示す、例示的なスキーマデータ構造を示す図である。
【図４】オブジェクトの属性の値に基づくオブジェクト間関係の複数階層を生成する例示的手順を示す図である。
【図５】データポリアーキから情報（ポリアーキ的照会言語（ＰＱＬ）応答）を返すようにサーバに要求するためにクライアントによって使用される例示的ＰＱＬ要求を示す図である。
【図６】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を表示するユーザインターフェース（ＵＩ）を示す図であり、具体的には、ＰＱＬ照会に、ポリアーキ的データセットの検索を実行するのに用いる特定の属性を指定するための、データポリアーキスキーマに基づく修飾子パラメータが含まれる図である。
【図７】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を表示するＵＩを示すブロック図であり、具体的には、ＰＱＬ照会に、関心を持たれる要素のスキーマに基づく修飾子パラメータが含まれ、このパラメータによって、検索の結果を修正するのに用いられる制限属性が指定されるブロック図である。
【図８】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を表示するＵＩを示すブロック図であり、具体的には、ＰＱＬ照会に、データ関係のポリアーキに関する数学的動作を実行する論理修飾子パラメータが含まれるブロック図である。
【図９】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を示すＵＩのブロック図であり、具体的には、ＰＱＬ照会に、データストアに保管されたオブジェクトをその中で表示する次元を指定するための次元情報インジケータパラメータが含まれるブロック図である。
【図１０】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を示すＵＩを示す図であり、具体的には、ＰＱＬ照会に、次元情報修飾子パラメータが含まれ、これによって、サーバプロセスが、ポリアーキ的データセットの複合オブジェクトと１つ以上の他のオブジェクトの間のデータ関係を提示するための、特定の階層方向および特定の階層深さが指定される図である。
【図１１】例示的なＰＱＬ応答を形成するための、特定の属性およびデータ関係の２つの対応するポリアーキの間の後続の交差に関する例示的なＰＱＬ照会での位置決め要素の使用を示すＵＩを示す図である。
【図１２】例示的なＰＱＬ照会と、対応する例示的なＰＱＬ応答を示すＵＩを示す図であり、具体的には、ＰＱＬ照会に、データ関係の２つのポリアーキに関するフィルタパラメータおよび和集合パラメータの使用が示されている図である。
【図１３】データポリアーキ（すなわち、オブジェクトの属性の値に基づく動的に生成されるオブジェクト間関係の複数階層）内のデータを管理する（たとえば、オブジェクトにアクセスする、オブジェクトを提示する、提供する、操作するなど）例示的な手順の諸態様を示す図である。
【図１４】データポリアーキを管理する例示的なオペレーティング環境の諸態様を示す図である。
【符号の説明】
１０２  データポリアーキサーバ
１０４  ネットワーク
１０６  データサーバ
１０８−１〜１０８−４  データベース
１１０  クライアントコンピュータ
１１２  プロセッサ
１１４  メモリ
１１６  プログラムモジュール
１１８  データ
１２０  データポリアーキ管理モジュール
１２２  ポリアーキ的データセット
１２４  関心を持たれる要素のスキーマ
２１０−１〜２１０−Ｎ  仮想オブジェクト
２１２  ＧＵＩＤデータフィールド
２１４  属性データフィールド
２１６  述部データフィールド
２１８  ドメインプロパティデータフィールド
２２０  サブオブジェクトエンティティ参照
３１０−１  特徴的要素
３１０−２  位置決め要素
３１０−３  分類要素
５００  ポリアーキ的データセット照会
５０２  スキーマＩＤ
５１０  オブジェクト変換パラメータ
５１０−１  特定の関心を持たれる要素
５１０−２  応答を制限するための修飾子
５１０−３  論理修飾子
５１０−４  次元情報インジケータ
５１０−５  次元情報修飾子
６００  ユーザインターフェース
６１０  第１区域
６１２  第２区域
６１４  第３区域
６１８  ＳＯＡＰエンベロープ
６２０  ＰＱＬ応答
１４００  コンピューティング環境
１４１２  処理ユニット
１４１４  システムメモリ
１４１６  バス
１４１８  ＲＯＭ
１４２０  ＲＡＭ
１４２２  ＢＩＯＳ
１４２４  ハードディスクドライブ
１４２６  磁気ディスクドライブ
１４２８  磁気ディスク
１４３０  光ディスクドライブ
１４３２  光ディスク
１４３４  データ媒体インターフェース
１４３８  オペレーティングシステム
１４４０  アプリケーションプログラム
１４４２  他のプログラムモジュール
１４４４  プログラムデータ
１４４６  キーボード
１４４８  ポインティングデバイス
１４５０  ユーザ入力インターフェース
１４５２  モニタ
１４５４  ビデオアダプタ
１４５５  出力周辺インターフェース
１４５７  ＬＡＮ
１４５８  モデム
１４５９  ＷＡＮ
１４６０  インターネット
１４６２  リモートコンピュータ
１４６６  ネットワーク
１４６９  リモートアプリケーション
【図１】
0004880152.tif 000016
【図２】
0004880152.tif 000017
【図３】
0004880152.tif 000018
【図４】
0004880152.tif 000019
【図５】
0004880152.tif 000020
【図６】
0004880152.tif 000021
【図７】
0004880152.tif 000022
【図８】
0004880152.tif 000023
【図９】
0004880152.tif 000024
【図１０】
0004880152.tif 000025
【図１１】
0004880152.tif 000026
【図１２】
0004880152.tif 000027
【図１３】
0004880152.tif 000028
【図１４】
0004880152.tif 000029