JP5407043B2 - バイナリにエンコードされたｘｍｌデータの効率的な区分的アップデート - Google Patents

Description

発明の分野
本発明は概して、データ管理に関する。より詳しくは、関係データベース管理システム（ＲＤＢＭＳ）における区分的手法において、コンパクトバイナリにエンコードされたＸＭＬデータを効果的にアップデートする技術に関する。

背景
拡張マークアップ言語（ＸＭＬ）を使用することは、あらゆる種類の情報を表現したり交換したりするために、例えば、コンピュータプログラムのアプリケーションやサービスにおいて情報を交換するなどのために、一般的で有用な技術になってきている。よって、効果的かつ効率的にＸＭＬデータを保存および利用することも、同様に、有用で必要なことになってきている。このため、ＸＭＬデータの保存および利用ならびにＸＭＬデータに対するアクセスをサポートするために増強されたデータベースもある。データモデルとしてＸＭＬを用いる用途において主に要求されることの一つに、スキーマの柔軟性がある。しかしながら、ＸＭＬデータを保存するデータベースは、伝統的に、スキーマの柔軟性に関して最適化されたものではない。そのようなデータベースは、スキーマが提供されてそのスキーマが変化しにくいような場合においては効率的に動作し得るが、スキーマが変わりやすい場合、または、スキーマが大まかにしか構築されていない場合には、これらのデータベースは、ＸＭＬをサポートするための適切さを欠いたものになる。

ＸＭＬデータは、自己記述的なものである（すなわち、データとともにタグを含んでいる）が、標準的なＸＭＬの並列化フォーマットは、テキストベースのものであり、数字や日付を含んでいる。このため、同じデータを収集する場合でも、ＸＭＬ文書のサイズは、他の独自仕様のフォーマットに比して、著しく増大してしまう結果となる。ＸＭＬ文書のサイズが増大すると、ネットワーク帯域が限られているために、伝送に関する諸経費がかさむうえ、ディスクのＩ／Ｏ帯域幅が限られているために、保存および回復処理の動作が遅くなる。したがって、保存とクエリの利益を提供しつつスキーマの柔軟性を最大化しようとするＸＭＬデータのためのバイナリエンコーディング形式が導入された。このバイナリエンコーディング形式は、Ｒａｖｉ Ｍｕｒｔｈｙ他により出願された、「効率的な保存および処理のための階層的に組織化されたデータのエンコーディング」と題する米国特許出願第１１／１８２，９９７号（「Ｍｕｒｔｈｙ出願」）に記載されており、その全ての内容が、参照することにより、本明細書に完全に記載されているかのように、あらゆる目的のために組み込まれる。

Ｍｕｒｔｈｙ出願に記載されているエンコーディングフォーマットを用いて、ＸＭＬデータがコンパクトバイナリ形式で保存される。コンパクトバイナリ形式は、使用に適した形式のＸＭＬデータの全ての特徴を維持するものである。使用に適した形式とは、例えば、データの基礎となる階層型構造（例えば、データモデルまたはインフォセット）、要素および属性の概念などのものである。このようなコンパクトバイナリフォーマットは、ＸＭＬタグに関するオーバーヘッドを著しく最小化する。したがって、エンコードされたＸＭＬは、対応するテキスト文字表現のバイナリ表現に比してコンパクトなものになる。このバイナリフォーマットでは、データが効率的に事前に構文解析（ｐｒｅ−ｐａｒｓｅ）されるので、構文解析よりも効率的に処理できる。

データベース内のＸＭＬ文書の修正については、新しいノードを挿入することによって
、および、既存のノードを変更するか削除することによって、可能となる。なお、本明細書では、これらについて、まとめてアップデート操作と称することとする。ＸＭＬデータを操るアプリケーションの性質しだいでは、これらのタイプの操作を相対的に共通なものにできる。しかしながら、既存のＸＭＬデータ保存システムでは、バイナリにエンコードされたＸＭＬ文書をアップデートする効率的な手段を得ることはできない。このようなシステムは、典型的には、ＸＭＬ文書の全体を、オブジェクトツリー形式（例えばＤＯＭ）でローカルメモリ（例えばＲＡＭ）に読み込み、メモリ内でデータを変更し、アップデートされたＤＯＭツリーを変換して、保存に適したバイナリ形式に戻すようになっている。このプロセスは、一般的には非効率的であり、拡張性および性能に関する問題につながる。これは、ひとつには、ローカルメモリ内に、ＸＭＬ文書の全体を実体化する必要があることに起因する。さらに、既存のＸＭＬデータ保存システムのなかには、非常に特殊なＸＭＬスキーマを得ることができた場合には、ＸＭＬデータをアップデートするための最適化された技術をもたらし得るものもある。しかしながら、これらのシステムでは、ＸＭＬスキーマが極めて非拘束的である場合、または、使用可能なＸＭＬスキーマが無い場合に対しては、適切に対処できない。

したがって、上記した点に基づき、データベースに永続的に保存されているＸＭＬデータを、効率的にアップデートするための技術が必要である。

なお、この項目内で記述されるアプローチは、実行可能なアプローチであるが、過去に想到されたり実行されたりしたアプローチであるとは限らない。このため、別途に示すことのないかぎり、この項目内で記述されたアプローチのいずれについても、この項目に記載されているという理由で、ただの従来技術であると決めつけてはならない。

図面の簡単な説明
本発明を、添付の図面の個々の図に示された例を用いて、これらに限定されることなく説明する。なお、これらの図面では、同様の部材については同様の参照番号を付している。

図１は、本発明の実施形態に関し、ＸＭＬ文書に対する要求された修正に対応するタプル変更を生成する処理を示すフロー図であり、このＸＭＬ文書は、コンパクトバイナリ形式でデータベース内に永続的に保存されているものである。 図２は、本発明の実施形態に関し、コンパクトバイナリにエンコードされたＸＭＬデータに対するアップデートを、対応するタプル変更において表現する方法の例を示す図である。 図３は、本発明の実施形態を実施することが可能なコンピュータシステムを示すブロック図である。

発明の実施形態の詳細な説明
以下の記載では、説明のために、多数の個々の詳細を記述する。これは、本発明を深い理解をもたらすためである。しかしながら、本発明は当然、これらの個々の詳細がなくとも実施できるものである。他の例では、周知の構造および装置をブロック図の形で示している。これは、本発明が不明瞭になってしまうことを回避するためである。

本発明における機能の概要
本明細書に、データベースに保存されたＸＭＬデータをアップデートするための技術について説明する。既存の技術では、使用に適した形式のＸＭＬデータの全特徴を維持するようなコンパクトバイナリ形式を用いることで、ＸＭＬ文書を表現し解釈することが可能
である。このようなＸＭＬのコンパクトバイナリ表現については、次いでラージオブジェクト（例えばバイナリ・ラージ・オブジェクト（ｂｉｎａｒｙ ｌａｒｇｅ ｏｂｊｅｃｔ、すなわちＢＬＯＢ）として、永続的に（例えばディスクに）保存してよい。コンパクトバイナリ形式で保存されているＸＭＬ文書に対して要求された修正（例えば、挿入、削除、ノードのアップデート）に応じて、要求された修正に関する特定の表現が演算される。これは、この特定の表現をＸＭＬ文書のバイナリ形式に対して直接に適用するためである。したがって、要求された修正は、永続的に保存されているバイナリ形式に対して直接適用される。このとき、ＸＭＬ文書のオブジェクトツリー（例えばＤＯＭ）を構築することもないし、および／または、ＸＭＬ文書を対応するテキスト形式に構築または実体化することもない。

実際に変更を必要としているＸＭＬ文書におけるノードが特定される。この被影響ノード（ａｆｆｅｃｔｅｄ ｎｏｄｅ）の特定には、バイナリ表現中のどこにこの実際の変更を行う必要があるのか、例えば、実際の変更が始まるのは何バイトからなのか、の特定が含まれる。したがって、実際の変更が始まるのは何バイトからなのかを、「宛先オフセット」パラメータとして、要求された修正の表現内に含めることになる。しかしながら、ＸＭＬデータ用として適切なコンパクトバイナリ形式を用いる場合、バイナリ表現中のどこから実際の変更が開始するのかを特定することは、被影響ノードまたはノードが表現されている範囲（またはバイト数の範囲）を単純に特定することほど簡単ではない。これは、適切なバイナリ形式が、個々のＸＭＬ文書における既知の構造的特質および制限を有効に利用しているためである。この構造的な特徴および制限としては、例えば、対応するＸＭＬスキーマによって文書に付与されているものが挙げられる。この付与は、ＸＭＬ文書をコンパクト化する目的であり、概してタグによるトークン化（ｔｏｋｅｎｉｚａｔｉｏｎ
ｏｆ ｔａｇｓ）、によって、および、ＯＰコードを使用することによってなされる。例えば、同じタグが複数回繰り返される場合、または、ＸＭＬスキーマが要素の次数（ｏｒｄｅｒ ｏｆ ｅｌｅｍｅｎｔｓ）を制約している場合、適切なバイナリ形式を用いることで、対応するトークンＩＤを回避することが可能となる。したがって、バイナリ表現中のどこにこの実際の変更を行う必要があるのかについての演算では、ＸＭＬ文書がエンコードされたコンパクトバイナリ形式の性質を考慮するようにしてもよい。Ｍｕｒｔｈｙ出願には、ＸＭＬデータをエンコードするコンパクトバイナリ形式の非限定的な好ましい実施例に関する非常に詳細な記述があるので、これを参照されたい。

上記宛先オフセットパラメータに加えて、要求された修正の表現には、ＸＭＬ文書のバイナリ形式に実際の変更をインターリーブ（交互配置）するために十分な情報が含まれている。例えば、個々のアップデートノードに対応する特定の一連のバイトについて、ＸＭＬ文書全体を上書きすることなく、変更、追加または削除することが可能である。

環境ストレージシステムの操作
データベースシステムは、典型的には、１以上のクライアントを含んでいる。このクライアントは、データベースサーバに対して通信可能に接続されている。このデータベースサーバは、共用のデータベースに接続されている。「データベースサーバ」とは、サーバインスタンスおよびインスタンスが実行されているサーバマシンの一団をひっくるめた表現である。概して、サーバは、統合型ソフトウェアコンポーネントと、計算資源に関する記憶割当てとの組み合わせである。この計算資源とは、例えば、メモリ、ノード、および、統合型ソフトウェアコンポーネントをプロセッサにおいて実行するためのノード上のプロセスなどである。このようなソフトウェアと計算資源との組み合わせは、サーバのクライアントの利益になるような特種の機能を提供するために設けられているものである。

データベース管理の他の機能の中には、特定のデータベースにアクセスしたいというクライアントの要求を処理するにあたって、データベースサーバが、そのデータベースへの
アクセスを制御および促進する。クライアントがサーバと情報交換できるように、クライアントのためのセッションが確立される。データベースセッションなどのセッションは、クライアントからデータベースサーバなどのサーバに対して確立される個々の接続のことである。セッションを介して、クライアントは、一連の要求（例えば、データおよび／またはメタデータに対する要求）をデータベースサーバに対して出力できる。

データベースは、データおよびメタデータを含むものである。これらは、ハードディスクの組ような永続的メモリ機構に保存されている。これらのデータおよびメタデータは、論理的には、データベースに保存してもよい。この保存については、例えば、リレーショナルデータベース構成および／またはオブジェクトリレーショナルデータベース構成にしたがって行い得る。データベースアプリケーションは、データベースサーバにコマンドを出力することによって、データベースサーバと情報を交換する。このコマンドは、データベース内に保存されているデータに対する操作を、データベースサーバに実行させるためのものである。データベースアプリケーションからデータベースサーバに送られるデータベースコマンドは、データベースコマンドのオリジナルステートメントを含んでいる。データベースサーバがコマンドを処理できるように、コマンドは、データベースサーバによってサポートされたデータベース言語に準拠したものでなければならない。多くのデータベースサーバによってサポートされているデータベース言語の１つに、ストラクチャード・クエリ・ラングウェッジ（ＳＱＬ）として知られているものがあるが、これに限られるわけではない。

概して、データは、１以上のデータコンテナ内のデータベースに保存される。各コンテナはレコードを含んでおり、各レコード内のデータは、１以上のフィールドに体系化される。リレーショナルデータベースシステムでは、データコンテナは、概してテーブルと呼ばれ、レコードは行と呼ばれ、フィールドは列と呼ばれる。オブジェクト指向のデータベースでは、データコンテナは一般的にはオブジェクトクラスと呼ばれ、レコードはオブジェクトと呼ばれ、フィールドは属性と呼ばれる。他のデータベース構造は、他の専門用語が使用されるであろう。本発明を実施するシステムは、データコンテナまたはデータベース構造の特定の種類に限定されない。しかしながら、説明の便宜のために、本明細書において用いられる実施例および専門用語については、典型的にリレーショナルデータベースに関連したものとする。このため、データコンテナ、レコードおよびフィールドを示すために、それぞれ「テーブル」、「行」および「列」という用語を本明細書では使用する。

リレーショナルデータベースシステムは、特定の種類のデータに関する保存、管理およびクエリに対する（したがってデータのレポジトリとしての機能に対しても）ネイティブサポートを提供することにまで拡張し得る。例えば、ＸＭＬ文書をデータベースに直接に保存できるような特徴および技術によって、伝統的なリレーショナルデータベースシステムを増補してもよい。また、ＸＭＬ中心の手法（例えば、ＸＰａｔｈおよびＸＱｕｅｒｙ照会言語を用いた手法）または関係中心の手法（例えば、ＳＱＬ照会言語を用いた手法）で、かかるＸＭＬデータにアクセスできるような特徴および技術によって増補してもよい。このようなレポジトリは、ＸＭＬレポジトリまたはＸＭＬデータベース（すなわちＸＤＢ）と称されることもある。

ＸＭＬ文書のアップデート
ＸＭＬ文書に対するＸＭＬノードの挿入、アップデートおよび／または削除によって、ＸＭＬ文書を修正することができる。ＸＭＬ文書を修正するための要求は、ＸＭＬ文書を特定し、変更されるノードをＸＰａｔｈその他のパスネーム表現によって特定し、新しい値を付与することによって表現できる。要求される可能性のある１組の操作について、以下に示す。
（１）新しいノードの追加；ユーザは、ＸＰａｔｈその他のパスネーム表現を用いて、目
的のノードまたは親ノードを特定し、挿入すべき子ノード用の値を定めることができる。ＸＭＬ文書内における新しいノードの挿入位置は、例えば、新しいノードの挿入位置の前にある目的のノードを特定することによって（例えば、ｉｎｓｅｒｔＣｈｉｌｄ（）コマンド）、または、親ノードを特定し、特定された親ノードの最後の子として挿入すべき子ノードを付与することによって（例えば、ａｐｐｅｎｄＣｈｉｌｄ（）コマンド）、特定することができる。
（２）既存のノードのアップデート：ユーザは、ＸＰａｔｈその他のパスネーム表現を用いて目的のノードを特定し、アップデートすべき目的のノード用の値を定めることができる。
（３）ノードの削除：ユーザは、ＸＰａｔｈその他のパスネーム表現を用いて、削除の対象である目的のノードを特定することができる。

上記したように、伝統的なＸＭＬ保存システムは、通常、ＸＭＬ文書の全体を、ローカルメモリにロードして、要求された操作を実行するようになっている。しかしながら、これは動作を遅くする非効率的なプロセスである。このため、一実施形態では、保存されたＸＭＬ文書のコンパクトバイナリ表現を、ＸＭＬデータ修正要求に基づいて、直接アップデートする。すなわち、ローカル揮発性メモリにロードすることなく、ＸＭＬ文書を、永続的な保存装置（例えば、ディスクのような不揮発性メモリ）上で直接的にアップデートしてもよい。または、アップデートのためにＸＭＬ文書をローカル揮発性メモリにロードするとき、オブジェクトツリーとしてではなく、コンパクトバイナリ表現でロードするようにしてもよい。このコンパクトバイナリ表現は、テキストのＸＭＬを単純にバイナリフォーマットで表現したものに比べてコンパクトである（例えばＭｕｒｔｈｙ出願を参照）。

データベースに保存されたＸＭＬ文書のアップデートに関する効率的なプロセス
上記したように、ＸＭＬ文書のコンパクトバイナリ形式に対して直接適用するために、ＸＭＬ文書の変更に関する特定の表現が演算される。実施形態にしたがうと、このような変更は、パラメータ値の組によって表現され、本明細書において「タプル変更」と呼ばれる。概して、図１はタプル変更を生成するためのプロセスを示すフロー図である。

図１は、本発明の実施形態にかかる、タプル変更を生成するプロセスを示すフロー図である。このタプル変更は、コンパクトバイナリ形式でデータベース内に永続的に保存されているＸＭＬ文書に関して要求された修正に対応したものである。図１に示した方法は、１以上の命令のシーケンスを実行することによって遂行することが可能である。命令のシーケンスは、例えばコンピュータシステム（図３におけるコンピュータシステム３００）が備えているような、１以上のプロセッサによって実行される。

ブロック１０２では、コンパクトバイナリ形式でデータベースに保存されているＸＭＬ文書のコンテキスト内にある、ＸＭＬ文書に対する修正の要求を受信する。例えば、ＸＭＬデータの保存および管理をサポートしているデータベースシステム内のデータベースサーバが、ＳＱＬまたはＳＱＬ／ＸＭＬステートメントを受信する。かかるステートメントは、典型的には、（ａ）アップデート対象のＸＭＬ文書、（ｂ）特定されたＸＭＬ文書内の、アップデートされているノードに応じた１以上のパスネーム（例えばＸＰａｔｈｓ）、（ｃ）アップデートされているノードに対応する新しい値、を特定する。

ブロック１０４では、ＸＭＬ文書において修正を要求されている１以上のノードを、修正要求に基づいて特定する。修正要求において特定されたパスネームに基づいて被影響ノードを特定するために、データベースに保存されているＸＭＬデータを探すさまざまなアプローチを用いてよい。データベースに保存されているＸＭＬデータを探すアプローチの非限定的な例としては、ＸＭＬインデックス、ストリーミングＸＰａｔｈ評価（例えば非決定性有限状態オートマトン（例えば、ｎｏｎｄｅｔｅｒｍｉｎｉｓｔｉｃ ｆｉｎｉｔｅ ｓｔａｔｅ ａｕｔｏｍａｔｏｎ、すなわちＮＦＡ）などの使用が挙げられる。さらに、永続的な保存装置に保存されているＸＭＬ文書のコンパクトバイナリ形式は、究極的には、バイナリ・ラージ・オブジェクト（ＢＬＯＢ）としてもよい。このような場合には、ブロック１０４は、被影響ノード（単数または複数）が直列バイナリ形式で表現されているＢＬＯＢ内での正確な位置を特定する工程を含んでもよい。

ブロック１０６では、要求された修正が１以上のノードにおけるコンパクトバイナリ形式どのように影響を与えるのかについて演算する。例えば、ノード値が「１」から「１０００」に変わる場合、コンパクトバイナリ形式ではどのように「１０００」を表現するのか、について演算する。さらに他の例を挙げると、ノード値が整数型の「１」からフロート型の「１０００」に変わる場合、コンパクトバイナリ形式ではどのようにフロート型の「１０００」を表現するのか、について演算する。これは、コンパクトバイナリ形式では、Ｍｕｒｔｈｙ出願に記載されているように、そのネイティブなデータタイプを用いて値を保存している可能性があるからである。一実施形態では、コンパクトバイナリ形式で表現された１以上のノードのための「新しい値」を演算し、ＸＭＬ文書に対する要求された修正に関する特定の表現（例えばタプル変更）を用いて、パラメータとして表現する。これは、例えばブロック１１０において実施される。一実施形態では、前記新しい値は、要求された修正が特定された１以上のノードに与える直接の効果を越えた、要求された修正がコンパクトバイナリ形式に与えるあらゆる効果について考慮に入れている。これについては、より詳しく後述する。このように、新しい値は、古い値を交換するためにコンパクトバイナリ形式のバイトストリングに挿入された、一連のバイトにおける正味の値を表現したものである。

さらに、「１０００」を表現することは、「１」を表現するよりも、おそらく多くのバイト数を必要とする。このため、「新しい値の長さ」を、ブロック１０６の一部において演算するようにしてもよい。一実施形態では、１以上のノードのための新しい値の長さを演算し、ＸＭＬ文書に対する要求された修正に対応するタプル変更におけるパラメータとして表現する。これは、例えば、ブロック１１０において実施される。一実施形態では、前記新しい値は、要求された修正が特定された１以上のノードに与える直接の効果を超えた、要求された修正がコンパクトバイナリ形式に与えるあらゆる効果について考慮に入れている。これについては、より詳しく後述する。

コンパクトバイナリ形式（すなわち、文字ベースのＸＭＬ内容に関する単純なバイナリ表現ではない）で保存されているＸＭＬ文書に関しては、１つのノードに対する変更が、その１つのノードに対する直接の効果を越えて、コンパクトバイナリ表現に対しても影響することがある。例えば、Ｍｕｒｔｈｙ出願は「アレイモード最適化（ａｒｒａｙ ｍｏｄｅ ｏｐｔｉｍｉｚａｔｉｏｎ）」と呼ばれる技術について記載している。この技術によれば、同一のタグが複数回繰り返されている場合には、対応するトークンＩＤを繰り返さないようになっている。このように、ノードを追加または削除することで、タグシーケンスに影響を与え得る。そして、これにより、コンパクトバイナリエンコーディングのスキームにおけるアレイモード最適化成分にも影響を与え得る。例えば、Ｍｕｒｔｈｙ出願は、「スキーマシーケンシャル最適化」と呼ばれる技術について記載している。これによれば、メタデータ（例えば、ＸＭＬスキーマ）に関連する構造により、要素の順序が、特定の順序となるように強制される。このため、エンコーディングにおいて、ＸＭＬデータモデルを利用することによるトークンＩＤを不要にすることができる。このように、ＸＭＬスキーマに対する変更（例えばＤＤＬ操作を介するもの）により、ＸＭＬ文書に、これに対応する変更が誘発される。これは、スキーマへの準拠を維持するためである。ＸＭＬスキーマに対するこのような変更と、その結果生ずる対応するＸＭＬ文書に対する変更は、究極的には、ドキュメントにおける要素の順序に影響を及ぼし得る。したがって、コン
パクトバイナリエンコーディングのスキームにおけるスキーマシーケンシャル最適化成分にも影響を与え得る。

そこで、ブロック１０８では、要求された修正が１以上の特定されたノードに与える効果を越えて、要求された修正がＸＭＬ文書のコンパクトバイナリ形式にどのように影響するのか、について演算する。一実施形態では、要求された特定の修正に関してコンパクトバイナリ形式に与えられるこのような正味の効果の全体を、コンパクトバイナリ形式に挿入するための「新しい値」として表現する。このため、要求された特定の修正に関してコンパクトバイナリ形式に及ぼされる全体的な効果に関する新しい値を演算し、要求された修正に対応するタプル変更におけるパラメータとして表現する。これは、例えば、ブロック１１０において実施される。同様に、コンパクトバイナリ形式に対するこのような影響全体を、要求された修正に対応するタプル変更において、対応する「新しい値の長さ」のパラメータとして表現する。これは、例えば、ブロック１１０において実施される。つまり、要求された修正がコンパクトバイナリ形式に与える直接的な効果および間接的な効果は、たとえあったとしても、演算され、「新しい値」および「新しい値の長さ」という対応するパラメータとして、対応するタプル変更において共に表現される。

要求された修正による効果の表現
ブロック１１０では、要求された修正がＸＭＬ文書のコンパクトバイナリ形式に与える実際の効果を表現するパラメータを演算し、例えば対応するタプル変更を用いて表現する。次いで、このタプル変更は、データベースに永続的に保存されている、または揮発性メモリにローカルに保存されている、ＸＭＬ文書のコンパクトバイナリ形式に適用することが可能である。一実施形態では、ＸＭＬ文書のコンパクトバイナリ形式に対する要求された修正による効果が、＜ｄｅｓｔＯｆｆｓｅｔ，ｃｈａｎｇｅｄＬｅｎ，ｎｅｗＶａｌｕｅ，ｎｅｗＶａｌｕｅＬｅｎ＞のようなタプル変更の形式で表現される。上述のタプル変更パラメータを指すために用いられる名称は、実施状況に応じて異なる可能性がある。このように、タプル変更の成分については、上述のパラメータ名に限定されない。

ＢＬＯＢの性質が実施状況に応じて異なることには注意すべきである。このため、ＸＭＬ文書のコンパクトバイナリ表現を保存しているＢＬＯＢには、挿入および削除に対応している種類のものもある一方で、他のタイプのＢＬＯＢは対応していない。言い換えると、ＢＬＯＢ内のどこにおいても、必ずしも残余バイトを最後まで書き換える必要なく隣接するバイトからなる群を挿入または削除することの可能なＢＬＯＢもある、ということである。これに対して、挿入／削除ポイントの開始後にＢＬＯＢの全体を上書きしなければ、隣接するバイトからなる群を挿入または削除することの不可能なＢＬＯＢもある。本明細書において記載した技術は、ＢＬＯＢの性質に関わらず、タプル変更パラメータの演算時に、ＢＬＯＢの特徴を明確化することの可能なものである。

図２は、本発明の実施形態に関し、コンパクトバイナリにエンコードされたＸＭＬデータに対するアップデートが、対応するタプル変更においてどのように表現されるか、についての例を示す図である。

要求された修正による効果の生じたポイントを表現するために、コンパクトバイナリ形式における「ｄｅｓｔＯｆｆｓｅｔ（宛先オフセット）」というパラメータを使用する。このように、この宛先オフセットは、要求された修正を介してアップデートされている、少なくとも第１アトミックノード（バイナリ形式で現れる）については、要求された修正の開始されるコンパクトバイナリ形式におけるオフセット位置を特定する。一実施形態では、この宛先オフセットを、コンパクトバイナリ形式の先頭からのバイト数として表現する。上記したように、宛先オフセットは、要求された修正の影響を直接受ける特定されたノードにおける、現実の開始位置でなくてもよい。むしろ、宛先オフセットは、コンパク
トバイナリ形式の性質を考慮して、コンパクトバイナリ形式に対する現実の変更の開始される位置を特定する。例えば、要求された修正がバイナリ形式に与える実際の効果は、バイナリ形式において、ノード値の位置より前の位置から開始され得る。

図２に示した例では、１つのノードのみがアップデートされており、そのノードの古い値が、コンパクトバイナリ形式で、１６バイト、すなわち、バイト２２７〜２４３で表現されていると仮定している。さらに、アップデートされたノードのためのタグ名が変更されて、コンパクトバイナリエンコーディングのスキームにおける関連するアレイモード最適化成分が変更されることになる、ということも前提としている。例えば、第５の＜ｌｉｎｅｌｔｅｍ＞タグが、対応するＸＭＬ階層における同一の位置で、他の何らかのタグに変更されることにより、５つの連続した＜ｌｉｎｅｌｔｅｍ＞タグが分離される。このため、このノードに対する変更は、ノードの変更だけにとどまらず、コンパクトバイナリ形式に影響を与える。すなわち、アレイモード最適化における変更を反映して、前記ノードの前の数バイトが変更される必要がある。他のバイトに対するこのような効果のために、バイナリ形式に対する正味の効果は、実際には、バイト２２７からではなくバイト２２２から開始される。このように、このアップデートに関する宛先オフセットは、バイトストリングにおいてバイナリ形式に対する変更が開始されるバイト２２２を示す２２２である。

「ｃｈａｎｇｅｄＬｅｎ（変更された長さ）」というパラメータは、アップデートされたノードにおける変更された、すなわち古い値を、そのコンパクトバイナリ形式で表現するために用いられる。上記したように、この例では、そのノードの古い値は、１６バイトのコンパクトバイナリ形式で表現される。このため、このアップデートについて変更された長さは１６バイトである。

「ｎｅｗＶａｌｕｅ（新しい値）」というパラメータは、ノードのアップデートに起因するコンパクトバイナリ形式に対する変更全体に関する新しい値を表現するために用いられる。この新しい値は、対応するコンパクトバイナリ形式で表現されており、アップデートされたノードを超えてバイナリ形式にまで及んでいるあらゆる効果を含んでいる。「ｎｅｗＶａｌｕｅＬｅｎ（新しい値の長さ）」というパラメータは、ノードのアップデートに起因するコンパクトバイナリ形式に対する変更全体に関する新しい値の長さを、バイトで表現するために用いられるものである。この新しい値は、対応するコンパクトバイナリ形式で表現されている。したがって、このアップデートに関する新しい値の長さは２１バイト、すなわち、宛先オフセットバイト２２２からノードの終端のあるバイト２３４までである。この例では、１６バイトで記述された古いノード値を表現するバイトのストリングは、新しいノード値およびこのノード値によるバイナリ形式の残部に対する効果を表現する、２１バイトの新しいストリングと入れ替えられる。

一人のユーザがアップデート操作をすると、修正要求に含まれているＸＰａｔｈによって特定されるノードの数に基づいて、多数のタプル変更のなされる可能性がある。一実施形態では、これら一揃いのタプル変更は、本明細書において「ａｔｏｍ−ｄｉｆｆ−ＸＭＬ」と称されるＸＭＬ変更文書によって表現される。この「ａｔｏｍ」は、初歩的な変更操作を意味する。上記したように、この「ａｔｏｍ−ｄｉｆｆ−ＸＭＬ」は、コンパクトバイナリ形式に対する修正要求から生ずる変更を表現するものであり、対応する保存容量に基づく基本記憶領域に適用することができる。例えば、この記憶領域が区分的アップデートをサポートしている場合、「ａｔｏｍ−ｄｉｆｆ−ＸＭＬ」において表現される初歩的な変更操作は、根本的な基本記憶領域の構成に直接変換される。この記憶領域が上書き能力しかサポートしていない場合（長さを増やしたり減らしたりできない場合）、第１の変更（文書の順序に基づく変更）を超えて全てが上書きされることにより、「ａｔｏｍ−ｄｉｆｆ−ＸＭＬ」によって表現された要求された変更の全てが、根本的な基本記憶領域
の構成に適用される。

図２を参照して記載した例のようなノードアップデート操作に加えて、ノードを挿入したり削除したりしてもよい。新しいノードをＸＭＬ文書に挿入すると、コンパクトバイナリ形式にバイトが追加される。周囲のノードおよび周囲のノードの対応するバイナリ表現に対する新しいノードによる効果があれば、それを考慮しながら、宛先オフセットにより、バイトストリング内のどこに新しいノードを挿入するのかを特定する。同様に、ノード挿入操作に対応する新しい値および新しい値の長さにも、新しいノードおよび新しいノードによるコンパクトバイナリ表現に対する効果全体が考慮される。新しいノードを追加しているとしても、変更された長さのパラメータ（「古い」長さ）に関する対応する値を残すようにしてもよい。これは、新しいノードが、周囲のノードのコンパクトバイナリ表現に影響を与える可能性があるからである。したがって、このような場合、新しいノードの挿入によって影響を受ける周囲のノードに関する古い表現がある場合には、変更された長さのパラメータは、それを表現するものとなる。同様に、新しいバイナリ表現がｙバイトで構成されている場合、ＸＭＬ文書からノードを削除してバイト数ｘをバイト数ｙで置換するようにしてもよい。これは、ノードを削除すると、他のノードのバイナリ表現に影響を与える可能性があるからである。要約すれば、ＸＭＬ文書に対するノードのアップデート、削除、または追加のいずれにおいても、タプル変更に関する値は、ノードに対する変更とともに、このノードの変更が他のノードのコンパクトバイナリ表現に与える効果を反映する。

したがって、目的のＸＭＬ文書の全体をＤＯＭツリーとしてメモリ内に実体化することなく、ユーザ・アップデート・ステートメントを適用するための技術が示されている。これにより、他の技術に比して、よりよい性能および拡張性を得ることが可能となる。

ハードウェアの概観
図３は、本発明の実施形態を実現し得るコンピュータシステム３００を示すブロック図である。コンピュータシステム３００は、バス３０２または情報通信用の他の通信機構と、情報を処理するためにバス３０２に接続されているプロセッサ３０４と、を備える。コンピュータシステム３００は、さらにランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ３０６を備える。このメインメモリ３０６は、バス３０２に接続され、情報およびプロセッサ３０４により実行される命令を保存する。メインメモリ３０６は、プロセッサ３０４により実行される命令の実行中に、一時的な変数または他の中間情報を保存するためにも用いられる。コンピュータシステム３００は、読み出し専用メモリ（ＲＯＭ）３０８または他の静的記憶装置をさらに備える。これは、バス３０２に接続され、静的な情報およびプロセッサ３０４のための命令を保存する。磁気ディスクまたは光ディスクなどの保存装置３１０が設けられ、バス３０２に接続され、情報および命令の保存に用いられる。

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

本発明は、本明細書に記載した技術を実行するためのコンピュータシステム３００の使用に関するものである。本発明の一実施形態にしたがうと、これらの技術は、メインメモリ３０６に格納されている１以上の命令の１以上のシーケンスをプロセッサ３０４が実行することに応じて、コンピュータシステム３００によって遂行される。これらの命令は、保存装置３１０などのコンピュータ読み取り可能な他の媒体から、メインメモリ３０６に読み込むようにしてもよい。メインメモリ３０６に格納されている命令シーケンスは、プロセッサ３０４に、本明細書に記載の処理ステップを実行させる。代替の実施形態では、本発明を実施するためのソフトウェア命令に代えて、またはこれと組み合わせて、配線接続された回路を使用してもよい。このように、本発明の実施形態は、ハードウェア回路およびソフトウェアの特定の組み合わせに限定されない。

本明細書において用いている「マシン読み取り可能な媒体」という語は、特定の方法で装置を操作することの可能なデータの供給に関与している、あらゆる媒体を示すものである。コンピュータシステム３００を用いて実施される実施形態では、マシン読み取り可能なさまざまな媒体の使用を伴う。例えば、プロセッサ３０４に命令を与えて実行させることにおいてなどである。このような媒体は多様な形態を取ることが可能であり、例えば、不揮発性の媒体、揮発性の媒体および伝送媒体が挙げられるが、これらに限定されない。不揮発性の媒体としては、例えば、保存装置３１０のような、光学ディスクまたは磁気ディスクが挙げられる。揮発性の媒体としては、メインメモリ３０６のような、ダイナミックメモリが挙げられる。伝送媒体としては、同軸ケーブル、銅線、光ファイバーが挙げられる。この伝送媒体には、バス３０２を構成するワイヤも含まれる。伝送媒体は、無線および赤外線データ通信中に生成されるような、音波または光波の形態を取ることも可能である。

マシン読み取り可能な媒体における一般的な形態としては、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または他の磁気媒体、ＣＤ−ＲＯＭ、他のあらゆる光媒体、パンチカード、紙テープ、穴のパターンを有する他のあらゆる物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュ−ＥＰＲＯＭ、他のあらゆるメモリチップまたはメモリカートリッジ、後述するような搬送波、または、コンピュータが読み取れる他のあらゆる媒体、が挙げられる。

１以上の命令に関する１以上のシーケンスをプロセッサ３０４に伝えて実行するには、さまざまな形態のマシン読み取り可能な媒体を用いてよい。例えば、リモートコンピュータの磁気ディスクに対して、最初に命令を伝送する構成としてもよい。リモートコンピュータは、モデムを利用した電話線を介して、ダイナミックメモリに命令をロードできるとともに、この命令を送信することが可能である。コンピュータシステム３００に配されたモデムは、電話線を介してデータを受信し、赤外線送信装置を用いてデータを赤外線信号に変換することが可能である。この赤外線信号で運ばれるデータは、赤外線検出器によって受信することが可能であるとともに、適切な回路によってバス３０２に置くことができる。バス３０２は、メインメモリ３０６にデータを運ぶ。プロセッサ３０４は、そこから命令を取り出して実行する。メインメモリ３０６によって受信された命令は、プロセッサ３０４によって実行される前または実行された後に、光学的に保存装置３１０に保存してよい。

コンピュータシステム３００は、バス３０２に接続された通信インターフェイス３１８も備える。通信インターフェイス３１８は、ネットワークリンク３２０を介した双方向データ通信を可能とするものである。このネットワークリンク３２０は、ローカルネットワーク３２２に接続されている。例えば、通信インターフェイス３１８は、総合デジタル通信網（ＩＳＤＮ）カード、または、電話線の種類に応じたデータ通信接続を可能とするモデムであってよい。他の例として、通信インターフェイス３１８は、ローカルエリアネッ
トワーク（ＬＡＮ）に適したデータ通信接続を可能とするＬＡＮカードであってもよい。また、ワイヤレスリンクを実装してもよい。このようなあらゆる実施において、通信インターフェイス３１８は、さまざまな種類の情報を表現するディジタル・データ・ストリームを搬送するための、電気信号、電磁信号、または光信号を送受信するようになっている。

ネットワークリンク３２０は、典型的に、１以上のネットワークを介して、他のデータ装置に対するデータ通信を行う。例えば、ネットワークリンク３２０は、ローカルネットワーク３２２を介してホストコンピュータ３２４との間で、または、インターネット・サービス・プロバイダ（ＩＳＰ）３２６によって操作されるデータ装置との間で、接続を確立してもよい。そして、ＩＳＰ３２６は、全世界的なパケットデータ通信ネットワークを介して、データ通信サービスを提供するものである。このパケットデータ通信ネットワークは、現在では、一般に「インターネット」３２８と呼ばれるものである。ローカルネットワーク３２２およびインターネット３２８は、ともに、ディジタル・データ・ストリームを搬送する電気信号、電磁信号、または光信号を利用する。さまざまなネットワークを介して得られる信号、および、通信インターフェイス３１８を介して得られるネットワークリンク３２０上の信号は、コンピュータシステム３００に対してディジタルデータを入出力するものであり、情報を移送する搬送波の典型的な形態である。

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

受信されたコードは、受信されたままの状態でプロセッサ３０４によって実行するようにしてもよいし、および／または、後で実行するために、保存装置３１０または他の不揮発性保存装置に記憶するようにしてもよい。この方法では、コンピュータシステム３００は、搬送波の形態をなしているアプリケーションコードを得てもよい。

上記した明細書においては、本発明の実施形態を、実施ごとに異なり得る多数の個々の詳細を参照しながら説明してきた。したがって、本発明が何なのか、および、出願人が発明であると意図しているものは何なのか、についての唯一かつ排他的な指標は、後に補正される部分も含む本願における一連の請求項であり、これらは、請求項に由来する特定の形態で記載されている。かかる請求項に含まれている用語に関して本明細書において明確に説明した全ての定義は、請求項において使用されているようなこれらの用語の意味を規定している。よって、請求項に明確に記載されていない限定、要素、特質、特徴、長所または属性は、いかなる方法であっても、かかる請求項の範囲を限定しない。このため、明細書および図面は、限定的意味ではなく、例示的であるとみなされるべきである。

Claims (7)

1. プログラムであって、前記プログラムはコンピュータに、
   コンパクトバイナリ形式でデータベースに保存されているＸＭＬ文書に対する修正要求を受信するステップと、
   要求に基づき、要求された修正の対象であるＸＭＬ文書の１以上のノードを特定するステップと、
   要求された修正の対象であるＸＭＬ文書の１以上のノードの特定に基づいて、ＸＭＬ文書のコンパクトバイナリ形式に対する変更を特徴づけるパラメータを演算するステップと、
   前記パラメータに基づいて、前記ＸＭＬ文書のコンパクトバイナリ形式に対して要求された修正を施すステップとを実行させ、
   前記パラメータを演算するステップは、
   コンパクトバイナリ形式における第１の変更が適用されるべき開始地点を特定するステップと、
   前記開始地点を特定する宛先オフセットパラメータを演算するステップとを含み、
   前記開始地点は、前記ＸＭＬ文書のコンパクトバイナリ形式の先頭からのオフセットバイト数として特定される、プログラム。
2. 前記ＸＭＬ文書に対する修正は、少なくとも１つのノードを挿入する操作、または、ノードをアップデートする操作を含み、
   前記パラメータを演算するステップは、
   前記宛先オフセットパラメータと、
   ノードを挿入する操作またはノードをアップデートする操作の対象となるノードに関連する古いバイナリ値であって、ノードを挿入する操作またはノードをアップデートする操作の結果として入れ替えられる古いバイナリ値を表現するのに使用されるＸＭＬ文書のコンパクトバイナリ形式のバイト数を特定する、変更された長さのパラメータと、
   ノードを挿入する操作またはノードをアップデートする操作の結果として生じる新しいバイナリ値であって、ＸＭＬ文書のコンパクトバイナリ形式における古いバイナリ値と入れ替わる新しいバイナリ値を表現する新しい値のパラメータと、
   前記ＸＭＬ文書のコンパクトバイナリ形式の部分の新しい値を表現するためのバイト数を特定する新しい値の長さのパラメータと、を演算するステップを含む、請求項１に記載のプログラム。
3. ＸＭＬ文書のコンパクトバイナリ形式を変更するステップは、古い値を前記開始地点から始まる前記新しい値によって入れ替えるステップを含む、請求項２に記載のプログラム。
4. 前記パラメータを演算するステップは、
   要求された修正が、要求内のパスネーム表現に基づいたアップデートのためにＸＭＬ文書から特定される１以上のノードを表現するバイトに対して及ぼす効果を超えて、要求された修正がＸＭＬ文書のコンパクトバイナリ形式にどのように影響するのか、を演算するステップを含む、請求項１〜３のいずれか１項に記載のプログラム。
5. 前記ＸＭＬ文書のコンパクトバイナリ形式に対して要求された修正を施すステップは、要求された修正を、永続的な保存装置に保存されているコンパクトバイナリ形式に対して直接に施すステップを含む、請求項１〜４のいずれか１項に記載のプログラム。
6. 前記ＸＭＬ文書のコンパクトバイナリ形式に対して要求された修正を施すステップは、要求された修正を、ＸＭＬ文書のオブジェクトツリーを構築することなく実行するステップを含む、請求項５に記載のプログラム。
7. 前記パラメータを演算するステップは、１以上のノードの全てに対する修正を特徴づける単一のＸＭＬ文書を演算するステップを含む、請求項１〜６のいずれか１項に記載のプログラム。

Images