JP3756407B2

JP3756407B2 - ユーザ定義データ型のデータ項目を扱うための方法

Info

Publication number: JP3756407B2
Application number: JP2000569332A
Authority: JP
Inventors: ゴビンダラジャン，ラジャゴパラン; クリシナマーシー，ビスワナサン; ノリ，アニル
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 1998-09-08
Filing date: 1999-09-03
Publication date: 2006-03-15
Anticipated expiration: 2019-09-03
Also published as: JP2002524801A; HK1036335A1; CA2340739A1; US6470348B1; US6286015B1; DE69932524T2; AU5801999A; EP1112543A1; CA2340739C; DE69932524D1; AU757734B2; WO2000014656A1; EP1112543B1

Description

【０００１】
【発明の分野】
この発明は、データベースシステムに関し、より特定的には、データベースシステム内のユーザ定義データ型の使用に関する。
【０００２】
【発明の背景】
典型的には、データ項目は、揮発性メモリに記憶されるのとは異なった態様で不揮発性メモリに記憶される。すなわち、不揮発性メモリから揮発性メモリにロードする際、何らかの変換動作を行なわなければならない。同様に、揮発性メモリから不揮発性メモリに逆に記憶される際、別の変換動作を行なわなければならない。説明の目的のため、ここでは、データを揮発性フォーマットから不揮発性フォーマットに変換するプロセスを、データ項目を「ピクリング」すると称し、データを不揮発性フォーマットから揮発性フォーマットへ変換するプロセスを、データ項目を「アンピクリング」すると称する。
【０００３】
数多くの従来のリレーショナルデータベースシステムでは、自動ピクリングおよびアンピクリングは数少ないデータの型に対してしか行なわれない。このようなシステムがサポートするデータの型は典型的に、数および日付などのスカラー型を含む。「Ｃ」および「Java」などの他のプログラミング環境に関連して、典型的なデータベースシステムがサポートするデータ型の組は非常に限られている。このため、これらの他の環境において書かれたコンピュータプログラムによって生成され用いられるデータを記憶するのにそのデータベースシステムが用いられる際に困難が生じる。
【０００４】
たとえば、あるユーザは、複雑なユーザ定義のデータ型（「TYPE1」）を用いてデータを表わし操作する１組のルーチンを作成し得る。例示の目的のため、TYPE1を用いるユーザ実装のルーチンはここで集合的にAPP1と称する。
【０００５】
TYPE1の構造またはそのいずれの属性も、データベースシステム（「DBS1」）がサポートするどのデータ型の構造とも大幅に異なるものであり得る。APP1によって用いられるデータをDBS1が管理するデータベースに渡すためには、すべてのTYPE1データ項目を、DBS1がサポートするデータ型の１つ以上のインスタンスに変換しなければならない。一旦、データを、DBS1が理解しサポートするデータ型に変換すると、DBS1はデータを記憶しディスクから取出すことができる。同様に、APP1がDBS1からのデータを使用するには、そのデータを、DBS1がサポートするデータ型に関連付けられた構造からTYPE1に関連付けられた構造およびフォーマットに変換しなければならない。
【０００６】
図１を参照して、この図はAPP1がそのデータをDBS1内に記憶することを可能にするために行なわれなければならない変換動作を示すブロック図である。特定的には、APP1内で生成されるデータ項目はユーザTYPE1の構造およびフォーマットに従って記憶される。データ項目を記憶するためにDBS1に渡すためには、そのデータ項目はDBS1がサポートするデータ型（DBTYPE1）に変換される。DBS1内の揮発性メモリにある間、データ項目はアンピリングされたDBTYPE1として記憶される。DBS1はDBTYPE1データ項目をディスクに記憶するためにこれをピクリングする。
【０００７】
ディスクに記憶されるデータ項目をAPP1に供給するため、DBS1はデータ項目をアンピクリングしてアンピクリングされたDBTYPE1データ項目を作成する。アンピクリングされたDBTYPE1データ項目は次に、そのデータ項目を操作するAPP1内のルーチンに供給される前に、ユーザTYPE1データ型に変換される。
【０００８】
ユーザ定義型の一例は以下のように宣言される型である。
struct TYPE1
｛
int i;
char ^*s;
｝
この宣言はたとえば、APP1のソースコード内で生じ得る。APP1のソースコードはまた、TYPE1データ構造内に記憶されるデータを操作するのに用いられる１つ以上のメソッドを含む。このようなメソッドに対するインターフェイスの一例は以下のとおりである。
【０００９】
my＿method(TYPE1 ^*me, int i);
TYPE1データ項目は、TYPE1の属性を、NumberおよびDateなどのDBS1がサポートするデータ型にマッピングすることによってDBS1内へ受渡してもよい。TYPE1データ項目からデータを記憶するためのデータベースオブジェクトを作成するためのステートメントの一例は以下のとおりである。
【００１０】
create type DBTYPE1 as OBJECT
(
a Number;
b Date;
memberprocedure.set＿date();
)
APP1によって用いられるTYPE1構造とDBS1内においてTYPE1データを記憶するため用いられるDBTYPE1構造との間でデータを変換するために、以下の構造体を用いてもよい。
【００１１】
struct
｛
OCINumber n;
OCIDate d;
｝
この例では、TYPE1の属性がDBS1によってサポートされるデータ型によって十分に表わすことができることを仮定している。しかしながら、一般的なプログラム言語（ＣまたはJavaなど）において設計され実現されるデータ型は、データベースシステムによって容易に取得されるものではない。なぜなら、これらの内部構造はその言語のある特定の構造構文を用いてモデリングされており、データベースシステムによっては理解されないためである。
【００１２】
オブジェクト指向データベースは、ある特定のプログラム言語に強く結合されており、それらのためにその言語におけるデータ型のモデリングを行なうことが可能であるとしても、データベースシステムにおける言語中立性という柔軟性が損なわれる。たとえば、APP1を作成するのに用いられた言語と同じ言語を中心にDBS1が設計された場合、DBS1はTYPE1データ型をサポートし得る。しかし、他方で、APP1を作成するのに用いられた言語とは異なる言語を中心にDBS1が設計された場合、依然として複雑な変換が必要であり得る。
【００１３】
データベースシステムがサポートするデータ型に密接に対応していない属性を有するユーザ定義型を変換することに関連する負担を軽減するため、いくつかのデータベースシステムでは「RAW」データ型をサポートしている。データベースシステムの観点からは、RAWデータ項目とは構造を有さない単なるバイトの塊である。データベースによりサポートされる他のデータ型と同様に、RAWデータ項目は、関係表の列に記憶できる。データベースシステムはRAWデータ項目に対して何ら構造を想定していないため、RAWデータ項目は、データベースシステムがサポートするいずれのデータ型にも容易に変換されない属性を有する複雑なユーザ定義のデータ型に対するデータを記憶するのに用いることができる。
【００１４】
以下のステートメントにより、たとえばTYPE1データ項目からのデータを記憶するために用いることができるRAW列を有する表が作成される。
【００１５】
create table t
(coll raw(20),...);
以下のステートメントにより、外部my＿methodルーチンを呼出すための、データベースの内部のルーチンが作成される。
【００１６】
create procedure mymethod(a IN RAW)
この内部ルーチンに対する入力はRAWデータ項目であるが、外部my＿methodはTYPE1データ項目を想定している。したがって、mymethod手続きのインプリメーションは以下の形をとらなければならない。
【００１７】
mymethod(a)
｛
raw-to-struct(a)
manipulate
struct-to-raw(a)
｝
この例では、mymethodルーチンはRAWデータ項目「ａ」を受ける。raw-to-struct(a)ステートメントは、データベースによってデータ項目を記憶するのに用いられるRAWフォーマットからAPP1によって用いられるTYPE1フォーマットにデータ項目を変換するユーザ供給のルーチンを呼出す。「manipulate」ステートメントは、TYPE1データ項目を操作するユーザ供給ルーチンに対するコールを一般的に表わす。データ項目に対して所望の演算が行なわれた後、struct-to-raw(a)に対するコールにより、データ項目をTYPE1構造からデータベースによって用いられるRAWフォーマットに変換して戻す。
【００１８】
図２を参照して、APP1がそのデータをRAWデータ型をサポートするデータベース（DBS1）内に記憶するのを可能にするために行なわなければならない変換動作を示すブロック図が示される。特定的には、APP1内で生成されるデータ項目は、「user type1」に従ってフォーマット化される。データ項目を記憶するためにDBS1内に渡すために、データ項目はRAWデータ型に変換される。DBS1内の揮発性メモリ内にある間、データ項目はアンピクリングされたRAWデータとして記憶される。DBS1はそのRAWデータをピクリングしてこれをディスクに記憶する。
【００１９】
APP1にデータベース内に記憶されるデータ項目を供給するため、DBS1はRAWデータ項目をアンピクリングしてアンピクリングされたRAWデータを作成する。アンピクリングされたRAWデータは次に、データ項目を操作するAPP1内のルーチンに供給される前に、ユーザTYPE1データ型に変換される。
【００２０】
この例によって示されるように、RAWデータ型をサポートするデータベースシステムを用いていても、ユーザ定義型を作成するユーザ（「型作成者」）は、制御がデータベースシステムからユーザルーチンに渡されるたびに、RAWエンティティをその適当な構造化された等価物に変換したり戻したりするためのルーチンを提供する責任がある。特定的には、上述の例では、型作成者はraw-to-structおよびstruct-to-rawルーチンを書く責任がある。
【００２１】
ユーザ定義型からのデータをデータベース内においてRAWデータ項目として記憶することに関連してさまざまな欠点がある。たとえば、この技術では強い型づけをサポートしていない。換言すると、異なるユーザ定義型に関連付けられたデータ項目が、同じデータベース型としてデータベース内に記憶される。すなわち、データベースシステムおよび他のデータベースのユーザはこれらの型のあるものを別のものと区別することができない。これは、これらがすべてデータベース管理システムによってRAWエンティティとして扱われるためである。したがって、データベースシステムは、あるユーザが、ある種類のユーザ定義データ型からのデータを、別の種類のユーザ定義データ型からのデータを保持するはずであるRAW列に誤って記憶した場合にこれを検知することができない。
【００２２】
さらに、ユーザ定義型をRAWデータとして記憶する技術ではモデリングが貧弱である。データベースシステムがユーザ定義データ型を記憶できないことを考慮して作業することは型作成者にとって非常に厄介である。さらに、この技術では性能が比較的低い。これは、データがデータベースシステムとユーザアプリケーションとの間を行き来するたびに変換を行なうことが計算機資源を多く必要とするからである。
【００２３】
強い型づけをサポートし、かつRAWデータ型に対するデータベースのサポートを利用するため、ユーザ定義型のためのデータがRAW属性を有するデータベースのオブジェクト型に記憶されてもよい。たとえば、型作成者が２つの型TYPE1およびTYPE2を定義したと仮定する。TYPE1ユーザ型からのデータは、以下のステートメントによって作成されるデータベースオブジェクトに記憶されるだろう。
【００２４】
create type DBTYPE1 as OBJECT
(
a RAW(20)
mymethod1(a IN DBTYPE1);
)
同様に、TYPE2ユーザ型からのデータは、以下のステートメントによって作成されるデータベースオブジェクトに記憶されるだろう。
【００２５】
create type DBTYPE2 as OBJECT
(
a RAW(20);
mymethod2(a IN DBTYPE2);
)
この態様でデータベース定義オブジェクトをRAWデータ型と組合せて用いることにより、TYPE1およびTYPE2ユーザ定義データ型と関連付けられたデータは、データベースシステムにおいて互いから区別することができる。しかしながら、型作成者は依然としてRAW-ネイティブのフォーマット変換ルーチンを供給する責任がある。さらに、依然として、変換ルーチンを呼出すことに関連するオーバヘッドが、ユーザ定義型のためのデータがデータベースシステムとユーザ供給ルーチンとの間で受渡されるたびに生じる。
【００２６】
特定的には、何らかのデータ操作を行なうためにmymethod1ルーチンが呼ばれるたびに、入力データ項目「ａ」のRAW属性がRAWデータ項目からTYPE1データ項目へと変換されなければならない。操作の後、TYPE1データ項目はRAWデータ属性に変換して戻されなければならない。これらの変換は、データベースシステムによって制御される揮発性メモリとユーザ供給ルーチンによって用いられる揮発性メモリとの間でデータ項目が受渡されるたびに行なわなければならない。同様にmymethod2ルーチンに対するいずれのコールも、RAW属性をTYPE2データ項目に変換することと、外部ルーチンを呼ぶことと、次にTYPE2データ項目をRAWデータ属性に変換して戻すこととを含む。
【００２７】
上記に基づいて、型作成者が型作成者の選択するプログラム言語（Ｃ、JAVAなど）においてデータ型を構築することを可能にする機構を提供することが望ましいのは明らかである。さらに、データベースシステムがこれらのデータ型の内部構造を理解せずともデータベースシステムにそのような型を記憶させそれらにインデックスをつけさせることが望ましい。また、ユーザ定義型のデータが、データベース管理システムにおける他の言語環境からアクセス可能であり続けながら、同時にそれらのネイティブの言語環境においてはそれらのネイティブの形式として（Ｃの構造体またはJavaクラスとして）見えることを可能にする機構を提供することが望ましい。また、１組のデータがデータベース環境とそのネイティブ言語環境との間で受渡されるたびに変換を行なうことの必要を低減するまたはなくすことが望ましい。
【００２８】
【発明の概要】
ネイティブな構造がデータベースシステムには知られていないデータ型に関連付けられるデータ項目をデータベースシステム内で扱うための方法および装置が提供される。データ項目は、データベースシステムによって理解されていないにもかかわらず、そのネイティブな構造でデータベースシステム内に記憶される。データ項目を記憶するため、データベースシステムは、そのデータ項目にネイティブのプログラミング環境のランタイムサブシステムによって、またはユーザによって提供されるピクリングルーチンを呼ぶ。ストレージからルーチンを取出すため、データベースシステムはアンピクリングルーチンを呼ぶが、アンピクリングルーチンもまた、ユーザまたは適当なランタイムサブシステムによって提供される。データベースがデータ項目をそのネイティブなフォーマットに維持するため、データ項目がデータベースシステムと、データ項目を操作する外部ルーチンとの間で受渡される際に変換は必要ではない。
【００２９】
また、データベースシステム内でアクセスできるデータ項目の属性を宣言するための技術が提供される。ユーザは、データ項目がそのネイティブな環境において有する実際の属性とは異なり得る宣言された属性にアクセスするためにデータベースシステムが呼ぶルーチンを提供する。
【００３０】
この発明は、限定としてではなく例として添付の図面に示され、図中では同じ参照番号は同様の要素を示す。
【００３１】
【好ましい実施例の詳細な説明】
データベースシステムにユーザ実装のデータ型を記憶するための方法および装置を説明する以下の記載において、説明の目的で、この発明の完全な理解を促すために数多くの特定的な詳細が挙げられている。しかしながら、当業者には、この発明をこれらの特定の詳細なしに実施できることが明らかになるであろう。別の場合では、不必要にこの発明を曖昧にすることを避けるために周知の構造および装置はブロック図の形態で示している。
【００３２】
ハードウェアの概要
図３は、この発明のある実施例を実装し得るコンピュータシステム３００を示すブロック図である。コンピュータシステム３００は、バス３０２または情報を通信するための他の通信機構と、バス３０２に結合された、情報を処理するためのプロセッサ３０４とを含む。コンピュータシステム３００はまた、バス３０２に結合されプロセッサ３０４によって実行すべき命令および情報を記憶するためのランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などの主メモリ３０６を含む。主メモリ３０６はまた、プロセッサ３０４によって実行すべき命令の実行の間に一時変数または他の中間情報を記憶するのにも用いられる。コンピュータシステム３００はさらに、バス３０２に結合されプロセッサ３０４のための静的情報および命令を記憶するための読取専用メモリ（ＲＯＭ）３０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクなどの記憶装置３１０が、情報および命令を記憶するため設けられバス３０２に結合される。
【００３３】
コンピュータシステム３００は、コンピュータユーザに情報を表示するための、陰極線管（ＣＲＴ）などの表示装置３１２にバス３０２を介して結合されていてもよい。英数字キーおよび他のキーを含む入力装置３１４は、バス３０２に結合され、プロセッサ３０４に情報およびコマンド選択を通信する。別のタイプのユーザ入力装置は、プロセッサ３０４に方向情報およびコマンド選択を通信し、かつ表示装置３１２上のカーソル移動を制御するための、マウス、トラックボールまたはカーソル方向キーなどのカーソル制御３１６である。この入力装置は典型的に、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の、２軸での２つの自由度を有し、これは装置が平面における位置を特定することを可能にする。
【００３４】
この発明は、ユーザ実装のデータ型をデータベースシステムにおいて記憶するためのコンピュータシステム３００の使用に関する。この発明の一実施例によれば、ユーザ実装のデータ型は、プロセッサ３０４が主メモリ３０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行することに応答して、コンピュータシステム３００上で実行されるデータベースシステム内に記憶される。このような命令は、記憶装置３１０などの別のコンピュータ可読媒体から主メモリ３０６内へ読込まれてもよい。主メモリ３０６に含まれる命令のシーケンスの実行により、プロセッサ３０４がここで説明する処理ステップを行なうことになる。代替の実施例では、この発明を実施するのに布線回路をソフトウェア命令の代わりに、またはソフトウェア命令と組合せて用いてもよい。このように、この発明の実施例は、ハードウェア回路およびソフトウェアのいずれの特定の組合せにも限定されるものではない。
【００３５】
ここで用いられる用語「コンピュータ可読媒体」は、実行のためにプロセッサ３０４に命令を提供することにかかわるすべての媒体を指していう。このような媒体は数多くの形態をとることができ、これには不揮発性媒体、揮発性媒体および伝送媒体が含まれるが、これらに限定されるものではない。不揮発性媒体はたとえば、記憶装置３１０などの光ディスクまたは磁気ディスクを含む。揮発性媒体には、主メモリ３０６などの動的メモリが含まれる。伝送媒体には、バス３０２をなす配線を含む、同軸ケーブル、銅線および光ファイバが含まれる。伝送媒体はまた、電波および赤外線データ通信において生成されるもののような、音波または光波の形態をとっていてもよい。
【００３６】
一般的な形態のコンピュータ可読媒体には、たとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープまたは他の磁気媒体すべて、ＣＤ−ＲＯＭ、他の光学媒体すべて、穿孔カード、紙テープ、孔のパターンを有する他の物理媒体すべて、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のメモリチップすべてまたはカートリッジ、以下に説明するような搬送波またはコンピュータが読むことのできる他の媒体すべてが含まれる。
【００３７】
さまざまな形態のコンピュータ可読媒体が、実行のためにプロセッサ３０４に１つ以上の命令の１つ以上のシーケンスを与えることに関係し得る。たとえば、命令は初めに、遠隔地のコンピュータの磁気ディスクに担持されているかもしれない。遠隔地のコンピュータはその動的メモリに命令をロードして、命令をモデムを用いて電話回線を介して送信することができる。コンピュータシステム３００が有するモデムが電話回線上のデータを受信し、赤外線送信機を用いてそのデータを赤外線信号に変換することができる。赤外線検出器は赤外線信号に載ったデータを受信し、適当な回路がそのデータをバス３０２上に出力することができる。バス３０２はそのデータを主メモリ３０６に運び、そこからプロセッサ３０４が命令を取出し実行する。主メモリ３０６によって受信された命令は、場合により、プロセッサ３０４による実行の前または後のいずれかにおいて記憶装置３１０に記憶されてもよい。
【００３８】
また、コンピュータシステム３００は、バス３０２に結合される通信インターフェイス３１８を含む。通信インターフェイス３１８は、ローカルネットワーク３２２に接続されるネットワークリンク３２０に結合される双方向データ通信を提供する。たとえば、通信インターフェイス３１８は、対応するタイプの電話回線に対するデータ通信接続をもたらすモデムまたはサービス総合デジタルネットワーク（ＩＳＤＮ）カードであってもよい。別の例としては、通信インターフェイス３１８は、互換性のあるＬＡＮへのデータ通信接続をもたらすためのローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクもまた実現され得る。このような実現例のいずれにおいても、通信インターフェイス３１８は、さまざまなタイプの情報を表わすデジタルデータストリームを担持する電気信号、電磁信号または光信号を送受信する。
【００３９】
ネットワークリンク３２０は典型的には、１つ以上のネットワークを介して他のデータ装置に対するデータ通信を提供する。たとえば、ネットワークリンク３２０は、ローカルネットワーク３２２を介して、ホストコンピュータ３２４またはインターネットサービスプロバイダ（ＩＳＰ）３２６によって運用されるデータ機器に対する接続をもたらし得る。そのＩＳＰ３２６は、現在一般的に「インターネット」３２８と称されるワールドワイドパケットデータ通信ネットワークを介するデータ通信サービスを提供する。ローカルネットワーク３２２およびインターネット３２８はともに、デジタルデータストリームを担持する電気信号、電磁信号または光信号を用いる。さまざまなネットワークを介する信号と、ネットワークリンク３２０上および、デジタルデータをコンピュータシステム３００と授受する通信インタフェース３１８を介する信号とは、情報を転送する搬送波の例示的な形態である。
【００４０】
コンピュータシステム３００は、ネットワーク、ネットワークリンク３２０および通信インターフェイス３１８を介して、メッセージを送信しプログラムコードを含むデータを受信することができる。インターネットの例では、サーバ３３０がインターネット３２８、ＩＳＰ３２６、ローカルネットワーク３２２および通信インターフェイス３１８を介してアプリケーションプログラムに対する要求されたコードを送信するかもしれない。
【００４１】
受信されたコードは、受信されるとともにプロセッサ３０４によって実行されてもよく、および／または後に実行するために記憶装置３１０または他の不揮発性ストレージに記憶されてもよい。このような態様で、コンピュータシステム３００は搬送波の形態であるアプリケーションコードを得てもよい。
【００４２】
不透明型の概要
この発明の一局面によれば、データベースシステムがサポートしていないデータ型の型作成者は、そのデータ型をデータベースシステムに登録する。登録において、データベースシステムにはそのデータ型についての情報が供給される。データ型について供給される情報にはたとえば、そのデータ型に対する名、そのデータ型の属性に対する名、そのデータ型をピクリングおよびアンピクリングするためのルーチンならびにそのデータ型の個別の属性をゲットおよびセットするためのルーチンが含まれるだろう。
【００４３】
データベースシステムに供給される情報により、データベースシステムが、ユーザ定義データ型に属するデータ項目のネイティブな構造をピクリングし、これによってそのデータ項目をディスクに記憶できるようにし、そのデータ項目をアンピクリングしてそのデータ項目をそのネイティブな構造においてディスクから取出す機構を呼出すことが可能となる。データベース内の揮発性メモリ内に記憶される間、データ項目はそのネイティブ構造のままであるため、データベースシステムと外部ルーチンとの間で受渡される際に変換は必要ではない。
【００４４】
この態様で登録されるユーザ定義データ型はここで「不透明型」と称するが、これは、このようなユーザ定義データ型に属するデータ項目が、データベースシステムにとって未知であるまたはデータベースシステムが理解しない構造でデータベースシステム内に存在するためである。
【００４５】
型作成者の供給するピクリングルーチン
上に述べたように、不透明型登録プロセスにおいて、型作成者は不透明型とともに使用するためのピクリングおよびアンピクリングルーチンをデータベースシステムに供給してもよい。
【００４６】
ピクリングルーチンは、不透明型（「ネイティブ構造」）を操作する外部ルーチンが期待する構造およびフォーマットから永続的に記憶するのに適したフォーマット（「記憶可能な構造」）へとデータを変換する。逆に、アンピクリングルーチンでは、記憶可能な構造からネイティブ構造へとデータを変換する。データベースシステムは、データベースがサポートするデータ型に対する組込ピクリングおよびアンピクリングルーチンを呼出すのと同じ条件の下でユーザ供給データ型に対するピクリングおよびアンピクリングルーチンを呼出す。特定的には、アンピクリングルーチンは、不揮発性ストレージからデータベースシステムによって制御される揮発性ストレージの中へユーザ定義型のデータ項目を読込むことに応答して呼出される。ピクリングルーチンは、データベースシステムによって制御される揮発性ストレージ内にあるユーザ定義型のデータ項目を不揮発性ストレージに記憶する前に呼出される。
【００４７】
データベースシステムは不透明型のピクリングおよびアンピクリングルーチンを制御しているため、不透明型に関連付けられるデータ項目はデータベースシステム内にありながらそのネイティブな構造で存在することができる。データベースシステム内のデータ項目の構造およびフォーマットは、そのデータ項目を操作する外部ルーチンが必要とする構造およびフォーマットと同じであるため、データ項目をこれらのルーチンからデータベースシステムへおよびデータシステムからこれらのルーチンへ受渡す際に変換しなくてもよい。
【００４８】
図４を参照して、APP1がそのデータを不透明型をサポートするデータベースシステム（DBS1）内に記憶することを可能にするために行なわなければならない変換動作を示すブロック図が示される。特定的には、APP1内で生成されるデータ項目は、ユーザTYPE1の構造およびフォーマットに従ってAPP1内で記憶され操作される。DBS1内では、データ項目はそのネイティブの構造およびフォーマットのままである。すなわち、データ項目が記憶のためにDBS1内に渡される際に変換は行なわれない。DBS1は、型作成者によって供給されるピクリングルーチンを呼ぶことによってデータ項目をピクリングしてこれをディスクに記憶する。
【００４９】
APP1にディスクに記憶されるデータ項目を供給するために、DBS1は、型作成者が供給するアンピクリングルーチンを呼ぶことによってデータ項目をアンピクリングする。DBS1内でアンピクリングされるのだが、この際、データ項目はそのネイティブ構造およびフォーマットである。すなわち、アンピクリングされたデータ項目は、さらなる変換を全く行なうことなく、データ項目を操作するAPP1内のルーチンに供給することができる。
【００５０】
データ項目がデータベースシステムと外部ルーチンとの間で受渡されるたびに変換を行なうことを回避する能力の価値は、変換動作のコストが増大するにつれ増す。たとえば、大きいデジタル画像のためのデータをユーザ定義データ型が保持すると仮定する。性能上の理由のため、外部ルーチンは圧縮されていない画像を操作するよう設計される。しかしながら、ディスク空間を節約するため、画像は圧縮フォーマットでディスクに記憶されることとなる。
【００５１】
不透明型をサポートしないデータベースシステムでは、画像がデータベースシステムによって記憶される前に圧縮されることを確実にするため、外部ルーチンは画像をデータベースシステムに渡す前にすべての画像を圧縮しなければならないことになる。同様に、外部ルーチンはデータベースシステムから受取ったすべての画像を伸張しなければならないこととなる。
【００５２】
不透明型に対するサポートを用いて、ユーザは、圧縮および伸張をそれぞれ行なうピクリングおよびアンピクリングルーチンを登録してもよい。これによって、圧縮に関連するコストは画像が実際にディスクに記憶される際またはディスクから取出される際にのみ生じることとなり、画像がデータベースシステムと外部ルーチンとの間で受渡されるたびに生じることにはならない。
【００５３】
言語に基づいたピクリングおよびアンピクリング
この発明の別の局面によれば、不透明型は、データ項目がどのようにピクリングされアンピクリングされるかを言語環境が決定するような言語環境において作成してもよい。たとえば、JAVAにより実装されたデータ型はある特定のフォーマットを有するクラスファイル内に記憶され、JAVAランタイムサブシステムによりJAVAクラスをメモリ内にロードするための機構がもたらされる。このような条件の下では、特定のピクルおよびアンピクルルーチンを各々の個別のJAVAクラスに対して登録する必要はない。代わりに、データベースシステムは、どの不透明型がJAVAクラスであるかを示すメタデータを記憶する。データベースシステムはそこで、JAVAランタイムサブシステム内の適当なJAVAルーチンを自動的に呼出して、このようなJAVAクラスに属するオブジェクトをピクリングおよびアンピクリングする。
【００５４】
不透明型の属性へのアクセス
不透明型登録プロセスにおいて、型作成者は、不透明型の属性に対する名と、不透明型の個別の属性をゲットおよびセットするためのルーチンとをデータベースシステムに供給してもよい。たとえば、型作成者はデータベースシステムに以下のステートメントを提示してもよい。
【００５５】
create type foo as opaque object
(
attrib1,NUMBER;
attrib2,char(31);
)
この例では、「foo」の名を有する不透明型に対する不透明型宣言がデータベースシステムに提示される。不透明型宣言は、不透明型内の２つの属性に対する名を供給する（attrib1およびattrib2）。属性の各々に対し、この宣言はデータベースによりサポートされたデータ型を特定する。特定的に、attrib1に対して特定された、データベースによりサポートされるデータ型はNUMBERであり、attrib2に対して特定された、データベースによりサポートされる型はchar(31)である。しかしながら、この名および型情報があっても、不透明なデータ型は不透明なままである。なぜなら、データベースシステムはその不透明型のネイティブ構造を理解しないからである。よって、データベースシステムは補助なしにはfoo型のデータ項目内の個別の属性にアクセスすることができない。
【００５６】
データベースシステムがfoo型のデータ項目内の個別の属性にアクセスするのを可能にするために、型作成者は、個別の属性にアクセスするためのルーチンをデータベースシステムに登録する。たとえば、ユーザは２つのルーチン、すなわち、foo.attrib1.get(a OUT NUMBER）およびfoo.attrib1.set(a IN NUMBER）を供給してもよい。foo.attrib1.getルーチンは、NUMBER型の入力パラメータの値としてfoo型のデータ項目のattrib1属性の値をセットする。foo.attrib1.setルーチンは、foo型のデータ項目のattrib1属性の値としてNUMBER型の入力パラメータの値をセットする。
【００５７】
データベースシステムに供給される不透明型定義においてリストされる属性とネイティブなデータ型定義における属性との間に１対１のマッピングがある必要はない。したがって、型作成者には、データベースシステム環境内で、もしあれば、不透明型のどの部分にアクセスできるかということに関して高い柔軟度が許される。たとえば、型作成者は、ネイティブな言語宣言を用いて「web＿page」データ型を作成してもよい。
【００５８】
struct web＿page
｛
header:text;
body:text;
｝
しかしながら、型作成者は、以下の不透明型宣言を用いてweb＿page型をデータベースシステムに登録してもよい。
【００５９】
create type web＿page as opaque object:
(
firstword:char(10)
checksum: NUMBER;
)
不透明型宣言は、データベースシステムに、web＿pageデータ項目が２つの属性、すなわち、firstwordおよびchecksumを有することを知らせる。web＿pageデータ項目は、そのネイティブ環境においては実際には２つの異なる属性、すなわち、headerおよびbodyを有する。この例においてもそうであるように、不透明型宣言において特定される属性はデータ型のネイティブ属性のいずれにも対応していないこともあり得るため、これらはここで不透明型属性と称する。
【００６０】
headerおよびbody属性は、web＿page型のネイティブ構造を知っている外部ルーチンを呼出すことによってアクセスされ操作され得るが、データベースシステム内で直接アクセスすることはできない。データベースシステムはこれらの属性が存在していることさえも知らない。なぜなら、これらは不透明型宣言において名が挙がっていないためである。
【００６１】
型作成者は、データベースシステム内で不透明型属性にアクセスすることを可能にするルーチンを作成する。これらのルーチンはそのデータ型のネイティブ環境において書かれているため、これらはそのデータ型のすべてのネイティブ属性を知っておりアクセスすることができる。型作成者によりデータベースシステムに供給される属性アクセスルーチンは、どの不透明型属性にアクセスすることができ、かつどのようにこれらにアクセスするかを定める。たとえば、web＿pageデータ型の型作成者は、web＿pageデータ項目のbody内の先頭の単語をデータベース変数に記憶するweb＿page.firstword.get(a OUT Char(10)）関数を登録してもよい。同様に、型作成者は、web＿pageデータ項目のbodyにハッシュ関数を適用することによって生成されるチェックサムをデータベースのNUMBER変数に記憶するweb＿page.checksum.out(a OUT Char(10)）ルーチンを登録してもよい。
【００６２】
前述の明細書において、この発明をその特定の実施例を引用して説明した。しかしながら、この発明のより広い精神および範囲から逸脱することなくさまざまな修正および変更をこれに対して行なってもよいことが明らかになるであろう。したがって、この明細書および図面は限定的な意味ではなく例示的なものとみなすべきである。
【図面の簡単な説明】
【図１】あるアプリケーションが、そのアプリケーションが用いるデータ構造をサポートしないデータベースシステムを用いてそのデータを記憶する際に生じるさまざまな変換を示すブロック図である。
【図２】あるアプリケーションが、RAWデータ型をサポートするがそのアプリケーションが用いるデータ構造をサポートしないデータベースシステムを用いてそのデータを記憶する際に生じるさまざまな変換を示すブロック図である。
【図３】この発明の実施例が実装され得るコンピュータシステムのブロック図である。
【図４】この発明の一実施例に従ってデータ項目がデータベースシステム内にそのネイティブフォーマットにおいて記憶される際に、データ項目がデータベースシステムと外部ルーチンとの間で受渡される際に変換されない様子を示すブロック図である。

Claims

データベースシステムにおいて、前記データベースシステムにとって未知であるネイティブ構造を有するデータ型に関連付けられるデータ項目を扱う方法であって、
前記データベースシステムが、前記データ型に対するピクリング機構およびアンピクリング機構を特定するユーザ入力を受けるステップと、
前記データベースシステムが、前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを登録するステップと、
前記データベースシステムが、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを登録するステップと、
前記データ項目を不揮発性メモリに記憶する前に、前記データベースシステムが、ユーザ入力によって特定されたピクリング機構を呼出すステップを含み、前記ピクリング機構は前記データ項目を前記ネイティブ構造から記憶可能なフォーマットに変え、ピクリング機構を呼出すステップは、前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すことによって行なわれ、前記方法はさらに
前記データ項目を不揮発性メモリから読む際に、前記データベースシステムがユーザ入力によって特定されたアンピクリング機構を呼出すステップを含み、前記アンピクリング機構は前記データ項目を前記記憶可能なフォーマットから前記ネイティブ構造に変え、アンピクリング機構を呼出すステップは、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すことによって行なわれ、前記方法はさらに
データ項目が前記データベースシステムと前記データ項目が前記ネイティブ構造であることを期待するルーチンとの間で受渡される際に前記データ項目を前記ネイティブ構造に維持するステップを含む、方法。
前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すステップは、データ型に関連付けられたプログラミング環境に対するランタイムサブシステムを呼出すことによって行なわれ、
前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すステップは、データ型に関連付けられたプログラミング環境に対するランタイムサブシステムを呼出すことによって行なわれる、請求項１に記載の方法。
前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すステップは、前記データ型に属するデータ項目をピクリングするための第１のユーザ実装ルーチンを呼出すことによって行なわれ、
前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すステップは、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ実装ルーチンを呼出すことによって行なわれる、請求項１に記載の方法。
前記データベースシステムが、前記データ型と関連付けられた型宣言を受けるステップをさらに含み、前記型宣言は、前記データベースシステムがサポートするデータ型のものである１つ以上の属性を特定する、請求項１に記載の方法。
前記データベースシステムが、前記１つ以上の属性の第１の属性に関連付けられるユーザ指定の方法を登録するステップと、
前記データベースシステムが、前記第１の属性にアクセスするように前記ユーザ指定の方法を呼出すステップとをさらに含む、請求項４に記載の方法。
前記データベースシステムが、前記１つ以上の属性の第２の属性に関連付けられる第２のユーザ指定の方法を登録するステップと、
前記データベースシステムが、前記第２の属性にアクセスするように前記第２のユーザ指定の方法を呼出すステップとをさらに含む、請求項５に記載の方法。
前記ネイティブ構造は複数の属性を有し、前記複数の属性は前記型宣言によって特定される前記１つ以上の属性と１対１対応を有していない、請求項４に記載の方法。
前記ネイティブ構造は、前記型宣言によって特定される前記１つ以上の属性のいずれとも対応していない属性を有する、請求項７に記載の方法。
前記ネイティブ構造は、前記型宣言によって特定される前記１つ以上の属性に対応する属性を全く有していない、請求項７に記載の方法。
データベースシステムにおいて、前記データベースシステムにとって未知であるネイティブ構造を有するデータ型と関連付けられるデータ項目を扱うための方法であって、
前記データベースシステムが、前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを登録するステップと、
前記データベースシステムが、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを登録するステップと、
前記データ型に属するデータ項目を不揮発性メモリに記憶するために、前記データ型に属するデータ項目をピクリングするための前記第１のユーザ指定ルーチンを呼び出し、前記データ型に属するデータ項目を不揮発性メモリからロードするために、前記データ型に属するデータ項目をアンピクリングするための前記第２のユーザ指定ルーチンを呼び出すステップと、
前記データベースシステムが１組の属性を特定するユーザ入力を受けるステップと、
前記データベースシステムが、前記１組の属性における各属性に対して前記データベースシステムがサポートするデータ型を特定するユーザ入力を受けるステップと、
前記データベースシステムが、前記１組の属性の第１の属性にアクセスするための外部ルーチンを特定するユーザ入力を受けるステップとを含み、前記外部ルーチンは、前記データ項目が前記ネイティブ構造を有することを期待しており、前記方法はさらに、
前記データベースシステムが、前記少なくとも１つの属性にアクセスするための前記外部ルーチンを呼び出すステップを含み、前記外部ルーチンの呼出しに応答して、前記データベースシステムは前記外部ルーチンから前記第１の属性に関連付けられるデータ型に従って構成される値を受ける、方法。
データ項目が前記データベースシステムと前記データ項目が前記ネイティブ構造であることを期待するルーチンとの間で受渡される際に前記データ項目を前記ネイティブ構造に維持するステップをさらに含む、請求項１０に記載の方法。
前記ネイティブ構造は複数の属性を有し、前記複数の属性は前記１組の属性と１対１対応を有していない、請求項１０に記載の方法。
第１の属性は、前記複数の属性のいずれとも対応していない、請求項１２に記載の方法。
データベースシステムにおいて、前記データベースシステムにとって未知であるネイティブ構造を有するデータ型と関連付けられるデータ項目を扱うための命令の１つ以上のシーケンスを担持するコンピュータ可読記録媒体であって、１つ以上のプロセッサによる命令の１つ以上のシーケンスの実行により、１つ以上のプロセッサが以下のステップ、すなわち、
前記データベースシステムが、前記データ型に対するピクリング機構およびアンピクリング機構を特定するユーザ入力を受けるステップと、
前記データベースシステムが、前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを登録するステップと、
前記データベースシステムが、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを登録するステップと、
前記データ項目を不揮発性メモリに記憶する前に、前記データベースシステムが、ユーザ入力によって特定されたピクリング機構を呼出すステップとを行なうようにさせ、前記ピクリング機構は前記データ項目を前記ネイティブ構造から記憶可能なフォーマットに変え、前記ピクリング機構を呼出すステップは、前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すことによって行なわれ、前記コンピュータ可読記録媒体はさらに、
前記データ項目を不揮発性メモリから読む際に、前記データベースシステムが、ユーザ入力によって特定されたアンピクリング機構を呼出すステップを行わせ、前記アンピクリング機構は、前記データ項目を前記記憶可能なフォーマットから前記ネイティブ構造に変え、前記アンピクリング機構を呼出すステップは、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すことによって行なわれ、前記コンピュータ可読記録媒体はさらに、
データ項目が前記データベースシステムと前記データ項目が前記ネイティブ構造であることを期待するルーチンとの間で受渡される際に前記データ項目を前記ネイティブ構造に維持するステップを行なうようにさせる、コンピュータ可読記録媒体。
前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すステップは、データ型に関連付けられたプログラミング環境に対するランタイムサブシステムを呼出すことによって行なわれ、
前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すステップは、データ型に関連付けられたプログラミング環境に対するランタイムサブシステムを呼出すことによって行なわれる、請求項１４に記載のコンピュータ可読記録媒体。
前記データ型に属するデータ項目をピクリングするための第１のユーザ指定ルーチンを呼出すステップは、前記データ型に属するデータ項目をピクリングするための第１のユーザ実装ルーチンを呼出すことによって行なわれ、
前記データ型に属するデータ項目をアンピクリングするための第２のユーザ指定ルーチンを呼出すステップは、前記データ型に属するデータ項目をアンピクリングするための第２のユーザ実装ルーチンを呼出すことによって行なわれる、請求項１４に記載のコンピュータ可読記録媒体。
前記データベースシステムが、前記データ型と関連付けられた型宣言を受けるステップを行なうための命令をさらに含み、前記型宣言は、前記データベースシステムがサポートするデータ型のものである１つ以上の属性を特定する、請求項１４に記載のコンピュータ可読記録媒体。
前記データベースシステムが、前記１つ以上の属性の第１の属性に関連付けられるユーザ指定の方法を登録するステップと、
前記データベースシステムが、前記第１の属性にアクセスするように前記ユーザ指定の方法を呼出すステップとを行なうための命令のシーケンスをさらに含む、請求項１７に記載のコンピュータ可読記録媒体。
前記データベースシステムが、前記１つ以上の属性の第２の属性に関連付けられる第２のユーザ指定の方法を登録するステップと、
前記データベースシステムが、前記第２の属性にアクセスするように前記第２のユーザ指定の方法を呼出すステップとを行なうための命令をさらに含む、請求項１８に記載のコンピュータ可読記録媒体。
前記ネイティブ構造は複数の属性を有し、
前記複数の属性は、前記型宣言によって特定される前記１つ以上の属性と１対１対応を有していない、請求項１７に記載のコンピュータ可読記録媒体。
前記ネイティブ構造は、前記型宣言によって特定される前記１つ以上の属性のいずれとも対応していない属性を有する、請求項２０に記載のコンピュータ可読記録媒体。
前記ネイティブ構造は、前記型宣言によって特定される前記１つ以上の属性の１つに対応する属性を全く有していない、請求項２０に記載のコンピュータ可読記録媒体。