Oracle Database 11g XML DBの技術概要

(1)

Oracle Database 11g XML DB の

技術概要

Oracle ホワイト・ペーパー

2007 年 5 月

(2)

ご注意

本書は、オラクルの一般的な製品の方向性を示すことが目的です。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。下記の事項は、マテリアルやコード、機能の提供を確約するものではなく、また、購買を決定する際の判断材料とはなりえません。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定いたします。

(3)

Oracle Database 11g XML DB の技術概要

はじめに ... 5

XML の概要... 5

データ交換および統合 ... 5

XML 中心のアプリケーション開発 ... 5

コンテンツおよびメタデータの管理 ... 6

サーバー・ベースの XML をサポートするための要件 ... 6

Oracle XML DB のアーキテクチャ... 7

XMLType 記憶域モデル ... 7

Oracle XML DB リポジトリ ... 8

Oracle XML DB プロトコル・アーキテクチャ... 9

Oracle XML DB 用 API（Java、PL/SQL、ODP.NET、および C）... 10

Oracle XML DB の機能 ... 10

XMLType ... 10

構造化、Binary XML、および非構造化記憶域モデル ... 11

構造化記憶域 ... エラー! ブックマークが定義されていません。

Binary XML 記憶域 ... 12

非構造化記憶域 ... 13

記憶域モデルの選択に関するガイドライン ... 14

索引を使用したパフォーマンスの向上 ... 16

B-Tree 索引... 17

XMLIndex 索引 ... 17

XML スキーマ... 18

スキーマのための W3C Schema ... 18

拡張可能な XML スキーマのデータ型基本セット... 19

XML スキーマにより統合されるドキュメント・

モデリングとデータ・モデリング ... 19

Create XMLType 表および列の作成と DOM の正確さの保証 ... 19

スキーマの拡張 ... 19

XQuery を使用した XML データおよびリレーショナル・

データの問合せ、変換、アクセス ... 20

SQL/XML XQuery 関数 ... 22

XQuery のリライト ... 22

SQL/XML の二重性 ... 23

SQL 標準の SQL/XML 関数 ... 24

XML データからのリレーショナル・ビューおよび

リレーショナル・データからの XML ビュー... 24

XMLType の更新、変換、および差分/パッチ操作... 25

(4)

Oracle XML DB に格納された XML コンテンツの更新... 25

XSL 変換と Oracle XML DB... 26

XMLDiff および XMLPatch を使用した XML ドキュメントの

比較とパッチの適用 ... 26

XML データのフルテキスト検索. ... 27

Oracle XML DB リポジトリ ... 27

フォルダリング ... 27

リソースのバージョニング ... 28

リポジトリ・リソースのセキュリティ ... 29

リポジトリ・メタデータ ... 29

リポジトリ・イベント ... 30

XLink および XInclude... 31

Oracle XML DB リポジトリ API ... 32

インターネット・プロトコルのサポート ... 32

ネイティブな Oracle XML DB Web サービス ... 33

Oracle XML DB 対応のエンドツーエンドの高性能

プログラミング言語 API ... 33

ORACLE XML DB アプリケーション開発ツール... 33

Oracle SQL Developer を使用したデータベース層の開発方法... 34

Oracle JDeveloper を使用した SOA アプリケーションの

開発方法... 34

ORACLE XML DB ライフ・サイクル開発ツール... 34

SQL*Loader のサポート ... 34

エクスポート/インポートのサポート... 34

トランスポータブル表領域のエクスポートとインポート... 34

Oracle Streams とロジカル・スタンバイによる XMLType の

サポート... 35

Oracle Enterprise Manager のサポート... 35

(5)

Oracle Database 11g XML DB の技術概要

はじめに

Oracle XML DB は、5 年前の登場以来、さまざまな要件を持つ広範な用途で、顧客やパートナーに広く利用されています。 Oracle XML DB は、5 年前の登場以来、さまざまな要件を持つ広範な用途で、顧客やパートナーに広く利用されています。また、Oracle XML DB は、高度なパフォーマンス、信頼性、可用性、スケーラビリティ、およびセキュリティ備えたリレーショナル・プラットフォームで、もっとも包括的な標準ベースの XML の格納、取得、およびパブリッシング機能を提供することを目指し、ここ数年、順調に発展してきました。

XML の概要

XML は、データ、コンテンツ、メタデータに統一モデルを提供するオープン・スタンダードです。XML は自己記述的で、人間とマシンの両方から簡単に読み取れます。また、ベンダー中立で拡張が可能です。これらの特長により、幅広い産業で XML が採用されています。XML 使用の大半は、次に説明する 3 つのカテゴリのいずれかに当てはまります。 • データ交換および統合 • XML 中心のアプリケーション開発 • コンテンツおよびメタデータの管理企業環境に共通する要件の 1 つは、これらの使用カテゴリを情報処理フローに統合することです。データ交換および統合ある推定によると、一般的な IT 予算の 40%は、統合に費やされています。疎結合で柔軟な XML ベースの統合では、密結合の統合と比較して、大幅にコストが削減され、また製品化までの時間が短縮されることが一貫して証明されています。このアプローチの成功は、サービス指向アーキテクチャ（SOA）における XML メッセージの成長を見れば明らかです。また、企業は、法令順守の要件を満たすために、このような一時的な XML の一部を格納する必要があることを認識し始めています。 XML 中心のアプリケーション開発多数の垂直産業で、XML は、情報交換の事実上の業界標準として独自仕様の EDI 技術を置き換えています。通常、この標準によって定義されるデータ構造は、非常に複雑であり、純粋なリレーショナル・モデルにマッピングするのが難しい再帰的な構造および他の複雑な構成メンバーを含んでいます。

(6)

多くの場合、このようなデータ構造は、Worldwide Web Consortium（W3C）XML Schema 標準1を使用して記述されます。XMLの量と複雑度が増大すると、XMLおよびリレーショナル・データ間のマッピングのコストおよびオーバーヘッドが急激に増大します。多くの企業は、このデータをXMLとしてデータベースに直接格納することで、開発コストを削減しようとしています。コンテンツおよびメタデータの管理この数年間に、AdobeのFrameMakerなど、いくつかのハイエンドのドキュメント作成システムが独自仕様形式またはSGMLからXMLの使用に移行しました。最近になって、Open Office2_{やMicrosoft Officeなどのデスクトップ生産性ツールで、ド}

キュメントをXMLとして格納する切替えが行われました。その結果、企業が効果的に管理する必要のあるXMLコンテンツが増加しています。また、XMLは柔軟であるため、他の形式のコンテンツに関するメタデータ管理の媒体として優れています。

サーバー・ベースの XML をサポートするための要件

データベースのユーザーは、パフォーマンスを実現するプラットフォームと、次世代の XML 中心のアプリケーションを簡単に開発する機能を必要としています。最新の XML 標準およびアプリケーション開発技術を使用して、そのようなプラットフォームを使用する能力が不可欠となります。XML の量とミッション・クリティカルな性質が増大すると、企業では効率的に検索する機能が必要となります。同時に、他の企業データと同様に、厳密かつ簡単に管理する機能が必要です。ユーザーには、既存のリレーショナル・データベースと同レベルのパフォーマンス、信頼性、可用性、スケーラビリティ、セキュリティを提供する XML プラットフォームが必要です。既存のデータベース・テクノロジが、これらの XML 要件を満たすために進化することにより、ハイブリッド・プラットフォームとして、XML とリレーショナル・データを同様に管理できるようになります。ハイブリッド・プラットフォームにより、データとビジネス・プロセスの複雑性が軽減され、大幅なコスト削減が実現し、企業への新しいインフラストラクチャ導入に伴うリスクが回避されます。このようなハイブリッド・データベースが真に有効なものとなるには、XML の生成、ロード、更新、取得、変換、索引付けのプロセスをできる限り単純で効率的にする XML 標準をサポートする必要があります。

Oracle XML DB を実装する Oracle Database は、XML およびリレーショナル・データの両方を管理できる実績のあるハイブリッド・データベースです。Oracle XML DB は、この数年間にわたる Oracle Database の 4 つの主要なデータベース・リリースに不可欠な一部分です。顧客は、Oracle XML DB 上に XML 中心のアプリケーションを効果的にデプロイしてきました。

Oracle XML DB を使用する Oracle Database は、XML およびリレーショナル・データの両方を管理するための実証されたハイブリッド・データベースです。Oracle XML DB は、この数年間にわたる Oracle Database の 4 つの主要なデータベース・リリースの不可欠な一部分です。 _{オラクルは、Binary XML 記憶域モデルという新しい記憶域モデルの導入、および} XMLIndex 索引、インプレース XML スキーマ・エボルーション、データベースのネイティブな Web サービス、複合ドキュメントなどの数多くの重要な新機能の導入により、このリリースにおいてさらなる躍進を遂げつつあります。 1_{http://www.w3c.org} 2_{http://xml.openoffice.org/}

(7)

Oracle XML DB のアーキテクチャ

Oracle XML DB は、XMLType 抽象化、XML DB リポジトリ、標準問合せ言語、 API サポート、プロトコル・サポートといったコア・コンポーネントに基づいて開発されています。各コンポーネントが、Oracle XML DB の重要な側面を担う豊富なサービス・セットを提供しています。以下のセクションでは、これらのコンポーネントについて詳しく説明します。 Oracle XML DB は、XMLType 抽象化、 XML DB リポジトリ、標準問合せ言語、 API サポート、プロトコル・サポートといったコア・コンポーネントに基づいて開発されています。 XML は、さまざまなユースケースに対応するため、構造化データと非構造化データの両方をサポートします。そのため、 Oracle XML DB の顧客は、それぞれ異なる特徴を持つ XML の各種記憶域オプションや索引付けオプションを使用して、最適なデータ記憶域と問合せを実現できます。このようなさまざまなユースケースに対応するには、画一的なソリューションでは不十分です。

XMLType 記憶域モデル

Oracle XML DB は、それぞれ異なる要件を持つ多様な XML のユースケースに対応するために、包括的な記憶域モデル（構造化、非構造化、および Binary XML 記憶域モデル）をサポートしています。現在、顧客のユースケースの大半はデータ中心であるため、構造化記憶域が適しています。しかし、ドキュメント中心の Binary XML および XMLIndex 索引を使用したユースケースが確実に増加しており、これらのケースとはまったく異なります。 XML は、さまざまなユースケースに対応するため、構造化データと非構造化データの両方をサポートします。そのため、Oracle XML DB の顧客は、それぞれ異なる特徴を持つ XML の各種記憶域オプションや索引付けオプションを使用して、最適なデータ記憶域と問合せを実現できます。このようなさまざまなユースケースに対応するには、画一的なソリューションでは不十分です。下の図は、実際の XML ユースケースと、それに対応する XML 記憶域モデル、および Oracle XML DB

(8)

データ中心ハイブリッド（構造化および CLOB 記憶域） B-Tree、XMLIndex、およびフルテキスト索引構造化記憶域 B-Tree 索引ドキュメント中心 Binary XML または CLOB 記憶域 XMLIndex およびフルテキスト索引 Binary XML または CLOB 記憶域 XMLIndex およびフルテキスト索引非構造化構造化 ドキュメントの構成要素 表の垂直の列は、ドキュメントがデータ中心であるかまたはドキュメント中心であるかを示しています。水平の列は、ドキュメント内に構造化コンポーネントが含まれているか、または非構造化コンポーネントが含まれているかどうかを示しています。右上の四分の一は、スキーマを使用する構造化記憶域と B-tree 索引が適しているデータ中心の XML を示しています。左上の四分の一は、特定の非構造のフラグメントを含むデータ中心の XML を示しています。このユースケースの場合、最適な記憶域モデルは、CLOB として格納された非構造化部分を含む構造化記憶域と XMLIndex 索引を使用するモデルになります。左下の四分の一は、完全なドキュメント中心の XML を示しています。この場合、Binary XML または CLOB 記憶域と XMLIndex 索引を使用したモデルが推奨されます。右下の四分の一は、特定の構造化部分を含むドキュメント中心の XML を示しています。Binary XML または CLOB 記憶域と XMLIndex 索引を使用したモデルが最適です。

Oracle XML DB リポジトリ

リレーショナル・モデルの表、行、および列のメタファは、構造化データを管理するための効果的なメカニズムとして認められています。しかし、ドキュメント中心の XML などの半構造化データおよび非構造化データを管理する場合には、それほど有効ではありません。たとえば、1 冊の本を 1 つの表の一連の行として表現するのは簡単ではありません。1 冊の本は、book:chapter:section:paragraph といった階層で表現し、階層を一連のフォルダおよびサブフォルダで表した方が自然です。 Oracle XML DB リポジトリは、ファイル・システム内のファイルとして XML データを処理するために最適化された、Oracle Database のコンポーネントです。Oracle XML DB リポジトリには、リソースが含まれます。リソースは、フォルダ（ディレクトリ、コンテナ）またはファイルのどちらかです。各リソースには、次のプロパティがあります。 Oracle XML DB リポジトリは、ファイル・システム内のファイルとして XML データを処理するために最適化された Oracle Database のコンポーネントです。 • パスと名前で識別される。 • コンテンツ（データ）を持つ。コンテンツは XML データの場合もあるが、 XML データである必要はありません。 • コンテンツに加え、所有者、作成日などの一連のシステム定義されたメタデータ（プロパティ）を持つ。Oracle XML DB は、この情報を使用してリソースを管理します。 • ユーザー定義されたメタデータを持つ場合もある。ユーザー定義のメタデータには、コンテンツの一部ではなく、コンテンツに関連付けられた情報などがあります。 • 誰がリソースにアクセスでき、どの操作を実行できるかを指定する、関連付

(9)

Oracle XML DB リポジトリは特に XML コンテンツを処理しますが、Oracle XML DB リポジトリを使用して、XML 以外のその他の種類のデータを格納することもできます。つまり、リポジトリを使用すると、Oracle Database に格納された任意のデータにアクセスできます。次の方法で、Oracle XML DB リポジトリ内のデータにアクセスできます。 • SQL を使用して、RESOURCE_VIEW ビューおよび PATH_VIEW ビューからアクセスする。 • PL/SQL を使用して、DBMS_XDB API からアクセスする。

• Java を使用して、標準の JSR 170 Content Repository API または Java 対応の Oracle XML DB リソース API からアクセスする。データにアクセスして操作する API をサポートする以外に、Oracle XML DB リポジトリは、次のサービスに対応した API を提供しています。 • バージョニング - Oracle XML DB は、Oracle XML DB リポジトリ内のリソースをバージョニングするために、DBMS_XDB_VERSION PL/SQL パッケージを使用します。その後、リソースを更新すると新しいバージョンが作成されます（旧バージョンに対応するデータは格納されます）。バージョニングのサポートは、IETF WebDAV 標準に基づいています。 • ACL セキュリティ - Oracle XML DB リソース・セキュリティはアクセス制御リスト（ACL）に基づいています。Oracle XML DB 内のリソースごとに、それぞれの権限を指定する、関連付けられた ACL があります。リソースがアクセスまたは操作されるたびに、ACL はその操作を許可するかどうかを判断します。ACL は、一連のアクセス制御エントリ（ACE）を含む XML ドキュメントです。各 ACE が、特定のユーザーまたはグループ（データベース・ロール）に対して一連の権限を許可するか、取り消します。このアクセス制御メカニズムは、WebDAV 仕様に基づいています。 • フォルダリング - Oracle XML DB リポジトリは、その他のリソース（ファイルまたはフォルダ）を含むフォルダ（ディレクトリ）リソースの永続的な階層を管理します。プロトコル・サーバー、スキーマ・マネージャ、Oracle XML DB の RESOURCE_VIEW API などの Oracle XML DB モジュールは、フォルダリングを使用して、パス名をリソースにマッピングします。 Oracle XML DB プロトコル・アーキテクチャ SQL、PL/SQL、Java、C 言語に加えて、FTP、HTTP(S)、WebDAV などの標準の接続アクセス・プロトコルを使用して、Oracle XML DB リポジトリ内の XML ドキュメントにアクセスできます。リポジトリにより、コンテンツの作成者と編集者は、 Oracle Database に格納された XML コンテンツに直接アクセスできます。 SQL、PL/SQL、Java、C 言語以外にも、 FTP、HTTP(S)、WebDAV などの標準の接続アクセス・プロトコルを使用して、 Oracle XML DB リポジトリ内の XML ドキュメントにアクセスできます。このコンテキストにおけるリソースとは、URL によって識別されるファイルまたはフォルダです。WebDAV は、HTTP プロトコルの一連の機能拡張を定義している IETF 標準です。これによって、HTTP サーバーは DAV 対応クライアントのファイル・サーバーとして機能できます。たとえば、WebDAV 対応のエディタは、ファイル・システムを使用する場合と同様に、HTTP/WebDAV サーバーとやり取りできます。WebDAV 標準では、ファイルまたはフォルダのことを、リソースと呼びます。WebDAV サーバーによって管理される各リソースは、URL で識別されます。 Oracle XML DB は、これらのプロトコルのネイティブ・サポートを Oracle Database に追加します。

(10)

プロトコルは、ドキュメント中心の操作向けに設計されています。Oracle XML DB がこれらのプロトコルをサポートしているため、Windows Explorer や Microsoft Office、および Altova、Macromedia、Adobe などのベンダー製品は、Oracle XML DB リポジトリに格納された XML コンテンツを直接使用できます。

Oracle XML DB アーキテクチャの重要な機能の 1 つは、共有サーバー構成で Oracle Data Provider for .NET（ODP.NET）をサポートするために使用されているものと同じアーキテクチャを使用して、HTTP(S)、WebDAV、FTP プロトコルがサポートされている点です。リスナーは、ODP.NET サービス・リクエストをリスニングするのと同じ方法で、HTTP(S)および FTP リクエストをリスニングします。リスナーは、 HTTP(S)または FTP からリクエストを受け取ると、それを Oracle Database 共有サーバー・プロセスに渡します。共有サーバー・プロセスは、そのリクエストを処理し、適切な応答をクライアントに送信します。TNS リスナー・コマンドの lsnrctl status を使用すると、HTTP(S)および FTP サポートが有効であることを確認できます。

Oracle XML DB 用 API（Java、PL/SQL、ODP.NET、および C）

Oracle XML DB には、Java、PL/SQL、C などの一般的なプログラミング言語 API からアクセスできます。Oracle XML DB は、DOM API の Java、PL/SQL、および C 実装を備えています。サーブレットに基づく API などの JDBC を使用するアプリケーションの場合は、事前にそれらが処理するデータ構造について理解しておく必要があります。Oracle JDBC ドライバを使用すると、XMLType 表および列にアクセスしたり、それを更新できます。また、Oracle XML DB リポジトリにアクセスする PL/SQL プロシージャを呼び出すことができます。XSLT 変換に基づくような DOM を使用するアプリケーションの場合は、通常、データ構造に関する知識をあまり必要としません。DOM ベースのアプリケーションは、文字列名を使用してコンテンツの各部分を識別しているため、必要な情報を検索するために DOM ツリー内を動的に走査する必要があります。このため、Oracle XML DB は、DOM API を使用した XMLType 表および列に対するアクセスと更新をサポートしています。DOM API のプログラミングは JDBC を介したプログラミングより柔軟ですが、実行時により多くのリソースが必要となる場合があります。

Oracle XML DB の機能

ここでは、前述したアーキテクチャを備えた Oracle XML DB の個々の機能について説明します。

XMLType

柔軟性と多様性を提供するために、Oracle XML DB は、XML データの格納、問合せ、アクセス、変換、および操作を行うための XMLType 抽象型を実装しています。 XMLType は、XML データのネイティブなデータ型です。XML スキーマの妥当性検証や XML コンテンツ上の XSL 変換などの操作を可能にするメソッドを提供します。XMLType は、その他のデータ型と同様に使用できます。たとえば、次のいずれかを実行する場合に、XMLType を使用できます。 XMLType は、XML データのネイティブなデータ型です。XML スキーマの検証や XML コンテンツ上の XSL 変換などの操作を可能にするメソッドを提供します。 • リレーショナル表の列の作成 • PL/SQL 変数の宣言

(11)

• PL/SQL プロシージャと関数の定義および呼び出しまた、XMLType はオブジェクト・タイプであるため、XMLType インスタンスの表も作成できます。デフォルトでは、XMLType 表または列に、整形式な XML ドキュメントを含めることができます。 XMLType 表または列は、XML スキーマに準拠するために制約を加えることができます。これにはいくつかの利点があります。 • データベースは、確実に XML スキーマへの妥当性が検証された XML ドキュメントだけを表または列に格納します。 • 表または列のコンテンツが既知の XML 構造に準じているため、Oracle XML DB は XML スキーマに含まれた情報を使用して、XML に最適な問合せおよび更新処理を提供できます。 • 構造化記憶域を使用して XML ドキュメントのコンテンツを格納するオプションがあります。このオプションは、ドキュメントを分割し、それを一連のオブジェクト・リレーショナル・オブジェクトとして格納します。ドキュメントを格納するために使用されるオブジェクト・リレーショナル・モデルは、XML スキーマから派生したものです。

構造化、Binary XML、および非構造化記憶域モデル

XMLType は、ご使用のデータおよびユースケースの最適化を可能にする、さまざまな記憶域モデルに対応した抽象的なデータ型です。抽象的なデータ型であることから、すべての XMLType 操作で同一のインタフェースを使用できるため、アプリケーションとデータベースにおける問合せの柔軟性が向上します。Oracle XML DB は、ユーザーが保持している XML データの種類とその使用パターンにもっとも適した記憶域モデルを選択し、パフォーマンスと機能性を最適化できるように、さまざまな記憶域（永続化）モデルをサポートしています。そのため、XML データを XMLType として維持するために、いつ Oracle XML DB を使用し、どの XML データに対してどの記憶域モデルを使用するかが、重要な決定事項の 1 つとなります。 XMLType 記憶域は、データベースのインポート/エクスポートを使用して、あるモデルから別のモデルに変更できます。使用中のアプリケーション・コードを変更する必要はありません。アプリケーションを調整する場合は、XML 記憶域・オプションを変更できます。各記憶域・オプションにはそれぞれ固有の利点があります。 XMLType 表および列は、次の方法で格納できます。 • 構造化記憶域 - XMLType データは一連のオブジェクトとして格納されます。これは、構造化記憶域およびオブジェクト・ベースの永続化モデルとして参照されます。 • Binary XML 記憶域 - XMLType データは、特に XML データ用に設計された解析済みのバイナリ形式で格納されます。Binary XML は、コンパクトで解析済みの XML スキーマを認識する形式です。これは、解析済みの永続化モデルとして参照されます。 • 非構造化記憶域 - XMLType データは、キャラクタ・ラージ・オブジェクト（CLOB）インスタンスに格納されます。これは、CLOB 記憶域およびテキスト・ベースの永続化モデルとして参照されます。さらに、構造化記憶域と非構造化記憶域を組み合わせて、ハイブリッド記憶域として使用することもできます。

(12)

ハイブリッド記憶域の構造化部分では構造化記憶域機能を活用し、ハイブリッド記憶域の非構造化部分では非構造化記憶域の利点を活用します。

Binary XML と非構造化記憶域は、どちらも SecureFile と BasicFile の 2 つの LOB 記憶域オプションをサポートしています。SecureFile は、このリリースの革新的な新機能であり、半構造化データと非構造化データを対象に、高パフォーマンスかつスケーラブルに格納および取得を実行できます。各記憶域モデルは、ユースケースや XML データの特徴に依存した利点を備えています。構造化記憶域非構造化記憶域に比べ構造化記憶域の優れている点としては、最適化されたメモリー管理、軽減された記憶域要件、B-tree 索引付け、部分更新があります。ただし、これらの利点には、XML データの取得時に処理オーバーヘッドが増加する、特定の XMLType 表または列で管理可能な XML 構造の柔軟性が低減するといった欠点を伴います。構造化記憶域内でデータとメタデータ（列名など）が分離され、インスタンス構造を簡単には変更できないためです。構造化記憶域は、特に、管理可能な数のデータベース表の結合にマッピングされていることを前提に、頻繁に変更されない高度に構造化されたデータに適しています。 Binary XML 記憶域 Binary XML 記憶域は、非構造化記憶域よりも、更新、索引付け、部分抽出に優れた効率的なデータベース記憶域です。また、非構造化記憶域よりも高パフォーマンスな問合せを実現できます。XML 解析のボトルネックの影響を受けることはありません（解析済み永続性モデル）。構造化記憶域と同様に、Binary XML 記憶域も XML スキーマのデータ型を認識でき、ネイティブなデータベース・データ型を利用できます。また、非構造化記憶域と同様に、データベースの挿入または取得時にデータを変換する必要がありません。さらに、Binary XML 記憶域は、構造化記憶域と同様に、部分更新ができます。Binary XML データはデータベース外部でも使用できるため、効率的な XML 交換メディアとして利用し、多くの場合、データベースの負荷を軽減しパフォーマンス全体を向上させることができます。 Binary XML データは、非構造化記憶域と同様に、ドキュメントの順番を保持します。さらに、構造化記憶域と同様に、バイナリ記憶域を使用してデータとメタデータをデータベース・レベルで分離し、効率を高めることができます。ただし、非構造化記憶域と同様に、バイナリ記憶域では、データとメタデータを混在させることが可能なため、それに応じてインスタンス構造も異なります。Binary XML 記憶域は、構造化記憶域モデルで多数のデータベース表と結合して得られる非常に複雑な可変データを扱うことができます。その他の XMLType 記憶域モデルとは異なり、XML スキーマが事前にわかっていない場合でも、XML スキーマ・ベースのデータに対してバイナリ記憶域を使用できます。さらに、複数の XML スキーマを同一の表に格納し、共通の要素について問合せを実行できます。 Binary XML 記憶域では、非構造化記憶域に比べ、より効率的にデータベースの記憶域、更新、索引付け、部分抽出を実行できます。 XML スキーマ・ベースのデータを Binary XML の XMLType 表または列に挿入すると、データは XML スキーマに対して完全に検証されます。データが無効な場合、挿入は失敗します。

(13)

Binary XML 記憶域は、XML データの汎用的な記憶域モデルにもっとも近いモデルです。つまり、ドキュメント中心からデータ中心に至るまでの広範なユースケースにおいて、このモデルを効果的に使用できます。ストリーミングXMLスキーマの検証 XML スキーマの妥当性検証は、XML 処理の中でもコストのかかる手順の 1 つです。Binary XML 記憶域オプションでは、スキーマの検証は新しいストリーミング実装を使用して実行されます。ストリーミング XML スキーマ検証は、あまりメモリーを必要としません。したがって、非常に効率的に実行され、大量の XML ドキュメントやサイズの大きい XML ドキュメントを検証する場合でも十分に適応できます。ストリーミングXPath処理ストリーミング XPath エンジンは、非決定性有限オートマトン（NFA）として実装されます。一連の XPath をコンパイルして 1 つのステート・マシンに送り込んだ後、複数のインスタンス・ドキュメントを順次渡して、1 回のストリーミングですべての XPath を評価します。部分更新ユーザーは、正規の SQL UPDATE 文と、UPDATEXML、INSERTXMLBEFORE、 APPENDCHILDXML、DELETEXML などの部分更新の SQL 演算子を使用して、バイナリ形式で格納された XML ドキュメントを更新できます。ユーザーが元のドキュメントの一部分だけを更新した場合、システムは、ドキュメント全体を置き換えるのではなく、影響を受ける部分だけを置き換えて、更新を最適化します。この機能は、SecureFile 記憶域オプションを使用してスライディング・インサート（CLOB 値全体を置き換えることなく基本となる BLOB の一部を更新）を実行する機能に依存しています。部分更新の最適化は、ユーザーの構文やセマンティクスの点から見ると完全に透過的です。I/O およびロギングのオーバーヘッドが削減されるため、パフォーマンスが向上するという利点がもたらされます。非構造化記憶域非構造化記憶域では、構造化記憶域に比べ、XML ドキュメント全体の挿入および取得時に、より高いスループットを実現できます。データ変換が不要なため、データベース外部でも同じ形式を使用できます。また、非構造化記憶域は、構造化記憶域よりかなり柔軟にさまざまな XML 構造を格納できます。特に、非構造化記憶域は、ドキュメント中心のユースケースに適しています。これらの利点の代わりに、インテリジェント処理の一部が損なわれる場合があります。たとえば、索引付けが欠落した場合、データベースは、CLOB インスタンスに格納された XML データへの問合せや更新の最適化をほとんど実行できません。特に、XML 解析のコストは、（通常は暗黙的に）問合せパフォーマンスに大きな影響を与える場合があります。

(14)

XMLIndex を使用して索引付けすると、非構造化記憶域に対する問合せのパフォーマンスを改善できます。記憶域モデルの選択に関するガイドライン以下に、各記憶域モデルの相対的な利点と、特定のユースケースでの記憶域モデルの選択に関するガイドラインを示します。 構造化 記憶域 Binary XML 記憶域 非構造化 記憶域 スループット - XML ドキュメントのコンテンツ全体を登録する際に、XML 分解によりスループットが低下することがある。 ++ 高いスループット。高速 DOM ローディング。 + XML ドキュメントのコンテンツ全体を登録する際のスループットが高い。容量の効率（ディスク） ++ 容量効率が極めて高い。 + 容量効率が高い。 - 重要でない空白スペースと反復されるタブがほとんどのディスク容量を消費。データの柔軟性 - 限定された柔軟性。 XML スキーマに準拠するドキュメントのみ XMLType 表または列に格納可能。 + 柔軟性のある XML 構造を XMLType 表または列に格納可能。 + 柔軟性のある XML 構造を XMLType 表または列に格納可能。 XML スキーマの柔軟性 - 比較的柔軟。データとメタデータは個別に格納される。同じ XMLType 表で複数の XML スキーマは使用できない。 ++ 柔軟。データとメタデータは、一緒にまたは個別に格納できる。同じ XMLType 表で複数の XML スキーマを使用できる。 + 柔軟。データとメタデータは一緒に格納される。同じ XMLType 表で複数の XML スキーマを使用できない。

(15)

構造化 記憶域 Binary XML 記憶域 非構造化 記憶域 表 XML 再現性 - DOM 再現性：データベースに格納されている XML ドキュメントから作成した DOM は、元のドキュメントから作成された DOM と同じになる。ただし、余分な空白は削除されることがある。 - DOM 再現性：（構造化記憶域の説明を参照）。 + ドキュメント再現性：元の XML データ、バイト単位を維持。特に、元の空白はすべて保持される。更新操作（DML） ++ インプレースの部分更新。 + SecureFile LOB 記憶域の場合、インプレースの部分更新。 - ドキュメントの一部が更新された場合、ドキュメント全体をディスクに書き込み直す必要がある。 XQuery ベースの問合せと XPath ベースの問合せ ++ XPath 操作は、通常 XPath リライトを使用して評価可能で、特に多数のドキュメントが対象の場合にパフォーマンスが大幅に改善される。 + ストリーミング XPath 評価では、DOM の構築が回避され、単一のパスで複数の XPath 式を評価できる。ナビゲーション XPath 評価は、非構造化記憶域に比べかなり高速である。 XMLIndex 索引付けにより、問合せパフォーマンスを大幅に改善できる。 - XPath 操作は、機能評価を使用して CLOB データから DOM を構築することで評価される。サイズの大きいドキュメントまたは多数のドキュメントを対象に操作を実行すると、負荷が高くなる。XMLIndex 索引付けにより、問合せパフォーマンスを大幅に改善できる。 SQL 制約のサポート + SQL 制約はサポートされている。 + SQL 制約はサポートされている。 - SQL 制約は使用不可能。 SQL スカラー・データ型のサポート + 有 + 有 - 無索引付けのサポート B-tree 、 Oracle テキスト、およびファンクション索引。 XMLIndex 、ファンクション、Oracle テキスト索引。 XMLIndex 、ファンクション、Oracle テキスト索引。最適化されたメモリー管理 + メモリー要件を低減するように、XML 操作を最適化できる。 + メモリー要件を低減するように、XML 操作を最適化できる。ドキュメントに対して XML 操作を実行するには、そのドキュメントから DOM を作成する必要がある。挿入時の検証 XML データは、挿入時 + XML スキーマ・ベー XML スキーマ・ベース

(16)

構造化 記憶域 Binary XML 記憶域 非構造化 記憶域 る。に完全に検証される。部分的に検証される。

索引を使用したパフォーマンスの向上

Oracle XML DB は、各種記憶域モデルにおいて、XML コンテンツのさまざまな索引の作成をサポートしています。 • B-Tree索引。XMLType表または列が構造化記憶域技術に基づいている場合は、基本となるSQL型に応じて従来のB-Tree索引を作成できます。 • XMLIndex索引。XMLIndex索引は、Binary XML、非構造化、およびハイブリッド記憶域を使用しているXMLデータの内部構造を索引付けする汎用的な XML固有の索引を提供します。

(17)

• ファンクション索引。関数ベースの索引をXMLType表または列に作成できます。非構造化記憶域上の事前に定義されたXPath問合せにしか使用できません。 • フルテキスト索引。フルテキスト索引は、XMLType表または列に作成できます。 B-Tree 索引 B-tree 索引は、existsNode などの関数に基づいて索引を作成できますが、通常は SQL 関数 extractValue を使用して作成されます。索引作成プロセスで、Oracle XML DB は、XPath リライトを使用して、CREATE INDEX 文で使用されている XPath 式が、参照されているノードと基本となる SQL 型の属性をマッピングできるかどうかを判断します。XPath 式内のノードが SQL 型の属性とマッピングできる場合は、基本となる SQL オブジェクトに応じた従来の B-Tree 索引として索引が作成されます。XPath 式をオブジェクト・リレーショナル SQL で表現できない場合は、ファンクション索引が作成されます。 XMLIndex 索引 XMLIndex は、XML データの内部構造を索引付けする汎用的な XML 固有の索引を提供します。主な目的の 1 つは、XML データの非構造化記憶域とハイブリッド記憶域、つまり CLOB 記憶域による索引付けの制限を解消することです。これを実現するため、ドキュメントの XML タグを索引付けし、それらを対象とする XPath 式に基づいてドキュメント・フラグメントを識別しています。また、個々の値や値の範囲に基づいて迅速に検索するために、スカラー・ノード値を索引付けすることもできます。さらに、親と子、祖先と子孫、兄弟といった関係を索引付けした、各ノードのドキュメント階層情報を記録することもできます。 XMLIndex は、XML データの内部構造を索引付けする汎用的な XML 固有の索引を提供します。パスのサブセット化による索引サイズの縮小 XMLIndex の利点の 1 つは、非常に汎用的であることです。つまり、索引付けする XPath の場所を指定する必要はなく、問い合わせる XPath 式を事前に理解しておく必要もありません。デフォルトでは、XMLIndex は XML データ内の候補となるすべての XPath の場所を索引付けします。ただし、問合せを行う可能性がもっとも高い XPath 式がわかっている場合は、 XMLIndex の索引付けの対象範囲を狭め、パフォーマンスを向上させることができます。不要な索引数が少ないほど、索引付けに必要な容量も少量で済むため、 DML 操作での索引のメンテナンスが改善されます。また、索引付けされたノード数が少ないほど DDL パフォーマンスは向上し、パス表のサイズが小さいほど問合せパフォーマンスも高くなります。索引付けの対象範囲を狭めるには、索引付けする各 XML フラグメントに対応する一連の XPath 式（パス）から不要なパスを取り除き、候補となるパスをすべて含めたサブセットを指定します。これは、次の 2 通りの方法で実行できます。 • 除外 - 最初に、すべての候補となる XPath 式を内包させるデフォルト動作を実行し、その後、索引付けの対象からそれらの一部を除外します。

(18)

• 包含 - 最初に XPath 式の空のセットを使用して索引付けし、この内包セットにパスを追加します。

CREATE INDEX を使用して XMLIndex 索引を作成する場合、または ALTER INDEX を使用して変更する場合には、パスのサブセットを指定できます。どちらの場合も、文の PARAMETERS 句の PATHS パラメータで、サブセット化の情報を提供できます。除外する場合は、キーワード EXCLUDE を使用します。包含する場合は、ALTER INDEX でキーワード INCLUDE を使用し、さらに、キーワードを指定せずに CREATE INDEX（包含するパスをリストする）を使用します。また、 PATHS パラメータの対象ノードに名前空間のマッピングを指定できます。非同期索引メンテナンスデフォルトで、XMLIndex 索引付けは、元表との同期を保つために、各 DML 操作で維持されます。状況によっては、同期を保持する必要がなく、古い索引の使用が許容されている場合もあります。そのようなユースケースでは、索引のメンテナンスをコミット時だけに実行したり、データベースの負荷が低減したときに実行したりすることで、それにかかるコストを先延ばしにできます。これにより、 DML パフォーマンスを改善できます。また、索引が同期化されている場合は、非同期の索引行のバルク・ロードを有効にすることで、索引メンテナンスのパフォーマンスも改善できます。 Oracle XML DBリポジトリでのXMLIndexの使用方法データベース管理者は、Oracle XML DB リポジトリ内のリソース上で XMLIndex 索引を作成して、XML データまたはメタデータ（システム定義またはユーザー定義）の問合せを改善できます。DBMS_XDB_ADMIN パッケージには、Oracle XML DB リポジトリで XMLIndex 索引を作成し維持するためのプロシージャが含まれています。XMLIndex が作成されると、リソースへの問合せを効果的に利用できるようになるため、問合せの実行を最適化できます。

XML スキーマ.

Worldwide Web Consortium（W3C）XML Schema 勧告のサポートは、Oracle XML DB における重要な機能の 1 つです。XML スキーマは、一連の XML ドキュメントの構造、コンテンツ、および特定のセマンティクスを指定します。スキーマのための W3C Schema W3C Schema ワーキング・グループは、XML スキーマを公開しています。これは、通常"スキーマのためのスキーマ"と呼ばれています。この XML スキーマは、XML スキーマ言語の定義、つまりボキャブラリを提供します。XML スキーマ定義（XSD）は、スキーマのためのスキーマによって定義されたボキャブラリに準拠した XML ドキュメントです。XML スキーマは、W3C XML Schema ワーキング・グループによって定義されたボキャブラリを使用して、型定義と要素宣言の集合を作成します。要素宣言は、新しいクラスの XML ドキュメントのコンテンツと構造を記述するための共有ボキャブラリを宣言します。

(19)

拡張可能な XML スキーマのデータ型基本セット XML スキーマ言語では、要素と属性が強力に型付けされます。多数のスカラー・データ型が定義されています。継承や拡張などのオブジェクト指向技術を使用して、このデータ型の基本セットを拡大し、より複雑な型を定義できます。XML スキーマのボキャブラリには、複雑な型、置換グループ、繰り返し設定、ネスト、順番などを定義するために使用できる構成メンバーも含まれています。Oracle XML DB は、redefines を除き、XML Schema 勧告で定義されているすべての構成メンバーをサポートします。 XML スキーマは、一般に、XML インスタンス・ドキュメントがそれぞれの仕様に準拠しているかどうかを確認（検証）するためのメカニズムとして使用されます。 Oracle XML DB には、XML ドキュメントを XML スキーマに照らし合わせて検証するために使用できる XMLType メソッドと SQL 関数が組み込まれています。 XML スキーマにより統合されるドキュメント・モデリングとデータ・モデリング Oracle XML DB では、XML スキーマを使用して、データベース表と XML データを格納するためのデータ型を自動的に作成できます。これによって、データが構造化、非構造化、または半構造化であるかどうかに関係なく、すべてのデータに対して標準データ・モデルを使用できます。 XMLType 表および列の作成と DOM 再現性 XML スキーマ・ベースの XMLType 表と列を作成し、オプションで、それらの表と列を事前に登録した XML スキーマに準拠させ、DOM 再現性を維持するように指定できます。スキーマの拡張 Oracle XML DB で XML スキーマを使用する開発者の大きな課題の 1 つは、XML ドキュメントのコンテンツまたは構造の変更をどのように処理するかという点です。環境によっては、新たな規制、社内外のニーズをきっかけとして、頻繁または広範な変更が必要となることがあります。たとえば、新しい要素や属性を XML スキーマ定義に追加したり、データ型を変更したり、特定の状況に関する最小要件および最大要件を緩和または強化したりする必要が生じることがあります。このような場合には、既存のインスタンス・ドキュメント（データ）を有効なまま（または有効化可能なまま）維持し、さらに既存のアプリケーションを継続して実行できる状態を維持しながら、新しい要件を満たすように XML スキーマを" 拡張"する必要があります。当然、既存のドキュメントに配慮する必要がない場合は、XML スキーマに依存している XMLType 表を破棄し、古い XML スキーマを削除して、同じ URL に新しい XML スキーマを登録するだけです。ただし、大半の場合は、既存のドキュメントを維持し、新しい XML スキーマに対応できるようにそれらを変換する必要があります。

(20)

Oracle XML DB は、2 種類のスキーマの拡張をサポートしています。アプローチごとに、専用の PL/SQL プロシージャがあります。それらは、コピー・ベース拡張用の DBMS_XMLSCHEMA.copyEvolve と、インプレース・スキーマ拡張用の DBMS_XMLSCHEMA.inPlaceEvolve です。 Oracle XML DB は、2 種類のスキーマの拡張をサポートしています。 XQuery 1.0 は、問合せ、変換、および XML データとリレーショナル・データへのアクセスを実行するために設計された W3C 標準言語です。インプレース・スキーマを使用した拡張インプレース XML スキーマの拡張では、既存のデータをコピー、削除、再挿入する必要はなく、XML スキーマを変更します。そのため、インプレース・スキーマの拡張は、コピー・ベースの拡張に比べかなり高速です。一般に、インプレース・スキーマの拡張は、記憶域モデルを変更せず、変更内容が既存のドキュメントに影響しない場合（つまり、既存のドキュメントが新しいスキーマに準拠しているか、準拠可能な状態である場合）に実行できます。コピー・ベースのスキーマを使用した拡張コピー・ベースのスキーマの拡張では、スキーマに準拠するすべてのインスタンス・ドキュメントがデータベース内の一時領域にコピーされ、古いスキーマが削除され、変更後のスキーマが登録されます。その後、インスタンス・ドキュメントは一時領域から新しい場所へ挿入されます。インプレース・スキーマの拡張を実行する場合と同様の制限はありませんが、コピー・ベースのスキーマの拡張では、関連付けられたインスタンス・ドキュメントが多数存在する場合に、長い時間がかかることがあります。

XQuery を使用した XML データおよびリレーショナル・データの

問合せ、変換、アクセス

XQuery 1.0 は、問合せ、変換、および XML データとリレーショナル・データへのアクセスを実行するために設計された W3C 標準言語です。多くの点で SQL に似ていますが、SQL は構造化リレーショナル・データを問い合わせる目的で設計されているのに対し、XQuery は特に、各種データ・ソースから半構造化 XML データを問い合わせる目的で設計されています。XQuery を使用すると、XML データがデータベース表に格納されているか、Web サービスを介して入手可能であるか、または別の方法で直接作成されたかに関係なく、その XML データが見つかりさえすれば、問合せを実行できます。XQuery は、XML データの問合せ以外に、XML データを作成するために使用することもできます。この点において、XQuery は、 XSLT や XMLElement といった、その他の SQL/XML パブリッシュ関数の両方に対して、代替または補完機能として動作させることができます。

XQuery は、Post-Schema-Validation Infoset（PSVI）データ・モデルに基づいて開発されています。PSVI は、XML Information Set（Infoset）データ・モデルと XML Schema 型システムを一体化したものです。XQuery は、シーケンスに基づいて新しいデータ・モデルを定義します。各 XQuery 式の結果が、1 つのシーケンスとなります。 XQuery は、シーケンスを操作するだけです。この側面から見ると、シーケンスが順序付けられ、重複項目を含めることができる点を除けば、XQuery はセット操作言語に似ています。ネスト化された XQuery シーケンスは結果的に常にフラット化される点で、XQuery シーケンスとその他の言語シーケンスとは異なります。多くの場合、最大に最適化するために、シーケンスは順序に関係なく（非順序として）処理されます。これが可能な場合、シーケンスの順序はユーザーが制御します。

(21)

この非順序モードは、ネスト化された反復を処理する際の結合順序（for）、および XPath 式の処理（たとえば、/a/b で、ドキュメントの順序に関係なく b 要素とのマッチングを処理できる）に適用できます。 XQuery シーケンスは、アトミック（スカラー）値または XML ノードのどちらかである 0 個以上の項目から構成されます。項目は、XML スキーマの型に基づく豊富な型体系を使用して型付けされます。この型体系は、ブール値、数値、文字列などの単純なスカラー型に限定されていた XPath 1.0 の型体系から大幅に変更されています。 XQuery は、関数型言語です。つまり、候補となる一連の式から構成され、各式が評価されて値（XQuery の場合は、シーケンス）を返します。また、XQuery は、一般的に関数型言語として指示的に透明です。つまり、同じコンテキストで評価された同じ式は、同じ値を返します。これは理想的な数学的性質ですが、次に示す例外があります。 • 外部環境とのやり取りから値を導き出す XQuery 式。たとえば、 fn:current-time(...)、fn:doc(...)などの式は、変わる可能性のある外部条件（時間の変化、対象ドキュメントのコンテンツが変更される可能性）によって左右されるため、常に同じ値を返すとは限りません。場合によっては、fn:doc などの XQuery は、1 回の問合せの実行範囲内で指示的に透明になるように定義されます。つまり、1 回の問合せの中で、同じ引数を指定して fn:doc を呼び出すと、結果は毎回同じドキュメントになります。 • 特定の XQuery 言語実装に依存するように定義された XQuery 式。このような式の評価結果は、実装によって異なる場合があります。基本的に実装によって定義される関数の例として、fn:doc 関数があります。指示の透明性は、XQuery 変数にも当てはまります。つまり、同じコンテキスト内の同じ変数は、同じ値を返します。この点で、手続き型または命令型のプログラミング言語とは異なり、関数型言語は数学的な形式主義に似ています。手続き型言語の変数は、実際にはメモリー位置の名前であり、常に、そのコンテンツによって表される現在値（または状態）を保持しています。XQuery などの宣言型言語の変数は、実際には固定値の名前です。 FLWOR式

FLWOR は、XQuery のもっとも一般的な式構文です。FLWOR（"フラワー"と呼びます）は、for、let、where、order by、return の略です。FLWOR 式は、少なくとも 1 つの for 句または let 句と、1 つの return 句を持ちます。単一の where 句および order by 句はオプションです。

• for - 1 つまたは複数の各変数を値にバインドしますが、順番に何回でもバインドできます。つまり、各変数についてバインドが繰り返され、繰り返されるたびに変数は異なる値にバインドされます。

(22)

繰り返されるたびに、変数は表示された順序で値にバインドされます。そのため、for リストの$later 変数の前にある$earlier 変数の値が、$later 変数へのバインドに使用されることがあります。たとえば、次の式では、2 回目の繰り返しで、$i が 4 に、$j が 6（2+4）にバインドされます。

for $i in (3, 4), $j in ($i, 2+$i)

• let - 1 つ以上の変数をバインドします。

for の場合と同様に、let を使用して、let のバインド・リスト（もしくは、for または let で囲まれたリスト）で前にデプロイされている別の変数を使用して計算した値を、変数にバインドできます。たとえば、次の式は$j を 5（3+2）にバインドします。

let $i := 3, $j := $i +2

• where - 一定の条件に従い、for および let の変数バインドをフィルタします。これは、SQL の WHERE 句に似ています。

• order by - where のフィルタ結果をソートします。

• return - 順番付けられたフィルタ後の値から結果を作成します。これが、FLWOR 式全体の結果となります。結果は、1 つのフラット化されたシーケンスです。 for 式と let 式は、SQL の FROM 句と同様に機能します。where は SQL の WHERE 句と、order by は SQL の ORDER BY と同様に動作し、return は SQL の SELECT と同様に動作します。つまり、両方の言語で同じ名前を持つ 2 つのキーワード（where、order by）を除き、FLWOR の句の順序は SQL の句の順序とほぼ逆になります。ただし、対応する句の意味はよく似ています。ドキュメントの順序以外の任意の順序でシーケンスを作成するための唯一の方法は、FLWOR 式（order by を指定）を使用することです。 SQL/XML XQuery 関数

Oracle XML DB は、XQuery 式を SQL 文に渡すための SQL/XML 2006 標準の XMLQuery、 XMLTable、および XMLExists 関数をサポートしています。

• XMLQuery - SQL の SELECT 句で使用され、問合せから XML を生成します。

• XMLTable - SQL の FROM 句で使用され、XML データをリレーショナル表形式にマッピングします。

• XMLExists - SQL の WHERE 句で使用され、XQuery 式に指定された条件に基づいて問合せを処理します。 XQuery のリライトオラクルが提供する SQL/XML 関数の XQuery 式における問合せリライト技術は、 XML アプリケーションに高度なパフォーマンスとスケーラビリティをもたらします。SQL/XML 関数とそれらに対応する XMLType メソッドは、XQuery 式を使用して、XML ドキュメントの集合を検索し、XML ドキュメントに含まれるノードのサブセットにアクセスします。オラクルが提供する SQL/XML 関数の XQuery 式における問合せリライト技術は、XML アプリケーションに高度なパフォーマンスとスケーラビリティをもたらします。

(23)

多くの場合、Oracle XML DB は、このような式を、基本となるデータベース・オブジェクトに対して直接実行するコードにリライトできます。 Oracle XML DB は、使用する XML 記憶域方式に応じて、XMLType 表および列に対して実行される XQuery 式を評価する次の方法を提供しています。 • 構造化記憶域 - Oracle XML DB は、SQL/XML 関数の XQuery 式を同等の SQL 問合せに変換しようとします。SQL 問合せは、スキーマ・ベースの XMLType を支えるオブジェクト・リレーショナル・データ構造を参照します。このプロセスは、XQuery リライトと呼ばれています。問合せと更新操作を実行すると、このプロセスが発生することがあります。さらに、基本となるオブジェクト・リレーショナル表の B-tree 索引、フルテキスト索引、ファンクション索引を使用して、構造化記憶域の XQuery 式を評価できます。

• Binary XML 記憶域 - Oracle XML DB は、ファンクション索引、XMLIndex 索引、または単一のパス・ストリーミングを使用するといった異なる方法で XPath 式を評価できます。単一のパス・ストリーミングとは、Binary XML データの 1 回のスキャンで、一連の XPath 式を評価することです。問合せのコンパイル時に、コスト・ベース・オプティマイザが、最速のメソッドの組合せを選択します。XMLIndex パス表の VALUE 列にセカンダリ索引として、フルテキスト索引を作成し、XQuery ora:contains 関数を使用した最適なフルテキスト問合せを実行できます。 • 非構造化記憶域 - XMLIndex 索引、およびファンクション索引を使用して、非構造化記憶域の XPath 式を評価できます。さらに、 o XMLIndex 索引がない場合は、Oracle XML DB は、機能評価を使用して XPath 式を評価します。機能評価は、各 XML ドキュメントの DOM ツリーを作成した後、DOM API が提供するメソッドを使用して、プログラム的に XPath を解決します。操作に DOM ツリーの更新が含まれる場合は、操作の完了時に、XML ドキュメント全体をディスクに書き直す必要があります。 o XMLIndex 索引が使用可能な場合は、機能評価の代わりに XMLIndex が使用されます。さらに、XMLIndex パス表の VALUE 列にセカンダリ索引として、フルテキスト索引が存在する場合は、 XQuery ora:contains 関数を使用した最適なフルテキスト問合せを実行するために、この索引が使用されます。 Oracle XML DB の設計における主な目的は、SQL/XML の二重性を提供することです。

SQL/XML の二重性

Oracle XML DB の設計における主な目的は、SQL/XML の二重性を提供することです。 XML プログラマは、XML コンテンツと連携動作させることでリレーショナル・モデルの性能をフルに活用でき、SQL プログラマは、リレーショナル・コンテンツと連携動作させることで XML の柔軟性をフルに活用できます。これにより、特定のビジネス問題にもっとも適したツールを使用できます。

(24)

SQL/XML の二重性とは、同じデータを 1 つの表の複数の行に表示し、SQL および XQuery を使用して操作をしたり、1 つの XML ドキュメント内で複数のノードとして表示し、XQuery リライト、DOM、XSL 変換などの技術を使用して操作できることを意味しています。基本となる記憶域形式と索引を利用するために、アクセスおよび処理技術が最適化されています。これらの機能は、一般的なビジネス問題に簡潔なソリューションを提供します。例： • Oracle XML DB SQL/XML 関数を使用して、SQL 問合せから直接 XML データを生成できます。その後、データベースに常駐する XSLT プロセッサを使用して、XML データを HTML などのその他の形式に変換できます。 • 異なるデータ形式間で変換を行うことなく、SQL 問合せ、オンライン分析処理（OLAP）、およびビジネス・インテリジェンス/データ・ウェアハウジング操作に使用するために、XML コンテンツにアクセスできます。 • XML コンテンツに対して、テキスト操作、空間的操作、およびマルチメディア操作を実行できます。 SQL 標準の SQL/XML 関数 SQL/XML 2006 標準は、SQL、XML、および XQuery 構造間のマッピングと、XML の問合せ、アクセス、生成を実行する関数を定義しています。 Oracle XML DB は、SQL/XML 標準で定義された SQL 関数を提供します。この標準は、International Committee for Information Technology Standards（INCITS）Technical Committee H2 によって規定された仕様に基づいて定義されています。INCITS は、 SQL をはじめとするデータベース言語の構文とセマンティクスの標準を開発するための主要な標準化団体です。 Oracle XML DB は、SQL/XML 標準で定義された SQL 関数を提供します。 SQL/XML 関数は、次の 2 つのカテゴリに分けられます。 • 通常の SQL 操作の一部として XML コンテンツの問合せおよびアクセスに使用できる関数。XMLQuery、XMLTable、および XMLExists 関数が、このカテゴリに属します。 • SQL 問合せの結果から XML データを生成するために使用できる関数。これには、XMElement、XMLAttributes、XMLAgg、XMLForest といった関数が含まれます。 SQL/XML 関数を使用して、SQL 文の一部として XML コンテンツを処理できます。これらの関数は、XQuery 式または XPath 式を使用して、XML 構造内を検索し、操作対象のノードを特定します。SQL 文に埋め込まれた XQuery 式および XPath 式の機能により、XML へのアクセスは非常に簡素化されます。 XML データからのリレーショナル・ビューおよびリレーショナル・データからの XML ビューオラクルが提供する XQuery 記述技術によってサポートされている Oracle XML DB は、XML とリレーショナル・データのシームレスな統合を提供します。オラクルの SQL/XML 実装により、高度なパフォーマンスの XML パブリッシングが可能になり、XQuery が直接リレーショナル・データを操作できるようになります。

(25)

逆に、XML コンテンツのリレーショナル・ビューにより、SQL 操作を XML で効率的に実行できるようになります。 XMLビューを使用したリレーショナル・データのラップ XMLType ビューを使用して、既存のリレーショナル・データおよびオブジェクト・リレーショナル・データを XML 形式にラップできます。XMLType ビューは、 SQL/XML XMLQuery または XML 生成関数（XMLAgg、XMLForest など）を使用して、作成できます。XQuery 、ora:view 関数とともに SQL XMLQuery 関数を使用すると、柔軟な手法で、リレーショナル・データを複雑な構造化 XML にパブリッシュできます。 XMLデータのリレーショナル・ビューへのマッピング XML データが普及している一方、XML データを処理できない既存のリレーショナル・データベース・アプリケーションが多数存在しています。Oracle XML DB は、XML データをリレーショナル・ビューにマッピングするために、SQL/XML の XMLTable 関数と、その COLUMNS 句を効率的にサポートします。XQuery リライト技術、記憶域モデル、索引付け、スキーマを利用して、XMLTable 関数で作成されたリレーショナル・ビューのダウン・ストリーム処理を、純粋なリレーショナル・パフォーマンスに近づけることができます。

XMLType の更新、変換、および差分/パッチ操作

Oracle XML DB は、XML 処理を包括的かつ効率良くサポートします。XML コンテンツの記憶域、索引付け、問合せに加え、XML ドキュメントの更新、変換、比較、およびパッチの適用も、XML アプリケーションの重要な働きです。 Oracle XML DB に格納された XML コンテンツの更新

Oracle XML DB では、構造化記憶域モデルまたは SecureFile と Binary XML 記憶域の組み合わせモデルのどちらかを使用して、細分化された XML コンテンツの更新操作を実行できます。更新操作は、ドキュメントのコンテンツ全体を置き換えることもできれば、ドキュメントの一部分だけを置き換えることもできます。XML ドキュメントの部分更新は、非常に強力です。特に、サイズの大きなドキュメントに少量の変更を加える場合には、更新の実行に要するネットワーク・トラフィック量とディスク入出力を大幅に削減できます。 XML ドキュメント全体を置き換えることなく、XML データを増分更新するために使用できる SQL 関数がいくつかあります。 • updateXML - 任意の種類の XML ノードを置き換えます。 • insertChildXML - XML 要素または属性ノードを特定の要素ノードの子として挿入します。 • insertXMLbefore - 任意の種類の XML ノードを特定ノード（属性ノード以外）の直前に挿入します。 • appendChildXML - 任意の種類の XML ノードを、特定の要素ノードの最後の子ノードとして挿入します。