1. 開発者ガイド
  2. XML Schemaとオブジェクト・リレーショナルXMLType
  3. XMLType記憶域および索引付けの選択

16 XMLType記憶域および索引付けの選択

アプリケーションの設計では、使用するXMLType記憶域モデルおよび使用する索引付けの方法を選択することも重要です。

親トピック: XML Schemaとオブジェクト・リレーショナルXMLType

16.1 XMLType記憶域モデルと索引付けの方法の選択に関する概要

XMLTypeとは、XMLデータおよびその使用を最適にするための様々な記憶域モデルと索引付けモデルを提供する抽象SQLデータ型です。抽象データ型であるため、アプリケーションおよびデータベース問合せの柔軟性が増し、同じインタフェースをすべてのXMLType操作に使用できます。

アプリケーションが異なれば、XMLデータの使用方法も異なります。これは、リレーショナル・データソースから構築されることもあり、比較的構造化されています。これは抽出、変換およびロード(ETL)操作に使用されることもあり、その場合もきわめて構造化されます。書籍や記事のように、書式自由の文書(非構造化、または半構造化)に使用される場合もあります。

データの種類が異なれば、検索の方法も異なります。データ中心のユースケースでは固定の問合せセットを伴うことが多く、ドキュメント中心のユースケースでは任意の(非定型)問合せを伴う場合が多くなります。

XMLの使用方法は多岐にわたるため、どのようなユースケースでも最適なパフォーマンスと柔軟性が得られる万能の記憶域モデルはありません。Oracle XML DBには、XMLTypeに2つの記憶域モデルがあり、これらの記憶域モデルごとに適切な索引付け方法のアプローチがいくつかあります。パフォーマンスと機能は、使用しているXMLデータの種類とその使用方法に最も適するように調整できます。

したがって、どのXMLデータにどのXMLType記憶域モデルを使用するかということが、重要な決定事項の1つです。この章の内容は、特定のユースケースに最適な記憶域オプションを選択する際に役立ちます。

XMLType表および列は、次の方法で格納できます。

  • バイナリXML記憶域 - これは、事後解析の永続性とも呼ばれます。これが、Oracle XML DBのデフォルトの記憶域モデルです。XMLデータに特化して設計された事後解析型のバイナリ形式です。バイナリXMLは、簡潔でXML Schema対応です。バイナリXML記憶域の最大の利点は、柔軟性です。XML Schemaに基づく文書にも、XML Schemaに基づかない文書にも使用できます。きわめて多様なデータを許可する、あるいは変化が激しい、または予測できないXML Schemaに対して使用できます。この記憶域モデルには、効率的な部分更新と、ストリーミング可能な問合せ評価の機能もあります。

  • オブジェクト・リレーショナル記憶域 - これは、構造化記憶域、オブジェクトベースの永続性とも呼ばれます。この記憶域モデルは、エンティティ関連(ER)のXMLデータ分解を表します。既知で多かれ少なかれ固定の問合せセットを伴い、高度に構造化されたデータに対して最高のパフォーマンスを発揮します。問合せのパフォーマンスはリレーショナル・データのパフォーマンスに一致し、更新はインプレースで実行できます。

注意:

Oracle Database 12cリリース1 (12.1.0.1)以降、XMLType用の非構造化(CLOB)記憶域モデルは非推奨です。バイナリXML記憶域をかわりに使用してください。

CLOBデータとして格納されている既存のXMLTypeデータがある場合は、Oracle GoldenGateを使用して、それをバイナリXML記憶域の形式に移動することを検討してください。特定のXML文書について文書の再現性が重要な場合は、そのコピーをCLOB列に格納します。

Oracle XML DBは、XMLTypeデータに対して次の種類の索引をサポートします。

  • オブジェクト・リレーショナル記憶域でのBツリー・ファンクション索引

  • バイナリXML記憶域でのXML検索索引

  • バイナリXML記憶域での構造化および非構造化コンポーネントを含むXMLIndex

  • バイナリXML記憶域でXMLIndex (構造化および非構造化コンポーネントの両方)に対して自動的に作成されるセカンダリ表でのBツリー索引

ユースケースが異なれば、必要なXMLType記憶域モデルと索引の組合せも異なります。

関連トピック

親トピック: XMLType記憶域および索引付けの選択

16.2 XMLTypeのユースケースの範囲: データ中心からドキュメント中心

XMLType記憶域モデルを選択する際には、XMLデータの性質とその使用方法を検討します。ユースケースには、データ中心の程度が最も高いものからドキュメント中心の程度が最も高いものまでの範囲があります。

図16-1ではこのことについて説明しています。ここでは、データ中心の程度が最も高いケースを左端に、ドキュメント中心の程度が最も高いケースを右端に示しています。

図16-1 XMLのユースケースとXMLType記憶域モデル

図16-1の説明が続きます
「図16-1 XMLのユースケースとXMLType記憶域モデル」の説明

データ中心データは高度に構造化されており、構造は比較的静的および予測可能で、アプリケーションはその構造を好材料として活用します。データはXML Schemaに準拠しています。

ドキュメント中心のデータは、次の2つの場合に分けられます。

  • データは一般に構造がないか、可変構造を持っています。これには、構造化された部分と非構造化の部分が両方ある文書も含まれます。文書の構造が時間とともに変わる場合(拡張)や、テキスト・ノードと子要素の両方を含めて多数の要素があり、内容が混在する場合(半構造化)があります。多数のXML要素が欠落していたり、異なった順序で表示されたりすることがあります。ドキュメントはXML Schemaに準拠している場合もしていない場合もあります。

  • データは比較的構造化されていますが、アプリケーションはその構造の長所を活用しません。つまり、構造がないかのようにデータを処理します。

親トピック: XMLType記憶域および索引付けの選択

16.3 XMLTypeとして格納されるXMLデータの一般的なユースケース

XMLTypeとして格納されるXMLデータの一般的なユースケースに対応するアプリケーション・ユースケースの推奨事項を示します。

ユースケースが一般的でなく、ここで説明されていない場合は、この章の他の項で特殊なケースに関する情報を参照してください。

注意:

この項で扱うのは、XMLTypeとして永続的に保持されているXMLデータの一般的な使用方法です。XMLデータの一般的なユースケースの1つが、リレーショナル・データからのXMLデータの生成です。これはリレーショナル記憶域を伴い、生成されるXMLデータは必ずしも永続的に保持されないため、ここでは扱いません。

(生成されたXMLデータがXMLTypeとして永続的に保持されるケースについては、XMLTypeのユースケース: ETLのステージを経たXMLデータを参照してください。)

関連トピック

親トピック: XMLType記憶域および索引付けの選択

16.3.1 XMLTypeのユースケース: XMLフラグメントの更新または問合せがない

このユースケースでは、データベースに格納されているXMLデータのフラグメントを更新または問い合せる必要がありません。

このユースケースには、次のオプションがあります。

  • バイナリXML記憶域を使用して、XMLTypeとして格納します。

  • リレーショナルBLOBまたはCLOB列、可能であればSecureFiles LOBに格納します。

XMLデータをXMLTypeとしてではなくリレーショナルLOB列に格納する場合、Oracle Databaseではデータが解析されず、その妥当性を保証できません。(そのデータに対してXMLType操作は実行できません。)

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.3.2 XMLTypeのユースケース: 異なるXML Schemaを持つ多様なソースからのデータ統合

XMLデータが、異なるXML Schemaを使用する複数のデータソースから取得される場合は、バイナリXML記憶域を使用します。

このユースケースには、3つの下位ケースがあります。

  • XMLデータに予測可能な構造化データのアイランドが含まれ、問合せが既知の場合には、構造化コンポーネントを含むXMLIndexを使用し、(これらのアイランドの周囲にあるのが非構造化データでも)構造化アイランドを索引付けします。構造化された索引コンポーネントに、使用する問合せが反映されます。このようなユースケースの例が、RSSニュース・アグリゲータです。

  • このような構造化アイランドがない場合、または問合せが事前には未知である(非定型)場合、非構造化コンポーネントを含むXMLIndexを使用してください。

  • 全文検索を伴う問合せを使用する場合は、XQueryプラグマora:no_schemaとともに、XML検索索引を使用します。

関連トピック

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.3.3 XMLTypeのユースケース: ETLのステージを経たXMLデータ

このユースケースでは、データが外部ソースから抽出され、操作のニーズに応じて変換され(通常はリレーショナル)、最後にデータベースにロードされます(抽出、変換、ロード(ETL))。特に、変換の際にはこのユースケースを利用します。

ETLのユースケースでは多くの場合、異なるソフトウェアやハードウェア・システムを使用する複数の当事者によって維持またはホストされている複数のアプリケーションからデータを統合します。抽出されたデータは、変換を担当する当事者または変換後に使用する当事者とは別の当事者が担当することが少なくありません。

これに伴うXMLデータは通常、高度に構造化されており、XML Schemaに準拠しています。このユースケースでは、XMLデータからのリレーショナル・データ生成も、リレーショナル・データからのXML生成も扱います。

ETLユースケースのサブセットでは、XMLデータの効率的な更新が必要です。更新には、XML文書全体の置換や、文書のフラグメントのみに対する変更(部分更新)が伴うことがあります。

このユースケースに適しているのは通常、XMLTypeデータのオブジェクト・リレーショナル記憶域です。

関連トピック

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.3.4 XMLTypeのユースケース: 半構造化XMLデータ

このユースケースでは、XMLデータが可変フォームであるか、またはその大部分が明確に定義されていません。関連付けられているXML Schemaがない可能性もあれば、XML Schemaできわめて多様なデータを許可する、または変化が激しい、または予測できない可能性もあります。

このユースケースに適しているのは通常、XMLTypeデータのバイナリXML記憶域です。

問合せパスが既知の場合には構造化コンポーネントXMLIndexの索引付けを使用し、パスが事前に既知でない(非定型問合せ)場合にはパスサブセット化された非構造化コンポーネントXMLIndexの索引付けを使用します。XQuery全文問合せには、XML検索索引を使用します。

関連トピック

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.3.5 XMLTypeのユースケース: ビジネス・インテリジェンス問合せ

XMLデータに対するビジネス・インテリジェンス(BI)問合せを有効にするには、SQL/XML関数XMLTableを使用して、仮想表の列としてデータに含まれる値を予測します。次に、分析関数ウィンドウでSQL ORDER BYおよびGROUP BYを使用して、仮想表の列を操作します。

ビジネス・インテリジェンス問合せの場合、通常は次の操作をすべて実行します。

  • XMLTypeデータをバイナリXMLとして格納する。

  • 構造化コンポーネントが含まれるXMLIndex索引を使用する。

  • SQL/XML関数XMLTableを使用してデータに対するリレーショナル・ビューを作成し、ビューでBIアプリケーションに関連する列をすべて予測する。

  • これらのリレーショナル・ビューに対してアプリケーション問合せを記述する。

これらのビューに1対1対応でXMLIndex索引が作成される場合、そのビューに対する問合せはXMLIndex構造化コンポーネントのリレーショナル表に対する問合せに、Oracle Databaseによって自動的に変換され、リレーショナルのパフォーマンスが発揮されます。

仮想表の列に対して分析関数ウィンドウ、ORDER BYまたはGROUP BYを使用すると、これらの操作が構造化コンポーネントXMLIndex表で対応する物理的な列に対するウィンドウ、ORDER BYおよびGROUP BY操作に変換されます。

関連トピック

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.3.6 XMLTypeのユースケース: 全文検索を伴うXML問合せ

アプリケーションでXMLデータに対する全文検索を実行する必要がある場合は、バイナリXML記憶域を使用して、問合せに対応するXML検索索引を作成します。

関連トピック

親トピック: XMLTypeとして格納されるXMLデータの一般的なユースケース

16.4 XMLType記憶域モデルについての考慮事項

ほとんどのユースケースでXMLTypeのバイナリXML記憶域を使用することをお薦めします。オブジェクト・リレーショナル記憶域は特殊なケースに適しています。

次の条件がすべて満たされないかぎり、オブジェクト・リレーショナル記憶域は適しません。

  • 特定のXMLType列または表に格納する予定であるXML文書すべての詳細なデータ形式を厳格に指定するXML Schemaがある。アプリケーションがデータ中心である。

  • XML Schemaが、インプレースのスキーマ拡張を許可しない形で頻繁に拡張されない。

  • データが特にスパースではない(空または欠落している要素を多数含んでいない)。

  • XML文書をすべて同時に挿入または選択する必要がない。部分更新や部分選択が一般的である。

  • 文書の再現性が必要とされない(DOM再現性で十分)。

表16-1に、この詳細を示します。XMLType記憶域モデルの選択に関してここで提示するガイドラインは独立したものではないため、各行は、条件列の条件が満たされるまで、示されている順序のとおりに適用してください。

表16-1 XMLType記憶域モデルについての考慮事項

条件 対応

1. 文書の再現性のプロパティが必要なため、元の空白をすべて維持する。

データベース用とXML処理用に、バイナリXML記憶域を使用します。ただし、元の文書のコピーもCLOB (リレーショナル)列に格納します。

(自身でデータを更新する場合、2つのバージョンの同期は自己責任です。)

2. XMLデータの一部のみを選択または更新する必要がほとんど皆無である。かわりに、通常はXML文書をすべて同時に挿入または選択する。

バイナリXML記憶域を使用します。

3. 同じXMLType表または列にある別のXML Schemaに準拠するXMLTypeインスタンスを格納する必要がある。

(Oracle XML DBがXML Schemaを使用してXML問合せやその他の処理を最適化できなくなるため、このような処理は一般的に推奨されません。)

バイナリXML記憶域を使用します。

4. データにXML Schemaがない。

バイナリXML記憶域を使用します。

XML Schemaの検証によってデータに利点があると考えられる場合には、スキーマ生成ツールを使用してXML Schemaを生成するかどうかを検討してください。

5. XML Schemaが頻繁に、または予測されない形で拡張され、インプレースのXML Schema拡張によるメリットを得られない。

インプレース拡張は通常、変更によって既存の文書が無効にならず、記憶域モデルの変更を伴わない場合にのみ許可されます。XML Schemaの拡張を参照してください。

バイナリXML記憶域を使用します。

XML Schemaを更新するには、PL/SQLプロシージャDBMS_XMLSCHEMA.copyEvolveを使用します。

6. XMLデータが非常にスパースである。

バイナリXML記憶域を使用します。

7. XML Schemaが、要素anyやchoiceなどの構造体を使用せず、データ形式の詳細な仕様が提供されない。

(XML Schemaジェネレータを使用すると、生成されるスキーマにはこのような構造体が含まれることが多い。)

オブジェクト・リレーショナル記憶域を使用します。

8. XML Schemaを変更して、XMLデータ構造の厳格な定義を妨げるanyやchoiceなどの構造体を削除できる。

そのような構造体を削除し、オブジェクト・リレーショナル記憶域を使用します。

9. そのような構造体を削除できない。

バイナリXML記憶域を使用します。

親トピック: XMLType記憶域および索引付けの選択

16.5 XMLTypeの索引付けについての考慮事項

XMLTypeデータがオブジェクト・リレーショナル形式で格納されている場合は、リレーショナル・データの場合とまったく同じように、Bツリー・ビットマップ索引を作成します。バイナリXMLとして格納されているXMLTypeデータにはXMLIndex索引付けを使用します。

ドキュメント中心XMLデータの一般的な索引付けでは、非構造化コンポーネントとともにXMLIndexを使用します。これは、非定型(任意)の問合せに適しています。

データに、頻繁に問い合せる予測可能な部分が含まれる場合は、それらの部分に対して構造化コンポーネントを含むXMLIndexを使用します。このユースケースの例として、通常は書式自由だが著者、日付、タイトルについては固定フィールドを持つような仕様があります。

通常は構造化されていないコンテンツ内の構造のアイランドを処理するは、構造化および非構造化コンポーネントの両方を含む1つのXMLIndex索引を作成します。両方のコンポーネントを使用する可能性のあるユースケースとして、構造化データが存在するときは文書からXMLフラグメントを抽出するような問合せをサポートする場合などがあります。索引の構造化コンポーネントは、問合せで構造化データの有無を確認するWHERE句の条件に使用されます。非構造化コンポーネントは、フラグメントの抽出に使用されます。

表16-2に、バイナリXMLとして格納されているXMLTypeデータの索引付けの簡単なガイドラインを示します。これらのガイドラインは独立しているので、「条件」に書かれた条件が満たされる場合には、索引付けの方法を組み合せて使用できます。

表16-2 XMLTypeの索引付けについての考慮事項

条件 対応

データに予測可能な構造化データのアイランドが含まれている。

構造化アイランドのそれぞれに対する構造化コンポーネントを含むXMLIndexを使用します。

全文問合せをサポートする必要がある。

XML検索索引を使用します。

述語を含む非定型XML問合せをサポートする必要がある。

非構造化コンポーネントを含むXMLIndexの使用

親トピック: XMLType記憶域および索引付けの選択

16.6 XMLType記憶域オプション: 相対的なメリット

それぞれのXMLType記憶域モデルには、独自の長所と短所があります。

表16-3に、XMLTypeの各記憶域モデルの長所と短所をまとめます。(+)と(-)の記号は、それぞれ長所と短所を大まかに示しています。

表16-3 XMLType記憶域モデル: 相対的なメリット

品質 バイナリXML記憶域 オブジェクト・リレーショナル記憶域

スループット

(+)高いスループット。高速なDOMロード。バイナリ・エンコーダ/デコーダからのオーバーヘッドが多少発生します。

(-) XML分解では、XML文書のコンテンツ全体の収集または取出し時のスループットが低下する場合があります。

索引付けのサポート

XMLIndexとXML検索索引。

特定の要素または属性に対するBツリー索引、ビットマップ索引、およびOracle Text索引。

問合せ

(+) XMLIndexを使用するときに高速です。索引を使用できない問合せは、ストリーミングXPath評価を使用し、これも高速になります。

(++)リレーショナル問合せのパフォーマンス。基礎となるオブジェクト・リレーショナル列に対してBツリー索引を作成できます。

更新操作(DML)

(+)インプレースのピース単位更新(SecureFiles LOB記憶域の場合)。

(++)リレーショナル更新のパフォーマンス。列はインプレースで更新されます。

データの柔軟性

(+) XMLType列または表に格納可能なXML文書の構造に柔軟性があります。

(-)柔軟性は制限されます。XML Schemaに準拠する文書のみ格納できます。

XML Schemaの柔軟性

(++) XML Schemaに基づく文書とXML Schemaに基づかない文書のどちらも格納できます。登録されている任意のXML Schemaに準拠する文書を、同じXMLType表または列で格納できます。

(-)同じXML Schemaに準拠する文書のみを、特定のXMLType表または列に格納できます。

挿入時の検証

(++) XML Schemaに基づくデータは挿入時に完全に検証されますが、時間がかかります。

(+) XMLデータは挿入時に部分的に検証されます。

圧縮と暗号化

(+) SecureFiles LOB記憶域を持つバイナリXMLは、圧縮/暗号化が可能です。

(++)各XML要素/属性を個々に圧縮/暗号化できます。

親トピック: XMLType記憶域および索引付けの選択