JP2007501476A - オブジェクトおよび従属オブジェクトをドロップしないデータベースシステム - Google Patents

Abstract

データベースシステムにおいてオブジェクト（たとえば、テーブル）および従属オブジェクトをドロップしないための技術が与えられる。オブジェクトがドロップされると、オブジェクトはごみ箱に移動され、そこでオブジェクトは、ユーザーがオブジェクトをドロップしないか、またはオブジェクトがパージされるまで存在する。従属オブジェクトも、従属オブジェクトが従属するオブジェクトとともにごみ箱に移動される。オブジェクトは、ユーザーによって、またはより多くの記憶空間が必要なときに、明示的にごみ箱からパージされ得る。従属オブジェクトおよびパーティションのパージングは、より多くの記憶空間を得る必要がなければ、先送りされ得る。

Description

発明の背景
この発明はコンピュータシステムに関する。より具体的には、この発明は、データベースシステムにおいてオブジェクトおよび従属オブジェクトをドロップしない能力をもたらすことに関する。

概して、データベース管理システム（ＤＢＭＳ）は、データベースにおいて情報の編成、記憶、検索、機密保護、および保全性を制御するコンピュータソフトウェアである。データベースにおける情報は、多くのタイプのオブジェクトを利用して、記憶され得る。たとえば、情報はテーブルに記憶されることができ、テーブルへのアクセスはインデックスによって容易になり得る。他の共通オブジェクトは、入れ子テーブル、部分テーブル、インデックス編成テーブル（ＩＯＴ）、ラージオブジェクト（ＬＯＢ）、制約、トリガなどを含む。

多くの理由から、ユーザーはオブジェクトをパージまたは削除することを決めるであろう。たとえば、より多くの記憶空間を利用可能にするために、オブジェクトがもはや必要ないとユーザーは感じる場合もあれば、またはそれは偶発的なものであるかもしれない。パージのための理由にかかわらず、ユーザーは時折考えを変え、オブジェクトを元に戻すことを望む。

今日のデータベースアプリケーションを用いて、データベースの現在の状態が定期的に記憶される。さらに、その状態以降にデータベース上で実行されるトランザクションのリストも記憶される。ユーザーがパージされたオブジェクトを検索したいとき、データベースは最後に記憶された状態にロールバックされる。ロールバックの後、その状態が記憶された後に実行されたトランザクションは、トランザクションのリストから実行され得る。

この解決策はパージされたオブジェクトを検索し得るが、比較的時間がかかるという不利な点を有する。より重要なことには、この解決策は、データベースのロールバックおよびロールフォワードの間、新しいトランザクションが典型的にデータベースによって除外されることができないという不利な点を有する。したがって、データベースは、パージされたオブジェクトの検索の間、事実上シャットダウンされる。

データベースシステムにおいてオブジェクトがパージされる方法を改善するための革新的な技術を有することは有益であろう。さらに、データベースがシャットダウンされる必要なく、オブジェクトの検索を可能にする革新的な技術を有することは有益であろう。

発明の概要
この発明は、データベースにおいてオブジェクトおよび従属オブジェクトをドロップしないための革新的な技術をもたらす。概して、ユーザーがオブジェクトをドロップまたは削除したいとき、そのオブジェクトはごみ箱に移動されるか、またはごみ箱に置かれる。このオブジェクトに従属するオブジェクトも、ごみ箱に移動されるであろう。後に、ユーザーがそのオブジェクトを検索したい場合、オブジェクトはごみ箱から移動され得る。この態様で、オブジェクトの検索は速くなされることができ、検索の間データベースがシャ
ットダウンされる必要がない。この発明のいくつかの具体的な実施例は以下に記載される。

一つの実施例では、この発明はデータベースシステムにおいてドロップしないことを可能にする方法をもたらす。データベースにおいてオブジェクトをドロップするコマンドが受取られる。オブジェクトはごみ箱に移動され、そのオブジェクトに従属する従属オブジェクトがあれば、従属オブジェクトはごみ箱に移動される。オブジェクトをドロップしないようにコマンドを受取るとすぐに、オブジェクトはごみ箱から移動される。

別の実施例では、この発明はデータベースシステムにおいてドロップしないことを可能にする方法をもたらす。データベースにおいてオブジェクトをドロップするコマンドが受取られる。オブジェクトはごみ箱に移動され、そのオブジェクトに従属する従属オブジェクトがあれば、従属オブジェクトはごみ箱に移動される。オブジェクトをドロップしないようにコマンドを受取るとすぐに、オブジェクトはごみ箱から移動される。より多くの空間が必要であれば、オブジェクトはより多くの記憶空間を与えるようにパージされる。

この発明の他の特徴および利点は、同一または同様の構造が同じ参照番号を用いて示される、以下の記載および添付の図面との関連を再検討するとすぐに、容易に明らかとなる。

好ましい実施例の詳細な説明
以下の記載では、この発明は、データベース環境においてオブジェクトおよび従属オブジェクトをドロップしない実施例を参照して記載される。しかしながら、この発明の実施例は任意の特定の構造、環境、アプリケーション、または実現例に限定されない。たとえば、データベース管理システムのための例示的な３段構造が記載されるが、この発明は任意のデータベースアプリケーションまたは構造に有利に適用されてもよい。したがって、以下の実施例の記載は、例示を目的とするものであり、限定を目的とするものではない。

かなり一般的なデータベース管理システム構造は、図１に示される３段構造である。データベース管理システムの中核には、データベース３を記憶する中央記憶装置１がある。データベース３は、典型的にはより大型のコンピュータシステムの一部である１つ以上のハードドライブ上に典型的に記憶される。情報は、情報を記憶するためにテーブルに大きく依存するリレーショナルデータベース管理システムを用いて、さまざまなフォーマットでデータベース３上に記憶され得る。

データベースサーバ５は、データベース３と対話するプログラムの例である。データベースサーバの各々の例は、とりわけ、独立してデータベース３を照会することができ、その中に情報を記憶することができる。データベースサーバ５は、グラフィカルユーザーインターフェイスなどのユーザーフレンドリーなインターフェイスを含まないかもしれない。

したがって、１つ以上のアプリケーションサーバ７が、ユーザーインターフェイスをデータベースサーバ５に与え得る。たとえば、アプリケーションサーバ７はインターネット（または他のネットワーク）上のウェブアプリケーションサーバであり得る。アプリケーションサーバ７は、データベースサーバ５を介してデータベース３にアクセスするためのユーザーフレンドリーな機構を与え得る。ウェブブラウザ９はアプリケーションサーバ７にアクセスするために利用され得る。

図２は、この発明の実施例を実現する、コンピュータシステムに存在し得る構成要素のブロック図を示す。コンピュータシステム１０１は、コンピュータプログラム（オペレーティングシステムを含む）からの命令を実行するプロセッサ１０３を含む。プロセッサは典型的にメモリキャッシュも有するが、プロセッサ１０３は命令またはコンピュータコードおよびデータを記憶し得るメモリ１０５を利用する。

固定記憶装置１０７は、典型的には永続的であり、メモリ１０５と比較するとより多くの記憶を与えるように、コンピュータプログラムおよびデータを記憶し得る。現在のところ、データベースのための一般的な固定記憶装置は、多重（たとえば、配列）ハードドライブである。取外し可能記憶装置１０９は、その上に記憶されるコンピュータプログラムおよび／またはデータに移動性を与える。取外し可能記憶装置の例は、フロッピー（登録商標）ディスク、テープ、ＣＤ／ＲＯＭ、フラッシュメモリ装置などである。

メモリ１０３、固定記憶装置１０７、および取外し可能記憶装置１０９は、この発明を実現するコンピュータコードを組入れるコンピュータプログラム、この発明とともに使用するためのデータなどを記憶および検索するために利用され得る、コンピュータが読取可能な記憶媒体の例を与える。さらに、搬送波の状態で（たとえば、インターネットを含むネットワークにおいて）実施されるデータ信号は、コンピュータが読取可能な記憶媒体であり得る。入力１１１は、ユーザーがシステムとインターフェイスすることを可能にする。入力は、キーボード、マウス、ボタン、ダイヤル、または任意の他の入力機構の使用を介してなされることができる。出力１１３は、システムがユーザーに出力を与えることを可能にする。出力は、モニタ、ディスプレイ画面、ＬＥＤ、プリンタ、または任意の他の出力機構を介して与えられることができる。

ネットワークインターフェイス１１５は、システムが接続されるネットワークとシステムがインターフェイスすることを可能にする。コンピュータシステム１０１のシステムバス構造は矢印１１７によって表わされる。図２に示される構成要素は、多くのコンピュータシステムに見出されることができる。しかしながら、構成要素は追加、削除、および組合せられ得る。たとえば、固定記憶装置１０７は、ネットワーク接続を介してアクセスされるファイルサーバであり得るだろう。このように、図２は例示を目的とするものであり、限定を目的とするものではない。

例示的なデータベースアプリケーションおよび環境が記載されてきたので、データベースにおける例示的なオブジェクトを論じることは有益であろう。図３は、データベースに存在してもよいオブジェクトおよび従属オブジェクトを示す。

テーブル２０１はラージオブジェクト（ＬＯＢ）２０３を含むように示される。テーブルは、データベースに情報を記憶するために使用される一般的なオブジェクトである。情報は典型的にテーブルのフィールドに記憶され、数、ストリング、ポインタ、入れ子テーブルなどのデータタイプを含み得る。入れ子テーブル、パーティション付テーブル、ＩＯＴなどの総称テーブルに加えて、多くの種類のテーブルがある。

例示の目的で、ＬＯＢ２０３は、テーブルに記憶されてもよい別のタイプのデータを表わすように示される。ＬＯＢは、２値画像およびサウンドファイルなどの情報を記憶し得る。より効率的にテーブル２０１にアクセスするために、インデックス２０５および２０７が示される。インデックスは典型的にキーフィールドを利用して、より効率的にテーブルにアクセスする。

ＬＯＢ２０３およびインデックス２０５、２０７は従属オブジェクトの例であり、なぜならば、それらは別のオブジェクト（この場合は、テーブル２０１）に従属するからであ
る。ＬＯＢ２０３およびインデックス２０５、２０７が従属オブジェクトである理由は、それらが従属するオブジェクトがなければ、それらはほとんど価値がないか、または全く価値がないかもしれないからである。

いくつかの従属オブジェクトは再構成可能であり、これは従属オブジェクトがパージされると再構成され得ることを意味する。インデックス２０５および２０７は、再構成され得る従属オブジェクトの例である。ＬＯＢ２０３は、一度パージされると再構成されることが典型的にできない従属オブジェクトの例である。従属オブジェクトの他の例は制約およびトリガを含むが、この発明は任意のタイプの従属オブジェクトで作動するように有利に適用されることができる。

データベースは典型的には、図３に示されるものよりもはるかに複雑である。しかしながら、この図はこの発明の実施例を記載するのに有益となる。

図４は、データベースからオブジェクトをドロップしないプロセスのフローチャートを示す。ここに示されるすべてのフローチャートと同様に、ステップはこの発明の精神および範囲から逸脱することなく追加、削除、組合せ、または並べ替えられることができる。

ステップ３０１において、オブジェクトをドロップするようにコマンドが受取られる。コマンドは典型的にはユーザーから受取られ、グラフィカルユーザーインターフェイスまたはコマンドラインなどのインターフェイスを介して入力されてもよい。オブジェクトをドロップすることによって、ユーザーはオブジェクト（たとえば、テーブル）がもはや必要なくなることを確信していることを示している。

ステップ３０３において、オブジェクトはごみ箱に移動される。ごみ箱は、より多くの記憶空間を得るために、ユーザーがオブジェクトをドロップしないか、ユーザーが明示的にオブジェクトをパージするか、またはデータベースがオブジェクトをパージするまで、ドロップされたオブジェクトを記憶するリポジトリである。オブジェクトの移動は、ごみ箱の中にあるものを規定する変数を変更することによって実行されることができる。

いくつかの実施例では、ごみ箱はディクショナリテーブルとして実現される。オブジェクトがドロップされると、項目がこのテーブルの中に作られ、これらのオブジェクトはドロップされないことが可能である。ごみ箱の中のオブジェクトのための空間は、たとえオブジェクトがドロップされるとしても、依然として適切なユーザーに割当てられてもよい。一つの実施例のさらなる詳細は、図７および図８を参照して以下に記載される。

ステップ３０５において、ドロップされたオブジェクトに従属する任意の従属オブジェクトがあるかどうかが判断される。従属オブジェクトがあれば、ステップ３０７において、従属オブジェクトはごみ箱に移動される。たとえば、図３に戻って参照して、テーブル２０１がドロップされるべきであるとユーザーが指示すると、システムはＬＯＢ２０３およびインデックス２０５、２０７をテーブル２０１の従属オブジェクトとして識別し、それらはごみ箱に移動されるであろう。

図４に戻って、ステップ３０９において、オブジェクトをドロップしないようにコマンドを受取るとすぐに、オブジェクトはごみ箱から移動される。オブジェクトをごみ箱から移動することによって、データベースシステムは、検索の間データベースが事実上シャットダウンされる必要なく、テーブルをドロップしないことが可能になっている。

オブジェクトがドロップされず、ごみ箱から移動されると、ごみ箱に存在する任意の従属オブジェクトもごみ箱から移動され得る（つまり、ドロップされない）。いくつかの例
では、再構成可能な従属オブジェクトは、より多くの記憶空間を得るために、ごみ箱からパージされたかもしれない。再構成可能な従属オブジェクトは、それが従属するオブジェクトがドロップされないとき、再構成可能なオブジェクトが必要とされるとき、データベースシステムが処理要件において一時的な静止を有するとき、または任意の他のときに、再構成されることができる。

図４は、如何にしてオブジェクトおよび従属オブジェクトがごみ箱に移動されてもよいかという例を示した。図５はオブジェクトがごみ箱から移動されてもよい方法を示す。より具体的には、図５はオブジェクトおよび従属オブジェクトがごみ箱から除去され得る方法を示すプロセスのフローチャートを示す。

ステップ３５１において、より多くの記憶空間が必要とされない状態にデータベースがある場合、ユーザーはごみ箱からオブジェクトおよび従属オブジェクトを除去するようにコマンドを実行することができる。たとえば、ステップ３５３において、ユーザーはごみ箱からオブジェクトまたは従属オブジェクトを明示的にパージし得る。オブジェクトまたは従属オブジェクトが一度パージされると、ユーザーが考えを変えた場合にオブジェクトまたは従属オブジェクトを検索するために、ロールバックおよびロールフォワードを実行することが必要であろう。

さらに、ステップ３５５において、ユーザーはオブジェクトまたは従属オブジェクトをドロップしなくてもよい。オブジェクトまたは従属オブジェクトをドロップしないことによって、オブジェクトまたは従属オブジェクトはごみ箱から移動され、まるでドロップされなかったかのように利用可能である。

記憶空間が必要である場合、ステップ３５７において、データベースはパージするためにオブジェクトを選択してもよい。ステップ３５９において、データベースは、ステップ３５９で選択されたオブジェクトに従属する従属オブジェクトをパージしてもよい。ステップ３６１において、選択されたオブジェクトがパージされる。

記載されるように、いくつかの実施例では、より多くの記憶空間が必要である場合、データベースはパージするためにオブジェクトおよび従属オブジェクト（もしあれば）を選択する。他の実施例では、たとえば、パージされるオブジェクトを選択するために、ユーザーがこのプロセスにかかわることができる。

ごみ箱の中にあるオブジェクトが依然として記憶空間を占めるために、ユーザーが新しいオブジェクトを要求する（またはデータベースがオブジェクトを作成する必要がある）ときに、より多くの記憶空間が所望されることが判断されることになるということが起こってもよい。図６は、ごみ箱の中の１つ以上のオブジェクトをパージすることによって、より多くの記憶空間を得るプロセスのフローチャートを示す。

ステップ４０１において、ある量の記憶空間の要求が受取られる。ステップ４０３において、最も古いオブジェクトがパージされるために選択される。いくつかの実施例では、最も古いオブジェクトが選択されるが、他の実施例はパージされるオブジェクトを選択するために任意の数の特性を使用することができる。

ステップ４０５において、選択されたオブジェクトがパーティションに分割されるかどうかが判断される。選択されたオブジェクトがパーティションに分割されない場合、ステップ４０７において、オブジェクトはパージされる。パージされるオブジェクトに従属するオブジェクトもパージされ得る。しかしながら、ステップ４０７におけるオブジェクトのパージングが要求された記憶空間をもたらしたために、従属オブジェクトがこのときに
パージされる必要がない場合、従属オブジェクトのパージングは後に延期されることが可能である。たとえば、いくつかの実施例では、デーモンがバックグラウンドにおいて実行され、パージ可能であると印を付けられたが、まだパージされていない、ごみ箱の中の従属オブジェクトを識別する。デーモンは、その後、より都合のよいときに、これらの従属オブジェクトをパージし得る。

ステップ４０９において、より多くの記憶空間がまだ必要であるかどうかが判断され、より多くの記憶空間が必要であれば、フローはステップ４０３に戻る。そうでない場合には、要求された記憶空間は利用可能になっている。

ステップ４０５に戻って、オブジェクトがパーティションに分割される場合、ステップ４１１において、１つ以上のパーティションがパージされる。いくつかの実施例では、すべてのパーティションがパージされる。しかしながら、要求された記憶空間を得るために、すべてのパーティションに満たないパーティションがパージされる必要がある場合、それらのパーティションのみがすぐにパージされる。上記に記載されるように、他のパーティションはパージ可能であると印を付けられることができ、デーモンは後にごみ箱からこれらのパーティションをパージすることができる。このように、オブジェクトの一部（たとえば、１つ以上のパーティション）が将来のパージのために印を付けられることができる。

要求された記憶空間を得るために必要とされるオブジェクトまたはパーティションをパージすることのみによって見られることができるように、ユーザー（またはデータベース）は記憶空間を得るために必要な限りただ待っているだけである。したがって、従属オブジェクトまたはパーティションが、必要でない記憶空間のためにパージされるのをユーザーは待つ必要はない。このため、いくつかの実施例では、ユーザーが明示的にオブジェクトをパージするとき、そのオブジェクト、すべての従属オブジェクトおよびすべてのパーティションはすぐにパージされる（つまり、デーモンによるパージのために先送りされない）。なぜなら、コマンドを発行したのはユーザーであり、処理の遅れを被るはずであるのはユーザーであるからである。

例
上記に論じられるように、ごみ箱はテーブルとして実現され得る。テーブルはドロップされたあらゆるオブジェクトのための項目を含み得る。図７はテーブルがごみ箱を実現するスキーマの例を示し、以下はテーブルにおける具体的なフィールドを記載する。

ＯＢＪ♯は、ドロップされるオブジェクトのために元のオブジェクト番号を記憶する。このフィールドは、ディクショナリテーブルにおいてオブジェクトを識別するために使用される。ＯＢＪ♯はデータベースにおけるすべてのオブジェクトに対して固有であり、したがって、オブジェクトに対して固有の識別子を形成する。

パーティションの場合、新しいオブジェクトはごみ箱に移動されるときに生成されることになり、したがって、新しいＯＢＪ♯がその新しいオブジェクトに割当てられ得る。この新しいＯＢＪ♯は次いで、主体パーティションを識別するために使用され得る。いくつかの実施例では、パーティションがドロップされない場合、パーティションは新しいオブジェクトとして回復されることになる。

ＯＷＮＥＲ♯は、オブジェクトの元の所有者のためにＵＳＥＲ♯を記憶するために使用される。オブジェクトをドロップすると、所有者情報はそのオブジェクトのために修正され得る。ユーザーがオブジェクトをドロップしなければ、オブジェクトは元の所有者へ復元されるはずであり、これはこのフィールドを用いて容易になり得る。

ＯＲＩＧＩＮＡＬ＿ＮＡＭＥはオブジェクトの元の名前を保持する。オブジェクトの名前は、オブジェクトがごみ箱に移動されると、変更され得る。オブジェクトの元の名前は、ユーザーの便宜のためだけに維持される。

ＯＰＥＲＡＴＩＯＮは、オブジェクト上で実行されたＤＤＬオペレーションを指定する。このフィールドは、オブジェクトが適切に処理されることができるように、オブジェクトがドロップされたか、または切捨てられたかを見分けるために使用され得る。このフィールドは以下の２つの有効な値のうちの１つを保持し得る。２つの有効な値とは、０−オブジェクトはドロップされた（ＤＲＯＰ）、および１−オブジェクトは切捨てられた（ＴＲＵＮＣＡＴＥ）である。

ＴＹＰＥ♯はドロップされるオブジェクトのオブジェクトタイプを記憶する。以下は、ドロップしないためにサポートされ得るタイプの例である。その例とは、テーブル、標準インデックス、ビットマップインデックス、入れ子テーブル、ＬＯＢ、ＬＯＢインデックス、ドメインインデックス、ＩＯＴトップインデックス、ＩＯＴオーバーフローセグメント、ＩＯＴマッピングテーブル、トリガ、制約、テーブルパーティション、テーブル複合パーティション、インデックスパーティション、インデックス複合パーティション、ＬＯＢパーティション、ＬＯＢ複合パーティションなどである。

ＴＳ♯は、ドロップされ、直ちにごみ箱に移動されるオブジェクトに「テーブル空間（Table Space）」番号を与える。これは、今にも一杯になる「テーブル空間（Tablespace）」のために空間を空けようとするのに有益であり得る。空間を入れるためにまだ多大な量の空間を有する「テーブル空間（Tablespace）」からの空間を再利用することは、空間圧力の問題を解決しないであろう。したがって、ほとんど一杯であり、いくらかの空間を必要とするテーブル空間のためにのみ、ごみ箱からの空間を再利用することは有益であろう。

ＦＩＬＥ♯は、オブジェクトのためのセグメントヘッダのために「ファイル番号（File
Number）」を記憶する。ＴＳ♯およびＢＬＯＣＫ♯とともに、固有のＳＥＧ＄項目が得られることができる。

ＢＬＯＣＫ♯は、オブジェクトのためのセグメントヘッダに「ブロック番号（Block Number）」を与える。ＴＳ♯およびＦＩＬＥ♯とともに、固有のＳＥＧ＄項目が得られることができる。このフィールドは、空間圧力の場合に、セグメントヘッダに効率的にアクセスするために利用され得る。

ＤＲＯＰＴＩＭＥは、オブジェクトがドロップされたシステム時間を記憶する。このフィールドの値は、オブジェクトがごみ箱の中に存在した時間を計算するために使用され得る。空間圧力の場合に、オブジェクトはドロップされた順序でごみ箱から再利用され得る。このように、このフィールドはごみ箱の中のオブジェクトの、時間をベースにした順序付けを維持するために使用されることさえある。

ＤＲＯＰＳＣＮは、オブジェクトのドロップを引起したＳＣＮを与える。これは「フラッシュバック（Flash Back）」クエリに役立つであろう。

ＰＡＲＴＩＴＩＯＮ＿ＮＡＭＥは、ドロップされたパーティションの名前を保持する。非パーティションテーブルの場合、このフィールドは「ヌル（ＮＵＬＬ）」になる。したがって、フィールドはユーザーの便宜のために使用されるのみである。

ＦＬＡＧＳは、ごみ箱の中のオブジェクトのためにさまざまなフラグを保持する。このフィールドにおけるビットのうちの１つは、オブジェクトがドロップされないことが可能であるかどうかを常に把握するために使用され得る。空間再利用のためのインクリメンタルアプローチの場合、オブジェクトに属するわずかなエクステントのみが空けられ、残余のエクステントがまだごみ箱の中に存在するということは十分にあり得る。オブジェクトに割当てられるエクステントが空けられていない場合、そのオブジェクトはドロップされないことが可能である。オブジェクトに属する１つのエクステントさえ空けられれば、オブジェクトはドロップされるはずである。

ＲＥＬＡＴＥＤは、対象としているオブジェクトのために親オブジェクトのＯＢＪ♯を識別する。

ＢＯは、このオブジェクトがドロップされ、ごみ箱に置かれることを引起したベーステーブルのためにＯＢＪ♯を記憶する。

ＰＵＲＧＥＯＢＪは、空間圧力を受けてパージされることになるオブジェクト（たとえば、インデックスまたはテーブルのいずれか）に対し、この特定のオブジェクトをシステムからパージし、空間を開放することが望ましい場合には、ＯＢＪ♯を与える。

ＢＡＳＥ＿ＴＳ♯は、ベースオブジェクト（たとえば、テーブル）のために「テーブル空間（TableSpace）」番号を記憶する。

ＢＡＳＥ＿ＯＷＮＥＲ♯は、ベースオブジェクトの所有者のためにユーザー番号を保持する。

ＳＰＡＣＥはオブジェクトのサイズを与える。このフィールドは、ごみ箱の中のオブジェクトによって利用される空間の量を見る（たとえば、ブロックの数において）ために使用され得る。

ＣＯＮ♯は、制約に起因して作られるインデックスの場合に、制約ＩＤを記憶する。そうでない場合には、これは「ヌル（ＮＵＬＬ）」になる。

ＳＰＡＲＥ１、ＳＰＡＲＥ２、およびＳＰＡＲＥ３は、将来の実現例において利用されてもよい。

図７においてテーブルのスキーマが記載されてきたので、ドロップされ、ごみ箱に置かれるオブジェクトおよび従属オブジェクトの例を論じることは有益であろう。

ユーザーがオブジェクトをドロップすると、オブジェクトはごみ箱に置かれる。オブジェクトはＯＢＪ＄においてドロップされると印を付けられる（しかし、パージされない）。ユーザーはユーザーの判断でこのオブジェクトをパージできるか、またはオブジェクトは空間圧力を受けて自動的にパージされることになる。

図８は、ドロップされたオブジェクトおよび従属オブジェクトのための項目を示す。この項目は、テーブルＴＡＢＬＥ１およびインデックスＩＮＤＥＸ１（従属オブジェクト）がドロップされたことを示す。これらの項目は、ＴＡＢＬＥ１がドロップされたときに、テーブルに追加された。

示され得るように、ＲＥＬＡＴＥＤフィールドは、ＩＮＤＥＸ１がＴＡＢＬＥ１に関連することを示す。したがって、ＴＡＢＬＥ１がドロップされたので、ＩＮＤＥＸ１はごみ
箱にある。

ユーザーは最初にＴＡＢＬＥ１をドロップしないことをせずにＩＮＤＥＸ１をドロップしないことはできないはずであるが、関連するオブジェクトからの空間が再利用されていなければ、ＴＡＢＬＥ１をドロップしないことはＩＮＤＥＸ１をドロップしないことにもなる。オブジェクトが回復される（ドロップされない）必要があるとき、ごみ箱からの元の所有者情報（たとえば、ＯＷＮＥＲ♯）は、オブジェクトの割当てを元の所有者に戻すために利用されることになる。オブジェクトがパージされる（ユーザーまたは空間再利用プロセスのいずれかによって）ときにのみ、オブジェクトはごみ箱から除去されることになり、空間は空間を要求するトランザクションによって再使用されることが可能である。

上記はこの発明の好ましい実施例の完全な記載であるが、さまざまな代替例、修正例、および等価物が使用され得る。この発明は上記に記載される実施例に適切な修正を行なうことによって同様に適用できることは明らかなはずである。たとえば、テーブルのスキーマがごみ箱を実現するために利用され得るが、この発明は記載される具体的な例に限定されるものではない。したがって、上記の記載は、等価物の全範囲とともに特許請求の範囲の境界によって規定されるこの発明の範囲を限定するものとして捉えられるべきではない。

データベース管理システムのための３段構造の例を示す。 この発明の実施例に関連して利用され得るコンピュータシステムのブロック図を示す。 データベースにおけるいくつかの例示的なオブジェクトのブロック図を示す。 従属オブジェクトがあれば、従属オブジェクトを含むデータベースにおけるオブジェクトをドロップしないプロセスのフローチャートを示す。 オブジェクトがごみ箱から除去され得る複数の方法を示すプロセスのフローチャートを示す。 より多くの記憶空間を得るために、ごみ箱からオブジェクトをパージするプロセスのフローチャートを示す。 データベースシステムにおいてごみ箱を実現するために利用され得るテーブルのスキーマの例を示す。 ごみ箱においてドロップされたオブジェクト（たとえば、テーブル）および従属オブジェクトのための、図７のテーブルにおける項目の例を示す。

Claims (25)

1. データベースシステムにおいてドロップしないことを可能にする方法であって、
   データベースにおいてオブジェクトをドロップするようにコマンドを受取ることと、
   前記オブジェクトをごみ箱に移動することと、
   前記オブジェクトに従属する従属オブジェクトがあれば、前記従属オブジェクトを前記ごみ箱に移動することと、
   前記オブジェクトをドロップしないようにコマンドを受取るとすぐに、前記オブジェクトを前記ごみ箱から移動することとを含む、方法。
2. 前記ごみ箱の中の前記オブジェクトをパージすることをさらに含む、請求項１に記載の方法。
3. 前記オブジェクトはより多くの記憶空間を得るためにパージされた、請求項２に記載の方法。
4. ある量の記憶空間の要求を受取ることをさらに含む、請求項１に記載の方法。
5. 前記量の記憶空間を得るために、前記ごみ箱の中のオブジェクトをパージすることをさらに含む、請求項４に記載の方法。
6. パージされる前記オブジェクトに従属する従属オブジェクトをパージすることをさらに含む、請求項４に記載の方法。
7. 前記量の記憶空間を得る必要があれば、パージされる前記オブジェクトに従属する従属オブジェクトをパージすることと、将来のパージのために任意の他の従属オブジェクトに印を付けることとをさらに含む、請求項４に記載の方法。
8. オブジェクトの一部が前記量の記憶空間を得るためにパージされる必要がなければ、将来のパージのために前記一部に印を付けることをさらに含む、請求項４に記載の方法。
9. 前記ごみ箱はテーブルである、請求項１に記載の方法。
10. 前記テーブルは従属オブジェクトが従属する前記オブジェクトを識別するフィールドを含む、請求項１に記載の方法。
11. データベースシステムにおいてドロップしないことを可能にするコンピュータプログラム製品であって、
    データベースにおいてオブジェクトをドロップするようにコマンドを受取るコンピュータコードと、
    前記オブジェクトをごみ箱に移動するコンピュータコードと、
    前記オブジェクトに従属する従属オブジェクトがあれば、前記従属オブジェクトを前記ごみ箱に移動するコンピュータコードと、
    前記オブジェクトをドロップしないようにコマンドを受取るとすぐに、前記オブジェクトを前記ごみ箱から移動するコンピュータコードと、
    前記コンピュータコードを記憶する、コンピュータが読取可能な媒体とを含む、コンピュータプログラム製品。
12. 前記コンピュータが読取可能な媒体はＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク、テープ、フラッシュメモリ、システムメモリ、ハードドライブ、または搬送波の状態で
    実施されるデータ信号である、請求項１１に記載のコンピュータプログラム製品。
13. ユーザーが前記ごみ箱の中のオブジェクトをドロップしないことが可能であるように、テーブルに情報を記憶し、ドロップされたオブジェクトを示す、ごみ箱を実現するテーブルを含むデータベースを含む、データベースシステム。
14. 前記テーブルは従属オブジェクトが従属する前記オブジェクトを識別するフィールドを含む、請求項１３に記載のデータベースシステム。
15. データベースシステムにおいてドロップしないことを可能にする方法であって、
    データベースにおいてオブジェクトをドロップするようにコマンドを受取ることと、
    前記オブジェクトをごみ箱に移動することと、
    前記オブジェクトに従属する従属オブジェクトがあれば、前記従属オブジェクトを前記ごみ箱に移動することと、
    前記オブジェクトをドロップしないようにコマンドを受取るとすぐに、前記オブジェクトを前記ごみ箱から移動することと、
    より多くの記憶空間が必要であれば、より多くの記憶空間を与えるように前記オブジェクトをパージすることとを含む、方法。
16. ある量の記憶空間の要求を受取ることをさらに含む、請求項１５に記載の方法。
17. パージされる前記オブジェクトに従属する従属オブジェクトをパージすることをさらに含む、請求項１５に記載の方法。
18. 前記量の記憶空間を得る必要があれば、パージされる前記オブジェクトに従属する従属オブジェクトをパージすることと、将来のパージのために任意の他の従属オブジェクトに印を付けることとをさらに含む、請求項１５に記載の方法。
19. オブジェクトの一部が前記量の記憶空間を得るためにパージされる必要がなければ、将来のパージのために前記一部に印を付けることをさらに含む、請求項１５に記載の方法。
20. 前記ごみ箱はテーブルである、請求項１５に記載の方法。
21. 前記テーブルは従属オブジェクトが従属する前記オブジェクトを識別するフィールドを含む、請求項１５に記載の方法。
22. データベースシステムにおいてドロップしないことを可能にするコンピュータプログラム製品であって、
    データベースにおいてオブジェクトをドロップするようにコマンドを受取るコンピュータコードと、
    前記オブジェクトをごみ箱に移動するコンピュータコードと、
    前記オブジェクトに従属する従属オブジェクトがあれば、前記従属オブジェクトを前記ごみ箱に移動するコンピュータコードと、
    前記オブジェクトをドロップしないようにコマンドを受取るとすぐに、前記オブジェクトを前記ごみ箱から移動するコンピュータコードと、
    より多くの記憶空間が必要であれば、より多くの記憶空間を与えるように前記オブジェクトをパージするコンピュータコードと、
    前記コンピュータコードを記憶する、コンピュータが読取可能な媒体とを含む、コンピュータプログラム製品。
23. 前記コンピュータが読取可能な媒体はＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク、テープ、フラッシュメモリ、システムメモリ、ハードドライブ、または搬送波の状態で実施されるデータ信号である、請求項２２に記載のコンピュータプログラム製品。
24. ユーザーが前記ごみ箱の中のオブジェクトをドロップしないことが可能であるように、テーブルに情報を記憶し、ドロップされたオブジェクトを示す、ごみ箱を実現するテーブルを含むデータベースを含むデータベースシステムであって、オブジェクトはより多くの記憶空間が必要であれば前記ごみ箱からパージされる、データベースシステム。
25. 前記テーブルは従属オブジェクトが従属する前記オブジェクトを識別するフィールドを含む、請求項２４に記載のデータベースシステム。

Images