JP4866844B2 - Ｌｏｂに格納されたｘｍｌ内容の効率的な抽出 - Google Patents

Description

発明の分野
この発明は情報の管理に関するものであり、より具体的には、格納されたＸＭＬデータから、Ｘパス（ＸPath）経路式によって識別される有効な自立型ＸＭＬフラグメントを抽出することに関するものである。

背景
近年、拡張マークアップ言語データ（eXtensible Markup Language）（「ＸＭＬデータ」）の格納およびクエリを可能にするデータベースシステムが開発されてきた。ＸＭＬのクエリのための多くの発展する規格が存在するが、それらはすべてＸパスの何らかの変形を含む。Ｘパスは、文書の論理構造または階層を通る経路に基づいてアドレス指定構文を使用することによってＸＭＬ文書の中の項目を位置付け、処理する方法を記載する言語である。Ｘパス「経路式」によって識別されるＸＭＬ文書の部分とは、ＸＭＬ文書の構造内で、経路式と一致する任意の経路の終わりに存在する部分である。

リレーショナルデータベースサーバによって管理されるＸＭＬ文書は典型的には、構造化されていないシリアル化データとして、ＬＯＢ（ラージオブジェクト）データ型の何らかの形式で格納される。たとえば、ＸＭＬ文書は、ＣＬＯＢ（文字ＬＯＢ）またはＢＬＯＢ（バイナリＬＯＢ）などの構造化されていない記憶装置に格納される場合もあれば、文書はＯ−Ｒ（ＸＭＬスキーマを使用するオブジェクトリレーショナル構造）として格納される場合もある。

多くのＸパスクエリを満たすためにＸＭＬ文書がいかに格納されたとしても、Ｘパス経路式と一致する格納されたＸＭＬ文書のフラグメントを識別および抽出する方法は必要である。

残念ながら、ＸＭＬデータを格納するための組込サポートを有するデータベースシステムでさえ、通常は経路ベースのクエリの取扱用に最適化されることはなく、データベースシステムのクエリ性能は不備な点が多い。ＸＭＬスキーマ定義が利用可能であろう特定の場合には、ＸＭＬインスタンス文書で使用される構造およびデータ型は、Ｘパスクエリを最適化するために使用され得る。しかしながら、ＸＭＬスキーマ定義が利用可能ではなく、探索される文書がいかなるスキーマにも従わない場合には、経路ベースのクエリのための効率的な技術は存在しない。

ＸＭＬスキーマ定義が利用可能でないときに文書を照会する性能を向上させるために、すべての文書の全面的な走査またはテキストキーワードベースの索引のような特別なメカニズムが使用されてもよい。しかしながら、これらのメカニズムは、Ｘパス経路式と一致する格納されたＸＭＬ文書のフラグメントをすばやく識別および抽出する効率的な方法の必要性を満たさない。

格納されたＸＭＬデータのフラグメントの位置をすばやく識別する方法がたとえ利用可能であったとしても、識別された位置からフラグメントを効率的に抽出する方法は依然として必要である。識別された位置に存在するフラグメントは、有効な自立型ＸＭＬ文書ではないかもしれない。たとえば、フラグメント内で使用される名前空間接頭辞はそのフラグメントの外側で宣言されてもよく、したがって、識別された位置から検索されるフラグメントはすべての必要な宣言を持たないことになる。

上述に基づいて、Ｘパス経路式と一致する有効な自立型ＸＭＬフラグメントを識別および抽出するためのシステムならびに方法が明らかに必要である。

このセクションに記載されるアプローチは、追求され得るアプローチであるが、必ずしも以前に考えられたアプローチまたは追求されたアプローチではない。したがって、特に他に表示がない限り、このセクションに記載されるアプローチはいずれも、このセクションに包含されているという理由だけで先行技術としての資格があると想定されるべきではない。

この発明は限定としてではなく一例として添付図面の図に図示され、添付図面では同一の参照数字は同様の要素を指す。

詳細な説明
以下の説明には、説明の目的で、この発明を完全に理解できるようにするために多くの具体的な詳細が記載される。しかしながら、この発明はこれらの具体的な詳細がなくても実施され得ることは明白である。他の場合に、この発明を不必要に曖昧にすることを避けるために、周知の構造および装置はブロック図の形式で示される。

例示的なＸＭＬ文書
説明の目的で、以下の２つのＸＭＬ文書に関連して例が以下に挙げられる。

上述のように、ｐｏ１．ｘｍｌおよびｐｏ２．ｘｍｌは、ＸＭＬ文書の２つの例に過ぎない。本明細書に記載される技術は、任意の特定の型、構造または内容を有するＸＭＬ文書に限定されるものではない。このような文書がこの発明のさまざまな実施例に従っていかに索引付けされ、アクセスされることができるかということについての例が以下に挙げ
られる。

ＸＭＬ索引
２００４年７月２日に出願された「ＸＭＬデータにアクセスするための索引（INDEX FOR ACCESSING XML DATA）」と題される米国特許出願連続番号第１０／８８４，３１１号（以下「ＸＭＬ索引アプリケーション」）は、Ｘパスクエリに基づいて、リレーショナルデータベースサーバによって管理されるＸＭＬ文書に効率的にアクセスするために使用され得る索引のさまざまな実施例を記載する。このような索引は本明細書においてＸＭＬ索引と称される。

ＸＭＬ索引アプリケーションに記載されるＸＭＬ索引は、実際のＸＭＬデータを格納するために使用されるフォーマットおよびデータ構造（「ベース構造」）にかかわらずＸパスクエリを処理するために使用されることができる。たとえば、実際のＸＭＬデータは、ＣＬＯＢ（実際のＸＭＬテキストを格納する文字ＬＯＢ）、Ｏ−Ｒ（ＸＭＬスキーマが存在する状態でのオブジェクトリレーショナル構造化形式）、またはＢＬＯＢ（ＸＭＬデータの何らかのバイナリ形式を格納するバイナリＬＯＢ）などのいずれの形式でも、データベース内またはデータベースの外側の構造に存在することが可能である。

１つの実施例に従って、ＸＭＬ索引は、Ｘパスベースの述語および／またはＸパスベースのフラグメント抽出を含むクエリの性能を改善するドメイン索引である。たとえば、ＸＭＬ索引は、ＣＬＯＢまたは構造化記憶装置として格納されるＸＭＬスキーマベースの列およびスキーマのないＸＭＬ型の列の上に構築されることができる。１つの実施例では、ＸＭＬ索引は、経路索引、値索引および順序索引を協同使用することによって生じる論理索引である。

経路索引は、単純な（ナビゲーション）経路式に基づいてこのメカニズムをルックアップノードにもたらす。値索引は、値の同等性または範囲に基づいてルックアップをもたらす。複数の二次的な値索引がデータ型当たり１つ存在し得るであろう。順序索引は、索引付けされたノードに階層順序付け情報を関連付ける。順序索引は、ＸＭＬノード間の親子関係、上位−下位関係および兄弟関係を決定するために使用される。

ユーザがＸパスを伴うクエリを（述語またはフラグメント識別子として）実行依頼するとき、ＸパスステートメントはＸＭＬ索引テーブルにアクセスするＳＱＬクエリに分解される。生成されたクエリは典型的には、経路、値および順序制約付きのルックアップの組を実行し、その結果を適切に併合する。

説明の目的で、本明細書に記載される技術は、ＸＭＬ索引がＸＭＬ索引アプリケーションに記載されるようにＸＭＬ文書を索引付けするために使用される文脈で記載される。しかしながら、本明細書に記載される技術は、いかなる特定の索引構造またはメカニズムにも限定されるものではなく、クエリのどの方法が使用されるかにかかわらず有効な自立型ＸＭＬフラグメントを識別および抽出するために使用されることができる。

ＰＡＴＨ（経路）テーブル
１つの実施例に従って、論理ＸＭＬ索引はＰＡＴＨテーブルおよび二次索引の組を含む。上述のように、各々の索引付けされたＸＭＬ文書は多くの索引付けされたノードを含んでもよい。ＰＡＴＨテーブルは索引付けされたノード当たり１つの行を含む。各々の索引付けされたノードごとに、ノードについてのＰＡＴＨテーブルの中の行は、ノードに関連付けられたさまざまな情報を含む。

１つの実施例に従って、ＰＡＴＨテーブルに含まれる情報は、（１）ノードへの経路を
示すＰＡＴＨＩＤ（経路ＩＤ）、（２）ベース構造内でノードについてのフラグメントデータを位置付けるための「位置データ」、および（３）ノードを含むＸＭＬ文書の構造的階層内のノードの位置を示す「階層データ」を含む。任意に、ＰＡＴＨテーブルは、値に関連付けられるそれらのノードについての値情報も含んでもよい。これらのタイプの情報の各々は、以下により詳細に説明される。

経路
ＸＭＬ文書の構造は、ＸＭＬ文書内のノード間の親子関係を確立する。ＸＭＬ文書の中のノードの「経路」は、「ルート」ノードから始まり特定のノードに達する一連の親子リンクを反映する。たとえば、ｐｏ２．ｘｍｌの中の「User」ノードへの経路は、/PurchaseOrder/Actions/Action/Userである。なぜなら、「User」ノードは「Action」ノードの子であり、「Action」ノードは「Actions」ノードの子であり、「Actions」ノードは「PurchaseOrder」ノードの子であるためである。

ＸＭＬ索引が索引付けするＸＭＬ文書の組は本明細書において「索引付けされたＸＭＬ文書」と称される。１つの実施例に従って、ＸＭＬ索引は、索引付けされたＸＭＬ文書のすべての中の経路のすべて、または索引付けされたＸＭＬ文書の中の経路の一部に構築されてもよい。どの経路が索引付けされるかを指定するための技術が以下に説明される。特定のＸＭＬ索引によって索引付けされる経路の組は本明細書において「索引付けされたＸＭＬ経路」と称される。

ＰＡＴＨＩＤ
１つの実施例に従って、索引付けされたＸＭＬ経路の各々は、一意の経路識別子（「ＰＡＴＨＩＤ」）を割当てられる。たとえば、ｐｏ１．ｘｍｌおよびｐｏ２．ｘｍｌに存在する経路は、以下のテーブルに図示されるようにＰＡＴＨＩＤを割当てられてもよい。

経路を識別し、経路にＰＡＴＨＩＤを割当てるためにさまざまな技術が使用されることができる。たとえば、ユーザは経路を明示的に列挙し、このように識別された経路についての対応するＰＡＴＨＩＤを指定してもよい。代替的には、索引付けされたＸＭＬ文書の組に文書が加えられるときにデータベースサーバは各々のＸＭＬ文書をパーズしてもよい。パージング動作の間、データベースサーバは、既にＰＡＴＨＩＤを割当てられていないいずれの経路も識別し、それらの経路に新しいＰＡＴＨＩＤを自動的に割当てる。経路へのＰＡＴＨＩＤのマッピングはさまざまな方法でデータベース内に格納されてもよい。１つの実施例に従って、経路へのＰＡＴＨＩＤのマッピングは、ＸＭＬ索引自体から切り離されたメタデータとして格納される。

１つの実施例に従って、異なるスキーマに従うＸＭＬ文書のために同一のアクセス構造が使用される。索引付けされたＸＭＬ文書が異なるスキーマに従い得るので、各々のＸＭＬ文書は典型的には、ＰＡＴＨＩＤが割当てられた経路の一部のみを含むことになる。

位置データ
ノードに関連付けられる位置データは、（１）ノードを含むＸＭＬ文書がベース構造内のどこに存在するか、および（２）ノードに対応するＸＭＬフラグメントが、格納されたＸＭＬ文書内のどこに位置付けられるかを示す。したがって、位置データの性質はベース構造の性質に基づいて実現例ごとに異なることになる。位置情報は典型的には、ＸＭＬ文書がパーズされるときにＰＡＴＨテーブルに加えられる。

説明の目的で、（１）ベース構造はリレーショナルデータベース内のテーブルであり、（２）各々の索引付けされたＸＭＬ文書はベーステーブルの対応する行に格納されると仮定される。このような文脈では、ノードについての位置データはたとえば（１）ノードを含むＸＭＬ文書が格納されるベーステーブルの中の行の識別子（「ＲＩＤ」）と、（２）ノードに対応するフラグメントデータへの、格納されたＸＭＬ文書内での高速アクセスをもたらすロケータとを含み得る。

ロケータは概念上、元の文書を「指し示す」情報であり、典型的にはそのポイントから始まるフラグメントデータを検索するために使用される。ロケータは、ＸＭＬ文書のために使用される実際の記憶装置に依存し、記憶装置のＣＬＯＢ、Ｏ−ＲまたはＢＬＯＢ形式ごとに異なる可能性がある。たとえば、ＣＬＯＢに格納されるＸＭＬ文書の中のノードのロケータは、ノードが始まるＣＬＯＢ内の開始文字オフセットであり得るだろう。さらに、ノードのバイト長はロケータの一部として格納されてもよい。合わせて、この情報は格納されたＸＭＬ文書内の開始位置および終了位置をもたらし、ＸＭＬフラグメントを効率的に抽出するために使用されることができる。たとえば、ロケータは、データを抽出することによって、ロケータによって指定された文字オフセットから始めることによって、およびロケータによって示されたバイトの数についてのデータを読取ることによって、指定されたＸパスクエリと一致するノードを含むＸＭＬフラグメントを検索するために使用されてもよい。

しかしながら、ロケータは文字オフセットまたはバイトオフセットよりも複雑である可能性がある。たとえば、ロケータは特定のフラグを含み得るであろう。別の例として、リレーショナルテーブルに細断されたＸＭＬ文書が格納される場合、ロケータは適切なテーブルおよび／または行識別子などを含み得るであろう。

階層データ
ノードについてのＰＡＴＨテーブルの行は、ノードを含むＸＭＬ文書の階層構造内のどこにノードが存在するかを示す情報も含む。このような階層情報は本明細書においてノードの「OrderKey（順序キー）」と称される。

１つの実施例に従って、階層順序情報はデューイタイプ（Dewey-type）の値を使用して表わされる。具体的には、１つの実施例では、ノードのOrderKeyはノードの直接の親のOrderKeyに値を追加することによって作成され、ここで、追加される値はその特定の子ノードの、親ノードの子の中での位置を示す。

たとえば、特定のノードＤがノードＣの子であり、ノードＣ自体がノードＢの子であり、ノードＢがノードＡの子であると仮定されたい。さらに、ノードＤがOrderKey１．２．４．３．を有すると仮定されたい。OrderKeyの中の最後の「３」は、ノードＤがその親ノードＣの第３の子であることを示す。同様に、４は、ノードＣがノードＢの第４の子であることを示す。２は、ノードＢがノードＡの第２の子であることを示す。先頭の１は、ノードＡがルートノードである（つまり、親を持たない）ことを示す。

上述のように、子のOrderKeyは、子の数に対応する値を親のOrderKeyに追加することに
よって容易に作成されることができる。同様に、親のOrderKeyは、子のOrderKeyの中の最後の数を取除くことによって子のOrderKeyから容易に導き出される。

１つの実施例に従って、各々のOrderKeyによって表わされる合成数は、バイトに匹敵する値に変換され、そのため、２つのOrderKey間の数学的比較は、OrderKeyが対応するノードの、ＸＭＬ文書の構造的階層内での相対的な位置を示す。

たとえば、OrderKey１．２．７．７に関連付けられるノードは、ＸＭＬ文書の階層構造においてOrderKey１．３．１に関連付けられるノードに先行する。したがって、データベースサーバは、OrderKey１．２．７．７を第１の値に変換し、OrderKey１．３．１を第２の値に変換する変換メカニズムを使用し、ここで第１の値は第２の値未満である。第２の値を第１の値と比較することによって、第１の値に関連付けられるノードが第２の値に関連付けられるノードに先行することをデータベースサーバは容易に判断できる。この結果を達成するためにさまざまな変換技術が使用されてもよく、この発明は任意の特定の変換技術に限定されるものではない。

値情報
索引付けされた文書内のいくつかのノードは、属性ノードまたは単純要素に対応するノードであってもよい。本明細書において使用されるように、「単純要素」はいかなる属性または子要素も持たない要素であり、その値は単一のテキストストリングである。たとえば、「ｐｏ１．ｘｍｌ」では、「Reference」要素は「ＳＢＥＬＬ−２００２１００９１２３３３６０１ＰＤＴ」という単一のテキスト値を有する単純要素である。

１つの実施例に従って、属性ノードおよび単純要素のために、ＰＡＴＨテーブルの行は属性および単純要素の実際の値も格納する。このような値はたとえばＰＡＴＨテーブルの「値の列」に格納されてもよい。以下により詳細に説明される二次的な「値索引」は値の列に構築される。

ＰＡＴＨテーブルの例
１つの実施例に従って、ＰＡＴＨテーブルは以下のテーブルに指定されるように定義される列を含む。

上に説明されたように、ＰＡＴＨＩＤはノードに割当てられた識別子であり、ノードへの十分に拡張された経路を一意に表わす。ＯＲＤＥＲ＿ＫＥＹは、ノードに関連付けられ
るデューイ順序付け数のシステム表現である。１つの実施例に従って、OrderKeyの内部表現は文書の順序付けも保存する。

ＶＡＬＵＥの列は単純要素（つまり、子要素のない）ノードおよび属性ノードのために効果的なテキスト値を格納する。１つの実施例に従って、隣接するテキストノードは連結によって合体される。ＸＭＬ索引アプリケーションに記載されるように、索引作成中にオプションを指定することによってＶＡＬＵＥの列に格納される効果的なテキスト値をユーザがカスタマイズできるようにメカニズムが設けられ、たとえば混合テキスト、余白、大文字と小文字の区別などの動きがカスタマイズされることができる。ユーザは、有界のＲＡＷ列またはＢＬＯＢを含むいかなる数のフォーマットでもＶＡＬＵＥの列を格納できる。ユーザが有界の記憶装置を選択する場合、索引作成中のオーバーフローはいずれもエラーとしてフラグを立てられる。

以下のテーブルは、（１）上述の列を有し、（２）ｐｏ１．ｘｍｌおよびｐｏ２．ｘｍｌのための入力で埋められたＰＡＴＨテーブルの一例である。具体的には、ＰＡＴＨテーブルの各々の行はｐｏ１．ｘｍｌまたはｐｏ２．ｘｍｌの索引付けされたノードに対応する。この例では、ｐｏ１．ｘｍｌおよびｐｏ２．ｘｍｌはそれぞれにベーステーブルの行Ｒ１およびＲ２に格納されると仮定される。

この例では、rowid（行ｉｄ）の列は、ＰＡＴＨテーブルの各々の行ごとに一意の識別子を格納する。ＰＡＴＨテーブルが作成されるデータベースシステム次第で、rowidの列は暗黙の列である場合がある。たとえば、行のディスク位置はその行のための一意の識別子として使用されてもよい。以下により詳細に説明されるように、二次的な順序および値索引はＰＡＴＨテーブルのrowid値を使用して、ＰＡＴＨテーブル内に行を位置付ける。

上に示された実施例では、ノードのＰＡＴＨＩＤ、ＯＲＤＥＲ＿ＫＥＹおよびＶＡＬＵＥはすべて単一のテーブルに含まれる。代替的な実施例では、ＰＡＴＨＩＤ、ＯＲＤＥＲ＿ＫＥＹおよびＶＡＬＵＥの情報を対応する位置データ（たとえば、ベーステーブルＲＩＤおよびＬＯＣＡＴＯＲ）にマップするために別個のテーブルが使用されてもよい。

上に示された実施例では、ＰＡＴＨテーブルの「ＲＩＤ」および「ＬＯＣＡＴＯＲ」の列の中の情報は、索引付けされたノードが格納される位置を識別するために使用される。この例では、ベーステーブルの中の各々の行は索引付けされたＸＭＬ文書に対応する。ベーステーブルの中の各々の行はＣＬＯＢを使用して、関連付けられるＸＭＬ文書を格納する。ＰＡＴＨテーブルの中のＲＩＤの列は、ＸＭＬ文書がＣＬＯＢとして格納されるベーステーブルの中の行を識別し、ＬＯＣＡＴＯＲの列は、索引付けされたノードが始まるＣＬＯＢへの文字オフセットおよびノードのための文字長を格納する。

たとえば、上述のサンプルのＸＭＬ文書ｐｏ１．ｘｍｌおよびｐｏ１．ｘｍｌは、ＣＬＯＢデータ構造としてベーステーブルの行Ｒ１およびＲ２に、構造化されていないシリアル化形式で格納される。ＰＡＴＨテーブルの中でrowid「１」によって識別されるノードは、ベーステーブルの行Ｒ１に位置付けられ、格納されたＣＬＯＢの文字１から始まり、３５０文字の長さを有する。別の例として、rowid「９」によって識別されるノードは、ベーステーブルの行Ｒ２に位置付けられ、文字７２から始まり、３６文字の長さを有する。ＰＡＴＨテーブルのこの行は、以下に示されるｐｏ２．ｘｍｌの第１の＜Action＞ノードに対応する。

＜Action＞
＜User＞ZLOTKEY＜/User＞
＜/Action＞
上記の埋められたＰＡＴＨテーブルに示される例は、ロケータ情報が単純要素および属性ノードのために格納されない実施例を図示する。他の実施例では、ロケータ情報は、単純要素を含むすべてのノードのために格納および維持され得るであろう。さらに、埋められたＰＡＴＨテーブルに示される例は、ＬＯＣＡＴＯＲの列がオフセットおよび長さ情報の両方を格納する実施例を図示する。代替的な実施例では、オフセット情報のみが格納されてもよい。代替的には、上述のように、他のタイプのロケータ情報がＬＯＣＡＴＯＲの列に格納されてもよい。本明細書に記載される技術は、任意の特定のタイプの位置データに依存するものではない。

二次索引
ＰＡＴＨテーブルは、幅広い範囲のクエリを満たすＸＭＬ文書および／またはＸＭＬフラグメントを位置付けるのに必要な情報を含む。しかしながら、二次アクセス構造がなくても、このようなクエリを満たすためにＰＡＴＨテーブルを使用することにはしばしば、ＰＡＴＨテーブルの全面的な走査が必要となる。したがって、１つの実施例に従って、（１）経路ルックアップを実行し、および／または（２）順序ベースの関係を識別するクエリを加速するためにさまざまな二次索引がデータベースサーバによって作成される。１つの実施例に従って、以下の二次索引がＰＡＴＨテーブルで作成される。

・（ＰＡＴＨＩＤ，ＲＩＤ）上のＰＡＴＨＩＤ＿ＩＮＤＥＸ
・（ＲＩＤ，ＯＲＤＥＲ＿ＫＥＹ）上のＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ
・ＶＡＬＵＥ ＩＮＤＥＸＥＳ
・（ＲＩＤ，ＳＹＳ＿ＤＥＷＥＹ＿ＰＡＲＥＮＴ（ＯＲＤＥＲ＿ＫＥＹ））上のＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ

ＰＡＴＨＩＤ＿ＩＮＤＥＸ
ＰＡＴＨＩＤ＿ＩＮＤＥＸは、ＰＡＴＨテーブルのＰＡＴＨＩＤ、ＲＩＤの列に構築される。したがって、ＰＡＴＨＩＤ＿ＩＮＤＥＸへの入力は（キー値、rowid）の形式であり、ここでキー値は特定のＰＡＴＨＩＤ／ＲＩＤの組合せを表わす合成値であり、rowidはＰＡＴＨテーブルの特定の行を識別する。

（１）ベーステーブルの行および（２）ノードのＰＡＴＨＩＤが公知であるとき、ＰＡＴＨＩＤ＿ＩＮＤＥＸはそのノードについて、ＰＡＴＨテーブル内で行をすばやく位置付けるために使用されてもよい。たとえば、キー値「３．Ｒ１」に基づいて、ＰＡＴＨＩＤ＿ＩＮＤＥＸは、キー値「３．Ｒ１」に関連付けられる入力を見つけるために横断されてもよい。ＰＡＴＨテーブルが上に図示されたように埋められていると仮定すると、索引入力は３というrowid値を有するであろう。３というrowid値は、ＰＡＴＨテーブルの第３の行を指し、この第３の行はＰＡＴＨＩＤ３およびＲＩＤ Ｒ１に関連付けられるノードのための行である。

ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ
ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸは、ＰＡＴＨテーブルのＲＩＤおよびＯＲＤＥＲ＿ＫＥＹの列に構築される。したがって、ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸへの入力は（キー値、rowid）の形式であり、ここでキー値は特定のＲＩＤ／ＯＲＤＥＲ＿ＫＥＹの組合せを表わす合成値であり、rowidはＰＡＴＨテーブルの特定の行を識別する。

（１）ベーステーブルの行および（２）ノードのＯＲＤＥＲＫＥＹが公知であるとき、ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸはそのノードについて、ＰＡＴＨテーブル内で行をすばやく位置付けるために使用されてもよい。たとえば、キー値「Ｒ１．’１．２’」に基づいて、ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸは、キー値「Ｒ１．’１．２’」に関連付けられる入力を見つけるために横断されてもよい。ＰＡＴＨテーブルが上に図示されたように埋められていると仮定すると、索引入力は３というrowid値を有するであろう。３というrowid値は、ＰＡＴＨテーブルの第３の行を指し、この第３の行はＯＲＤＥＲＫＥＹ１．２およびＲＩＤ Ｒ１に関連付けられるノードのための行である。

値索引
経路ルックアップに基づくクエリがＰＡＴＨＩＤ＿ＩＮＤＥＸを使用して加速されることができるのとちょうど同じように、値ルックアップに基づくクエリはＰＡＴＨテーブルのＶＡＬＵＥの列に構築された索引によって加速されることができる。しかしながら、ＰＡＴＨテーブルのＶＡＬＵＥの列はさまざまなデータ型についての値を保持することができる。したがって、１つの実施例に従って、ＶＡＬＵＥの列に格納された各々のデータ型ごとに別個の値索引が構築される。このように、ＶＡＬＵＥの列がストリング、数およびタイムスタンプを保持する実現例では、以下の値（二次）索引も作成される。

・ＳＹＳ＿ＸＭＬＶＡＬＵＥ＿ＴＯ＿ＳＴＲＩＮＧ（value）上のＳＴＲＩＮＧ＿ＩＮＤＥＸ
・ＳＹＳ＿ＸＭＬＶＡＬＵＥ＿ＴＯ＿ＮＵＭＢＥＲ（value）上のＮＵＭＢＥＲ＿ＩＮＤＥＸ
・ＳＹＳ＿ＸＭＬＶＡＬＵＥ＿ＴＯ＿ＴＩＭＥＳＴＡＭＰ（value）上のＴＩＭＥＳＴＡＭＰ＿ＩＮＤＥＸ
これらの値索引は、データ型ベースの比較（同等性および範囲）を実行するために使用される。たとえば、ＮＵＭＢＥＲ値索引は、ユーザＸパス内で数ベースの比較を取扱うために使用される。たとえば、ＮＵＭＢＥＲ＿ＩＮＤＥＸへの入力は（数、rowid）の形式であってもよく、ここでrowidは「数」の値に関連付けられるノードのための、ＰＡＴＨテーブル内の行を指す。同様に、ＳＴＲＩＮＧ＿ＩＮＤＥＸ内の入力は（ストリング、rowid）の形式を有してもよく、ＴＩＭＥＳＴＡＭＰ＿ＩＮＤＥＸ内の入力は（タイムスタンプ、rowid）の形式を有してもよい。

ＰＡＴＨテーブルの中の値のフォーマットは、データ型の固有のフォーマットに対応しないかもしれない。したがって、値索引を使用するとき、データベースサーバは格納されたフォーマットから指定されたデータ型に値のバイトを変換するために変換機能を呼出し
てもよい。さらに、データベースサーバは、以下に記載されるように、任意の必要な変形を適用する。１つの実施例に従って、変換機能はＲＡＷおよびＢＬＯＢ値の両方で作動し、変換が可能でない場合にはヌルを返す。

デフォルトにより、ＸＭＬ索引が作成されるときに値索引が作成される。しかしながら、ユーザはクエリの作業量の知識に基づいて１つ以上の値索引の作成を抑えることができる。たとえば、すべてのＸパス述語がストリング比較のみを伴う場合、ＮＵＭＢＥＲおよびタイムスタンプ値索引は回避されることができる。

ＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ
１つの実施例に従って、ＰＡＴＨテーブルに構築される二次索引の組はＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸを含む。ＯＲＤＥＲ＿ＫＥＹ索引と同様に、ＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸは、ＰＡＴＨテーブルのＲＩＤおよびＯＲＤＥＲ＿ＫＥＹの列に構築される。結果として、ＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸの索引入力は（キー値、rowid）の形式を有し、ここでキー値は特定のＲＩＤ／ＯＲＤＥＲ＿ＫＥＹの組合せに対応する合成値である。しかしながら、ＯＲＤＥＲ＿ＫＥＹ索引とは異なって、ＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ入力におけるrowidは、特定のＲＩＤ／ＯＲＤＥＲ＿ＫＥＹの組合せを有するＰＡＴＨテーブルの行を指さない。それどころか、各々のＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ入力のrowidは、ＲＩＤ／ＯＲＤＥＲ＿ＫＥＹの組合せに関連付けられるノードの直接の親であるノードのＰＡＴＨテーブルの行を指す。

たとえば、上に図示された埋められたＰＡＴＨテーブルでは、ＲＩＤ／ＯＲＤＥＲ＿ＫＥＹの組合せ「Ｒ１．’１．２’」は、ＰＡＴＨテーブルの行３の中のノードに対応する。ＰＡＴＨテーブルの行３の中のノードの直接の親は、ＰＡＴＨテーブルの行１によって表わされるノードである。結果として、「Ｒ１．’１．２’」のキー値に関連付けられるＰＡＲＥＮＴ＿ＯＲＤＥＲＫＥＹ＿ＩＮＤＥＸ入力は、ＰＡＴＨテーブルの行１を指すrowidを有するであろう（つまり、rowid＝１）。

ＸＭＬ索引を使用してＸパスクエリを処理する
上述のように、ＸＭＬ索引は、ＸＭＬ文書の必須部分、つまりタグ、値および入れ子情報をＰＡＴＨ、ＶＡＬＵＥおよびＯＲＤＥＲ索引に取込むことによってＸパスベースのクエリならびにフラグメント抽出の性能を改善する。ＰＡＴＨ索引は、タグを索引付けするために使用され、単純な経路式に基づいてフラグメントを識別するためにメカニズムを与える。ＶＡＬＵＥ索引は、ＸＭＬ値が索引付けされることを可能にする。ＯＲＤＥＲ索引は、索引付けされたノードに階層順序付け情報を関連付け、ＸＭＬノード間の親子関係、上位−下位関係および兄弟関係を決定するために使用される。

ユーザがＸパスを伴うクエリを実行依頼するとき、Ｘパス式はＸＭＬ索引テーブルにアクセスするＳＱＬクエリに分解され得る。生成されたクエリは典型的には、経路、値および順序制約付きルックアップの組を実行し、その結果を適切に併合する。

特に、２００４年９月１６日に出願された「ＸＭＬ索引を使用したＸＭＬデータの効率的なクエリ処理（EFFICIENT QUERY PROCESSING OF XML DATA USING XML INDEX）と題される同時継続出願米国特許出願連続番号第１０／９４４，１７０号（以下「クエリ処理」アプリケーション）は、指定された経路に対応するＸＭＬデータを識別するためにＸＭＬ索引を使用する、「索引がイネーブルにされた」クエリを実行するための方法のさまざまな実施例を記載する。特に、クエリ処理アプリケーションは、ＸＭＬ索引を使用してＸパス演算子を評価するための技術を記載する。

より具体的には、クエリ処理アプリケーションは、（１）総称的な経路式を単純な経路、述語および構造結合などのより単純な構成要素に分解するため、（２）索引付けされた経路構成要素のデューイ順序キーでＳＱＬ述語を使用して構造結合を表わすことを伴い得るＳＱＬクエリをＸＭＬ索引のテーブルに対して生成するため、および（３）元のデータを指すロケータを使用したフラグメント抽出のための技術を記載する。

索引がイネーブルにされたクエリは、経路式に基づいて生成され、ＸＭＬ索引のＰＡＴＨテーブルにアクセスする。経路ベースのクエリの経路式またはそのフラグメントは、テンプレートと組み合わされる。各々のテンプレートは規則に関連付けられる。指定された経路のフラグメントがテンプレートと一致するフォーマットであるとき、対応する規則は索引がイネーブルにされたクエリについてのＳＱＬを生成するために使用される。このプロセスは、クエリ処理アプリケーションに詳細に記載される。

ＸＭＬ索引を使用してextract（）演算子を処理する
クエリ処理アプリケーションに記載される技術を使用して評価され得る１つのＸパス演算子は、extract（）演算子である。Ｘパスextract（）演算子の結果は、指定されたＸパス式を満たすＸＭＬ文書のＸＭＬフラグメントを含むＸＭＬ型である。

クエリ処理アプリケーションに記載されるように、extract（）演算子はＸＭＬ索引テーブルにＳＱＬクエリとして再書込されることができる。たとえば、/PurchaseOrder/ActionsノードでのＸパスクエリのためのextract（）演算子は、以下のようにＳＱＬクエリに翻訳されてもよい。

ここで、：Ｂ１＝pathid（‘/PurchaseOrder/Actions’）であり（pathid（）は、当該経路に関連付けられるＰＡＴＨＩＤを探すために使用される内部機能であり）、po＿tabは格納されたＸＭＬ文書を含むベーステーブルである。

ＳＹＳ＿ＸＭＬＩＮＤＥＸ＿ＭＫＸＭＬ（）演算子は、索引列の値に基づいてＸＭＬ型イメージを構築する。１つの実施例では、このルックアップはＳＹＳ＿ＸＭＬＩＮＤＥＸ＿ＧＥＴＦＲＡＧ（）演算子を使用して実現されてもよい。行識別子およびロケータを与えられると、ＳＹＳ＿ＸＭＬＩＮＤＥＸ＿ＧＥＴＦＲＡＧ（）演算子は、行識別子およびロケータに対応するＸＭＬフラグメントからなるＸＭＬ型イメージを構成する。

ＸＭＬＡＧＧ（）は、ＳＹＳ＿ＸＭＬＩＮＤＥＸ＿ＭＫＸＭＬ（）演算子によって生成されたフラグメントを連結する演算子である。上記の例を使用して、ノード‘/PurchaseOrder/Actions’を含む各々の行ごとに、フラグメントはベーステーブルから検索され、単一のＸＭＬ型イメージに集約される。

たとえば、上記の埋められたＰＡＴＨテーブルを使用して、

の出力は、

になるだろう。１つの実施例では、返される出力は、開始タグおよび終了タグを含む、上記の結果を連結することによって作成される単一の長いストリングである。

本明細書に記載される技術は、ノードに対応する実際のテキストフラグメントを得るＳＹＳ＿ＸＭＬＩＮＤＥＸ＿ＧＥＴＦＲＡＧ（）演算子を実現するために使用される。

効率的な抽出プロセス
図２に示されるプロセス２００は、この発明の実施例に従ってＸＭＬフラグメントを抽出するための１つの技術のステップを図示する。示されるように、ステップ２１０において、ノードが最初に識別される。ＸＭＬ索引およびクエリ処理アプリケーションに記載される技術などの技術はいずれも、経路式と一致するノードを識別するために使用されることができる。

次に、ステップ２１５において、ノードが単純要素であるかまたは複合要素であるかを判断するためにノードが調べられる。上述のように、単純要素は子または属性を持たない要素であり、その値は単一のテキスト値である。複合要素は属性を有するかまたは子要素を有する要素である。

ノードが単純要素である場合、ステップ２２０によって示されるように、ＸＭＬ索引に格納された情報を使用して、元のＸＭＬ文書を調査することなくフラグメントが構成されることができる。ノードが複合要素である場合、ステップ２３０によって示されるように、ベーステーブルに格納された元のＸＭＬ文書がフラグメントを抽出するために調査され、抽出されたフラグメントは適切な解釈のために必要に応じてパッチされる。各々のプロセスは以下により詳細に説明される。

図２に示されるプロセスの実施例は、元のＸＭＬ文書を調査することなくフラグメントを構成するために、ＸＭＬ索引に格納された情報を利用するが、単純要素および複合要素が異なったように扱われることは要件ではない。単純要素または複合要素のいずれの型とも一致するフラグメントが、格納されたＸＭＬデータから抽出されることが可能である。

単純要素フラグメント
格納されたＸＭＬ文書がＸＭＬ索引で索引付けされるとき、単純要素の値はＰＡＴＨテーブルのＶＡＬＵＥの列に存在する。したがって、単純要素についてのＸＭＬフラグメントは元のＸＭＬ文書を格納するベーステーブルを調査することなく構成されることができる。フラグメントは、識別されたノードについてのＰＡＴＨテーブルのＶＡＬＵＥの列から得られる値に、適切な開始タグおよび終了タグを加えることによって構築される。

たとえば、ノード‘/PurchaseOrder/Reference’は、上記のＸＭＬ文書ｐｏ１．ｘｍｌ
およびｐｏ２．ｘｍｌの中の単純要素である。式‘/PurchaseOrder/Reference’のＰＡＴＨＩＤが最初に求められる。この例では、ＰＡＴＨＩＤは「２」である。いずれかのノードがこのＰＡＴＨＩＤに対応するかどうかを判断するためにＰＡＴＨテーブルが調べられる（ステップ２１０）。この例では、「２」および「７」というrowidを有するノードが、ＰＡＴＨＩＤ＝２と一致する。図２のプロセスは各々の一致するノードごとに実行される。

ステップ２１５において、ノード２およびノード７の両方について、ロケータ情報がなく、ＶＡＬＵＥの列が単純なテキストストリングを含むとき、これらの行についてのＬＯＣＡＴＯＲおよびＶＡＬＵＥの列を調べることによって各々が単純要素であることが判断されることができる。これらの単純要素のノードの各々ごとに、プロセスはステップ２２０に進む。ステップ２２０では、ノードについてのフラグメントは、開始タグ、値および終了タグを含むストリングを作成することによって構築されることができる。開始タグは、このＰＡＴＨＩＤに関連付けられる経路の最後の構成要素（この例では「Reference」）を抽出することによって作成される。ＰＡＴＨテーブルの中でこのノードに対応するＶＡＬＵＥは、開始タグの後のフラグメントに入れられる。たとえば、ノード２についてのフラグメントのＶＡＬＵＥの構成要素は、「ＳＢＥＬＬ−２００２１００９１２３３３６０１ＰＤＴ」である。むすびの文字「／」および上で判断された構成要素のストリング（たとえば、「Reference」）からなるむすびのタグは、フラグメントのストリングを完全なものにする。このプロセスを辿ることによって、ノード２のフラグメントは「＜Reference＞ＳＢＥＬＬ−２００２１００９１２３３３６０１ＰＤＴ＜/Reference＞」であると決定される。これは、このノードに対応する元のＸＭＬ文書ｐｏ１．ｘｍｌのフラグメントと一致する。

属性のみを抽出するクエリは、単純要素と同様に扱われることができる。しかしながら、属性を含む要素は、以下により詳細に記載される複合要素として扱われる。

システムが名前空間および生成された接頭辞を加えることができるので、単純要素は適切な解釈のためにパッチングを必要とせず、プロセスは単純要素のためのステップ２９０に進む。

ＸＭＬ索引を使用して複合要素を抽出する
複合要素のノードの場合、フラグメントは、複合要素に関連付けられたＸＭＬ文書を格納するベーステーブルからパーズされなければならない。上述のように、ＰＡＴＨテーブルにおける各々の行は、ＸＭＬ文書におけるノードに対応し、元のＸＭＬ文書を含むベーステーブルにおける行のＲＩＤと、ベーステーブルに格納されたＸＭＬ文書内でノードを見つけるためのロケータとを含む。

たとえば、ノード/PurchaseOrder/Reference/ActionsでのＸパスextract（）は、集約されたフラグメントをもたらすはずである。

しかしながら、上述の単純要素とは異なって、これらのフラグメントは格納されたＸＭＬ文書から抽出される。たとえば、経路式「/PurchaseOrder/Reference/Actions」はＰＡＴＨＩＤ３に対応する。ＰＡＴＨテーブルから、rowid３および８を有するノードがこのＰＡＴＨＩＤと一致する。これらの行のＶＡＬＵＥの列は空いており、ＬＯＣＡＴＯＲの列はフラグメントを抽出するためのオフセットおよび長さの情報をもたらす。したがって、ステップ２１５において、これらのノードの各々が複合要素に対応することが判断され、プロセスはステップ２３０に進む。

ステップ２３０において、ノードに対応するフラグメントテキストが位置付けられ、読取られる。たとえばノード３について、ＲＩＤの列は、格納されたＸＭＬデータがベーステーブルの行Ｒ１に位置付けられることを示し、ＬＯＣＡＴＯＲフィールドは、フラグメントが文字６４から始まり、５６という長さを有することを示す。したがって、ノード３に対応するフラグメントテキストは、「ｐｏ１．ｘｍｌ」を含むベーステーブルの行Ｒ１においてＣＬＯＢから文字６４−１２０を抽出することによって作成されることができる。ノード８に対応するＸＭＬフラグメントは同様に、「ｐｏ２．ｘｍｌ」を含むベーステーブルの行Ｒ２においてＣＬＯＢから文字６３−１５２を抽出することによって作成されることができる。

これらの例では、抽出されたＸＭＬフラグメントは偶然有効である。しかしながら、多くの場合、これらの方法を使用して抽出されたＸＭＬフラグメントは自立型でないかもしれない。たとえば、抽出されたフラグメントはフラグメント内に定義されない参照を含むまたは使用する場合がある。本明細書に記載される方法は、結果として生じるフラグメントが確実に有効でありかつ自立型であるように、上記の技術を使用して作成されたフラグメントを「パッチする」ことを可能にする。

接頭辞および名前空間
ＸＭＬにおける要素名が固定されないので、２つの異なる文書が２つの異なるタイプの要素を表わす同一の名前を使用するときには名前の衝突が起こり得る。名前の衝突を回避する１つの標準的な方法は、名前とともに接頭辞を使用するというものである。

たとえば、表１および表２は、両方が「表」要素を使用するＸＭＬ文書を図示する。

これら２つのＸＭＬ文書が両方データベースに格納される場合、場合によっては要素名の衝突が存在し得るであろう。なぜなら、両方の文書が異なる内容および定義を有する＜table＞要素を含むためである。これらのタイプの衝突を解決し、防止する１つの標準的な方法は、名前空間接頭辞の使用によるものである。一例として、以下の表１Ａおよび表２Ａは、要素名の衝突を回避するために表１および表２のＸＭＬ文書がいかに修正され得るかを図示する。

表１Ａおよび表２Ａに示されるように、要素名の衝突はもはや問題ではない。なぜなら、２つの文書が＜table＞要素について異なる名前（つまり、＜ｈ：table＞および＜ｆ：ｔable＞）を使用するためである。接頭辞を使用することによって、２つの異なるタイプの＜table＞要素が可能である。

接頭辞は典型的には、要素についての情報を担持するＸＭＬ文書を参照する。表１Ｂおよび表２Ｂは、特定の名前空間を参照するために接頭辞がいかに定義され得るかを示す。

名前空間に関連付けられる修飾名を要素の接頭辞に与えるために、接頭辞のみを使用する代わりに、xmlns属性が＜table＞タグに加えられた。典型的には、名前空間属性は以下の構文を用いて要素の開始タグに置かれる。

xmlns：namespace−prefix＝“namespace”
表１Ｂおよび表２Ｂによって示されるように、定型資源識別子（ＵＲＩ）が使用されることができるが、名前空間自体はインターネットアドレスを使用して定義されることができる。複数の名前空間接頭辞が単一要素の属性として宣言されることができる。

名前空間が要素の開始タグにおいて属性として定義されるとき、同一の接頭辞を有するすべての子要素は同一の名前空間に関連付けられる。さらに、表１Ｃおよび表２Ｃに示されるように、デフォルトの名前空間が要素のために使用されることができる。デフォルトの名前空間が使用されるとき、接頭辞はすべての子要素で使用される必要はない。デフォルトの名前空間宣言は、その範囲内のすべての接頭辞が付いていない要素名に当てはまる。

接頭辞は修飾名の名前空間接頭辞部分をもたらし、名前空間宣言の際に名前空間の参照に関連付けられなければならない。接頭辞は、名前空間名のためのプレースホルダとしてのみ機能する。接頭辞ではなく名前空間名は、含んでいる文書を超えて範囲が広がる名前を構成する際に使用される。接頭辞および名前空間の宣言は、属性および要素に当てはまり得る。

接頭辞を宣言する名前空間宣言の範囲は、現れる開始タグの初めから、対応する終了タグの終わりまで広がり、同一の接頭辞名を使用するいずれの内部宣言の範囲も排除する。このような名前空間宣言は、宣言に指定された接頭辞が一致する範囲内のすべての要素および属性の名前に当てはまる。

名前空間接頭辞は、接頭辞が使用される要素の開始タグまたは上位要素の中の名前空間宣言の属性において宣言されたに違いにない。この制約は、名前空間宣言の属性がＸＭＬ文書に直接にもたらされるのではなく、外部エンティティにおいて宣言されたデフォルトの属性を介してもたらされる場合に、問題を招くおそれがある。

これは特にフラグメント抽出の文脈で問題がある。外部文書での宣言が問題であるだけでなく、抽出されたＸＭＬフラグメントが、フラグメントが抽出される文書の、より以前のセクションにおいて宣言された接頭辞を使用する可能性がある。さらに、抽出されたフラグメントがいかなる名前空間にも直接的な参照を持たないので、その上で有効であるフラグメントが抽出されるかもしれないが、抽出されたフラグメントは、上位要素の範囲内にある場合には、上位のデフォルトの名前空間宣言を使用すべきである。

本明細書に記載される技術は、所望のノードおよびすべてのその上位からの名前空間宣言のリストを構築することによってこの問題を解決する。このリストは、ＰＡＴＨテーブルを照会することによって構築される。このリストは次いで、完全で有効な自立型ＸＭＬフラグメントを得るために、ステップ２３０において作成されたフラグメントに継ぎ合わされる。

フラグメント抽出における名前空間宣言の取扱
上述のように、Ｘパスextract（）演算子が単純要素に対して評価されるとき、所望のフラグメントはＰＡＴＨテーブルのみを使用して構成されることができる。複合要素が抽出されるときには、フラグメントはＰＡＴＨテーブルからの位置情報を使用して元のデータから読取られる。しかしながら、抽出されたＸＭＬフラグメントにおいて接頭辞が使用されるとき、抽出されたフラグメントは接頭辞も説明しなければならない。さらに、抽出されるノードの上位要素において使用されるデフォルトの名前空間宣言はいずれも考慮されなければならない。

たとえば、表３において例示的なＸＭＬ文書「ｐｏ３．ｘｍｌ」を考慮されたい。

Ｘパスクエリ「extract（/po:purchaseOrder/po:lineItem/myns:SomeOtherTag）」が上述のプロセスのみを使用して評価される場合、このクエリによって返される結果として生じるフラグメントは表３のライン１０１−１０４から成るであろう。しかしながら、このＸＭＬフラグメントは名前空間接頭辞「ｐｏ」を参照し、この名前空間接頭辞「ｐｏ」はロケータ情報に従って抽出されるフラグメント（つまり、ライン１０１−１０４）の中のどこにも定義されない。その代わりに、この接頭辞は宣言され、表１のライン１の中の名前空間「ｐｏ．ｘｓｄ」にマップされる。

宣言「xmlns：ｐｏ＝″ｐｏ．ｘｓｄ″」は、適切に解釈されるフラグメント、つまり「自立型である」フラグメントのためにステップ２３０において順番に作成されるフラグメントに継ぎ合わされる必要がある。

１つの実施例では、名前空間宣言はロケータ自体の中に維持されることができる。しかしながら、この情報はあらゆるレベルに存在するであろう。好ましい実施例では、宣言情報はＰＡＴＨテーブルに格納された情報を使用して構築される。この実施例では、抽出されているノードのすべての上位ノードを識別するためにＳＱＬクエリが使用され、名前空間宣言は上位ノードから集められる。さらに、本明細書に記載される技術は、前に記載されたＸＭＬ名前空間スコーピング規則に準拠するように、正確に、つまり、より深い宣言が浅い宣言に優先する状態で逆の順序で名前空間宣言を解く。

図２におけるステップ２４０によって示されるように、ノードの上位が識別される。ＸＭＬ索引が使用される場合、上位情報がOrderKeyを使用して格納されるので、これは単純なクエリである。ステップ２５０において、ＸＭＬフラグメントの適切な解釈に必要な情報が各々の識別された上位ごとに検索される。フラグメントの適切な解釈に必要な、上位
から検索された任意の宣言または他の情報が存在する場合、ステップ２８０において、この情報はフラグメントにパッチされる。たとえば、フラグメントの中で使用されるが定義されないいずれの接頭辞のための名前空間宣言も、最も近い上位ノードから検索され、ステップ２３０において作成されたフラグメントにパッチされる。

たとえば、名前空間宣言を集め、それらを正確に解くためにすべての上位ノードを調べるように以下のＳＱＬクエリが使用され得るであろう。（：Ｂ１＝考慮されている文書のＲＩＤ、：Ｂ２＝抽出されるノードのOrderKey）

示されるように、外側のサブクエリは所与の文書においてすべての名前空間宣言を選択する。各々のこのような宣言ごとに、宣言が上位要素に存在するかどうかをexists（）サブクエリが判断する。

スコーピング規則を正確に説明するために、上位要素に存在する宣言は下位にも存在し、下位が親の宣言に優先するのでその宣言は無視されるはずである。さらに、親要素に存在する宣言は孫要素における宣言に優先するなどである。適切な順序で各々の上位を考慮し、スコーピング規則を説明することによって、フラグメントに加えられる必要のある宣言のリストがステップ２５０において作成される。スコーピング規則を説明するために、上位ノードは最も近いものから最も離れたものまで考慮される。各々の宣言が上位の中に見つけられるとき、宣言がフラグメント自体の一部としてまたはより以前の上位ノードにおいて既に考慮されていた場合には、それは無視される。そうでなければ、宣言は、フラグメントにパッチされるストリングに加えられる。

たとえば、表３の中のノードの以下のＸパスクエリを考慮されたい。
extract（‘/po:purchaseOrder/po:lineItem/myns:SomeOtherTag’）
ステップ２３０において表３から抽出されるフラグメントは以下のとおりである。

接頭辞「ｐｏ」はこのフラグメントでは定義されない。
このフラグメントの上位がステップ２５０において考慮されるとき、定義の以下のリストが作成される。

ステップ２８０において定義のリストの中でフラグメントに継ぎ合わされた後、結果として生じるフラグメントは以下のとおりである。

この例示的なフラグメントを自立型のフラグメントにするために宣言xmlns：ｐｓ２＝"ｐｏ２．ｘｓｄ"は必要とされないが、そこに含まれているものはフラグメントを無効にすることなく、またはフラグメントの意味を変更することはない。代替的な実施例では、宣言がフラグメントにパッチされる前に、抽出されているノードに宣言が必要であるかどうかを判断するために宣言が調べられる。

適切な解釈に必要なすべての情報を含む、ステップ２８０において作成された自立型のフラグメントは次いで、ステップ２９０において返される。

本明細書に記載される技術は名前空間宣言および接頭辞の文脈で記載されてきたが、この技術は他の状況で使用されることが可能である。たとえば、エンティティまたはマクロ参照の存在はフラグメントの自立型の性質を同様に複雑にする。名前空間と同様に、いずれのエンティティ参照もＤＴＤ（データ型定義）宣言とともに最初に付加される必要があるので、ＣＬＯＢオフセットによって識別されたフラグメントは簡単に流出されることができない。

ハードウェアの概観
図１は、この発明の実施例が実現され得るコンピュータシステム１００を図示するブロック図である。コンピュータシステム１００は、バス１０２または情報を通信するための他の通信メカニズムと、バス１０２に結合され情報を処理するためのプロセッサ１０４とを含む。コンピュータシステム１００は、バス１０２に結合され情報およびプロセッサ１０４によって実行される命令を格納するための、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１０６も含む。メインメモリ１０６は、プロセッサ１０４によって実行される命令の実行中に一時的な変数または他の中間情報を格納するためにも使用されてもよい。コンピュータシステム１００はさらに、バス１０２に結合されプロセッサ１０４のための静的情報および命令を格納するためのリードオンリメモリ（ＲＯＭ）１０８または他の静的記憶装置を含む。情報および命令を格納するために、磁気ディスクまたは光学ディスクなどの記憶装置１１０が設けられ、バス１０２に結合される。

コンピュータシステム１００は、コンピュータユーザに情報を表示するための陰極線管（ＣＲＴ）などのディスプレイ１１２に、バス１０２を介して結合されてもよい。英数字および他のキーを含む入力装置１１４は、プロセッサ１０４に情報およびコマンド選択を伝えるためにバス１０２に結合される。ユーザ入力装置の別のタイプは、プロセッサ１０４に方向情報およびコマンド選択を伝えるため、およびディスプレイ１１２でカーソルの動きを制御するための、マウス、トラックボールまたはカーソル方向キーなどのカーソル制御装置１１６である。この入力装置は典型的には、２つの軸、つまり第１の軸（たとえ
ば、ｘ）および第２の軸（たとえば、ｙ）において２つの自由度を有し、これによって、装置が平面で位置を指定できる。

この発明は、本明細書に記載される技術を実現するためのコンピュータシステム１００の使用に関するものである。この発明の１つの実施例に従って、それらの技術は、メインメモリ１０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行するプロセッサ１０４に応答して、コンピュータシステム１００によって実行される。このような命令は、記憶装置１１０などの別の機械可読媒体からメインメモリ１０６に読込まれてもよい。メインメモリ１０６に含まれる命令のシーケンスの実行は、本明細書に記載されるプロセスステップをプロセッサ１０４に実行させる。代替的な実施例では、この発明を実現するために、ソフトウェア命令の代わりにまたはソフトウェア命令と組合せられて、ハードワイヤード回路が使用されてもよい。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアの任意の特定の組合せに限定されるものではない。

本明細書において使用される「機械可読媒体」という用語は、特定の態様で機械に動作させるデータを与えることに関与する任意の媒体を指す。コンピュータシステム１００を使用して実現される実施例では、さまざまな機械可読媒体はたとえば実行のためにプロセッサ１０４に命令を与えることにかかわる。このような媒体は、不揮発性媒体、揮発性媒体および伝達媒体を含むがそれらに限定されない多くの形態を取ってもよい。不揮発性媒体はたとえば、記憶装置１１０などの光学ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ１０６などの動的メモリを含む。伝達媒体は、バス１０２を含む線などの同軸ケーブル、銅線および光ファイバを含む。伝達媒体は、電波および赤外線データ通信中に生成される波などの音波または光波の形態も取り得る。

機械可読媒体の一般的な形態はたとえばフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、もしくは他の磁気媒体、ＣＤ−ＲＯＭ、他の光学媒体、パンチカード、紙テープ、孔のパターンを有する他の物理的な媒体、ＲＡＭ、ＰＲＯＭおよびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、他のメモリチップもしくはカートリッジ、以下に記載される搬送波、またはコンピュータが読取ることのできる他の媒体を含む。

機械可読媒体のさまざまな形態は、実行のためにプロセッサ１０４に１つ以上の命令の１つ以上のシーケンスを搬送することにかかわってもよい。たとえば、命令は最初にリモートコンピュータの磁気ディスクで搬送されてもよい。リモートコンピュータはその動的メモリに命令をロードすることができ、モデムを使用して電話線によってその命令を送ることができる。コンピュータシステム１００にローカルなモデムは、電話線に沿ってデータを受取ることができ、データを赤外線信号に変換するために赤外線送信機を使用することができる。赤外線検出器は、赤外線信号の状態で搬送されたデータを受取ることができ、適切な回路はバス１０２にデータを置くことができる。バス１０２はメインメモリ１０６にデータを搬送し、メインメモリ１０６からプロセッサ１０４は命令を検索し、実行する。メインメモリ１０６によって受取られた命令は、プロセッサ１０４による実行の前または後に任意に記憶装置１１０に格納されてもよい。

コンピュータシステム１００は、バス１０２に結合された通信インターフェイス１１８も含む。通信インターフェイス１１８は、ローカルネットワーク１２２に接続されるネットワークリンク１２０への２方向のデータ通信結合をもたらす。たとえば、通信インターフェイス１１８は、対応するタイプの電話線へのデータ通信接続をもたらすために、統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであってもよい。別の例として、通信インターフェイス１１８は、互換性のあるローカルエリアネットワーク（ＬＡＮ）へのデータ通信接続をもたらすために、ＬＡＮカードであってもよい。ワイヤレスリンクも実
現されてもよい。いかなるこのような実現例においても、通信インターフェイス１１８は、さまざまなタイプの情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号または光信号を送受信する。

ネットワークリンク１２０は典型的には、１つ以上のネットワークを介して他のデータ装置へのデータ通信をもたらす。たとえば、ネットワークリンク１２０は、ローカルネットワーク１２２を介してホストコンピュータ１２４への接続をもたらす場合もあれば、インターネットサービスプロバイダ（ＩＳＰ）１２６によって動作されるデータ機器への接続をもたらす場合もある。ＩＳＰ１２６は次いで、現在一般に「インターネット」１２８と称されるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスをもたらす。ローカルネットワーク１２２およびインターネット１２８は両方、デジタルデータストリームを搬送する電気信号、電磁信号または光信号を使用する。さまざまなネットワークを介する信号、ならびにコンピュータシステム１００へおよびコンピュータシステム１００からデジタルデータを搬送する、ネットワーク１２０に沿って通信インターフェイス１１８を介する信号は、情報を伝える搬送波の例示的な形態である。

コンピュータシステム１００は、ネットワーク、ネットワークリンク１２０および通信インターフェイス１１８を介してメッセージを送ることができ、プログラムコードを含むデータを受取ることができる。インターネットの例では、サーバ１３０はインターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターフェイス１１８を介して、アプリケーションプログラムのために要求されたコードを伝えるかもしれない。

受取られたコードは受取られたときにプロセッサ１０４によって実行されてもよく、および／または後の実行のために記憶装置１１０もしくは他の不揮発性記憶装置に格納されてもよい。この態様で、コンピュータシステム１００は搬送波の形態でアプリケーションコードを得ることができる。

上記の明細書では、この発明の実施例は実現例ごとに異なる可能性のある多くの具体的な詳細を参照しながら記載されてきた。したがって、何がこの発明であるかおよび出願人によって何がこの発明であるように意図されるかは、このような特許請求の範囲が発行する具体的な形で、本出願から発行される特許請求の範囲の組に単独で排他的に示され、いかなるその後の修正も含む。このような特許請求の範囲に含まれる用語について本明細書に明白に記載される定義はいずれも、特許請求の範囲の中で使用される用語の意味を決定する。したがって、特許請求の範囲に明白に記載されない限定、要素、特性、特徴、利点または属性はいかなる方法でもこのような特許請求の範囲を限定すべきではない。したがって、明細書および図面は限定的な意味ではなく例示的な意味で考えられるべきである。

本明細書に記載される技術が実現され得るシステムのブロック図である。 要求に応答して自立型ＸＭＬフラグメントを効率的に与えるためのステップを図示するフローチャートである。

Claims (13)

1. データベース管理システムによって管理されるＸＭＬ文書の中でノードについての自立型ＸＭＬフラグメントを与えるための方法であって、
   ＸＭＬフラグメントの要求を受取る、コンピュータによって実現されるステップを含み、要求はＸＭＬ経路式を含み、前記方法はさらに、
   データベース管理システムによって管理されるＸＭＬ文書の中で、ＸＭＬ経路式と一致するノードを識別する、コンピュータによって実現されるステップと、
   識別されたノードに対応するＸＭＬフラグメントを抽出する、コンピュータによって実現されるステップとを含み、ＸＭＬフラグメントは自立型ではなく、前記方法はさらに、
   ＸＭＬフラグメントの適切な解釈に必要な情報を含む前記ノードの１つ以上の上位ノードを識別する、コンピュータによって実現されるステップを含み、必要な情報は、ＸＭＬフラグメントによって使用されるがＸＭＬフラグメント内に定義されない参照を含み、前記方法はさらに、
   必要な情報をＸＭＬフラグメントに挿入することによって自立型ＸＭＬフラグメントを構築するようにＸＭＬフラグメントをパッチする、コンピュータによって実現されるステップと、
   要求に応答して自立型ＸＭＬフラグメントを与える、コンピュータによって実現されるステップとを含む、方法。
2. データベース管理システムは、データベース管理システムに格納されたＸＭＬ文書を索引付けする索引を含み、ＸＭＬ文書の中でノードを識別するステップは、ノードを識別するために索引を使用することを含む、請求項１に記載の方法。
3. 索引は、経路、値および順序索引を含む、請求項２に記載の方法。
4. 第１のＸＭＬフラグメントを抽出するステップは、
   識別されたノードに対応する格納されたＸＭＬデータの位置を判断することと、
   判断された位置からＸＭＬデータを読取ることとを含む、請求項１に記載の方法。
5. 識別されたノードに対応する格納されたＸＭＬデータの位置を判断するステップは、データベース管理システムに格納されたＸＭＬ文書を索引付けする索引から位置情報を読取ることを含む、請求項４に記載の方法。
6. ＸＭＬフラグメントを抽出するステップは、
   索引の中の情報を使用してＸＭＬフラグメントを構成することを含む、請求項２に記載の方法。
7. １つ以上の上位ノードを識別するステップは、順序索引を使用することを含む、請求項３に記載の方法。
8. 前記ＸＭＬフラグメントの適切な解釈に必要な情報は、名前空間宣言である、請求項１に記載の方法。
9. 適切な解釈に必要な情報を含む１つ以上の上位ノードを識別するステップは、名前空間宣言を含む上位ノードを識別することを含む、請求項８に記載の方法。
10. 適切な解釈に必要な情報を含む１つ以上の上位ノードを識別するステップは、第１のＸＭＬフラグメントにおいて名前空間宣言が宣言されたかどうかを判断することを含む、請求項８に記載の方法。
11. 適切な解釈に必要な情報を含む１つ以上の上位ノードを識別するステップは、最も近い上位ノードからルート上位ノードまで順番に各々の上位ノードを調べることを含む、請求項１に記載の方法。
12. ＸＭＬフラグメントの適切な解釈に必要な情報は名前空間宣言であり、上位ノードにおける名前空間宣言が、既に考慮された上位ノードにおける名前空間宣言と一致する場合、名前空間宣言が適切な解釈に必要とされないことが判断される、請求項１１に記載の方法。
13. 請求項１から１２のいずれかに記載の方法をコンピュータに実行させるための、プログラム。

Images