JP2011181106A

JP2011181106A - Ｘｍｌデータ記憶、クエリー再書込、ビジュアライゼーション、マッピング、および参照のための方法および装置

Info

Publication number: JP2011181106A
Application number: JP2011128317A
Authority: JP
Inventors: Muralidhar Krishnaprasad; クリシュナプラサド，ムラリダール; Viswanathan Krishnamurthy; クリシュナマーシー，ビスワナサン; Ravi Murthy; マーシー，ラビ; Visar Nimani; ニマニ，ビサー
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2000-09-07
Filing date: 2011-06-08
Publication date: 2011-09-15
Anticipated expiration: 2021-09-07
Also published as: JP4890728B2; EP1337937A2; CA2421214C; AU9069301A; JP2004519755A; HK1054092A1; CA2767315A1; CA2421214A1; JP5320438B2; WO2002021339A3; WO2002021339A2; EP1337937B1; AU2001290693B2; CA2767315C

Abstract

【課題】ＸＭＬドキュメントとしてビジュアライズされるべき関係データベースの１つ以上の部分のための技術が提供される。
【解決手段】ＵＲＬをビジュアライズされたＸＭＬドキュメント上のXPath表記として定義することによって関係データベースに記憶されるデータにアクセスするための標準的なユニフォームリソースロケータ（ＵＲＬ）メカニズムが提供される。関係データベース内のデータからＸＭＬデータおよびメタデータをマッピングするための技術、ユーザがデータベースクエリーを用いてＸＭＬドキュメントの形で関係データベースからデータを取出すことを可能にするための技術、および、関係データベース内でのクエリー再書込およびＸＭＬデータ記憶のための技術が提供される。
【選択図】図４

Description

［関連出願および優先権主張］
この出願は、発明者ムラリダールクリシュナプラサド（Muralidhar Krishnaprasad）、ビスワナサンクリシュナマーシー（Viswanathan Krishnamurthy）、およびラビマーシー（Ravi Murthy）による「ＸＭＬデータ記憶、クエリー再書込、ビジュアライゼーション、マッピング、および参照」(“XML DATA STORAGE,QUERY REWRITES, VISUALIZATION, MAPPING AND REFERENCING”）と題された、２０００年９月７日に提出された米国特許仮出願第６０／２３０,８７８号の優先権を主張する。

この出願は、発明者としてムラリダールクリシュナプラサド、ビスワナサンクリシュナマーシー、およびラビマーシーを挙げる「データベースデータおよびメタデータに対する関係データベースおよびユニバーサルリソース識別子のＸＭＬビジュアライゼーションのための方法および装置」(“METHOD AND APPARATUS FOR XML VISUALIZATION OF A RELATIONAL DATABASE AND UNIVERSAL RESOURCE IDENTIFIERS TO DATABASE DATA AND METADATA”）と題された米国特許出願第号、代理人事件整理番号５０２７７‐１５６４の優先権を主張する。

この出願は、発明者としてムラリダールクリシュナプラサド、ビスワナサンクリシュナマーシー、ラビマーシー、およびビサールニマニ(Visar Nimani)を挙げる「関係データおよびメタデータをＸＭＬにマッピングするための装置および方法」(“APPARATUS AND METHOD FOR MAPPING RELATIONAL DATA AND METADATA TO XML”)と題された米国特許出願第号、代理人事件整理番号５０２７７−１５６５の優先権を主張する。

この出願は、発明者としてムラリダールクリシュナプラサド、ビスワナサンクリシュナマーシー、およびラビマーシーを挙げる「関係データベースシステム内のＸＭＬデータの一様な操作およびフレキシブルな記憶のための方法および装置」(“METHOD AND APPARATUS FOR FLEXIBLE STORAGE AND UNIFORM MANIPULATION OF XML DATA IN A RELATIONAL DATABASE SYSTEM”)と題された米国特許出願第号、代理人事件整理番号５０２７７−１５６６の優先権を主張する。

この発明は、一般に、関係データベースに関し、より具体的には、データベースのＸＭＬビジュアライゼーション、データベースオブジェクトへのＤＢＵＲＩ参照、関係データベースデータおよびメタデータのＸＭＬデータへのマッピング、ＸＭＬクエリーに応答してのＸＭＬデータの提供、ＸＭＬデータ記憶、操作、およびクエリー能力に関する。

ワールドワイドウェブでは、ドキュメント内の異なるソースからのデータを参照する必要がある。このようなデータを参照する標準的なやり方は、ＵＲＩまたはユニバーサルリソース識別子を用いることによる。大部分のデータが関係データベース内にあるため、このようなデータに対する標準的なＵＲＩベースのアクセス方法をサポートすることが必要である。通常、このようなアプリケーションは、サーブレット（Servlet）のような標準的なメカニズムを用いて書込まれ、これは、次に、ＳＱＬステートメントを実行してデータベースデータを取出し、フォーマットし得る。ＳＱＬデータの結果を、拡張可能マークアップ言語（ＸＭＬ）等の、ユーザが必要とする標準的なフォーマットに変換するためには、多くの場合、かなりの処理が必要とされる。ＸＭＬは、データを表わすためのワールドワイドウェブコンソーシアム（Ｗ３Ｃ）規格である。

関係データベース内のデータは、典型的には、データベースを管理するデータベースサーバにコマンドを送信することによって、アクセスされる。このようなコマンドは、データベースサーバがサポートするデータベース言語に適合していなければならない。

多くのアプリケーションは、現在、ＸＭＬドキュメントの形の入力データを予想して設計されている。アプリケーションに提供されるデータが関係データベースから来る場合、データは、典型的には、ＸＭＬドキュメントに再フォーマットされなければならない。

データがＸＭＬドキュメントとして提供される場合、ドキュメントの受信側は、ＸＭＬドキュメントの構造を理解しなければならない。ＸＭＬドキュメントが関係データベースクエリーの結果から生成される場合、結果として得られるＸＭＬドキュメントの構造は、典型的には、クエリーの性質に基づいて変化する。したがって、関係データをＸＭＬドキュメントに変換し、このように生成されたＸＭＬドキュメントの構造を示すデータを生成するプロセスは、面倒なものであり、柔軟性を欠くおそれがある。

種々の技術を用いて、このようなＸＭＬドキュメントからのデータを関係データベースに記憶することができる。１つの技術によると、各ＸＭＬドキュメントは、単一のデータ項目として扱われ、そのようなものとして関係表の単一の列に記憶される。この技術は、データベースサーバにサブミットされる前にＸＭＬが処理されなくてもよい点で、便宜的である。しかし、データベースサーバは、ＸＭＬドキュメントを単一のデータ項目とみなすため、データベースサーバは、ＸＭＬドキュメントが構成されており、単一のＸＭＬドキュメントが多くの属性および特定の値を備えたエレメントを含み得るという事実を活用することはできない。

代替的な技術によると、ＸＭＬドキュメントがデータベースに記憶される前に、ＸＭＬドキュメントは、その構成属性およびエレメントデータに分割され得る。各属性およびエレメントの値は、データベースにサブミットされ、表の対応する列に挿入される。この技術が用いられる場合、データベースサーバを用いて個別の属性値に基づいてデータが選択され得る。しかし、データがデータベースから取出される場合、属性値は、単一のＸＭＬドキュメントの一部としてではなく、まぎれもないデータ項目として提供される。ＸＭＬドキュメントを回復するためには、データベースサーバから受信されるデータは、再フォーマットされ、構成されてＸＭＬドキュメントを再構成しなければならない。

上に基づいて、ＵＲＬを用いたリソースへのアクセスをサポートするブラウザ等のクライエントが関係データにアクセスすることを可能にするための、それほど面倒でないメカニズムおよび技術を提供することが明らかに望ましい。

さらに、理にかない、融通性があり、かつ効率的な様態で関係データをＸＭＬに変換するための技術を提供することが望ましい。

記憶される特定の形に依存しないＸＭＬドキュメントを処理するための技術の提供が望まれる。言い換えると、アプリケーションにとって、それらのＸＭＬデータの記憶表現を独立して決定し、それが機能性にいかなる影響も与えないことが望ましい。しかし、記憶の選択は、アプリケーションの性能に影響を与えるおそれもある。さらに、データベースサーバにとって、ユーザ動作の最適な処理のために選択された記憶表現を活用する技術を実現することも望ましい。

ユーザがＸＭＬフォーマットで関係データベースからのデータを見ることと取出すこととを可能にするための技術が提供される。（１）このようなデータへのＵＲＩ参照を提供することによって、ワールドワイドウェブを通してユーザがこのデータにアクセスするための、（２）データベース内のこれらのＵＲＩ参照上で動作を記憶し、実行するための、技術が提供される。

データを関係データベースと交換するときにＸＭＬ構文を用いるための技術も提供される。ユーザは、XPath表記を用いてデータベースのこれらの「ビジュアライズされた」部分をナビゲートし得る。

関係データベース内のメタデータおよびデータをＸＭＬデータにマッピングするための技術が提供される。この発明の特定の実施例に従うと、オブジェクト関係データをＸＭＬデータに標準的にマッピングし、さらにはオブジェクト関係スキーマをＸＭＬスキーマに標準的にマッピングすることによって、ユーザがデータベースクエリを用いてＸＭＬドキュメントの形で関係データベースからデータを取出すことを可能にするためのメカニズムが提供される。異なるデータベーススキーマ内のデータベースメタデータオブジェクトを異なるＸＭＬネーム空間にマッピングすることによって、ＸＭＬネーム空間を用いてスキーマ情報を増加させる。

関係データベースシステム内で抽象データ型を用いてＸＭＬデータをモデル化するための技術が提供される。

ユーザがＸＭＬクエリーをサブミットして、関係データベースに記憶されるＸＭＬドキュメント内のデータにアクセスする時に、ＸＭＬクエリーおよびマッピング情報に基づいてデータベースクエリーを生成するためのメカニズムが提供される。このプロセスは、ＸＭＬデータの基礎をなす記憶表現をより良く活用する他のクエリーへと、ユーザクエリー（および他のデータ操作動作）を再び書込むことを含む。

この発明は、同じ参照番号が同様の要素を指す添付の図内で、限定としてではなく、例として例示される。

関係データベース内のスキーマおよびスキーマオブジェクトを例示したブロック図である。関係データベースに記憶された表を例示したブロック図である。 Uritypeの階層を例示したブロック図である。 Uritypeデータを記憶する関係データベース表を例示したブロック図である。表を例示したブロック図である。ＳＱＬ結果セットを含むビューを例示したブロック図である。 XMLType記憶アーキテクチャを例示したブロック図である。 XMLType列の構造を例示したブロック図である。この発明の実施例が実現され得るコンピュータを示す図である。

ＸＭＬ構文を用いて関係データベース内のデータにアクセスするための技術、関係データベースからのデータおよびメタデータをＸＭＬにマッピングするための技術、関係データベースシステム内で抽象データ型を用いてＸＭＬデータをモデル化するための技術、多数の記憶表現のための技術、一様なクエリーインターフェイスのための技術、およびクエリー再書込を用いた最適な処理のための技術が提供される。以下の説明では、説明上、この発明の完全な理解を提供するために、多くの具体的な詳細事項が示される。しかし、これらの具体的な詳細事項なしに、この発明が実施され得ることは、当業者には明らかであろう。他の例では、この発明を不必要に曖昧なものにしないために、周知の構造および装置がブロック図の形で示される。

機能的な概要
ここで説明される技術を用いると、「現在のユーザ」とここで呼ばれる、関係データベースの特定のいずれかのユーザは、現在のユーザがアクセス特権を許可された関係データベース内のすべての表およびビューならびに関連のスキーマをＸＭＬツリーとして見ることができる。言い換えると、ユーザは、表およびビューの形でデータベースデータを見る代わりに、データは、ＸＭＬドキュメントの形でユーザに対して提供され、ＸＭＬドキュメントの典型的な構造はツリーである。

データベースの、いくつかの並行な現在のユーザが存在し得る。しかし、説明を簡素化するために、ここで説明される技術は、単一の現在のユーザを指す。ＸＭＬツリーは、以下、「ビジュアライズされたＸＭＬドキュメント」と呼ばれる。ビジュアライズされたＸＭＬドキュメントは、表およびビューならびに関連のスキーマのＸＭＬ表現を含む。ＸＭＬドキュメントは、ユーザのアクセス権に基づくため、ＸＭＬドキュメントは、各ユーザのアクセス権に基づいてユーザごとに異なり得る。したがって、ここで説明されるようなビジュアライズされたＸＭＬドキュメントは、現在のユーザに関連する。

ＵＲＬまたはＵＲＩによって識別され、かつ関係データベース内でアクセスされるべきデータ項目は、ここで「目標データ」と呼ばれる。目標データは、実現例ごとに異なり得る。目標データは、関係データベーススキーマオブジェクト、関係データ、および制御ファイル等の多くの種類のデータのいずれであってもよい。この発明は、特定のいずれかの種類の目標データに限定されない。

目標データがＸＭＬデータであるかのように、現在のユーザが関係データベース内の目標データにアクセスし、それを操作するために、以下のためのメカニズムが提供される。すなわち、１）現在のユーザが関係データベース内でアクセス特権を有するすべてのデータを含む、現在のユーザのためのいずれかの関係データベースのデフォルトバーチャルビジュアライゼーションであって、デフォルトバーチャルビジュアライゼーションは標準的なＸＭＬドキュメントとして定義される、デフォルトバーチャルビジュアライゼーションを定義するためのメカニズム、２）標準的なユニフォームリソースインディケータ（ＵＲＩ）を提供するためのメカニズムであって、これは、データベース内で局所的に定義され、さらには、これによって、ビジュアライズされたＸＭＬドキュメント上でのXPath表記としてＵＲＩを定義することにより、ビジュアライズされたＸＭＬドキュメントの１つ以上のフラグメントがアクセスされ得る、標準的なユニフォームリソースインディケータ（ＵＲＩ）を提供するためのメカニズム、３）ビジュアライズされたＸＭＬドキュメント上でのXpath表記としてＵＲＬを定義することによって関係データベースに記憶されるデータにアクセスするために関係データベースの外のウェブブラウザと共に用いられ得るメカニズムとして標準的なユニフォームリソースロケータ（ＵＲＬ）を提供するためのメカニズム、４）ＵＲＩおよびＵＲＬを記憶するために用いられ得る新しいデータ型および新しいオブジェクト型を関係データベース内で提供するためのメカニズム、５）ここで説明されるような標準的なＵＲＩおよびＵＲＬを用いて、ビジュアライズされたドキュメントを通して関係データベース内のデータを修正、生成、追加、または削除するためのメカニズムを提供するためのメカニズムが提供される。

XPath表記は、ＸＭＬドキュメントをナビゲートするためのＷ３ｃの標準的なやり方である。XPath表記は、ビジュアライズされたＸＭＬドキュメント（関係データベースのＸＭＬビジュアライゼーション）上での走査(traversal)および挿入／削除／更新を可能にする。XPath表記は、関係データベース内でＳＱＬデータ定義言語（ＤＤＬ）およびデータベース操作言語（ＤＭＬ）へと変換され得る。

（１）関係データベースのＸＭＬビジュアライゼーションと、（２）XPath表記を用いてビジュアライズされたＸＭＬドキュメントをナビゲートするためのメカニズムとの組合せによって、ユーザが関係データベース内のいずれかのデータを「指し示す」ことが可能となる。たとえば、/SCOTT/EMP/ROW［EMPNO=2100］等のXPath表記は、ＥＭＰＮＯ＝２１によって識別される行内のデータ値を指し示す。ここでの行は、ＥＭＰと呼ばれる関係データベース表内にあり、これは、スコットと呼ばれる関係データベーススキーマのスキーマオブジェクトである。関係データベースのＸＭＬビジュアライゼーションは、ここでより詳細に説明される。

データベースクエリーの結果は、ここで、「ＳＱＬ結果セット」と呼ばれる。ＳＱＬ結果セットが１つ以上のＸＭＬドキュメントに変換されると、変換された結果セットは、ここで「ＸＭＬ結果セット」と呼ばれる。関係データベース内のデータは、ここで「オブジェクト関係データ」と呼ばれ、オブジェクト関係データに関連したメタデータが、ここで関係データベーススキーマと呼ばれる。関係データベーススキーマは、オブジェクトの集合であり、ここで「スキーマオブジェクト」と呼ばれる。スキーマオブジェクトは、関係データベース内のデータを直接指す論理構造である。したがって、スキーマオブジェクトは、表、ビュー、クラスタ、およびインデックス等の構造を含む。

ユーザが関係データベースクエリー言語を用いてクエリーをサブミットし、さらにはＸＭＬドキュメントの形の結果セットを受取り得るために、以下のためのメカニズムが提供される。すなわち、１）関係データベースからＸＭＬの形へとオブジェクト関係データをマッピングするための、２）関係データベーススキーマをＸＭＬの形にマッピングするための、３）オブジェクト関係データおよび関係データベーススキーマからＸＭＬドキュメントを生成するための、メカニズムが提供される。

オブジェクト関係データおよび関係データベーススキーマから結果セットしてＸＭＬドキュメントを生成するためのメカニズムは、関係データベースに記憶されるルールセットに基づく。データベースクエリーの処理中に、予め定義されるか、または動的に定義されるいずれかであるオブジェクト関係データは、ルールセットに基づいて対応のＸＭＬデータにマッピングされる。このようなマッピングは、ここで「ＸＭＬの形へのオブジェクト関係データの標準的なマッピング」と呼ばれる。

同様に、関係データベーススキーマは、関係データベーススキーマをそれらの対応のＸＭＬスキーマにマッピングすることによって、ＸＭＬの形にマッピングされる。このようなマッピングは、「ＸＭＬスキーマへの関係データベーススキーマの標準的なマッピング」とここで呼ばれるルールセットに基づく。ＸＭＬスキーマへの関係データベーススキーマの標準的なマッピングは、ここでより詳細に説明される。

さらに、ＸＭＬ結果セットの生成、つまり、ＳＱＬ結果セットからのＸＭＬドキュメントの生成は、ここでより詳細に説明されるようなルールセットに基づく。

ＸＭＬデータおよびＳＱＬデータの処理を関係データベース内で一体化するために、関係データベース内でＸＭＬ型のデータ型をサポートして表の列および行内にＸＭＬドキュメントを記憶するためのメカニズムが提供される。記憶表現は、実現例ごとに異なり得る。この発明は、特定のいずれの記憶表現にも限定されない。この発明の特定の実施例では、ユーザは、関係データベース内での記憶のためにＸＭＬドキュメントをサブミットし得る。ＸＭＬドキュメントの各フィールドからのデータは、記憶に関連した種々の既存のインデックス付けメカニズムを活用する様態で、関係データベースに自動的に記憶される。たとえば、ＸＭＬドキュメントが、関係データベース内での記憶のためにサブミットされると、ＸＭＬドキュメントの各フィールドを記憶するために、関係データベース内で対応の記憶列を決定するためのメカニズムが提供される。したがって、ＸＭＬドキュメントの各フィールドは、関係データベース内のある列にマッピングされ、このマッピング情報は、関係データベースに記憶される。データの型に応じて、データフィールドのいくつかがまとめられて単一のオブジェクト関係列に記憶され得、他のフィールドは、別個のオブジェクト関係列として記憶され得る。ＸＭＬドキュメントの各フィールドからのデータには、適切なインデックス付け方式を用いて、インデックスが付けられ得る。たとえば、Ｂツリーインデックスが、関係型データを含む列のために用いられ得、インターメディアテキスト等のテキストインデックスが、大きなテキストデータを含む列のために用いられ得る。特定の実施例では、ユーザは、マッピング情報を特定し得る。マッピング情報を特定することによって、ユーザは、マッピングの細分性を制御し得る。

したがって、以下のような技術が提供される。すなわち、１）ＸＭＬデータおよびＳＱＬデータの一様な処理のための技術、２）明確に定義されたＸＭＬ動作セットのための一様なクエリーインターフェイスのための技術であって、動作セットは、関係データベース内のＸＭＬデータのための基礎をなす記憶メカニズムから分離されている、技術、３）関係データベース内での基礎をなす記憶メカニズムのデータアクセスおよびデータ操作能力を活用する形へのクエリー再書込のための技術が提供される。

関係データベースおよびXPathのバーチャルＸＭＬビジュアライゼーション
特定の実施例によると、現在のユーザは、ユーザがアクセス特権を許可された関係データベース内のすべてのデータを、ビジュアライズされたＸＭＬドキュメントとして見ることができる。ビジュアライズされたＸＭＬドキュメントは、表およびビューを備えたスキーマセットおよび「データベースタグ」を含む。たとえば、データベースが“oradb”と呼ばれるならば、ＸＭＬドキュメントは、データベースタグ“<oradb>”で始まり、データベースタグ“<／oradb>”で終了する。

現在のユーザは、ビジュアライズされたＸＭＬドキュメントからのエレメントの読出、挿入、更新、および削除を許可される。したがって、現在のユーザは、関係データベース内でのデータの記憶またはアクセスの実際の性質を認識していない。現在のユーザは、ビジュアライズされたＸＭＬドキュメントをナビゲートするためにXPath表記を用いるのみである。

たとえば、関係データベースの現在のユーザがスコットであると仮定する。関係データベースの現在のユーザの各々に関連しているのは、同じ名前によるスキーマである。スキーマは、表、ビュークラスタ、および機能等の関係データベースオブジェクトの論理集合である。

図１Ａは、関係データベース内のスキーマおよびスキーマオブジェクトを例示するブロック図である。図１Ａの列１０２は、スキーマオブジェクトのリストを含む。説明のために、２つのスキーマ、ＳＣＯＴＴおよびＪＯＮＥＳのみが示される。列１０４は、各スキーマ内の関係データベースオブジェクトを含む。説明のために、２つの表、ＥＭＰおよびＤＥＰＴのみが示される。スキーマＳＣＯＴＴは表ＥＭＰを含み、スキーマＪＯＮＥＳは表ＤＥＰＴを含む。

図１Ｂは、関係データベースに記憶される表を例示したブロック図である。関係データベース１１０は、表ＥＭＰおよびＤＥＰＴを含む。表ＥＭＰは、３つの列、ＥＭＰＮＯ、ＥＮＡＭＥ、およびＳＡＬＡＲＹを有する。ＥＭＰの各列は、値の行を含む。表ＤＥＰＴは、２つの列、ＤＥＰＴＮＯおよびＤＮＡＭＥを有する。ＤＥＰＴの各列は、値の行を含む。

現在のユーザ、スコットは、関係データベース内のスキーマＳＣＯＴＴおよびＪＯＮＥＳにアクセスする特権を有し、さらにはＳＣＯＴＴおよびＪＯＮＥＳに関連するデータにアクセスする特権を有すると仮定する。この技術の特定の実施例に従うと、現在のユーザ、スコットは、（全ビジュアライゼーションではないが）以下のような関係データベースのデフォルトバーチャルビジュアライゼーションを見ることができる。

上のデフォルトバーチャルビジュアライゼーションは、デフォルトバーチャルビジュアライゼーションの１つの実現例にすぎない。デフォルトバーチャルビジュアライゼーションは、実現例ごとに異なり得る。この発明は、ある特定のビジュアライゼーションモデルに限定されない。

この技術の特定の実施例に従うと、ＵＲＬおよびＵＲＩをビジュアライズされたＸＭＬドキュメント上のXPath表記として定義することによって、いずれかのデータベースに記憶されたデータにアクセスするための標準的なＵＲＬおよびＵＲＩメカニズムも提供される。

この発明の１つの実施例に従うと、ＵＲＬは、もともとのＵＲＩ処理メカニズムを用いてＵＲＬが指し示すデータにアクセスするサーブレットを用いることによって、処理され得る。

この発明の特定の実施例に従うと、データベースタグ（oradb）は、処理コンテキスト内に暗黙的に結びつけられ得、ＵＲＬ内で明示的に特定される必要はない。

関係データベースへのローカルアクセスを有さない現在のユーザは、ブラウザを用いてＵＲＬを用いることによりインターネット上の関係データベース内のデータにアクセスし得る。たとえば、現在のユーザはスコットであり、スコットはブラウザを用いて、ＥＭＰ表がスキーマＳＣＯＴＴ内にあり、従業員番号が２１００である行の、ＥＭＰ表の従業員名列にアクセスしたいと仮定する。スコットが用いるであろうＵＲＬは、以下のように示され得る。

上のＵＲＬでは、データベースタグ“oradb”は暗黙的に結びつけられ、したがって、ユーザはＵＲＬ内でデータベースタグを特定する必要はない。

ＵＲＬまたはＵＲＩにアクセスした結果は、以下で示されるようなｅネーム変数を含むビジュアライズされたＸＭＬドキュメントのフラグメントであり得る。

現在のユーザは、コンテント型でＵＲＬまたはＵＲＩを増補して多目的インターネットメール拡張（ＭＩＭＥ）タイプの出力を特定し得る。たとえば、ＵＲＬが、イメージを記憶しているＢＬＯＢ（バイナリラージオブジェクト）列を指し示し、イメージが「目標データ」ならば、コンテント型は、gifに設定され得る。したがって、ＵＲＬを用いることに応答して、現在のユーザは、たとえば、大きな１６進法ファイルではなくイメージを得る。

別の例として、現在のユーザは、ＵＲＬを増補して、ＵＲＬが指し示す列のテキスト値を目標データとして要求し得る。たとえば、現在のユーザ、スコットが、従業員番号が２１００である行の、ＥＭＰ表の従業員名列にアクセスするために以下のＵＲＬを用いると仮定する。

“text()”は、テキストノードを識別するためのXPath規格である。上のＵＲＬ内でtext()を用いることによって、従業員番号が２１００である行の、ＥＭＰ表の従業員名列内でテキスト値のみを含む結果が生み出されるであろう。従業員番号が２１００である行の、ＥＭＰ表の従業員名列内のテキスト値は、「ジョン」である。したがって、text()を用いて上のＵＲＬにアクセスする結果は、「ジョン」である。対照的に、例の従業員名列にアクセスするためにtext()がＵＲＬ内で用いられない場合、「ジョン」は、以下のようにビジュアライズされたＸＭＬドキュメントのフラグメント内にインラインされる。

<ENAME>John</ENAME>
この発明の別の実施例では、ＵＲＬとともに、またはユーザ書込機能を通して記憶され得る他の補助情報に基づいて、ＭＩＭＥ情報がデータベースによって自動的に引出され得る。

関係データベースのバーチャルＸＭＬビジュアライゼーションを定義するためのマッピングルール
データベースのデフォルトバーチャルビジュアライゼーションを標準的なＸＭＬドキュメントとして定義するための技術が提供される。１つの実施例に従うと、デフォルトバーチャルビジュアライゼーションを定義するためのルールは、以下のとおりである。

１）目標データを含む関係データベースを識別する擬似トップレベル囲みタグが存在する。目標データを含む関係データベースを識別する囲みタグのペアの例は、<oradb>...</oradb>であり、“oradb”は、以下で示されるように、目標データを含む関係データベースの名前である（ビジュアライゼーション内のすべてのエレメントが示されているわけではない）。

２）現在のユーザがアクセス特権を許可された関係データベース内の各スキーマは、ビジュアライズされたＸＭＬドキュメント内の１つのエレメントに対応する。エレメントの名前は、エレメントが対応するスキーマの名前と同じである。ここで示される例では、関係データベース“oradb”内のスキーマＳＣＯＴＴは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。同様に、スキーマＪＯＮＥＳは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。以下のビジュアライズされたＸＭＬドキュメントは、スキーマエレメントレベルでの関係データベースのビジュアライゼーションである。例示の目的のために、スキーマＳＣＯＴＴおよびＪＯＮＥＳに対応するエレメントのみが示される。

３）現在のユーザがアクセス特権を許可された関係データベース内の各表またはビューは、ビジュアライズされたＸＭＬドキュメント内の１つの要素に対応する。エレメントの名前は、エレメントが対応する表またはビューの名前と同じである。ここで示される例では、関係データベース“oradb”内の表ＥＭＰは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。同様に、表ＤＥＰＴは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。以下のビジュアライズされたＸＭＬドキュメントは、表エレメントレベルでの関係データベースのビジュアライゼーションである。例示のために、表ＥＭＰおよびＤＥＰＴに対応するエレメントのみが示される。

４）現在のユーザがアクセス特権を許可された関係データベース内の各表またはビューの各行は、ビジュアライズされたＸＭＬドキュメント内の１つのエレメントに対応する。以下のビジュアライズされたＸＭＬドキュメントは、行エレメントレベルでの関係データベースのビジュアライゼーションである。例示のために、表ＥＭＰおよびＤＥＰＴの行に対応するエレメントのみが示される。

５）現在のユーザがアクセス特権を許可された関係データベース内の各表またはビューの各列は、ビジュアライズされたＸＭＬドキュメント内の１つのエレメントに対応する。エレメントの名前は、エレメントが対応する列の名前と同じである。ここで示される例では、表ＥＭＰ内の列ＥＭＰＮＯは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。同様に、列ＥＮＡＭＥは、ビジュアライズされたＸＭＬドキュメント内の同じ名前を有するエレメントによって表わされる。以下のビジュアライズされたＸＭＬドキュメントは、列エレメントレベルでの関係データベースのビジュアライゼーションである。例示のために、表ＥＭＰ内の列ＥＭＰＮＯおよびＥＮＡＭＥに対応するエレメントのみが示される。

XPath表記を関係データベースクエリーに変換するためのルール
この発明の１つの実施例に従うと、ＸＭＬビジュアライゼーション上でのXpathクエリーは、関係データベースクエリーおよびＸＭＬ内でフォーマットされる結果へと変換され得る。XPath表記を関係データベースクエリーに変換するための技術が提供される。説明のために、クエリーに変換されるべきXPath表記が関係データベース“oradb”のコンテキスト内にあると仮定する。したがって、典型的なXPath表記のフォーマットは“oradb”のコンテキストであり、以下のように生成され得る。

/Schema/Table/Row/Column/Attribute...（! further attributes）
上のXPath表記の各エレメントは、任意で述語を有し得る。述語は、形［(element)(operator)(value)］をとる。

たとえば、エレメント、Rowは、以下のような述語を有し得る。
/Schema/Table/Row［Column1=2100］/Column2
XPath表記を関係データベースクエリーに変換するためのルールは、XPath表記のための上の一般的なフォーマットを指し、以下のとおりである。

１）形/Schema/TableのXPath表記は、以下のＳＱＬステートメント等の対応する関係データベースクエリーに変換される。

Select*
From Schema.Table
上のステートメントで用いられる構文は、単なる例示にすぎない。ＳＱＬステートメントの実際の構文は、実現例ごとに異なり得る。この発明は、特定のいかなる構文にも限定されない。

ＳＱＬステートメントの結果は、次に、ビジュアライズされたＸＭＬドキュメントの対応するフラグメントに変換され得る。

２）形/Schema/Table/Row/ColumnのXPath表記は、以下のＳＱＬステートメント等の対応する関係データベースクエリーに変換される。

Select Column
From Schema.Table
上のステートメントで用いられる構文は、単なる例示にすぎない。ＳＱＬステートメントの実際の構文は、実現例ごとに異なり得る。この発明は、特定のいかなる構文にも限定されない。

３）形/Schema/Table/Row［Empno=2100］/ColumnのXPath表記は、以下のＳＱＬステートメント等の対応する関係データベースクエリーに変換される。

Select Column2
From Schema.Table
Where Column1=2100
上のステートメントで用いられる構文は、単なる例示にすぎない。クエリー言語ステートメントの実際の構文は、実現例ごとに異なり得る。この発明は、特定のいずれかの構文に限定されない。

クエリー言語ステートメントの結果は、次に、ビジュアライズされたＸＭＬドキュメントの対応するフラグメントに変換され得る。

ＵＲＩ型
特定の実施例に従うと、特別なデータ型が関係データベース内で提供されて関係データベース内でＵＲＩおよびＵＲＬが記憶される。このようなデータ型は、ここで“Uritype”と呼ばれる。ＵＲＩおよびＵＲＬは、ＵＲＩおよびＵＲＬをUritypeデータとして定義することによって、関係データベース表内の列に記憶され得る。

図２Ａは、Uritypeの階層を例示するブロック図である。図２Ａは、サブタイプを含む一般的なUritype２１０を示す。特定の実施例に従うと、サブタイプは、DB-Uritype２１２、HTTP-Uritype２１４、およびFTP-Uritype２１６である。

HTTP-Uritypeは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）ＵＲＬを記憶し、ＨＴＴＰプロトコルを用いてＵＲＬによって指し示されるデータをフェッチする。FTP-Uritypeは、ＦＴＰ（ファイル転送プロトコル）ＵＲＬを記憶し、ＦＴＰを用いてデータをフェッチする。DB-Uritypeは、ここで説明されるXpathメカニズムを用いてイントラデータベース参照を記憶する。

DB-Uritypeは、前に定義されたXpath変換メカニズムを用いて、または他のメカニズムを通して、ＵＲＬに関連したデータをフェッチし得る。

ユーザは、Uritypeのサブタイプまたは他のサブタイプのいずれかを定義し得、そのＵＲＬによって指し示されるデータを得るための実現例を提供し得る。

ＵＲＩおよびＵＲＬを記憶できることとは別に、Uritypeデータ型に関連した一般的な機能は、ＵＲＩおよびＵＲＬの取出と、関係データベース内でＬＯＢとして、たとえば、ＣＬＯＢおよびＢＬＯＢとして記憶されるＸＭＬドキュメントの取出とを含む。

現在のユーザが、ＵＲＬによって指し示される目標データを関係データベースから取り出したい場合、現在のユーザのXPath表記は、適切なクエリー言語ステートメントに自動的に変換される。このようなステートメントの実際の構文は、関係データベース内で用いられるクエリー言語に依存し、実現例ごとに異なり得る。この発明は、特定のいずれかの構文に限定されない。Uritypeデータ型の関係データベース機能は、以下のステートメントによって要約され得る。

getURL();
getBLOB();
getCLOB().
getXML();
上のステートメントは、単に機能を例示するにすぎない。このようなステートメントは、必ずしもクエリー言語ステートメントではない。この発明は、ある特定のセットのクエリー言語ステートメントに限定されない。

図２Ｂは、Uritypeデータを記憶する関係データベース表を例示するブロック図である。関係データベース表２００は、パーチェスオーダ表である。表２００は、２つの列、パーチェスオーダ番号列２５０とパーチェスオーダリンク列２６０とを有する。両列２５０および２６０は、３つのデータ行、つまり、行２７１、行２７２、および行２７３を含む。パーチェスオーダリンク列は、型UriTypeのデータを記憶し得る。

行２７１の列２６０は、型HTTP-Uritypeのデータを記憶する。行２７２の列２６０は、型FTP-Uritypeのデータを記憶する。最後に、行２７３の列２６０は、型DB-Uritypeのデータを記憶する。DB-Uritype、HTTP-Uritype等は、UriType型のサブタイプとして定義されたため、これらの型のインスタンスをパーチェスオーダリンク列に記憶できることが注目される。

現在のユーザは、表２００内で記憶されるUritypeデータによって指し示されるデータのいずれかを引出し得る。データベースは、適切なメカニズムを用いてデータを自動的にフェッチする。

たとえば、以下で示されるクエリーは、パーチェスオーダリンク列によって指し示されるパーチェスオーダデータを取出す。

データベースは、第１の行に対してはＨＴＴＰを通してパーチェスオーダをフェッチし、第２の行に対してはＦＴＰを用い、最後の行に対してはDB-Uritype処理メカニズムを用いる。

上のステートメントで用いられる構文は、単なる例示にすぎない。実際の構文は、実現例ごとに異なり得る。この発明は、特定のいずれかの構文に限定されない。適切なクエリーへの変換は、現在のユーザには見えない。したがって、現在のユーザが目標データの型を認識する必要はない。

ＵＲＩＴＹＰＥ機能を用いての関係データの修正
特定の実施例に従うと、ここで説明されるような標準的なＵＲＩおよびＵＲＬを用いて関係データベースに記憶されるＸＭＬデータを修正、追加、または削除するためのメカニズムが提供される。

たとえば、現在のユーザ、スコットは、（全ビジュアライゼーションではないが）以下のような関係データベースのデフォルトバーチャルビジュアライゼーションを見ることができると仮定する。

現在のユーザ、スコットが、従業員番号が２１００である行の、ＥＭＰ表の従業員名列のデータを更新したがっているとさらに仮定する。更新は、名前「ジョン」を「メアリ」に変更することを含む。

特定の実施例に従うと、現在のユーザ、スコットが関係データベースへの直接のアクセスを有するならば、スコットは、以下を行ない得る。すなわち、１）ＸＭＬデータの更新のための更新動作を選択し、２）以下のXPath表記を用いる。

XPath表記/SCOTT/EMP/ROW［EMPNO=2100］/ENAMEは、更新されるべき目標データの行および列を示す。

XPath表記<ENAME>Mary</ENAME>は、更新されるべき目標データの新しい値を示す。
上のXPath表記は、以下のようなクエリー言語ステートメントに変換される。

UPDATE“SCOTT”.”EMP”
SET“ENAME”='Mary'
Where“EMPNO”=2100;
現在のユーザ、スコットがウェブブラウザを用いて関係データベース内の目標データにアクセスする場合、特定の実施例に従うと、汎用サーブレットが提供されて現在のユーザが、標準的なＵＲＩおよびＵＲＬを用いて関係データベース内に記憶されるＸＭＬデータを修正、追加、または削除することが可能となり得る。名前「ジョン」を「メアリ」に更新する上の例を用いると、スコットが以下を行なうことを可能にする汎用サーブレットが提供される。すなわち、１）ＸＭＬデータを更新するために更新動作を選択し、２）以下のXPath表記の形で「更新」情報をサーブレットにポストする。

/SCOTT/EMP/ROW［EMPNO=2100］/ENAME
<ENAME>Mary</ENAME>
他の特定の実施例に従うと、特別なサーブレットが各データベース動作のために提供され得る。言い換えると、ＩＮＳＥＲＴ動作のために「挿入−サーブレット」が存在し得、ＤＥＬＥＴＥ動作のために「削除−サーブレット」が存在し得、ＵＰＤＡＴＥ動作のために「更新−サーブレット」が存在し得る。

名前「ジョン」を「メアリー」に更新する上の例を用いて、スコットが以下を行なうことを可能にする“Insert＿servlet”が提供される。すなわち、１）ＸＭＬデータを更新するために更新動作を選択し、２）以下のXPath表記の形で「更新」情報をサーブレットに対してポストする。

同じメカニズムを用いてメタデータを修正、追加、または削除する。たとえば、現在のユーザ、スコットがスキーマＳＣＯＴＴを削除したい場合、スコットは、以下を行ない得る。すなわち、１）関係データベース内のＸＭＬデータを削除するために削除動作を選択し、２）ビジュアライズされたＸＭＬドキュメント内のどのレベルが削除されるべきかを示す以下のXPath表記を用いる。

図３Ａは、関係データベースに記憶される表を例示したブロック図である。表ＥＭＰは、３つの列、ＥＭＰＮＯ、ＥＮＡＭＥ、およびＳＡＬＡＲＹを有する。ＥＭＰの各列は、表ＥＭＰの複数行の各々の値を含む。しかし、簡素化のために、図３Ａは、２つの行、つまり、行３０２および行３０４のみを示す。列ＥＭＰＮＯでは、行３０２は値「２１００」を含み、行３０４は値「２２００」を含む。同様に、列ＥＮＡＭＥでは、行３０２は値“ＪＯＨＮ”を含み、行３０４は値“ＭＡＲＹ”を含む。列ＳＡＬＡＲＹでは、行３０２は値「５５Ｋ」を含み、行３０４は値「６５Ｋ」を含む。

例として、ユーザが関係データベースクエリーをサブミットして列のうちの２つからの値、つまり、表ＥＭＰからのＥＭＰＮＯおよびＥＮＡＭＥを取出すことを仮定する。関係データベースクエリーの一例は、以下のＳＱＬステートメント、SELECT empno, ename FROM empである。

上のステートメントで用いられる構文は、単なる例示にすぎない。ＳＱＬステートメントの実際の構文は、実現例ごとに異なり得る。この発明は、特定のいずれかの構文に限定されない。

図３Ｂは、ename FROM emp、SELECT empno、およびＳＱＬステートメントのＳＱＬ結果セットを含むビューを例示したブロック図である。ＳＱＬ結果セットは、表ＥＭＰの２つの列のみを含む。したがって、図３Ｂは、列ＥＭＰＮＯおよびＥＮＡＭＥのみを示す。たとえＳＱＬ結果セットが列ＥＭＰＮＯおよびＥＮＡＭＥ内のすべての値の行を含むとしても、簡素化のために、（それぞれ行３０２および３０４からの値を含む）行３１０および３１２のみが図３Ｂで示される。

図３ＢのＳＱＬ結果セットは、この発明の特定の実施例に従うと、以下のルールに基づいて対応するＸＭＬ結果セットに変換され得る。

１）ＸＭＬ結果セットは、ＲＯＷＳＥＴタグで始まるＸＭＬドキュメントの形にある。ＲＯＷＳＥＴタグは、ＸＭＬドキュメントが行エレメントのセットを含むことを示す。

２）ＳＱＬ結果セットの各行は、ＸＭＬドキュメント内の対応のＲＯＷエレメントに変換され、ＲＯＷエレメントはＲＯＷタグのペアによって示される。

３）ＳＱＬ結果セットのある所与の行内の各列は、ＳＱＬ結果セットの所与の行に対応する取囲む(encompassing)ＲＯＷエレメント内に埋込まれる対応するＣＯＬＵＭＮエレメントに変換される。ＣＯＬＵＭＮタグの名前は、ＳＱＬ結果セット内の対応する列の名前である。

ＲＯＷＳＥＴ、およびＲＯＷタグは、この発明の異なる実現例で異なった名前を有し得る。この発明は、このようなタグに関して特定のいかなる名前にも限定されない。ＣＯＬＵＭＮタグに関しては、１つの実施例に従うと、ＣＯＬＵＭＮタグの名前を変更するために、エイリアスメカニズムが提供される。

例示のために、上の例のＸＭＬ結果セットは、以下のように現われ得る。

オブジェクト関係データのマッピング
ＸＭＬの形へのオブジェクト関係データの標準的なマッピングの例は、以下のとおりである。

ａ）ＸＭＬエレメントへのオブジェクト関係列のマッピング
たとえば、図３Ａを参照して、単一の行３０２におけるＥＭＰＮＯおよびＥＮＡＭＥを選択するためのＳＱＬクエリーのＸＭＬ結果セットは、以下のように現われ得る。

オブジェクト関係列ＥＭＰＮＯおよびＥＮＡＭＥは、ＸＭＬ結果セット内の対応するＣＯＬＵＭＮエレメントにマッピングされる。ＥＭＰＮＯおよびＥＮＡＭＥは、取囲むＲＯＷエレメント内に埋込まれる。

ｂ）オブジェクト型の属性を含むネストにされたサブエレメントを有するＸＭＬエレメントへのオブジェクト関係オブジェクト型のマッピング
説明のために、“Address＿t”と呼ばれる、ユーザによって定義される型は、あらかじめ関係データベース内で生成されると仮定する。“Address＿t”は、３つのスカラ属性、つまり、ＣＩＴＹ、ＳＴＡＴＥ、およびＺＩＰを含む複雑なオブジェクト型である。関係データベース内にはEmployee＿tableと呼ばれる表が存在すると仮定する。Employee＿tableは、２つの列ＥＮＡＭＥおよびＡＤＤＲＥＳＳを有する。ＥＮＡＭＥは、「ストリング」の型であり、ＡＤＤＲＥＳＳは、ユーザによって定義される型“Address＿t”である。列ＥＮＡＭＥおよびＡＤＤＲＥＳＳは、各々、値の単一の行のみを、つまり、従業員名「ジョン」およびジョンのアドレスをそれぞれ含むことをさらに仮定する。

“SELECT*FROM Employee＿table”等のＳＱＬクエリーは、この発明の特定の実施例に従うと、以下のＸＭＬ結果セットにマッピングするＳＱＬ結果セットを生成し得る。

オブジェクト関係列ＡＤＤＲＥＳＳは、ＸＭＬ結果セット内の同じタグ名を有するエレメントにマッピングする。“address＿t”型であるエレメントＡＤＤＲＥＳＳは、属性ＣＩＴＹ、ＳＴＡＴＥ、およびＺＩＰを有し、これらはエレメントＡＤＤＲＥＳＳのサブエレメントにマッピングされる。各サブエレメントは、ＸＭＬ結果セット内のその対応するタグ名としての属性の名前を有する。

ｃ）ＸＭＬリストへのオブジェクト関係集合型のマッピング
説明のために、“Lineitems＿t”と呼ばれる、ユーザによって定義される型が、あらかじめ関係データベース内で生成されることを仮定する。“Lineitems＿t”は、複数の集合項目を含む集合オブジェクト型である。各集合項目は、集合内の項目の位置上の値を定義するＩＤ属性を有する。たとえば、関係データベース内にはPurchaseOrder＿tableと呼ばれる表が存在することを仮定する。PurchaseOrder＿tableは、２つの列、パーチェスオーダ番号のためのＰＯＮＯと、ライン項目リストのためのＬＩＮＥＩＴＥＭＳとを有する。ＰＯＮＯは、「番号」の型であり、ＬＩＮＥＩＴＥＭＳは、“Lineitems＿t”の型である。列ＰＯＮＯおよびＬＩＮＥＩＴＥＭＳは、各々、値の単一の行、つまり、パーチェスオーダ番号「１０１」と、パーチェスオーダ番号「１０１」に関連したライン項目の集合とを含むとさらに仮定する。ライン項目の集合内には、１項目、つまり、「ブック」が存在すると仮定する。

“SELECT * FROM PurchaseOrder＿table”等のＳＱＬクエリーは、以下のＸＭＬ結果セットにマッピングするＳＱＬ結果セットを生成する。

オブジェクト関係列ＬＩＮＥＩＴＥＭＳは、ＸＭＬ結果セット内の同じタグ名を有するエレメントにマッピングする。ＬＩＮＥＩＴＥＭＳ内の各集合項目は、ＬＩＮＥＩＴＥＭＳエレメント内に埋込まれるサブエレメントにマッピングされる。各集合項目は、タグ名としての集合型名、つまり、“ＬＩＮＥＩＴＥＭ＿Ｔ”を有する。各集合項目は、エレメントＬＩＮＥＩＴＥＭ＿Ｔ内に埋込まれるサブエレメントにマッピングされる属性ＬＩＮＥＩＴＥＭＮＡＭＥおよびＣＯＳＴを有する。各サブエレメントは、その対応するタグ名としての属性名、たとえば、＜ＬＩＮＥＩＴＥＭＮＡＭＥ＞、および＜ＣＯＳＴ＞を有する。

ｄ）ＵＲＩ参照へのオブジェクト関係ＲＥＦ型のマッピング
オブジェクト関係ＲＥＦ列は、いずれかのオブジェクト関係表内に含まれる行オブジェクトへのオブジェクト参照を記憶するための列である。説明のために、関係データベースは、Employee＿tableと呼ばれる表を有すると仮定する。Employee＿tableは、列ＥＭＰＴＮＯ、ＥＮＡＭＥ、およびＤＥＰＴＲＥＦを有する。ＥＭＰＮＯは、「番号」の型であり、ＥＭＰＮＯは値「１５」の１つの行のみを有すると仮定する。ＥＮＡＭＥは、「ストリング」の型であり、ＥＮＡＭＥは値「ジョン」の１つの行のみを有すると仮定する。ＤＥＰＴＲＥＦは、“ＲＥＦ”の型であり、ＤＥＰＴＲＥＦは値の１つの行のみを有し、これは、Department＿tableと呼ばれる別の表内のＤＥＰＴＮＯ＝１００１に対応する値の行への参照であることを仮定する。Department＿tableは、スキーマＳＣＯＴＴ内にあり、値「１００１」を備えた列ＤＥＰＴＮＯと値“ＳＰＯＲＴＳ”を備えた列ＤＥＰＴＮＡＭＥとを有すると仮定する。

“SELECT EMPNO, DEPTREF FROM Employee-table”等のＳＱＬクエリーは、以下のＸＭＬ結果セットにマッピングするＳＱＬ結果セットを生成する。

この発明の特定の実施例に従うと、オブジェクト関係ＲＥＦ値を、１６進法（“ＨＥＸ”）でエンコードされるバイナリ値に変換することによって、ＤＥＰＴＲＥＦ列内のＲＥＦ値は、ＸＭＬ結果セットのためのＸＭＬの形に変換される。したがって、上のＸＭＬ結果セットでは、「０３４４８５５ＦＦ４ＡＢＢＣＣ３３３３」が、エンコードされたＨＥＸである。

この発明の他の特定の実施例に従うと、ＲＥＦ値をデータベースユニフォームリソースインディケータ（“ＤＢＵＲＩ”）参照へと変換することによって、ＤＥＰＴＲＥＦ列内のＲＥＦ値は、ＸＭＬの形に変換される。ＤＢＵＲＩ参照は、発明者としてムラリダールクリシュナプラサド、ビスワナサンクリシュナマーシー、ラビマーシーを挙げる「データベースデータおよびメタデータに対する関係データベースおよびユニバーサルリソース識別子のＸＭＬビジュアライゼーションのための方法および装置」と題された米国特許出願第号、代理人事件整理番号５０２７７‐１５６４で詳細に説明される。

上の同じ例を用いると、ＤＢＵＲＩ参照は、SCOTT/DEPARTMENT＿TABLE/ROW［DEPTNO=“1001”］として現われ得、Deptnoは、主要なキー情報である。したがって、ＸＭＬ結果セットは、以下として現われ得る。

この発明のさらなる他の実施例に従うと、ＲＥＦ列に記憶されるオブジェクトを独自に識別するオブジェクト識別子は、ＤＢＵＲＩ参照を生成するときに用いられ得る。上の同じ例を用いて、ＤＢＵＲＩ参照は、以下として現われ得る。

したがって、ＸＭＬ結果セットは、以下のように現われ得る。

この発明の実施例に従うと、ＬＯＢ値もＤＢＵｒｉ参照に変換され得る。たとえば、ＤＥＰＴ＿ＰＨＯＴＯと呼ばれる部門表内に列が存在し、これがＢＬＯＢ列ならば、ＤＢＵｒｉ参照が用いられて、ＸＭＬドキュメント内でＢＬＯＢデータをインラインする代わりに、ＢＬＯＢデータが参照され得る。

ＸＭＬ結果は、ＤＥＰＴ＿ＰＨＯＴＯ列に対して以下のように現われ得る。

この発明は、ＬＯＢおよびＲＥＦへのＤＢＵｒｉ参照を生成することに限定されない。ＤＢＵｒｉ参照は、ビジュアライズされたドキュメント内でインラインされなくてもよいデータベースデータのいずれかの部分を参照するために生成され得る。たとえば、ネストにされた表、ＬＯＮＧ、および他のデータ型は、ビジュアライズされたドキュメント内で全データをインラインする代わりに、ＤＢＵｒｉ参照に変換され得る。ＤＢＵｒｉ参照は、Xpath表記の述語内で行のＲＯＷＩＤまたは主要なキー情報を用いることによって、生成され得る。

関係データベーススキーマのマッピング
関係データベーススキーマは、関係データベーススキーマをそれらの対応するＸＭＬスキーマにマッピングすることによって、ＸＭＬの形にマッピングされる。たとえば、図３Ａを参照して、単一の行３０２でＥＭＰＮＯおよびＥＮＡＭＥを選択するためのＳＱＬクエリーのＸＭＬ結果セットを生成するために、ＸＭＬスキーマが生成される。ＸＭＬスキーマは、ＸＭＬ結果セットの構造を定義し、これは、ＸＭＬドキュメントの形である。したがって、単一の行３０２でＥＭＰＮＯおよびＥＮＡＭＥを選択するためのＳＱＬクエリーのＸＭＬ結果セットに対応するＸＭＬスキーマは、この発明の特定の実施例に従うと、以下のとおりである。

上の例からわかるように、ＸＭＬ結果セット（ＸＭＬドキュメント）の構造を定義することに加えて、ＸＭＬスキーマはまた、もしあれば、データ上の制約およびデータの型を定義する。たとえば、上のサンプルＸＭＬスキーマは、特に、以下を示す。すなわち、１）すべてのＸＭＬスキーマに適用される規格を定義するネーム空間のためのＵＲＬ、つまり、http://www.w3.org/2000/10/XMLSchema、２）エレメントＲＯＷＳＥＴが、「複合体」型であり、ＲＯＷエレメントを含むこと、３）ＲＯＷエレメントが、「複合体」型であり、ＸＭＬドキュメント内で任意の回数だけ起こり得ること、３）ＲＯＷエレメント内に埋込まれるエレメントＥＭＰＮＯは「整数」型であること、４）ＲＯＷエレメント内に埋込まれるエレメントＥＮＡＭＥは、「ストリング」型であること、を示す。空白許可（nullable）属性は、エレメント値がＮＵＬＬであり得るか否かを示す。“MinOccurs”は、結果として得られるドキュメント内でのこのエレメントの発生の最小の回数を示す。

代替的には、ＸＭＬスキーマは、その対応するＸＭＬ結果セット（ＸＭＬドキュメント）内で「インライン」され得る。たとえば、図３Ａを参照して、単一の行３０２でＥＭＰＮＯおよびＥＮＡＭＥを選択するためのＳＱＬクエリーのＸＭＬ結果セットは、この発明の特定の実施例に従うと、以下のようにＸＭＬ結果セット内でその対応のＸＭＬスキーマをインラインし得た。

ＸＭＬネーム空間
ある所与の関係データベーススキーマに関連したオブジェクト関係データ型定義は、対応のＸＭＬネーム空間に結合(bound)され得る。ＸＭＬネーム空間は、ＸＭＬドキュメント内でエレメント型および属性名として用いられる名前の集合である。ＸＭＬネーム空間は、ＵＲＬによって定義され得る。たとえば、ここで説明されるように、関係データベースはユーザによって定義される型“Address＿t”を有し、これは、３つのスカラ属性、つまり、ＣＩＴＹ、ＳＴＡＴＥ、およびＺＩＰを含む複雑なオブジェクト型であると仮定する。説明のために、複雑なオブジェクト型“Address＿t”は関係データベーススキーマＳＣＯＴＴ内で定義されると仮定する。したがって、“Address＿t”は、たとえば、ＵＲＬ, http://ora.com/SCOTTによって定義されるＸＭＬネーム空間に結合され得る。

ＸＭＬスキーマは、異なるＸＭＬネーム空間からのオブジェクト関係型を含み得る。例示のために、関係データベーススキーマＦＯＯおよび関係データベーススキーマＰＥＥが生成されると仮定する。さらに、関係データベーススキーマＦＯＯは、AddressTypeと呼ばれる、ユーザによって定義される型を含み、関係データベーススキーマＰＥＥは、NameTypeと呼ばれる、ユーザによって定義される型を含むことが仮定される。AddressTypeは、３つのスカラ属性、つまり、ＣＩＴＹ、ＳＴＡＴＥ、およびＺＩＰを含む。NameTypeは、２つのスカラ属性、つまり、ＦＩＲＳＴＮＡＭＥおよびＬＡＳＴＮＡＭＥを含む。オブジェクト関係表ＥＭＰ２が生成されることが仮定される。ＥＭＰ２は、２つの列、つまり、ＥＮＡＭＥおよびＥＡＤＤＲを有する。ＥＮＡＭＥは、従業員名「ジェームスボンド」を含み、NameTypeの型である。ＥＡＤＤＲは、ジェームスボンドのアドレスを含み、AddressTypeの型である。

以下のＳＱＬステートメントは、関係データベース内のＥＭＰ２、NameType、AddressType、データベーススキーマＰＥＥ、およびデータベーススキーマＦＯＯの生成を例示する。

表ＥＭＰ２では、列ＥＮＡＭＥは、関係データベーススキーマＰＥＥのために定義されるNameTypeを用い、列ＥＡＤＤＲは、関係データベーススキーマＦＯＯのために定義されるアドレス型を用いる。

したがって、ＳＥＬＥＣＴ*ＦＲＯＭＥＭＰ２等のＳＱＬクエリーのＸＭＬ結果セットに対応するＸＭＬスキーマは、ＦＯＯおよびＰＥＥのためのＸＭＬネーム空間を定義する別個のＵＲＬを含む。ＦＯＯのためのＸＭＬネーム空間は、AddressTypeのための定義を含む。ＰＥＥのためのＸＭＬネーム空間は、NameTypeのための定義を含む。

ＳＥＬＥＣＴ*ＦＲＯＭＥＭＰ２等のＳＱＬクエリーのＸＭＬ結果セットに対応するＸＭＬスキーマは、この発明の特定の実施例に従うと、以下のとおりである。

代替的には、ＸＭＬスキーマは、目標データ、つまり、ＥＭＰ２内の従業員のアドレスおよび名前を含むその対応するＸＭＬ結果セット内で「インライン」され得る。この発明の特定の実施例に従うと、ＸＭＬ結果セットは、「インライン」されるその対応するＸＭＬスキーマを示す。

ＸＭＬデータおよびＳＱＬデータの一様な処理
典型的には、関係データベース内には、予め定義された関係データ型が存在する。典型的な予め定義された関係データ型の例は、数、日付、およびストリング等である。オブジェクト関係データベースはまた、ユーザによって定義されるオブジェクト型を含み得る。しかし、ＸＭＬデータおよびＳＱＬデータの一様な処理を提供するために、XMLTypeと呼ばれるデータ型が、関係データベースシステム内でもともと定義される。XMLTypeデータ型は、構造化ＸＭＬデータであっても、非構造化ＸＭＬデータであっても、いずれの型のＸＭＬデータも記憶するために用いられ得る。

図４は、XMLType記憶アーキテクチャを例示したブロック図である。ブロック４０２は、ブロック４０６で示されるXMLTypeを用いて記憶されるべきＸＭＬデータである。XMLTypeは、ＸＭＬデータのための基礎をなす記憶メカニズムを含む。記憶メカニズムのうちのいくつかが、記憶層４１４で示される。記憶層４１４では、ＬＯＢ記憶メカニズム４０８、オブジェクト関係記憶メカニズム４１０、および「他の」記憶メカニズム４１２が示される。「他の」記憶メカニズム４１２は、ＸＭＬデータのためのいずれかの適切な記憶メカニズムであり得る。したがって、記憶層４１４内の記憶メカニズムは、ＸＭＬデータのための記憶メカニズムの、余すところのないセットを含むわけではない。XMLTypeは、基礎をなす記憶メカニズムを含むため、ＸＭＬデータのユーザは、XMLTypeを見るのみであり、ＸＭＬデータの基礎をなす記憶メカニズムの実際の詳細は、ユーザから隠れている。典型的には、関係データベースシステムの管理者は、記憶されるべきＸＭＬデータのための基礎をなす記憶メカニズムを選択する。管理者は、記憶メカニズムの性能詳細事項に基づいて、基礎をなす記憶メカニズムのタイプを選択する。

記憶を示すために、ある所与のＸＭＬドキュメントのフィールドのうちのいくつかは、構造化データを含み得る。構造化データは、関係データベース内の関係列にマッピングされ得るデータである。別の例では、ＸＭＬドキュメントは、全ブックのテキストコンテントを含むと仮定する。ＸＭＬドキュメントのあらゆるエレメントまたはフィールドを関係列にマッピングすることによってこのようなＸＭＬドキュメントを広げる(explode)のではなく、ユーザが照会しそうなデータを含むフィールドのみが、ストリング、番号等の予め定義された関係型にマッピングされ、残りのデータは、まとめられ、キャラクタラージオブジェクト（ＣＬＯＢ）のための１つの列にマッピングされる。ユーザは、ユーザ自身のテンプレートを生成してどのフィールドが関係列にマッピングされるべきか、およびどのフィールドがＣＬＯＢにマッピングされるべきかを特定し得る。

図５は、XMLType列の構造を例示したブロック図である。列５０４は、構造化データを含むＸＭＬドキュメントを含んだXMLType列である。構造化データのフィールドは、隠し列５０６にマッピングされる。たとえば、ＸＭＬドキュメントのＰＯＮＯエレメントは、ＮＵＭＢＥＲ列にマッピングされ、ＰＮＡＭＥはストリング列にマッピングされる。図５では、網掛けされたエリアは、列がユーザからは見えないように隠されていることを示す。ユーザは、単一のXMLType列を見るのみである。

一様なクエリーインターフェイス
この発明の特定の実施例に従うと、関連データベース内に記憶されるXMLTypeデータ上の動作のコアセットを定義するために、一様なクエリーインターフェイスが提供される。このような動作は、基礎をなす記憶フォーマットからは独立している。この発明の特定の実施例に従うと、XMLTypeデータ上の動作は、以下のように機能的に要約される。

１）ある所与のＸＭＬドキュメントのフラグメントの抽出
２）ＸＭＬドキュメント内の特定の構造の存在のテスト
３）ＸＭＬドキュメント内の特定のデータ値の抽出
４）ある所与のＸＭＬドキュメントの変換
上の動作リストは、XMLTypeデータのための余すところのない動作リストというわけではない。動作のいくつかを例示するために、“Ｘ”と呼ばれるＸＭＬドキュメントがパーチェスオーダデータを含むと仮定する。パーチェスオーダデータは、値「２１」を備えたパーチェスオーダ番号“ＰＯＮＯ”、値“ＪＯＨＮ”を備えたパーチェスオーダネーム“ＰＮＡＭＥ”、およびライン項目の集合を含み、以下のように現われる。

したがって、この発明の特定の実施例に従うと、ＸＭＬドキュメント“Ｘ”のフラグメントを抽出するための動作の例は、以下のとおりである。

EXTRACT (X,‘PO/LINEITEM’)
上の動作は、ドキュメントＸのフラグメントを抽出し、フラグメントは、ＬＩＮＥＩＴＥＭ下のすべてのブランチから構成されるサブツリーである。

ＸＭＬドキュメント“Ｘ”内の特定のデータ値を抽出するための動作の例は、以下のとおりである。

EXTRACTVALUE (X,‘PO/PNAME’)
上の動作は、ＰＮＡＭＥ内のスカラ値、つまり、“ＪＯＨＮ”を抽出する。

ＸＭＬドキュメント“Ｘ”内での特定のエレメントの存在のテストのための動作例は、以下のとおりである。

EXISTSNODE (X,‘PO/［PONO=21］’)
上の動作は、値が２１であるＰＯＮＯと呼ばれる子を有する、ＰＯと呼ばれるエレメントをＸＭＬドキュメント“Ｘ”が有するかをテストする。

ＸＳＬスタイルシートを用いてＸＭＬドキュメントを変換するための動作例は、以下のとおりである。

TRANSFORM (X,‘<xs1>......stylesheet.....</xs1>’)
上の動作は、ＸＭＬドキュメントの基礎をなす記憶フォーマットに関して、全く寛容である。

クエリー再書込
この発明の特定の実施例に従うと、関係データベース内の基礎をなす記憶メカニズムのデータアクセスおよびデータ操作能力を活用する形へとユーザクエリーを再書込みするためのメカニズムが提供される。

ある所与のＸＭＬドキュメントの構造化データのフィールドは、フィールド内のデータがユーザによって頻繁に照会されるようであれば、別個の関係列にマッピングされ得る。たとえば、ＸＭＬドキュメントのフィールドのうちの１つが従業員名を含み、ユーザが従業員名の値をもとにしてＸＭＬドキュメントを頻繁に照会することが予想されると仮定する。これらの条件下では、従業員名は、ＸＭＬドキュメントそれ自体を記憶する列とは別のＥＮＡＭＥと呼ばれる関係列に記憶され得る。ＸＭＬユーザが、ある特定の従業員の名前に基づいてクエリーをサブミットしてＸＭＬドキュメントにアクセスすると、ＸＭＬユーザのクエリーは、自動的に再書込みされてＥＮＡＭＥ列のみにアクセスする。

対照的に、クエリー再書込メカニズムが提供されず、従業員名が別個の列に記憶されないならば、ＸＭＬユーザがある特定の従業員の名前に基づいてクエリーをサブミットしてＸＭＬドキュメントにアクセスする場合、ＸＭＬドキュメントをパーズすることによって、ドキュメントオブジェクトモデル（ＤＯＭ）が各ＸＭＬドキュメントに対して生成される。次に、適切なＸＰＡＴＨ表記を適用することによって、ＤＯＭ上で従業員名に対して探索が行なわれる。ＤＯＭを生成し、次にＤＯＭ上で探索を行なうことは、明らかに、より効率性に欠ける。

別の例では、関係データベースの既存のインデックス付け能力を用いてＸＭＬユーザのクエリーを満足させる。データが頻繁に照会されることが予想されるならば、データは、別個の関係列に記憶され得、Ｂツリーインデックスが、その列上で構築され得る。次に、ＸＭＬユーザクエリーがサブミットされて、たとえば、ＰＯＮＯ＝２１である行が選択されるならば、ＰＯＮＯ列上のＢツリーインデックスを用いて、ＰＯＮＯ列内で値２１を有するＸＭＬドキュメントを含む行が識別され得る。同様に、ＸＭＬドキュメントがＬＯＢとして記憶されるならば、テキストインデックスを用いてＬＯＢ列上での探索が最適化され得る。

関係データベース内のＸＭＬドキュメントの記憶に関連したマッピング情報およびユーザのＸＭＬクエリーに基づいて、データベースクエリー、たとえば、ＳＱＬクエリーを生成するためのメカニズムがデータベース内で提供される。

図５を参照して、図５の表はＰＯ‐ＴＡＢＬＥと呼ばれ、Ｂツリーインデックスは関係列ＰＯＮＯ上で生成されると仮定する。ＸＭＬユーザが以下のクエリーをサブミットすると仮定する。

SELECT * From PO-TABLE
Where EXISTNODE (PO-XML,‘/PO［PONO=21］’)
この発明の特定の実施例に従うと、上のＸＭＬユーザのクエリーは、以下へと変換される。

SELECT * From PO-TABLE
Where PO-XML .PONO=21
したがって、インデックス探索は、ＰＯＮＯの述語に対して行われ得る。

ハードウェア
図６は、この発明の実施例が実現され得るコンピュータシステム６００を例示したブロック図である。コンピュータシステム６００は、情報の通信を行なうためのバス６０２または他の通信メカニズム、および、情報を処理するための、バス６０２に結合されるプロセッサ６０４を含む。コンピュータシステム６００はまた、プロセッサ６０４によって実行されるべき情報および命令の記憶のための、バス６０２に結合されるランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置等のメインメモリ６０６を含む。メインメモリ６０６はまた、プロセッサ６０４によって実行されるべき命令の実行中に一時変数または他の中間情報を記憶するために用いられ得る。コンピュータシステム６００はさらに、プロセッサ６０４のための命令および静的情報を記憶するための、バス６０２に結合される読出専用メモリ（ＲＯＭ）６０８または他の静的記憶装置を含む。磁気ディスクまたは光学ディスク等の記憶装置６１０が、設けられ、情報および命令を記憶するためにバス６０２に結合される。

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

この発明は、ここで説明される技術を実現するためのコンピュータシステム６００の用途に関連する。この発明の１つの実施例に従うと、これらの技術は、メインメモリ６０６内に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ６０４が実行することに応答して、コンピュータシステム６００によって実現される。このような命令は、記憶装置６１０等の別のコンピュータ読出可能な媒体からメインメモリ６０６へと読出され得る。メインメモリ６０６内に含まれる命令シーケンスの実行によって、プロセッサ６０４がここで説明されるプロセスステップを実行させられる。多重処理構成における１つ以上のプロセッサを用いてメインメモリ６０６内に含まれる命令シーケンスを実行することもできる。代替的な実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せてハードワイヤード回路を用いてこの発明を実現することもできる。したがって、この発明の実施例は、ハードウェア回路とソフトウェアとの特定のいずれかの組合せに限定されない。

ここで用いられるような用語「コンピュータ読出可能な媒体」は、実行のために命令をプロセッサ６０４に提供するいずれかの媒体を指す。このような媒体は、不揮発性媒体、揮発性媒体、および送信媒体を含むがそれらに限定されない多くの形をとり得る。不揮発性媒体は、たとえば、記憶装置６１０等の光学ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ６０６等のダイナミックメモリを含む。送信媒体は、バス６０２を含むワイヤを含んだ、同軸ケーブル、銅ワイヤ、および光ファイバを含む。送信媒体はまた、電波および赤外線データ通信中に生成されるような音波または光波の形をとり得る。

コンピュータ読出可能な媒体の一般的な形は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または他のいずれかの磁気媒体、ＣＤ−ＲＯＭ、他のいずれかの光学媒体、パンチカード、ペーパーテープ、ホールパターンを備えた他のいずれかの物理的な媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、他のいずれかのメモリチップまたはカートリッジ、以下で説明されるような搬送波、またはコンピュータが読出可能な他のいずれかの媒体を含む。

種々の形のコンピュータ読出可能な媒体は、実行のために１つ以上の命令の１つ以上のシーケンスをプロセッサ６０４に搬送することに関与し得る。たとえば、命令は、最初リモートコンピュータの磁気ディスク上で搬送され得る。リモートコンピュータは、命令をそのダイナミックメモリにロードし、モデムを用いて電話線上で命令を送信し得る。コンピュータシステム６００にとってローカルなモデムは、電話線上のデータを受信し、赤外線トランスミッタを用いてデータを赤外線信号に変換し得る。バス６０２に結合される赤外検出器が、赤外線信号で搬送されたデータを受信し、データをバス６０２上に置き得る。バス６０２は、データをメインメモリ６０６へと搬送し、ここから、プロセッサ６０４は命令を取出し、実行する。メインメモリ６０６が受取る命令は、任意で、プロセッサ６０４による実行の前に、またはその後に、記憶装置６１０上に記憶され得る。

コンピュータシステム６００はまた、バス６０２に結合される通信インターフェイス６１８を含む。通信インターフェイス６１８は、ローカルネットワーク６２２に接続されるネットワークリンク６２０に結合される双方向データ通信を提供する。たとえば、通信インターフェイス６１８は、統合サービスデジタル通信網（ＩＳＤＮ）カードまたはモデムであってデータ通信接続を対応する種類の電話線に提供し得る。別の例として、通信インターフェイス６１８は、ローカルエリアネットワーク（ＬＡＮ）カードであってデータ通信接続を適合したＬＡＮに提供し得る。ワイヤレスリンクも実現され得る。このようないずれの実現例でも、通信インターフェイス６１８は、種々の種類の情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送受信する。

ネットワークリンク６２０は、典型的には、１つ以上のネットワークを通して他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク６２０は、ローカルネットワーク６２２を通してホストコンピュータ６２４へと、またはインターネットサービスプロバイダ（ＩＳＰ）６２６によって動作されるデータ装置へと、接続を提供し得る。ＩＳＰ６２６は、次に、現在「インターネット」６２８と通例呼ばれるワールドワイドパケットデータ通信ネットワークを通してデータ通信サービスを提供する。ローカルネットワーク６２２およびインターネット６２８の両方は、デジタルデータストリームを搬送する電気信号、電磁信号、または光信号を用いる。コンピュータシステム６００へと、およびコンピュータシステム６００からデジタルデータを搬送する、ネットワークリンク６２０上にあり通信インターフェイス６１８を通る信号および種々のネットワークを通る信号は、情報を運ぶ搬送波の例示的な形である。

コンピュータシステム６００は、ネットワーク、ネットワークリンク６２０、および通信インターフェイス６１８を通して、プログラムコードを含むメッセージを送信し、プログラムコードを含むデータを受信し得る。インターネットの例では、サーバ６３０は、インターネット６２８、ＩＳＰ６２６、ローカルネットワーク６２２、および通信インターフェイス６１８を通して、アプリケーションプログラムのための要求されたコードを送り得る。この発明に従うと、アプリケーションをダウンロードしたものが、ここで説明される技術を実現する。

受信されたコードは、それが受信される時にプロセッサ６０４によって実行され得、および／または、後の実行のために記憶装置６１０に、または他の不揮発性記憶装置に記憶され得る。この様態で、コンピュータシステム６００は、搬送波の形のアプリケーションコードを得ることができる。

上の明細書では、この発明は、その具体的な実施例を参照しながら説明された。しかし、この発明のより広い思想および範囲から逸脱することなく、この発明に対して種々の変形および変更が可能であることは明らかであろう。したがって、明細書および図は、限定的な意味ではなく例示的な意味で理解されるべきである。

Claims

関係データベース内のデータを管理するための方法であって、
前記関係データベースでの記憶のためにＸＭＬドキュメントをデータベースサーバで受信するステップと、
前記データベースサーバが、前記関係データベース内の対応する列への、ＸＭＬドキュメント内の１つ以上のフィールドのマッピングを表すマッピング情報を、前記関係データベースに記憶するステップと、
前記データベースサーバが、前記ＸＭＬドキュメントからのデータを、もともとのデータ型の１つ以上のインスタンスとして、前記関係データベース内において、前記マッピング情報に基づいて前記データベースサーバによって決定される場所に記憶するステップとを含み、
前記もともとのデータ型は、前記データベースサーバに固有であり、前記データベースサーバによってサポートされるＸＭＬデータのための複数の記憶メカニズムを含み、
前記方法はさらに、
前記データベースサーバが前記ＸＭＬドキュメントからのデータの要求を受信することに応答して、前記データベースサーバが、前記マッピング情報を調べて、前記ＸＭＬドキュメントからのデータにどのようにアクセスすべきかを決定するステップを含む、方法。
データを記憶するステップは、
前記ＸＭＬドキュメントの複数のフィールドのための値を関係表の第１の列に記憶するステップと、
前記ＸＭＬドキュメントの少なくとも１つのフィールドのための値を、前記関係表の第２の列に記憶するステップとを含み、第２の列は前記第１の列とは異なる、請求項１に記載の方法。
データの要求は、ＸＭＬクエリーである、請求項１に記載の方法。
前記ＸＭＬクエリーおよび前記マッピング情報に基づいてデータベースクエリーを生成するステップと、
前記データベースクエリーを実行して前記ＸＭＬドキュメントからのデータにアクセスするステップとをさらに含む、請求項３に記載の方法。
前記データベースクエリーは、基礎をなす関係列に直接アクセスし、テキストインデックスであるインデックスを用いる、請求項４に記載の方法。
前記ＸＭＬドキュメントの構造は、構造化データの１つ以上のフィールドを含むようにユーザによって定義されており、構造化データは、前記関係データベース内の既存の関係データオブジェクト型に対応する型であるデータである、請求項１に記載の方法。
ＸＭＬドキュメントの構造は、非構造化データの１つ以上のフィールドを含むようにユーザによって定義されており、非構造化データは、前記関係データベースでの記憶のために前記ＸＭＬドキュメントの処理中に前記関係データベース内のＬＯＢデータ型にマッピングされるデータである、請求項１に記載の方法。
前記マッピング情報は、ユーザによって定義される、請求項１に記載の方法。
一組の操作が、前記もともとのデータ型のために、前記データベースサーバによって定義される、請求項１に記載の方法。
前記マッピング情報は、前記ＸＭＬドキュメントのフィールドを関係表の複数の列にマッピングし、
前記ＸＭＬドキュメントからのデータを記憶するステップは、前記ＸＭＬドキュメントの前記フィールドを解析して複数の値を識別するステップと、前記複数の値の各々を前記関係表の前記複数の列のうちの異なる１つ１つに記憶するステップとを含む、請求項１に記載の方法。
前記要求は、前記ＸＭＬドキュメントのフィールドのための基準を特定し、
前記方法は、以下のステップを行なうことによって前記基準が満たされているかを判断するステップを含み、前記以下のステップは、
前記マッピング情報に基づいて、前記フィールドが、ある特定の列にマッピングされる複数のフィールドのうちの１つであることを判断するステップと、
前記特定の列内のデータを解析して前記ＸＭＬドキュメントのための前記フィールドの値の位置を特定するステップと、
前記値が基準を満たすかを判断するステップとを含む、請求項１に記載の方法。
前記関係データベース内の１つ以上のフィールドは、前記関係データベース内の１つ以上のフィールドを２つ以上含む、請求項１に記載の方法。
１つ以上のプロセッサによって実行されると１つ以上のプロセッサに請求項１〜１２のいずれかに記載の方法を実行させる１つ以上の命令シーケンスを格納している、コンピュータ読み取り可能な記録媒体。