| Oracle® XML DB開発者ガイド 11gリリース2 (11.2) B70200-03 |
|
 前 |
 次 |
この章では、Oracle XML DBのソリューションを計画する場合に考慮する基本的な設計基準について説明します。
この章の内容は次のとおりです。
次の場合、Oracle XML DBは自動的にインストールされます。
Database Configuration Assistant(DBCA)を使用して、汎用テンプレートを使用してOracle Databaseを構築する場合
SQLスクリプトcatqmを使用してOracle Databaseをインストールする場合
Oracle XML DBがすでにインストールされているかどうかは、自分で判断できます。次の条件に当てはまる場合は、インストールされています。
データベース・スキーマ(ユーザー・アカウント)XDBが存在する。確認するには、次の問合せを実行します。
SELECT * FROM ALL_USERS;
ビューRESOURCE_VIEWが存在する。確認するには、次のコマンドを使用します。
DESCRIBE RESOURCE_VIEW
|
関連項目:
|
Oracle XML DBは、アプリケーションで処理されるデータの一部または全部がXMLで表現されているアプリケーションに適しています。Oracle XML DBでは、高パフォーマンスのデータベースで、XMLデータの収集、格納、処理および取出しが実行されます。また、既存のリレーショナル・データからXMLを迅速に容易に生成できます。
Oracle XML DBが特に適しているアプリケーションは、次のとおりです。
Business-to-Business(B2B)およびApplication-to-Application(A2A)統合
インターネット
コンテンツ管理
メッセージ機能
Webサービス
典型的なOracle XML DBアプリケーションには、次のうち1つ以上の特長があります。
多くのXML文書を収集または生成する必要がある。
大規模なXML文書を処理または生成する必要がある。
1つの文書内でも、多数の文書の集まりにわたっても、高パフォーマンスな検索が必要とされる。
高いレベルのセキュリティが必要とされる。
ファイングレイン・セキュリティが必要とされる。
データ処理でXML文書を使用し、データをリレーショナル表に格納する必要がある。
プログラミングで、SQL、XML、XQuery、XPath、XSLなどのオープン標準がサポートされている必要がある。
FTP、HTTP(S)、WebDAV、Java Database Connectivity(JDBC)などの標準インターネット・プロトコルを使用して情報にアクセスする必要がある。
XMLデータはSQLから問い合せる必要がある。
XMLデータに分析機能を適用する必要がある。
XML文書をXML Schemaに基づいて検証する必要がある。
Oracle XML DBを使用すると、Oracle Database内でのXML文書の格納および処理手順を微調整できます。アプリケーションの性質に応じて、XML記憶域には次のうち1つ以上の機能が必要です。
XML文書の高パフォーマンスな収集および取出し
XML文書の高パフォーマンスな索引付けおよび検索
XML文書のセクションの更新
構造化または非構造化されたXML文書の管理
この項では、Oracle XML DBアプリケーションを計画する際に考慮できる基本的な設計基準について説明します。
高度に構造化されたデータ(主にXML)にするか、半構造化データにするか、非構造化データにするか。高度に構造化されたデータにする場合、表はXML Schemaに基づいた表にするか、XML Schemaに基づかない表にするか。
XMLデータがXML Schemaに基づいていない場合、その構造化の方法とは関係なく、XMLType表またはビューにバイナリXMLまたはCLOBインスタンスとして、またはOracle XML DBリポジトリのフォルダ内のファイルとして格納できます。
XMLデータがXML Schemaに基づいている場合は、その構造化部分に非構造化、構造化(オブジェクト・リレーショナル)またはバイナリXML記憶域を使用できます。非構造化部分には、XML Schemaに基づかないデータと同じオプションを使用できます。
この項では、Oracle XML DBリポジトリにリソースとして格納されるデータに関する事項を取り上げます。
他のアプリケーションおよびユーザーが、どのようにXMLおよびその他のデータにアクセスする必要があるか。アクセスにどの程度のセキュリティ・レベルが必要か。バージョニングが必要か。
リポジトリへのアクセス方法には、主に次の2つがあります。
ナビゲーション・ベースのアクセスまたはパス・ベースのアクセス。これはコンテンツ/ドキュメントおよびデータ指向アプリケーションの両方に適しています。Oracle XML DBでは、次の言語およびアクセスAPIが提供されています。
リソース・ビューおよびパス・ビューを介したSQLアクセス。第25章「RESOURCE_VIEWおよびPATH_VIEWを使用したリポジトリへのアクセス」を参照してください。
DBMS_XDBを介したPL/SQLアクセス。第26章「PL/SQLを使用したリポジトリへのアクセス」を参照してください。
コンテンツ指向のアプリケーションに最適なHTTP(S)、WebDAVまたはFTPを使用したプロトコルベースのアクセス。第28章「プロトコルを使用したリポジトリへのアクセス」を参照してください。
問合せベースのアクセス。これはデータ指向アプリケーションに最適です。Oracle XML DBでは、次のAPIを介して、SQL問合せを使用するアクセスが可能です。
(JDBCを介する)Javaアクセス。「Java DOM API for XMLType」を参照してください。
PL/SQLアクセス。第13章「PL/SQL APIs for XMLType」を参照してください。
ポジトリ・データにアクセスするためのこれらのオプションについては、第21章「Oracle XML DBリポジトリのデータへのアクセス」を参照してください。
次のアクセス基準についても考慮します。
どの程度のセキュリティ・レベルが必要か。第27章「リポジトリのアクセス制御」を参照してください。
アプリケーションに最適な索引付けの形式は何か。Oracle Textの索引付けおよび問合せを使用する必要があるか。第4章「XMLTypeの操作」、第6章「XMLTypeデータの索引付け」および第12章「XMLデータの全文検索」を参照してください。
データのバージョニングが必要か。必要な場合は、第24章「リソースのバージョン管理」を参照してください。
どの言語でアプリケーションをプログラミングするか。
Oracle XML DBアプリケーションは、次の言語でプログラミングできます。
Java(JDBC、Javaサーブレット)
PL/SQL
XMLデータを生成する必要があるか。第18章「データベースからのXMLデータの生成」を参照してください。
XML文書はどれほどの頻度でアクセス、更新および操作されるか。更新の対象は文書のフラグメントか、または文書全体か。
XMLデータをHTMLやWMLなどの他の言語に変換する必要があるか。その場合は、アプリケーションによってXMLデータがどのように変換されるか。第11章「XMLTypeデータの変換および検証」を参照してください。
アプリケーションを主にデータベースに常駐させる必要があるか、またはデータベースと中間層の両方で動作させる必要があるか。
アプリケーションは、データ中心、ドキュメント(コンテンツ中心)、またはその両方のいずれであるか。
次の処理オプションは、Oracle XML DBアプリケーションの設計時に使用可能であり、考慮する必要があります。
XSLT: XMLデータをHTMLやWMLなどの他の言語に変換する必要があるか、その場合は、アプリケーションによってXMLデータがどのように変換されるか。Oracle XML DBにXML文書を格納中に、文書の構造が特定のXML Schemaに準拠するかどうか(妥当かどうか)を確認できます(オプション)。第11章「XMLTypeデータの変換および検証」を参照してください。
DOM再現性、ドキュメントの再現性。ドキュメントの再現性を維持するには非構造化記憶域を使用します。DOM再現性を維持するには、XML Schemaに基づくデータに対してバイナリXMLまたは構造化記憶域を使用します。第13章「PL/SQL APIs for XMLType」および「DOM再現性」を参照してください。
XPath検索。SQL文に埋め込まれたまたはHTTP(S)リクエストの一部としてXPath構文を使用すると、データベース内のXMLコンテンツを問い合せることができます。第4章「XMLTypeの操作」、第12章「XMLデータの全文検索」、第21章「Oracle XML DBリポジトリのデータへのアクセス」および第25章「RESOURCE_VIEWおよびPATH_VIEWを使用したリポジトリへのアクセス」を参照してください。
XMLの生成およびXMLTypeビュー。XMLデータを生成または再生成する必要があるか。「はい」の場合、第18章「データベースからのXMLデータの生成」を参照してください。
XML文書はどれほどの頻度でアクセス、更新および操作されるか。第4章「XMLTypeの操作」および第25章「RESOURCE_VIEWおよびPATH_VIEWを使用したリポジトリへのアクセス」を参照してください。
更新の対象は文書のフラグメントか、または文書全体か。XPath式を使用して、文書全体を再書込みせずに、更新中に文書の個々の要素および属性を指定できます。これは、特に大規模なXML文書の場合により効率的です。第7章「XML Schemaの格納と問合せ: 基本」を参照してください。
アプリケーションは、データ中心、ドキュメントおよびコンテンツ中心、または統合(データとドキュメント中心の両方)のいずれであるか。第3章「Oracle XML DBの使用」を参照してください。
ゲートウェイを介して、アプリケーション間でXMLデータを交換するか。Oracle Streamsアドバンスト・キューイング(AQ)またはSOAPに準拠させる必要があるか。第37章「Oracle Streams AQを使用したXMLデータの交換」を参照してください。
アドバンスト・キューイング(AQ)では、XMLおよびXMLTypeアプリケーションがサポートされています。XMLType属性を含むペイロードを持つキューを作成できます。これらのペイロードは、XML文書を含むメッセージの転送および格納に使用できます。XMLType属性を持つOracle Databaseオブジェクトを定義すると、次の操作を実行できます。
複数の型のXML文書を同じキュー内に格納します。この文書は、CLOB値として内部的に格納されます。
XPathやXQuery式を使用して、XMLType属性を持つメッセージを選択的にデキューします。
XPathやXQuery式を使用して、メッセージ内容を問い合せるルールベースのサブスクライバを定義します。
変換を定義して、Oracle DatabaseオブジェクトをXMLTypeに変換します。
リレーショナル・データ、XMLデータ、XML Schemaなどをどの方法でどの場所に格納するか。
|
注意: 通常、データ構造、アクセス、言語および処理に対して選択する内容は相互に関連しています。ただし、記憶域モデルの選択は、他の選択とは関連がありません。 |
図2-1に、XMLType表およびビューに対するOracle XML DBの記憶域オプションを示します。
既存のリレーショナル・データがある場合は、XMLTypeビューをそのデータに作成することで、そのデータにXMLデータとしてアクセスできます。次を使用して、XMLTypeビューを定義できます。
SQL/XML関数。第18章「データベースからのXMLデータの生成」および第5章「Oracle XML DBでのXQueryの使用」を参照してください。
オブジェクトタイプ: オブジェクト表、オブジェクト・コンストラクタおよびオブジェクト・ビュー
アプリケーション用に選択した記憶域オプションにかかわらず、Oracle XML DBでは同じ機能が提供されます。使用する記憶域モデルは、アプリケーションのパフォーマンスおよびXMLデータの再現性に影響する場合がありますが、次のオプションとは関係がありません。
データの問合せまたは更新の方法および頻度。
データのアクセス方法。これは、アプリケーション処理の要件のみによって決まります。
アプリケーションで使用される言語。これは、アプリケーション処理の要件のみによって決まります。
XMLを使用してデータを表現する際の問題点の1つは、他の表現方法よりもオーバーヘッドが増加することです。この問題を解決するために、Oracle XML DBには、特にXML処理のパフォーマンスが大幅に向上するように設計された機能がいくつか組み込まれています。これらの機能については、次の各項で説明します。
XMLで表現されたデータをテキスト・ファイルにすると、同じデータをJavaオブジェクトまたはリレーショナル表に格納した場合よりサイズが平均で3倍になります。これには、主に次の2つの理由があります。
タグ名(データを表すメタデータ)と空白(フォーマット文字)によって、文書内の領域量が大幅に増加します。特に、高度に構造化されたデータ中心のXMLの場合に増加します。
XMLファイル内のすべてのデータが、判読可能な(文字列)形式で表現されているためです。
数値の文字列表現では、ネイティブな(バイナリ)表現の約2倍のバイト数が必要です。構造化またはバイナリXML記憶域を使用してXML文書をOracle XML DBに格納すると、格納処理によって文書内のすべてのタグと空白文字が破棄されます。
この最適化によって節約できる領域量は、データに対するタグ名の割合と文書内のコレクション数によって決まります。高度に構造化されたデータ中心のXMLデータの場合は、領域を大幅に節約できる可能性があります。文書の出力またはXPath評価などのノード・ベースの操作を行うと、Oracle XML DBは、関連するXML Schemaに含まれる情報を使用して必要なタグ情報を動的に再構成します。
ドキュメント・オブジェクト・モデル(DOM)は、XML文書の代表的なプログラミング・モデルです。DOM APIは簡単に使用できますが、基礎となるDOMツリーの生成ではメモリーに関して高コストになります。一般的なDOM実装では、DOMツリー内のノードごとに約80から120バイトのシステム・オーバーヘッドが維持されます。高度に構造化されたデータの場合、DOMツリーには、基礎になる文書に比べて10から20倍のメモリー量が必要です。
従来のDOM実装では、操作を開始する前にXML文書のコンテンツ全体をDOMツリーにロードする必要があります。アプリケーションによる処理が文書内のわずかな割合のノードにのみ必要な場合は、メモリーや処理のオーバーヘッドに関して非常に非効率になります。かわりにSimple API for XML(SAX)を使用した場合、XML文書の処理に必要なメモリー量は削減できますが、そのデメリットは、XML文書内のノードに対して線形処理のみ可能であることです。
Oracle XML DBでは、XML Object (XOB)と呼ばれる動的メモリー内の内部構造を使用してXML Schemaに基づくXML文書を管理することで、DOMプログラミングに関連するメモリー・オーバーヘッドが削減されます。XOBはタブ名やノード型などの情報をコピーしないため、同等のDOMよりも大幅に小さく、関連するXML Schemaから容易に取得できます。Oracle XML DBでは、アプリケーションがスキーマに基づくXMLTypeのコンテンツを操作する際に、自動的にXOBを使用します。XOBの使用は、ユーザーには透過的です。XMLTypeデータ型、C、PL/SQLおよびJava APIの使用時にXOBが使用されていることはユーザーにはわかりません。
XOBでは、遅延ロードされた仮想DOM機能を使用して、XML文書の操作に必要なメモリー量を削減することもできます。これにより、Oracle XML DBは、コードがそのオブジェクト内のノードで操作を開始するまで、サブ要素またはコレクションの一部であるノードの動的メモリー表現のロードを遅延できます。その結果、アプリケーションが文書内のいくつかのノードのみ操作する場合は、操作対象のノードとその直接の兄弟のみがメモリーにロードされます。XOBを使用できるのは、XML文書がXML Schemaに基づいている場合のみです。XML文書のコンテンツがXML Schemaに基づいていない場合、XOBのかわりに従来のDOMが使用されます。
DOMツリーを移入するには、アプリケーションでXML文書を解析する必要があります。XMLからDOMツリーを作成する処理は、非常にCPU集中型の処理です。XML文書がテキストとして格納される典型的なDOMベースのアプリケーションでは、アプリケーションで文書の操作を開始する前に、すべての文書を解析してDOMツリーにロードする必要があります。また、DOMツリーのコンテンツが更新された場合は、ツリー全体をテキスト形式に再シリアライズしてディスクに書き込む必要があります。
Oracle XML DBを使用すると、文書を何度も解析する必要がなくなります。構造化またはバイナリXML記憶域として文書を格納した場合、XML文書をディスクからメモリーにロードする際の解析は不要です。Oracle XML DBでは、関連するXML Schemaから導出される情報を使用して、ディスク形式と動的メモリー形式間に直接マップします。XML Schemaに基づくデータが変更された場合、Oracle XML DBは、更新されたデータのみをディスクに書き込めます。XMLデータがXML Schemaに基づいていない場合は、かわりに従来のDOMが使用されます。
ほとんどのDOM実装では、DOMツリー内の特定のノードを検索するときに文字列比較を使用します。このため、DOMツリーの単純な検索でも、数百または数千もの命令サイクルが必要になる場合があります。XOBでのノード検索は、DOMでのノード検索と比較して非常に効率的です。XOBは、C/C++オブジェクトと同様に計算済のオフセット・モデルに基づいており、文字列比較ではなく動的なハッシュテーブルを使用してノード検索を実行します。
従来のXMLアプリケーションでXML Schemaに関連する強力な機能を使用すると、多くの追加オーバーヘッドが発生する可能性があります。たとえば、XML Schemaに対してXML文書を検証するには、そのXML Schema自体を検索、解析および検証する必要があります。
Oracle XML DBでは、XML Schemaの使用に関連するオーバーヘッドを最小化します。データベースに登録されたXML Schemaは、テキスト、XOBおよびデータのディスク内表現との間のマップに必要なすべてのメタデータとともに、Oracle XML DBのスキーマ・キャッシュにロードされます。XML Schemaをデータベースに登録した後、そのXML Schemaを使用するために解析や検証を行う必要はありません。スキーマ・キャッシュは、データベースのすべてのユーザーが共有します。Oracle XML DBの操作でXML Schemaに含まれる情報が必要な場合は、必要な情報にキャッシュから直接アクセスできます。
スキーマの全体検証の実行やXML文書のテキスト形式へのシリアライズなど、一部の操作では多くのメモリーおよびCPUリソースが必要です。Oracle XML DBでは、これらの操作をクライアントまたは中間層のプロセッサに肩代わりさせることができます。Oracle Call Interface (OCI)インタフェースおよびJDBC用OCIドライバにより、XOBをクライアントで管理できます。XML Schemaのキャッシュされた表現はクライアントにもダウンロードできます。これにより、XML出力やXML Schemaの検証などの操作を、サーバー・リソースではなくクライアントまたは中間層のリソースを使用して実行できるようになります。
XMLベースのJavaアプリケーションでは、XMLファイルの解析時に別のボトルネックが発生します。ネイティブにコンパイルされたJavaまたはJITでコンパイルされたJavaでも、XML解析操作では、ネイティブなC言語を使用した場合に比較して2倍の実行時間がかかります。XMLアプリケーションを実装する際のパフォーマンス上の主要なボトルネックの1つは、XML文書内のデータをテキスト、Javaおよびネイティブ・サーバーの各表現に変換するコストです。この変換を実行するためのコストはXMLファイルのサイズと複雑さに比例するため、適度なサイズのファイルの場合でも重大なボトルネックになります。
Oracle XML DBではこの問題に対処するため、すべてのJavaインタフェースおよびPL/SQLインタフェースを、C言語でのネイティブ実装に対する軽量なファサードとして実装します。Java、C、PL/SQLおよびSQLすべてが同じ基礎となる実装を使用します。これによって、言語的に中立なXMLサポートが提供され、XML解析およびDOM処理のパフォーマンスが向上します。
JavaおよびXMLの使用時の最大のボトルネックの1つは、型変換によるものです。Javaでは、内部的にUCS-2を使用して文字データを表現します。ほとんどのXMLファイルとデータベースには、UCS-2でエンコードされたデータは含まれていません。XMLファイルに含まれているすべてのデータは、Javaプログラムで操作する前に、8ビットまたはUTF-8エンコーディングからUCS-2エンコーディングに変換する必要があります。
Oracle XML DBではこの問題に対処するため、遅延型変換を使用します。遅延型変換を使用すると、アプリケーションがノードのコンテンツにアクセスするまで、そのノードのコンテンツはJavaで必要な形式に変換されません。データは、直前まで内部表現のままです。アプリケーションがXML文書内の数個のノードのみにアクセスする場合は、不要な型変換を回避することによってパフォーマンスが大幅に向上します。
Oracle Databaseから名前をロードし、生成されたHTMLにその名前を出力するJSPを考えてみます。一般的なJSP実装ではデータベース(ASCIIまたはISO8859キャラクタ・セットのデータが格納されている可能性があります)から名前を読み取り、そのデータをUCS-2に変換して、Javaに文字列として戻します。JSPでは、文字列コンテンツを参照せず、囲まれたHTMLの出力後にそのコンテンツを出力するのみで、クライアントのブラウザ用に元と同じASCIIまたはISO8859に再変換します。Oracle XML DBでは、XMLTypeに書込みインタフェースを提供します。このため、すべての要素は、それ自体をJavaキャラクタ・セットによる変換なしでストリーム(ServletOutputStreamなど)に直接書き込むことができます。図2-2にOracle XML DB Application Program Interface (API)スタックを示します。
図2-2 Oracle XML DBのApplication Program Interface(API)スタック
