JP2005505058A - オブジェクト−リレーショナルデータベースシステムにｘｍｌスキーマをマッピングするための機構 - Google Patents

Abstract

ユーザによる、データベースシステムへのXMLスキーマ登録を可能にするための方法およびシステムを提供する。データベースシステムは、登録されたXMLスキーマに基づき、XMLスキーマに準拠するXML文書をデータベースシステム内にどのように格納すべきかを決定する。この決定は、XMLスキーマで定義された構成体を、データベースシステムがサポートする構成体にマッピングすることに関わる。このような構成体は、データ型、および要素、制約、継承等の間の階層的な関係を含み得る。マッピングが決定されると、後に受信される、登録されたXMLスキーマに準拠するXML文書をどのように格納するかを決定するために、このマッピングはデータベースシステムによって格納および使用される。

Description

【技術分野】
【０００１】
関連出願
この出願は、以下の米国仮特許出願、すなわち、
２００１年９月２８日に出願された、エリック・セドラー（Eric Sedlar）およびビスワナサン・クリシュナマーシー（Viswanathan Krishnamurthy）による「データベースシステムが設けられたファイルベースのアクセス（File Based Access Provided With a Database System）」と題された米国仮特許出願第６０／３２６，０５２号、および
２００２年５月７日に出願された、ニプン・アガーウォル（Nipun Agarwal）、ラビ・マーシー（Ravi Murthy）、エリック・セドラー、シバサンカラン・チャンドラセカー（Sivasankaran Chandrasekar）、フェイ・ジー（Fei Ge）、シアム・パンナラ（Syam Pannala）、ニーマ・ジャラリ（Neema Jalali）、およびムラリドハー・クリシュナプラサド（Muralidhar Krishnaprasad）による「ファイルシステム抽象化をもたらす、データへのSQLアクセス（SQL Access to Data that Provides a File System Abstraction）」と題された米国仮特許出願第６０／３７８，８００号から優先権を主張する。これらの内容の全体は、この明細書においてあらゆる目的のために引用によって援用される。
【０００２】
また、この出願は、以下の米国特許出願、すなわち、
本願と同日に出願された、ニプン・アガーウォル、ラビ・マーシー、エリック・セドラー、シバサンカラン・チャンドラセカー、およびフェイ・ジーによる「リレーショナルシステム内の階層データにアクセスするための演算子（OPERATORS FOR ACCESSING HIERARCHICAL DATA IN A RELATIONAL SYSTEM）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９７５号）、
本願と同日に出願された、ニプン・アガーウォル、エリック・セドラー、ラビ・マーシー、およびナミット・ジャイン（Namit Jain）による「リレーショナルデータの一貫した階層的抽象化の提供（PROVIDING A CONSISTENT HIERARCHICAL ABSTRACTION OF RELATIONAL DATA）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９７６号）、
本願と同日に出願された、ニプン・アガーウォル、エリック・セドラー、およびラビ・マーシーによる「データベースシステム内のバージョン化されたデータを効率よく管理するためのインデックス付け（INDEXING TO EFFICIENTLY MANAGE VERSIONED DATA IN A DATABASE SYSTEM）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９７８号）、
本願と同日に出願された、ラビ・マーシー、エリック・セドラー、ニプン・アガーウォル、およびニーマ・ジャラリによる「階層的に組織されたリソースのコンテントおよびプロパティを格納するための機構（MECHANISMS FOR STORING CONTENT AND PROPERTIES OF HIERARCHICALLY ORGANIZED RESOURCES）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９７９号）、
本願と同日に出願された、ラビ・マーシー、エリック・セドラー、ニプン・アガーウォル、サム・イディキュラ（Sam Idicula）、およびニコラス・モントヤ（Nicolas Montoya）による「データベースシステムにおける一様なアクセス制御のための機構（MECHANISM FOR UNIFORM ACCESS CONTROL IN A DATABASE SYSTEM）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９８０号）、
本願と同日に出願された、シアム・パンナラ、エリック・セドラー、ブシャン・クハラドカー（Bhushan Khaladkar）、ラビ・マーシー、シバサンカラン・チャンドラセカー、およびニプン・アガーウォルによる「XML文書の遅延実現化のためのローダブルユニット（LOADABLE UNITS FOR LAZY MANIFESTATION OF XML DOCUMENTS）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９８１号）、および
本願と同日に出願された、ニーマ・ジャラリ、エリック・セドラー、ニプン・アガーウォル、およびラビ・マーシーによる「リレーショナルデータベースシステムにおいて階層的アクセスを提供する、構造化データに効率よくインデックス付けする機構（MECHANISM TO EFFICIENTLY INDEX STRUCTURED DATA THAT PROVIDES HIERARCHICAL ACCESS IN A RELATIONAL DATABASE SYSTEM）」と題された米国特許出願連続番号第 号（代理人事件整理番号第５０２７７−１９８２号）にも関連する。これらの内容の全体は、あらゆる目的のためにこの明細書において引用によって援用される。
【０００３】
発明の分野
この発明はデータベースシステムにXMLデータを格納するための技術に関する。
【背景技術】
【０００４】
発明の背景
データは、リレーショナルデータベースシステム内でさまざまな種類のデータコンテナに格納される。このようなデータコンテナは、一般に構造を有する。コンテナの構造は、コンテナが含むデータに課される。たとえば、テーブルは行列に編成されている。データがテーブルに格納される際に、そのデータ内の個々のデータアイテムが特定の行および列に格納され、したがってそのデータに構造を課す。
【０００５】
一般に、データに課される構造は、データ内の論理関係に対応する。たとえば、一般にテーブルの所定の行内に格納されたすべての値は互いに何らかの論理関係を有する。たとえば、従業員テーブルの所定の行内の値はすべて、同一の従業員に対応し得る。
【０００６】
データベースシステムの外で電子データが構造化される程度は、データの特性に基づいて大きく異なり得る。たとえば、スプレッドシートに格納されたデータは概して高度に構造化されているが、視覚イメージを表わすデータは概してそれほど高度に構造化されていない。
【０００７】
XML（拡張可能なマークアップ言語（eXtensible Markup Language））は、あらゆる形のデータを記述して格納するためのフォーマットとしてますます一般的になっている。したがって、XML文書の格納、探索および処理に対するサポートの提供は、今日のデータ管理システムにとって極めて重要な課題である。
【０００８】
特定の型のXML文書の構造に関する情報は、「XMLスキーマ」と呼ばれる文書で特定できる。たとえば、特定の型のXML文書に対するXMLスキーマは、その特定の型のXML文書に含まれるデータアイテムに対する名前と、その型のXML文書に含まれるデータアイテム間、その特定の型のXML文書に含まれるデータアイテムのデータ型間等の階層関係とを特定できる。
【０００９】
残念なことに、XML文書が構造化されているものの、データベースシステムを用いてXML文書を格納する際に、データベースシステムはXML文書の構造をほとんど無視してしまう。たとえば、複数の属性に対する複数の値を含んで高度に構造化されたXML文書が、テーブルの１つのＣＬＯＢ列における、区別されていない原子的なデータ片であるかのように単に格納されてしまうおそれがある。XML文書がこのように格納されると、データベースの性能およびスケーラビリティの特徴を十分に活用してXMLデータにアクセスすることができない。
【００１０】
この発明は、同様の参照番号が同様の要素を指す添付の図面において、限定としてではなく例示として示される。
【発明を実施するための最良の形態】
【００１１】
発明の実施例の詳細な説明
オブジェクト−リレーショナルデータベースシステムにXMLスキーマをマッピングするための方法およびシステムを説明する。以下の説明では、多数の特定の詳細を説明のために明示して、この発明が完全に理解されるようにしている。しかしながら、このような特定の詳細なしにこの発明を実施できることは明らかである。他の例では、周知の構造および装置をブロック図の形で示し、この発明を必要以上に分かりにくくすることを避けている。
【００１２】
機能的な概観
この明細書では、データを保持するために用いられるデータベースコンテナがデータに課す構造と、そこからデータが生じるXML文書の構造との間の相関関係を高める態様で、XMLデータをデータベースシステム内で管理するためのさまざまな技術を説明する。一局面によると、データベースシステムのユーザがデータベースシステムにXMLスキーマを登録可能にする機構が設けられる。XMLスキーマは、明示的に（API呼出しを介して）、または暗黙的に（XMLスキーマに準拠するインスタンス文書がデータベース内に最初に挿入される際に）登録され得る。
【００１３】
データベースシステムは、所定のXMLスキーマに対する登録プロセス中に、（１）XMLスキーマに対する適切なデータベース表現、および（２）マッピング情報を決定する。「適切なデータベース表現」の決定とは、XMLスキーマに準拠するデータがデータベースシステムによってどのように管理されるべきかについての決定である。所定のXMLスキーマに対する適切なデータベース表現の決定は、たとえば、データベースのオブジェクト、集合型、および制約の決定、ならびに所定のXMLスキーマに準拠するXML文書からのデータを格納するためにデータベースシステムが用いるべきインデックスの決定さえも含み得る。
【００１４】
マッピング情報は、XMLスキーマに含まれる構成体と適切なデータベース表現に含まれる構成体との間のマッピングを示す。マッピング情報は、たとえば、XMLスキーマの特定の要素に関連するデータが、適切なデータベース表現の一部として生成されたテーブルの特定の列に格納されるべきであることを示し得る。一般に、適切なデータベース表現およびマッピング情報は、XMLスキーマに記述されている構造と、XMLデータが格納されているデータベースコンテナがデータに課す構造との間に高い相関関係を生じるように生成される。
【００１５】
システムの概観
図１は、オブジェクト−リレーショナルデータベースシステムにXMLスキーマをマッピングするための機構を含むシステムのブロック図である。具体的に、データベースサーバ１０４（この明細書では「XDB」とも呼ばれる）は、XMLスキーママッパー１０６を含む。XMLスキーマ１０２がデータベースサーバ１０４に登録されると、XMLスキーママッパー１０６は、XMLスキーマ１０２に準拠する文書に対して適切なデータベース表現１０８を決定して、XMLスキーマの要素と適切なデータベース表現１０８の要素との間の相関関係を示すマッピング情報１１０を生成する。
【００１６】
一実施例によると、データベースサーバ１０４は、
・W3C準拠の任意のXMLスキーマを登録し、
・登録されたXMLスキーマに対してXML文書の妥当性検証を行ない、
・ローカルスキーマおよびグローバルスキーマの両方を登録し、
・オブジェクト型からXMLスキーマを生成し、
・（手動によるスキーマ進化のための機構として）XMLスキーマの再登録をサポートし、
・或るAPI（FTP、HTTP等）を介して文書が挿入される際にXMLスキーマの暗黙的な登録をサポートし、
・別のユーザが所有するスキーマをユーザが参照できるようにし、
・同じ名前を有するローカルスキーマが存在している場合、ユーザがグローバルスキーマを明示的に参照できるようにし、
・XMLスキーマの進化をサポートするように構成される。
【００１７】
一実施例によると、XMLスキーママッパー１０６は、
・構造化されたデータベースマッピングを（一般にスキーマ登録中に）XMLスキーマから生じるように構成され、このことは、たとえば、SQLオブジェクト型、集合型等の生成と、スキーマ注釈を介したマッピング情報の入手とを含むことが考えられ、XMLスキーママッパー１０６はさらに、
・複数の正当なマッピングが存在する場合に、ユーザが特定のSQL型マッピングを特定できるようにし、
・登録されたXMLスキーマに基づいてXMLTypeのテーブルおよび列を作成し、
・スキーマベースのXMLTypeテーブルに対するDMLおよびクエリーのサポートを行なうように構成される。
【００１８】
XMLスキーマ登録
一実施例によると、XMLスキーマは、データベースサーバ１０４内で使用または参照され得る前に、まずデータベースサーバ１０４に登録されなければならない。登録プロセスが完了した後、このスキーマに準拠する（および、文書内のスキーマURLを介してこのスキーマを参照する）XML文書は、データベースサーバ１０４によって処理され得る。このスキーマが定義したルートXML要素用のテーブルおよび／または列を作成して、準拠する文書を格納できる。
【００１９】
一実施例によると、スキーマは、スキーマ文書およびそのURL（スキーマ位置としても公知）を特定することによってDBMS_XMLSCHEMAパッケージを用いることにより登録される。ここで用いられるURLは、登録されたスキーマをデータベース内で一意に識別する名前にすぎず、スキーマ文書が位置付けられている物理的なURLである必要がないことに注意されたい。さらに、スキーマのターゲット名前空間は、その中で要素および型が宣言された「抽象的な」名前空間を特定する別のURL（スキーマ位置URLとは異なる）である。インスタンス文書は、ルート要素の名前空間と、この要素を定義するスキーマの位置（URL）との両方を特定すべきである。
【００２０】
たとえば、以下に示すXMLスキーマを考えられたい。このスキーマは、「PurchaseOrderType」と呼ばれるcomplexTypeと、この型の要素「PurchaseOrder」とを宣言している。
【００２１】
【数１】

【００２２】
以下のステートメントは、URL「http://www.oracle.com/PO.xsd」にこのスキーマを登録する（docは上述のスキーマのテキストを保持する変数である）。
【００２３】
【数２】

【００２４】
以下により詳細に説明するように、登録されたXMLスキーマを用いてスキーマベースのXMLTypeのテーブルおよび列を作成できる。以下は、上述のXMLスキーマに準拠するXMLTypeインスタンスである。schemaLocation属性は、スキーマURLを特定する。
【００２５】
【数３】

【００２６】
この発明の一実施例によると、XMLスキーマ登録は、（１）スキーマの妥当性検証、（２）適切なデータ構造の決定、および（３）マッピング情報の生成を含む。これらの段階の各々を、より詳細に以下に説明する。
【００２７】
XMLスキーマの妥当性検証
XMLスキーマは、特定の型のXML文書の構造を記述する。しかしながら、XMLスキーマは、それ自体が、XMLスキーマで特定された構造に準拠しなければならないXML文書である。具体的に、各XMLスキーマは、XMLスキーマ文書型に関連するXMLスキーマ文書に記述された構造に準拠しなければならない。XMLスキーマ登録におけるスキーマの妥当性検証の段階で、登録中のXMLスキーマが検査されて、そのXMLスキーマがXMLスキーマ文書型に関連するXMLスキーマで特定された構造に準拠していることが確認される。
【００２８】
適切なデータベース表現の決定
上で述べたように、適切なデータベース表現の決定は、XMLスキーマに準拠するデータがデータベースシステムによってどのように管理されるべきであるかに関する決定である。一実施例によると、適切なデータベース表現は、（１）その中にデータが含まれているXML文書がデータに課す構造と、（２）データベースシステムがデータに課す構造との間に高い相関関係を得るように選択される。
【００２９】
高い相関関係を得る能力は、少なくとも部分的に、データベースシステムの機能に依存する。データベースシステムの特定の機能はベンダごとおよびバージョンごとに異なる。或る機能がほとんどのデータベースシステムに一般的なものであっても、他の機能はそうではない。したがって、この明細書では、この発明の実施例を特定の組の機能を有するデータベースシステムという文脈で説明しているが、この発明はそのような特定の機能を有するデータベースシステムに限定されない。
【００３０】
一実施例によると、適切なデータベース表現の決定は、XMLスキーマで遭遇し得る構成体の各型を、ターゲットとなるオブジェクト−リレーショナルデータベースシステムがサポートする対応する構成体にどのようにマッピングするかに関してXMLスキーママッパー１０６の動作を支配する、一組の一般規則に基づいて行なわれる。これらの規則は、XMLスキーママッパー１０６の論理へとハードコード化され得、または、XMLスキーママッパ
ー１０６が用いるメタデータで表わされ得る。一実施例によると、一般規則は以下の問題、すなわち、
・ターゲットとなるオブジェクト−リレーショナルデータベースシステムがサポートするデータ型に、XMLがサポートするデータ型をどのようにマッピングするか、
・XMLスキーマが定義する構造を、同様の構造を有するデータベースオブジェクトにどのようにマッピングするか、
・ターゲットとなるオブジェクト−リレーショナルデータベースシステムがサポートする制約実行機構に、XMLがサポートする制約をどのようにマッピングするか、
・ターゲットとなるオブジェクト−リレーショナルデータベースシステムにおいて、XMLスキーマが別のXMLスキーマから継承していることをどのように反映するか、
・ターゲットとなるオブジェクト−リレーショナルデータベースシステムにおいて、XMLがサポートする他の構成体、たとえばinclude要素およびimport要素を介した外部参照、ワイルドカード、単純コンテント（内容）、置換えグループ等をどのように反映するか、に対処する。
【００３１】
オブジェクト−リレーショナルデータ型へのXMLデータ型のマッピング
XMLスキーマは一組の基本型を宣言する。一実施例によると、XMLスキーママッパー１０６が用いる規則は、ターゲットのデータベースシステムがサポートして、かつ、XMLデータ型の各々が対応するデータ型を定義する。たとえば一実施例において、XMLデータ型「string（文字列）」は、VARCHARまたはCLOBのいずれかのSQLデータ型にマッピングする。この例において、XMLスキーママッパー１０６は、たとえばXMLスキーマで文字列要素に対して宣言され得る任意の長さの制約に基づいて、特定の文字列要素をVCHARまたはCLOBのいずれにマッピングすべきであるかを選択できる。XMLスキーママッパー１０６が用い得るデータ型対データ型のマッピング規則の多数の例を以下に示し、付録Ｉで説明する。
【００３２】
データベースオブジェクトへのXML構造のマッピング
SQLスキーマは、その中に現われ得る要素および属性に関して、要素の構造を記述する。データベースオブジェクトにXML構造をマッピングする規則は、XMLスキーマ内で定義されたXMLの属性および要素に対応する属性を有するSQLオブジェクト型をどのようにマッピングすべきかを示す。たとえば、属性Xならびに要素YおよびZを含むXML要素Aは、３つの属性、すなわちX、YおよびZを有するオブジェクト型にマッピングする。
【００３３】
データベース制約へのXML制約のマッピング
XMLスキーマは、さまざまな形の制約を特定することができる。XMLスキーママッパー１０６がこのような制約に遭遇すると、このような制約はSQLの適切な制約機構にマッピングされる。たとえば、XMLスキーマで定義された「文字列」属性に対する長さの制約は、maxLength＝「２０」であり得る。一実施例によると、このような制約により、この文字列属性はデータ型VARCHAR2(20)にマッピングされる。
【００３４】
XML要素に適用され得る別の種類の制約が、要素が出現する最大回数を特定する制約である。最大回数が１よりも大きい場合、ターゲットのデータベースシステムがサポートするアレイ型（VARRAY等）に要素をマッピングできる。XML制約に対して特定された出現の回数は、VARRAYのカーディナリティを規定する。
【００３５】
XMLスキーマの要素に対して特定され得、適切なデータベース表現内の対応する制約に反映され得る他の種類の制約には、一意性の制約、参照一貫性の制約、not nullの制約等が含まれる。
【００３６】
継承のマッピング
XMLスキーマモデルは複合型の継承を可能にする。一実施例によると、XMLスキーマが継承の構成体を用いる場合、その継承は、ターゲットのデータベースシステムがサポートするSQLオブジェクトの継承機構にマッピングされる。たとえば、XMLスキーマ内において、XMLcomplexTypeの「USAddress」を別のcomplexTypeの「Address」の拡張子として宣言できる。それに応答して、適切なデータベース表現内では、「Address」に対応するSQLオブジェクト型の部分型としてSQLオブジェクト型「USAddress」が宣言される。
【００３７】
ローカルスキーマおよびグローバルスキーマ
XMLスキーマは、デフォルトにより、登録を行なうユーザに属する。XMLスキーマ文書への参照は、ディレクトリ/sys/schemas/<username>/...内のXDB階層内に格納される。たとえば、ユーザSCOTTが上述のスキーマを登録した場合、それはファイル/sys/schemas/SCOTT/www.oracle.com/PO.xsdにマッピングされる。このようなスキーマは、ローカルスキーマと呼ばれる。一般にこれらのスキーマは、そのスキーマが属するユーザによってのみ使用可能である。インスタンスXML文書に現われるスキーマ位置が単にURLであるため、スキーマURLをデータベースのユーザ名で適格化するという概念が存在しないことに注目されたい。したがって、スキーマの所有者のみが、XMLTypeのテーブル、列またはビュー、妥当性検証済文書等を定義する際にそのスキーマを用いることができる。
【００３８】
ローカルスキーマとは対照的に、特権を与えられたユーザは、dbms_xmlschema登録関数に対する引数を特定することによって、XMLスキーマをグローバルスキーマとして登録できる。グローバルスキーマを全ユーザが見ることができ、これらはXDB階層内の/sys/schemas/PUBLIC/...のディレクトリ下に格納される。このディレクトリへのアクセスがACLによって制御され、デフォルトによってDBAによってのみ書込可能であることに注意されたい。ユーザは、グローバルスキーマの登録を可能にするために、このディレクトリに関する書込特権を有する必要がある。
【００３９】
ユーザは、既存のグローバルスキーマと同じURLを有するローカルスキーマを登録することができる。ローカルスキーマは、同じ名前（URL）を有するどのようなグローバルスキーマをも常に隠している。
【００４０】
ユーザは、可能性として他のユーザが所有する既存のスキーマへのリンクを登録できる。スキーマリンクは、そのURLによって識別される。そこで、スキーマリンクURLは、スキーマURLが期待されるたびに、たとえばxmltypeテーブルを作成するたびに用いられ得る。スキーマリンクへの参照は、参照時に下位のスキーマへと翻訳される。ユーザがグローバルスキーマと同じ名前を有するローカルスキーマを有する場合、ユーザによるグローバルスキーマへの明示的な参照を可能にする機構が存在する。ユーザはグローバルスキーマへのリンク（異なる名前を有する）を登録できる。
【００４１】
XMLスキーマの削除
一実施例によると、dbms_xmlschema.deleteSchema手順を用いることにより、XMLスキーマを削除することができる。ユーザがスキーマを削除しようとする場合、データベースサーバはまず、その従属子が存在するかどうかをチェックする。従属子が存在する場合はデータベースサーバがエラーを生じ、削除動作は行われない。スキーマを削除する間にFORCEオプションが与えられ、ユーザがこのFORCEオプションを特定する場合、スキーマ削除は、たとえ従属性のチェックに合格していなくても進展する。このモードでは、スキーマ削除がスキーマの従属子のすべてを妥当ではないものとしてマークする。
【００４２】
XMLスキーマに対する従属性のモデル
一実施例によると、以下のオブジェクトは登録されたXMLスキーマに「従属する」。
【００４３】
・このスキーマ内の何らかの要素に準拠するXMLType列を有するTable／View。
【００４４】
・それらの定義の一部としてこのスキーマを含むかまたはインポートするXMLスキーマ。
【００４５】
・たとえばXMLGEN演算子内でスキーマ名を参照するカーソル（注：これらは純粋に一時的なオブジェクトである）。
【００４６】
以下の動作により、XMLスキーマオブジェクトに従属性が加えられる。
【００４７】
・スキーマ登録：含まれる／インポートされるスキーマのすべてに従属性を加える。
【００４８】
Table/View/Cursor作成：参照されたXMLスキーマオブジェクトにテーブル／ビュー／カーソルからの従属性を加える。
【００４９】
トランザクショナルな挙動
一実施例によると、スキーマの登録は非トランザクショナルなものであり、他のSQL DDLの動作と同様に自動的に遂行される。登録が成功すると、動作は自動的に遂行される。しかしながら、登録が失敗すると、データベースは登録開始前の状態にロールバックされる。スキーマ登録プロセスが潜在的にオブジェクト型およびテーブルの作成を含むため、エラーの回復は、作成されたこのようなテーブルおよび型のどのようなものも落とすことを含む。したがって、スキーマ登録の全体が原子的であるように保証される。すなわち、スキーマ登録の全体が成功するか、またはデータベースが登録開始前の状態に修復されるかのいずれかである。
【００５０】
XMLスキーマの進化
ユーザは、登録されたXMLスキーマを再登録して新規のXMLスキーマ文書を与えることにより、その登録されたXMLスキーマを進化させることができる。dbms_XMLschema.registerSchema関数を用いてXMLスキーマを再登録することができる。このスキーマに従属するXMLTypeテーブルが存在しない場合（XMLTypeビューは可能）、この動作は常に成功する。一実施例によると、従属するXMLTypeテーブルが存在する場合、データベースサーバ１０４は、入力されるスキーマ文書が完全なSQLマッピング注釈を含んで、かつ、それらがこのようなXMLTypeテーブルのすべてに適用され得る妥当なマッピングを表わすことを要求する。
【００５１】
例−要素名または属性名の変更：ユーザは登録されたスキーマ文書を取出して、必要な変更を行なってそれを再登録する。この変更が下位のテーブルに影響を及ぼさないことに注意されたい。
【００５２】
例−新規の要素または属性の追加：この変更は下位のテーブルに影響を及ぼすため、複数のステップで行われなければならない。ユーザはまず、ALTER TYPEおよび／またはALTER TABLEのコマンドを用いて下位のテーブルを進化させる。これにより、XMLスキーマは妥当でないものとしてマークされる。次に、ユーザはXMLスキーマ文書を適宜変更して、それを再登録する。
【００５３】
一実施例によると、１ステップのXMLスキーマ進化がもたらされる。すなわち、ユーザが新規のXMLスキーマを入力するだけで、下位の型およびテーブルの変更がすべて暗黙的に決定される。
【００５４】
XMLスキーマの暗黙的な登録
インスタンス文書がHTTPまたはFTP等のプロトコルを介してXDBに挿入されると、インス
タンス文書が準拠するスキーマ（特定されている場合）が、まだ登録されていない場合には暗黙的に登録される。スキーマ登録は常に自動的に遂行されるため、暗黙的な登録は自律的なトランザクション内で行なわれる。
【００５５】
XMLTypeテーブル
XMLスキーマの「適切なデータベース表現」の一部であるテーブルおよび列を、この明細書では「スキーマベースの」テーブルおよび列と呼ぶ。一実施例によると、スキーマベースのXMLTypeのテーブルおよび列は、（登録されたスキーマの）スキーマURLとルート要素名とを参照することによって作成できる。スキーマ位置および要素名の両方を含む１つのURLを提供する際に、XPointer記法の部分集合（以下に示す）も用いることができる。
【００５６】
【数４】

【００５７】
スキーマベースのXMLTypeは、デフォルトにより、下位の（隠された）オブジェクト型の列に格納される。スキーマの登録プロセス中に、SQLオブジェクト型を（任意に）作成することができる。XMLからSQLのオブジェクト型および属性へのマッピングは、追加の注釈、すなわちXDBが定義した新規の属性として、XMLスキーマ文書内にそれ自体が格納される。
【００５８】
スキーマベースのXMLTypeは、下位の１つのLOB列にも格納できる。
【００５９】
【数５】

【００６０】
SQLオブジェクト型の作成
一実施例によると、XMLスキーマが登録されるとき、データベースサーバ１０４は、このスキーマに準拠するXML文書の構造化された格納を可能にする適切なSQLオブジェクト型を作成する。SQLオブジェクト型はすべて、現時点でのユーザのスキーマにおいて（デフォルトによって）作成される。たとえば、PO.xsdが登録されている場合、以下のSQL型が作成される。
【００６１】
【数６】

【００６２】
上述のオブジェクトの型および属性の名前は、実際にシステムにより生成可能である。スキーマが、記入されたSQLName属性を既に含んでいる場合、この名前がオブジェクトの属性名として用いられる。そうでない場合、長さまたは矛盾の理由から使用できない場合を除き、名前はXML名から導出される。SQLSchema属性が記入されている場合、オラクル（Oracle）は、特定されたスキーマに型を作成しようとする。現時点でのユーザはこの動作を行なうために、何らかの必要な特権を有していなければならない。
【００６３】
オブジェクト型へのXMLスキーマへのマッピング−詳細な例
以下の章は、XMLスキーマ情報からSQLオブジェクト型をどのようにして生成できるかについての詳細を示す。上で述べたように、実際のマッピング規則は、さまざまな要因に基づいて実現例ごとに異なり得る。このような要因の１つが、ターゲットのデータベースシステムの機能である。以下の詳細な例では、ターゲットのデータベースシステムが、現在オラクル・コーポレイション（Oracle Corporation）から入手可能なOracle 9iR2で現在利用可能なデータ型およびオブジェクト型付けの機構をサポートするものと考える。
【００６４】
単純型のマッピング
一実施例によると、XML基本型は、最も近いSQLデータ型にマッピングされる。たとえば、decimal、positive Integer、およびfloatは、すべてSQLNUMBERにマッピングされる。XMLのenumeration（列挙）型は、１つのRAW(n)属性を有するオブジェクト型にマッピングされる。ここで、nの値は列挙宣言内で考えられる値の数によって決定される。XMLのリストまたはunionデータ型は、SQLの文字列（VARCHAR2/CLOB）データ型にマッピングされる。
【００６５】
【表１】

【００６６】
【表２】

【００６７】
複合型のマッピング
一実施例によると、複合型がオブジェクト型にマッピングされる。complexType内で宣言されたXML属性は、オブジェクト属性にマッピングする。そして、XML属性を定義するsimpleTypeは、対応する属性のSQLデータ型を決定する。complexType内で宣言されたXML要素もまた、オブジェクト属性にマッピングされる。オブジェクト属性のデータ型は、XML要素を定義するcomplexTypeまたはsimpleTypeによって決定される。
【００６８】
XML要素がmaxOccurs属性の値＞１で宣言された場合、この要素はSQLの集合属性にマッピングされる。集合は、（maintainOrder属性がFALSEに設定された場合）VARRAY（デフォルト）または入れ子構造のテーブルのいずれかであり得る。さらに、VARRAYのデフォルト格納は、LOBではなくテーブル（OCT）［OCT-FS］に存在する。そして、ユーザはstoreAsLob属性をTRUEに設定することによってLOB格納を選択できる。
【００６９】
一般に、SQL属性の名前は、以下のアルゴリズムを用い、XMLの要素または属性の名前から生成される。
【００７０】
１．XMLの要素／属性の名前を用いよ（３０文字に短縮される）。
【００７１】
２．違法なSQL文字が発見された場合、それを下線（'_'）にマッピングせよ。
【００７２】
３．この名前が一意ではない場合、シーケンス番号を追加せよ（注：このことは、番号を追加する前に名前の短縮をさらに要求し得る）。
しかしながら、ユーザは、このスキーマ内においてSQLName属性に対する値を与えることによって、SQL属性名を明示的に特定することができる。
【００７３】
DOM忠実度
XMLスキーマ内で宣言された要素および属性のすべては、対応するSQLオブジェクト型内の別個の属性にマッピングされる。しかしながら、XMLインスタンス文書には、このような要素／属性によって直接表現されない情報の断片がいくつか存在する。それらの例は、
・コメント
・名前空間宣言
・接頭辞の情報
である。
【００７４】
DOMトラバーサル（DOM忠実度と呼ばれる）のために、戻されたXML文書が最初の文書と同一であることを保証するため、生成されたSQLオブジェクト型のすべてにSYS_XDBPD$と呼ばれるバイナリ属性を加える。この属性は、他の属性のどれにも格納できない情報の断片のすべてを格納し、それによってデータベースシステム内に格納されたXML文書のDOM忠実度を確保する。注：SYS_XDBPD$属性は、はっきりさせるために、多くの例で省略される。しかしながら、この属性は、スキーマ登録プロセスによって生成されるSQLオブジェクト型のすべてに存在し得る。
【００７５】
SQLのライン外格納
一実施例によると、デフォルトによって、サブ要素は、埋込まれたオブジェクト属性にマッピングされる。しかしながら、ライン外格納がよりよい性能をもたらすシナリオも存在し得る。このような場合、SQLInline属性をFALSEに設定でき、XMLスキーママッパ１０６は、埋込まれたREF属性を有するオブジェクト型を生成する。REFは、ライン外で格納されるXMLフラグメントに対応するXMLTypeの別のインスタンスを指す。（XMLTypeの）デフォルトテーブルも、ライン外のフラグメントを格納するために作成される。
【００７６】
例
【００７７】
【数７】

【００７８】
LOBへのXMLフラグメントのマッピング
ユーザは複合要素に対するSQLTypeをLOB(CLOB/BLOB)として特定することができ、その場合、XMLフラグメントの全体がLOB属性に格納される。これは、XML文書の一部がほとんどクエリーされずに１つの断片として大抵は検索および格納されるシナリオにおいて有用である。LOBとしてフラグメントを格納することにより、構文解析／分解／再構成のオーバーヘッドが減じられる。
【００７９】
例
【００８０】
【数８】

【００８１】
simpleContentのマッピング
simpleContent宣言に基づいたcomplexTypeは、XML属性に対応する属性と、ボディ値に対応する追加のSYS_XDBBODY$属性とを有するオブジェクト型にマッピングされる。ボディ属性のデータ型は、ボディの型を定義するsimpleTypeに基づく。
【００８２】
例
【００８３】
【数９】

【００８４】
any/anyAttributeのマッピング
any要素宣言およびanyAttribute属性宣言は、オブジェクト型におけるLOBにマッピングされる。LOBはany宣言に整合するXMLフラグメントのテキストを格納する。名前空間の属性を用いて、特定された名前空間に属するようにコンテンツを制約することができる。any要素宣言内のprocessContents属性は、any宣言に整合するコンテンツに対して要求される妥当性のレベルを示す。
【００８５】
例
【００８６】
【数１０】

【００８７】
SQLのvarchar2対CLOBへの文字列のマッピング
XMLスキーマがデータ型を「string」に、かつ、４０００未満のmaxLength値に特定した場合、それは特定された長さのvarchar2属性にマッピングされる。しかしながら、maxLength値がXMLスキーマに特定されていない場合、それはLOBにしかマッピングされ得ない。これは、文字列の値の大部分が実際には小さく、それらのうちのごく一部がLOBを必要とするほどの大きさである場合に次善の策である。理想的なSQLデータ型は、小さな文字列に対してはvarcharsのように働きつつ、一層大きな文字列にも対処することのできるvarchar2(^*)であろう。さらに、このような列は、インデックス付け、SQL関数等のvarcharの機能性のすべてをサポートすべきである。小さな場合に対して性能および／または機能性を損なうことなく非有界のバイナリ値を保持するためにraw(^*)データ型を必要とするため、同様の場合が生じ得る。
【００８８】
代替的な実施例によると、非有界の文字列のすべてがCLOBにマッピングされて、非有界のバイナリ要素／属性のすべてがBLOBにマッピングされる。
【００８９】
SQLのvarchar2対NVARCHAR2への文字列のマッピング
デフォルトにより、XMLの文字列データ型はSQLのvarchar2にマッピングされる。しかしながら、ユーザは以下の２つの方法でこの挙動をオーバーライドすることができる。
【００９０】
１．ユーザは、SQLTypeを、特定の文字列の要素または属性に対してNVARCHAR2となるように特定できる。これにより、NVARCHAR2は特定の要素／属性に対するSQL型として確実に選択される。
【００９１】
２．ユーザは、スキーマ宣言の先頭において、mapStringToNCHAR属性を「true」に設定できる。これにより、すべてのXML文字列は、要素レベルで明示的にオーバーライドされない限りNVARCHAR2（またはNCLOB）データ型にマッピングされる。
【００９２】
スキーマベースのXMLテーブルの作成
"http://www.oracle.com/PO.xsd"によって識別されるXMLスキーマが既に登録されたものと考えられたい。XMLTypeテーブルを作成して、このスキーマのPurchaseOrder要素に準拠するインスタンスを、オブジェクト−リレーショナルなフォーマットで以下のように格納することができる。
【００９３】
【数１１】

【００９４】
PurchaseOrder要素がマッピングされたオブジェクト型に対応する隠し列が作成される。加えて、名前空間宣言等のトップレベルのインスタンスデータを格納するために、XMLExtraオブジェクト列が作成される。注：XMLDATAは、下位のオブジェクト列への直接のアクセスを可能にするXMLTypeの擬似属性である。
【００９５】
格納句（storage clause）の特定
下位の列は、
１．オブジェクト記法：XMLDATA.<attrl>.<attr2>....
２．XML記法：ExtractValue（xmltypecol、'/attr1/attr2'）
によって、格納句において参照され得る。
【００９６】
【数１２】

【００９７】
インデックスの作成
上で示したように、XMLtype列の下位にある列は、CREATE INDEXステートメントのオブジェクト記法またはXML記法のいずれかを用いて参照され得る。
【００９８】
【数１３】

【００９９】
制約
オブジェクト記法またはXML記法のいずれかを用いることにより、下位の列に対する制約を特定することができる。
【０１００】
【数１４】

【０１０１】
DML
以下のように、新規のインスタンスをXMLTypeテーブル内に挿入できる。
【０１０２】
【数１５】

【０１０３】
XMLTypeテーブルは、XPathベースのSQL演算子を用いてクエリーされ得る。
【０１０４】
【数１６】

【０１０５】
クエリー書換機構は、existsNodeおよびextractoperatorsを含むクエリーを書換えて下位の属性の列に直接アクセスし、それによってXMLの構成後にXPathの評価が続くことを避ける。たとえば、上述のクエリーは、以下のものに書換えられる。
【０１０６】
【数１７】

【０１０７】
クエリー書換
スキーマベースのXMLType列上で演算するXPathベースの演算子（Extract、ExistNode、ExtractValue）は、下位のSQL列に反するように書換えられる。これにより、XMLのオブジェクト−リレーショナルな格納を最大限に利用する、さらなるSQLの最適化が可能になる。以下の種類のXPath式は、下位のSQLクエリーに翻訳され得る。
【０１０８】
１．単純なXPath式−オブジェクト型の属性のみにわたるトラバーサルに関わり、属性は単純なスカラまたはオブジェクト型自体である。サポートされる軸は、子軸および属性軸のみである。
【０１０９】
２．集合トラバーサル式−集合式のトラバーサルに関わる。サポートされる軸は、子軸および属性軸のみである。
【０１１０】
３．^*軸に関わる式−結果的に得られるノードのデータ型がすべて強制である場合、ワイルドカード軸に関わるこれらの式を変換する。（たとえばCUST/^*/CUSTNAMEは、同一のまたは強制的なデータ型のすべてであるCUSTNAMEを指さなければならない。
【０１１１】
４．子孫軸（//）に関わる式−結果として得られるノードのデータ型が同一または強制である場合、これらの式を変換する。
【０１１２】
５．これらの式はすべて、XMLType等に対するREFのような「隠れた」トラバーサルを含む型のキャッシュとともに作業しなければならない（たとえば、xdb$schema_tは、xdb$element_tに対するREFのvarrayを格納しており、このことは、XPath式または結果として得られるXML文書に直接現われない）。
【０１１３】
これらのXPath式の変形は、ExistsNode、ExtractValue、およびExtract usageのシナリオでサポートされる。
【０１１４】
XPathのクエリー書換の例
【０１１５】
【数１８】

【０１１６】
関数書換規則
EXTRACT、EXTRACTVALUE、およびEXISTSNODEは、以下の位置、すなわち、
・選択リスト内のSQLクエリーにおいて句述部のグループ別および順序別の式
・CREATE INDEXステートメントのIndex句
に出現し得る。
【０１１７】
【数１９】

【０１１８】
これらの場合のすべてにおいて、EXISTSNODEおよびEXTRACTの演算子は、下位の式を定義することによって置き換えられる。XPath式は書換えられるために以前のセクションに記載された条件を満たさなければならない。
【０１１９】
インデックスの場合において、演算子ツリー全体の置き換えが１つの列を生じる場合、そのインデックスは、関数インデックスではなく、列上のドメインインデックスまたはBTreeインデックスに変化する。
【０１２０】
オブジェクト／スカラ属性のトラバーサルに対する書換
単純なXPathトラバーサルは、オブジェクト型のアクセス機構に書換えられる。述部は、それらをwhere句に入れることによって処理される。或るオブジェクト型全体にわたるXPathの子のアクセスは、下位のオブジェクト型のオブジェクト属性のアクセスに翻訳される。たとえば、A/Bはa.bにマッピングし、ここでAはオブジェクト型aにマッピングし、XPathのノードBは「a」と名付けられた「b」の属性にマッピングする。
【０１２１】
この書換は、XPath式のどのようなレベルにおいても、すなわち、XPathトラバーサルが述部内またはロケーションパス変数内のいずれに生じていても一貫している。
【０１２２】
たとえば、PO/CUSTOMER/CUSTOMERNAMEは"po"."cust"."custname".となる（POが'po'にマッピングする等と考えられたい）。
【０１２３】
述部は、下位のオブジェクト式の述部式を書換えることによって処理される。
【０１２４】
EXISTSNODEに対する単純な場合では、主なロケーションパストラバーサルがIS NOT NULL述部になるのに対し、EXTRACTの場合では、これが抽出される実際のノードになる。
【０１２５】
EXISTNODE(po_col, 'PO/CUSTOMER/CUSTOMERNAME')は、
CASE (WHEN("po"."cust"."custname" IS NOT NULL) then 1 else 0)
となる。
【０１２６】
述部は同様の態様で処理される。たとえば、以下に与えられた演算子、すなわち
EXISTNODE(po_col, 'PO/CUSTOMER[CUSTOMERNO=20]/CUSTOMERNAME')
において、述部、D=20はユーザが特定したかのように処理され(A/B/D=20）、したがって式全体は、
CASE(WHEN("PO"."CUST"."CUSTNAME"IS NOT NULL
AND("PO"."CUST"."CUSTNO"=20))THEN 1 ELSE 0)
となる。
【０１２７】
集合トラバーサル
XPath式は、集合構成体にも及び得、クエリーは集合テーブル上のサブクエリーを用いることにより、依然として書換えられる。たとえば、EXISTSNODE(po_col,'/PO/Lineitems[lineitemno=20]')は、購入指示書内に項目が存在するかどうかをチェックし、ここで項目数は２０である。これは、
case(when(exists(select^*from TABLE("po"."lineitems")where lineitemno=20))then 1 else 0)
となる。
【０１２８】
デフォルトテーブル
スキーマ登録の一部として、デフォルトテーブルも作成することができる。デフォルトテーブルは、このスキーマに準拠するXMLインスタンス文書が、どのようなテーブル仕様も有さないFTP、HTTP等のAPIを介して挿入される場合に最も有用である。このような場合、XMLインスタンスはデフォルトテーブル内に挿入される。
【０１２９】
ユーザがdefaultTable属性に値を与えている場合、XMLTypeテーブルはその名前で作成される。または、何らかの内部で生成された名前で作成される。さらに、tableStorage属性として特定されたどのようなテキストも、生成されたCREATETABLEステートメントに追加される。
【０１３０】
内部メモリデータ型の特定
XMLデータはRDBMSメモリ内のC構造に格納される。一般に、XMLデータのインメモリ表現は、それがロード時間におけるデータ型の変換を避けようとし、かつ、アクセスされたときにのみデータを変換するようなものである。なぜなら、文書の多くの部分は全くアクセスされないことが考えられるためである。スキーマ登録の一部として、インメモリデータ型がXMLデータ型に基づいて選択される。そして、この情報は、memDatatype属性を用いてスキーマ文書内に格納される。しかしながら、アプリケーションが、異なるインメモリ表現を優先させて、デフォルトメモリ型をオーバーライドすることを望み得るいくつかのシナリオがある。
【０１３１】
たとえば、文字列のデフォルトメモリ表現は、データベースセッションの文字集合に文字列データを保持する「char」である。しかしながら、このデータが固定幅UCS-2ユニコード（Fixed Width UCS-2 Unicode）であることを要求するJava（登録商標）アプリケーションによってのみこのデータが消費される場合、memDatatypeを「Java（登録商標）String」に設定すると、性能を一層高めることができる。これにより、データベースサーバ１０４は、ユニコードのフォーマットでJava（登録商標）メモリ内に確実にデータを直接保持し、それによってどのようなフォーマットの変換またはコピーも回避する。
【０１３２】
【表３】

【０１３３】
マッピング情報の生成
適切なデータベース表現が特定のXMLスキーマに対して決定されると、特定のXMLスキーマで識別された要素と適切なデータベース表現の要素との間の相関関係を示すためにマッピング情報が生成される。たとえば、型「person」に対するXMLスキーマに対する適切なデータベース表現が、personXML文書に含まれるデータアイテムを格納するためのテーブルPERSONを含む場合、マッピング情報は、personXML文書とテーブルPERSONとの間の相関関係を示す。
【０１３４】
XMLスキーマとデータベーススキーマオブジェクト（テーブル等）との間の一般的な相関関係に加え、マッピング情報は,より一層細かいレベルの細分性で相関関係を反映できる。たとえば、マッピング情報は、PERSONテーブルのどの特定の列が、personXML文書内の特定のデータアイテムの各々を格納するために用いられるべきであるかを示し得る。
【０１３５】
一実施例によると、SQLマッピングに関する情報自体は、XMLスキーマ文書内に格納される。登録プロセス中に、XMLスキーママッパ１０６は（上で述べたように）SQL型を生成する。加えて、XMLスキーママッパ１０６は、マッピング情報を格納するためにXMLスキーマ文書に注釈を加える。注釈は、新規の属性の形をとる。例：以下のスキーマは、SQLType属性およびSQLName属性を介して収集されたSQLマッピング情報を示す。
【０１３６】
【数２０】

【０１３７】
入力スキーマ文書における、ユーザによって特定された名前
ユーザは、スキーマを登録する前に、SQLName属性およびSQLType属性に記入することによって、SQLオブジェクト型およびその属性の名前を特定することができる。SQLNameおよびSQLTypeの値がユーザによって特定される場合、XMLスキーママッパ１０６はこれらの名前を用いてSQLオブジェクト型を作製する。これらの属性がユーザによって特定されない場合、内部の名前生成アルゴリズムを用いて名前を生成する。名前生成アルゴリズムに関する詳細は、付録を参照されたい。
【０１３８】
以下の表は、SQLマッピング情報を収集するためにスキーマ内で用いられる注釈のすべてを記載している。ユーザがこれらの属性のいずれに対しても値を特定する必要のないことに注意されたい。XMLスキーママッパ１０６はスキーマ登録プロセス中に適切な値を記入する。しかしながら、ユーザが少なくともトップレベルのSQL型の名前を特定して、後にそれらを参照可能にすることが勧められる。注釈はすべて、属性宣言および要素宣言内で特定され得る属性の形をとる。これらの属性は、XDB名前空間である、http://xmlns.oracle.com/xdb/XDBSchema.xsdに属する。
【０１３９】
【表４】

【０１４０】
【表５】

【０１４１】
ハイブリッド格納モデル
一実施例によると、XMLスキーママッパ１０６は、ハイブリッド格納モデルをサポートするように実現される。このハイブリッド格納モデルにおいて、XMLスキーマ内で定義された或る要素の構造は適切なデータベース表現に維持され、或る要素の構造は維持されない。たとえば、XML文書型の最も頻繁にクエリー／更新される部分はオブジェクト型の属性にマッピングされ得、一方でXML文書の残りの部分はともにCLOB内に格納される。一実施例によると、それに対して構造が維持されるべきであるか、または維持されるべきではない特定の部分は、適切なマッピング指示文でXMLスキーマに予め注釈を付けることによって指定される。
【０１４２】
XMLスキーマ登録のトランザクショナルな本質
一実施例によると、XMLスキーマ登録は、スキーマ登録動作中にエラーに遭遇すると部分的な作用を取消す補償動作の実行を可能にする態様で、データベースサーバ１０４のトランザクションサポートを用いて行なわれる。
【０１４３】
XMLスキーマにおけるサイクル定義の処理
XMLスキーマはサイクルを含み得る。一実施例によると、XMLスキーママッパ１０６は、SQLオブジェクト型にマッピングする間に、REFを用いることによってこのようなサイクルを検出してそれらを破壊するように構成される。REFをどのように用いてサイクルを破壊するかについての詳細な説明を、付録Ｉに提示する。
【０１４４】
マッピング情報に基づいたXML文書の格納
特定の文書型に対するXMLスキーマがデータベースサーバ１０４に登録された後に、そのスキーマに準拠するXML文書をデータベースサーバ１０４によってインテリジェントに管理することができる。一実施例によると、データベースサーバ１０４が管理するデータベースにリソースが格納されなければならないことをプロトコルが示すと、データベースサーバ１０４が.xml、.xsl、.xsd等に対する文書のファイル名拡張子をチェックする。文書がXMLである場合、予め構文解析するステップが行なわれ、その文書のルート要素のXML schemaLocationおよびnamespaceを決定するために十分なリソースが読出される。この位置は、そのschemaLocation URLを有して登録されたスキーマを探すために用いられる。登録されたスキーマが現在の文書のルート要素に対する定義によって位置付けられている場合、そのリソースの内容を格納するために、その要素に対して特定されたデフォルトテーブルを用いる。
【０１４５】
一実施例によると、この明細書に記載されたXMLスキーマ登録技術をサポートするデータベースサーバにXML文書が格納されると、データベースサーバは文書の妥当性を検証して、それらの文書が対応するXMLスキーマに準拠することを確認できる。この妥当性検証は、XML文書が用いる構造およびデータ型の両方の妥当性検証を含み得る。
【０１４６】
この明細書に記載された技術を用いることによって他のさまざまな利点が得られる。たとえば、スキーマ登録プロセスにより、データベースサーバは、XML文書およびそれらを格納するために用いられるテーブルに対して完全性の制約および他の形の制約を実施することができる。加えて、データベースサーバは、XMLデータに基づいてXMLテーブルにインデックスを作成して区画することができる。
【０１４７】
XML文書からのデータがデータベース内に格納される要領にXML文書の構造が反映されるため、この構造を反映するために一般に用いられるタグ情報は、そのデータとともに格納される必要はない。XMLタグのいくつかまたはすべての格納を回避できることから、格納のオーバーヘッドを著しく減じることができる。なぜなら、XMLタグがXML文書のサイズの大きな部分をなすことが多いためである。
【０１４８】
他の性能の利点も可能になる。たとえば、XPathクエリーを書換えて下位の列に直接アクセスすることによってクエリーの性能を高めることができる。加えて、更新を書換えて下位の列を直接更新することによって更新の性能を高めることができる。したがって、格納された文書からのXMLデータの一部を更新しても、格納された文書に対してXMLデータ全体の書換えは必ずしも要求されない。
【０１４９】
ハードウェアの概観
図２は、この発明の一実施例が実現され得るコンピュータシステム２００を示すブロック図である。コンピュータシステム２００は、バス２０２または情報を通信するための他の通信機構と、バス２０２に結合されて情報を処理するためのプロセッサ２０４とを含む。コンピュータシステム２００は、バス２０２に結合されてプロセッサ２０４が実行する命令および情報を格納するためのメインメモリ２０６、たとえばランダムアクセスメモリ（RAM）または他の動的記憶装置も含む。メインメモリ２０６は、プロセッサ２０４が実行する命令の実行中に、一時的数値変数または他の中間情報を格納するためにも使用可能である。コンピュータシステム２００は、バス２０２に結合されてプロセッサ２０４に対する静的情報および命令を格納するための読出専用メモリ（ROM）２０８または他の静的記憶装置をさらに含む。磁気ディスクまたは光学ディスク等の記憶装置２１０が設けられてバス２０２に結合され、情報および命令を格納する。
【０１５０】
コンピュータシステム２００は、コンピュータユーザに情報を表示するためのディスプレイ２１２、たとえば陰極線管（CRT）に、バス２０２を介して結合され得る。英数字キーおよび他のキーを含む入力装置２１４がバス２０２に結合されて、情報および指令選択をプロセッサ２０４に通信する。別の種類のユーザ入力装置が、方向情報および指令選択をプロセッサ２０４に通信してディスプレイ２１２上のカーソル動作を制御するためのカーソル制御２１６、たとえばマウス、トラックボール、またはカーソル方向キーである。この入力装置は一般に、２つの軸、すなわち第１の軸（x等）および第２の軸（y等）において２自由度を有し、これによって入力装置は平面上で位置を特定できる。
【０１５１】
この発明は、この明細書に記載された技術を実現するためにコンピュータシステム２００を用いることに関する。この発明の一実施例によると、これらの技術は、メインメモリ２０６に含まれる１つ以上の命令からなる１つ以上のシーケンスをプロセッサ２０４が実行することに応答して、コンピュータシステム２００により実行される。このような命令は、別のコンピュータ読取可能な媒体、たとえば記憶装置２１０等からメインメモリ２０６内に読出すことができる。メインメモリ２０６に含まれる命令のシーケンスを実行することにより、プロセッサ２０４はこの明細書に記載された処理のステップを実行する。代替的な実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せて結線回路を用いて、この発明を実施することができる。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアの任意の特定の組合せに限定されない。
【０１５２】
この明細書で用いられる「コンピュータ読取可能な媒体」という用語は、プロセッサ２０４に対して実行のために命令を提供することにかかわる任意の媒体を指す。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含む多くの形態をとり得るが、これらに限定されない。不揮発性媒体には、たとえば記憶装置２１０等の光学または磁気ディスクが含まれる。揮発性媒体には、メインメモリ２０６等の動的メモリが含まれる。伝送媒体には、同軸ケーブル、銅線、および光ファイバが含まれ、バス２０２を有するワイヤが含まれる。伝送媒体は、電波および赤外線データ通信の際に生成されるもの等の音波または光波の形をとり得る。
【０１５３】
コンピュータ読取可能な媒体の一般的な形態には、たとえばフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、CD-ROM、任意の他の光学媒体、パンチカード、紙テープ、孔パターンを有する任意の他の物理的媒体、RAM、PROM、EPROM、FLASH-EPROM、任意の他のメモリチップもしくはカートリッジ、以下に述べる搬送波、またはコンピュータが読出すことのできる任意の他の媒体が含まれる。
【０１５４】
プロセッサ２０４に対して実行のために１つ以上の命令からなる１つ以上のシーケンスを運ぶ際に、コンピュータ読取可能な媒体のさまざまな形態が関与し得る。たとえば、命令は、最初に遠隔コンピュータの磁気ディスクで運ばれ得る。遠隔コンピュータはそれらの命令をそれ自体の動的メモリにロードして、それらの命令を、モデムを用いて電話回線経由で送信することができる。コンピュータシステム２００に対してローカルなモデムが電話回線上のデータを受信して、赤外線送信機を用いてそのデータを赤外線信号に変換することができる。赤外線信号によって運ばれたデータは赤外線検出器によって受信され得、適切な回路がそのデータをバス２０２上に出力することができる。バス２０２はそのデータをメインメモリ２０６に運び、そこからプロセッサ２０４が命令を取り出して実行する。メインメモリ２０６が受信した命令は、プロセッサ２０４による実行前または実行後のいずれかに、記憶装置２１０に任意に格納され得る。
【０１５５】
コンピュータシステム２００は、バス２０２に結合された通信インターフェイス２１８も含む。通信インターフェイス２１８は、ローカルネットワーク２２２に接続されたネットワークリンク２２０に対する双方向のデータ通信結合をもたらす。たとえば通信インターフェイス２１８は、対応する種類の電話回線に対するデータ通信接続を設けるためのサービス統合デジタル網（ISDN）カードまたはモデムであり得る。別の例として、通信インターフェイス２１８は、互換性を有するLANにデータ通信接続を設けるためのローカルエリアネットワーク（LAN）カードであり得る。無線リンクもまた実現することができる。このようなどの実現例においても、通信インターフェイス２１８は、さまざまな種類の情報を表わすデジタルデータストリームを運ぶ電気的、電磁的、または光学的信号を送受信する。
【０１５６】
ネットワークリンク２２０は一般に、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信をもたらす。たとえば、ネットワークリンク２２０は、ローカルネットワーク２２２経由でホストコンピュータ２２４またはインターネットサービスプロバイダ（Internet Service Provider）（ISP）２２６が作動させるデータ装置に接続をもたらすことができる。ISP２２６は次いで、現在一般に「インターネット」２２８と呼ばれるワールドワイドパケットデータ通信網を介してデータ通信サービスを提供する。ローカルネットワーク２２２およびインターネット２２８はともに、デジタルデータストリームを運ぶ電気的、電磁的、または光学的信号を用いる。さまざまなネットワークを経由する信号と、ネットワークリンク２２０上の、コンピュータシステム２００との間でデジタルデータを運ぶ通信インターフェイス２１８経由の信号とは、情報を運搬する搬送波の例示的形態である。
【０１５７】
コンピュータシステム２００は、ネットワーク、ネットワークリンク２２０、および通信インターフェイス２１８を介してメッセージを送信してプログラムコードを含むデータを受信することができる。インターネットの例では、サーバ２３０は、インターネット２２８、ISP２２６、ローカルネットワーク２２２および通信インターフェイス２１８経由でアプリケーションプログラムに対して要求されたコードを送信することができる。
【０１５８】
受信されたコードは、受信されたときにプロセッサ２０４によって実行され得、および／または後の実行のために記憶装置２１０もしくは他の不揮発性記憶装置に格納され得る。このようにして、コンピュータシステム２００は搬送波の形でアプリケーションコードを得ることができる。
【０１５９】
上述の明細書では、この発明の実施例を実現例ごとに異なり得る多数の特定の詳細を参照して説明してきた。したがって、この発明が何であるか、およびこの発明を目指して出願人が何を意図しているかを独占的に示す唯一ものが、この出願から発生して特有の形態をとった請求項の組である。特有の形態においてこのような請求項は、以降の任意の補正を含んで発生する。このような請求項に含まれる用語に対してこの明細書で明示された任意の定義は、請求項で用いられている通りにこのような用語の意味を支配するものとする。したがって、請求項に明示的に記載されていない限定、要素、特性、特徴、利点または属性は、このような請求項の範囲を決して限定しない。したがって、明細書および図面は限定的な意味ではなく例示的な意味で捉えられるべきである。
【０１６０】
［付録Ｉ］
（Oracle9i XML データベース開発者用ガイド−オラクルXML DB：Oracle9i XML Database Developer's Guide - Oracle XML DB）
・XMLスキーマの紹介
・XMLスキーマおよびオラクルXML DBの紹介
・オラクルXML DBおよびXMLスキーマの使用
・DBMS_XMLSCHEMAの紹介
・オラクルXML DB使用前のXMLスキーマの登録
・DBMS_XMLSCHEMAを使用したXMLスキーマの削除
・登録されたXMLスキーマを使用するための指針
・XMLスキーマ登録中のJava（登録商標）Bean生成
・DBMS_XMLSCHEMA.generateSchema()を使用した、オブジェクトリレーショナル型からのXMLスキーマの生成
・XMLTypeのXMLスキーマに関連する方法
・XMLスキーマの管理および格納
・DOM忠実度
・XMLスキーマに基づいたオラクルXML DBによるXMLTypeテーブルおよび列の作成
・XMLスキーマ登録前にSQLオブジェクト型名を特定するためのSQLName属性およびSQLType属性の使用
・DBMS_XMLSCHEMAを使用した型のマッピング
・XMLスキーマ：SimpleTypeのSQLへのマッピング
・XMLスキーマ：ComplexTypeのSQLへのマッピング
・オラクルXML DB complexTypeの拡張および制限
・XMLスキーマベースのXMLテーブルを作成するためのさらなる指針
・XMLスキーマベースのオブジェクトリレーショナル格納でのクエリー書換
・XMLスキーマ登録中のデフォルトテーブルの作成
・テーブル内順序付き集合(OCT)
・XMLスキーマ間での循環参照
XMLスキーマの紹介
XMLスキーマ勧告は、XMLにおけるXML文書の内容および構造を記述するために、ワールドワイドウェブコンソーシアム(W3C)によって作成された。それは文書型定義(DTD)の全能力を含んでおり、そのため既存のDTDはXMLスキーマに変換可能である。DTDと比較して、XMLスキーマはさらなる能力を有する。
XMLスキーマおよびオラクルXML DBの紹介
XMLスキーマは、XMLで書かれたスキーマ定義言語である。それは、準拠するインスタンス文書の構造およびさまざまな他の意味論を記述するために使用可能である。たとえば、以下のXMLスキーマ定義po.xsdは、注文書XML文書の構造および他の特性を記述している。
【０１６１】
このマニュアルでは、XMLスキーマ定義をXMLスキーマと呼ぶ。
【０１６２】
例５−１ XMLスキーマ定義po.xsd
以下は、XMLスキーマ定義po.xsdの一例である。
【０１６３】
【数２１】

【０１６４】
例５−２ XMLスキーマpo.xsdに準拠するXML文書po.xml
以下は、XMLスキーマpo.xsdに準拠するXML文書の一例である。
【０１６５】
【数２２】

【０１６６】
注：
ここで使用されるURL‘http://www.oracle.com/PO.xsd'は単に、データベース内の登録されたXMLスキーマを一意的に識別する名前であり、XMLスキーマ文書が配置されている物理的なURLである必要はない。また、XMLスキーマのターゲット名前空間は、その中で要素および型が宣言された抽象的な名前空間を特定する、XMLスキーマ位置URLとは異なる別のURLである。
【０１６７】
XMLスキーマは随意でターゲット名前空間URLを特定できる。この属性が省略されている場合、XMLスキーマはターゲット名前空間を持たない。注：targetnamespaceは通常、XMLスキーマのURLと同じである。
【０１６８】
XMLインスタンス文書は、ルート要素の名前空間（XMLスキーマのターゲット名前空間と同じ）と、このルート要素を定義するXMLスキーマの位置(URL)との双方を特定しなければならない。この位置は属性xsi:schemaLocationで特定される。XMLスキーマがターゲット名前空間を持たない場合、XMLスキーマURLを特定するために属性xsi:noNamespaceSchemaLocationを使用する。
オラクルXML DBおよびXMLスキーマの使用
オラクルXML DBは注釈付きのXMLスキーマをメタデータ、つまり、オラクルXML DBによって規定されたいくつかの属性を伴った標準XMLスキーマ定義として使用する。これらの属性は異なる名前空間にあり、インスタンス文書がデータベースにいかにマッピングされるかを制御する。これらの属性はXMLスキーマ名前空間とは異なる名前空間にあるため、そのような注釈付きのXMLスキーマは依然として正当なXMLスキーマ文書である。
【０１６９】
オラクルXML DBを使用する際、まず自分のXMLスキーマを登録しなければならない。そうすれば、XMLTypeテーブル、列、およびビューを作成する間、そのXMLスキーマURLが使用できる。
【０１７０】
オラクルXML DBは、以下のタスクのためにXMLスキーマサポートを提供する。
【０１７１】
・任意のW3C準拠のXMLスキーマを登録すること。
【０１７２】
・登録されたXMLスキーマ定義に対し、自分のXML文書の妥当性を検証すること。
【０１７３】
・ローカルおよびグローバルXMLスキーマを登録すること。
【０１７４】
・オブジェクト型からXMLスキーマを生成すること。
【０１７５】
・別のユーザが所有するXMLスキーマを参照すること。
【０１７６】
・ローカルXMLスキーマが同じ名前で存在する場合に、グローバルXMLスキーマを明確に参照すること。
【０１７７】
・XMLスキーマ登録中に、自分のXMLスキーマから構造化データベースマッピングを生成すること。これは、SQLオブジェクト型、集合型、およびデフォルトテーブルを生成することと、XMLスキーマ属性を用いてマッピング情報を取得することとを含む。
【０１７８】
・多数の正当なマッピングがある場合に、ある特定のSQL型マッピングを特定すること。
【０１７９】
・登録されたXMLスキーマに基づいて、XMLTypeテーブル、ビュー、および列を作成すること。
【０１８０】
・XMLスキーマベースのXMLTypeテーブルに対し、操作(DML)およびクエリーを実行すること。
【０１８１】
・スキーマベースのXMLインスタンスがFTP、HTTP/WebDavプロトコルおよび他の言語を用いてオラクルXML DBリポジトリに挿入される場合に、データをデフォルトテーブルへ自動的に挿入すること。
XMLスキーマはなぜ必要か？
XMLTypeは、データベース内の列およびテーブルへのXMLの格納を容易にするデータ型である。XMLスキーマは、データベースへのXML列およびテーブルの格納をさらに容易にし、空間性能節約オプションに加え、XMLデータ用のより多くの格納およびアクセスオプションを提供する。
【０１８２】
たとえば、XMLスキーマを用いて、どの要素および属性が使用可能か、どの種類の要素入れ子化およびデータ型が格納または処理中のXML文書において可能であるかを宣言することができる。
【０１８３】
XMLスキーマはXMLからSQLへの柔軟なマッピングセットアップを提供する
オラクルXML DBでのXMLスキーマの使用は、XML格納マッピングのための柔軟なセットアップを提供する。たとえば：
・データが高度に構造化されている場合（大部分がXML）、XML文書の各要素はテーブル内の或る列として格納可能である。
【０１８４】
・データが構造化されていない場合（すべてまたは大部分が非XMLデータ）、データは文字ラージオブジェクト(CLOB)に格納可能である。
【０１８５】
どの格納方法を選択するかは、自分のデータをどう使用するかに依存し、クエリー可能性、および、自分のデータをクエリーして更新するための自分の要件に依存する。言い換えれば、XMLスキーマの使用により、高度に構造化されたデータ、または構造化されていないデータを格納するためのより一層の柔軟性が与えられる。
【０１８６】
XMLスキーマはXMLインスタンスの妥当性検証を可能にする
オラクルXML DBでXMLスキーマを使用する別の利点は、XMLスキーマに従い、最高性能のためのオラクルXMLリポジトリ要件を基準にして、XMLインスタンスの妥当性検証を実行できる点である。たとえば、XMLスキーマは、許容されたアイテム発生の許容された構造、型、数、またはアイテムの許容された長さなどの、XMLスキーマにおいて宣言された定義に、すべての入力XML文書が準拠することをチェックできる。
【０１８７】
また、オラクルXML DBにXMLスキーマを登録することにより、FTPまたはHTTPなどのプロトコルを使用してXMLインスタンスを挿入し、格納する場合に、XMLスキーマ情報はいかに効率よくXMLインスタンスが挿入されるかに影響を与え得る。
【０１８８】
XMLインスタンスが、それらについての事前情報なしで取扱われなければならない場合、XMLスキーマは、最適な格納、忠実度、およびアクセスを予測する上で有用となり得る。
DBMS_XMLSCHEMAの紹介
オラクルXML DBのXMLスキーマ機能性は、オラクルXML DBアプリケーションによって使用されるXMLスキーマ定義の登録を取扱うサーバ側構成要素のPL/SQL供給パッケージ、DBMS_XMLSCHEMAを介して利用可能である。
【０１８９】
主なDBMS_XMLSCHEMA関数のうちの２つを以下に挙げる。
【０１９０】
・registerSchema()：これは、以下の事項が与えられたXMLスキーマを登録する。
【０１９１】
・文字列、LOB、XMLType、およびURITypeを含むさまざまなフォーマットであり得るXMLスキーマソース
・そのスキーマURLまたはXMLSchema名
・deleteSchema()：これは、そのURLまたはXMLSchema名によって識別された、以前に登録されたXMLスキーマを削除する。
オラクルXML DB使用前のXMLスキーマの登録
XMLスキーマは、それがオラクルXML DBによって任意のコンテキストにおいて使用または参照され得る前に、登録されなければならない。XMLスキーマは、DBMS_XMLSCHEMA.registerSchema()を使用し、以下の事項を特定することによって登録される：
・VARCHAR、CLOB、XMLType、またはURITypeとしてのXMLスキーマソース文書。
【０１９２】
・XMLスキーマURL。これは、XMLインスタンス文書内で使用される、それらの文書が準拠するXMLスキーマの位置を特定するためのXMLスキーマ用名前である。
【０１９３】
登録完了後：
・このXMLスキーマに準拠し、それをXML文書内のXMLスキーマのURLを用いて参照するXML文書は、オラクルXML DBによって処理可能である。
【０１９４】
・このXMLスキーマによって定義されたルートXML要素のためにテーブルおよび列を作成し、準拠するXML文書を格納することが可能である。
DBMS_XMLSCHEMAを使用したXMLスキーマの登録
DBMS_XMLSCHEMAを使用してXMLスキーマを登録する。これは、XMLスキーマ文書と、XMLスキーマ位置としても公知のそのURLとを特定することを伴う。
【０１９５】
例５−３ DBMS_XMLSCHEMAを使用した、complexTypeを宣言するXMLスキーマの登録
以下に示すXMLスキーマを考慮されたい。それは、PurchaseOrderTypeと呼ばれるcomplexTypeと、この型の要素PurchaseOrderとを宣言している。このスキーマはPL/SQL可変docに格納される。以下は、XMLスキーマをURL:http://www.oracle.com/PO.xsdに登録する。
【０１９６】
【数２３】

【０１９７】
登録されたスキーマを用いて、XMLスキーマベースのテーブル、またはXMLスキーマベースの列を作成することができる。たとえば、以下のステートメントは、XMLスキーマベースの列を有するテーブルを作成する。
【０１９８】
【数２４】

【０１９９】
以下は、上のテーブルに挿入中の前述のXMLスキーマに準拠するXMLTypeインスタンスを示す。schemaLocation属性はスキーマURLを特定する。
【０２００】
【数２５】

【０２０１】
ローカルおよびグローバルXMLスキーマ
XMLスキーマは、ローカルまたはグローバルとして登録可能である。
【０２０２】
・ローカルXMLスキーマ：ローカルスキーマとして登録されたXMLスキーマは、デフォルトにより、所有者しか見ることができない。
【０２０３】
・グローバルXMLスキーマ：グローバルスキーマとして登録されたXMLスキーマは、デフォルトにより、データベースユーザ全員が見たり使用することができる。
【０２０４】
あるXMLスキーマを登録する場合、DBMS_XMLSCHEMAは、そのXMLスキーマに対応するオラクルXML DBリソースをオラクルXML DBリポジトリに追加する。XMLスキーマURLは、以下の規則に従って、オラクルXML DBリポジトリにおけるリソースの経路名を判断する。
【０２０５】
ローカルXMLスキーマ
オラクルXML DBでは、ローカルXMLスキーマリソースは、/sys/schemas/<username>ディレクトリの下で作成される。経路名の残りはスキーマURLから得られる。
【０２０６】
例５−４ ローカルXMLスキーマ
たとえば、スキーマURL：http://www.myco.com/PO.xsdを有し、スコット(SCOTT)によって登録されたローカルXMLスキーマには、経路名：/sys/schemas/SCOTT/www.myco.com/PO.xsdが与えられる。
【０２０７】
XMLスキーマをローカルXMLスキーマとして登録するには、データベースユーザは、この経路名でリソースを作成する適切な許可(ACL)を必要とする。
【０２０８】
デフォルトにより、XMLスキーマは、そのXMLスキーマをオラクルXML DBに登録した後でユーザに属する。XMLスキーマ文書への参照は、オラクルXML DBリポジトリに、ディレクトリ：/sys/schemas/<username>/....に格納される。
【０２０９】
たとえば、SCOTTが前述のXMLスキーマを登録した場合、それはファイル：/sys/schemas/SCOTT/www.oracle.com/PO.xsdにマッピングされる。
【０２１０】
そのようなXMLスキーマはローカルと呼ばれる。一般に、それらはそれらが属する者にしか利用できない。
【０２１１】
注：通常、XMLスキーマを用いてXMLTypeテーブル、列またはビューを定義したり、文書の妥当性を検証したりすることなどができるのは、XMLスキーマの所有者のみである。しかしながら、オラクルは、http://xmlns.oracle.com/xdb/schemas/SCOTT/www.oracle.com/PO.xsdとして特定され得る、十分に適格なXMLスキーマURLをサポートしている。この拡張URLは、特権を与えられたユーザが他のユーザに属するXMLスキーマを特定するために使用可能である。
【０２１２】
グローバルXMLスキーマ
ローカルスキーマとは対照的に、特権を与えられたユーザは、DBMS_XMLSCHEMA登録関数に対して引数を特定することによって、XMLスキーマをグローバルXMLスキーマとして登録することができる。
【０２１３】
グローバルスキーマは全ユーザが見ることができ、オラクルXML DBリポジトリ内の/sys/schemas/PUBLIC/ディレクトリの下に格納されている。
【０２１４】
注：このディレクトリへのアクセスはアクセス制御リスト(ACL)によって制御されており、デフォルトにより、DBAによってのみ書込可能である。グローバルスキーマを登録するには、このディレクトリにおけるWRITE特権が必要である。
【０２１５】
XDBAdmin関数も、このディレクトリへのWRITEアクセスを、それがデフォルトの「保護された」ACLによって保護されていると仮定して提供する。
既存のグローバルスキーマと同じURLを用いてローカルスキーマを登録することができる。ローカルスキーマは常に、同じ名前(URL)を有するどのグローバルスキーマも隠す。
【０２１６】
例５−５ グローバルXMLスキーマ
たとえば、SCOTTによって登録され、URL:www.myco.com/PO.xsdを有するグローバルスキーマは、/sys/schemas/PUBLIC/www.myco.com/PO.xsdにおいてオラクルXML DBリポジトリにマッピングされる。
【０２１７】
XMLスキーマをグローバルとして登録するには、データベースユーザは、このリソースを作成する適切な許可(ACL)を必要とする。
XMLスキーマの登録：オラクルXML DBによる格納およびアクセスインフラストラクチャのセットアップ
XMLスキーマを登録する一環として、オラクルXML DBは、そのXMLスキーマに準拠するXMLインスタンスの格納、アクセスおよび操作を容易にするいくつかの他のステップも実行する。これらのステップは以下の事項を含む。
【０２１８】
・型の作成：あるXMLスキーマが登録される場合、オラクルは、このXMLスキーマに準拠するXML文書の構造化された格納を可能にする適切なSQLオブジェクト型を作成する。XMLスキーマ文書内のオラクルXML DBが定義した属性を使用して、これらのオブジェクト型がいかに生成されるかを制御することができる。
【０２１９】
・デフォルトテーブルの作成：XMLスキーマ登録の一環として、オラクルXML DBは、すべてのルート要素のためのデフォルトXMLTypeテーブルを生成する。テーブル作成中に使用される任意の列およびテーブルレベル制約も特定可能である。
【０２２０】
・Java（登録商標）beanの作成：Java（登録商標）beanは、XMLスキーマ登録中に随意で生成可能である。これらのJava（登録商標）クラスは、アクセサおよびミューテータ方
法を、スキーマ内で宣言された要素および属性に提供する。XMLスキーマが周知である場合、Java（登録商標）beanを用いたアクセスは、XMLを操作するためのより良好な性能を提供する。これは、実行時名前変換を回避するのに役立つ。
DBMS_XMLSCHEMAを使用したXMLスキーマの削除
DBMS_XMLSCHEMA.deleteSchema手順を使用することによって、登録されたXMLスキーマを削除できる。XMLスキーマを削除したい場合、DBMS_XMLSCHEMAは以下の事項をチェックする。
【０２２１】
・現在のユーザが、オラクルXML DBリポジトリ内のXMLスキーマに対応するリソースを削除する適切な特権(ACL)を有すること。XMLスキーマリソースに対して適切なACLを設定することにより、どのユーザがどのXMLスキーマを削除できるかを制御できる。
【０２２２】
・従属子について。従属子があれば、それはエラーを起こし、削除動作は失敗する。これは、XMLスキーマを削除するRESTRICT（制限）モードと呼ばれる。
【０２２３】
FORCE（強制）モード
XMLスキーマの削除中、FORCEモードオプションが提供される。FORCEモードオプションを特定すると、XMLスキーマ削除は、それが従属性チェックに合格しなかった場合でも進行する。このモードでは、XMLスキーマ削除は、その従属子すべてを、妥当でないとしてマークする。
【０２２４】
CASCADE（カスケード）モード
CASCADEモードオプションは、スキーマを登録する事前の呼出しの一環として、すべての生成された型、デフォルトテーブル、およびJava（登録商標）beanをドロップする。
【０２２５】
DBMS_XMLSCHEMAについては、Oracle９i XML API リファレンス-XDKおよびXDBの章も参照されたい。
【０２２６】
例５−６ DBMS_XMLSCHEMAを使用したXMLスキーマの削除
以下の例は、XMLスキーマPO.xsdを削除する。まず、従属テーブルpo_tabがドロップされる。次に、スキーマは、DBMS_XMLSCHEMA.DELETESCHEMAでFORCEおよびCASCADEモードを用いて削除される。
【０２２７】
【数２６】

【０２２８】
登録されたXMLスキーマを使用するための指針
以下のセクションはXMLスキーマをオラクルXML DBに登録するための指針を説明する。
登録されたXMLスキーマに従属するオブジェクト
以下のオブジェクトは、登録されたXMLスキーマに従属する。
【０２２９】
・XMLスキーマ内の何らかの要素に準拠するXMLType列を有するテーブルまたはビュー。
【０２３０】
・このスキーマを定義の一部として含む、またはインポートするXMLスキーマ。
【０２３１】
・たとえばDBMS_XMLGEN演算子内でXMLスキーマ名を参照するカーソル。なお、これらは純粋に一時的なオブジェクトである。
XMLTypeテーブル、ビューまたは列の作成
XMLスキーマの登録後、それを用いてXMLスキーマベースのXMLTypeテーブル、ビュー、および列を、以下を参照することによって作成することができる。
【０２３２】
・登録されたXMLスキーマのXMLスキーマURL
・ルート要素の名前
例５−７ XMLTypeテーブルの登録後作成
たとえば、XMLスキーマベースのXMLTypeテーブルを、以下のように作成することができる。
【０２３３】
【数２７】

【０２３４】
以下のステートメントは、スキーマに準拠するデータを挿入する。
【０２３５】
【数２８】

【０２３６】
XMLスキーマに対するXMLインスタンスの妥当性検証：schemaValidate()
妥当性検証方法のうちの１つを用いることによって、登録されたXMLスキーマに対してXMLTypeインスタンスの妥当性を検証することができる。
【０２３７】
例５−８ schemaValidate()を使用したXMLの妥当性検証
以下のPL/SQLの例は、XMLスキーマPO.xsdに対するXMLインスタンスの妥当性を検証する。
【０２３８】
【数２９】

【０２３９】
（テーブルからフェッチすることにより）xmldocを投入する。
【０２４０】
【数３０】

【０２４１】
XMLスキーマに対して妥当性を検証する。
【０２４２】
【数３１】

【０２４３】
十分に適格なXMLスキーマURL
デフォルトにより、XMLスキーマURL名は常に現在のユーザの範囲内で参照される。言い換えれば、データベースユーザがXMLスキーマURLを特定すると、それらはまず、現在のユーザによって所有されるローカルXMLスキーマの名前として解決される。
【０２４４】
・そのようなXMLスキーマがない場合、それらはグローバルXMLスキーマの名前として解決される。
【０２４５】
・グローバルXMLスキーマがない場合、オラクルXML DBはエラーを起こす。
【０２４６】
ユーザが参照できないXMLスキーマ
これらの規則は、デフォルトにより、ユーザが以下の種類のXMLスキーマを参照できないことを意味する。
【０２４７】
・異なるデータベースユーザによって所有されているXMLスキーマ
・ローカルXMLスキーマと同じ名前を有するグローバルXMLスキーマ
十分に適格なXMLスキーマURLはXMLスキーマURLへの明確な参照を可能にする
これらの場合においてXMLスキーマへの明確な参照を可能にするために、オラクルXML DBは、十分に適格なXMLスキーマURLの概念をサポートしている。この形では、そのようなXMLスキーマURLが以下のようなオラクルXML DB名前空間に属する点を除けば、XMLスキーマを所有するデータベースユーザの名前もXMLスキーマURLの一部として特定される。
【０２４８】
【数３２】

【０２４９】
例５−９ 十分に適格なXMLスキーマURLの使用
たとえば、URL:http://www.example.com/po.xsdを有するグローバルXMLスキーマを考慮されたい。
【０２５０】
データベースユーザのSCOTTが同じURLを有するローカルXMLスキーマを有すると仮定されたい。
【０２５１】
ユーザのジョー（JOE）は、SCOTTが所有する以下のようなローカルXMLスキーマを参照できる。
【０２５２】
http://xmlns.oracle.com/xdb/schemas/SCOTT/www.example.com/po.xsd
同様に、グローバルXMLスキーマについて十分に適格なURLは以下のとおりである。
【０２５３】
http://xmlns.oracle.com/xdb/schemas/PUBLIC/www.example.com/po.xsd
XMLスキーマ登録のトランザクショナルな挙動
XMLスキーマの登録は非トランザクショナルであり、他のSQL DDL演算と同様に、以下のように自動遂行される。
【０２５４】
・登録が成功すると、演算は自動遂行される。
【０２５５】
・登録が失敗すると、データベースは登録開始前の状態にロールバックされる。
【０２５６】
XMLスキーマ登録は潜在的にオブジェクト型およびテーブルの作成を伴うため、エラー回復は、任意のそのような作成された型およびテーブルをドロップすることを伴う。このため、XMLスキーマ登録全体は原子的であることが保証される。つまり、それは成功するか、またはデータベースが登録開始前の状態に回復されるかのどちらかである。
XMLスキーマ登録中のJava（登録商標）bean生成
Java（登録商標）beanはXMLスキーマ登録中に随意で生成可能であり、アクセサおよびミューテータ方法を、XMLスキーマ内で宣言された要素および属性に提供する。データベース内に格納されたXMLデータへの、Java（登録商標）beanを用いたアクセスは、XMLスキーマが周知で、実行時名前変更を回避することによりほぼ固定されている場合に、XMLデータを操作するためのより良好な性能を提供する。
【０２５７】
例５−１０ XMIスキーマ登録中のJava（登録商標）beanクラスの生成
たとえば、XMLスキーマPO.xsdに対応するJava（登録商標）beanクラスは、以下のアクセサおよびミューテータ方法を有する。
【０２５８】
【数３３】

【０２５９】
注：オラクルXML DBにおけるJava（登録商標）beanサポートは、XMLスキーマベースのXML文書に対してのみである。スキーマベースでないXML文書は、オラクルXML DB DOM APIを用いて操作可能である。
DBMS_XMLSCHEMA.generateSchema()を使用した、オブジェクトリレーショナル型からのXMLスキーマの生成
XMLスキーマは、デフォルトマッピングを自動的に使用して、オブジェクトリレーショナル型から生成可能である。DBMS_XMLSCHEMAパッケージ内のgenerateSchema()およびgenerateSchemas()関数は、オブジェクト型名を有する文字列と、オラクルXML DB XMLスキーマを有する別のものとを取入れる。
【０２６０】
・generateSchema()は、あるXMLスキーマを含むXMLTypeを戻す。それは随意で、所与のオブジェクト型により参照された、またはトップレベルの型にのみ制限されたすべての型について、XMLスキーマを生成可能である。
【０２６１】
・generateSchemas()は、異なる名前空間に各々対応する複数のXMLスキーマのXMLSequenceTypeを戻す点を除けば、同様である。それはまた、好ましいXMLスキーマ位置のルートURL：http://xmlns.oracle.com/xdb/schemas/<schema>.xsdを特定する、さらなる随意の引数を取る。
【０２６２】
それらは、XMLスキーマをオラクルXML DBに登録するために使用可能な注釈付XMLスキーマを随意で生成することも可能である。
【０２６３】
例５−１１ XMLスキーマの生成：generateSchema()の使用
たとえば以下のオブジェクト型の場合、
【０２６４】
【数３４】

【０２６５】
この型についてのスキーマは、以下のように生成できる。
【０２６６】
【数３５】

【０２６７】
これは、型EMPLOYEE_Tに対応するスキーマを戻す。このスキーマは、EMPLOYEE_Tという名前のELEMENTと、EMPLOYEE_TTypeと呼ばれるCOMPLEXTYPEとを宣言する。このスキーマは、http://xmlns.oracle.com/xdbからの他の注釈を含む。
【０２６８】
【数３６】

【０２６９】
XMLTypeのXMLスキーマに関連する方法
表５−１は、XMLType APIのXMLスキーマに関連する方法を一覧表示している。
【０２７０】
【表６】

【０２７１】
XMLスキーマの管理および格納
XMLスキーマ文書はそれら自体、オラクルXML DBにXMLTypeインスタンスとして格納される。XMLスキーマに関連するXMLType型およびテーブルは、オラクルXML DB設置スクリプトcatxdbs.sqlの一部として作成される。
ルートXMLスキーマ XDBSchema.xsd
複数のXMLスキーマのためのXMLスキーマは、ルートXMLスキーマ XDBSchema.xsdと呼ばれる。XDBSchema.xsdは、オラクルXML DBによって登録可能な任意の妥当なXMLスキーマ文書を記述する。XDBSschema.xsdには、オラクルXML DBデポジトリを介して、/sys/schemas/PUBLIC/xmlns.oracle.com/xdb/XDBSchema.xsdでアクセス可能である。
XMLスキーマベースのXMLType構造はどのようにして格納されるか？
XMLスキーマベースのXMLType構造は、以下の方法のうちの１つで格納される。
【０２７２】
・下位のオブジェクト型の列内。これはデフォルト格納機構である。
【０２７３】
− XMLスキーマ登録プロセス中、SQLオブジェクト型が随意で作成可能である。
【０２７４】
− XMLからSQLオブジェクト型および属性へのマッピングはXMLスキーマ文書に別途注釈として、つまり、オラクルXML DBによって定義され、http://xmlns.oracle.com/xdbで定義された属性として格納される。
【０２７５】
・単一の下位のLOB列内。ここでは、格納選択は、CREATE TABLEステートメントのSTORE AS句において特定される。
【０２７６】
【数３７】

【０２７７】
格納機構の特定
STORE AS句を使用する代わりに、ある特定のXMLスキーマに基づいたマッピングに従ってテーブルおよび列が格納されるよう特定することができる。そのマッピングに使用されたXMLスキーマのためのURLが特定可能である。
【０２７８】
XMLスキーマベースではないXMLデータは、CLOBを使用してテーブルに格納できる。しかしながら、インデックス付け、クエリー書換えなどの利点は得られない。
DOM忠実度
文書オブジェクトモデル（DOM）忠実度は、元のXML文書と比較された、検索されたXML文書の構造を、DOMトラバーサルのために保持するという概念である。DOM忠実度は、オラクルXML DBに格納されたXML文書の正確性および完全性を確実にするために必要である。
オラクルXML DBはいかにしてDOM忠実度をXMLスキーマで確実にするか
XMLスキーマにおいて宣言されたすべての要素および属性は、対応するSQLオブジェクト型における別個の属性にマッピングされる。しかしながら、XMLインスタンス文書内の情報の断片の中には、これらの要素または属性によって直接表現されないものもある。例を以下に挙げる。
【０２７９】
・コメント
・名前空間宣言
・接頭辞情報
たとえば、データベースに格納されたXML文書を再生成する際に、このデータの完全性および正確性を確実にするため、オラクルXML DBは、DOM忠実度と呼ばれるデータ完全性機構を使用する。
【０２８０】
DOM忠実度は、特にDOMトラバーサルの目的のために、戻されたXML文書が元のXML文書と比較してどれだけ同一かを指す。
DOM忠実度およびSYS_XDBPD$
DOM忠実度が維持されること、および戻されたXML文書が元のXML文書と同一であることをDOMトラバーサルのために保証するために、オラクルXML DBは、システムバイナリ属性SYS_XDBPD$を、作成された各オブジェクト型に追加する。
【０２８１】
この属性は、他の属性のどれにも格納できない情報の断片すべてを格納し、それにより、オラクルXML DBに格納されたすべてのXML文書のDOM忠実度を確実にする。情報のそのような断片の例は、順序情報、コメント、処理命令、名前空間接頭辞などを含む。
【０２８２】
これは位置記述子（PD）列にマッピングされる。
【０２８３】
注：一般に、この情報を設定することはよい考えではない。なぜなら、PD列がなければ、コメント、処理命令などの情報の追加断片がなくなる可能性があるためである。
【０２８４】
SYS_XDBPD$をいかに抑制するか
DOM忠実度が必要でない場合には、属性maintainDOM＝FALSEを設定することにより、XMLスキーマ定義においてSYS_XDBPD$を抑制することができる。
【０２８５】
注：ここでは明瞭にするため、属性SYS_XDBPD$は多くの例において省略されている。しかしながら、この属性は、XMLスキーマ登録プロセスによって生成されるすべてのSQLオブジェクト型に、位置記述子（PD）列として常に存在する。
XMLスキーマに基づいたオラクルXML DBによるXMLTypeテーブルおよび列の作成
オラクルXML DBは、XMLスキーマベースのXMLTypeテーブルおよび列を、以下を参照して作成する。
【０２８６】
・登録されたXMLスキーマのXMLスキーマURL
・ルート要素の名前
図３は、XMLTypeテーブルを作成するためのシンタックスを示す。
【０２８７】
【数３８】

【０２８８】
以下の例に示すXPointer記法のサブセットは、XMLスキーマ位置および要素名を含む単一のURLを提供するためにも使用可能である。
【０２８９】
例５−１２ XMLスキーマベースのXMLTypeテーブルの作成
この例は、XMLスキーマを所与のURLで使用することにより、XMLTypeテーブルpo_tabを作成する。
【０２９０】
【数３９】

【０２９１】
同等な定義は以下のとおりである。
【０２９２】
【数４０】

【０２９３】
SQLオブジェクトリレーショナル型はXMLスキーマベースのXMLTypeテーブルを格納する
XMLスキーマが登録される際、オラクルXML DBは、このXMLスキーマに準拠するXML文書の構造化された格納を可能にする適切なSQLオブジェクト型を作成する。SQLオブジェクト型はすべて、デフォルトにより、現在登録されているXMLスキーマに基づいて作成される。
【０２９４】
例５−１３ XMLTypeテーブルを格納するためのSQLオブジェクト型の作成
たとえば、PO.xsdをオラクルXML DBに登録する場合、以下のSQL型が作成される。なお、型の名前は生成名であり、Itemxxx_t、Itemxxx_COLL、およびPurchaseOrderTypexxx_T（式中、xxxは３桁の整数である）に必ずしも整合しない。
【０２９５】
【数４１】

【０２９６】
注：前述の例におけるオブジェクト型および属性の名前は、システムにより生成可能である。
【０２９７】
・XMLスキーマが、記入されたSQLName、SQLType、またはSQLColType属性を既に含む場合、この名前がオブジェクト属性の名前として使用される。
【０２９８】
・XMLスキーマがSQLName属性を含まない場合、名前は、それが長さまたは矛盾による理由のために使用できない場合でない限り、XML名から得られる。
【０２９９】
SQLSchema属性が使用される場合、オラクルXML DBは、特定されたデータベーススキーマを用いてオブジェクト型を作成しようとする。現在のユーザは、これを実行するのに必要な特権をもっていなければならない。
XMLスキーマ登録前にSQLオブジェクト型名を特定するためのSQLName属性およびSQLType属性の使用
XMLスキーマを登録する前に、生成されたSQLオブジェクトの特定の名前を特定することは、XMLスキーマ定義に属性SQLNameおよびSQLTypeを含める。
【０３００】
・SQLNameおよびSQLTypeの値を特定する場合、オラクルXML DBは、これらの名前を使用してSQLオブジェクト型を作成する。
【０３０１】
・これらの属性を特定しない場合、オラクルXML DBは、システムにより生成された名前を使用する。
【０３０２】
注：これらの属性のいずれについても、値を特定する必要はない。オラクルXML DBは、XMLスキーマ登録プロセス中に適切な値を記入する。しかしながら、後で参照できるように、少なくともトップレベルのSQL型の名前を特定することが推奨される。
【０３０３】
すべての注釈は、属性および要素宣言内で特定可能な属性の形をとっている。これらの属性は、オラクルXML DB名前空間：http://xmlns.oracle.com/xdbに属している。
【０３０４】
表５−２は、要素および属性宣言において特定可能なオラクルXML DB属性を一覧表示する。
【０３０５】
【表７】

【０３０６】
【表８】

【０３０７】
【表９】

【０３０８】
【表１０】

【０３０９】
登録中、SQLマッピングがXMLスキーマにおいて特定される
SQLマッピングに関する情報は、XMLスキーマ文書に格納される。登録プロセスは、SQL型を生成し、XMLスキーマ文書に注釈を追加して、マッピング情報を格納する。注釈は新しい属性の形をとる。
【０３１０】
例５−１４ SQLType属性およびSQLName属性を使用したSQLマッピングの取得
以下のXMLスキーマ定義は、SQLマッピング情報がSQLType属性およびSQLName属性を使用していかに取得されるかを示す。
【０３１１】
【数４２】

【０３１２】
図４は、オラクルXML DBが、XML文書、およびXMLスキーマにおいて特定されたマッピングを用いて、XMLスキーマベースのXMLTypeテーブルをいかに作成するかを示している。XMLTypeテーブルがまず作成され、XMLスキーマにおいて格納がいかに特定されているかに依存してXMl文書がマッピングされ、１つのXMLType列にCLOBとして格納されるか、または、オブジェクトリレーショナル的に、テーブルの数行にわたり広がって格納される。
【０３１３】
XMLTypeテーブルがまず作成され、XMLスキーマにおいて格納がいかに特定されているかに依存してXMl文書がマッピングされ、１つのXMLType列にCLOBとして格納されるか、または、オブジェクトリレーショナル的に、テーブルの数行にわたって広がって格納される。
DBMS_XMLSCHEMAを使用した型のマッピング
DBMS_XMLSCHEMAを使用して、属性および要素についての型情報のマッピングを設定する。
属性マッピング型情報の設定
属性宣言は、以下のうちの１つに関して特定されたその型を有し得る。
【０３１４】
・基本型
・このXMLスキーマ内、または外部のXMLスキーマにおいて宣言されたグローバルsimpleType
・このXMLスキーマ内、または外部のXMLスキーマにおいて宣言された、グローバル属性への参照（ref＝“..”）
・ローカルsimpleType
すべての場合において、SQL型および関連する情報（長さおよび精度）、ならびにメモリマッピング情報は、属性が基づくsimpleTypeに由来する。
【０３１５】
SQL型のオーバーライド
入力されたXMLスキーマ文書においてSQLType値を明確に特定できる。この場合、特定された型は妥当性が検証される。これにより、以下の特定の形のオーバーライドが可能になる。
【０３１６】
・デフォルト型がSTRINGである場合、それをCHAR、VARCHARまたはCLOBのいずれかにオーバーライドすることができる。
【０３１７】
・デフォルト型がRAWである場合、それをRAWまたはBLOBにオーバーライドすることができる。
要素マッピング型情報の設定
要素宣言は、以下のうちの１つに関してその型を特定できる。
【０３１８】
・ある属性宣言用の型を特定するための方法のいずれか
・このXMLスキーマ文書内、または外部のXMLスキーマにおいて特定されたグローバルcomplexType
・このXMLスキーマ文書内、または外部のXMLスキーマにそれ自体があり得る、グローバル要素への参照（ref＝“...”）
・ローカルcomplexType
SQL型のオーバーライド
complexTypeに基づいた要素は、デフォルトにより、サブ要素および属性の各々に対応する属性を含むオブジェクト型にマッピングされる。しかしながら、入力されたXMLスキーマにおけるSQLType属性の値を明確に特定することによって、このマッピングをオーバーライドすることができる。SQLType用の以下の値が、この場合に可能となる。
【０３１９】
・VARCHAR2
・RAW
・CLOB
・BLOB
これらは、テキスト形式または分解されていない形式のXMLをデータベースに格納することを表わす。以下の特殊な場合が取扱われる。
【０３２０】
・要素を宣言するために使用されたcomplexType、およびcomplexType内で宣言された要素を処理する一環としてサイクルが検出された場合、SQLInline属性は「偽」にされ、正しいSQLマッピングがREF XMLTYPEにセットされる。
【０３２１】
・maxOccurs>1の場合、VARRAY型が作成される必要が有り得る。
【０３２２】
−SQLInline＝“true”の場合、前に決定されたSQL型がその要素型であるvarray型が作成される。
【０３２３】
＊VARRAYのカーディナリティは、maxOccurs属性の値に基づいて決定される。
【０３２４】
＊VARRAY型の名前は、SQLCollType属性を使用しているユーザによって明確に特定されるか、要素名を切り刻むことによって得られる。
【０３２５】
−SQLInline＝“false”である場合、SQL型は、XMLTypeへのREFのアレイを表わす予め定義された型であるXDB.XDB$XMLTYPE_REF_LIST_Tに設定される。
【０３２６】
・要素がグローバル要素である場合、またはSQLInline＝“false”である場合、デフォルトテーブルが作成される必要がある。それはテーブル作成コンテキストに追加される。デフォルトテーブルの名前は、ユーザによって特定されているか、または要素名を切り刻むことによって得られる。
XMLスキーマ：SimpleTypeのSQLへのマッピング
このセクションは、XMLスキーマsimpleTypeをSQLオブジェクト型にマッピングするためにXMLスキーマ定義をいかに使用するかについて述べる。
【０３２７】
表５−５〜表５−８は、XMLスキーマ定義において特定されたような、XMLスキーマsimpleTypeのSQLへのデフォルトマッピングを一覧表示している。たとえば、以下のものが挙げられる。
【０３２８】
・XML基本型は、最も近いSQLデータ型にマッピングされる。たとえば、DECIMAL、POSITIVEINTEGERおよびFLOATはすべて、SQL NUMBERにマッピングされる。
【０３２９】
・XML列挙型は、単一のRAW(n)属性を有するオブジェクト型にマッピングされる。nの値は、列挙宣言における可能な値の数によって決定される。
【０３３０】
・XMLリストまたはユニオンデータ型は、SQLにおける文字列(VARCHAR2/CLOB)データ型にマッピングされる。
【０３３１】
【表１１】

【０３３２】
【表１２】

【０３３３】
simpleType：XML文字列のSQL VARCHAR2対CLOBへのマッピング
データ型が4000未満のmaxLength値を有する文字列であるとXMLスキーマが特定する場合、それは特定された長さのVARCHAR2属性にマッピングされる。しかしながら、maxLengthがXMLスキーマにおいて特定されていない場合、それはLOBのみにマッピング可能である。これは、文字列値のほとんどが小さく、それらの一部のみがLOBを必要とするほど十分大きいものである場合に、次善の策である。図５を参照されたい。
【０３３４】
図５−３ オラクルXML DB：XML文字列のSQL VARCHAR2またはCLOBへのマッピング
XMLスキーマ：ComplexTypeのSQLへのマッピング
XMLスキーマを使用して、complexTypeはSQLオブジェクト型に以下のようにマッピングされる。
【０３３５】
・complexType内で宣言されたXML属性は、オブジェクト属性にマッピングされる。XML属性を定義するsimpleTypeは、対応する属性のSQLデータ型を決定する。
【０３３６】
・complexType内で宣言されたXML要素も、オブジェクト属性にマッピングされる。オブジェクト属性のデータ型は、XML要素を定義するsimpleTypeまたはcomplexTypeによって決定される。
【０３３７】
XML要素が属性maxOccurs>1で宣言されている場合、それはSQL内のcollection属性にマッピングされる。maintainOrder属性が偽に設定された場合には、collectionはVARRAY（デフォルト）、または入れ子構造のテーブルとなり得る。さらに、VARRAYのデフォルト格納は、LOBではなくテーブル内順序付集合（OCT）にある。storeAsLob属性を真に設定することによって、LOB格納を選択できる。
【０３３８】
ページ５−７０（原文）の「テーブル内順序付集合（OCT）」も参照されたい。
complexTypeのSQLへのマッピング：ライン外格納のためにSQLInLine属性を偽へ設定
デフォルトにより、サブ要素は、埋込まれたオブジェクト属性にマッピングされる。しかしながら、ライン外格納がより良好な性能を提供する場合があり得る。そのような場合、SQLInLine属性は偽に設定可能であり、オラクルXML DBは、埋込まれたREF属性を有するオブジェクト型を生成する。REFは、ライン外で格納されるXMLフラグメントに対応するXMLTypeの別のインスタンスを指す。デフォルトXMLTypeテーブルも、ライン外フラグメントを格納するために作成される。
【０３３９】
図６は、ライン外格納のためのcomplexTypeのSQLへのマッピングを示す。
【０３４０】
例５−１５ オラクルXML DB XMLスキーマ：complexTypeマッピング−ライン外格納のために、SQLInLine属性を偽へ設定
ライン外格納のために、属性を偽へ
この例では、要素Addrの属性であるxdb:SQLInLineが偽に設定される。結果として生じるオブジェクト型OBJ_T2は、REF属性が埋込まれた型XMLTypeの列を有する。REF属性は、テーブルAddr_tab内のオブジェクト型OBJ_T1で作成された別のXMLTypeインスタンスを指す。Addr_tabはStreetおよびCityという列を有する。後者のXMLTypeインスタンスはライン外で格納される。
【０３４１】
【数４３】

【０３４２】
このXMLスキーマを登録する際、オラクルXML DBは、以下の型およびXMLTypeテーブルを生成する。
【０３４３】
【数４４】

【０３４４】
complexTypeのSQLへのマッピング： XMLフラグメントのラージオブジェクト（LOB）へのマッピング
複合要素についてのSQLTypeを、文字ラージオブジェクト（CLOB）またはバイナリラージオブジェクト（BLOB）として特定することができる。ここでは、XMLフラグメント全体がLOB属性内に格納される。これは、XML文書の一部がほとんどクエリーされず、大抵、単一の断片として検索され、格納される場合に有用である。XMLフラグメントをLOBとして格納することにより、構文解析／分解／再構成オーバーヘッドを節約できる。
【０３４５】
例５−１６ オラクルXML DB XMLスキーマ：XMLフラグメントのLOBへのcompelxTypeマッピング
以下の例では、XMLスキーマは、XMLフラグメントの要素Addrが属性SQLType＝“CLOB”を使用していることを特定する。
【０３４６】
【数４５】

【０３４７】
このXMLスキーマを登録する際、オラクルXML DBは、以下の型およびXMLTypeテーブルを生成する。
【０３４８】
【数４６】

【０３４９】
図７ complexType XMLフラグメントの文字ラージオブジェクト（CLOB）へのマッピング
オラクルXML DB complexTypeの拡張および制限
XMLスキーマでは、complexTypeは、complexContentおよびsimpleContentに基づいて宣言される。
【０３５０】
・simpleContentは、simpleTypeの拡張として宣言される。
【０３５１】
・complexContentは、以下のうちの１つとして宣言される。
【０３５２】
−ベース型
−complexType拡張
−complexType制限
XMLスキーマにおけるcomplexType宣言：継承の取扱い
complexTypeについて、オラクルXML DBは、XMLスキーマにおける継承を以下のように取扱う。
【０３５３】
・他のcomplexTypeを拡張するよう宣言されたcomplexTypeについては、ベース型に対応するSQL型が、現在のSQL型についてのスーパー型として特定される。サブ複合型において宣言された追加の属性および要素だけが、サブオブジェクト型に属性として追加される。
【０３５４】
・他のcomplexTypeを制限するよう宣言されたcomplexTypeについては、サブ複合型用のSQL型が、そのベース型用のSQL型と同じに設定される。これは、SQLが継承機構を介してオブジェクト型の制限をサポートしていないためである。XMLスキーマにおける制限によって、任意の制約が課される。
【０３５５】
例５−１７ XMLスキーマにおける継承：complexTypeの拡張としてのcomplexContent
ベースのcomplexType“Address”と、２つの拡張“USAddress”および“IntlAddress”とを定義するXMLスキーマを考慮されたい。
【０３５６】
【数４７】

【０３５７】
注：型INTLADDR_Tは最終型として生成される。なぜなら、対応するcomplexTypeが“final”属性を特定するためである。デフォルトにより、すべてのcomplexTypeは、他の型によって拡張および制限可能であり、このため、すべてのSQLオブジェクト型は、非最終型として作成される。
【０３５８】
【数４８】

【０３５９】
例５−１８ XMLスキーマにおける継承：complexTypeにおける制限
ベースのcomplexType Addressと、country属性の特定化を禁止する制限型LocalAddressとを定義するXMLスキーマを考慮されたい。
【０３６０】
【数４９】

【０３６１】
SQLにおける継承サポートは制限の概念をサポートしないため、制限されたcomplexTypeに対応するSQL型は、親オブジェクト型の空のサブタイプである。上述のXMLスキーマについて、以下のSQL型が生成される。
【０３６２】
【数５０】

【０３６３】
complexTypeのマッピング：オブジェクト型へのsimpleContent
simpleContent宣言に基づいたcomplexTypeは、XML属性に対応する属性と、ボディ値に対応する別途のSYS_XDBBODY属性とを有するオブジェクト型にマッピングされる。ボディ属性のデータ型は、ボディの型を定義するsimpleTypeに基づく。
【０３６４】
例５−１９ XMLスキーマcomplexType： complexTypeのsimpleContentへのマッピング
【０３６５】
【数５１】

【０３６６】
このXMLスキーマを登録する際、オラクルXML DBは、以下の型およびXMLTypeテーブルを生成する。
【０３６７】
【数５２】

【０３６８】
complexTypeのマッピング：AnyおよびAnyAttribute
オラクルXML DBは、要素宣言であるanyと、属性宣言であるanyAttributeとを、作成されたオブジェクト型内のVARCHAR2属性に（または随意でラージオブジェクト（LOB）に）マッピングする。オブジェクト属性は、any宣言に整合するXMLフラグメントのテキストを格納する。
【０３６９】
・namespace属性は、コンテンツが特定の名前空間に属するよう、コンテンツを制限するために使用可能である。
【０３７０】
・any要素宣言内のprocessContents属性は、any宣言に整合するコンテンツにとって必要な妥当性検証のレベルを示す。
【０３７１】
例５−２０ オラクルXML DB XMLスキーマ：complexTypeのAny/AnyAttributeへのマッピング
このXMLスキーマの例はあるany要素を宣言し、それをオブジェクト型OBJ_T内の列SYS_XDBANY$にマッピングする。この要素は、属性processContentsがany宣言に整合するコンテンツの妥当性を検証することを抜かすことも宣言する。
【０３７２】
【数５３】

【０３７３】
それは以下のステートメントをもたらす。
【０３７４】
【数５４】

【０３７５】
XMLスキーマにおけるcomplexType間の循環の取扱い
オブジェクト型を生成する一方で、XMLスキーマにおけるサイクルは壊される。なぜなら、オブジェクト型は、サイクルが完了する時点でREF属性を導入することによって、サイクルを許可しないためである。このため、データの一部はライン外で格納されるが、検索される際には依然として親XML文書に属している。
【０３７６】
例５−２１ XMLスキーマ：complexType間の循環
XMLスキーマは、complexTypeの定義間の循環を許可する。図５−６はこの例を示しており、ここでは、complexType CT1の定義は別のcomplexType CT2を参照でき、一方、CT2の定義は第１の型CT1を参照する。
【０３７７】
XMLスキーマは、complexTypeの定義間の循環を許可する。これは長さ２のサイクルの例である。
【０３７８】
【数５５】

【０３７９】
SQL型は、型定義においてサイクルを許可しない。しかしながら、SQL型は、弱いサイクル、つまり、REF（参照）属性に関わるサイクルをサポートする。したがって、循環XMLスキーマ定義は、適切な点でSQLInline＝“false”を強制することによっていかなるサイクルも回避されるように、SQLオブジェクト型にマッピングされる。これは弱いサイクルを作成する。
【０３８０】
前述のXMLスキーマについて、以下のSQL型が生成される。
【０３８１】
【数５６】

【０３８２】
図８ 同じXMLスキーマにおける異なるcomplexType間の相互参照
例５−２２ XMLスキーマ：complexType間の循環、自己参照
循環complexTypeの別の例は、それ自体への参照を有するcomplexTypeの宣言を伴う。以下は、それ自体を参照する型＜SectionT＞の例である。
【０３８３】
【数５７】

【０３８４】
以下のSQL型が生成される。
【０３８５】
注：section属性は、XMLTypeインスタンスへのREFのvarrayとして宣言される。埋込まれたsectionは２回以上出現する可能性があるので、属性はVARRAYである。そして、SQLオブジェクトのサイクル形成を避けるために、それはXMLTypeへのREFのVARRAYである。
【０３８６】
【数５８】

【０３８７】
XMLスキーマベースのXMLテーブルを作成するためのさらなる指針
“http://www.oracle.com/PO.xsd”によって識別される自分のXMLスキーマが登録されたと仮定されたい。その場合、XMLTypeテーブルであるmyPOsが、このXMLスキーマの要素であるPurchaseOrderに準拠するインスタンスを格納するよう、以下のようなオブジェクトリレーショナルフォーマットで作成され得る。
【０３８８】
【数５９】

【０３８９】
図９は、complexTypeがそれ自体をいかに参照できるか、または循環させ得るかを概略的に示す。
【０３９０】
図９ XMLスキーマ内のcomplexType自己参照
XMLスキーマベースのXMLテーブルを作成するためのさらなる指針
“http://www.oracle.com/PO.xsd”によって識別される自分のXMLスキーマが登録されたと仮定されたい。その場合、XMLTypeテーブルであるmyPOsが、このXMLスキーマの要素であるPurchaseOrderに準拠するインスタンスを格納するよう、以下のようなオブジェクトリレーショナルフォーマットで作成され得る。
【０３９１】
【数６０】

【０３９２】
隠し列が作成される。これらは、PurchaseOrder要素がマッピングされたオブジェクト型に対応する。加えて、名前空間宣言などのトップレベルのインスタンスデータを格納するために、XMLExtraオブジェクト列が作成される。
【０３９３】
注：XMLDATAは...を可能にするXMLTypeの擬似属性である。
XMLType CREATE TABLEステートメントにおける格納句の特定
格納を特定するため、下位の列は、XMLType格納句において、オブジェクト記法またはXML記法のいずれかを用いて参照され得る。
【０３９４】
・オブジェクト記法：XMLDATA.<attr1>.<attr2>....
例：
【０３９５】
【数６１】

【０３９６】
・XML記法：extractValue（xmltypecol,‘/attr1/attr2’）
例：
【０３９７】
【数６２】

【０３９８】
CREATE INDEXを使用したXMLType列の参照
前述の例に示すように、XMLType列の下位にある列は、CREATE TABLEステートメントにおいてオブジェクト記法またはXML記法のいずれかを使用して参照され得る。同じことがCREATE INDEXステートメントにおいて当てはまる。
【０３９９】
【数６３】

【０４００】
XMLType列に対する制約の特定
制約も、下位にあるXMLType列について、オブジェクト記法またはXML記法のいずれかを用いて特定することができる。
【０４０１】
・オブジェクト記法
【０４０２】
【数６４】

【０４０３】
・XML記法
【０４０４】
【数６５】

【０４０５】
新規インスタンスのXMLType列への挿入
以下のように、新規のインスタンスをXMLType列に挿入することができる。
【０４０６】
【数６６】

【０４０７】
XMLスキーマベースのオブジェクトリレーショナル格納でのクエリー書換
クエリー書換とは何か？
XMLTypeがXMLスキーマを使用して（オブジェクトリレーショナル的に）構造化されたストレージに格納され、XPathを用いたクエリーが使用される場合、クエリーは下位のオブジェクトリレーショナル列に直接行くように書換えられる。これにより、B^*Treeまたは他のインデックスがもし列上に存在すれば、それをオプティマイザによるクエリー評価に用いることが可能になる。このクエリー書換機構は、existsNode()、extract()、extractValue()、およびupdateXML()といったSQL関数におけるXPathのために使用される。これにより、XPathは、メモリにXML文書を構成しなくても、XML文書に対して評価されるようになる。
【０４０８】
例５−２３ クエリー書換
たとえば、
【０４０９】
【数６７】

【０４１０】
といったクエリーは、Company要素の値を得てそれをリテラル‘Oracle’と比較しようとする。MyPOsテーブルが既にXMLスキーマベースのオブジェクトリレーショナル格納で作成されているため、extractValue演算子は、purchaseorderについての会社情報を格納する下位のリレーショナル列に書換えられる。
【０４１１】
こうして、前述のクエリーは以下のように書換えられる。
【０４１２】
【数６８】

【０４１３】
Company列に、
【０４１４】
【数６９】

【０４１５】
といった正規のインデックスが作成されていた場合、前述のクエリーはそのインデックスをその評価に使用するであろう。
クエリー書換はいつ起こるか？
クエリー書換は、以下のSQL関数について起こる。
【０４１６】
・extract()
・existsNode()
・extractValue
・updateXML
書換は、クエリー、DMLまたはDDLステートメント内の任意の式にあるかもしれないこれらのSQL関数について起こる。たとえば、extractValue()を用いて、下位のリレーショナル列上にインデックスを作成することができる。
【０４１７】
例５−２４ SELECTステートメントおよびクエリー書換
この例は、既存の発注書を得る。
【０４１８】
【数７０】

【０４１９】
ここに、下位の列を使用するよう書換えられるステートメントの数例を挙げる。
【０４２０】
例５−２５ DMLステートメントおよびクエリー書換
この例は、会社がオラクルではない発注書をすべて削除する。
【０４２１】
【数７１】

【０４２２】
例５−２６ CREATE INDEXステートメントおよびクエリー書換
この例は、Company列上にインデックスを作成する。これがオブジェクトリレーショナル的に格納されてクエリー書換が起こるため、下位のリレーショナル列上の正規のインデックスが作成される。
【０４２３】
【数７２】

【０４２４】
この場合、SQL関数の書換が単純なリレーショナル列をもたらすならば、インデックスは、関数ベースのインデックスというよりもむしろ、列上のBTreeまたはドメインインデックスになる。
どのXPath式が書換えられるか？
ワイルドカードまたは子孫軸を持たない単純な式に関するXPathが書換えられる。XPathは、要素または属性ノードを選択してもよい。述部がサポートされてSQL述部に書換えられる。
【０４２５】
表５−１０は、このリリースにおいて下位のSQLクエリーに変換可能なXPath式の種類を一覧表示している。
【０４２６】
【表１３】

【０４２７】
サポートされないXPath構成体：以下のXPath構成体は書換えられない。
【０４２８】
・XPath関数
・XPath変数参照
・子軸および属性軸以外のすべての軸
・ワイルドカードおよび子孫式
・UNION演算
サポートされないXMLスキーマ構成体：以下のXMLスキーマ構成体はサポートされない。これは、XPath式が以下のXMLスキーマ構成体を有するノードを含む場合には、式全体が書換えられないことを意味する。
【０４２９】
・オープンなコンテント、つまりanyコンテントを含む要素の子にアクセスするXPath式。ノードがanyコンテントを含む場合、anyがXPathにおいて特定された名前空間以外の名前空間をターゲットとする場合を除き、式は書換えできない。any属性は同様に取扱われる。
【０４３０】
・CLOB格納。XMLスキーマが要素定義の一部をSQL CLOBにマッピングする場合には、そのような要素をトラバースするXPath式はサポートされない。
【０４３１】
・列挙型。
【０４３２】
・代替可能要素。
【０４３３】
スカラ型の非デフォルトマッピング。たとえば、ネイティブの整数などのネイティブストレージにマッピングされた数字型。
【０４３４】
・子が宣言されたcomplexTypeの一構成要素ではない場合における、継承されたcomplexTypeについての子のアクセス。
【０４３５】
たとえば、street要素を有するaddress complexTypeを有する場合を考慮されたい。shipmentNumber要素を含むshipAddrと呼ばれる派生型を有することができる。PurchaseOrderが型アドレスのアドレス要素を持っていた場合には、“/PurchaseOrder/address/street”といったXPathは書換えられ、一方、“/PurchaseOrder/address/shipmentNumber”は書換えられない。
【０４３６】
・数字とともに追加されたブールなどの非強制的データ型演算。
XPathはいかに書換えられるか？
以下のセクションは、この章で前に説明した同じpurchaseorderスキーマを用いて、関数がいかに書換えられるかを説明する。
【０４３７】
例５−２７ オブジェクト型生成中のXPathの書換
以下のpurchaseorderスキーマを考慮されたい。
【０４３８】
【数７３】

【０４３９】
このスキーマに準拠するテーブルが作成される。
【０４４０】
【数７４】

【０４４１】
挿入されるXML文書は、挿入される前に、スキーマに対して部分的に妥当性が検証される。
【０４４２】
【数７５】

【０４４３】
XMLスキーマは順序付けを維持することについて何も特定しなかったため、デフォルトは、順序付けおよびDOM忠実度を維持することである。こうして、型は、ノードの順序付けを維持し、コメント、処理命令などの追加アイテムを取得するために必要な追加情報を格納するために、SYS_XDBPD$を有する。
【０４４４】
SYS_XDBPD$属性はまた、要素の存在に関する情報（つまり、入力文書内に要素があったかどうか）を維持する。これはスカラコンテントを有する要素にとって必要である。なぜなら、それらは単純なリレーショナル列にマッピングするためである。この場合、空の、および欠落しているスカラ要素の双方が列内のNULL値にマッピングし、SYS_XDBPD$属性のみが２つの場合を区別するのに役立ち得る。クエリー書換機構は、SYS_XDBPD$属性の存在または不在を考慮に入れて、クエリーを適切に書換える。
【０４４５】
このXMLスキーマが、スキーマURL：http://www.oracle.com/PO.xsdに登録されていると仮定されたい。そのスキーマを有するpo_tabテーブルを作成することができる。
【０４４６】
【数７６】

【０４４７】
ここで、このテーブルは、実際のデータを格納する型“PurchaseOrder_T”である隠しXMLData列を有する。
XPath式の書換：マッピングのタイプおよび論点
XPath式のマッピングのタイプおよび論点を、以下のセクションで説明する。
【０４４８】
・「単純なXPathのためのマッピング」
・「スカラノードのためのマッピング」
・「述部のマッピング」
・「集合述部のマッピング」
・「集合トラバーサルでの文書順序付け」
・「集合インデックス」
・「満たすことができないXPath式」
・「名前空間の取扱い」
・「日付フォーマットの変換」
単純なXPathのためのマッピング：単純なXPathのための書換は、XPath式に対応する属性にアクセスすることに関わる。表５−１１は、XPathマッピングを一覧表示している。
【０４４９】
【表１４】

【０４５０】
スカラノードのためのマッピング：XPath式は、XML文書内のスカラコンテントにマッピングするtext()演算子を含み得る。書換え時、これは下位のリレーショナル列に直接マッピングする。
【０４５１】
たとえば、XPath式“/PurchaseOrder/PONum/text()”は、SQL列 XMLData.“PONum”に直接マッピングする。
【０４５２】
PONum列内のNULL値は、入力文書にテキストノードがなかったため、または要素自体が欠落していたために、テキスト値が利用できないことを意味している。これはスカラ要素にアクセスするよりも効率が良い。なぜなら、SYS_XDBPD$属性内の要素の存在についてチェックする必要がないからである。
【０４５３】
たとえば、XPath“/PurchaseOrder/PONum”は、SQL属性 XMLData.“PONum”にもマッピングする。
【０４５４】
しかしながら、この場合、クエリー書換は、XMLData列内のSYS_XDBPD$を用いて、要素自体の存在についてもチェックしなければならない。
【０４５５】
述部のマッピング：述部は、SQL述部式にマッピングされる。
【０４５６】
例５−２８ 述部のマッピング
たとえば、XPath式：
【０４５７】
【数７７】

【０４５８】
における述部は、SQL述部：
【０４５９】
【数７８】

【０４６０】
にマッピングする。
【０４６１】
たとえば、以下のクエリーは、オブジェクトリレーショナルな同等物に書換えられ、XPathの関数的評価を必要としない。
【０４６２】
【数７９】

【０４６３】
集合述部のマッピング：XPath式は、集合式を有するリレーショナル演算子に関与してもよい。Xpath１．0では、集合に関与する条件は、実在チェックである。言い換えれば、集合の一構成要素が条件を満たす場合でさえ、式は真である。
【０４６４】
例５−２９ 集合述部のマッピング
たとえばXpath：
【０４６５】
【数８０】

【０４６６】
における集合述部は、SQL集合式：
【０４６７】
【数８１】

【０４６８】
にマッピングする。
【０４６９】
たとえば、以下のクエリーは、オブジェクトリレーショナルな同等物に書換えられる。
【０４７０】
【数８２】

【０４７１】
<condition>集合という集合を有する場合、より複雑な書換が起こる。この場合、これら２つの集合引数からのノードの少なくとも１つの組合せが条件を満たすならば、述部は満たされていると考えられる。
【０４７２】
例５−３０ existsNode()を使用した集合述部のマッピング
たとえば、アイテムの価格が何らかの部品番号と同じであるようなItemをPurchaseorderが有するかどうかをチェックする架空のXPath：
【０４７３】
【数８３】

【０４７４】
が、SQL集合式：
【０４７５】
【数８４】

【０４７６】
にマッピングすると考慮されたい。
【０４７７】
たとえば、以下のクエリーは、オブジェクトリレーショナルな同等物に書換えられる。
【０４７８】
【数８５】

【０４７９】
集合トラバーサルでの文書順序付け：書換のほとんどは元の文書順序付けを保存している。しかしながら、SQLシステムはサブクエリーの結果における順序付けを保証していないので、extract()関数を用いて集合から要素を選択する場合、結果のノードは文書順にならないかもしれない。
【０４８０】
例５−３１ 集合トラバーサルでの文書順序付け
たとえば、
【０４８１】
【数８６】

【０４８２】
は、以下に示すようにサブクエリーを使用するよう書換えられる。
【０４８３】
【数８７】

【０４８４】
大抵の場合、集約の結果は集合要素と同じ順序になるであろうが、これは保証されておらず、このため、結果は文書順にならないかもしれない。これは、将来のリリースで調整されるであろう限界である。
【０４８５】
集合インデックス：XPath式は、集合のある特定のインデックスにアクセスすることもできる。たとえば、“/PurchaseOrder/Item[1]/Part”は、集合の最初のItemを抽出し、次にその中のPart属性にアクセスするよう書換えられる。
【０４８６】
集合がVARRAYとして既に格納されていた場合、この演算は、元の文書内にあるのと同じ順序でノードを検索する。集合のマッピングが入れ子構造のテーブルへなされている場合には、順序は決まっていない。VARRAYが順序付け集合テーブル（OCT）（storeVarrayAsTable＝“true”が設定されている場合に、スキーマコンパイラによって作成されたテーブルについてのデフォルト）として格納されている場合、この集合インデックスアクセスは、VARRAY上に存在するIOTインデックスを使用するために最適化される。
【０４８７】
満たすことができないXPath式：XPath式は、入力文書内に存在できないノードへの参照を含む場合がある。式のそのような部分は、書換中、SQL NULLにマッピングする。たとえば、XPath式“/PurchaseOrder/ShipAddress”は、PO.xsd XMLスキーマに準拠するどのインスタンス文書によっても満たすことができない。なぜなら、XMLスキーマがPurchaseOrderの下でShipAddress要素を許可しないためである。このため、この式は、SQL NULLリテラルにマッピングする。
【０４８８】
名前空間の取扱い：名前空間は、関数ベースの評価と同様に取扱われる。スキーマベースの文書については、関数（EXISTSNODE/EXTRACTなど）がどの名前空間パラメータも特定しない場合、スキーマのターゲット名前空間が、XPath式についてのデフォルト名前空間として使用される。
【０４８９】
例５−３２ 名前空間の取扱い
たとえば、SQL関数が名前空間接頭辞およびマッピングを明確に特定していない場合、XPath式 /PurchaseOrder/PONumは、xmlns:a=“http://www.oracle.com/PO.xsd”を有する/a:PurchaseOrder/a:PONumとして扱われる。言い換えれば、
【０４９０】
【数８８】

【０４９１】
は、以下のクエリーと同等である。
【０４９２】
【数８９】

【０４９３】
クエリー書換を実行する際、ある特定の要素についての名前空間は、XMLスキーマ定義のそれと整合される。XMLスキーマがelementFormDefault＝“qualified”を含む場合、XPath式内の各ノードは、名前空間をターゲットとしなければならない（これは、デフォルト名前空間特定化を使用して、または、各ノードに名前空間接頭辞をつけることによってなされ得る）。
【０４９４】
elementFormDefaultが不適格である場合（これがデフォルトである）、名前空間を定義するノードのみが接頭辞を含むべきである。たとえば、PO.xsdが不適格とされるべき要素形を有する場合、existsNode()関数は以下のように書換えられるべきである。
【０４９５】
【数９０】

【０４９６】
注：elementFormDefaultが不適格である場合、前述の例でSQL関数existsNode()の名前空間パラメータを省略することは、各ノードをターゲット名前空間にデフォルト設定することになるであろう。これはXMLスキーマ定義と整合せず、したがって、結果を全く戻さないであろう。関数が書換えられようとなかろうと、これは真である。
【０４９７】
日付フォーマットの変換：デフォルト日付フォーマットは、XMLスキーマとSQLとでは異なる。したがって、日付の比較に関するXPath式を書換える場合には、XMLフォーマットを使用する必要がある。
【０４９８】
例５−３３ 日付フォーマットの変換
たとえば、式：［@PurchaseDate＝“2002-02-01”］を、XMLData.“PurchaseDate”＝“2002-02-01”として単純に書換えることはできない。なぜなら、SQL用のデフォルト日付フォーマットは、YYYY-MM-DDではないからである。このため、書換え中、テキスト値を日付データ型に正しく変換するために、XMLフォーマット文字列が追加される。
【０４９９】
このため、前述の述部は以下のように書換えられる。
【０５００】
【数９１】

【０５０１】
同様に、これらの列を（extract()などに必要な）テキスト値に変換する場合には、それらをXMLと同じ日付フォーマットに変換するために、XMLフォーマット文字列が追加される。
existsNode()のためのXPath式書換
existsNode()は、XPathが任意のノード（text()または要素ノード）を戻すかどうかを示す数値０または１を戻す。前述のセクションにおいて述べたマッピングに基づいて、existsNodeは単に、XPathがtext()ノードまたはnon-scalarノードをターゲットとする場合にはスカラ要素がヌルでないかどうかをチェックし、その他の場合には要素の存在をSYS_XDBPD$を用いてチェックする。SYS_XDBPD$属性が存在しない場合、scalarノードの存在は、そのスカラ列についてのヌル情報によって判断される。
【０５０２】
文書の順序を維持した状態でのexistsNodeマッピング：表５−１２は、文書順序付けが保存されている場合、つまり、SYS_XDBPD$が存在し、スキーマ文書においてmaintainDOM＝“true”である場合の、existsNode()の場合のさまざまなXPathのマッピングを示す。
【０５０３】
【表１５】

【０５０４】
例５−３４ 文書の順序を維持した状態でのexistsNodeマッピング
前述のマッピングを用いると、number2100を有するpurchaseorderが2000よりも大きいpriceを有するpartを含むかどうかをチェックするクエリー：
【０５０５】
【数９２】

【０５０６】
は、以下のようになる。
【０５０７】
【数９３】

【０５０８】
CASE式は、一定のリレーショナルな同等式のためにさらに最適化され、このクエリーは以下のようになる。
【０５０９】
【数９４】

【０５１０】
これはその評価にリレーショナルインデックスを、もしPartおよびPONum列にあれば使用するであろう。
【０５１１】
文書の順序を維持しないexistsNodeマッピング：SYS_XDBPD$が存在しない場合（つまり、XMLスキーマがmaintainDOM＝“false”を特定する場合）、NULLスカラ列は、存在しないスカラ要素にマッピングする。このため、SYS_XDBPD$属性を用いてノードの存在をチェックする必要はない。表５−１３は、SYS_XDBPD$属性がない状態でのexistsNode()のマッピングを示す。
【０５１２】
【表１６】

【０５１３】
extractValue()のための書換
extractValue()は、スカラコンテントを得るために、extract()を用い、次にgetStringVal()またはgetNumberVal()を用いて、textノードおよび属性を抽出するためのショートカットである。extractValueは、スカラ要素のためのtextノード、またはattributeノードの値を戻す。extractValue()は、多数の値または非スカラ要素を戻すことは取扱不可である。
【０５１４】
表５−１４は、extractValue()の場合のさまざまなXPath式のマッピングを示す。あるXPath式がある要素をターゲットとする場合、extractValueは、その要素のtextノード子を検索する。こうして、/PurchaseOrder/PONumと/PurchaseOrder/PONum/text()という２つのXPath式が、extractValueによって同一に取扱われ、それら双方は、PONumのスカラコン
テントを検索する。
【０５１５】
【表１７】

【０５１６】
例５−３５ extractValue()の書換
たとえば、
【０５１７】
【数９５】

【０５１８】
のようなSQLクエリーは、以下のようになる。
【０５１９】
【数９６】

【０５２０】
それは単純なスカラ列に書換えられるので、PONum属性上のインデックスは、もしあれば、クエリーを満たすために使用されてもよい。
【０５２１】
インデックスの作成：ExtractValueをインデックス式に使用することができる。式がスカラ列に書換えられた場合には、インデックスは、関数ベースのインデックスの代わりにBTreeインデックスとなる。
【０５２２】
例５−３６ インデックスの作成
たとえば、
【０５２３】
【数９７】

【０５２４】
は、以下のように書換えられ、
【０５２５】
【数９８】

【０５２６】
こうして正規のBTreeインデックスになる。これは有用である。なぜなら、関数インデックスとは異なり、同じインデックスが以下のような列をターゲットとするクエリーを満たすことができるためである。
【０５２７】
【数９９】

【０５２８】
こうして正規のB^*Treeインデックスになる。これは有用である。なぜなら、関数インデックスとは異なり、同じインデックスが以下のような列をターゲットとするクエリーを満たすことができるためである。
【０５２９】
【数１００】

【０５３０】
extract()のための書換
extract()は、XPathの結果をXMLとして検索する。textノードに関するXpath式については、extract()のための書換は、extractValue()のそれと同様である。
【０５３１】
文書の順序を維持した状態でのExtractマッピング：表５−１５は、文書の順序が保存されている場合の（つまり、SYS_XDBPD$が存在し、スキーマ文書においてmaintainDOM＝“true”である場合の）extract()の場合のさまざまなXPathのマッピングを示す。
【０５３２】
注：text値のみを有するXMLインスタンスを作成することを示すために、例は、空のエイリアス文字列“”を有するXMLElementおよびXMLForestを示している。これは例示のためにのみ示されている。
【０５３３】
【表１８】

【０５３４】
例５−３７ 文書順序付けが保存された状態でのextract()のためのXPathマッピング
表５−１５におけるマッピングを用いると、2000よりも大きいpriceを有するpartをpurchaseorderが含む場合のPONum要素を抽出するクエリー：
【０５３５】
【数１０１】

【０５３６】
は、以下のようになる。
【０５３７】
【数１０２】

【０５３８】
Check_Node_Existsは、単なる例示目的の内部関数である。
【０５３９】
文書の順序を維持しないExtractマッピング：SYS_XDBPD$が存在しない場合、つまり、XMLスキーマがmaintainDOM＝“false”を特定する場合、NULLスカラ列は、存在しないスカラ要素にマッピングする。このため、SYS_XDBPD$属性を用いてノードの存在をチェックする必要はない。表５−１６は、SYS_XDBPD$属性がない状態でのexistsNode()のマッピングを示す。
【０５４０】
【表１９】

【０５４１】
updateXML()を使用した更新の最適化
updateXML()を使用した定期的な更新は、XML文書の値を更新し、次に文書全体を新しく更新された文書と置換えることを伴う。
【０５４２】
XMLTypeがXMLスキーママッピングを使用してオブジェクトリレーショナル的に格納されている場合、更新は、文書の断片を直接更新するよう最適化される。たとえば、PONum要素値の更新は、メモリ内の文書全体を具体化して次に更新を実行する代わりに、XMLData.PONum列を直接更新するよう書換えられ得る。
【０５４３】
updateXML()は、最適化を用いるために、それについての以下の条件を満たさなければならない。
【０５４４】
・updateXML()に供給されたXMLType列は、SET句において更新中の同じ列でなければならない。例を以下に挙げる。
【０５４５】
【数１０３】

【０５４６】
・XMLType列は、オラクルXML DBのXMLスキーママッピングを使用してオブジェクトリレーショナル的に格納されていなければならない。
【０５４７】
・XPath式は、述部または集合トラバーサルを伴ってはならない。
【０５４８】
・複製のスカラ式はあってはならない。
【０５４９】
・updateXML()関数におけるすべてのXPath引数は、スカラコンテント、つまりテキストノードまたは属性しかターゲットとしてはならない。例を以下に挙げる。
【０５５０】
【数１０４】

【０５５１】
前述の条件がすべて満たされれば、updateXMLは、単純なリレーショナルな更新に書換えられる。たとえば、
【０５５２】
【数１０５】

【０５５３】
は以下のようになる。
【０５５４】
【数１０６】

【０５５５】
DATE変換：Date、gMonth、gDateなどの日付データ型は、XMLスキーマとSQLシステムとでは異なるフォーマットを有する。そのような場合、updateXMLがこれらの列についての文字列値を有するならば、書換は自動的にXMLフォーマット文字列を、文字列値を正しく変換する状態にする。このため、日付列について特定された文字列値は、XML日付フォーマットに整合しなければならず、SQL日付フォーマットに整合してはならない。
XMLスキーマ登録中のデフォルトテーブルの作成
XMLスキーマ登録の一環として、デフォルトテーブルも作成できる。デフォルトテーブルは、このXMLスキーマに準拠するXMLインスタンス文書がFTPまたはHTTPなどテーブル仕様を持たないAPIを介して挿入される場合に、最も有用である。そのような場合、XMLインスタンスはデフォルトテーブルに挿入される。
【０５５６】
属性defaultTableについての値を与えた場合、XMLTypeテーブルはその名前で作成される。その他の場合、それは内部で生成された名前で作成される。
【０５５７】
さらに、tablePropsおよびcolumnProps属性を使用して特定された任意のテキストが、生成されたCREATE TABLEステートメントに添付される。
テーブル内順序付き集合（OCT）
XMLスキーマ内のアレイ（maxOccurs＞１を有する要素）は通常、VARRAYに格納され、それは、ラージオブジェクト（LOB）内か、または入れ子構造のテーブルに類似した別個の格納テーブル内のいずれかに格納可能である。
【０５５８】
注：VARRAYの要素が別個のテーブルに格納されている場合、VARRAYはテーブル内順序付き集合（OCT）と呼ばれる。以下の段落では、OCTへの参照は、「格納」テーブルのためにインデックス編成型テーブル（IOT）格納が使用されていることも仮定している。
【０５５９】
これにより、VARRAYの要素は、IOTに基づいた別個のテーブルに存在できるようになる。テーブルのプライマリキーは（NESTED_TABLE_ID，ARRAY_INDEX）である。NESTED_TABLE_IDは、要素をそれらを含む親とリンクさせるために使用され、一方、ARRAY_INDEX列は、集合内の要素の位置を追跡する。
VARRAY格納のためのOCTの使用
OCT格納を特定するには２つの方法がある。
【０５６０】
・スキーマ属性“storeVarrayAsTable”による方法。デフォルトにより、これは“false”であり、VARRAYはLOB内に格納される。これが“true”にセットされている場合、maxOccurs＞１を有するすべてのVARRAY、すべての要素はOCTとして格納される。
【０５６１】
・“tableProps”属性を使用して格納を明確に特定することによる方法。OCTを作成するために必要とされる、まさしくそのSQLを、tableProps属性の一部として使用することができる。
【０５６２】
【数１０７】

【０５６３】
VARRAY格納のためにOCTを使用する利点は、要素へのより速いアクセス、および、より良好なクエリー可能性を含む。要素の属性上にインデックスを作成することができ、これらはクエリー書換のためのより良好な実行を支援することができる。
XMLスキーマ間での循環参照
XMLスキーマ文書は、それらが通常の態様で次々と登録されることを防止できる循環従属性を有し得る。そのようなXMLスキーマの例を以下に示す。
【０５６４】
例５−３８ 循環従属性
別のスキーマを含むスキーマは、含まれたスキーマが存在しない場合には作成できない。
【０５６５】
【数１０８】

【０５６６】
しかしながら、それはFORCEオプションで作成可能である。
【０５６７】
【数１０９】

【０５６８】
このスキーマを使用しようとする試みは、再コンパイルしようとして失敗する。
【０５６９】
【数１１０】

【０５７０】
ここで、２番目のスキーマをFORCEオプションで作成する。これは、１番目のスキーマもVALIDにしなければならない。
【０５７１】
【数１１１】

【０５７２】
双方を使用してテーブルなどが作成可能である。
【０５７３】
【数１１２】

【０５７４】
互いに対して循環従属性を有するこれらのXMLスキーマの双方を登録するには、DBMS_XMLSCHEMA.registerSchemaにおいてFORCEパラメータを以下のように使用しなければならない。
【０５７５】
１．ステップ１：“s1.xsd”をFORCEモードに登録する。
【０５７６】
【数１１３】

【０５７７】
このとき、s1.xsdは妥当でなく、使用できない。
【０５７８】
２．ステップ２：“s2.xsd”をFORCEモードに登録する。
【０５７９】
【数１１４】

【０５８０】
２番目の演算はs1.xsdを自動的にコンパイルし、双方のXMLスキーマを妥当にする。
【図面の簡単な説明】
【０５８１】
【図１】この発明の一実施例に従った、XMLスキーマに含まれる構成体をオブジェクト−リレーショナルな構成体にマッピングするための機構を含むデータベースシステムのブロック図である。
【図２】この発明の実施例が実現され得るコンピュータシステムを示すブロック図である。
【図３】この発明の一実施例に従った、XML型テーブルを作成するためのシンタックスを示すブロック図である。
【図４】この発明の一実施例に従った、特定のXMLスキーマに準拠する文書に対する適切なデータベース表現に対してデータベースオブジェクトを作成するように構成されたデータベースシステムを示すブロック図である。
【図５】データベースがサポートする２つの代替的なデータ型にXML文字列が選択的にマッピングされることを示すブロック図である。
【図６】complexTypeがライン外格納のためにSQLにマッピングされていることを示す図である。
【図７】文字ラージオブジェクト（CLOB）にマッピングされたcomplexTypeのXMLフラグメントを示す図である。
【図８】同一のXMLスキーマにおけるcomplexType間の相互参照を示す図である。
【図９】XMLスキーマ内のcomplexTypeの自己参照を示すブロック図である。
【図１０】XMLスキーマ間における循環参照を示すブロック図である。

Claims (47)

1. データベースシステムでデータを管理するための方法であって、
   データベースシステム内で、XMLスキーマに準拠する文書を前記データベースシステム内に格納するための適切なデータベース表現を決定するステップと、
   前記XMLスキーマの要素と前記適切なデータベース表現の要素との間の相関関係を示すマッピングデータを生成するステップとを含む、方法。
2. 適切なデータベース表現を決定する前記ステップは、
   ユーザが特定した情報に基づき、前記XMLスキーマの要素が、前記要素に対して前記データベースシステム内で他のオブジェクト型を生成することなく１つのCLOBにマッピングされるべきであることを決定するステップを含み、
   マッピングデータを生成する前記ステップは、前記要素を前記１つのCLOBにマッピングするデータを生成するステップを含む、請求項１に記載の方法。
3. 前記XMLスキーマに対してユーザが特定した注釈の形で、前記ユーザが特定した情報を受信するステップをさらに含む、請求項２に記載の方法。
4. 適切なデータベース表現を決定する前記ステップは、ユーザが特定した情報に基づき、前記XMLスキーマの要素の第１の組のサブ要素が１つのCLOBにマッピングされるべきであることを決定するステップを含み、
   マッピングデータを生成する前記ステップは、前記１つのCLOBに前記第１の組のサブ要素をマッピングするデータを生成するステップと、前記CLOB以外の１つ以上のオブジェクトに前記要素の第２の組のサブ要素をマッピングするデータを生成するステップとを含む、請求項１に記載の方法。
5. 適切なデータベース表現を決定する前記ステップは、前記データベースシステムがサポートするデータ型に、前記XMLスキーマの要素に関連するデータ型をマッピングするステップを含む、請求項１に記載の方法。
6. 適切なデータベース表現を決定する前記ステップは、前記XMLスキーマの要素に対応する属性を含むSQLオブジェクト型を定義するステップを含む、請求項１に記載の方法。
7. データ型をマッピングする前記ステップは、
   前記XMLスキーマの要素に関連する特定のデータ型が第１の長さに関連する場合、第１のデータベースデータ型に前記特定のデータ型をマッピングするステップと、
   前記特定のデータ型が第２の長さに関連する場合、第２のデータベースデータ型に前記特定のデータ型をマッピングするステップとを含み、前記第１のデータベースデータ型は前記第２のデータベースデータ型と異なる、請求項５に記載の方法。
8. 適切なデータベース表現を決定する前記ステップは、特定の要素が１より大きな最大出現回数を有するように定義されている場合、前記データベースシステムがサポートする集合型に前記XMLスキーマの特定の要素をマッピングするステップを含む、請求項５に記載の方法。
9. 前記集合型はアレイ型であり、前記アレイ型のカーディナリティは、前記特定のデータベース要素に対して特定された前記最大出現回数に基づいて選択される、請求項８に記載の方法。
10. 適切なデータベース表現を決定する制約の前記ステップは、前記XMLスキーマにおいて
    前記XMLスキーマの要素に対して特定された制約に基づき、前記適切なデータベース表現において制約を定義するステップを含む、請求項１に記載の方法。
11. 制約を定義する前記ステップは、一意性の制約、参照の制約、およびnot nullの制約からなる組からの制約を定義するステップを含む、請求項１０に記載の方法。
12. 第１のデータ型は前記XMLスキーマの要素に関連し、
    前記XMLスキーマは前記第１のデータ型が第２のデータ型から継承することを特定し、
    適切なデータベース表現を決定する前記ステップは、前記データベースシステム内でオブジェクト型の部分型を定義するステップを含み、前記オブジェクト型は前記第２のデータ型に対応する、請求項１に記載の方法。
13. 適切なデータベース表現を決定する前記ステップは、
    第１の組で別個の各要素を前記第１の組の他の要素とは別個に維持するデータベース構造に、前記XMLスキーマの第１の組の要素をマッピングするステップと、
    第２の組の要素の全要素が１つの区別されないデータベース要素として組合わされるデータベース構造に、前記XMLスキーマの第２の組の要素をマッピングするステップとを含む、請求項１に記載の方法。
14. 前記データベースシステムは、前記XMLスキーマに関連する指示文に基づいて前記第１の組の帰属関係および前記第２の組の帰属関係を決定する、請求項１３に記載の方法。
15. 前記第１の組の要素における要素は、前記第２の組の要素に存在するように選択された要素よりも前記要素が頻繁にアクセスされるであろうという可能性に基づき、前記第１の組に存在するように選択される、請求項１３に記載の方法。
16. 適切なデータベース表現を決定する前記ステップおよびマッピングデータを生成する前記ステップは、前記データベースシステム内で変更を生じるXMLスキーマ登録動作の一部として行なわれ、
    前記方法は、前記XMLスキーマ登録動作によって生じたすべての変更を、前記XMLスキーマ登録動作中に特定のエラーに遭遇することに応答して自動的に除去するステップをさらに含む、請求項１に記載の方法。
17. 適切なデータベース表現を決定する前記ステップは、前記XMLスキーマのサイクルをどのように破壊するかを決定するステップを含む、請求項１に記載の方法。
18. 前記XMLスキーマは、複数の構成要素を伴うサイクルを含み、サイクルをどのように破壊するかを決定する前記ステップは、サイクル状の定義の各構成要素に対し、その子構成要素のすべてに対するポインタを保持させるステップを含む、請求項１に記載の方法。
19. サイクルをどのように破壊するかを決定する前記ステップは、サイクル状の定義の全体が前記データベースシステム内の１つのCLOBとして格納されるためにマッピングされるようにするステップを含む、請求項１に記載の方法。
20. マッピングデータを生成する前記ステップは、前記XMLスキーマに注釈を加えるステップと、前記データベースシステム内に前記注釈の付いたXMLスキーマを格納するステップとを含む、請求項１に記載の方法。
21. 前記適切なデータベース表現に基づいてデータベース内に構造を作成するステップと、
    前記構造に、前記XMLスキーマに準拠するXML文書からのデータを格納するステップとをさらに含む、請求項１に記載の方法。
22. XML文書からのデータを格納する前記ステップは、
    前記データベースシステムにおいてXML文書を受信するステップと、
    前記XML文書から、前記XMLスキーマの個々の要素に関連するデータを識別するステップと、
    前記データに関連する要素および前記マッピングデータに基づき、前記構造内の位置に、個々の要素に関連する前記データを格納するステップとを含む、請求項２１に記載の方法。
23. 前記XMLスキーマがXMLスキーマに対する１つのXMLスキーマに準拠しているかどうかを決定するために、前記データベースシステム内で前記XMLスキーマを妥当性検証するステップをさらに含む、請求項１に記載の方法。
24. 決定する前記ステップは、前記データベースサーバで前記XMLスキーマを受信することに応答して開始されるXMLスキーマ登録動作の一部として行なわれる、請求項１に記載の方法。
25. 決定する前記ステップは、前記XMLスキーマに準拠するXML文書を前記データベースサーバで受信することに応答して開始されるXMLスキーマ登録動作の一部として行なわれる、請求項１に記載の方法。
26. 前記XMLスキーマは、前記データベースシステムが前記XMLスキーマの少なくとも１つの要素をどのようにマッピングすべきであるかを示す、ユーザが特定した注釈を含み、
    前記マッピングデータの少なくとも一部は、前記ユーザが特定した注釈を反映する、請求項２４に記載の方法。
27. データベースシステムでデータを管理するための命令を運ぶコンピュータ読取可能な媒体であって、前記命令は、１つ以上のプロセッサによって実行されると、
    データベースシステム内で、XMLスキーマに準拠する文書を前記データベースシステム内に格納するための適切なデータベース表現を決定するステップと、
    前記XMLスキーマの要素と前記適切なデータベース表現の要素との間の相関関係を示すマッピングデータを生成するステップとをプロセッサに行なわせる命令を含む、コンピュータ読取可能な媒体。
28. 適切なデータベース表現を決定する前記ステップは、前記データベースシステムがサポートするデータ型に前記XMLスキーマの要素に関連するデータ型をマッピングするステップを含む、請求項２７に記載のコンピュータ読取可能な媒体。
29. 適切なデータベース表現を決定する前記ステップは、前記XMLスキーマの要素に対応する属性を含むSQLオブジェクト型を定義するステップを含む、請求項２７に記載のコンピュータ読取可能な媒体。
30. データ型をマッピングする前記ステップは、
    前記XMLスキーマの要素に関連する特定のデータ型が第１の長さに関連する場合、第１のデータベースデータ型に前記特定のデータ型をマッピングするステップと、
    前記特定のデータ型が第２の長さに関連する場合、第２のデータベースデータ型に前記特定のデータ型をマッピングするステップとを含み、前記第１のデータベースデータ型は前記第２のデータベースデータ型と異なる、請求項２８に記載のコンピュータ読取可能な媒体。
31. 適切なデータベース表現を決定する前記ステップは、特定の要素が１より大きな最大出現回数を有するように定義されている場合、前記データベースシステムがサポートする集合型に前記XMLスキーマの特定の要素をマッピングするステップを含む、請求項２８に記載のコンピュータ読取可能な媒体。
32. 前記集合型はアレイ型であり、前記アレイ型のカーディナリティは、前記特定のデータベース要素に対して特定された前記最大出現回数に基づいて選択される、請求項３１に記載のコンピュータ読取可能な媒体。
33. 適切なデータベース表現を決定する制約の前記ステップは、前記XMLスキーマにおいて前記XMLスキーマの要素に対して特定された制約に基づき、前記適切なデータベース表現において制約を定義するステップを含む、請求項２７に記載のコンピュータ読取可能な媒体。
34. 制約を定義する前記ステップは、一意性の制約、参照の制約、およびnot nullの制約からなる組からの制約を定義するステップを含む、請求項３３に記載のコンピュータ読取可能な媒体。
35. 第１のデータ型は前記XMLスキーマの要素に関連し、
    前記XMLスキーマは前記第１のデータ型が第２のデータ型から継承することを特定し、
    適切なデータベース表現を決定する前記ステップは、前記データベースシステム内でオブジェクト型の部分型を定義するステップを含み、前記オブジェクト型は前記第２のデータ型に対応する、請求項２７に記載のコンピュータ読取可能な媒体。
36. 適切なデータベース表現を決定する前記ステップは、
    第１の組で別個の各要素を前記第１の組の他の要素とは別個に維持するデータベース構造に、前記XMLスキーマの第１の組の要素をマッピングするステップと、
    第２の組の要素の全要素が１つの区別されないデータベース要素として組合わされるデータベース構造に、前記XMLスキーマの第２の組の要素をマッピングするステップとを含む、請求項２７に記載のコンピュータ読取可能な媒体。
37. 前記データベースシステムは、前記XMLスキーマに関連する指示文に基づいて前記第１の組の帰属関係および前記第２の組の帰属関係を決定する、請求項３６に記載のコンピュータ読取可能な媒体。
38. 前記第１の組の要素における要素は、前記第２の組の要素に存在するように選択された要素よりも前記要素が頻繁にアクセスされるであろうという可能性に基づき、前記第１の組に存在するように選択される、請求項３６に記載のコンピュータ読取可能な媒体。
39. 適切なデータベース表現を決定する前記ステップおよびマッピングデータを生成する前記ステップは、前記データベースシステム内で変更を生じるXMLスキーマ登録動作の一部として行なわれ、
    前記コンピュータ読取可能な媒体は、前記XMLスキーマ登録動作によって生じたすべての変更を、前記XMLスキーマ登録動作中に特定のエラーに遭遇することに応答して自動的に除去するステップを行なうための命令をさらに含む、請求項２７に記載のコンピュータ読取可能な媒体。
40. 適切なデータベース表現を決定する前記ステップは、前記XMLスキーマのサイクルをどのように破壊するかを決定するステップを含む、請求項２７に記載のコンピュータ読取可能な媒体。
41. マッピングデータを生成する前記ステップは、前記XMLスキーマに注釈を加えるステップと、前記データベースシステム内に前記注釈の付いたXMLスキーマを格納するステップとを含む、請求項２７に記載のコンピュータ読取可能な媒体。
42. 前記適切なデータベース表現に基づいてデータベース内に構造を作成するステップと、
    前記構造に、前記XMLスキーマに準拠するXML文書からのデータを格納するステップとを行なうための命令をさらに含む、請求項２７に記載のコンピュータ読取可能な媒体。
43. XML文書からのデータを格納する前記ステップは、
    前記データベースシステムにおいてXML文書を受信するステップと、
    前記XML文書から、前記XMLスキーマの個々の要素に関連するデータを識別するステップと、
    前記データに関連する要素および前記マッピングデータに基づき、前記構造内の位置に、個々の要素に関連するデータを格納するステップとを含む、請求項４２に記載のコンピュータ読取可能な媒体。
44. 前記XMLスキーマがXMLスキーマに対する１つのXMLスキーマに準拠しているかどうかを決定するために、前記データベースシステム内で前記XMLスキーマを妥当性検証するステップを行なうための命令をさらに含む、請求項２７に記載のコンピュータ読取可能な媒体。
45. 決定する前記ステップは、前記データベースサーバにおいて前記XMLスキーマを受信することに応答して開始されるXMLスキーマ登録動作の一部として行なわれる、請求項２７に記載のコンピュータ読取可能な媒体。
46. 決定する前記ステップは、前記XMLスキーマに準拠するXML文書を前記データベースサーバで受信することに応答して開始されるXMLスキーマ登録動作の一部として行なわれる、請求項２７に記載のコンピュータ読取可能な媒体。
47. 前記XMLスキーマは、前記データベースシステムが前記XMLスキーマの少なくとも１つの要素をどのようにマッピングすべきかを示す、ユーザが特定した注釈を含み、
    前記マッピングデータの少なくとも一部は、前記ユーザが特定した注釈を反映する、請求項４５に記載のコンピュータ読取可能な媒体。

Images