JP2004505380A - ネスト化データベースを実行するための方法、システム及びデータ構造 - Google Patents
ネスト化データベースを実行するための方法、システム及びデータ構造 Download PDFInfo
- Publication number
- JP2004505380A JP2004505380A JP2002515631A JP2002515631A JP2004505380A JP 2004505380 A JP2004505380 A JP 2004505380A JP 2002515631 A JP2002515631 A JP 2002515631A JP 2002515631 A JP2002515631 A JP 2002515631A JP 2004505380 A JP2004505380 A JP 2004505380A
- Authority
- JP
- Japan
- Prior art keywords
- data structure
- database
- lock
- data
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
データの同時使用のリクエストを処理、管理する方法及びシステム。ネスト化されたデータベースによって、データへのアクセスや変更が可能な様々な環境を創出する。現在存在する各トランザクションについて、そのトランザクションと関連するデータベースやサブデータベースの表示や参照を有する。また、問題の各データ・アイテムに対し、どのデータベースやサブデータベースがそのアイテムに関連しているかを示すデータ構造も有する。トランザクション、サブデータベース、データ・アイテムに関するデータ構造の使用により、種々のトランザクションやサブデータベースに対する制御の領域（ｓｐｈｅｒｅ）を創出することができる。これにより、データを複数の利用者間で容易に共有することができる。サブデータベースの創出はデータの複数のコピーを必要とせず、本データベースマネジメントシステムは、所望により複数のコピーも使用できるとはいえ、１部（ｏｎｅ ｃｏｐｙ）のデータを使用するだけで遂行可能である。
Description
【０００１】
【発明の属する技術分野】
本発明は一般にデータベースマネジメントシステムに関し、より詳細には、データベース資源を不適切な使用から守るためにロックマネジャを用いたデータマネジメントシステムやトランザクション処理システムに関する。
【０００１】
本発明は更に、メモリにストアされたコンピュータデータ構造に基づいて、ネスト化データベースの使用を許容するデータベースマネジメントシステムの実行方法にも関する。加えて本発明は、共有データへの同時アクセスを提供する如何なるシステムにも関するものであって、またそのようなシステムに適用できる。
【０００２】
【従来の技術、及び発明が解決しようとする課題】
二人の人や二グループの団体が同時に或るデータベースやその他のロケーションに存在する情報にアクセスしたい時、あるいは同時か殆ど同時に同一の情報に関するデータベースにデータを書き込みたい時に存在する問題として、コンフリクト等の問題は避けることができない。このような問題は、データが共有されるタイプのアプリケーションでは如何なるアプリケーションでも起こりうるものであって、ワード・プロセッシングとエンジニアリング設計は、そのような同時アクセスが起こる２つの領域である。但し、本発明はこれら二領域に加え、二以上のグループが同一のデータを使用したいと希望する如何なる状況に対しても適用可能である。
【０００３】
データベースマネジメントシステムにおいては、ＡＣＩＤ （”Ａｔｏｍｉｃｉｔｙ， Ｃｏｎｓｉｓｔｅｎｃｙ， Ｉｓｏｌａｔｉｏｎ， Ｄｕｒａｂｉｌｉｔｙ”）と称される特性が望まれる。
【０００４】
Ａｔｏｍｉｃｉｔｙ（アトミック性）とは、トランザクション（即ちデータベースへの変更）の結果が全て正しくデータベースに反映されているか、あるいはトランザクションの結果のいずれも全く反映されていないことを意味する。一般に、トランザクションについては「コミット（確認）」あるいは「アボート（中止）」という表現が用いられる。トランザクションが確認されると、このトランザクションによってデータベースになされた全ての変更が恒久的に保存され、データベースは定常状態に置かれる。
【０００５】
トランザクションが中止されると、このトランザクションによってデータベースになされた如何なる変更も撤回され、この場合もやはりデータベースは定常状態（ｃｏｎｓｉｓｔｅｎｔ ｓｔａｔｅ）に置かれる。
【０００６】
Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）とは、各トランザクションがデータベースに対し矛盾のない結果のみを確認することを意味する。
【０００７】
よって或るトランザクションによって、データベースは或る一定常状態から他の或る一定常状態にされなければならない。
【０００８】
Ｉｓｏｌａｔｉｏｎ（隔離性）とは、トランザクション内の事象が同時的に進行している他のトランザクションから隠されていなければならないことを意味する。同時的トランザクションは互いに干渉してはならない。それらトランザクションはあたかも専用のデータベースを有するがごとくに実行されなければならない。
【０００９】
Ｄｕｒａｂｉｌｉｔｙ（継続性）とは、一旦トランザクションが完了し、その結果がデータベースに対し確認されてしまうと、その後如何なる動作不良があってもこれらの結果が生き残り続けることをシステムが保障しなければならないことを意味する。
【００１０】
上記のＡＣＩＤ 特性は非常に望ましいものであるが、同一のデータに書込む者が複数存在すると、通常、ＡＣＩＤ 特性との妥協が必要となる。トランザクションの諸特性を確実にし且つ同時に各人又は各トランザクションがしようとしていることを何であれ許容することは非常に困難である。
【００１１】
或るデータが使用されている時に、他者に対し単純に該データへのアクセスを許容すると、ＡＣＩＤ 特性との不可避なコンフリクトが顕在化する。
【００１２】
【課題を解決するための手段】
従って、本発明の一目的は、同一のデータに複数の団体がアクセスできるようにすることである。本発明の更なる目的は、複数のユーザが存在する環境で、可能な限りＡＣＩＤ 特性が維持されるよう、データをロックすることである。本発明の更なる目的は、複数のユーザや団体が、種々の異なるデータベース（以下、これら異なる各種データベースを、単にデータベースと称するかあるいはバーチャルデータベース、サブデータベースと称する）を経由してデータにアクセスできるようにするデータベースマネジメントシステムを提供することである。本発明の更なる目的は、サブデータベースやバーチャルデータベースの実行を許容するデータベースマネジメントシステム及び／又はそのデータ構造を提供することである。
【００１３】
これら及びその他の目的は、複数のユーザが存在する環境で、データの同時実行制御とロックを許容する、データ構造を有するメモリ、方法、システム、及びコンピュータプログラム製品によって達成される。現在存在するトランザクションについて、そのトランザクションに関連するデータベース又はサブデータベースへの関連付けや参照（リファレンス）を有する。トランザクションに関係するこのデータ構造を以下、トランザクション制御ブロックと称する。
【００１４】
データ構造（本明細書ではこれをデータベース制御ブロックと称する）は、どのデータベースあるいはサブデータベースがデータ・アイテムに関係しているかを示す。更に、そのデータについての実際のロックに関係するデータ構造が存在し、これをロック制御ブロック（及び／又はロックリクエストブロック）と称する。
【００１５】
種々のデータ構造間の関連付けにより、ネストされたデータベース、サブデータベース、バーチャルデータベースという概念を実現させることができる。例えば、データ構造アレンジメントは、好ましくは特定のトランザクションのコンテキストデータベースに関する判断（ｄｅｔｅｒｍｉｎａｔｉｏｎ）が存在することを許容すると共にそのトランザクションの下のサブデータベースを許容する。更に、トランザクションに関係するデータ構造は、そのデータのロックに関するデータ構造によって表される、許可されたあるいは許可待ちのロックリクエストへの参照を含む。バーチャルデータベースに関係するデータ構造、即ちデータベース制御ブロックは、ロッキングデータ構造として参照され、ロックが関係するのはいずれのデータベースあるいはサブデータベースであるのかを決定できるようになっている。
【００１６】
本発明の一実施形態では、データ処理システムによってアクセスされるデータをストアするためのメモリが存在する。このデータは必ずしもエンドユーザが究極的に欲しているデータ・アイテムである必要はなく、ロッキングとサブデータベース情報を示すデータ構造に関係するデータであることができる。メモリは、トランザクションの情報を含むデータ構造を有する。好ましくは、このデータ構造はトランザクション制御ブロックとして実現される。メモリは更にトランザクションのデータのロックの情報を含むデータ構造を有する。このデータ構造を、以下、ロック制御ブロック及び／又はロックリクエストブロックと称する場合がある。更に、複数データベースの情報を含む複数のデータ構造が存在する。種々のデータベースに関係するこれらのデータ構造を、データベース制御ブロックと称する場合がある。このデータベース制御ブロックを用いて特定のデータベースやサブデータベースをロック及びトランザクションに関連付け、あるいはその逆に関連付け、ネスト化データベースあるいはサブデータベースを適切に制御する。
【００１７】
本発明はまた、ネスト化データベースあるいはサブデータベースの概念を実現化する、データ構造の作成（ｃｒｅａｔｉｏｎ）と使用に関する。あるデータ・アイテムがロックされていることを示す一方法は、第一の階層レベルと関連する第一のトランザクションによってそのデータ・アイテムがロックされていることを示すデータ構造をこの第一の階層レベルに作成する種々の段階を含む。
【００１８】
更に、本発明方法は、データ・アイテムが第二の階層レベルと関連する第二のトランザクションによってロックされていることを示すデータ構造を第二の階層レベルに作成する段階を含む。かくして、これら段階は、制御されたデータ構造（ロック制御ブロック等）の階層を作成する。階層における各レベルは異なるデータベース、サブデータベース、又はバーチャルデータベースによって使用されることができる。
【００１９】
或るデータ・アイテムへのアクセスを達成するためには、最初に判断しなければならないことがある。それはそのデータ・アイテムに関してロックが存在するかどうかという点である。これについては次の各ステップを追うことによって決定できる：（ａ） 第一の階層レベルにそのデータ・アイテムに対するロックが存在するかどうかを判断するステップ、及び （ｂ） ステップ（ａ）でそのデータ・アイテムに対するロックが存在しないと判断された場合、第一の階層レベルにおいてそのデータ・アイテムに対するロックを作成するステップ。
【００２０】
ステップ（ｃ）は、ステップ（ａ）でそのデータ・アイテムに対するロックが存在しないと判断された場合、第二のレベルに該データ・アイテムに対するロックが存在するかどうかを判断するステップである。更に、ステップ（ｄ）は、そのデータ・アイテムに関するロックが第二の階層レベルに存在しないと判断された場合、該データ・アイテムに関するロックを作成するステップである。
【００２１】
上記の機能を実行する方法の各ステップに加え、本発明は、上記機能を行使するための各種手段を有するシステムを包含する。更に、本発明は、本方法を実施するための実行可能な指令を含むコンピュータプログラム製品も包含する。
【００２２】
【発明の実施の形態】
本発明とその利点については、添付の図面を参照することによってより完全な理解に到達できるであろう。
以下、図を参照して本発明を説明する。各図面を通して、同一の参照番号は同一又は対応する部分を示す。図１はデータベースマネジメントシステム（ＤＢＭＳ）１００を示す。トランザクションオペレーション及びマネージメント（管理）はトランザクションマネージャ１０２及びロックマネージャ１０４で処理されるが、これらは両者ともシステムのデータプロセッサ即ちＣＰＵ１０６によって実行されるソフトウエア手続である。トランザクションマネージャは、許可待ち中のトランザクションのアイデンティティとステータスの追跡履歴（ｔｒａｃｋ）を残すためにトランザクションテーブル１０８（これはツリー構造として実施されることもある）を維持する。ロックマネージャ１０４はロックテーブル１１０を維持するが、これは通常ハッシュテーブル及び種々のリンクしたリスト及び／又はツリー構造（以下により詳細に記述する）を使用して実施される。ロックテーブル１１０はデータベース１１２中の資源に関してリクエストされたロックの追跡履歴を保持する。ロックテーブル１１０は、トランザクションのメモリアドレス、トランザクションＩＤ、ロックのタイプやモード、ロックのパラメータ、ロックと関連したデータベースやサブデータベースに関係する情報を蓄えてもよい。データベース１１２は、ＤＢＭＳ１００によって実行されるトランザクションにアクセス可能なデータを保存する。データベース１１２は永続的なデータを保存する必要はない（但し通常の場合は永続的なデータ保存である）。別の方法では、保存されたデータは暫定的であってもよい。従って、データベースの内容について共同的に作業しているトランザクションは、ほんの数分、数時間、又は数日だけ存在するデータ資源を処理出来、システムが取り出されるかシャットダウンされた場合には存在しなくなるであろう。
【００２３】
またＤＢＭＳ１００は、通常、付加的メモリ資源１１４、システムの種々の部分を相互接続するための一以上のシステムバス１１６、及びネットワークインターフェース１１８やクライアントワークステーション１２０との通信を取扱うための他の通信インターフェースを含む。メモリ１１４は、ランダムアクセスメモリを含むがそれに限定されない如何なるタイプのメモリを使用して提供されてもよく、好ましくは、読出し可能で且つ書込み可能なメモリである。更に、メモリ１１４は本発明のデータ構造を保存するために利用してもよい。図１は本発明の一つの可能な実施例を示すが、本発明の機能を達成するために、任意の所望のハードウエア及びソフトウエアを利用できる。例えば、本発明は、任意のタイプのコンピュータ、コンピュータサーバ、及び／又はパーソナルコンピュータ及び／又は任意の所望のオペレーティングシステムが動作するハードウエアを使用して実施できる。係るハードウエアの構成要素、構造、及び作用は周知である。
【００２４】
図２を参照すると、好ましい実施形態における「ロックテーブル」１１０が次のように提供される。ハッシュ関数１５０を用いて、資源識別子（ＲＩＤ）を、固定したサイズを有するように提供されるハッシュテーブル１５２内のハッシュテーブルアドレスに変換する。関数１５０によってハッシュされる資源識別子は、資源のタイプやレベルの標識（例えば、ロックされるべき資源は、データベース、テーブル、ページ、組（ｔｕｐｌｅ）、その他の何れであるかを示す）及び資源の開始アドレスを含んでもよい。ハッシュテーブルのスロット１５４−１等の各アドレス可能なスロット１５４は、そのスロットのハッシュテーブルアドレスに対応するロックされた資源がない場合のヌル値か、ハッシュ値がそのスロットのハッシュテーブルアドレスに対応する一以上のロックされた資源が有る場合には、ＬＣＢ１６０−１等のロック制御ブロック（ＬＣＢ）のリストへのポインタの何れかを含む。
【００２５】
ロックマネージャは、実際にロックされる各ロック可能なデータ・アイテムに対して一ロック制御ブロック（ＬＣＢ）１６０を割り当て（即ち生成し記憶される）、トランザクションが有する各ロックに対してＬＲＢ１６２−１等の一ロックリクエストブロック（ＬＲＢ）１６２を割り当てる（即ち生成し記憶される）であろう。従って、もし特定のデータベースの一オブジェクトが三つの異なるトランザクションによって所定の時点でロックされる場合には、そのオブジェクトに対してＬＣＢ１６０が一個と、そのＬＣＢから“ぶら下がっている（ｈａｎｇｉｎｇ）”リンクした３個のＬＲＢ（トランザクション当たり一）のリストとが存在するであろう。
【００２６】
各ＬＣＢ１６０は好ましくは次のものを含む：
ロックされた資源に対する資源識別子のコピーを通常含むロックＩＤ １７０と、
このＬＣＢによって表わされるデータベース資源に関して認められた（ｇｒａｎｔｅｄ）全てのロックの最も制限的なアクセスモード（例えば、ブラウズ、読出し、パラメータ化された読出し、書込み、パラメータ化された書込み、又は排他（ｅｘｃｌｕｓｉｖｅ））を示すモード標識１７１と、
ロックされた資源の未処理の（ｏｕｔｓｔａｎｄｉｎｇ）パラメータ化された読出しロック（もし有れば）によって使用される読出しパラメータの論理ＯＲを表わす、好ましくはビットマップの形態にある、任意的読出しパラメータ標識１７２と、
ロックされた資源の未処理のパラメータ化された書込みロック（もし有れば）の書込みパラメータ、好ましくはビットマップの形態にある、オプショナル書込みパラメータ標識１７３（なお、読出し及び書込みパラメータ標識１７２及び１７３の詳細によって本発明の様相が更に構成されるものであるがこれについては、Ａｎｆｉｎｄｓｅｎに付与された米国特許第５，９８３，２２５号に詳細に記載されており、それを本明細書の一部を構成するものとしてここに援用する）と、
このＬＣＢによって表わされるデータベース資源のための認められた資源リクエストに対するＬＲＢ １６２のリストへの認められたリクエストリストポインタ１７４と、
このＬＣＢによって表わされる許可待ち（即ち、未だ認められていない）資源リクエストに対するＬＲＢ １６２のリスト（キュー（ｑｕｅｕｅ）とも呼ばれる）への許可待ちリクエストポインタ １７５と、
このＬＣＢが属するデータベース又はサブデータベースへの参照であるデータベースフィールド１７７とを含む。本発明の特徴は、データは、本明細書ではサブデータベース、バーチャルデータベース、データベースとして参照される異なるデータベースに分割されてもよいということである。係る分割を行うことにより、同一のデータを使用する人やトランザクションが複数あることが可能である。係るシステムにおいて、本発明者は、或るロックがどのデータベースに属するかを知ることが望ましく、また係る情報はデータベースフィールド１７７を使用して容易に決定され得ることを見出した。本発明の特徴はデータベースリファレンス１７７等のリファレンスを使用して実現されるが、ＬＣＢ内のデータベース名を含むような他の実施形態も可能である。図２では、データベースリファレンス１７７はグローバルデータベース１９２を参照している。
【００２７】
このグローバルデータベース１９２は最高レベルのデータベースであり、更なるサブデータベースは、ＤＢ１、ＤＢ２、・・・ＤＢｎとして言及される。サブデータベース使用の更なる詳細を以下に説明する。即ち、
ネクストレベルＬＣＢリファレンス１７８は、サブデータベースロック制御ブロック（ＳＬＣＢ）１６４−１等のサブデータベース（異なる階層レベルでのバーチャル又はサブデータベース）ロック制御ブロックを示し（このリファレンスは、ヌルか、又は異なる階層レベルでのサブデータベースロック制御ブロックの何れかを参照する。このフィールドに関する更なる情報を以下に述べる）、そして
このＬＣＢと同一のハッシュアドレスを共有する次のＬＣＢ（もし有れば）への次のＬＣＢポインタ１７６。
【００２８】
ＬＣＢ １６０内のフィールド１７２及び１７３によって表わされる読出しパラメータと書込みパラメータは、本発明にとって必須ではないが、本発明におけるサブデータベースの発明と合わせて又は切り離して使用されてもよい特徴を表わす。更に、パラメータ１７２及び１７３は、ＤＢＭＳによって使用される従来のアクセスモードへの本発明による拡張を表わす。読出し／書込みパラメータドメインの定義されたセットの各異なる値が、対応するデータの信頼性の分類又はカテゴリーを表わす。従って、８個のパラメータ値（各々８−ビットパラメータフイールドの対応するビットによって表わされる）を有するパラメータドメインは、８個迄の異なるデータ信頼性分類を定義することが可能であろう。本発明の別の実施形態においては、パラメータを、“信頼性”以外のデータベースオブジェクトのプロパティ（例えばオブジェクト上に書込みロック状態を作るアプリケーションのタイプやそのＩＤ、又は書込みロックされていてもデータを読もうとするか否かを判断するためにアプリケーションによって使用され得る他の情報等）を示すために使用してもよい。
【００２９】
許可された（ｇｒａｎｔｅｄ）又は許可待ちの一ロックリクエストを表わす各ＬＲＢ １６２は、好ましくは、次のものを含む：
特定のトランザクションによって資源がアクセスされるかリクエストされるアクセスモード（例えば、ブラウズ、読出し、パラメータ化された読出し、書込み、パラメータ化された書込み、又は排他（ｅｘｃｌｕｓｉｖｅ））を示すモード標識１８１と、
このＬＲＢに対応するロックをリクエストしたかあるいは保持するトランザクションを同定するトランザクション識別子１８４と、
この読出し又は書込みロックの所有者によって使用される読出し又は書込みアクセスモードパラメータ（もし有れば）を表わす、好ましくはビットマップ形態にある、任意的パラメータ標識１８２（このフィールドは、このロック又はロックリクエストされる所有者がパラメータ化されたアクセスリクエストを使用している場合にのみ使用される。ロック制御ブロックのパラメータ１７２及び１７３のように、パラメータフィールド１８２は、本発明に係るネスト化データベースやサブデータベースを実施するために必須ではなくまた、必要でもない）と、
トランザクションＩＤ １８４によって同定されるトランザクションＴ１等のトランザクションによって所有されるＬＲＢのリンクしたリストを形成するために使用されるロックセットポインタ１８５（なお、ＬＲＢのリンクしたリストは、二重にリンクしたリスト等の更なる特徴を含むように実施されてもよく、それによりＬＲＢのチェーンを二方向にトレースすることが可能になる。ＬＲＢの更なる別態様が以下に記載される）と、
このＬＲＢと同一のデータベース資源に対するネクストＬＲＢ（もし有れば）へのネクストＬＲＢポインタ１８６。
【００３０】
ＬＣＢの読出し及び書込みパラメータフィールドとＬＲＢのアクセスモードパラメータフィールドに対する典型的なサイズは１〜２バイトで、８〜１６個の別個のパラメータ値をサポートする。
【００３１】
サブデータベースＬＣＢ（ＳＬＣＢ）１６４−１は、ＬＣＢ １６０−１ と同一又は類似の構成を有している。従って、サブデータベースＬＣＢ１６４は、サブデータベースのデータに対するアクセスのロックを制御するために ＬＣＢが使用されることを明確に示すためにＳＬＣＢと呼ぶ。図２において、ＳＬＣＢ １６４−１からサブデータベースＤＢ１ へのリファレンス又はポインタはデータベースリファレンス１７７ であり、 ＳＬＣＢ １６４−１ はサブデータベースＤＢ１ に接続されていることを示している。同様に、ＬＣＢ １６０−１ のデータベースリファレンス１７７ はグローバルデータベース１９２ を参照する。しかしながら、ＤＢＭＳは、全ての ＬＣＢ、或いは少なくとも第一レベルのＬＣＢ がグローバルデータベース１９２ を参照するようにセットアップできるため、 ＬＣＢからデータベースリファレンスフィールド１７７ を削除することが可能てあり、好ましい。
【００３２】
本明細書全体を通して、図面は、一つのフィールドから図中の他のアイテムを指定するポインタとして現れるもを示す。これらのポインタは、従来のコンピュータのポインタに限定されず、任意のタイプのリファレンス又はツリー構造として実施できる。更に、参照する情報をデータ構造自体に含めてもよい。したがって、フィールド１７７ がグローバルデータベース１９２ を参照する代わりに、グローバルデータベース１９２ に関連する情報をフィールド１７７ に入れてもよい。以下に詳細に説明するが、グローバルデータベース１９２ 及びサブデータベースＤＢ１ 、ＤＢ２ 、．．． 、ＤＢｎ を含む種々のデータベースはデータベース制御ブロック（ＤＢＣＢ）であり、好適な実施形態では、エンドユーザが最終的に必要とするデータを含んでいない。むしろ、データベース制御ブロックは、データベース又はサブデータベースの何れにロック又はロック制御ブロック（即ち、ＬＣＢ ）が関係しているのかを示すのに使用される。
【００３３】
ＳＬＣＢ １６４−１は、ＬＲＢ １６２−１と同一の構造を有するＬＲＢ １６２−２ を参照する。図２は、二つのトランザクション制御ブロックＴ１、Ｔ２も示す。トランザクションＴ１はグローバルデータベースと関連付けられ、トランザクションＴ２はサブデータベースＤＢ１ と関連付けられている。更に、トランザクションＴ１は、 ＬＲＢ １６２−１を参照することにより許可ブロックリクエストを得る。同様に、トランザクションＴ２はＬＲＢ １６２−２ を参照する。これは、トランザクションＴ２がサブデータベースＤＢ１ に関連するデータにロークを有していることを示す。
【００３４】
本発明においては、ロックマネージャの主要部分はロック制御ブロック（ＬＣＢ） である。従来のデータベースマネジメントシステムのように、ＬＣＢ は、ロック可能な資源、例えば、リレーショナルやテーブルやレコードにおけるオブジェクト、ロー（組）を特定する。
【００３５】
そのような資源は通常オブジェクト ＩＤ（”ＯＩＤ”）、組ＩＤ（”ＴＩＤ”） 、ＲＯＷ／ＲＥＣＯＲＤ ＩＤ（”ＲＩＤ”）によって特定される。説明を簡単にするために、これらのＩＤ全体を示す用語としてＲＩＤ と言う語を使用する。
【００３６】
図２ではハッシュテーブルが示されているが、本発明はハッシュテーブルを用いたものに限定されない。考慮すべき点は、対応するＬＣＢ を見つけるのにＲＩＤ を使用するのが好ましく、ハッシュテーブルが好適な手段であることである。しかしながら、アレーやその他のサーチ型構造を用いることもでき、本発明はハッシュテーブルの使用に限定されない。
【００３７】
或るＲＩＤ には如何なるトランザクションによってもロックが設定されない場合、簡便な方法は、データ構造内にそのＲＩＤ のためのＬＣＢ を設けないことである。即ち、ハッシュテーブルから到達可能な ＬＣＢは、現時点における少なくとも一つのトランザクションによってロックされる可能性のある資源等の、全てのロック可能な資源のサブセットを表しているにすぎない。
【００３８】
ＬＣＢ を一方向にリンクするための別の方法として、二重にリンクされたリスト設けることができ、これによりＬＣＢ のチェーンを両方向にトレースすることが可能となる。各ロック可能な資源について、問題となっている資源に対してロックを保持するトランザクションが複数存在することが可能である。許可されたか或いは許可待ちのロックリクエストは、ロックリクエストブロック（ＬＲＢ） によって表される。各ＬＲＢ がそのＬＣＢ をリファーバック又は参照することが好ましい。この特徴は、簡明化とスペースの観点から図面には含まれていない。また、二重リンク構造を用いてＬＲＢ チェーンを提供することも可能であり、これにより、ＬＲＢ のチェーンを両方向にトレース（追跡）することが可能となる。更に、最初の ＬＲＢがＬＲＢ のチェーン内の最後のＬＲＢ を参照することも可能である。これにより、チェーンの終端を可能な限り速く見つけ出したいとき（例えば、待ちリストの終りに新しい ＬＲＢを挿入するとき）の性能を向上できる。例えば、この特徴を提供するためには、図３において、ＬＲＢ １６２−５ はＬＲＢ １６２−７ を参照する。
【００３９】
図３は、本発明で使用するデータ構造の例である。
【００４０】
しかしながら、簡明化のためにＤＢＣＢは示されていない。トランザクション制御ブロック（ＴＣＢ）Ｔｌ及びＴ２はトランザクションを表す。トランザクションは多くのロック、従って多くのＬＲＢ を持つことができ、一ＬＲＢ は一トランザクションのみに属するのが好ましい。各ＴＣＢ に対して一組のＬＲＢ が維持されている。図では、破線を用いてＬＲＢ 間の関係及び ＴＣＢからＬＲＢ への関係を表している。ＬＲＢ を二重リンクリストの形態で構成することもでき、更に、各ＬＲＢ がそのトランザクション制御ブロックを参照するようにＬＲＢ を設けることできる。例えば、この場合、図３の各ＬＲＢ１６２は ＴＣＢ Ｔ１ 又はＴＣＢ Ｔ２の一方を参照する。
【００４１】
本発明の ＬＣＢ及びＳＬＣＢのデータ構造から明らかなように、ロック可能な資源とデータベースを表すために一つのＬＣＢ が使用される。即ち、ＬＣＢ は特定のデータベース内のロック可能な資源（グローバルデータベース又はその中のサブデータベースの一つｔ）を表す。
【００４２】
図４はロッキングに用いるデータ構造を示し、各 ＬＣＢ（又はＳＬＣＢ）は単一のデータベース、従って単一のデータベース制御ブロック（ＤＢＣＢ）に関連しているのが好ましいことを示すために提供されている。例えば、図１においては、ＳＬＣＢ １６４−１はＤＢ１ を参照し、ＳＬＣＢ １６４−２はＤＢ２ を参照し、ＳＬＣＢ １６４−３はＤＢ１ を参照し、ＳＬＣＢ １６４−４はＤＢ２ を参照する。必要に応じ、グローバルデータベースのためのデータベース制御ブロックを持つことを回避することも可能である。何故なら、最も低い階層レベルにある ＬＣＢの各々はグローバルデータベースに属し、ＬＣＢ 及びトランザクションに対してのデフォルトであると考えることができるためである。この場合、グローバルデータベースとの関係を示すために ＬＣＢ及びＴＣＢ からの参照が適宜使用される
【００４３】
更に、図４は、任意数のレベルのサブデータベースをどの様にして作ることができるかを示す。上で述べたように、ＳＬＣＢの構造をＬＣＢ の構造と同一にすることが可能であり、サブデータベースのためのＬＣＢ をグローバルデータベースのためのＬＣＢ と区別するために、本特許出願では上記のようなラベリングを行った。しかしながら、ＬＣＢ をチェーンで結ぶために使用される「ｎｅｘｔ ＬＣＢ ｒｅｆｅｒｅｎｃｅ」を用いることなくＳＬＣＢを設けることによりメモリをある程度節約できる。しかしながら、必要に応じ、ＳＬＣＢを一方向に相互にリンクするか、或いは必要であれば二重リンクにすることもできる。図４では、ＬＣＢ １６０−１ 及び１６０−２ は第一レベルのＬＣＢ であり、グローバルデータベースに関連付けられておいる。ＳＬＣＢ １６４−１及び１６４−３ は第二レベルのＬＣＢ であり、第一レベルのＳＬＣＢと考えることもできる。ＳＬＣＢ １６４−２及び１６４−４ は第三レベルのＬＣＢ，、即ち第二レベルのＳＬＣＢである。同一レベルのＳＬＣＢ間のオプションのリンクは、破線の矢印又は参照記号によって表されており、二重リンクを設け、ＳＬＣＢ １６４−３がＳＬＣＢ １６４−１も参照できるようにすることも可能である。
【００４４】
図５は、好ましい実施形態では、各トランザクションが単一のデータベースに属していることを示す。トランザクション制御ブロックＴ１、Ｔ２、Ｔ３、．．． 、Ｔｍはそれぞれ、単一のデータベース制御ブロックを参照する。従って、特定のトランザクションに関連するデータベース又はサブデータベースのレベルを決定することが可能である。
【００４５】
図６はデータ構造の例を示し、好ましい実施形態のトランザクションはそれら自身のデータベース内の資源のみにアクセスする。例えば、実線の矢印を用いてグローバルデータベース１９２ を参照するトランザクションＴ１の場合、トランザクションＴ１は、破線の矢印を用いて ＬＲＢ １６２−１及び１６２−３ も参照するが、ＬＲＢ １６２−１ 及び１６２−３ の各々は、ハッシュテーブル１５２ によって参照される第一レベル即ち ＬＣＢレベルと関連付けられている。又、トランザクションＴ２及びそのトランザクション制御ブロックはサブデータベースＤＢ１ を参照するか又はその一部であり、破線の矢印を用いて ＬＲＢ １６２−２及び１６２−４ を更に参照するが、 ＬＲＢ １６２−２及び１６２−４ は、第二ＬＣＢ レベル即ち第一ＳＬＣＢレベルと関連付けられ、且つ ＤＢ１と対応している。好ましい実施形態においては、トランザクションは単一のデータベースのコンテキスト内で行われる。更に、トランザクションのデータベースの範囲内でない資源にトランザクションがアクセスすることを阻止するのが好ましい。実施レベルでは、これにより、トランザクションのＬＲＢ は、そのトランザクションのトランザクション制御ブロックが参照するのと同一のデータベース制御ブロックを参照する ＬＣＢ（又はＳＬＣＢ）に属するか又は関連付けられている。例えば、図６では、Ｔ２は ＤＢ１内で実行される。
【００４６】
従って、Ｔ２（１６２−２及び１６２−４）のＬＲＢ は、同一のデータベースＤＢ１ を参照するＬＣＢ（ＳＬＣＢ１６４−１ 及び１６４−２）に属する。
【００４７】
図７は、データベース制御ブロック（ＤＢＣＢ）の実施例を示す。好ましい実施形態では、ＤＢＣＢに対して、エンドユーザが最終的に必要とするデータを記憶することはリクエストされておらず、ＤＢＣＢの目的は、ＬＣＢ 又はＳＬＣＢによって少なくとも部分的に表されるロックがどのデータベース又はサブデータベースに属するかを示すことである。
【００４８】
図７では、ＤＢＣＢ ２０２は、ＩＤと略された識別子フィールド２０４ を含む。このフィールドはＤＢＣＢの名称又は識別情報を示す。アクティブトランザクションフィールド２０６ （Ａｃｔ Ｔｘと略す）は、問題となっているデータベース又はサブデータベース内において現時点でアクティブになっているトランザクションへのＤＢＣＢからのトレースを可能にする。例えば、サブデータベースの所有者がサブデータベースをコミット又は終了することを望む場合、上記の機能は望ましい。システムは、サブデータベースのアクティブトランザクションが何であるかを決定しなければならず、もしアクティブトランザクションのリストが空でない場合、サブデータベースの所有者は、サブデータベース内で他の作業が行われていることを示すと共に、現時点でそれらのトランザクションを終了することが望ましいか否かを問い合わせる警告を得る。サブデータベースを終了することについて責任を有する者（ｅｎｔｉｔｙ）に、終了の決定を変更する可能性を与えることが望ましい。
【００４９】
或いは、サブデータベース内においてアクティブトランザクションが実行されている時点ではサブデータベースを終了できないようにシステムを構成することも可能である。この場合、トランザクションを終了させ、アクティブトランザクションが存在しない時だけサブデータベースの終了が許容されるようにしなければならない。そのようなチェックがない場合、システムはトランザクション状態を停止し、データベース・マネジメントシステムの特性が望ましくない状態になるであろう。
【００５０】
アクティブトランザクションフィールド２０６ は、全てのアクティブトランザクションのリストを含むリンクされたリストの一部である単一のリファレンス又は複数のリファレンスを含んでいてもよく、或いは、アクティブトランザクションの名称又は識別情報を含んでいてもよい。それに加えるか又はそれに代え、アクティブトランザクションフィールドは、問題となっているデータベース又はサブデータベースのためのアクティブトランザクションの各々を参照する二重リンクリストを用いて実施することもできる。
【００５１】
所有トランザクションフィールド ２０８ （Ｏｗｎ Ｔｘと略す）は、問題となっているＤＢＣＢを作り、従ってそれを所有するトランザクションへの参照である。グローバルデータベースの場合、このフィールドはヌルリファレンスに設定されるであろう。また、サブデータベースの場合、このフィールドは、その作成／所有トランザクション制御ブロックを参照する。スーパーデータベースフィールド２１０ （Ｓｕｐ ＤＢと略す）は、このデータベースによってその一部を構成しているデータベースを表すＤＢＣＢへの参照である。
【００５２】
サブデータベースフィールド２１２ （Ｓｕｂ Ｄｂと略す）は、このデータベースのサブデータベースを表すＤＢＣＢのセットへの参照である。ネクストデータベースフィールド２１４ （Ｎｅｘｔ ＤＢと略す）は、データベース階層の同一レベル内の次のＤＢＣＢを参照する。先の（ｐｒｅｖｉｏｕｓ）データベースフィールド２１６ （Ｐｒｅｖ ＤＢと略す）は、サブデータベース階層の同一レベル内の前の ＤＢＣＢ への参照である。Ｎｅｘｔ ＤＢ 及びＰｒｅｖ ＤＢ フィールドは、サブデータベース階層内の或るレベルにおけるＤＢＣＢの二重リンクリストを作るために使用される。
【００５３】
このようにして、親データベースが同一であるサブデータベースが上記のリスト内でリンクされる。ＤＢＣＢ ２０２の最後のフィールドの３個の点又は楕円は、必要に応じて追加のフィールドがＤＢＣＢに含まれることを表している。
【００５４】
ＤＢＣＢ の目的は、資源階層又はデータベース階層において、ロック等の特定のものが属している場所を具体的に高精度で示すことである。これにより、サブデータベースとシステムの残部との関係を簡単に決定することが可能になる。
【００５５】
上記した ＤＢＣＢ 及び以下に詳述するトランザクション制御ブロック（ＴＣＢ） に関して、これらのデータ構造内に多数のフィールドが含まれているが、このフィードは各図に示されていない。参照の数を理解可能な範囲に抑え、且つ分かり易くするために、参照の内には図示しないものもある、即ち不要なものもある。したがって、図面に参照が含まれていないという事実は、参照が存在しないことを意味するものと解釈してはならず、同様に、データ構造が特定の参照又はフィールドを含むという事実は、そのような参照がそのデータ構造の絶対条件であると解釈してはならない。好ましくは、ＤＢＣＢは階層を形成している。
【００５６】
しかしながら、 ＤＢＣＢ を階層に配置しない構成も可能である。
【００５７】
図８はトランザクション制御ブロック（ＴＣＢ） データ構造２２２を示す。このデータ構造は、アクティブトランザクションを示し、トランザクションが属しているデータベース又はサブデータベースのレべルを示し、及び／又はトランザクションのロックされた資源とロックの状態を決定するために使用される。
【００５８】
ＴＣＢ 内には、例えば、トランザクションの名称を識別する識別子フィールド２２４ が設けられている。コンテキストデータベースフィールド２２６ （Ｃｔｘｔ ＤＢ と略す）は、問題となっているトランザクションについての範囲又はコンテキストを表す、データベースのＤＢＣＢを参照するために用いられる。
【００５９】
これは、トランザクションの作成時に決定されるであろう。本発明の実施形態によれば、トランザクションが発生してからそれが終了するまでトランザクションは存続し、その全ての動作を単一のデータベース内で行う。好ましい実施形態においては、トランザクションの存続期間の開始から終了まで単一のコンテキスト内にトランザクションを存在させるルールを用いることにより本発明は能率的に且つ適切に動作する。このように、コンテキストデータベースフィールド２２６ は、問題となっているトランザクションの範囲又はコンテキストを表すために使用される。例えば、コンテキストデータベースフィールド２２６ はグローバルデータベースを参照する。これは、ＴＣＢ に対応するトランザクションはグローバルデータベース内で実行されるか、又はそのコンテキストデータベースとしてグローバルデータベースを有していることを意味する。
【００６０】
図８のサブデータベースフィールド２２８ は、このトランザクションが作成したサブデータベースのセットを表すために使用される。なお、このフィールドを空にするか又はヌルを参照するようにすることも可能である。トランザクションは多数のサブデータベースを作成することが可能で、従って、多数のサブデータベースを所有することが可能である。
【００６１】
実行されているアクションの種類によっては、特定のトランザクションのためにどれだけ多くのサブデータベースが存在しているかを決定することが望ましい場合がある。従って、トランザクションを終了することが望ましくなった時点で、そのトランザクションが実行される前に存在していたサブデータベースを知ることが好ましい。同様に、既に説明したように、データベース制御ブロックのためのサブデータベースを知ることが望ましい。
【００６２】
フィルド２３０ はＴＣＢ の許可されたロックリクエストを表し、フィールド２３４ はＴＣＢ の許可待ちのロックリクエストを表す。図面、例えば図６に示すように、これらのフィールド２３０ 及び２３４ は、 ＴＣＢからＬＲＢ への参照を用いて作成される。
【００６３】
必要な場合、トランザクション又はＴＣＢ の階層を維持するためにスーパートランザクションフィールド２３６ が用いられる。スーパートランザクションフィールド２３６ は、問題となっているトランザクションよりも階層の高いトランザクションを参照又は指定する。例えば、問題となっているトランザクションを作成したか又はそのトランザクションの作成を許可したトランザクションを参照するためにトランザクションフィールド２３６ が使用される。
【００６４】
図９は、ＤＢＣＢ間の関係及びＤＣＢＣとＴＣＢ との関係を示す。これらのデータ構造は、資源のロックを制御するために使用される。図９では、図面が過度に複雑になることを避けるために、ハッシュテーブル、ＬＣＢ 、ＳＬＣＢ、ＬＲＢ は示されていない。しかしながら、通常、これらのデータ構造は、本システム内に存在している。図９には、ＴＣＢ Ｔ１、Ｔ２、Ｔ３、．．． 、Ｔｍが示されている。
【００６５】
ＤＢＣＢ ２４０、２５０ 、２６０ 、２７０ 、２８０ 、２９０ 、３００ も示されている。本例では、ＤＢＣＢの階層を見ることができる。例えば、ＤＢＣＢ ２４０は、ＤＢＣＢ階層構造にける最も高いレベルのＤＢＣＢであり、グローバルデータベース１９２ に対応している。ＤＢＣＢ ２４０に関しては、ＩＤフィールド２４１ が、このＤＢＣＢがグローバルデータベースのためのものであることを示す。ＤＢＣＢでは、グローバルデータベースの所有者、即ち所有トランザクションを明確に特定する必要はないので、Ｏｗｎ Ｔｘフィールド２４３ はヌルを示している。同様に、グローバルデータベースについてはスーパーデータベースは存在しないため、Ｓｕｐ ＤＢフィールド２４４ もヌルを示している。
【００６６】
Ｓｕｂ ＤＢ フィールド２４５ は、本データベースのためのサブデータベースを参照し、この場合、ＤＢＣＢ ２５０を参照する。この特定の例では、グローバルデータベースのレベルには、他のデータベースが存在せず、従って、Ｎｅｘｔ ＤＢフィールド２４６ 及びＰｒｅｖ ＤＢ フィールド２４７ の各々はヌルを示す。なお、図９では、図面を簡単にするために図７に示すアクティブトランザクションフィールド２０６ が示されていないが、上記した様に、好ましい実施形態では、アクティブトランザクションフィールドが使用される。
【００６７】
ＤＢＣＢ ２４０以下の階層レベルには ＤＢＣＢ ２５０ と２６０ がある。図９のフィールドは自明であるため、これらのフィールドの全ては説明しない。しかしながら、ＤＢＣＢ ２５０ に関しては、所有（ｏｗｎｉｎｇ）トランザクション２５３ が Ｔ２ を参照し、このＤＢＣＢのためのスーパーデータベース ２５４は、ＤＢＣＢ ２４０によって表されているグローバルデータベースであることが分かる。このサブデータベースのためのＤＢＣＢ ２５０は、ＤＢＣＢ ２７０を参照するＳｕｂ ＤＢ ２５５によって示されている。データベース ２５０の他のサブデータベース２３０、２９０、３００はサブデータベース ２７０にリンクされている。Ｎｅｘｔ ＤＢ フィールド２５６は ＤＢＣＢ ２６０を参照し、Ｐｒｅｖ ＤＢフィールド２５７ はヌルを参照する。
【００６８】
ＤＢＣＢ ２５０と階層レベルが同一のＤＢＣＢ ２６０ に関しては、所有トランザクション２６３ は Ｔ３ であり、スーパーデータベース２６４は ＤＢＣＢ ２４０ を参照し、ヌルを参照しているサブＤＢフィールド２６５ によって表されているようにＤＢＣＢ ２６０のためのサブデータベースは存在せず、フィールド２６６ によって示されているようにＮｅｘｔ ＤＢ は存在しない。Ｐｒｅｖ ＤＢ フィールド２６７ は ＤＢＣＢ ２５０ を参照する。ＤＢＣＢ ２４０、 ２５０、及び２６０ についての上記の記載から、ＤＢＣＢ ２７０、２８０ 、２９０ 、及び３００ の各々は、ＤＢＣＢ ２５０及び２６０ の階層レベルよりも低い同一の階層レベルであることが分かる。
【００６９】
ＤＢＣＢ に関しては、一般化して考えると、スーパーデータベースフィールドは、如何なるスーパーデータベースも参照しないグローバルデータベースを除き、一つのスーパーデータベースを参照する。そのような参照により、上記の階層の表現が可能とされている。図９は、特定の一連のトランザクションの間におけるＤＢＣＢの配置の例を示してるだけであり、図９に示す階層と全く同じである必要はない。
【００７０】
トランザクションがサブデータベースを作成する時、サブデータベースは、その作成するトランザクションのコンテキストに基づいて作成される。図９においては、トランザクションＴ２及びＴ３はグローバルデータベース内で実行されることが好ましい。何故ならば、その様にしないと、それらはグローバルデータベース内に属するサブトランザクションを作成できないからである。従って、ＤＢＣＢ ２５０及び２６０ が、それらの上位の（ｓｕｐｅｒｉｏｒ）のデータベースとしてＤＢＣＢ ２４０で表されるグローバルデータベースを有しているという事実は、所有トランザクションはグローバルデータベースをその範囲又はコンテキストとして有していることを示す。
【００７１】
更に、上で述べたように、各ＤＢＣＢのためのスーパーデータベースは一つしか存在しないことが好ましいが、サブデータベースの数は任意である。しかしながら、そのような必要のない別の実施形態も可能である。
【００７２】
図９は、例えば、ＤＢＣＢ ２５０がＤＢＣＢ ２６０を参照し、ＤＢＣＢ ２６０が ＤＢＣＢ ２５０ を参照することにより二重リンクリスト構造を示しているが、そのようなＤＢＣＢ間の二重リンクリスト関係は必須要件ではなく、ツリー構造等、他の構成も使用できる。別のオブジェクトを指定又は参照する ＤＢＣＢ からのポインタ又はリファレンスであることができるが、その目的は、ＤＢＣＢの位置を表す或る構造のセット又はリストを表すことである。この代替の実施形態では、別のデータ構造がデータ構造アレンジメントに付加される。そのような代替の配置は、データ構造アレンジメントをより複雑化するが、そのようにする利点がある。その一例は、必要であれば、ＤＢＣＢの次の参照及び／又は前の参照を削除できることである。
【００７３】
図１０は、図９に示されていないＴＣＢ 及びＤＢＣＢの別の詳細部分を示す。この詳細部分は、明確化及び図面が過度に乱雑になるのを防ぐために図９では省略されていた。同様に、図９に含まれている ＤＢＣＢ の特徴は、明確化のために図１０では省略されている。図１０では、アクティブトランザクションフィールドはＤＢＣＢ内に示されており、コンテキスト及びサブデータベースフィールドの使用は ＴＣＢに関して示されている。図１０のこれらのフィールドは、ＤＢＣＢとＴＣＢ の関係を寄り詳細に示す。
【００７４】
図９に示すように、トランザクションがその所有トランザクションの追跡履歴を保持（ｋｅｅｐ ｔｒａｃｋ）することが好ましく、又サブデータベースのアクティブトランザクションの追跡履歴を保持することが好ましい。
【００７５】
そのような機能は、 ＤＢＣＢ のアクティブトランザクションリファレンス又はフィールドによって行われる。図１０に示すように、ＤＢＣＢ ３１０は識別フィールド３１１ 及びアクティブトランザクションフィールド３１２ を有する。アクティブトランザクションフィールド３１２ は ＴＣＢ ３２０を参照する。これにより、ＤＢＣＢ ３１０に対応するサブデータベースの所有者は、ＴＣＢ ３２０ に対応するトランザクションがＤＢＣＢ ３１０のためのアクティブトランザクションであることを判定できる。更に、ＴＣＢ ３２０ の最も右側の部分においてＴＣＢ ３３０ への参照があり、ＴＣＢ ３３０ は ＴＣＢ ３４０を参照していることが分かる。
【００７６】
また、ＴＣＢ ３４０ は、ＴＣＢ ３２０ を参照するＴＣＢ ３３０ を参照する。更に、ＴＣＢ ３２０ 、３３０ 、３４０ の各々のコンテキストデータフィールドは ＤＢＣＢ ３１０ を参照する。
【００７７】
トランザクションが作成又は開始される場合、そのトランザクションがある種のコンテキストを有し、その中でトランザクションが実行されるのが好ましい。古典的なコンテキスト及び従来技術においては、このセッティングが常にグローバルデータベースであった。しかしながら、本発明のネスト化データベースでは、トランザクションをグローバルデータベース内で開始して実行でき、又ランザクションをサブデータベース内で開始することもできる。好ましくは、トランザクションが開始されたサブデータベース外のデータはアクセスできず、又、好ましくは、このトランザクションが実行されているデータベースをロックマネージャが知っているか判定でき、これがコンテキストデータベースとして参照されるものである。トランザクションがリクエストしている資源がコンテキストデータベース外である場合、そのような情報に対するアクセスのリクエストはロックマネージャによって拒否されるのが好ましい。しかしながら、別の方法として、問題となっているサブデータベースを動的に成長させることも可能である。必要であれば、この動的成長が丁度その時に起きるようにでき、又、更に必要であれば、成長を（ユーザの介在なしに）自動的に開始させることもできる。その様な成長は、図１６のプロセスに類似したマネージャ内で生じる。図１６は、新しいデータ・アイテムがどの様にしてサブデータベースに持ってこられるかを示す。リクエストされているデータがコンテキストデータベースの一部である場合、その資源はアクセス可能なデータベースに属し、評価しなければならない次の問題は、その資源について矛盾するロックが存在するか否かである。矛盾するロックが存在しない場合、ロックマネージャはロックリクエストを許可できる。従って、本発明のデータ構造は、資源がアクセス可能であるか否かの表示と、その資源がロックされているか否かの判定の両方を可能にする。
【００７８】
図１０を再度参照すると、ＴＣＢ ３２０ のＳｕｂ ＤＢフィールド３２３ は ＤＢＣＢ ３４８ を参照し、ＴＣＢ ３３０ のＳｕｂ ＤＢフィールド３３３ は ＤＢＣＢ ３４６ を参照し、ＴＣＢ ３４０ のＳｕｂ ＤＢフィールド３４３ はＤＢＣＢ ３４７ を参照することが分かる。 ＤＢＣＢ ３４８ 、３５２ 、３５６ に関しては、これらのＤＢＣＢのスーパーデータベースポインタ又はリファンレスは ＤＢＣＢ ３１０ を参照する。ＤＢＣＢ ３４８は、そのアクティブトランザクションリファレンスを使用してＴＣＢ ３６０ を参照する。ＴＣＢ ３６０ 及び３６４ はそれぞれ、コンテキストデータベースリファレンスを用いて ＤＢＣＢ ３４８ を参照する。
【００７９】
図１０の単純化したＤＢＣＢ及びＴＣＢ のフィールドの詳細構造は、明確化のためと、図１０がリファレンスによって過度に複雑になることを避けるために省略されている。
【００８０】
図１１は、資源のロックを制御及びモニターするために使用されるデータ構造の代替構成を示す。図２、図４、及び図６を参照して示した実施例では、或るデータベース内の或る資源のロックに対するロックリクエストをロックマネージャが処理するとき、グローバルデータベース内のその或る資源のためのＬＣＢ を見つけ出すために資源ＩＤ（ＲＩＤ） を最初に使用する。その後、必要であれば、同一のＲＩＤ ではあるが、処理中のロックリクエストによって特定された特定のデータベース又はサブデータベース内のＲＩＤ のためのＬＣＢ を見つけ出すために”Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ”リファレンスを使用する。図１１の代替の実施形態（及び図１２の代替の実施形態） は、上に述べた場合とは逆のイベントシーケンスを可能にする。即ち、図１１のデータ構造により、ロックマネージャは、ＤＢＣＢによって表されたデータベースを最初に見つけ、その後、そのデータベース内でＲＩＤ 見つけることが可能となる。これは、上に述べたように単一のグローバルサーチテーブルだけではなく、ＤＢＣＢ 毎に一つのサーチテーブルを設けることによって達成される。
【００８１】
図１１において、ＤＢＣＢは、その所有する（ｏｗｎｉｎｇ）ＴＣＢを参照することに加えサーチテーブルを参照する。このサーチテーブルは問題のデータベース内に含まれているＲＩＤへのアクセスを提供する。例えば、ＤＢ１はテーブル３８０を参照し、ＤＢ２はテーブル３９０を参照し、ＤＢｎはサーチテーブル４００を参照する。各サーチテーブル３８０、３９０、４００はＳＬＣＢを参照するが、このＳＬＣＢは特定のデータ・アイテムのロックに関する情報を提供する。図１１には図示されていないが、ＬＲＢは、ＳＬＣＢに関連する許可されたあるいは許可待ちのロックリクエストに対して用いることができ、その用い方は上に記載の実施態様におけると同様である。
【００８２】
テーブル３８０、３９０、４００等のサブデータベースサーチテーブルは、ハッシュテーブルとすることができるが、別の態様で作成することも可能である。例えば、ＬＣＢリファレンス群の固定サイズの配列アレイを用いて作成することができるであろう。サブデータベースのサイズがサブデータベース創出の際に固定されている場合にはそのような態様は有利であろう。あるいはまた、ＬＣＢリファレンス群の非固定サイズの配列アレイ（成長可能（ｇｒｏｗａｂｌｅ）アレイ）を用いて作成することもできる。ハッシュテーブルをサブデータベースサーチテーブルとして用いる場合、このハッシュテーブルには、所望により、グローバルデータベースハッシュテーブルよりもより少ないエントリーを割り当てることができる。ハッシュテーブルをサブデータベースサーチテーブルとして用いる場合、与えられたいずれのハッシュテーブルに対してもＬＣＢのチェーンを持つことができるであろう。これは例えば、サーチテーブル４００について図示されているように、リファレンス４０２はＳＬＣＢ １６４−５ を参照し、ＳＬＣＢ １６４−５ はＳＬＣＢ １６４−６を参照している。図１１に示す別実施形態では、各ＬＣＢは異なるサーチテーブルの下にオーガナイズされているので、ＬＣＢやＳＬＣＢの”Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ”フィールドはもはや必要でない。よってそのようなサーチテーブルの一つにおける所定のエントリーから、上述の実施形態のＬＣＢとＳＬＣＢの階層構造とは対照的に、ＬＣＢの線形構造にアクセスすることができる。図１１では、各サブデータベースＤＢＣＢは、その所有ＴＣＢへの参照を有し、また、各ＴＣＢはそこに含まれるＤＢＣＢへの参照を有する。図１１のデータ構造はスーパーデータベース・リファレンスの使用をなくするものではない（但し、これらリファレンスについては図１１、１２には図示していない）。
【００８３】
図１１では、トランザクションに対するコンテキストデータベースに関係する情報を示す、ＴＣＢとＤＢＣＢ間の両方向に行き来するリファレンスが存在する。即ち、例えばＴ１について説明すると、Ｔ１はグローバルデータベース１９２に向けられているので、Ｔ１がグローバルデータベース内で処理実行すること、あるいはＴ１がグローバルデータベースをそのコンテキストデータベースとして有することがわかる。ＤＢ１からトランザクションＴ１への参照について説明すると、この参照は、ＤＢ１がＴ１によって所有される、あるいは創出されることを示す。Ｔ２、Ｔ３、Ｔ４は全てＤＢ１を参照しており、これらのトランザクションはＤＢ１の範囲内あるいはコンテキスト内で実行されることを示す。図１１の示す所によれば、Ｔ４は、ＤＢ２からＴ４へと参照されることにより、ＤＢ２の作成元であるが、Ｔ４はＤＢ１内で動作する。この情報から、ＤＢ２はＤＢ１に含まれるサブデータベースであると結論することができる。念のため記載すると、図１１は単にサブデータベースシステムの一例を示すものに過ぎず、別の表現方法もありうる。しかしながら、図１１に示すように、Ｔ４を介する結合のゆえに、ＤＢ２の内部に存在するものはなんであれ、ＤＢ１のサブセットである。図１１はまた、Ｔ５とＴ６がＤＢ２をそのコンテキストとして実行することを示している。Ｔ６はＤＢｎを創出し、Ｔ７とＴ８とはＤＢｎの中で動作する。
【００８４】
図１２は、本発明の更なる別の実施態様を示す。サブデータベースは、サイズが小さくできることから（なぜならそれらは少数のロック可能な資源を含むようにできる為）、必要に応じて、サブデータベースを固定サイズとすることができるであろう。また、必要に応じて、サーチテーブル４１０、４１４、４１６はＬＣＢのアレイとできるであろう。各ＬＣＢはサブデータベースに対するものなので、図１２のＬＣＢは、ＳＬＣＢ（サブデータベースロック制御ブロック）１６４−１〜１６４−２０として示されている。リファレンス群のアレイやＬＣＢリファレンス群のハッシュテーブルではなく、ＳＬＣＢのアレイを用いることができるであろう。なお、ハッシュテーブル１５２は好ましくは前述の各実施形態に関して記載されたのと同様にして作成される。グローバルデータベースに対するこのハッシュテーブルの作成は、所望により、グローバルデータベースに対して多数のＬＣＢを使用することを許容するものである。もしサブデータベースの特定の使用が知られている場合には（知られていない場合でも）、サブデータベースにおけるアイテムの数を例えば２０データ・アイテム等の任意数に制限することが適切であるかもしれない。この数は必要に応じ、より大きくも小さくもすることができる。しかしながら、これは固定された数であって、実施形態においてはアレイ４１０、４１４、４１６が２０メモリを有するように作成することができる（各メモリは全ＳＬＣＢを保持できる）。そうすれば、もし割り当てられたメモリの一部分のみが用いられた場合、用いられていない部分は無駄になるが、この用いられていない部分はそれほど大きいものではなく、また、達成される利点として、新しいＬＣＢが導入されてもダイナミックメモリの割当てに対処する必要がない。また、サーチテーブルなしにＬＣＢのチェイン（リンクされたリストやダブルリンクされたリスト等）を持つことも可能で、特定のＬＣＢを設定する必要がある場合にはいつでもポインタやリファレンスチェーンの順次的な調査ができる。
【００８５】
図１３は、ＤＢＣＢに関するデータ構造群とＴＣＢ群の両者を含む階層を示す。本発明によれば、トランザクション群とデータベース群とを、同一の種類の「物」としてみることができる。これが可能な理由は、データベースをパッシブトランザクションとみることができるからである。よって、データベースがパッシブトランザクションとみなされ、トランザクションとして上に記載したもの（Ｔ１等）がアクティブトランザクションと表示（ｌａｂｅｌ）されることから、単一の階層データ構造におけるＤＢＣＢとＴＣＢへの統一化されたアプローチが可能となる。
【００８６】
図１３にはＡＴＣＢ群とＰＴＣＢ群を示すが、これらをそれぞれアクティブＴＣＢ及びパッシブＴＣＢと称する。アクティブＴＣＢ（即ちＡＴＣＢ）は前述のＴＣＢに対応し、パッシブＴＣＢ（即ちＰＴＣＢ）はＤＢＣＢの別称である。図１３では、データベース／トランザクション階層とも称される階層のルーツは、グローバルデータベースＰＴＣＢ ４２０である。このノードは、上記のグローバルデータベースデータ構造１９２に対応する。この階層において、いずれのノードも如何なるタイプの子ノードを有してもよいようにできる（とはいっても、ＰＴＣＢがその直接的親ノードとして他のＰＴＣＢを有することは通常ないし、そのようなことは行なわれていないであろうが）。上で述べたことを別の言い方でいうと次のようにいえる。階層の出発点はグローバルデータベースで、これは階層のルーツであり、そこから、トランザクションやサブデータベースが作成され寿命を全うする、考えうる殆どあらゆる方法でデータベース／トランザクション階層が動的に展開される（成長（ｇｒｏｗ）と退縮（ｓｈｒｉｎｋ））。このことは、グローバルデータベースに対するＰＴＣＢは、他のノード全てが過渡的（ｔｒａｎｓｉｅｎｔ）でありながらトランザクション・マネジメントとロック・マネジメントが行なわれる対象に対してシステムが存在する限り、存在するであろうということを意味する。この場合、グローバルデータベースに対するＰＴＣＢは、恒常的に存在するように作成することができる。図１３の統合された（ｕｎｉｆｉｅｄ）構造は、上に述べたいずれの実施態様についても用いることができる。これが意味することは、システムは、全てのＬＣＢへのアクセスを提供するグローバルサーチテーブルを有するように作るか、あるいは問題としているＰＴＣＢに属するＬＣＢ群へのアクセスを与えるＰＴＣＢ毎にサーチテーブルを有するように作ることができる、ということである。
【００８７】
図１３を参照すると、グローバルデータベースＰＴＣＢ ４２０が一番上の階層レベルに描かれている。このグローバルデータベースＰＴＣＢ ４２０の直下には４種のトランザクションＡＴＣＢ ４２２、ＡＴＣＢ ４２４、ＡＴＣＢ ４２６がある。これら３種のＡＴＣＢ はトップレベルのトランザクションであって、グローバルデータベースＰＴＣＢ をそれらの直接の親ノードとして有している。図１３の階層における全ての他のトランザクションやＡＴＣＢは、サブトランザクションと考えることができる。図１３に示したデータ構造の関係を実現可能である理由は、本発明者の知見、即ち、サブデータベースをパッシブトランザクションと見ることができ、またサブデータベースが常ににアクティブトランザクションよって創出されると、そのサブデータベースはサブトランザクションになる、という本発明者の知見による。図１３に示すデータ構造の階層と統合化（ｕｎｉｆｉｃａｔｉｏｎ）の利点は、図１０に示す構成に比べ単純化できる可能性が提供されていることである。この単純化がもたらされる理由は、ＴＣＢ群階層とＤＢＣＢ群階層という二つの異なる階層の間を行き来するポインタやリファレンスの代わりに単一の階層があるためであると考えることができる。これにより、データベース制御ブロックをしてその所有トランザクションとスーパーデータベースとの間の差別化をさせる代わりに、データ構造の作成を、それら２つのフィールドのただ一つのみが必要とされるようにして行なうことができる；その場合、スーパーノードのみを含むシステムとすることができる。例えば、図１０を見ると、各トランザクション制御ブロックはコンテキストデータベースを指すポインタやレファンレスを有しており、従前の実施方法におけるデータ構造は、（必要ではないにせよ）スーパートランザクションを指す他のポインタやレファンレスを有するのが好ましい。これに対し、図１３の実施形態では、これらスーパートランザクション及びコンテキストデータベースリファレンスやポインタは、単一のリファレンスと結び付けられる。前出の実施形態と同様、本実施形態でもハッシュテーブル、ＬＣＢ、ＳＬＣＢ、ＬＲＢ等のサーチテーブルが用いられる。
【００８８】
ロックリクエストを実施するときは、前出の実施形態と同様の処理ステップを行なう。処理にあたっては、ＴＣＢからＬＣＢへ、あるいはＬＣＢからＴＣＢへと進むことが望まれるかもしれない。正に前の例と同様に、回答は、ＰＴＣＢ（これはＤＢＣＢに対応する）を参照するＴＣＢやＡＴＣＢによって判断されることができる。別の方法として、ＰＴＣＢが見出される所まで上方に階層を上がって行くこともできる。いずれの場合においても、トランザクション制御ブロックから、そのトランザクションのデータベース制御ブロックへと迅速に進むことができる。この時点で、２つのオプションのいずれかに従うことができる。即ち、ハッシュテーブルを有するＲＩＤを用いて問題のリファレンスを見つけ次いで問題のデータベースに対するＬＣＢを見つけるか、あるいは、ＤＢＣＢに行ってからハッシュテーブル又はデータベース制御ブロックに行く（これらは所望する一つのＲＩＤに対するＬＣＢをサーチするのに用いられる）。ＰＴＣＢの構造は、前に記載したＤＢＣＢと同様である。
【００８９】
しかしながら、ＰＴＣＢは、所有トランザクションとＤＢＣＢのスーパーデータベースフィールドを結合させることによって作成することが好ましく、この結合されたフィールドを、簡単に「上位」（ｓｕｐｅｒｉｏｒ）と称することができよう。
【００９０】
上記ＴＣＢに対応するＡＴＣＢの作成に関しては、図８のコンテキストデータベースフィールド２２６を、図８のＴＣＢのスーパートランザクションあるいは親トランザクションフィールドと結合させることができる。このようにして（必要に応じ付加的な変更がなされるにせよ）、ＡＴＣＢをＴＣＢと非常に類似した方法で作成することができる。
【００９１】
前出の各実施形態では、ロックリクエストブロック（ＬＲＢ）を参照するＬＣＢあるいはＳＬＣＢを用いることが好ましい。この実施形態の別の方法として又はこれに加え、ＬＲＢを、ＬＣＢ又はＳＬＣＢ自身の中の許可待ちリクエストビットマップや許可されたリクエストビットマップで置き換えることもできる。図１４を参照すると、ＬＣＢやＳＬＣＢの別の実施形態がデータ構造４６０として示されている。このデータ構造はＬＲＢに保存されている情報をＬＣＢへと統合するので、ＬＣＢ（及びＳＬＣＢ）はクラッシク形式のＬＣＢ（及びＳＬＣＢ）より多くの情報を含む、より「リッチ」な制御ブロックである。図１４のデータ構造は米国特許第５，９８３，２２５号の図３のデータ構造に基づいていると共にこれに類似しているものであって、この特許公報を本明細書の一部を構成するものとしてここに援用する。
【００９２】
データ構造４６０はロックＩＤフィールド４６２を含むが、このフィールドは通常、今問題としているロックされた資源やその他の資源に対する資源識別子のコピーを有する。モードフィールド（ｍｏｄｅ ｆｉｅｌｄ）４６４は、このＬＣＢで表されるデータベース資源に関して許可された全ロックの最も制限的なアクセスモードを示す。許可されたリクエストビットマップフィールド４６６及び許可待ちリクエストビットマップフィールド４６８はそれぞれ、システム（あるいはサブデータベースレベル）によってサポートされた同時的トランザクションの最大数を示すよう、十分なサイズの（例えば、６４ビットあるいは１２８ビットの）ビットマップを含む。各トランザクションにはビットマップトランザクション識別子が一つ割り当てられる。許可されたリクエストビットマップ４６６は、ＬＣＢ（又はＳＬＣＢ）４６０で表されるロック資源を許可された各アクティブトランザクションに対するセットビットを含む。同様に、許可待ちリクエストビットマップ４６８は、ＬＣＢ４６０で表される資源に許可待ちのロックリクエスト（アクセスリクエストとも称する）を有する各アクティブトランザクションに対するセットビットを含む。データベースフィールド４７０は、ＬＣＢ４６０に対応する資源に対するデータベースを表すＤＢＣＢへのリファレンスを含む。本実施形態によれば、他の実施形態と同様、所定のレコードあるいはオブジェクトの唯一個の物理的コピーが存在するが、そのレコードは二以上のデータベースにおいてアクセスされることができ、仮にある一時点で二以上のデータベース中でアクセスされることができない場合には、時間をずらせばアクセス可能であるようにシステムを作成することができる。よって、トランザクションが現在問題としている資源にアクセスしている時、その資源をどのデータベース中にアクセスしようとしているのかを示すこと、またその場合その目下問題となっている資源が所属する各データベースに対し、単一のＬＣＢ（又はＳＬＣＢ）が存在すること、が好ましく、そして好ましくは、そのＬＣＢ（又はＳＬＣＢ）は目下問題としているデータベースがそれに対応していることを明示的にはっきりこれと示すことができるべきである。これが、データベースフィールド４７０の目的である。
【００９３】
ネクスト・レベルＬＣＢ４７２については、このフィールドはネクスト・レベルＬＣＢを参照するが、参照の仕方は図４及び図６に示すより高い階層レベルのＳＬＣＢの参照の場合と同様である。フィールド４７４は、追加のフィールドがＬＣＢ／ＳＬＣＢ４６０中に含まれてもよいことを示す。例えば、読出し／書込みパラメータビットマップ（その例としては、米国特許第５，９８３，２２５号の図２に要素１７２及び１７３として示されている要素が挙げられる）を用い、ＬＣＢ４６０で示すデータベース資源について許可された読出し／書込みパラメータ化アクセスモードを表すことができる。加えて、他のフィールド群もＬＣＢ４６０のエリア４７４に含まれていても良い。ネクストＬＣＢフィールド４７６を用いてネクストＬＣＢを表しても良く、このフィールド４７６は図２のフィールド１７６に対応するであろう。更に、データベースフィールド４７７及びネクスト・レベルＬＣＢフィールド１７８が図２に関して作成されると同様、データベースフィールド４７０及びネクスト・レベルＬＣＢ４７２も作成されることができる。ＬＣＢ（あるいはＳＬＣＢ）４６０の別の実施形態をもって、ＬＣＢ又はＳＬＣＢが用いられている先の図面のいずれかに置き換えることができ、このようにすることによって、それら実施例で用いることが好ましいＬＲＢを使用しないで済ませることができる。
【００９４】
本発明は様々なトランザクションに関し、ここでトランザクションとは作業の論理的単位（ａ ｌｏｇｉｃａｌ ｕｎｉｔ ｏｆ ｗｏｒｋ）と考えることができる。このようなトランザクションは、人が端末の前に座って作業をする環境に基づくものであるか、既存のコンピュータプログラム及びそのプログラムの命令を実行するためのリクエストを走らせたり提示したり（ｓｕｂｍｉｓｓｉｏｎ）することに基づく何かであることができる。サブトランザクションは、トランザクションと共に、あるいはトランザクションの下で、あるいはトランザクションと関連してなされる作業という概念に関する。
【００９５】
トランザクションをサブユニットに分割することは、サブトランザクションを作り出すことと考えることができる。所望により（例示的実施形態に過ぎないが）、トランザクションは、他のトランザクションとは独立したものと考えることができ、また作業の自律的単位であることができる。
【００９６】
これに対し、サブトランザクションは、非自律的あるいは非独立的トランザクションと考えることができる。よって、サブトランザクションはより高いレベルのトランザクションの一部と考えることができる。
【００９７】
データベースはデータの集まり（ｃｏｌｌｅｃｔｉｏｎ）と考えることができる。サブデータベースもまたデータの集まり（ｃｏｌｌｅｃｔｉｏｎ）であるが、サブデータベースは一般に動的に創出（ｄｙｎａｍｉｃａｌｌｙ ｃｒｅａｔｅｄ）され、暫定的なエンティティ（ｔｒａｎｓｉｅｎｔ ｅｎｔｉｔｙ）と考えられる。好ましい実施形態においては、サブデータベースは、創出トランザクションが生きている間だけ生き続け、サブデータベースを創出したエンティティが存在しなくなったらサブデータベースも存在しなくなるように作成しても良い。サブデータベースは、制御の領域（ａ ｓｐｈｅｒｅ ｏｆ ｃｏｎｔｒｏｌ）である、あるいはこれと関係する、と考えることができる。この制御の領域とは、データのサブセットの周囲にフェンスやラインを置き、そのフェンスの内側がサブデータベースとみなされる領域である。サブデータベースはまた、バーチャルデータベースと考えることもできる。本明細書においては、「データベース」という語はサブデータベース又はバーチャルデータベースを指すものとして使用することがある。サブデータベースは、物質化される必要がないという意味ではバーチャルなものと考えることができる。本発明の実施態様においては、サブデータベース中に別の物理的コピーを持つ必要はない。よって、グローバルデータベースに属し且つ同時にグローバルデータベース制御ブロック１９２に対応する一以上のサブデータベースに属することができるデータのコピーを一個のみ有すれば良く、別の物理的コピーを持つ必要はない。
【００９８】
好ましくは、データは図１のデータベース等のグローバルデータベースに保存される。グローバルデータベース１９２は、好ましくはＤＢＭＳのロックマネージャを管理し動作させるプロセス中で用いられるデータベース制御ブロックとして具現化される。データベース中に実際に格納されているデータを得るためには、グローバルデータベース１９２及び他のＤＢＣＢ群、ＤＢ１、ＤＢ２、．．．、ＤＢｎは所望のデータを得るためのエントリーポイントとしては直接使用されず、データは好ましくはこれらのデータ構造に格納されない。
【００９９】
本発明の一実施形態においては、ＬＣＢ及びＳＬＣＢを経由してデータに到達する（あるいはデータへのアクセスを得るために用いられるロック情報を得る）ことが好ましい。
【０１００】
次を仮定するものとする：即ちレコードＩＤ（ＲＩＤ）が一個存在し、そのＲＩＤに対応する特定のレコードにアクセスしたいと所望され、且つそのレコードへのアクセスが所定のデータベース又はサブデータベース中にあるものと仮定する。基本的なアプローチでは、例えば図２〜１０に示したデータ構造では、ＲＩＤに対するエントリーを得るためにハッシュテーブルを用いるが、そのＲＩＤが見出された時には、そのＲＩＤは、空であるかもしれないＬＣＢ群のチェーンを指すか特定のＲＩＤに対応する一ＬＣＢを指す。その他のＲＩＤ群に所属するＬＣＢ群は無視することができる。若しサブデータベースが所望のものでないかあるいはグローバルデータベースレベルのものであるならば、ハッシュテーブルの利用によって見いだされたＬＣＢに対応するＬＲＢ群を調べ、コンフリクトしているロックが存在するかどうか、またそのロックリクエストは許可できるかどうかを判断する。もしコンフリクトしているロックが存在しロックリクエストが許可されるものなら、リクエストされたロックに対応するＬＲＢを、許可されたＬＲＢ群のチェーン中に導入し、データへのアクセス許可を認容する。このとき、該システム中の他のコンポーネント、例えばバッファマネージャ（よく知られており図示しない）に行くこともできる。また、実際のデータを得るためにレコードを取ってくるための目的とする物理的アドレスやディスクへのアクセスを許容するアイテムに行くこともできる。若しネスト化データベース群やサブデータベース群が存在すれば、データベース制御ブロックを用いてデータへのアクセスに対する許可を得る。データに直接アクセスするためデータベース制御ブロックを用いることは好ましくない。上に述べたように、データを得るためには、ハッシュテーブルを用いてそのハッシュテーブルからハングオフ（ｈａｎｇｓ ｏｆｆ）している対応ＬＣＢ群を見出す。問題としているＲＩＤに対するエントリーが得られ、図面上、右への動きがあり問題としているＲＩＤに対するＬＣＢを見出す。どのようにデータが得られるかを視覚化したものが図４である。図４では、第一レベルのＬＣＢ １６０−１と１６０−２が存在する。図４のハッシュテーブル１５２から、ＬＣＢ １６０−１と接続するリファレンス１５４−１が見出される。ＬＣＢ １６０−１はグローバルデータベースＤＢＣＢ １９２を参照する。データがデータベース ２ （ＤＢ２）に入力されている、あるいは問題とするトランザクションがデータベース ２のコンテキスト内で行われると仮定すると、正しい資源に対するＳＬＣＢを見出すことが必要である。第一レベルのＬＣＢ １６０−１から第二レベルのＬＣＢ １６４−１へと進むことが必要となる。ＳＬＣＢ １６４−１はＤＢ１を参照するが、これは所望のデータベースではない。
【０１０１】
よって、ＬＣＢ／ＳＬＣＢの階層を一レベルずつＬＣＢ群の第三レベルまで上って行くゆくと、ＳＬＣＢ １６４−２がＤＢ２を参照していることが分かるが、このＤＢ２が所望するものであるので、正しいＬＣＢのレベルに到達できたことになる。この段階でロックマネージャは、ＳＬＣＢ １６４−２においてこのデータベース及びこの資源に対しどんなロックが存在するかを調べる。もし新しいロックリクエストが既に存在するもの（それが何であれ）と適合性（ｃｏｍｐａｔｉｂｌｅ）があるなら、そのロックリクエストは許可される。一旦ロックリクエストが許可されれば、データに対するロックが得られるが、そのデータ自身にアクセスできなければならない。好ましい実施形態においては、ＤＢＣＢを用いずにデータへのアクセスを得る。好ましくは、同時実行制御のためにデータベース制御ブロックを用い、該制御ブロックがロックマネージャによって使用されることが好ましく、バッファマネージャや、データを取りに出ていくシステム中の何らかの他のメカニズムによって使用されないことが好ましい。好ましい実施形態においては、データベース制御ブロックは単なる制御ブロックであってデータを含まない；即ちデータベース制御ブロックは制御情報を含む。よって、一旦ロックが許可されると、システムは或るトランザクションが特定のＲＩＤを持つ資格を有する（ｅｎｔｉｔｌｅｄ ｔｏ）と表示（ｉｎｄｉｃａｔｉｏｎ）する。
【０１０２】
次いで、従来の技術およびデータベース構築法によって、例えば、「該データに対するロックが許可された」との表示を存在させることができる。また、ＲＩＤによって同定されるデータを得るために、バッファマネージャや他の構成要素を用いることもできる。
【０１０３】
バッファマネージャはデータを得るためにＤＢＣＢを必要としない、あるいは使用しないことが好ましい。データを得ることは物理的なアクセス経路の問題、及びディスクのどこに所望のデータが存在するかという問題である。
【０１０４】
好ましい実施形態においては、データは一部のみである。但し別の実施形態では二部以上であることができる。好ましくは、所望のレコードその他の如何なるオブジェクトもその数は一部である。該レコード等はディスク上に物理的アドレスを有しており、バッファマネージャはＲＩＤによって与えられた物理的アドレスを特定することができ、バッファマネージャにとっては、データがどのサブデータベースに属するのかはどうでもよい；なお、該物理的アドレスは如何なる場合でも不変であることが好ましい。
【０１０５】
以上、ＳＬＣＢやＬＣＢはＤＢＣＢに対するリファレンスやポインタを有するものとして説明してきた。しかしながら、別の実施形態では、ＬＣＢやＳＬＣＢの中に或るフィールドを有することによって、これらリファレンスやポインタを不要とすることができる。このフィールドは、ナンバーであるか、あるいはＳＬＣＢが特定のデータベース又はサブデータベースに属することを示す表示である。ＬＣＢやＳＬＣＢに対するリファレンスは別の態様も可能である。
【０１０６】
本発明のサブデータベースを実現するのに用いられるデータ構造は、「ロッキング」として知られている周知の同時実行制御技法に再帰（ｒｅｃｕｒｓｉｏｎ）を用いる。
【０１０７】
再帰法を行なうには、所定の原理を何度も繰り返し適用し、本発明においてはデータのグローバルな集まり（例えば、ワードプロセッシングやエンジニアリングやＣＡＤ／ＣＡＭ 設計のドキュメントや構造等）を収めているグローバルデータベースからスタートする。
【０１０８】
同時実行制御（ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ）は、或る一人あるいは一トランザクションの行為によって、他の者が作業中のデータが壊されたり不良になったりしないことを確実にするために、ロッキングによって行なわれる。本発明で用いる原理は、ミニデータベースとみなしうるサブデータベースやネスト化データベースを創出すること、次いでグローバルデータベースに対してなさたと同じ基本概念とロッキングをサブデータベースに対して実施することである。従って、本発明はグローバルデータベースにおける原理をサブデータベース群のバーチャルな集まりに適用するものである。よって、本発明は、再帰的同時実行制御の原理を共同作業（ｃｏｌｌａｂｏｒａｔｉｏｎ）の問題に適用し、これによってバーチャルデータベースやバーチャルな砂箱（ｓａｎｄｂｏｘ）環境の作出を可能とする。これらのバーチャルな環境やサブデータベースに対し、本発明は従来の同時実行制御の使用を許容し、共同作業することを所望している複数のユーザ間での時として複雑なパターンのやり取りを確立することを可能とする。
【０１０９】
若しデータの変更をキャンセルしたい希望や前の状態にデータを戻せるようにしたいという希望がある場合（これはアトミック性に関係する）、本発明はトランザクションの範囲において、各データ・アイテムになされたすべてのログを保持するように構成することができる。そのログのコンテンツによって、変更されたいかなるアイテムも前進的にも後退的にも両方向の回復が可能となる。これは回復可能性として知られており、その実施には周知の各種技法が存在する。しかしながら、書込みを行なう複数の人々の間での共同作業実現へのアプローチの多くは、トランザクションをより小さなトランザクション群に分割することによってトランザクションのアトミック性を犠牲にしている。そのようなアプローチのよく知られた例として、オープンネスト化トランザクションやいわゆるｓａｇａｓが挙げられる。これは上記の極く小さいアトミック・トランザクションの中での回復可能性を実現するものであるが、ユーザの見たいという希望により、トランザクションを構成する極く大きい作業論理単位（ｌｏｇｉｃａｌ ｕｎｉｔ ｏｆ ｗｏｒｋ）については回復可能性は失われる。このため、トランザクションの補償という概念の導入が必要となる。これはアプリケーション開発者によって創出される必要のあるトランザクションである。言い換えるとこれは本質的には回復可能性へのドゥ・イット・ユアセルフともいうべきアプローチである。
【０１１０】
これはネスト化データベースの場合とは対照的である。即ち、ネスト化データベースの場合、回復可能性は失われず、補償トランザクションの使用も不要である。更に、ネスト化データベースの存在下において、回復可能性を実現するための周知の技法を引き続き用いることができる；即ち回復可能性の実現の目的で何らの新たなアルゴリズム、データ構造、技法も開発する必要はない。データベースのネスト化におけるあらゆるレベルで回復可能性が保持できることは、標準技法によるサポートと組み合わせることにより、共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｗｏｒｋ）の問題への他の各種アプローチと比べて優れた本発明の利点である。
【０１１１】
本発明の好ましい実施形態においては、サブデータベースを創出したり稼動しはじめるために、問題としているオブジェクトやサブデータベースに関する書込みロックを有することが好ましい。トランザクションは制御領域を確立するが、誰でも動的に（ｄｙｎａｍｉｃａｌｌｙ）或るオブジェクトを該制御領域に持ってきて、その制御領域の性質に基づいてそれらのオブジェクトを操作（ｍａｎｉｐｕｌａｔｉｏｎ）することができる。書込み制御領域があれば、制御の全領域あるいはその一部を変更することができる。書込みロックによってデータの書込み、削除、挿入、変更が許容され、好ましい実施形態によれば、書込みロックはサブデータベースの創出に対する一要件である。サブデータベースは、書込みロックでなくデータベースロックを作出すると考えることができる。データベースロックを持っていても書込みロックでできることの全てはできないかもしれないし、またデータベースロックは現実にはその構成要素に対し、書込みロックに幾つかの権利を放棄させるようにしてしまうかもしれない。幾つかの権利が放棄されてしまうかもしれないが、それら権利を放棄してサブデータベースを作出することの利点は、そのサブデータベースの所有者が他者や他のグループと該サブデータベースのオブジェクトを共有することに異存がないことにより同時実行制御の別の枠組み（ｒｅｇｉｍｅ）が作出されることである。
【０１１２】
特定のトランザクションに関するロックマネージャは、そのトランザクションをして或るデータベースの範囲内で一生を終わるようにさせる。従って、本発明は、様々な範囲のトランザクションや様々なサブデータベースを有するトランザクションを認識する再帰的アルゴリズムを用いる態様として実施できる。本発明は、システムをより強力にしまた付加的特徴を実現するために米国特許第５，９８３，２２５の技法と共に実施することができとはいえ、本発明は、米国特許第５，９８３，２２５号公報に記載のパラメータ化ロックマネジメントシステムとは異なる。本発明におけるネストされたデータベースあるいはデータベースをネスト化すること、およびサブデータベースを利用することの目的は、データに書込む者が複数ある場合それら複数の者の間を調整することにある。
【０１１３】
図１５に戻ると、これは新しい空の（ｅｍｐｔｙ）サブデータベースを作出するためのフローチャートである。図１５で暗黙の了解事項とされていることは、トランザクションがデータベース又はグローバルデータベース内の何らかの他のサブデータベースの中で実行されていること、及びこのトランザクションの所有者あるいはこのトランザクションの管理者が新しいデータベースを作りだそうとしていることである。図１５において、スタートの後、ステップ４８２で新しいＤＢＣＢを作成する。創出されようとしているこの新しいサブデータベースの存在に関する制御点あるいは参照点とするために、データベース制御ブロックが作成される。上で述べたように、好ましい実施形態においては、このサブデータベースに対してデータのコピーを作成する必要はないが、必要に応じて、データのコピーを作成しても良い。ステップ４８４、４８６、４８８は作成されたＤＢＣＢを、存在するかもしれない他のデータ構造と関連付けるものである。ステップ４８４では、ＤＢＣＢの「Ｏｗｎ ＴＸ」フィールドをして、作成／所有トランザクションを参照させる。
【０１１４】
このステップは、作成トランザクションと新しいＤＢＣＢとの間の関係を明確にするために行なわれる。なお、各フローチャートに記載の全ステップが必須であるのはなく、実施態様によっては、所望であればあるいは名指されたデータ構造やフィールドが使用されていないならば、なくても良いステップもあろう。次に、ステップ４８６では、ＤＢＣＢのスーパーデータベースフィールドをして適切なＤＢＣＢのスーパーデータベースを参照させる。これを行なうことにより、「この新しいサブデータベースをその一部として有するデータベースは何か」をシステムに告げ、またＤＢＣＢデータ構造において明確にする。次いで、ステップ４８８では、ＤＢＣＢデータ構造の「Ｐｒｅｖ ＤＢフィールド」や「Ｎｅｘｔ ＤＢ」に書込み、それらが同胞データベース（もし存在すれば）を参照できるようにする。これらの同胞データベースは、同一の作成トランザクション（もしあれば）によって予め作成された他のサブデータベースであることができ、この予めの作成は、該他のサブデータベースとの関係が定義されあるいは作成されるようになされるものである。
【０１１５】
次に、図１５中、ステップ４９０では作成トランザクションのＴＣＢ中に適切な情報を書込むが、この書込みはこのＤＢＣＢが作成トランザクションのＴＣＢの「Ｓｕｂ ＤＢフィールド」によって参照されるようになされる。このステップによって、スーパーデータベースがこの新しいデータベースを、それ自身（即ちスーパーデータベース自身）が有するサブデータベース群の集合中に含むことが確実になる。最後に、ステップ４９２において、ＬＣＢのための新しいサーチテーブルが割り当てられ、該新しいサーチテーブルはこのＤＢＣＢから参照される。このステップ４９２は全ての実施形態において実施されなければならないものではないが、図１１のデータ構造及び／又は図１２のデータ構造では望まれるステップである。図１１及び／又は図１２の実施形態において、好ましくは、各ＤＢＣＢはそれ自身のハッシュテーブルや、アレイや、そのドメイン又はサブデータベースの中にあるＲＩＤを指定するためのエントリーポイントとして用いられるその他のサーチ構造を有することが好ましい。図１５のプロセスはそこで終了する。
【０１１６】
図１６は、サブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）ために前記ＲＩＤをサブデータベース中に持ち込むプロセスを示す。図１５で作成されたサブデータベースは最初作られた時には空であって、図１６は、オブジェクトやデータ・アイテムがどのようにしてサブデータベースに引き込まれ、目下問題としているサブデータベース中で実行されることになる将来のトランザクションにそのオブジェクトやデータ・アイテムが利用可能となるかを示す。図１６において、スタート後、ステップ５００は問題のオペレーションが有効かどうかを判断する。このステップが行なわれる理由は、好ましい実施形態においては操作者は如何なるオブジェクトもサブデータベースに移動できないが、一定の条件が存在するべきであるからである。例えば、サブデータベースを所有する、創出されたトランザクションは、この時点では、それ（トランザクション）がサブデータベースへと持ち込もうと希望しているオブジェクトを所有していることが好ましい。その他の質問や判定も実施することができる。例えば、オブジェクトがこのサブデータベースのスーパーデータベース中に存在する場合にのみオブジェクトをそのサブデータベースにき込む（該スーパーデータベースがグローバルデータベースや他のサブデータベースであろうとなかろうと）などである。よって、好ましい実施形態においは、オブジェクトをデータベース階層におけるその直上のデータベースからのみ引きだすことができる。若し、上記二条件が満たされないなどの理由でオペレーションが有効でないと判断されれば、図１６のプロセスはそこで終了する。
【０１１７】
もしステップ５００がそのオペレーションが有効であると判断すれば、ステップ５０２に進み、目下問題としているオブジェクトをサブデータベース中に取り込む。図１６の実施形態は図２〜４及び６に示したアレンジメント等のデータ構造アレンジメントに関する。ステップ５０２ではスーパーデータベースにおいてこのＲＩＤに対するＬＣＢを見つけ出す（ｌｏｃａｔｅ）。好ましくは、このステップは次のように行なわれる。即ち、まずハッシュテーブルに行き、ＲＩＤをハッシングし、ハッシュテーブルのエントリー又はリファレンスを獲得し、そしてポインタチェーンやリファレンスに従って前記ハッシュテーブルから第一のレベルのＬＣＢに進む。このＬＣＢはグローバルデータベース中のＲＩＤを特定するであろう。もし、問題としているオブジェクトを目下引き込もうとしているこのサブデータベースがグローバルデータベースの直下のものではなく、その上に（即ちグローバルデータベースとそれ自身の間に）他のサブデータベースを幾つか有しているならば、次のレベルのデータベースリファレンス群の中を移動したりあるいは一ＬＣＢから他のＬＣＢへと、このサブデータベースの直接上のスーパーデータベース中の資源を特定するＬＣＢに到達するまで次のレベルのＬＣＢに移動することが適切である。ステップ５００に関するこの判定によって、そのようなＬＣＢが存在するようになることが分かる。
【０１１８】
ステップ５０２の後、ステップ５０４に進み、このデータベースあるいはサブデータベース中の問題のＲＩＤに新しいＬＣＢを割り当てる。この新しいＬＣＢは、我々が作成した新しいサブデータベース（そこに資源が持ち込まれる）中の全く同じ資源を表す。ステップ５０６において、スーパーデータベース中のこのＲＩＤに対するＬＣＢは新しいＬＣＢを参照するようにされる。最後に、ステップ５０８で、この新しいＬＣＢにこのデータベースのためのＤＢＣＢを参照させる。即ち、この新しいＬＣＢがはっきりとデータベースとの関係を示すことを確実にすることが好ましい。これは「これは私のデータベースだ」とか「これは私のコンテキストデータベースだ」ということを示すことによってなされる。図１６のプロセスはそこで終了する。
【０１１９】
図１７は、データベースやサブデータベースの要素をいかにして構成する（ｐｏｐｕｌａｔｅ）かを示すフローチャートである。これは例えば、図１１や１２に示すデータ構造を有する別の態様においても用いることができる。このように要素を集めて構成する（ｐｏｐｕｌａｔｉｎｇ）目的は、資源のロック状態を決定するためにＬＣＢを作出することによりロッキング構造を実現する点にある。
【０１２０】
図１７ではスタートした後、ステップ５１０を行う。このステップは問題のオペレーションが有効かどうかを判定する。このステップは、図１６のステップ５００と同一のステップであるので、このステップの説明は省略する。次に、ステップ５１２において、このデータベース用のＤＢＣＢを見つけ出す。
【０１２１】
この時、グローバルデータベースや対象とする何らかのサブデータベース等のデータベースは既知である。なお、データベース制御ブロックによって或るオブジェクトを引き込もうという企図が存在するデータベースはどれかが示されることが好ましい。更に、所定のデータベース用のＤＢＣＢを見つけ出す方法があることが好ましく、それはデータベース制御ブロックへの参照があるようになされることが好ましい。次に、ステップ５１４において、このデータベース内で、新しいＬＣＢ（又はＳＬＣＢ）が問題のＲＩＤに対して割り当てられる。このステップでは、データベース中に新しいオブジェクトが持ち込まれる際に新しいＬＣＢが作出される。即ち、もし一オブジェクトが複数のデータベースに存在すれば、そのオブジェクトを有するデータベース群が存在することにより、そのオブジェクトは自身を表す同数のＬＣＢを有す。最後に、ステップ５１６において、ＬＣＢがデータベースのサーチテーブルに挿入される。これはレコードＩＤについてハッシングし、ハッシュテーブルが使用されていると仮定するとハッシュテーブルエントリーを得ることによって達成される（但しアレイやテーブル等上述の別法を用い、新しいＬＣＢを、如何なるハッシュテーブルエントリーであれ、ハッシュ関数が指示する挿入箇所に挿入してもよい）。この時もしＬＣＢのチェーンが空であれば（即ち、ＬＣＢなし）、ＬＣＢをチェーン中最初のアイテムとして挿入する。また、チェーンが空でなければ、ＬＣＢを第一のアイテムとして挿入するか、あるいは、チェーンにおける最後又は中間のアイテムとして挿入する（エントリーが挿入され、問題としている特定のハッシュテーブルやアレイ・エントリーから到達されうる限りにおいて）。
【０１２２】
図１８は、図２〜４及び６に示した本発明実施形態のデータ構造を用いてロックリクエストの処理を行なうための例示的ステップを示すフローチャートである。図１８において、スタート後、ステップ５２０を行なって、問題としているＲＩＤ用のハッシュテーブル・スロットを見つけ出す。ロックリクエストによって、あるデータへのアクセスの許可を求めているトランザクションを特定し、このＲＩＤがその中に見出されようとしているデータベースを特定すると共に問題のデータのＩＤやＲＩＤを特定する。更に、アクセスモードの表示が存在し、これはたとえばデータの読出しや書込みが所望されているか等である。この情報はロックリクエストの処理の際、ロックマネージャによって利用される。よって、ＲＩＤ用のためのハッシュテーブル・スロットを見つけ出すために、ＲＩＤのハッシングがあって、ハッシュテーブル・エントリーが見出され、そしてハッシュテーブル・エントリーにおけるリファレンスが調べられて、グローバルデータベース中でこのＲＩＤに対するＬＣＢが存在するかどうかを判断する。もしステップ５２２でＲＩＤのためのＬＣＢがグローバルデータベース中に存在しないと判断されれば、ステップ５３０に進み、そこでＬＣＢを作出してそれを第一レベルのＬＣＢチェーンに挿入する。ステップ５２２でＲＩＤのためのＬＣＢがグローバルデータベース中に存在しないと判断されれば、ロックリクエストは、ＬＣＢがまだ存在していないためＬＣＢが作出されるという比較的単純な状況において、グローバルデータベース中の前記ＲＩＤのためのものと結論付けられ、ＬＣＢがまだ存在していないからには、そのデータ・アイテムについてのロックを有するトランザクションは他にないと容易に判断されるため、リクエストされているロックは無条件に許可されるであろう。このようにしてグローバルデータベースに関係する第一レベルのＬＣＢチェーンへのＬＣＢの挿入がなされる。ステップ５３０の後、ステップ５３２で前記リクエストを許可し、許可されたリクエストに対応するＬＲＢを創出する。
【０１２３】
あるいは、もしステップ５２２で、ＲＩＤのためのＬＣＢがグローバルデータベース中に存在すると判断されれば、ステップ５２４に進み、正しいデータベースあるいはサブデータベースが見出されるまで「Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ」に従う。ステップ５２４を行なう回数はゼロ回であってもよい。よってグローバルデータベース中の資源に対するリクエストがもしあっても、目下見られているＬＣＢが所望の、あるいは正しいＬＣＢであるかどうかを即座に見出すことができ、よって、このＬＣＢでストップして先に進まないことができる。次に、ステップ５２６では、競合しているロックが存在するかどうかを判断する。これはそのデータ・アイテムに対してすでに許可されているかもしれない既存のロックのいずれとも前記リクエストが適合する（ｃｏｍｐａｔｉｂｌｅ）かどうかを判断することによって容易に行なうことができる。もしステップ５２６で競合しているロックが存在すると判断されればステップ５２８に進み、リクエストは待ち状態（ｑｕｅｕｅｄ）とされるかあるいは拒絶される。システムには待ち時間を設定することができ、既存のロックをリリースしてロックマネージャが後でリクエストされたロックを許可してよい時がきたかどうかを再考することができるようにもできる。あるいは、ステップ５２８において、リクエストされたロックは単純に拒絶されるようにしても良い；これは単にこの問題をどのように取り扱うかに関する設計上の選択事項である。すぐリクエストを拒絶すればハンギングを防止でき、また所望のロックへのアクセスを得られるかもしれないとの希望をもって不特定時間の間待つという問題をなくすることができる。
【０１２４】
ステップ５２６で競合するロックが存在しないと判定された場合、ステップ５３２に進み、ここで適切に資源や関連するデータのロッキングを指摘するためにリクエストを許可しそのリクエストに関係するＬＲＢを創出する。
【０１２５】
図１８と同様に図１９も、ネスト化データベースの存在下で如何にロックリクエストは取り扱われるかを示すが、図１９は、各データベースあるいはサブデータベース制御ブロックがそれ自身のサーチテーブルを有している図１１及び図１２のデータ構造に関するものである。図１９では、スタート後、問題のデータベースのためのＬＣＢサーチテーブルが見いだされる。これは、ロックリクエストによって特定されるデータベースのＤＢＣＢからサーチテーブルリファレンスに従うことによって行なうことができる。次に、ステップ５３６において、ＲＩＤのためのハッシュテーブル・スロットが見出される（もし本態様に関してそのようなデータ構造が存在するならば）。別の方法として、ハッシュテーブルを持つことを避けたいのであれば、本実施態様はＬＣＢの表示や割り当てをより直接的に行なうようにしてもよい。次に、ステップ５３８で、ＲＩＤ用のＬＣＢが既に存在するかどうかを判断する。
【０１２６】
もしＬＣＢが存在しないなら、ステップ５３７に進み、リクエストがグローバルデータベース中の資源のためのものであるかどうかを判断する。その場合、ステップ５４４へ進む。しかしながら、もし前記リクエストが或るサブデータベース中の資源のためのものであってその資源のためのＬＣＢがそのサブデータベースのサーチテーブルに存在しないなら、トランザクションがリクエストしているものはそのコンテキストデータベースの範囲から外れる何らかのものであることになるので、特殊な状態であることになる。通常、そのようなリクエストは拒絶される（ステップ５３９の「ＮＯ」の枝で示される）。しかしながら、システムのプラグラミング次第ではその時にリクエストされた資源を動的に持ち込む可能性（即ち問題のサブデータベースを動的に成長される可能性）を、サブデータベースの成長が許容されるべきかどうかを決定するステップ５３９の質問によって開いておくことができるであろう。そのような判断は人間の介入によってでもよらなくても行なうことができるであろう。ステップ５３９における答えがイエスであるときは、ステップ５４４に進む。必要に応じて、図１８のフローチャートを修正し、図１９のステップ５２２と５３０の間にステップ５３７と５３９を挿入することができる。これによって、ステップ５３７及び５３９の機能性が図１８のプロセスにおいて達成される。
【０１２７】
ステップ５３８において、もしＲＩＤ用のＬＣＢが既に存在すると判断されるならば、ステップ５４０に進み、競合するロックが存在するかどうかを判定する。もし競合するが存在するなら、図１８のステップ５２８に関して説明したように、ロックリクエストが待ちの状態（ｑｕｅｕｅｄ）にされるかあるいは拒絶される。もし競合するロックが存在しないなら、ステップ５４６に進み、上述のようにロックのリクエストが許可されＬＲＢが作出される。図１９のプロセスはそこで終了する。
【０１２８】
図２０は、サブデータベースの終了時に実行されるステップを示すフローチャートである。スタート後、ステップ５５０ は、このデータベースのトランザクション又はサブデータベースが存在するか否かを判定する。ステップ５５０ の問い合わせの何れかに対する答えがＹＥＳの場合、流れはステップ５５２ に進み、このプロセスを継続するリクエストがあるか否かを問い合わせる。ステップ５５２ の判定ブロックは任意の要求される方法で行うことができ、ユーザがサブデータベースを終了することをまだ望んでいるか否かシステムのユーザに問い合わせた後におけるユーザの手動判定であってもよい。
【０１２９】
或いは、サブデータベースを終了することを受け入れられるか否かを示す自動判定であってもよい。このデータベースのトランザクション又はサブトランザクションが存在するためにサブデータベースを保存することが望まれる場合には、問題となっているデータは保存することが望まれているので、流れはステップ５５２ からエンドへ進行する。ステップ５５２ の継続的な判定は予めプログラムできる、即ちコンピュータプーグラム判定であり、手操作による判定であっもよい。ステップ５５２ において終了を継続する要求がある場合、ステップ５５４ が実行され、本データベースの全てのサブデータベースとトランザクションが終了される。この終了は、再帰（ｒｅｃｕｒｓｉｏｎ）の他の例である。何故なら、ステップ５５４ のアクションを実行することにより、テップ５５４ で終了されるアイテムのために図２０のフローチャートが再度実行されるからである。
【０１３０】
問題となっているデータベースについてのトランザクション又はサブデータベースが存在しないとステップ５５０ で判定された場合、又はステップ５５４ の実行の後にステップ５５６ が実行された場合、問題となっているデータベースについての全ての ＬＣＢの割当てが解除される。このステップ５５６ の割当て解除は安全に行うことができる。何故なら、ＬＲＢ 及びこれらのＬＣＢ に依存するトランザクション又はサブデータベースが存在しておらず、それらを除去、即ち割当て解除する（例えば、コンピュータのメモリからそれらを削除する）ことが可能であるためである。次に、ステップ５５８ が実行され、サーチテーブルが使用されている場合には、サーチテーブルの割当てを解除される。なお、場合によっては、割当て解除すべきサーチテーブルが存在しない場合があり、この場合、ステップ５５８ を実行する必要はない。最後に、ステップ５６０ が実行されて、問題となっているデータベースのための ＤＢＣＢ の割当てが解除され、ステップ５６０ が一旦実行されると、通常は、このサブデータベース専用に設けられたコンピュータメモリ内にデータ構造が存在しなくなり、サブデータベースが存続を停止する。図２０のプロセスはその後終了する。
【０１３１】
本発明の可能なアプリケーション、結果、及び特徴をより簡単に分かるようにするため、本発明ができることの例を図２１（ａ）〜図２１（ｄ）を参照して説明する。本例は、ドキュメントを共用する例であるが、本発明は多くのアプリケーションを有し、複数のユーザの間でデータを共有したいという希望がある如何なる状況においても使用できる。更に、本発明は、一つのドキュメントの一部をユーザの間で共有し、複数のユーザが単一のドキュメントに対して同時に作業するために用いることもできる。本例では、各ユーザのために単一のスクリーン、即ちコンピュータ・ディスプレイが提供され、ユーザが利用できるドキュメント又ははデータ・アイテムの各々が画面上に示される。しかしながら、これは例示に過ぎず、実際には、問題としているデータ・アイテムの各々を単一のコンピュータスクリーンに表示する要求も必要性もない。図２１（ａ）を参照すると、４つのドキュメント、即ち、ドキュメント１ ５７２ 、ドキュメント２ ５７４ 、ドキュメント３ ５７６ 、ドキュメント４ ５７８ を有するゲールのコンピュータスクリーン５７０ が示されている。この図２１（ａ）のスクリーン５７０ において、ゲールは書込みロックドキュメント１ 、２ 、３ 、４ を有し、ゲールはこれらのドキュメントの内容を読んだり書いたりできる。図２１（ａ）〜２１（ｄ）の例の実施を示すデータ構造に関して以下に説明するように、ゲールはグローバルデータベース内にトップレベルのトランザクションを有している。
【０１３２】
図２１（ｂ）では、ゲールはサブデータベースを作成し、論理的に言えば、ドキュメント２ 、３ 、４ をこのサブデータベースに引き入れた。これにより、これらのドキュメントは、各ドキュメントの右上の角において”Ｒ／Ｏ” で指定されているように、読出専用になる。
【０１３３】
図２１（ｃ）に、ゲールのためのスクリーンショット５７０ が示されており、又、ブライアンは自分のスクリーン５８０ に示されているように、ドキュメント２ ５８２ 及びドキュメント４ ５８４ に対して作業できるようになっていることを示している。
【０１３４】
図２１（ｃ）において、ブライアンはゲールのサブデータベース内でトランザクションを開始し、書込みロックドキュメント２ 及び４ を有している。これにより、ブライアンは、これらのドキュメントに対してフルエディットを行うことができるようになり、一方、ゲールは、暫くの間、ブライアンの管理下にあるドキュメント２ 及び４ に対して書込みを行うことができない。しかし、必要であれば、ゲールがそれらを読み出し、ブライアンが行っている作業を観察することができる。
【０１３５】
図２１（ｄ）に、ゲールのスクリーン５７０ とブライアンのスクリーン５８０ を見ることができるが、更に、アンヌがスクリーン５９０ を有しており、このスクリーン５９０ には、読出専用ドキュメントであるドキュメント２ ５９２ とドキュメント３ ５９４ が示されている。図２１（ｄ）のシナリオでは、アンヌがゲールのサブデータベース内でトランザクションを開始した。彼女はドキュメント２ について読出しロックを、ドキュメント３ について書込みロックを有しており、アンヌはドキュメント３ だけを変更できる。
【０１３６】
なお、図２１（ｄ）において、ブライアンはドキュメント２ ５８２ について書込みロックを有し、一方、アンヌはドキュメント２ について読出しロックを有している。従来のシステムでは、通常、ブライアンの書込みロックとアンヌの読出しロックは矛盾する。アンヌがブライアンの作業を見られるようにするために、パラメータ化ロック又はその他の機構を用いることができる。したがって、本発明の中核、即ちネスト化データベースをパラメータ化ロックと組み合わせて、システムの能力を更に高めることができる。
【０１３７】
図２１（ａ）及び２１（ｄ）の例が存在するシナリオを実施するために、例示的データ構造を図２２（ａ）〜２２（ｄ）及び２３（ａ）〜２３（ｄ）にそれぞれ示す。これらの図面は、サブデータベース及びデータの共有がどのように起きるかを示している。図２２（ａ）〜２２（ｄ）は、図２１（ａ）〜２１（ｄ）の例を実施するために用いられるデータ構造の最初の例を示す。図２２（ａ）では、ゲールはトランザクション制御ブロック（ＴＣＢ）６００を有している。又、ドキュメント１−４ のそれぞれのためにロック制御ブロック（ＬＣＢ） が設けられ、これらは１６０−１ 〜１６０−４ の番号が付けられている。ドキュメントのロッキングを実施するために、各ＬＣＢ に関連してロックリクエストブロック（ＬＲＢ）１６２−１〜１６２−４ が使用される。図２２（ａ）の各ＬＣＢ １６０ はグローバルデータベース１９２ （実際にはグローバルデータベース制御ブロック）を参照し、これにより、ゲールは、グローバルデータベース内でトップレベルのトランザクションを有していることを表す。ゲールのトップレベルのトランザクションであるＴＣＢ ６００ については、ドキュメント１−４ の各々についてフルエディットの能力がある。
【０１３８】
これらのドキュメントのためのＬＣＢ 及びデータ自体は、グローバルデータベースの一部であるか関連しているものと考えなければならない。
【０１３９】
図２１（ｂ）に対応する図２２（ｂ）においては、ゲールはサブデータベースを作成し、論理的に言えば、ドキュメント２ 、３ 、４ をサブデータベースに移動させる。サブデータベースは、ゲールが他の人を招き入れて共同作業するために作られる。ゲールはサブデータベースを作成しているので、追加のデータ構造が図２２（ｂ）に示されている。特に、ドキュメント２ 、３ 、４ はサブデータベースの一部であるので、第二レベルのＬＣＢ （ＳＬＣＢとも呼ばれる） がドキュメント２ 、３ 、４ のために作られ、符号 １６４−２、１６４−４ 、１６４−１ によってそれぞれ表されている。これらの ＳＬＣＢ がゲールのサブデータベース制御ブロック（ＤＢＣＢ）６０２ を参照しているのが分かる。ゲールはドキュメント１ を彼女のサブデータベースに移していないため、ドキュメント１ のための第二レベルのＬＣＢ 又はＳＬＣＢは存在しない。従って、この時点では、ドキュメント１ だけが、ゲールが編集できるドキュメントであり、他のドキュメントは閲覧だけが可能である。他のドキュメントが異なるサブデータベースに移動されたために、ゲールはドキュメント１ だけを編集できることをデータ構造が表すようにするため、ゲールのサブデータベースへ移動されたドキュメントのためのＬＲＢ のモードフィールドが、ロックについてのドキュメントに関連する能力を示すために変更される。図２２（ｂ）では、ゲールのサブデータベース内にアクティブなトランザクションは存在していない。更に、図２２（ｂ）では、ゲールのＴＣＢ のためのコンテキストデータベースはグローバルデータベース １９２に残っており、ゲールのサブデータベースはゲールのトランザクションによって所有されていることを示すためにゲールのサブデータベース ＤＢＣＢ ６０２ はゲールのＴＣＢ ６００ を参照する。
【０１４０】
図２２（ｃ）を参照すると、ブライアンは、ゲールのサブデータベース内でトランザクションを開始し、ブライアンのトランザクションは、図２２（ｃ）の右上部のブライアンのＴＣＢ ６０４ によって表されている。この特定の例では、ブライアンのトランザクションはドキュメント２ 、３ 、４ のみをアクセスできる。何故なら、ゲールのサブデータベースのドキュメント内、これらに対してのみブライアンのトランザクションがアクセス許可を有しているからである。しかしながら、本発明の或る実施形態では、別のユーザ、例えばブライアンがサブデータベース内でトランザクションを開始した後であっても、ゲールが、更なるドキュメントを追加することにより、彼女のデータベースを動的に成長させることが可能である。図２２（ｃ）では、ブライアンは、書込みロックをドキュメント２ 及び４ に設定しており、これらのドキュメントについてのフルエディットの能力を有している。従って、ゲールは、ブライアンがドキュメントに対して何を行っているのかを見ることはできるが、彼女は、彼の行った変更に対して直接変更を加えることはできない。
【０１４１】
ドキュメント２ 及び４ に対して書込みロックを持つことができるブライアンの能力は、ドキュメント２ のためのＬＲＢ １６２−６ を参照しているドキュメント４ のためのＬＲＢ １６２−５ へのブライアンのＴＣＢ ６０４ からの破線の矢印、即ちリファレンスによって表されている。又、図２２（ｃ）から分かることは、ブライアンのＴＣＢ ６０４ がゲールのサブデータベース（又はＤＢＣＢ）６０２ を参照していることであり、これはブライアンのＴＣＢ のためのコンテキストデータベースがゲールのサブデータベースであることを示している。
【０１４２】
図２１（ｄ）に示した配置とアクセス能力に対応する図２２（ｄ）を参照すると、アンヌはゲールのサブデータベース内で既にトランザクションを開始している。ブライアンのトランザクションと同様、ゲールがより多くのドキュメントを加えることによって彼女のサブデータベースを動的に成長させることを選択していない限り、アンヌのトランザクションは、ドキュメント２ 、３ 、４ のみをアクセスできる。この時点では、アンヌはドキュメント３ に対して書込みロックを有し、ドキュメント２ に対して読出しロックを有している。この情報は ＬＲＢ １６２−７及びＬＲＢ １６２−８ によって表される。ドキュメント２ のためのＳＬＣＢであるＬＲＢ １６２−７ は読出しロックを示し、ドキュメント３ のためのＬＲＢ １６２−８ は書込みロックを示すようにそのモードが設定される。この時点では、アンヌはドキュメント３ のみを編集できるが、彼女はブライアンがドキュメント２ に対して行っている変更を全て見ることができる。必要であれば、アンヌはドキュメント４ も見ることができ、同様に、必要であれば、ブライアンはドキュメント３ を見ることができる。ＬＲＢ １６２−７ 及び１６２−８ の参照に加え、アンヌのＴＣＢ ６０６ は、コンテキストデータベースリファレンスにより、ゲールのサブデータベース６０２ も参照する。
【０１４３】
図２３（ａ）〜２３（ｄ）は、図１１に示したデータ構造を使用して図２１（ａ）〜２１（ｄ）の例を実行するようにした代替の実施形態を示す。図２１（ａ）に対応する図２３（ａ）では、問題となっている４つのドキュメントのためのＬＣＢ １６０−１ 〜１６０−４ があり、各 ＬＣＢは対応するＬＲＢ １６２ を参照している。ゲールのＴＣＢ ６５０ は ＬＲＢ １６２を参照しており、又、ゲールのＴＣＢ ６５０ は、そのコンテキストデータベースがグローバルデータベース１９２ であることを示している。
【０１４４】
図２１（ｂ）に対応する図２３（ｂ）では、ゲールはサブデータベースを作成し、これにより、ゲールのサブデータベースのためのデータベース制御ブロック６５２ が作成される。ゲールのサブデータベース ＤＢＣＢ ６５２ はゲールのＴＣＢ ６５０ を参照して、ゲールのサブデータベースがゲールのトランザクションによって所有されていることを示し、又、ゲールのサブデータベース６５２ はハッシュテーブル、アレー又はその他の構造 ６５４を参照する。この構造６５４ は、ゲールのサブデータベースの一部である、３つのドキュメントのためのＳＬＣＢ １６４−１、１６４−２ 、１６４−３ を有している。ＳＬＣＢ １６４は、テーブル６５４ のリファレンス６５６ 、６５８ 、６６０ によって参照される。
【０１４５】
図２１（ｃ）に対応する図２３（ｃ）では、ブライアンのトランザクションが存在するようになり、これがブライアンのＴＣＢ ６７０ として表されている。ブライアンのＴＣＢ ６７０ はゲールのサブデータベース制御ブロック６５２ を参照し、ブライアンのＴＣＢ ６７０ 即ちトランザクションのコンテキストデータベースはゲールのサブデータベース６５２ であることを示す。ブライアンは、ドキュメント２ 及び４ についてのロックを得るが、これらはＬＲＢ １６０−５及び１６０−６によって表されている。
【０１４６】
図２１（ｄ）の配置に対応する図２３（ｄ）では、アンヌのトランザクションが存在するようになり、ゲールのサブデータベースをそのコンテキストデータベースとして有している。これは、アンヌのＴＣＢ ６８０ のコンテキスト ＤＢ リファレンスのゲールのＤＢＣＢ ６５２への参照によって示されている。
【０１４７】
更に、アンヌはドキュメント２ 及び３ に対して所定の権利を有しており、これは、ドキュメント２ 及び３ のためのＬＲＢ １６０−７ 及び１６０−８ を参照するアンヌのＴＣＢ ６８０ によってデータ構造内で表される。ＬＲＢ １６０−７ 及び１６０−８ は、アンヌが有しているアクセス能力が読出し専用であるのか書込みもできるのかを示すためにそれらのフィールドをセットする。
【０１４８】
図２１（ａ）〜２３（ｄ）に関して記載した上記の例は、異なるドキュメントのロックと共有に関するものであった。しかし、本発明は、ファイル又はドキュメントレベルでの共有に限定されるものでなく、複数のユーザ等の間で単一のファイル、ドキュメント、設計図等を共有するために利用できるものである。単一のファイルやドキュメントや他のデータ・アイテムを、本明細書で開示したネスト化データベースのフレームワーク内で共有するようにした実施形態を達成することは、ロッキングの細分性（ｌｏｃｋｉｎｇ ｇｒａｎｕｌａｒｉｔｙ）に関連している。即ち、ロッキングデータ構造又はＬＣＢ がどの資源を表しているかに関係する。従って、本発明は、例えば、パラブラフレベル、センテンスレベル等、ファイル又はドキュメントのより小さい部分のロッキングを可能にし、更に、個々の単語、文字、又はビット毎にロッキングを行うことを可能にする。
【０１４９】
更に、ドキュメントプロセシング又はワードプロセシング環境以外では、設計図の異なる部分を ＣＡＤ／ＣＡＭ システム又は他のシテスム上で共有できる。
【０１５０】
図２４（ａ）〜２４（ｄ）により提示する例（及び、必要であれば前出の例）では、ブライアンのトランザクションとアンヌのトランザクションは実際にはゲールのトランザクションのサブトランザクションである。従って、ゲール、ブライアン、及びアンヌのトランザクションの各々は、ゲールのトップレベルのトランザクションと同一の細分性でロッキングを行うものととりあえず推定される。しかしながら、別の方法として、ゲールにセクションレベルでロックさせ、またこれと同時に、ドキュメント又はパラブラフレベルでロックする他のトップレベルのトランザクションを持つことも可能である。
【０１５１】
多細分性ロッキングの概念は知られているが、本発明では、多細分性ロッキングとネスト化データベースの概念の両方を一緒に用いてもよく、一般にこれらの概念は相互に直交している（例えば、互いに独立している）ものと考えられている。多細分性ロッキングに関しての更なる情報は、以下で参照されている Ａｎｆｉｎｄｓｅｎの論文から得ることができるであろう。
【０１５２】
図２４（ａ）〜２４（ｄ）の実施例に戻って、図２４（ａ）にゲールのテキストエディタの例示的なスクリーンイメージ７１０を示す。問題になっているテキストのドキュメントはセクション１、セクション２、セクション３、セクション４で示される４セクションを有する。図２４（ａ）において、ゲールは図示されたドキュメントの全てのセクションをロックしており、全ドキュメントの完全エディット能力を有する。各セクションにおいて、サンプルテキストが図示されているが、任意の所望のテキストを使用してもよい。
【０１５３】
図２４（ｂ）のスクリーンイメージ７２０もまたゲールのテキストエディタを示しているが、しかしこのイメージでは、ゲールはセクション２、３、４をサブデータベースに委託（ｄｅｌｅｇａｔｅｄ）してしまっており、セクション２、３、４を通じて斜線で示されているこれらのセクションは今はゲールのエディタ内でリードオンリーになっている。
【０１５４】
図２４（ｃ）のスクリーンイメージ７３０は、ブライアンのテキストエディタを示す。図２４（ｃ）に関しては、ブライアンはゲールのサブデータベース（そこで作業することがブライアンはゲールによってオーソライズされている）を介してゲールのドキュメントにアクセスした。ブライアンは、セクション２及び４上に書込みロックを問題なくリクエストし、その結果セクション２及び４はブライアンのエディタ内でエディット可能であるが、セクション１及び３はリードオンリーである。なお、ドキュメントのリードオンリーセクションを通じての斜線は、説明の目的だけのためであり、斜線がテキストにかけられているいる必要はない。しかしながら、好ましい一実施形態では、或るセクションはロックされており他のセクションはロックされていないことを示すことが望ましいかもしれない。これは、異なるタイプやロックのモードやアクセス能力に対してテキストの異なる色やテキストのバックグランドを利用することによって達成されるであろう。例えば、一つの色を各個人に割り当てることができ、各セクション又はドキュメントの他の部分は、データ上に書込みロックを有する個人又はグル−プ（ｅｎｔｉｔｙ）に従って色がつけられるであろう。或いは、単一の色がリードオンリーであるドキュメントのセクションを示すために利用されてもよい。
【０１５５】
最後に、図２４（ｄ）にアンヌのテキストエディタを示すスクリーンイメージ７４０を図示する。
【０１５６】
アンヌはゲールのサブデータベース（そこで作業することがアンヌはゲールによってオーソライズされている）を介してゲールのドキュメントにアクセスした。アンヌは、セクション３上に書込みロックを問題なくリクエストでき、その結果セクション３はアンヌのエディタ内でエディット可能であるが、セクション１、２、４はリードオンリーである。
【０１５７】
本発明は、明細書の教示に従ってプログラムされた一以上の従来の汎用ディジタルコンピュータを使用して差し支えなく実施され得ることは、コンピュータ技術の当業者であれば明白であろう。当業者にとっては明白であるように、適切なソフトウエアコーディングが、本開示の教示に基づいて、熟練プログラマーによって容易に用意できる。当業者にはすぐ明白となるように、本発明はまた、特定の集積回路のアプリケーションを用意すること又は従来のコンポーネント回路の適切なネットワークを接続することによって実施されてもよい。更に、本発明は、複数のコンピュータ、計算デバイス、他のタイプのデバイスを使用して実施されてもよい。これらのデバイスは、データ、命令、データのリクエスト、及びデータベースマネジメントシステムの運用に関係する他の任意の情報を伝達するために、如何なるタイプのネットワークを介して接続されてもよい。係るコンピュータネットワークは、必要に応じて、有線ネットワーク、電波、赤外線、又は超音波タイプネットワーク等の無線ネットワークを使用して実施されてもよい。汎用コンピュータの使用の代わりにあるいは追加として、本発明は、パーム・パイロット（Ｐａｌｍ Ｐｉｌｏｔ）、インターネットサーバ、特別目的コンピュータ、及び電話ブラウザを含む任意のタイプのインターネットブラウザ等のパーソナルディジタルアシスタントを含む任意のタイプのデバイスを使用して実施されることを含む。
【０１５８】
本発明は、本発明のプロセスを遂行するようにコンピュータをプログラムするために使用され得る命令を含む記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、磁気カードや光カードを含む任意のタイプのディスク、又はハードディスクドライブを含む電子命令を記憶するのに適している任意のタイプの媒体を含むことが出来るが、本発明の記憶媒体はこれに限られるものではない。また、本発明は、本明細書に記載されており、且つこのアプリケーションで論じられる何れかのメモリ又は保存媒体に記憶されてもよいデータ構造を含む。
【０１５９】
本発明は特定の好ましい実施形態を参照して記載されてきたが、当業者にとっては、本発明の範囲及び精神を逸脱することなしに、種々の変更が可能で同等物が要素の代用になれるということは明白である。例えば、本発明は、一メモリに記憶されたデータ構造を記載しているが、それはそのデータ構造を複数のメモリに記憶するのと同等であろう。更に、本発明は必要に応じて、データ構造を結合することもその範囲に含むものである。
【０１６０】
本発明は、発明者によって種々の出版物に従前記載されてきた技術及び理論の上に立ってなされた。これらの出版物としては、「Ａｐｏｔｒａｍ−アプリケーション指向のトランザクションモデル」、理学博士論文、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、１９９７年；「ネストされたデータベースによるマルチメディア会議での支持的共同作業」、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、ノルウェーコンピュータ科学会議議事録−ＮＩＫ’９６、１９９６、３１１−３２２頁；及び「ネストされたデータベースによる工学環境での共同作業サポート」、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、ＣＥＥＤＡの議事録、１９９６、Ｐｏｏｌｅ、ＵＫ、３２５−３３０頁、が挙げられ、これらを本明細書の一部を構成するものとしてここに援用する。これらの出版物に引用されている参考文献の各々も同様に本明細書の一部を構成するものとしてここに援用する。これらの出版物中のアプリケーション及び説明の各々は、本発明によって実施されるか、又は本発明と一緒に利用されてもよい。更に、米国特許第５，９８３，２２５号及び第６，０４４，３７０号を含む本発明者による米国特許を本明細書の一部を構成するものとしてここに援用し、本発明と一緒に使用しても、又は本発明と別個に使用してもよい。
【図面の簡単な説明】
【図１】
図１は、本発明を実施するデータベースマネジメントシステムのブロックダイアグラムである。
【図２】
図２は、サブデータベースに分割される資源について追跡履歴を保持（ｋｅｅｐｉｎｇ ｔｒａｃｋ）するためのデータ構造を示す。
【図３】
図３は、複数のリンクされたロック制御ブロック及びロックリクエストブロックを示す。
【図４】
図４は、サブデータベース内のデータ・アイテムに関するロックを設けるために用いるサブデータベースロック制御ブロック（ＳＬＣＢ）を含むデータ構造を示す。
【図５】
図５は、各トランザクションが特定のデータベース又はサブデータベースに属することを示す。
【図６】
図６は、この特定の実施態様において、トランザクションがそれ自身のデータベース又はサブデータベース中の資源にのみアクセス可能であることを示す。
【図７】
図７は、データベース制御ブロック（ＤＢＣＢ）データ構造の例示的構成を示す。
【図８】
図８は、トランザクション制御ブロック（ＴＣＢ）データ構造の例示的構成を示す。
【図９】
図９は、階層中に実現させたサブデータベースの例を示す
【図１０】
図１０は、アクティブトランザクションフィールドをデータベース制御ブロックに用い、コンテキストデータベースとサブデータベースフィールドとをトランザクション制御ブロックに用いた例を示す。
【図１１】
図１１は、サブデータベース毎に一サーチテーブルが存在し、且つサーチテーブルがサブデータベースロック制御ブロックへのリファレンスを含む、別の態様を示す。
【図１２】
図１２は、サブデータベースロック制御ブロックがアレイやテーブル内に含まれている、例示的構成を示す。
【図１３】
図１３は、データベース制御ブロックとトランザクション制御ブロックとを単一の階層的データ構造アレンジメントとして実現可能であることを示す。
【図１４】
図１４は、ロック制御ブロックデータ構造の別の構成を示す。
【図１５】
図１５は、新しいサブデータベースを作出するためのフローチャートである。
【図１６】
図１６は、ユーザ・データの物理的動きを必要とせずに如何にサブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）するかを示すフローチャートである。
【図１７】
図１７は、図１１のデータ構造を用いてサブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）するための別の実施形態を示すフローチャートである。
【図１８】
図１８は、ネスト化データベースの存在下でのロックリクエストの取り扱いを示すフローチャートである。
【図１９】
図１９は、ロック制御ブロックが図１１の別の構造を有する時の、ネスト化データベースの存在下でのロックリクエストの取り扱いを示すフローチャートの別の態様である。
【図２０】
図２０は、サブデータベースの使用を終わるために用いるプロセスのフローチャートである。
【図２１（ａ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｂ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｃ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｄ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２２（ａ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｂ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｃ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｄ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２３（ａ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｂ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｃ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｄ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２４（ａ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｂ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｃ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｄ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【符号の説明】
１００ データベースマネジメントシステム（ＤＢＭＳ）
１０２ トランザクションマネージャ
１０４ ロックマネージャ
１０６ データプロセッサ（ＣＰＵ）
１０８ トランザクションテーブル
１１０ ロックテーブル
１１２ データベース
【発明の属する技術分野】
本発明は一般にデータベースマネジメントシステムに関し、より詳細には、データベース資源を不適切な使用から守るためにロックマネジャを用いたデータマネジメントシステムやトランザクション処理システムに関する。
【０００１】
本発明は更に、メモリにストアされたコンピュータデータ構造に基づいて、ネスト化データベースの使用を許容するデータベースマネジメントシステムの実行方法にも関する。加えて本発明は、共有データへの同時アクセスを提供する如何なるシステムにも関するものであって、またそのようなシステムに適用できる。
【０００２】
【従来の技術、及び発明が解決しようとする課題】
二人の人や二グループの団体が同時に或るデータベースやその他のロケーションに存在する情報にアクセスしたい時、あるいは同時か殆ど同時に同一の情報に関するデータベースにデータを書き込みたい時に存在する問題として、コンフリクト等の問題は避けることができない。このような問題は、データが共有されるタイプのアプリケーションでは如何なるアプリケーションでも起こりうるものであって、ワード・プロセッシングとエンジニアリング設計は、そのような同時アクセスが起こる２つの領域である。但し、本発明はこれら二領域に加え、二以上のグループが同一のデータを使用したいと希望する如何なる状況に対しても適用可能である。
【０００３】
データベースマネジメントシステムにおいては、ＡＣＩＤ （”Ａｔｏｍｉｃｉｔｙ， Ｃｏｎｓｉｓｔｅｎｃｙ， Ｉｓｏｌａｔｉｏｎ， Ｄｕｒａｂｉｌｉｔｙ”）と称される特性が望まれる。
【０００４】
Ａｔｏｍｉｃｉｔｙ（アトミック性）とは、トランザクション（即ちデータベースへの変更）の結果が全て正しくデータベースに反映されているか、あるいはトランザクションの結果のいずれも全く反映されていないことを意味する。一般に、トランザクションについては「コミット（確認）」あるいは「アボート（中止）」という表現が用いられる。トランザクションが確認されると、このトランザクションによってデータベースになされた全ての変更が恒久的に保存され、データベースは定常状態に置かれる。
【０００５】
トランザクションが中止されると、このトランザクションによってデータベースになされた如何なる変更も撤回され、この場合もやはりデータベースは定常状態（ｃｏｎｓｉｓｔｅｎｔ ｓｔａｔｅ）に置かれる。
【０００６】
Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）とは、各トランザクションがデータベースに対し矛盾のない結果のみを確認することを意味する。
【０００７】
よって或るトランザクションによって、データベースは或る一定常状態から他の或る一定常状態にされなければならない。
【０００８】
Ｉｓｏｌａｔｉｏｎ（隔離性）とは、トランザクション内の事象が同時的に進行している他のトランザクションから隠されていなければならないことを意味する。同時的トランザクションは互いに干渉してはならない。それらトランザクションはあたかも専用のデータベースを有するがごとくに実行されなければならない。
【０００９】
Ｄｕｒａｂｉｌｉｔｙ（継続性）とは、一旦トランザクションが完了し、その結果がデータベースに対し確認されてしまうと、その後如何なる動作不良があってもこれらの結果が生き残り続けることをシステムが保障しなければならないことを意味する。
【００１０】
上記のＡＣＩＤ 特性は非常に望ましいものであるが、同一のデータに書込む者が複数存在すると、通常、ＡＣＩＤ 特性との妥協が必要となる。トランザクションの諸特性を確実にし且つ同時に各人又は各トランザクションがしようとしていることを何であれ許容することは非常に困難である。
【００１１】
或るデータが使用されている時に、他者に対し単純に該データへのアクセスを許容すると、ＡＣＩＤ 特性との不可避なコンフリクトが顕在化する。
【００１２】
【課題を解決するための手段】
従って、本発明の一目的は、同一のデータに複数の団体がアクセスできるようにすることである。本発明の更なる目的は、複数のユーザが存在する環境で、可能な限りＡＣＩＤ 特性が維持されるよう、データをロックすることである。本発明の更なる目的は、複数のユーザや団体が、種々の異なるデータベース（以下、これら異なる各種データベースを、単にデータベースと称するかあるいはバーチャルデータベース、サブデータベースと称する）を経由してデータにアクセスできるようにするデータベースマネジメントシステムを提供することである。本発明の更なる目的は、サブデータベースやバーチャルデータベースの実行を許容するデータベースマネジメントシステム及び／又はそのデータ構造を提供することである。
【００１３】
これら及びその他の目的は、複数のユーザが存在する環境で、データの同時実行制御とロックを許容する、データ構造を有するメモリ、方法、システム、及びコンピュータプログラム製品によって達成される。現在存在するトランザクションについて、そのトランザクションに関連するデータベース又はサブデータベースへの関連付けや参照（リファレンス）を有する。トランザクションに関係するこのデータ構造を以下、トランザクション制御ブロックと称する。
【００１４】
データ構造（本明細書ではこれをデータベース制御ブロックと称する）は、どのデータベースあるいはサブデータベースがデータ・アイテムに関係しているかを示す。更に、そのデータについての実際のロックに関係するデータ構造が存在し、これをロック制御ブロック（及び／又はロックリクエストブロック）と称する。
【００１５】
種々のデータ構造間の関連付けにより、ネストされたデータベース、サブデータベース、バーチャルデータベースという概念を実現させることができる。例えば、データ構造アレンジメントは、好ましくは特定のトランザクションのコンテキストデータベースに関する判断（ｄｅｔｅｒｍｉｎａｔｉｏｎ）が存在することを許容すると共にそのトランザクションの下のサブデータベースを許容する。更に、トランザクションに関係するデータ構造は、そのデータのロックに関するデータ構造によって表される、許可されたあるいは許可待ちのロックリクエストへの参照を含む。バーチャルデータベースに関係するデータ構造、即ちデータベース制御ブロックは、ロッキングデータ構造として参照され、ロックが関係するのはいずれのデータベースあるいはサブデータベースであるのかを決定できるようになっている。
【００１６】
本発明の一実施形態では、データ処理システムによってアクセスされるデータをストアするためのメモリが存在する。このデータは必ずしもエンドユーザが究極的に欲しているデータ・アイテムである必要はなく、ロッキングとサブデータベース情報を示すデータ構造に関係するデータであることができる。メモリは、トランザクションの情報を含むデータ構造を有する。好ましくは、このデータ構造はトランザクション制御ブロックとして実現される。メモリは更にトランザクションのデータのロックの情報を含むデータ構造を有する。このデータ構造を、以下、ロック制御ブロック及び／又はロックリクエストブロックと称する場合がある。更に、複数データベースの情報を含む複数のデータ構造が存在する。種々のデータベースに関係するこれらのデータ構造を、データベース制御ブロックと称する場合がある。このデータベース制御ブロックを用いて特定のデータベースやサブデータベースをロック及びトランザクションに関連付け、あるいはその逆に関連付け、ネスト化データベースあるいはサブデータベースを適切に制御する。
【００１７】
本発明はまた、ネスト化データベースあるいはサブデータベースの概念を実現化する、データ構造の作成（ｃｒｅａｔｉｏｎ）と使用に関する。あるデータ・アイテムがロックされていることを示す一方法は、第一の階層レベルと関連する第一のトランザクションによってそのデータ・アイテムがロックされていることを示すデータ構造をこの第一の階層レベルに作成する種々の段階を含む。
【００１８】
更に、本発明方法は、データ・アイテムが第二の階層レベルと関連する第二のトランザクションによってロックされていることを示すデータ構造を第二の階層レベルに作成する段階を含む。かくして、これら段階は、制御されたデータ構造（ロック制御ブロック等）の階層を作成する。階層における各レベルは異なるデータベース、サブデータベース、又はバーチャルデータベースによって使用されることができる。
【００１９】
或るデータ・アイテムへのアクセスを達成するためには、最初に判断しなければならないことがある。それはそのデータ・アイテムに関してロックが存在するかどうかという点である。これについては次の各ステップを追うことによって決定できる：（ａ） 第一の階層レベルにそのデータ・アイテムに対するロックが存在するかどうかを判断するステップ、及び （ｂ） ステップ（ａ）でそのデータ・アイテムに対するロックが存在しないと判断された場合、第一の階層レベルにおいてそのデータ・アイテムに対するロックを作成するステップ。
【００２０】
ステップ（ｃ）は、ステップ（ａ）でそのデータ・アイテムに対するロックが存在しないと判断された場合、第二のレベルに該データ・アイテムに対するロックが存在するかどうかを判断するステップである。更に、ステップ（ｄ）は、そのデータ・アイテムに関するロックが第二の階層レベルに存在しないと判断された場合、該データ・アイテムに関するロックを作成するステップである。
【００２１】
上記の機能を実行する方法の各ステップに加え、本発明は、上記機能を行使するための各種手段を有するシステムを包含する。更に、本発明は、本方法を実施するための実行可能な指令を含むコンピュータプログラム製品も包含する。
【００２２】
【発明の実施の形態】
本発明とその利点については、添付の図面を参照することによってより完全な理解に到達できるであろう。
以下、図を参照して本発明を説明する。各図面を通して、同一の参照番号は同一又は対応する部分を示す。図１はデータベースマネジメントシステム（ＤＢＭＳ）１００を示す。トランザクションオペレーション及びマネージメント（管理）はトランザクションマネージャ１０２及びロックマネージャ１０４で処理されるが、これらは両者ともシステムのデータプロセッサ即ちＣＰＵ１０６によって実行されるソフトウエア手続である。トランザクションマネージャは、許可待ち中のトランザクションのアイデンティティとステータスの追跡履歴（ｔｒａｃｋ）を残すためにトランザクションテーブル１０８（これはツリー構造として実施されることもある）を維持する。ロックマネージャ１０４はロックテーブル１１０を維持するが、これは通常ハッシュテーブル及び種々のリンクしたリスト及び／又はツリー構造（以下により詳細に記述する）を使用して実施される。ロックテーブル１１０はデータベース１１２中の資源に関してリクエストされたロックの追跡履歴を保持する。ロックテーブル１１０は、トランザクションのメモリアドレス、トランザクションＩＤ、ロックのタイプやモード、ロックのパラメータ、ロックと関連したデータベースやサブデータベースに関係する情報を蓄えてもよい。データベース１１２は、ＤＢＭＳ１００によって実行されるトランザクションにアクセス可能なデータを保存する。データベース１１２は永続的なデータを保存する必要はない（但し通常の場合は永続的なデータ保存である）。別の方法では、保存されたデータは暫定的であってもよい。従って、データベースの内容について共同的に作業しているトランザクションは、ほんの数分、数時間、又は数日だけ存在するデータ資源を処理出来、システムが取り出されるかシャットダウンされた場合には存在しなくなるであろう。
【００２３】
またＤＢＭＳ１００は、通常、付加的メモリ資源１１４、システムの種々の部分を相互接続するための一以上のシステムバス１１６、及びネットワークインターフェース１１８やクライアントワークステーション１２０との通信を取扱うための他の通信インターフェースを含む。メモリ１１４は、ランダムアクセスメモリを含むがそれに限定されない如何なるタイプのメモリを使用して提供されてもよく、好ましくは、読出し可能で且つ書込み可能なメモリである。更に、メモリ１１４は本発明のデータ構造を保存するために利用してもよい。図１は本発明の一つの可能な実施例を示すが、本発明の機能を達成するために、任意の所望のハードウエア及びソフトウエアを利用できる。例えば、本発明は、任意のタイプのコンピュータ、コンピュータサーバ、及び／又はパーソナルコンピュータ及び／又は任意の所望のオペレーティングシステムが動作するハードウエアを使用して実施できる。係るハードウエアの構成要素、構造、及び作用は周知である。
【００２４】
図２を参照すると、好ましい実施形態における「ロックテーブル」１１０が次のように提供される。ハッシュ関数１５０を用いて、資源識別子（ＲＩＤ）を、固定したサイズを有するように提供されるハッシュテーブル１５２内のハッシュテーブルアドレスに変換する。関数１５０によってハッシュされる資源識別子は、資源のタイプやレベルの標識（例えば、ロックされるべき資源は、データベース、テーブル、ページ、組（ｔｕｐｌｅ）、その他の何れであるかを示す）及び資源の開始アドレスを含んでもよい。ハッシュテーブルのスロット１５４−１等の各アドレス可能なスロット１５４は、そのスロットのハッシュテーブルアドレスに対応するロックされた資源がない場合のヌル値か、ハッシュ値がそのスロットのハッシュテーブルアドレスに対応する一以上のロックされた資源が有る場合には、ＬＣＢ１６０−１等のロック制御ブロック（ＬＣＢ）のリストへのポインタの何れかを含む。
【００２５】
ロックマネージャは、実際にロックされる各ロック可能なデータ・アイテムに対して一ロック制御ブロック（ＬＣＢ）１６０を割り当て（即ち生成し記憶される）、トランザクションが有する各ロックに対してＬＲＢ１６２−１等の一ロックリクエストブロック（ＬＲＢ）１６２を割り当てる（即ち生成し記憶される）であろう。従って、もし特定のデータベースの一オブジェクトが三つの異なるトランザクションによって所定の時点でロックされる場合には、そのオブジェクトに対してＬＣＢ１６０が一個と、そのＬＣＢから“ぶら下がっている（ｈａｎｇｉｎｇ）”リンクした３個のＬＲＢ（トランザクション当たり一）のリストとが存在するであろう。
【００２６】
各ＬＣＢ１６０は好ましくは次のものを含む：
ロックされた資源に対する資源識別子のコピーを通常含むロックＩＤ １７０と、
このＬＣＢによって表わされるデータベース資源に関して認められた（ｇｒａｎｔｅｄ）全てのロックの最も制限的なアクセスモード（例えば、ブラウズ、読出し、パラメータ化された読出し、書込み、パラメータ化された書込み、又は排他（ｅｘｃｌｕｓｉｖｅ））を示すモード標識１７１と、
ロックされた資源の未処理の（ｏｕｔｓｔａｎｄｉｎｇ）パラメータ化された読出しロック（もし有れば）によって使用される読出しパラメータの論理ＯＲを表わす、好ましくはビットマップの形態にある、任意的読出しパラメータ標識１７２と、
ロックされた資源の未処理のパラメータ化された書込みロック（もし有れば）の書込みパラメータ、好ましくはビットマップの形態にある、オプショナル書込みパラメータ標識１７３（なお、読出し及び書込みパラメータ標識１７２及び１７３の詳細によって本発明の様相が更に構成されるものであるがこれについては、Ａｎｆｉｎｄｓｅｎに付与された米国特許第５，９８３，２２５号に詳細に記載されており、それを本明細書の一部を構成するものとしてここに援用する）と、
このＬＣＢによって表わされるデータベース資源のための認められた資源リクエストに対するＬＲＢ １６２のリストへの認められたリクエストリストポインタ１７４と、
このＬＣＢによって表わされる許可待ち（即ち、未だ認められていない）資源リクエストに対するＬＲＢ １６２のリスト（キュー（ｑｕｅｕｅ）とも呼ばれる）への許可待ちリクエストポインタ １７５と、
このＬＣＢが属するデータベース又はサブデータベースへの参照であるデータベースフィールド１７７とを含む。本発明の特徴は、データは、本明細書ではサブデータベース、バーチャルデータベース、データベースとして参照される異なるデータベースに分割されてもよいということである。係る分割を行うことにより、同一のデータを使用する人やトランザクションが複数あることが可能である。係るシステムにおいて、本発明者は、或るロックがどのデータベースに属するかを知ることが望ましく、また係る情報はデータベースフィールド１７７を使用して容易に決定され得ることを見出した。本発明の特徴はデータベースリファレンス１７７等のリファレンスを使用して実現されるが、ＬＣＢ内のデータベース名を含むような他の実施形態も可能である。図２では、データベースリファレンス１７７はグローバルデータベース１９２を参照している。
【００２７】
このグローバルデータベース１９２は最高レベルのデータベースであり、更なるサブデータベースは、ＤＢ１、ＤＢ２、・・・ＤＢｎとして言及される。サブデータベース使用の更なる詳細を以下に説明する。即ち、
ネクストレベルＬＣＢリファレンス１７８は、サブデータベースロック制御ブロック（ＳＬＣＢ）１６４−１等のサブデータベース（異なる階層レベルでのバーチャル又はサブデータベース）ロック制御ブロックを示し（このリファレンスは、ヌルか、又は異なる階層レベルでのサブデータベースロック制御ブロックの何れかを参照する。このフィールドに関する更なる情報を以下に述べる）、そして
このＬＣＢと同一のハッシュアドレスを共有する次のＬＣＢ（もし有れば）への次のＬＣＢポインタ１７６。
【００２８】
ＬＣＢ １６０内のフィールド１７２及び１７３によって表わされる読出しパラメータと書込みパラメータは、本発明にとって必須ではないが、本発明におけるサブデータベースの発明と合わせて又は切り離して使用されてもよい特徴を表わす。更に、パラメータ１７２及び１７３は、ＤＢＭＳによって使用される従来のアクセスモードへの本発明による拡張を表わす。読出し／書込みパラメータドメインの定義されたセットの各異なる値が、対応するデータの信頼性の分類又はカテゴリーを表わす。従って、８個のパラメータ値（各々８−ビットパラメータフイールドの対応するビットによって表わされる）を有するパラメータドメインは、８個迄の異なるデータ信頼性分類を定義することが可能であろう。本発明の別の実施形態においては、パラメータを、“信頼性”以外のデータベースオブジェクトのプロパティ（例えばオブジェクト上に書込みロック状態を作るアプリケーションのタイプやそのＩＤ、又は書込みロックされていてもデータを読もうとするか否かを判断するためにアプリケーションによって使用され得る他の情報等）を示すために使用してもよい。
【００２９】
許可された（ｇｒａｎｔｅｄ）又は許可待ちの一ロックリクエストを表わす各ＬＲＢ １６２は、好ましくは、次のものを含む：
特定のトランザクションによって資源がアクセスされるかリクエストされるアクセスモード（例えば、ブラウズ、読出し、パラメータ化された読出し、書込み、パラメータ化された書込み、又は排他（ｅｘｃｌｕｓｉｖｅ））を示すモード標識１８１と、
このＬＲＢに対応するロックをリクエストしたかあるいは保持するトランザクションを同定するトランザクション識別子１８４と、
この読出し又は書込みロックの所有者によって使用される読出し又は書込みアクセスモードパラメータ（もし有れば）を表わす、好ましくはビットマップ形態にある、任意的パラメータ標識１８２（このフィールドは、このロック又はロックリクエストされる所有者がパラメータ化されたアクセスリクエストを使用している場合にのみ使用される。ロック制御ブロックのパラメータ１７２及び１７３のように、パラメータフィールド１８２は、本発明に係るネスト化データベースやサブデータベースを実施するために必須ではなくまた、必要でもない）と、
トランザクションＩＤ １８４によって同定されるトランザクションＴ１等のトランザクションによって所有されるＬＲＢのリンクしたリストを形成するために使用されるロックセットポインタ１８５（なお、ＬＲＢのリンクしたリストは、二重にリンクしたリスト等の更なる特徴を含むように実施されてもよく、それによりＬＲＢのチェーンを二方向にトレースすることが可能になる。ＬＲＢの更なる別態様が以下に記載される）と、
このＬＲＢと同一のデータベース資源に対するネクストＬＲＢ（もし有れば）へのネクストＬＲＢポインタ１８６。
【００３０】
ＬＣＢの読出し及び書込みパラメータフィールドとＬＲＢのアクセスモードパラメータフィールドに対する典型的なサイズは１〜２バイトで、８〜１６個の別個のパラメータ値をサポートする。
【００３１】
サブデータベースＬＣＢ（ＳＬＣＢ）１６４−１は、ＬＣＢ １６０−１ と同一又は類似の構成を有している。従って、サブデータベースＬＣＢ１６４は、サブデータベースのデータに対するアクセスのロックを制御するために ＬＣＢが使用されることを明確に示すためにＳＬＣＢと呼ぶ。図２において、ＳＬＣＢ １６４−１からサブデータベースＤＢ１ へのリファレンス又はポインタはデータベースリファレンス１７７ であり、 ＳＬＣＢ １６４−１ はサブデータベースＤＢ１ に接続されていることを示している。同様に、ＬＣＢ １６０−１ のデータベースリファレンス１７７ はグローバルデータベース１９２ を参照する。しかしながら、ＤＢＭＳは、全ての ＬＣＢ、或いは少なくとも第一レベルのＬＣＢ がグローバルデータベース１９２ を参照するようにセットアップできるため、 ＬＣＢからデータベースリファレンスフィールド１７７ を削除することが可能てあり、好ましい。
【００３２】
本明細書全体を通して、図面は、一つのフィールドから図中の他のアイテムを指定するポインタとして現れるもを示す。これらのポインタは、従来のコンピュータのポインタに限定されず、任意のタイプのリファレンス又はツリー構造として実施できる。更に、参照する情報をデータ構造自体に含めてもよい。したがって、フィールド１７７ がグローバルデータベース１９２ を参照する代わりに、グローバルデータベース１９２ に関連する情報をフィールド１７７ に入れてもよい。以下に詳細に説明するが、グローバルデータベース１９２ 及びサブデータベースＤＢ１ 、ＤＢ２ 、．．． 、ＤＢｎ を含む種々のデータベースはデータベース制御ブロック（ＤＢＣＢ）であり、好適な実施形態では、エンドユーザが最終的に必要とするデータを含んでいない。むしろ、データベース制御ブロックは、データベース又はサブデータベースの何れにロック又はロック制御ブロック（即ち、ＬＣＢ ）が関係しているのかを示すのに使用される。
【００３３】
ＳＬＣＢ １６４−１は、ＬＲＢ １６２−１と同一の構造を有するＬＲＢ １６２−２ を参照する。図２は、二つのトランザクション制御ブロックＴ１、Ｔ２も示す。トランザクションＴ１はグローバルデータベースと関連付けられ、トランザクションＴ２はサブデータベースＤＢ１ と関連付けられている。更に、トランザクションＴ１は、 ＬＲＢ １６２−１を参照することにより許可ブロックリクエストを得る。同様に、トランザクションＴ２はＬＲＢ １６２−２ を参照する。これは、トランザクションＴ２がサブデータベースＤＢ１ に関連するデータにロークを有していることを示す。
【００３４】
本発明においては、ロックマネージャの主要部分はロック制御ブロック（ＬＣＢ） である。従来のデータベースマネジメントシステムのように、ＬＣＢ は、ロック可能な資源、例えば、リレーショナルやテーブルやレコードにおけるオブジェクト、ロー（組）を特定する。
【００３５】
そのような資源は通常オブジェクト ＩＤ（”ＯＩＤ”）、組ＩＤ（”ＴＩＤ”） 、ＲＯＷ／ＲＥＣＯＲＤ ＩＤ（”ＲＩＤ”）によって特定される。説明を簡単にするために、これらのＩＤ全体を示す用語としてＲＩＤ と言う語を使用する。
【００３６】
図２ではハッシュテーブルが示されているが、本発明はハッシュテーブルを用いたものに限定されない。考慮すべき点は、対応するＬＣＢ を見つけるのにＲＩＤ を使用するのが好ましく、ハッシュテーブルが好適な手段であることである。しかしながら、アレーやその他のサーチ型構造を用いることもでき、本発明はハッシュテーブルの使用に限定されない。
【００３７】
或るＲＩＤ には如何なるトランザクションによってもロックが設定されない場合、簡便な方法は、データ構造内にそのＲＩＤ のためのＬＣＢ を設けないことである。即ち、ハッシュテーブルから到達可能な ＬＣＢは、現時点における少なくとも一つのトランザクションによってロックされる可能性のある資源等の、全てのロック可能な資源のサブセットを表しているにすぎない。
【００３８】
ＬＣＢ を一方向にリンクするための別の方法として、二重にリンクされたリスト設けることができ、これによりＬＣＢ のチェーンを両方向にトレースすることが可能となる。各ロック可能な資源について、問題となっている資源に対してロックを保持するトランザクションが複数存在することが可能である。許可されたか或いは許可待ちのロックリクエストは、ロックリクエストブロック（ＬＲＢ） によって表される。各ＬＲＢ がそのＬＣＢ をリファーバック又は参照することが好ましい。この特徴は、簡明化とスペースの観点から図面には含まれていない。また、二重リンク構造を用いてＬＲＢ チェーンを提供することも可能であり、これにより、ＬＲＢ のチェーンを両方向にトレース（追跡）することが可能となる。更に、最初の ＬＲＢがＬＲＢ のチェーン内の最後のＬＲＢ を参照することも可能である。これにより、チェーンの終端を可能な限り速く見つけ出したいとき（例えば、待ちリストの終りに新しい ＬＲＢを挿入するとき）の性能を向上できる。例えば、この特徴を提供するためには、図３において、ＬＲＢ １６２−５ はＬＲＢ １６２−７ を参照する。
【００３９】
図３は、本発明で使用するデータ構造の例である。
【００４０】
しかしながら、簡明化のためにＤＢＣＢは示されていない。トランザクション制御ブロック（ＴＣＢ）Ｔｌ及びＴ２はトランザクションを表す。トランザクションは多くのロック、従って多くのＬＲＢ を持つことができ、一ＬＲＢ は一トランザクションのみに属するのが好ましい。各ＴＣＢ に対して一組のＬＲＢ が維持されている。図では、破線を用いてＬＲＢ 間の関係及び ＴＣＢからＬＲＢ への関係を表している。ＬＲＢ を二重リンクリストの形態で構成することもでき、更に、各ＬＲＢ がそのトランザクション制御ブロックを参照するようにＬＲＢ を設けることできる。例えば、この場合、図３の各ＬＲＢ１６２は ＴＣＢ Ｔ１ 又はＴＣＢ Ｔ２の一方を参照する。
【００４１】
本発明の ＬＣＢ及びＳＬＣＢのデータ構造から明らかなように、ロック可能な資源とデータベースを表すために一つのＬＣＢ が使用される。即ち、ＬＣＢ は特定のデータベース内のロック可能な資源（グローバルデータベース又はその中のサブデータベースの一つｔ）を表す。
【００４２】
図４はロッキングに用いるデータ構造を示し、各 ＬＣＢ（又はＳＬＣＢ）は単一のデータベース、従って単一のデータベース制御ブロック（ＤＢＣＢ）に関連しているのが好ましいことを示すために提供されている。例えば、図１においては、ＳＬＣＢ １６４−１はＤＢ１ を参照し、ＳＬＣＢ １６４−２はＤＢ２ を参照し、ＳＬＣＢ １６４−３はＤＢ１ を参照し、ＳＬＣＢ １６４−４はＤＢ２ を参照する。必要に応じ、グローバルデータベースのためのデータベース制御ブロックを持つことを回避することも可能である。何故なら、最も低い階層レベルにある ＬＣＢの各々はグローバルデータベースに属し、ＬＣＢ 及びトランザクションに対してのデフォルトであると考えることができるためである。この場合、グローバルデータベースとの関係を示すために ＬＣＢ及びＴＣＢ からの参照が適宜使用される
【００４３】
更に、図４は、任意数のレベルのサブデータベースをどの様にして作ることができるかを示す。上で述べたように、ＳＬＣＢの構造をＬＣＢ の構造と同一にすることが可能であり、サブデータベースのためのＬＣＢ をグローバルデータベースのためのＬＣＢ と区別するために、本特許出願では上記のようなラベリングを行った。しかしながら、ＬＣＢ をチェーンで結ぶために使用される「ｎｅｘｔ ＬＣＢ ｒｅｆｅｒｅｎｃｅ」を用いることなくＳＬＣＢを設けることによりメモリをある程度節約できる。しかしながら、必要に応じ、ＳＬＣＢを一方向に相互にリンクするか、或いは必要であれば二重リンクにすることもできる。図４では、ＬＣＢ １６０−１ 及び１６０−２ は第一レベルのＬＣＢ であり、グローバルデータベースに関連付けられておいる。ＳＬＣＢ １６４−１及び１６４−３ は第二レベルのＬＣＢ であり、第一レベルのＳＬＣＢと考えることもできる。ＳＬＣＢ １６４−２及び１６４−４ は第三レベルのＬＣＢ，、即ち第二レベルのＳＬＣＢである。同一レベルのＳＬＣＢ間のオプションのリンクは、破線の矢印又は参照記号によって表されており、二重リンクを設け、ＳＬＣＢ １６４−３がＳＬＣＢ １６４−１も参照できるようにすることも可能である。
【００４４】
図５は、好ましい実施形態では、各トランザクションが単一のデータベースに属していることを示す。トランザクション制御ブロックＴ１、Ｔ２、Ｔ３、．．． 、Ｔｍはそれぞれ、単一のデータベース制御ブロックを参照する。従って、特定のトランザクションに関連するデータベース又はサブデータベースのレベルを決定することが可能である。
【００４５】
図６はデータ構造の例を示し、好ましい実施形態のトランザクションはそれら自身のデータベース内の資源のみにアクセスする。例えば、実線の矢印を用いてグローバルデータベース１９２ を参照するトランザクションＴ１の場合、トランザクションＴ１は、破線の矢印を用いて ＬＲＢ １６２−１及び１６２−３ も参照するが、ＬＲＢ １６２−１ 及び１６２−３ の各々は、ハッシュテーブル１５２ によって参照される第一レベル即ち ＬＣＢレベルと関連付けられている。又、トランザクションＴ２及びそのトランザクション制御ブロックはサブデータベースＤＢ１ を参照するか又はその一部であり、破線の矢印を用いて ＬＲＢ １６２−２及び１６２−４ を更に参照するが、 ＬＲＢ １６２−２及び１６２−４ は、第二ＬＣＢ レベル即ち第一ＳＬＣＢレベルと関連付けられ、且つ ＤＢ１と対応している。好ましい実施形態においては、トランザクションは単一のデータベースのコンテキスト内で行われる。更に、トランザクションのデータベースの範囲内でない資源にトランザクションがアクセスすることを阻止するのが好ましい。実施レベルでは、これにより、トランザクションのＬＲＢ は、そのトランザクションのトランザクション制御ブロックが参照するのと同一のデータベース制御ブロックを参照する ＬＣＢ（又はＳＬＣＢ）に属するか又は関連付けられている。例えば、図６では、Ｔ２は ＤＢ１内で実行される。
【００４６】
従って、Ｔ２（１６２−２及び１６２−４）のＬＲＢ は、同一のデータベースＤＢ１ を参照するＬＣＢ（ＳＬＣＢ１６４−１ 及び１６４−２）に属する。
【００４７】
図７は、データベース制御ブロック（ＤＢＣＢ）の実施例を示す。好ましい実施形態では、ＤＢＣＢに対して、エンドユーザが最終的に必要とするデータを記憶することはリクエストされておらず、ＤＢＣＢの目的は、ＬＣＢ 又はＳＬＣＢによって少なくとも部分的に表されるロックがどのデータベース又はサブデータベースに属するかを示すことである。
【００４８】
図７では、ＤＢＣＢ ２０２は、ＩＤと略された識別子フィールド２０４ を含む。このフィールドはＤＢＣＢの名称又は識別情報を示す。アクティブトランザクションフィールド２０６ （Ａｃｔ Ｔｘと略す）は、問題となっているデータベース又はサブデータベース内において現時点でアクティブになっているトランザクションへのＤＢＣＢからのトレースを可能にする。例えば、サブデータベースの所有者がサブデータベースをコミット又は終了することを望む場合、上記の機能は望ましい。システムは、サブデータベースのアクティブトランザクションが何であるかを決定しなければならず、もしアクティブトランザクションのリストが空でない場合、サブデータベースの所有者は、サブデータベース内で他の作業が行われていることを示すと共に、現時点でそれらのトランザクションを終了することが望ましいか否かを問い合わせる警告を得る。サブデータベースを終了することについて責任を有する者（ｅｎｔｉｔｙ）に、終了の決定を変更する可能性を与えることが望ましい。
【００４９】
或いは、サブデータベース内においてアクティブトランザクションが実行されている時点ではサブデータベースを終了できないようにシステムを構成することも可能である。この場合、トランザクションを終了させ、アクティブトランザクションが存在しない時だけサブデータベースの終了が許容されるようにしなければならない。そのようなチェックがない場合、システムはトランザクション状態を停止し、データベース・マネジメントシステムの特性が望ましくない状態になるであろう。
【００５０】
アクティブトランザクションフィールド２０６ は、全てのアクティブトランザクションのリストを含むリンクされたリストの一部である単一のリファレンス又は複数のリファレンスを含んでいてもよく、或いは、アクティブトランザクションの名称又は識別情報を含んでいてもよい。それに加えるか又はそれに代え、アクティブトランザクションフィールドは、問題となっているデータベース又はサブデータベースのためのアクティブトランザクションの各々を参照する二重リンクリストを用いて実施することもできる。
【００５１】
所有トランザクションフィールド ２０８ （Ｏｗｎ Ｔｘと略す）は、問題となっているＤＢＣＢを作り、従ってそれを所有するトランザクションへの参照である。グローバルデータベースの場合、このフィールドはヌルリファレンスに設定されるであろう。また、サブデータベースの場合、このフィールドは、その作成／所有トランザクション制御ブロックを参照する。スーパーデータベースフィールド２１０ （Ｓｕｐ ＤＢと略す）は、このデータベースによってその一部を構成しているデータベースを表すＤＢＣＢへの参照である。
【００５２】
サブデータベースフィールド２１２ （Ｓｕｂ Ｄｂと略す）は、このデータベースのサブデータベースを表すＤＢＣＢのセットへの参照である。ネクストデータベースフィールド２１４ （Ｎｅｘｔ ＤＢと略す）は、データベース階層の同一レベル内の次のＤＢＣＢを参照する。先の（ｐｒｅｖｉｏｕｓ）データベースフィールド２１６ （Ｐｒｅｖ ＤＢと略す）は、サブデータベース階層の同一レベル内の前の ＤＢＣＢ への参照である。Ｎｅｘｔ ＤＢ 及びＰｒｅｖ ＤＢ フィールドは、サブデータベース階層内の或るレベルにおけるＤＢＣＢの二重リンクリストを作るために使用される。
【００５３】
このようにして、親データベースが同一であるサブデータベースが上記のリスト内でリンクされる。ＤＢＣＢ ２０２の最後のフィールドの３個の点又は楕円は、必要に応じて追加のフィールドがＤＢＣＢに含まれることを表している。
【００５４】
ＤＢＣＢ の目的は、資源階層又はデータベース階層において、ロック等の特定のものが属している場所を具体的に高精度で示すことである。これにより、サブデータベースとシステムの残部との関係を簡単に決定することが可能になる。
【００５５】
上記した ＤＢＣＢ 及び以下に詳述するトランザクション制御ブロック（ＴＣＢ） に関して、これらのデータ構造内に多数のフィールドが含まれているが、このフィードは各図に示されていない。参照の数を理解可能な範囲に抑え、且つ分かり易くするために、参照の内には図示しないものもある、即ち不要なものもある。したがって、図面に参照が含まれていないという事実は、参照が存在しないことを意味するものと解釈してはならず、同様に、データ構造が特定の参照又はフィールドを含むという事実は、そのような参照がそのデータ構造の絶対条件であると解釈してはならない。好ましくは、ＤＢＣＢは階層を形成している。
【００５６】
しかしながら、 ＤＢＣＢ を階層に配置しない構成も可能である。
【００５７】
図８はトランザクション制御ブロック（ＴＣＢ） データ構造２２２を示す。このデータ構造は、アクティブトランザクションを示し、トランザクションが属しているデータベース又はサブデータベースのレべルを示し、及び／又はトランザクションのロックされた資源とロックの状態を決定するために使用される。
【００５８】
ＴＣＢ 内には、例えば、トランザクションの名称を識別する識別子フィールド２２４ が設けられている。コンテキストデータベースフィールド２２６ （Ｃｔｘｔ ＤＢ と略す）は、問題となっているトランザクションについての範囲又はコンテキストを表す、データベースのＤＢＣＢを参照するために用いられる。
【００５９】
これは、トランザクションの作成時に決定されるであろう。本発明の実施形態によれば、トランザクションが発生してからそれが終了するまでトランザクションは存続し、その全ての動作を単一のデータベース内で行う。好ましい実施形態においては、トランザクションの存続期間の開始から終了まで単一のコンテキスト内にトランザクションを存在させるルールを用いることにより本発明は能率的に且つ適切に動作する。このように、コンテキストデータベースフィールド２２６ は、問題となっているトランザクションの範囲又はコンテキストを表すために使用される。例えば、コンテキストデータベースフィールド２２６ はグローバルデータベースを参照する。これは、ＴＣＢ に対応するトランザクションはグローバルデータベース内で実行されるか、又はそのコンテキストデータベースとしてグローバルデータベースを有していることを意味する。
【００６０】
図８のサブデータベースフィールド２２８ は、このトランザクションが作成したサブデータベースのセットを表すために使用される。なお、このフィールドを空にするか又はヌルを参照するようにすることも可能である。トランザクションは多数のサブデータベースを作成することが可能で、従って、多数のサブデータベースを所有することが可能である。
【００６１】
実行されているアクションの種類によっては、特定のトランザクションのためにどれだけ多くのサブデータベースが存在しているかを決定することが望ましい場合がある。従って、トランザクションを終了することが望ましくなった時点で、そのトランザクションが実行される前に存在していたサブデータベースを知ることが好ましい。同様に、既に説明したように、データベース制御ブロックのためのサブデータベースを知ることが望ましい。
【００６２】
フィルド２３０ はＴＣＢ の許可されたロックリクエストを表し、フィールド２３４ はＴＣＢ の許可待ちのロックリクエストを表す。図面、例えば図６に示すように、これらのフィールド２３０ 及び２３４ は、 ＴＣＢからＬＲＢ への参照を用いて作成される。
【００６３】
必要な場合、トランザクション又はＴＣＢ の階層を維持するためにスーパートランザクションフィールド２３６ が用いられる。スーパートランザクションフィールド２３６ は、問題となっているトランザクションよりも階層の高いトランザクションを参照又は指定する。例えば、問題となっているトランザクションを作成したか又はそのトランザクションの作成を許可したトランザクションを参照するためにトランザクションフィールド２３６ が使用される。
【００６４】
図９は、ＤＢＣＢ間の関係及びＤＣＢＣとＴＣＢ との関係を示す。これらのデータ構造は、資源のロックを制御するために使用される。図９では、図面が過度に複雑になることを避けるために、ハッシュテーブル、ＬＣＢ 、ＳＬＣＢ、ＬＲＢ は示されていない。しかしながら、通常、これらのデータ構造は、本システム内に存在している。図９には、ＴＣＢ Ｔ１、Ｔ２、Ｔ３、．．． 、Ｔｍが示されている。
【００６５】
ＤＢＣＢ ２４０、２５０ 、２６０ 、２７０ 、２８０ 、２９０ 、３００ も示されている。本例では、ＤＢＣＢの階層を見ることができる。例えば、ＤＢＣＢ ２４０は、ＤＢＣＢ階層構造にける最も高いレベルのＤＢＣＢであり、グローバルデータベース１９２ に対応している。ＤＢＣＢ ２４０に関しては、ＩＤフィールド２４１ が、このＤＢＣＢがグローバルデータベースのためのものであることを示す。ＤＢＣＢでは、グローバルデータベースの所有者、即ち所有トランザクションを明確に特定する必要はないので、Ｏｗｎ Ｔｘフィールド２４３ はヌルを示している。同様に、グローバルデータベースについてはスーパーデータベースは存在しないため、Ｓｕｐ ＤＢフィールド２４４ もヌルを示している。
【００６６】
Ｓｕｂ ＤＢ フィールド２４５ は、本データベースのためのサブデータベースを参照し、この場合、ＤＢＣＢ ２５０を参照する。この特定の例では、グローバルデータベースのレベルには、他のデータベースが存在せず、従って、Ｎｅｘｔ ＤＢフィールド２４６ 及びＰｒｅｖ ＤＢ フィールド２４７ の各々はヌルを示す。なお、図９では、図面を簡単にするために図７に示すアクティブトランザクションフィールド２０６ が示されていないが、上記した様に、好ましい実施形態では、アクティブトランザクションフィールドが使用される。
【００６７】
ＤＢＣＢ ２４０以下の階層レベルには ＤＢＣＢ ２５０ と２６０ がある。図９のフィールドは自明であるため、これらのフィールドの全ては説明しない。しかしながら、ＤＢＣＢ ２５０ に関しては、所有（ｏｗｎｉｎｇ）トランザクション２５３ が Ｔ２ を参照し、このＤＢＣＢのためのスーパーデータベース ２５４は、ＤＢＣＢ ２４０によって表されているグローバルデータベースであることが分かる。このサブデータベースのためのＤＢＣＢ ２５０は、ＤＢＣＢ ２７０を参照するＳｕｂ ＤＢ ２５５によって示されている。データベース ２５０の他のサブデータベース２３０、２９０、３００はサブデータベース ２７０にリンクされている。Ｎｅｘｔ ＤＢ フィールド２５６は ＤＢＣＢ ２６０を参照し、Ｐｒｅｖ ＤＢフィールド２５７ はヌルを参照する。
【００６８】
ＤＢＣＢ ２５０と階層レベルが同一のＤＢＣＢ ２６０ に関しては、所有トランザクション２６３ は Ｔ３ であり、スーパーデータベース２６４は ＤＢＣＢ ２４０ を参照し、ヌルを参照しているサブＤＢフィールド２６５ によって表されているようにＤＢＣＢ ２６０のためのサブデータベースは存在せず、フィールド２６６ によって示されているようにＮｅｘｔ ＤＢ は存在しない。Ｐｒｅｖ ＤＢ フィールド２６７ は ＤＢＣＢ ２５０ を参照する。ＤＢＣＢ ２４０、 ２５０、及び２６０ についての上記の記載から、ＤＢＣＢ ２７０、２８０ 、２９０ 、及び３００ の各々は、ＤＢＣＢ ２５０及び２６０ の階層レベルよりも低い同一の階層レベルであることが分かる。
【００６９】
ＤＢＣＢ に関しては、一般化して考えると、スーパーデータベースフィールドは、如何なるスーパーデータベースも参照しないグローバルデータベースを除き、一つのスーパーデータベースを参照する。そのような参照により、上記の階層の表現が可能とされている。図９は、特定の一連のトランザクションの間におけるＤＢＣＢの配置の例を示してるだけであり、図９に示す階層と全く同じである必要はない。
【００７０】
トランザクションがサブデータベースを作成する時、サブデータベースは、その作成するトランザクションのコンテキストに基づいて作成される。図９においては、トランザクションＴ２及びＴ３はグローバルデータベース内で実行されることが好ましい。何故ならば、その様にしないと、それらはグローバルデータベース内に属するサブトランザクションを作成できないからである。従って、ＤＢＣＢ ２５０及び２６０ が、それらの上位の（ｓｕｐｅｒｉｏｒ）のデータベースとしてＤＢＣＢ ２４０で表されるグローバルデータベースを有しているという事実は、所有トランザクションはグローバルデータベースをその範囲又はコンテキストとして有していることを示す。
【００７１】
更に、上で述べたように、各ＤＢＣＢのためのスーパーデータベースは一つしか存在しないことが好ましいが、サブデータベースの数は任意である。しかしながら、そのような必要のない別の実施形態も可能である。
【００７２】
図９は、例えば、ＤＢＣＢ ２５０がＤＢＣＢ ２６０を参照し、ＤＢＣＢ ２６０が ＤＢＣＢ ２５０ を参照することにより二重リンクリスト構造を示しているが、そのようなＤＢＣＢ間の二重リンクリスト関係は必須要件ではなく、ツリー構造等、他の構成も使用できる。別のオブジェクトを指定又は参照する ＤＢＣＢ からのポインタ又はリファレンスであることができるが、その目的は、ＤＢＣＢの位置を表す或る構造のセット又はリストを表すことである。この代替の実施形態では、別のデータ構造がデータ構造アレンジメントに付加される。そのような代替の配置は、データ構造アレンジメントをより複雑化するが、そのようにする利点がある。その一例は、必要であれば、ＤＢＣＢの次の参照及び／又は前の参照を削除できることである。
【００７３】
図１０は、図９に示されていないＴＣＢ 及びＤＢＣＢの別の詳細部分を示す。この詳細部分は、明確化及び図面が過度に乱雑になるのを防ぐために図９では省略されていた。同様に、図９に含まれている ＤＢＣＢ の特徴は、明確化のために図１０では省略されている。図１０では、アクティブトランザクションフィールドはＤＢＣＢ内に示されており、コンテキスト及びサブデータベースフィールドの使用は ＴＣＢに関して示されている。図１０のこれらのフィールドは、ＤＢＣＢとＴＣＢ の関係を寄り詳細に示す。
【００７４】
図９に示すように、トランザクションがその所有トランザクションの追跡履歴を保持（ｋｅｅｐ ｔｒａｃｋ）することが好ましく、又サブデータベースのアクティブトランザクションの追跡履歴を保持することが好ましい。
【００７５】
そのような機能は、 ＤＢＣＢ のアクティブトランザクションリファレンス又はフィールドによって行われる。図１０に示すように、ＤＢＣＢ ３１０は識別フィールド３１１ 及びアクティブトランザクションフィールド３１２ を有する。アクティブトランザクションフィールド３１２ は ＴＣＢ ３２０を参照する。これにより、ＤＢＣＢ ３１０に対応するサブデータベースの所有者は、ＴＣＢ ３２０ に対応するトランザクションがＤＢＣＢ ３１０のためのアクティブトランザクションであることを判定できる。更に、ＴＣＢ ３２０ の最も右側の部分においてＴＣＢ ３３０ への参照があり、ＴＣＢ ３３０ は ＴＣＢ ３４０を参照していることが分かる。
【００７６】
また、ＴＣＢ ３４０ は、ＴＣＢ ３２０ を参照するＴＣＢ ３３０ を参照する。更に、ＴＣＢ ３２０ 、３３０ 、３４０ の各々のコンテキストデータフィールドは ＤＢＣＢ ３１０ を参照する。
【００７７】
トランザクションが作成又は開始される場合、そのトランザクションがある種のコンテキストを有し、その中でトランザクションが実行されるのが好ましい。古典的なコンテキスト及び従来技術においては、このセッティングが常にグローバルデータベースであった。しかしながら、本発明のネスト化データベースでは、トランザクションをグローバルデータベース内で開始して実行でき、又ランザクションをサブデータベース内で開始することもできる。好ましくは、トランザクションが開始されたサブデータベース外のデータはアクセスできず、又、好ましくは、このトランザクションが実行されているデータベースをロックマネージャが知っているか判定でき、これがコンテキストデータベースとして参照されるものである。トランザクションがリクエストしている資源がコンテキストデータベース外である場合、そのような情報に対するアクセスのリクエストはロックマネージャによって拒否されるのが好ましい。しかしながら、別の方法として、問題となっているサブデータベースを動的に成長させることも可能である。必要であれば、この動的成長が丁度その時に起きるようにでき、又、更に必要であれば、成長を（ユーザの介在なしに）自動的に開始させることもできる。その様な成長は、図１６のプロセスに類似したマネージャ内で生じる。図１６は、新しいデータ・アイテムがどの様にしてサブデータベースに持ってこられるかを示す。リクエストされているデータがコンテキストデータベースの一部である場合、その資源はアクセス可能なデータベースに属し、評価しなければならない次の問題は、その資源について矛盾するロックが存在するか否かである。矛盾するロックが存在しない場合、ロックマネージャはロックリクエストを許可できる。従って、本発明のデータ構造は、資源がアクセス可能であるか否かの表示と、その資源がロックされているか否かの判定の両方を可能にする。
【００７８】
図１０を再度参照すると、ＴＣＢ ３２０ のＳｕｂ ＤＢフィールド３２３ は ＤＢＣＢ ３４８ を参照し、ＴＣＢ ３３０ のＳｕｂ ＤＢフィールド３３３ は ＤＢＣＢ ３４６ を参照し、ＴＣＢ ３４０ のＳｕｂ ＤＢフィールド３４３ はＤＢＣＢ ３４７ を参照することが分かる。 ＤＢＣＢ ３４８ 、３５２ 、３５６ に関しては、これらのＤＢＣＢのスーパーデータベースポインタ又はリファンレスは ＤＢＣＢ ３１０ を参照する。ＤＢＣＢ ３４８は、そのアクティブトランザクションリファレンスを使用してＴＣＢ ３６０ を参照する。ＴＣＢ ３６０ 及び３６４ はそれぞれ、コンテキストデータベースリファレンスを用いて ＤＢＣＢ ３４８ を参照する。
【００７９】
図１０の単純化したＤＢＣＢ及びＴＣＢ のフィールドの詳細構造は、明確化のためと、図１０がリファレンスによって過度に複雑になることを避けるために省略されている。
【００８０】
図１１は、資源のロックを制御及びモニターするために使用されるデータ構造の代替構成を示す。図２、図４、及び図６を参照して示した実施例では、或るデータベース内の或る資源のロックに対するロックリクエストをロックマネージャが処理するとき、グローバルデータベース内のその或る資源のためのＬＣＢ を見つけ出すために資源ＩＤ（ＲＩＤ） を最初に使用する。その後、必要であれば、同一のＲＩＤ ではあるが、処理中のロックリクエストによって特定された特定のデータベース又はサブデータベース内のＲＩＤ のためのＬＣＢ を見つけ出すために”Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ”リファレンスを使用する。図１１の代替の実施形態（及び図１２の代替の実施形態） は、上に述べた場合とは逆のイベントシーケンスを可能にする。即ち、図１１のデータ構造により、ロックマネージャは、ＤＢＣＢによって表されたデータベースを最初に見つけ、その後、そのデータベース内でＲＩＤ 見つけることが可能となる。これは、上に述べたように単一のグローバルサーチテーブルだけではなく、ＤＢＣＢ 毎に一つのサーチテーブルを設けることによって達成される。
【００８１】
図１１において、ＤＢＣＢは、その所有する（ｏｗｎｉｎｇ）ＴＣＢを参照することに加えサーチテーブルを参照する。このサーチテーブルは問題のデータベース内に含まれているＲＩＤへのアクセスを提供する。例えば、ＤＢ１はテーブル３８０を参照し、ＤＢ２はテーブル３９０を参照し、ＤＢｎはサーチテーブル４００を参照する。各サーチテーブル３８０、３９０、４００はＳＬＣＢを参照するが、このＳＬＣＢは特定のデータ・アイテムのロックに関する情報を提供する。図１１には図示されていないが、ＬＲＢは、ＳＬＣＢに関連する許可されたあるいは許可待ちのロックリクエストに対して用いることができ、その用い方は上に記載の実施態様におけると同様である。
【００８２】
テーブル３８０、３９０、４００等のサブデータベースサーチテーブルは、ハッシュテーブルとすることができるが、別の態様で作成することも可能である。例えば、ＬＣＢリファレンス群の固定サイズの配列アレイを用いて作成することができるであろう。サブデータベースのサイズがサブデータベース創出の際に固定されている場合にはそのような態様は有利であろう。あるいはまた、ＬＣＢリファレンス群の非固定サイズの配列アレイ（成長可能（ｇｒｏｗａｂｌｅ）アレイ）を用いて作成することもできる。ハッシュテーブルをサブデータベースサーチテーブルとして用いる場合、このハッシュテーブルには、所望により、グローバルデータベースハッシュテーブルよりもより少ないエントリーを割り当てることができる。ハッシュテーブルをサブデータベースサーチテーブルとして用いる場合、与えられたいずれのハッシュテーブルに対してもＬＣＢのチェーンを持つことができるであろう。これは例えば、サーチテーブル４００について図示されているように、リファレンス４０２はＳＬＣＢ １６４−５ を参照し、ＳＬＣＢ １６４−５ はＳＬＣＢ １６４−６を参照している。図１１に示す別実施形態では、各ＬＣＢは異なるサーチテーブルの下にオーガナイズされているので、ＬＣＢやＳＬＣＢの”Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ”フィールドはもはや必要でない。よってそのようなサーチテーブルの一つにおける所定のエントリーから、上述の実施形態のＬＣＢとＳＬＣＢの階層構造とは対照的に、ＬＣＢの線形構造にアクセスすることができる。図１１では、各サブデータベースＤＢＣＢは、その所有ＴＣＢへの参照を有し、また、各ＴＣＢはそこに含まれるＤＢＣＢへの参照を有する。図１１のデータ構造はスーパーデータベース・リファレンスの使用をなくするものではない（但し、これらリファレンスについては図１１、１２には図示していない）。
【００８３】
図１１では、トランザクションに対するコンテキストデータベースに関係する情報を示す、ＴＣＢとＤＢＣＢ間の両方向に行き来するリファレンスが存在する。即ち、例えばＴ１について説明すると、Ｔ１はグローバルデータベース１９２に向けられているので、Ｔ１がグローバルデータベース内で処理実行すること、あるいはＴ１がグローバルデータベースをそのコンテキストデータベースとして有することがわかる。ＤＢ１からトランザクションＴ１への参照について説明すると、この参照は、ＤＢ１がＴ１によって所有される、あるいは創出されることを示す。Ｔ２、Ｔ３、Ｔ４は全てＤＢ１を参照しており、これらのトランザクションはＤＢ１の範囲内あるいはコンテキスト内で実行されることを示す。図１１の示す所によれば、Ｔ４は、ＤＢ２からＴ４へと参照されることにより、ＤＢ２の作成元であるが、Ｔ４はＤＢ１内で動作する。この情報から、ＤＢ２はＤＢ１に含まれるサブデータベースであると結論することができる。念のため記載すると、図１１は単にサブデータベースシステムの一例を示すものに過ぎず、別の表現方法もありうる。しかしながら、図１１に示すように、Ｔ４を介する結合のゆえに、ＤＢ２の内部に存在するものはなんであれ、ＤＢ１のサブセットである。図１１はまた、Ｔ５とＴ６がＤＢ２をそのコンテキストとして実行することを示している。Ｔ６はＤＢｎを創出し、Ｔ７とＴ８とはＤＢｎの中で動作する。
【００８４】
図１２は、本発明の更なる別の実施態様を示す。サブデータベースは、サイズが小さくできることから（なぜならそれらは少数のロック可能な資源を含むようにできる為）、必要に応じて、サブデータベースを固定サイズとすることができるであろう。また、必要に応じて、サーチテーブル４１０、４１４、４１６はＬＣＢのアレイとできるであろう。各ＬＣＢはサブデータベースに対するものなので、図１２のＬＣＢは、ＳＬＣＢ（サブデータベースロック制御ブロック）１６４−１〜１６４−２０として示されている。リファレンス群のアレイやＬＣＢリファレンス群のハッシュテーブルではなく、ＳＬＣＢのアレイを用いることができるであろう。なお、ハッシュテーブル１５２は好ましくは前述の各実施形態に関して記載されたのと同様にして作成される。グローバルデータベースに対するこのハッシュテーブルの作成は、所望により、グローバルデータベースに対して多数のＬＣＢを使用することを許容するものである。もしサブデータベースの特定の使用が知られている場合には（知られていない場合でも）、サブデータベースにおけるアイテムの数を例えば２０データ・アイテム等の任意数に制限することが適切であるかもしれない。この数は必要に応じ、より大きくも小さくもすることができる。しかしながら、これは固定された数であって、実施形態においてはアレイ４１０、４１４、４１６が２０メモリを有するように作成することができる（各メモリは全ＳＬＣＢを保持できる）。そうすれば、もし割り当てられたメモリの一部分のみが用いられた場合、用いられていない部分は無駄になるが、この用いられていない部分はそれほど大きいものではなく、また、達成される利点として、新しいＬＣＢが導入されてもダイナミックメモリの割当てに対処する必要がない。また、サーチテーブルなしにＬＣＢのチェイン（リンクされたリストやダブルリンクされたリスト等）を持つことも可能で、特定のＬＣＢを設定する必要がある場合にはいつでもポインタやリファレンスチェーンの順次的な調査ができる。
【００８５】
図１３は、ＤＢＣＢに関するデータ構造群とＴＣＢ群の両者を含む階層を示す。本発明によれば、トランザクション群とデータベース群とを、同一の種類の「物」としてみることができる。これが可能な理由は、データベースをパッシブトランザクションとみることができるからである。よって、データベースがパッシブトランザクションとみなされ、トランザクションとして上に記載したもの（Ｔ１等）がアクティブトランザクションと表示（ｌａｂｅｌ）されることから、単一の階層データ構造におけるＤＢＣＢとＴＣＢへの統一化されたアプローチが可能となる。
【００８６】
図１３にはＡＴＣＢ群とＰＴＣＢ群を示すが、これらをそれぞれアクティブＴＣＢ及びパッシブＴＣＢと称する。アクティブＴＣＢ（即ちＡＴＣＢ）は前述のＴＣＢに対応し、パッシブＴＣＢ（即ちＰＴＣＢ）はＤＢＣＢの別称である。図１３では、データベース／トランザクション階層とも称される階層のルーツは、グローバルデータベースＰＴＣＢ ４２０である。このノードは、上記のグローバルデータベースデータ構造１９２に対応する。この階層において、いずれのノードも如何なるタイプの子ノードを有してもよいようにできる（とはいっても、ＰＴＣＢがその直接的親ノードとして他のＰＴＣＢを有することは通常ないし、そのようなことは行なわれていないであろうが）。上で述べたことを別の言い方でいうと次のようにいえる。階層の出発点はグローバルデータベースで、これは階層のルーツであり、そこから、トランザクションやサブデータベースが作成され寿命を全うする、考えうる殆どあらゆる方法でデータベース／トランザクション階層が動的に展開される（成長（ｇｒｏｗ）と退縮（ｓｈｒｉｎｋ））。このことは、グローバルデータベースに対するＰＴＣＢは、他のノード全てが過渡的（ｔｒａｎｓｉｅｎｔ）でありながらトランザクション・マネジメントとロック・マネジメントが行なわれる対象に対してシステムが存在する限り、存在するであろうということを意味する。この場合、グローバルデータベースに対するＰＴＣＢは、恒常的に存在するように作成することができる。図１３の統合された（ｕｎｉｆｉｅｄ）構造は、上に述べたいずれの実施態様についても用いることができる。これが意味することは、システムは、全てのＬＣＢへのアクセスを提供するグローバルサーチテーブルを有するように作るか、あるいは問題としているＰＴＣＢに属するＬＣＢ群へのアクセスを与えるＰＴＣＢ毎にサーチテーブルを有するように作ることができる、ということである。
【００８７】
図１３を参照すると、グローバルデータベースＰＴＣＢ ４２０が一番上の階層レベルに描かれている。このグローバルデータベースＰＴＣＢ ４２０の直下には４種のトランザクションＡＴＣＢ ４２２、ＡＴＣＢ ４２４、ＡＴＣＢ ４２６がある。これら３種のＡＴＣＢ はトップレベルのトランザクションであって、グローバルデータベースＰＴＣＢ をそれらの直接の親ノードとして有している。図１３の階層における全ての他のトランザクションやＡＴＣＢは、サブトランザクションと考えることができる。図１３に示したデータ構造の関係を実現可能である理由は、本発明者の知見、即ち、サブデータベースをパッシブトランザクションと見ることができ、またサブデータベースが常ににアクティブトランザクションよって創出されると、そのサブデータベースはサブトランザクションになる、という本発明者の知見による。図１３に示すデータ構造の階層と統合化（ｕｎｉｆｉｃａｔｉｏｎ）の利点は、図１０に示す構成に比べ単純化できる可能性が提供されていることである。この単純化がもたらされる理由は、ＴＣＢ群階層とＤＢＣＢ群階層という二つの異なる階層の間を行き来するポインタやリファレンスの代わりに単一の階層があるためであると考えることができる。これにより、データベース制御ブロックをしてその所有トランザクションとスーパーデータベースとの間の差別化をさせる代わりに、データ構造の作成を、それら２つのフィールドのただ一つのみが必要とされるようにして行なうことができる；その場合、スーパーノードのみを含むシステムとすることができる。例えば、図１０を見ると、各トランザクション制御ブロックはコンテキストデータベースを指すポインタやレファンレスを有しており、従前の実施方法におけるデータ構造は、（必要ではないにせよ）スーパートランザクションを指す他のポインタやレファンレスを有するのが好ましい。これに対し、図１３の実施形態では、これらスーパートランザクション及びコンテキストデータベースリファレンスやポインタは、単一のリファレンスと結び付けられる。前出の実施形態と同様、本実施形態でもハッシュテーブル、ＬＣＢ、ＳＬＣＢ、ＬＲＢ等のサーチテーブルが用いられる。
【００８８】
ロックリクエストを実施するときは、前出の実施形態と同様の処理ステップを行なう。処理にあたっては、ＴＣＢからＬＣＢへ、あるいはＬＣＢからＴＣＢへと進むことが望まれるかもしれない。正に前の例と同様に、回答は、ＰＴＣＢ（これはＤＢＣＢに対応する）を参照するＴＣＢやＡＴＣＢによって判断されることができる。別の方法として、ＰＴＣＢが見出される所まで上方に階層を上がって行くこともできる。いずれの場合においても、トランザクション制御ブロックから、そのトランザクションのデータベース制御ブロックへと迅速に進むことができる。この時点で、２つのオプションのいずれかに従うことができる。即ち、ハッシュテーブルを有するＲＩＤを用いて問題のリファレンスを見つけ次いで問題のデータベースに対するＬＣＢを見つけるか、あるいは、ＤＢＣＢに行ってからハッシュテーブル又はデータベース制御ブロックに行く（これらは所望する一つのＲＩＤに対するＬＣＢをサーチするのに用いられる）。ＰＴＣＢの構造は、前に記載したＤＢＣＢと同様である。
【００８９】
しかしながら、ＰＴＣＢは、所有トランザクションとＤＢＣＢのスーパーデータベースフィールドを結合させることによって作成することが好ましく、この結合されたフィールドを、簡単に「上位」（ｓｕｐｅｒｉｏｒ）と称することができよう。
【００９０】
上記ＴＣＢに対応するＡＴＣＢの作成に関しては、図８のコンテキストデータベースフィールド２２６を、図８のＴＣＢのスーパートランザクションあるいは親トランザクションフィールドと結合させることができる。このようにして（必要に応じ付加的な変更がなされるにせよ）、ＡＴＣＢをＴＣＢと非常に類似した方法で作成することができる。
【００９１】
前出の各実施形態では、ロックリクエストブロック（ＬＲＢ）を参照するＬＣＢあるいはＳＬＣＢを用いることが好ましい。この実施形態の別の方法として又はこれに加え、ＬＲＢを、ＬＣＢ又はＳＬＣＢ自身の中の許可待ちリクエストビットマップや許可されたリクエストビットマップで置き換えることもできる。図１４を参照すると、ＬＣＢやＳＬＣＢの別の実施形態がデータ構造４６０として示されている。このデータ構造はＬＲＢに保存されている情報をＬＣＢへと統合するので、ＬＣＢ（及びＳＬＣＢ）はクラッシク形式のＬＣＢ（及びＳＬＣＢ）より多くの情報を含む、より「リッチ」な制御ブロックである。図１４のデータ構造は米国特許第５，９８３，２２５号の図３のデータ構造に基づいていると共にこれに類似しているものであって、この特許公報を本明細書の一部を構成するものとしてここに援用する。
【００９２】
データ構造４６０はロックＩＤフィールド４６２を含むが、このフィールドは通常、今問題としているロックされた資源やその他の資源に対する資源識別子のコピーを有する。モードフィールド（ｍｏｄｅ ｆｉｅｌｄ）４６４は、このＬＣＢで表されるデータベース資源に関して許可された全ロックの最も制限的なアクセスモードを示す。許可されたリクエストビットマップフィールド４６６及び許可待ちリクエストビットマップフィールド４６８はそれぞれ、システム（あるいはサブデータベースレベル）によってサポートされた同時的トランザクションの最大数を示すよう、十分なサイズの（例えば、６４ビットあるいは１２８ビットの）ビットマップを含む。各トランザクションにはビットマップトランザクション識別子が一つ割り当てられる。許可されたリクエストビットマップ４６６は、ＬＣＢ（又はＳＬＣＢ）４６０で表されるロック資源を許可された各アクティブトランザクションに対するセットビットを含む。同様に、許可待ちリクエストビットマップ４６８は、ＬＣＢ４６０で表される資源に許可待ちのロックリクエスト（アクセスリクエストとも称する）を有する各アクティブトランザクションに対するセットビットを含む。データベースフィールド４７０は、ＬＣＢ４６０に対応する資源に対するデータベースを表すＤＢＣＢへのリファレンスを含む。本実施形態によれば、他の実施形態と同様、所定のレコードあるいはオブジェクトの唯一個の物理的コピーが存在するが、そのレコードは二以上のデータベースにおいてアクセスされることができ、仮にある一時点で二以上のデータベース中でアクセスされることができない場合には、時間をずらせばアクセス可能であるようにシステムを作成することができる。よって、トランザクションが現在問題としている資源にアクセスしている時、その資源をどのデータベース中にアクセスしようとしているのかを示すこと、またその場合その目下問題となっている資源が所属する各データベースに対し、単一のＬＣＢ（又はＳＬＣＢ）が存在すること、が好ましく、そして好ましくは、そのＬＣＢ（又はＳＬＣＢ）は目下問題としているデータベースがそれに対応していることを明示的にはっきりこれと示すことができるべきである。これが、データベースフィールド４７０の目的である。
【００９３】
ネクスト・レベルＬＣＢ４７２については、このフィールドはネクスト・レベルＬＣＢを参照するが、参照の仕方は図４及び図６に示すより高い階層レベルのＳＬＣＢの参照の場合と同様である。フィールド４７４は、追加のフィールドがＬＣＢ／ＳＬＣＢ４６０中に含まれてもよいことを示す。例えば、読出し／書込みパラメータビットマップ（その例としては、米国特許第５，９８３，２２５号の図２に要素１７２及び１７３として示されている要素が挙げられる）を用い、ＬＣＢ４６０で示すデータベース資源について許可された読出し／書込みパラメータ化アクセスモードを表すことができる。加えて、他のフィールド群もＬＣＢ４６０のエリア４７４に含まれていても良い。ネクストＬＣＢフィールド４７６を用いてネクストＬＣＢを表しても良く、このフィールド４７６は図２のフィールド１７６に対応するであろう。更に、データベースフィールド４７７及びネクスト・レベルＬＣＢフィールド１７８が図２に関して作成されると同様、データベースフィールド４７０及びネクスト・レベルＬＣＢ４７２も作成されることができる。ＬＣＢ（あるいはＳＬＣＢ）４６０の別の実施形態をもって、ＬＣＢ又はＳＬＣＢが用いられている先の図面のいずれかに置き換えることができ、このようにすることによって、それら実施例で用いることが好ましいＬＲＢを使用しないで済ませることができる。
【００９４】
本発明は様々なトランザクションに関し、ここでトランザクションとは作業の論理的単位（ａ ｌｏｇｉｃａｌ ｕｎｉｔ ｏｆ ｗｏｒｋ）と考えることができる。このようなトランザクションは、人が端末の前に座って作業をする環境に基づくものであるか、既存のコンピュータプログラム及びそのプログラムの命令を実行するためのリクエストを走らせたり提示したり（ｓｕｂｍｉｓｓｉｏｎ）することに基づく何かであることができる。サブトランザクションは、トランザクションと共に、あるいはトランザクションの下で、あるいはトランザクションと関連してなされる作業という概念に関する。
【００９５】
トランザクションをサブユニットに分割することは、サブトランザクションを作り出すことと考えることができる。所望により（例示的実施形態に過ぎないが）、トランザクションは、他のトランザクションとは独立したものと考えることができ、また作業の自律的単位であることができる。
【００９６】
これに対し、サブトランザクションは、非自律的あるいは非独立的トランザクションと考えることができる。よって、サブトランザクションはより高いレベルのトランザクションの一部と考えることができる。
【００９７】
データベースはデータの集まり（ｃｏｌｌｅｃｔｉｏｎ）と考えることができる。サブデータベースもまたデータの集まり（ｃｏｌｌｅｃｔｉｏｎ）であるが、サブデータベースは一般に動的に創出（ｄｙｎａｍｉｃａｌｌｙ ｃｒｅａｔｅｄ）され、暫定的なエンティティ（ｔｒａｎｓｉｅｎｔ ｅｎｔｉｔｙ）と考えられる。好ましい実施形態においては、サブデータベースは、創出トランザクションが生きている間だけ生き続け、サブデータベースを創出したエンティティが存在しなくなったらサブデータベースも存在しなくなるように作成しても良い。サブデータベースは、制御の領域（ａ ｓｐｈｅｒｅ ｏｆ ｃｏｎｔｒｏｌ）である、あるいはこれと関係する、と考えることができる。この制御の領域とは、データのサブセットの周囲にフェンスやラインを置き、そのフェンスの内側がサブデータベースとみなされる領域である。サブデータベースはまた、バーチャルデータベースと考えることもできる。本明細書においては、「データベース」という語はサブデータベース又はバーチャルデータベースを指すものとして使用することがある。サブデータベースは、物質化される必要がないという意味ではバーチャルなものと考えることができる。本発明の実施態様においては、サブデータベース中に別の物理的コピーを持つ必要はない。よって、グローバルデータベースに属し且つ同時にグローバルデータベース制御ブロック１９２に対応する一以上のサブデータベースに属することができるデータのコピーを一個のみ有すれば良く、別の物理的コピーを持つ必要はない。
【００９８】
好ましくは、データは図１のデータベース等のグローバルデータベースに保存される。グローバルデータベース１９２は、好ましくはＤＢＭＳのロックマネージャを管理し動作させるプロセス中で用いられるデータベース制御ブロックとして具現化される。データベース中に実際に格納されているデータを得るためには、グローバルデータベース１９２及び他のＤＢＣＢ群、ＤＢ１、ＤＢ２、．．．、ＤＢｎは所望のデータを得るためのエントリーポイントとしては直接使用されず、データは好ましくはこれらのデータ構造に格納されない。
【００９９】
本発明の一実施形態においては、ＬＣＢ及びＳＬＣＢを経由してデータに到達する（あるいはデータへのアクセスを得るために用いられるロック情報を得る）ことが好ましい。
【０１００】
次を仮定するものとする：即ちレコードＩＤ（ＲＩＤ）が一個存在し、そのＲＩＤに対応する特定のレコードにアクセスしたいと所望され、且つそのレコードへのアクセスが所定のデータベース又はサブデータベース中にあるものと仮定する。基本的なアプローチでは、例えば図２〜１０に示したデータ構造では、ＲＩＤに対するエントリーを得るためにハッシュテーブルを用いるが、そのＲＩＤが見出された時には、そのＲＩＤは、空であるかもしれないＬＣＢ群のチェーンを指すか特定のＲＩＤに対応する一ＬＣＢを指す。その他のＲＩＤ群に所属するＬＣＢ群は無視することができる。若しサブデータベースが所望のものでないかあるいはグローバルデータベースレベルのものであるならば、ハッシュテーブルの利用によって見いだされたＬＣＢに対応するＬＲＢ群を調べ、コンフリクトしているロックが存在するかどうか、またそのロックリクエストは許可できるかどうかを判断する。もしコンフリクトしているロックが存在しロックリクエストが許可されるものなら、リクエストされたロックに対応するＬＲＢを、許可されたＬＲＢ群のチェーン中に導入し、データへのアクセス許可を認容する。このとき、該システム中の他のコンポーネント、例えばバッファマネージャ（よく知られており図示しない）に行くこともできる。また、実際のデータを得るためにレコードを取ってくるための目的とする物理的アドレスやディスクへのアクセスを許容するアイテムに行くこともできる。若しネスト化データベース群やサブデータベース群が存在すれば、データベース制御ブロックを用いてデータへのアクセスに対する許可を得る。データに直接アクセスするためデータベース制御ブロックを用いることは好ましくない。上に述べたように、データを得るためには、ハッシュテーブルを用いてそのハッシュテーブルからハングオフ（ｈａｎｇｓ ｏｆｆ）している対応ＬＣＢ群を見出す。問題としているＲＩＤに対するエントリーが得られ、図面上、右への動きがあり問題としているＲＩＤに対するＬＣＢを見出す。どのようにデータが得られるかを視覚化したものが図４である。図４では、第一レベルのＬＣＢ １６０−１と１６０−２が存在する。図４のハッシュテーブル１５２から、ＬＣＢ １６０−１と接続するリファレンス１５４−１が見出される。ＬＣＢ １６０−１はグローバルデータベースＤＢＣＢ １９２を参照する。データがデータベース ２ （ＤＢ２）に入力されている、あるいは問題とするトランザクションがデータベース ２のコンテキスト内で行われると仮定すると、正しい資源に対するＳＬＣＢを見出すことが必要である。第一レベルのＬＣＢ １６０−１から第二レベルのＬＣＢ １６４−１へと進むことが必要となる。ＳＬＣＢ １６４−１はＤＢ１を参照するが、これは所望のデータベースではない。
【０１０１】
よって、ＬＣＢ／ＳＬＣＢの階層を一レベルずつＬＣＢ群の第三レベルまで上って行くゆくと、ＳＬＣＢ １６４−２がＤＢ２を参照していることが分かるが、このＤＢ２が所望するものであるので、正しいＬＣＢのレベルに到達できたことになる。この段階でロックマネージャは、ＳＬＣＢ １６４−２においてこのデータベース及びこの資源に対しどんなロックが存在するかを調べる。もし新しいロックリクエストが既に存在するもの（それが何であれ）と適合性（ｃｏｍｐａｔｉｂｌｅ）があるなら、そのロックリクエストは許可される。一旦ロックリクエストが許可されれば、データに対するロックが得られるが、そのデータ自身にアクセスできなければならない。好ましい実施形態においては、ＤＢＣＢを用いずにデータへのアクセスを得る。好ましくは、同時実行制御のためにデータベース制御ブロックを用い、該制御ブロックがロックマネージャによって使用されることが好ましく、バッファマネージャや、データを取りに出ていくシステム中の何らかの他のメカニズムによって使用されないことが好ましい。好ましい実施形態においては、データベース制御ブロックは単なる制御ブロックであってデータを含まない；即ちデータベース制御ブロックは制御情報を含む。よって、一旦ロックが許可されると、システムは或るトランザクションが特定のＲＩＤを持つ資格を有する（ｅｎｔｉｔｌｅｄ ｔｏ）と表示（ｉｎｄｉｃａｔｉｏｎ）する。
【０１０２】
次いで、従来の技術およびデータベース構築法によって、例えば、「該データに対するロックが許可された」との表示を存在させることができる。また、ＲＩＤによって同定されるデータを得るために、バッファマネージャや他の構成要素を用いることもできる。
【０１０３】
バッファマネージャはデータを得るためにＤＢＣＢを必要としない、あるいは使用しないことが好ましい。データを得ることは物理的なアクセス経路の問題、及びディスクのどこに所望のデータが存在するかという問題である。
【０１０４】
好ましい実施形態においては、データは一部のみである。但し別の実施形態では二部以上であることができる。好ましくは、所望のレコードその他の如何なるオブジェクトもその数は一部である。該レコード等はディスク上に物理的アドレスを有しており、バッファマネージャはＲＩＤによって与えられた物理的アドレスを特定することができ、バッファマネージャにとっては、データがどのサブデータベースに属するのかはどうでもよい；なお、該物理的アドレスは如何なる場合でも不変であることが好ましい。
【０１０５】
以上、ＳＬＣＢやＬＣＢはＤＢＣＢに対するリファレンスやポインタを有するものとして説明してきた。しかしながら、別の実施形態では、ＬＣＢやＳＬＣＢの中に或るフィールドを有することによって、これらリファレンスやポインタを不要とすることができる。このフィールドは、ナンバーであるか、あるいはＳＬＣＢが特定のデータベース又はサブデータベースに属することを示す表示である。ＬＣＢやＳＬＣＢに対するリファレンスは別の態様も可能である。
【０１０６】
本発明のサブデータベースを実現するのに用いられるデータ構造は、「ロッキング」として知られている周知の同時実行制御技法に再帰（ｒｅｃｕｒｓｉｏｎ）を用いる。
【０１０７】
再帰法を行なうには、所定の原理を何度も繰り返し適用し、本発明においてはデータのグローバルな集まり（例えば、ワードプロセッシングやエンジニアリングやＣＡＤ／ＣＡＭ 設計のドキュメントや構造等）を収めているグローバルデータベースからスタートする。
【０１０８】
同時実行制御（ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ）は、或る一人あるいは一トランザクションの行為によって、他の者が作業中のデータが壊されたり不良になったりしないことを確実にするために、ロッキングによって行なわれる。本発明で用いる原理は、ミニデータベースとみなしうるサブデータベースやネスト化データベースを創出すること、次いでグローバルデータベースに対してなさたと同じ基本概念とロッキングをサブデータベースに対して実施することである。従って、本発明はグローバルデータベースにおける原理をサブデータベース群のバーチャルな集まりに適用するものである。よって、本発明は、再帰的同時実行制御の原理を共同作業（ｃｏｌｌａｂｏｒａｔｉｏｎ）の問題に適用し、これによってバーチャルデータベースやバーチャルな砂箱（ｓａｎｄｂｏｘ）環境の作出を可能とする。これらのバーチャルな環境やサブデータベースに対し、本発明は従来の同時実行制御の使用を許容し、共同作業することを所望している複数のユーザ間での時として複雑なパターンのやり取りを確立することを可能とする。
【０１０９】
若しデータの変更をキャンセルしたい希望や前の状態にデータを戻せるようにしたいという希望がある場合（これはアトミック性に関係する）、本発明はトランザクションの範囲において、各データ・アイテムになされたすべてのログを保持するように構成することができる。そのログのコンテンツによって、変更されたいかなるアイテムも前進的にも後退的にも両方向の回復が可能となる。これは回復可能性として知られており、その実施には周知の各種技法が存在する。しかしながら、書込みを行なう複数の人々の間での共同作業実現へのアプローチの多くは、トランザクションをより小さなトランザクション群に分割することによってトランザクションのアトミック性を犠牲にしている。そのようなアプローチのよく知られた例として、オープンネスト化トランザクションやいわゆるｓａｇａｓが挙げられる。これは上記の極く小さいアトミック・トランザクションの中での回復可能性を実現するものであるが、ユーザの見たいという希望により、トランザクションを構成する極く大きい作業論理単位（ｌｏｇｉｃａｌ ｕｎｉｔ ｏｆ ｗｏｒｋ）については回復可能性は失われる。このため、トランザクションの補償という概念の導入が必要となる。これはアプリケーション開発者によって創出される必要のあるトランザクションである。言い換えるとこれは本質的には回復可能性へのドゥ・イット・ユアセルフともいうべきアプローチである。
【０１１０】
これはネスト化データベースの場合とは対照的である。即ち、ネスト化データベースの場合、回復可能性は失われず、補償トランザクションの使用も不要である。更に、ネスト化データベースの存在下において、回復可能性を実現するための周知の技法を引き続き用いることができる；即ち回復可能性の実現の目的で何らの新たなアルゴリズム、データ構造、技法も開発する必要はない。データベースのネスト化におけるあらゆるレベルで回復可能性が保持できることは、標準技法によるサポートと組み合わせることにより、共同作業（ｃｏｌｌａｂｏｒａｔｉｖｅ ｗｏｒｋ）の問題への他の各種アプローチと比べて優れた本発明の利点である。
【０１１１】
本発明の好ましい実施形態においては、サブデータベースを創出したり稼動しはじめるために、問題としているオブジェクトやサブデータベースに関する書込みロックを有することが好ましい。トランザクションは制御領域を確立するが、誰でも動的に（ｄｙｎａｍｉｃａｌｌｙ）或るオブジェクトを該制御領域に持ってきて、その制御領域の性質に基づいてそれらのオブジェクトを操作（ｍａｎｉｐｕｌａｔｉｏｎ）することができる。書込み制御領域があれば、制御の全領域あるいはその一部を変更することができる。書込みロックによってデータの書込み、削除、挿入、変更が許容され、好ましい実施形態によれば、書込みロックはサブデータベースの創出に対する一要件である。サブデータベースは、書込みロックでなくデータベースロックを作出すると考えることができる。データベースロックを持っていても書込みロックでできることの全てはできないかもしれないし、またデータベースロックは現実にはその構成要素に対し、書込みロックに幾つかの権利を放棄させるようにしてしまうかもしれない。幾つかの権利が放棄されてしまうかもしれないが、それら権利を放棄してサブデータベースを作出することの利点は、そのサブデータベースの所有者が他者や他のグループと該サブデータベースのオブジェクトを共有することに異存がないことにより同時実行制御の別の枠組み（ｒｅｇｉｍｅ）が作出されることである。
【０１１２】
特定のトランザクションに関するロックマネージャは、そのトランザクションをして或るデータベースの範囲内で一生を終わるようにさせる。従って、本発明は、様々な範囲のトランザクションや様々なサブデータベースを有するトランザクションを認識する再帰的アルゴリズムを用いる態様として実施できる。本発明は、システムをより強力にしまた付加的特徴を実現するために米国特許第５，９８３，２２５の技法と共に実施することができとはいえ、本発明は、米国特許第５，９８３，２２５号公報に記載のパラメータ化ロックマネジメントシステムとは異なる。本発明におけるネストされたデータベースあるいはデータベースをネスト化すること、およびサブデータベースを利用することの目的は、データに書込む者が複数ある場合それら複数の者の間を調整することにある。
【０１１３】
図１５に戻ると、これは新しい空の（ｅｍｐｔｙ）サブデータベースを作出するためのフローチャートである。図１５で暗黙の了解事項とされていることは、トランザクションがデータベース又はグローバルデータベース内の何らかの他のサブデータベースの中で実行されていること、及びこのトランザクションの所有者あるいはこのトランザクションの管理者が新しいデータベースを作りだそうとしていることである。図１５において、スタートの後、ステップ４８２で新しいＤＢＣＢを作成する。創出されようとしているこの新しいサブデータベースの存在に関する制御点あるいは参照点とするために、データベース制御ブロックが作成される。上で述べたように、好ましい実施形態においては、このサブデータベースに対してデータのコピーを作成する必要はないが、必要に応じて、データのコピーを作成しても良い。ステップ４８４、４８６、４８８は作成されたＤＢＣＢを、存在するかもしれない他のデータ構造と関連付けるものである。ステップ４８４では、ＤＢＣＢの「Ｏｗｎ ＴＸ」フィールドをして、作成／所有トランザクションを参照させる。
【０１１４】
このステップは、作成トランザクションと新しいＤＢＣＢとの間の関係を明確にするために行なわれる。なお、各フローチャートに記載の全ステップが必須であるのはなく、実施態様によっては、所望であればあるいは名指されたデータ構造やフィールドが使用されていないならば、なくても良いステップもあろう。次に、ステップ４８６では、ＤＢＣＢのスーパーデータベースフィールドをして適切なＤＢＣＢのスーパーデータベースを参照させる。これを行なうことにより、「この新しいサブデータベースをその一部として有するデータベースは何か」をシステムに告げ、またＤＢＣＢデータ構造において明確にする。次いで、ステップ４８８では、ＤＢＣＢデータ構造の「Ｐｒｅｖ ＤＢフィールド」や「Ｎｅｘｔ ＤＢ」に書込み、それらが同胞データベース（もし存在すれば）を参照できるようにする。これらの同胞データベースは、同一の作成トランザクション（もしあれば）によって予め作成された他のサブデータベースであることができ、この予めの作成は、該他のサブデータベースとの関係が定義されあるいは作成されるようになされるものである。
【０１１５】
次に、図１５中、ステップ４９０では作成トランザクションのＴＣＢ中に適切な情報を書込むが、この書込みはこのＤＢＣＢが作成トランザクションのＴＣＢの「Ｓｕｂ ＤＢフィールド」によって参照されるようになされる。このステップによって、スーパーデータベースがこの新しいデータベースを、それ自身（即ちスーパーデータベース自身）が有するサブデータベース群の集合中に含むことが確実になる。最後に、ステップ４９２において、ＬＣＢのための新しいサーチテーブルが割り当てられ、該新しいサーチテーブルはこのＤＢＣＢから参照される。このステップ４９２は全ての実施形態において実施されなければならないものではないが、図１１のデータ構造及び／又は図１２のデータ構造では望まれるステップである。図１１及び／又は図１２の実施形態において、好ましくは、各ＤＢＣＢはそれ自身のハッシュテーブルや、アレイや、そのドメイン又はサブデータベースの中にあるＲＩＤを指定するためのエントリーポイントとして用いられるその他のサーチ構造を有することが好ましい。図１５のプロセスはそこで終了する。
【０１１６】
図１６は、サブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）ために前記ＲＩＤをサブデータベース中に持ち込むプロセスを示す。図１５で作成されたサブデータベースは最初作られた時には空であって、図１６は、オブジェクトやデータ・アイテムがどのようにしてサブデータベースに引き込まれ、目下問題としているサブデータベース中で実行されることになる将来のトランザクションにそのオブジェクトやデータ・アイテムが利用可能となるかを示す。図１６において、スタート後、ステップ５００は問題のオペレーションが有効かどうかを判断する。このステップが行なわれる理由は、好ましい実施形態においては操作者は如何なるオブジェクトもサブデータベースに移動できないが、一定の条件が存在するべきであるからである。例えば、サブデータベースを所有する、創出されたトランザクションは、この時点では、それ（トランザクション）がサブデータベースへと持ち込もうと希望しているオブジェクトを所有していることが好ましい。その他の質問や判定も実施することができる。例えば、オブジェクトがこのサブデータベースのスーパーデータベース中に存在する場合にのみオブジェクトをそのサブデータベースにき込む（該スーパーデータベースがグローバルデータベースや他のサブデータベースであろうとなかろうと）などである。よって、好ましい実施形態においは、オブジェクトをデータベース階層におけるその直上のデータベースからのみ引きだすことができる。若し、上記二条件が満たされないなどの理由でオペレーションが有効でないと判断されれば、図１６のプロセスはそこで終了する。
【０１１７】
もしステップ５００がそのオペレーションが有効であると判断すれば、ステップ５０２に進み、目下問題としているオブジェクトをサブデータベース中に取り込む。図１６の実施形態は図２〜４及び６に示したアレンジメント等のデータ構造アレンジメントに関する。ステップ５０２ではスーパーデータベースにおいてこのＲＩＤに対するＬＣＢを見つけ出す（ｌｏｃａｔｅ）。好ましくは、このステップは次のように行なわれる。即ち、まずハッシュテーブルに行き、ＲＩＤをハッシングし、ハッシュテーブルのエントリー又はリファレンスを獲得し、そしてポインタチェーンやリファレンスに従って前記ハッシュテーブルから第一のレベルのＬＣＢに進む。このＬＣＢはグローバルデータベース中のＲＩＤを特定するであろう。もし、問題としているオブジェクトを目下引き込もうとしているこのサブデータベースがグローバルデータベースの直下のものではなく、その上に（即ちグローバルデータベースとそれ自身の間に）他のサブデータベースを幾つか有しているならば、次のレベルのデータベースリファレンス群の中を移動したりあるいは一ＬＣＢから他のＬＣＢへと、このサブデータベースの直接上のスーパーデータベース中の資源を特定するＬＣＢに到達するまで次のレベルのＬＣＢに移動することが適切である。ステップ５００に関するこの判定によって、そのようなＬＣＢが存在するようになることが分かる。
【０１１８】
ステップ５０２の後、ステップ５０４に進み、このデータベースあるいはサブデータベース中の問題のＲＩＤに新しいＬＣＢを割り当てる。この新しいＬＣＢは、我々が作成した新しいサブデータベース（そこに資源が持ち込まれる）中の全く同じ資源を表す。ステップ５０６において、スーパーデータベース中のこのＲＩＤに対するＬＣＢは新しいＬＣＢを参照するようにされる。最後に、ステップ５０８で、この新しいＬＣＢにこのデータベースのためのＤＢＣＢを参照させる。即ち、この新しいＬＣＢがはっきりとデータベースとの関係を示すことを確実にすることが好ましい。これは「これは私のデータベースだ」とか「これは私のコンテキストデータベースだ」ということを示すことによってなされる。図１６のプロセスはそこで終了する。
【０１１９】
図１７は、データベースやサブデータベースの要素をいかにして構成する（ｐｏｐｕｌａｔｅ）かを示すフローチャートである。これは例えば、図１１や１２に示すデータ構造を有する別の態様においても用いることができる。このように要素を集めて構成する（ｐｏｐｕｌａｔｉｎｇ）目的は、資源のロック状態を決定するためにＬＣＢを作出することによりロッキング構造を実現する点にある。
【０１２０】
図１７ではスタートした後、ステップ５１０を行う。このステップは問題のオペレーションが有効かどうかを判定する。このステップは、図１６のステップ５００と同一のステップであるので、このステップの説明は省略する。次に、ステップ５１２において、このデータベース用のＤＢＣＢを見つけ出す。
【０１２１】
この時、グローバルデータベースや対象とする何らかのサブデータベース等のデータベースは既知である。なお、データベース制御ブロックによって或るオブジェクトを引き込もうという企図が存在するデータベースはどれかが示されることが好ましい。更に、所定のデータベース用のＤＢＣＢを見つけ出す方法があることが好ましく、それはデータベース制御ブロックへの参照があるようになされることが好ましい。次に、ステップ５１４において、このデータベース内で、新しいＬＣＢ（又はＳＬＣＢ）が問題のＲＩＤに対して割り当てられる。このステップでは、データベース中に新しいオブジェクトが持ち込まれる際に新しいＬＣＢが作出される。即ち、もし一オブジェクトが複数のデータベースに存在すれば、そのオブジェクトを有するデータベース群が存在することにより、そのオブジェクトは自身を表す同数のＬＣＢを有す。最後に、ステップ５１６において、ＬＣＢがデータベースのサーチテーブルに挿入される。これはレコードＩＤについてハッシングし、ハッシュテーブルが使用されていると仮定するとハッシュテーブルエントリーを得ることによって達成される（但しアレイやテーブル等上述の別法を用い、新しいＬＣＢを、如何なるハッシュテーブルエントリーであれ、ハッシュ関数が指示する挿入箇所に挿入してもよい）。この時もしＬＣＢのチェーンが空であれば（即ち、ＬＣＢなし）、ＬＣＢをチェーン中最初のアイテムとして挿入する。また、チェーンが空でなければ、ＬＣＢを第一のアイテムとして挿入するか、あるいは、チェーンにおける最後又は中間のアイテムとして挿入する（エントリーが挿入され、問題としている特定のハッシュテーブルやアレイ・エントリーから到達されうる限りにおいて）。
【０１２２】
図１８は、図２〜４及び６に示した本発明実施形態のデータ構造を用いてロックリクエストの処理を行なうための例示的ステップを示すフローチャートである。図１８において、スタート後、ステップ５２０を行なって、問題としているＲＩＤ用のハッシュテーブル・スロットを見つけ出す。ロックリクエストによって、あるデータへのアクセスの許可を求めているトランザクションを特定し、このＲＩＤがその中に見出されようとしているデータベースを特定すると共に問題のデータのＩＤやＲＩＤを特定する。更に、アクセスモードの表示が存在し、これはたとえばデータの読出しや書込みが所望されているか等である。この情報はロックリクエストの処理の際、ロックマネージャによって利用される。よって、ＲＩＤ用のためのハッシュテーブル・スロットを見つけ出すために、ＲＩＤのハッシングがあって、ハッシュテーブル・エントリーが見出され、そしてハッシュテーブル・エントリーにおけるリファレンスが調べられて、グローバルデータベース中でこのＲＩＤに対するＬＣＢが存在するかどうかを判断する。もしステップ５２２でＲＩＤのためのＬＣＢがグローバルデータベース中に存在しないと判断されれば、ステップ５３０に進み、そこでＬＣＢを作出してそれを第一レベルのＬＣＢチェーンに挿入する。ステップ５２２でＲＩＤのためのＬＣＢがグローバルデータベース中に存在しないと判断されれば、ロックリクエストは、ＬＣＢがまだ存在していないためＬＣＢが作出されるという比較的単純な状況において、グローバルデータベース中の前記ＲＩＤのためのものと結論付けられ、ＬＣＢがまだ存在していないからには、そのデータ・アイテムについてのロックを有するトランザクションは他にないと容易に判断されるため、リクエストされているロックは無条件に許可されるであろう。このようにしてグローバルデータベースに関係する第一レベルのＬＣＢチェーンへのＬＣＢの挿入がなされる。ステップ５３０の後、ステップ５３２で前記リクエストを許可し、許可されたリクエストに対応するＬＲＢを創出する。
【０１２３】
あるいは、もしステップ５２２で、ＲＩＤのためのＬＣＢがグローバルデータベース中に存在すると判断されれば、ステップ５２４に進み、正しいデータベースあるいはサブデータベースが見出されるまで「Ｎｅｘｔ Ｌｅｖｅｌ ＬＣＢ」に従う。ステップ５２４を行なう回数はゼロ回であってもよい。よってグローバルデータベース中の資源に対するリクエストがもしあっても、目下見られているＬＣＢが所望の、あるいは正しいＬＣＢであるかどうかを即座に見出すことができ、よって、このＬＣＢでストップして先に進まないことができる。次に、ステップ５２６では、競合しているロックが存在するかどうかを判断する。これはそのデータ・アイテムに対してすでに許可されているかもしれない既存のロックのいずれとも前記リクエストが適合する（ｃｏｍｐａｔｉｂｌｅ）かどうかを判断することによって容易に行なうことができる。もしステップ５２６で競合しているロックが存在すると判断されればステップ５２８に進み、リクエストは待ち状態（ｑｕｅｕｅｄ）とされるかあるいは拒絶される。システムには待ち時間を設定することができ、既存のロックをリリースしてロックマネージャが後でリクエストされたロックを許可してよい時がきたかどうかを再考することができるようにもできる。あるいは、ステップ５２８において、リクエストされたロックは単純に拒絶されるようにしても良い；これは単にこの問題をどのように取り扱うかに関する設計上の選択事項である。すぐリクエストを拒絶すればハンギングを防止でき、また所望のロックへのアクセスを得られるかもしれないとの希望をもって不特定時間の間待つという問題をなくすることができる。
【０１２４】
ステップ５２６で競合するロックが存在しないと判定された場合、ステップ５３２に進み、ここで適切に資源や関連するデータのロッキングを指摘するためにリクエストを許可しそのリクエストに関係するＬＲＢを創出する。
【０１２５】
図１８と同様に図１９も、ネスト化データベースの存在下で如何にロックリクエストは取り扱われるかを示すが、図１９は、各データベースあるいはサブデータベース制御ブロックがそれ自身のサーチテーブルを有している図１１及び図１２のデータ構造に関するものである。図１９では、スタート後、問題のデータベースのためのＬＣＢサーチテーブルが見いだされる。これは、ロックリクエストによって特定されるデータベースのＤＢＣＢからサーチテーブルリファレンスに従うことによって行なうことができる。次に、ステップ５３６において、ＲＩＤのためのハッシュテーブル・スロットが見出される（もし本態様に関してそのようなデータ構造が存在するならば）。別の方法として、ハッシュテーブルを持つことを避けたいのであれば、本実施態様はＬＣＢの表示や割り当てをより直接的に行なうようにしてもよい。次に、ステップ５３８で、ＲＩＤ用のＬＣＢが既に存在するかどうかを判断する。
【０１２６】
もしＬＣＢが存在しないなら、ステップ５３７に進み、リクエストがグローバルデータベース中の資源のためのものであるかどうかを判断する。その場合、ステップ５４４へ進む。しかしながら、もし前記リクエストが或るサブデータベース中の資源のためのものであってその資源のためのＬＣＢがそのサブデータベースのサーチテーブルに存在しないなら、トランザクションがリクエストしているものはそのコンテキストデータベースの範囲から外れる何らかのものであることになるので、特殊な状態であることになる。通常、そのようなリクエストは拒絶される（ステップ５３９の「ＮＯ」の枝で示される）。しかしながら、システムのプラグラミング次第ではその時にリクエストされた資源を動的に持ち込む可能性（即ち問題のサブデータベースを動的に成長される可能性）を、サブデータベースの成長が許容されるべきかどうかを決定するステップ５３９の質問によって開いておくことができるであろう。そのような判断は人間の介入によってでもよらなくても行なうことができるであろう。ステップ５３９における答えがイエスであるときは、ステップ５４４に進む。必要に応じて、図１８のフローチャートを修正し、図１９のステップ５２２と５３０の間にステップ５３７と５３９を挿入することができる。これによって、ステップ５３７及び５３９の機能性が図１８のプロセスにおいて達成される。
【０１２７】
ステップ５３８において、もしＲＩＤ用のＬＣＢが既に存在すると判断されるならば、ステップ５４０に進み、競合するロックが存在するかどうかを判定する。もし競合するが存在するなら、図１８のステップ５２８に関して説明したように、ロックリクエストが待ちの状態（ｑｕｅｕｅｄ）にされるかあるいは拒絶される。もし競合するロックが存在しないなら、ステップ５４６に進み、上述のようにロックのリクエストが許可されＬＲＢが作出される。図１９のプロセスはそこで終了する。
【０１２８】
図２０は、サブデータベースの終了時に実行されるステップを示すフローチャートである。スタート後、ステップ５５０ は、このデータベースのトランザクション又はサブデータベースが存在するか否かを判定する。ステップ５５０ の問い合わせの何れかに対する答えがＹＥＳの場合、流れはステップ５５２ に進み、このプロセスを継続するリクエストがあるか否かを問い合わせる。ステップ５５２ の判定ブロックは任意の要求される方法で行うことができ、ユーザがサブデータベースを終了することをまだ望んでいるか否かシステムのユーザに問い合わせた後におけるユーザの手動判定であってもよい。
【０１２９】
或いは、サブデータベースを終了することを受け入れられるか否かを示す自動判定であってもよい。このデータベースのトランザクション又はサブトランザクションが存在するためにサブデータベースを保存することが望まれる場合には、問題となっているデータは保存することが望まれているので、流れはステップ５５２ からエンドへ進行する。ステップ５５２ の継続的な判定は予めプログラムできる、即ちコンピュータプーグラム判定であり、手操作による判定であっもよい。ステップ５５２ において終了を継続する要求がある場合、ステップ５５４ が実行され、本データベースの全てのサブデータベースとトランザクションが終了される。この終了は、再帰（ｒｅｃｕｒｓｉｏｎ）の他の例である。何故なら、ステップ５５４ のアクションを実行することにより、テップ５５４ で終了されるアイテムのために図２０のフローチャートが再度実行されるからである。
【０１３０】
問題となっているデータベースについてのトランザクション又はサブデータベースが存在しないとステップ５５０ で判定された場合、又はステップ５５４ の実行の後にステップ５５６ が実行された場合、問題となっているデータベースについての全ての ＬＣＢの割当てが解除される。このステップ５５６ の割当て解除は安全に行うことができる。何故なら、ＬＲＢ 及びこれらのＬＣＢ に依存するトランザクション又はサブデータベースが存在しておらず、それらを除去、即ち割当て解除する（例えば、コンピュータのメモリからそれらを削除する）ことが可能であるためである。次に、ステップ５５８ が実行され、サーチテーブルが使用されている場合には、サーチテーブルの割当てを解除される。なお、場合によっては、割当て解除すべきサーチテーブルが存在しない場合があり、この場合、ステップ５５８ を実行する必要はない。最後に、ステップ５６０ が実行されて、問題となっているデータベースのための ＤＢＣＢ の割当てが解除され、ステップ５６０ が一旦実行されると、通常は、このサブデータベース専用に設けられたコンピュータメモリ内にデータ構造が存在しなくなり、サブデータベースが存続を停止する。図２０のプロセスはその後終了する。
【０１３１】
本発明の可能なアプリケーション、結果、及び特徴をより簡単に分かるようにするため、本発明ができることの例を図２１（ａ）〜図２１（ｄ）を参照して説明する。本例は、ドキュメントを共用する例であるが、本発明は多くのアプリケーションを有し、複数のユーザの間でデータを共有したいという希望がある如何なる状況においても使用できる。更に、本発明は、一つのドキュメントの一部をユーザの間で共有し、複数のユーザが単一のドキュメントに対して同時に作業するために用いることもできる。本例では、各ユーザのために単一のスクリーン、即ちコンピュータ・ディスプレイが提供され、ユーザが利用できるドキュメント又ははデータ・アイテムの各々が画面上に示される。しかしながら、これは例示に過ぎず、実際には、問題としているデータ・アイテムの各々を単一のコンピュータスクリーンに表示する要求も必要性もない。図２１（ａ）を参照すると、４つのドキュメント、即ち、ドキュメント１ ５７２ 、ドキュメント２ ５７４ 、ドキュメント３ ５７６ 、ドキュメント４ ５７８ を有するゲールのコンピュータスクリーン５７０ が示されている。この図２１（ａ）のスクリーン５７０ において、ゲールは書込みロックドキュメント１ 、２ 、３ 、４ を有し、ゲールはこれらのドキュメントの内容を読んだり書いたりできる。図２１（ａ）〜２１（ｄ）の例の実施を示すデータ構造に関して以下に説明するように、ゲールはグローバルデータベース内にトップレベルのトランザクションを有している。
【０１３２】
図２１（ｂ）では、ゲールはサブデータベースを作成し、論理的に言えば、ドキュメント２ 、３ 、４ をこのサブデータベースに引き入れた。これにより、これらのドキュメントは、各ドキュメントの右上の角において”Ｒ／Ｏ” で指定されているように、読出専用になる。
【０１３３】
図２１（ｃ）に、ゲールのためのスクリーンショット５７０ が示されており、又、ブライアンは自分のスクリーン５８０ に示されているように、ドキュメント２ ５８２ 及びドキュメント４ ５８４ に対して作業できるようになっていることを示している。
【０１３４】
図２１（ｃ）において、ブライアンはゲールのサブデータベース内でトランザクションを開始し、書込みロックドキュメント２ 及び４ を有している。これにより、ブライアンは、これらのドキュメントに対してフルエディットを行うことができるようになり、一方、ゲールは、暫くの間、ブライアンの管理下にあるドキュメント２ 及び４ に対して書込みを行うことができない。しかし、必要であれば、ゲールがそれらを読み出し、ブライアンが行っている作業を観察することができる。
【０１３５】
図２１（ｄ）に、ゲールのスクリーン５７０ とブライアンのスクリーン５８０ を見ることができるが、更に、アンヌがスクリーン５９０ を有しており、このスクリーン５９０ には、読出専用ドキュメントであるドキュメント２ ５９２ とドキュメント３ ５９４ が示されている。図２１（ｄ）のシナリオでは、アンヌがゲールのサブデータベース内でトランザクションを開始した。彼女はドキュメント２ について読出しロックを、ドキュメント３ について書込みロックを有しており、アンヌはドキュメント３ だけを変更できる。
【０１３６】
なお、図２１（ｄ）において、ブライアンはドキュメント２ ５８２ について書込みロックを有し、一方、アンヌはドキュメント２ について読出しロックを有している。従来のシステムでは、通常、ブライアンの書込みロックとアンヌの読出しロックは矛盾する。アンヌがブライアンの作業を見られるようにするために、パラメータ化ロック又はその他の機構を用いることができる。したがって、本発明の中核、即ちネスト化データベースをパラメータ化ロックと組み合わせて、システムの能力を更に高めることができる。
【０１３７】
図２１（ａ）及び２１（ｄ）の例が存在するシナリオを実施するために、例示的データ構造を図２２（ａ）〜２２（ｄ）及び２３（ａ）〜２３（ｄ）にそれぞれ示す。これらの図面は、サブデータベース及びデータの共有がどのように起きるかを示している。図２２（ａ）〜２２（ｄ）は、図２１（ａ）〜２１（ｄ）の例を実施するために用いられるデータ構造の最初の例を示す。図２２（ａ）では、ゲールはトランザクション制御ブロック（ＴＣＢ）６００を有している。又、ドキュメント１−４ のそれぞれのためにロック制御ブロック（ＬＣＢ） が設けられ、これらは１６０−１ 〜１６０−４ の番号が付けられている。ドキュメントのロッキングを実施するために、各ＬＣＢ に関連してロックリクエストブロック（ＬＲＢ）１６２−１〜１６２−４ が使用される。図２２（ａ）の各ＬＣＢ １６０ はグローバルデータベース１９２ （実際にはグローバルデータベース制御ブロック）を参照し、これにより、ゲールは、グローバルデータベース内でトップレベルのトランザクションを有していることを表す。ゲールのトップレベルのトランザクションであるＴＣＢ ６００ については、ドキュメント１−４ の各々についてフルエディットの能力がある。
【０１３８】
これらのドキュメントのためのＬＣＢ 及びデータ自体は、グローバルデータベースの一部であるか関連しているものと考えなければならない。
【０１３９】
図２１（ｂ）に対応する図２２（ｂ）においては、ゲールはサブデータベースを作成し、論理的に言えば、ドキュメント２ 、３ 、４ をサブデータベースに移動させる。サブデータベースは、ゲールが他の人を招き入れて共同作業するために作られる。ゲールはサブデータベースを作成しているので、追加のデータ構造が図２２（ｂ）に示されている。特に、ドキュメント２ 、３ 、４ はサブデータベースの一部であるので、第二レベルのＬＣＢ （ＳＬＣＢとも呼ばれる） がドキュメント２ 、３ 、４ のために作られ、符号 １６４−２、１６４−４ 、１６４−１ によってそれぞれ表されている。これらの ＳＬＣＢ がゲールのサブデータベース制御ブロック（ＤＢＣＢ）６０２ を参照しているのが分かる。ゲールはドキュメント１ を彼女のサブデータベースに移していないため、ドキュメント１ のための第二レベルのＬＣＢ 又はＳＬＣＢは存在しない。従って、この時点では、ドキュメント１ だけが、ゲールが編集できるドキュメントであり、他のドキュメントは閲覧だけが可能である。他のドキュメントが異なるサブデータベースに移動されたために、ゲールはドキュメント１ だけを編集できることをデータ構造が表すようにするため、ゲールのサブデータベースへ移動されたドキュメントのためのＬＲＢ のモードフィールドが、ロックについてのドキュメントに関連する能力を示すために変更される。図２２（ｂ）では、ゲールのサブデータベース内にアクティブなトランザクションは存在していない。更に、図２２（ｂ）では、ゲールのＴＣＢ のためのコンテキストデータベースはグローバルデータベース １９２に残っており、ゲールのサブデータベースはゲールのトランザクションによって所有されていることを示すためにゲールのサブデータベース ＤＢＣＢ ６０２ はゲールのＴＣＢ ６００ を参照する。
【０１４０】
図２２（ｃ）を参照すると、ブライアンは、ゲールのサブデータベース内でトランザクションを開始し、ブライアンのトランザクションは、図２２（ｃ）の右上部のブライアンのＴＣＢ ６０４ によって表されている。この特定の例では、ブライアンのトランザクションはドキュメント２ 、３ 、４ のみをアクセスできる。何故なら、ゲールのサブデータベースのドキュメント内、これらに対してのみブライアンのトランザクションがアクセス許可を有しているからである。しかしながら、本発明の或る実施形態では、別のユーザ、例えばブライアンがサブデータベース内でトランザクションを開始した後であっても、ゲールが、更なるドキュメントを追加することにより、彼女のデータベースを動的に成長させることが可能である。図２２（ｃ）では、ブライアンは、書込みロックをドキュメント２ 及び４ に設定しており、これらのドキュメントについてのフルエディットの能力を有している。従って、ゲールは、ブライアンがドキュメントに対して何を行っているのかを見ることはできるが、彼女は、彼の行った変更に対して直接変更を加えることはできない。
【０１４１】
ドキュメント２ 及び４ に対して書込みロックを持つことができるブライアンの能力は、ドキュメント２ のためのＬＲＢ １６２−６ を参照しているドキュメント４ のためのＬＲＢ １６２−５ へのブライアンのＴＣＢ ６０４ からの破線の矢印、即ちリファレンスによって表されている。又、図２２（ｃ）から分かることは、ブライアンのＴＣＢ ６０４ がゲールのサブデータベース（又はＤＢＣＢ）６０２ を参照していることであり、これはブライアンのＴＣＢ のためのコンテキストデータベースがゲールのサブデータベースであることを示している。
【０１４２】
図２１（ｄ）に示した配置とアクセス能力に対応する図２２（ｄ）を参照すると、アンヌはゲールのサブデータベース内で既にトランザクションを開始している。ブライアンのトランザクションと同様、ゲールがより多くのドキュメントを加えることによって彼女のサブデータベースを動的に成長させることを選択していない限り、アンヌのトランザクションは、ドキュメント２ 、３ 、４ のみをアクセスできる。この時点では、アンヌはドキュメント３ に対して書込みロックを有し、ドキュメント２ に対して読出しロックを有している。この情報は ＬＲＢ １６２−７及びＬＲＢ １６２−８ によって表される。ドキュメント２ のためのＳＬＣＢであるＬＲＢ １６２−７ は読出しロックを示し、ドキュメント３ のためのＬＲＢ １６２−８ は書込みロックを示すようにそのモードが設定される。この時点では、アンヌはドキュメント３ のみを編集できるが、彼女はブライアンがドキュメント２ に対して行っている変更を全て見ることができる。必要であれば、アンヌはドキュメント４ も見ることができ、同様に、必要であれば、ブライアンはドキュメント３ を見ることができる。ＬＲＢ １６２−７ 及び１６２−８ の参照に加え、アンヌのＴＣＢ ６０６ は、コンテキストデータベースリファレンスにより、ゲールのサブデータベース６０２ も参照する。
【０１４３】
図２３（ａ）〜２３（ｄ）は、図１１に示したデータ構造を使用して図２１（ａ）〜２１（ｄ）の例を実行するようにした代替の実施形態を示す。図２１（ａ）に対応する図２３（ａ）では、問題となっている４つのドキュメントのためのＬＣＢ １６０−１ 〜１６０−４ があり、各 ＬＣＢは対応するＬＲＢ １６２ を参照している。ゲールのＴＣＢ ６５０ は ＬＲＢ １６２を参照しており、又、ゲールのＴＣＢ ６５０ は、そのコンテキストデータベースがグローバルデータベース１９２ であることを示している。
【０１４４】
図２１（ｂ）に対応する図２３（ｂ）では、ゲールはサブデータベースを作成し、これにより、ゲールのサブデータベースのためのデータベース制御ブロック６５２ が作成される。ゲールのサブデータベース ＤＢＣＢ ６５２ はゲールのＴＣＢ ６５０ を参照して、ゲールのサブデータベースがゲールのトランザクションによって所有されていることを示し、又、ゲールのサブデータベース６５２ はハッシュテーブル、アレー又はその他の構造 ６５４を参照する。この構造６５４ は、ゲールのサブデータベースの一部である、３つのドキュメントのためのＳＬＣＢ １６４−１、１６４−２ 、１６４−３ を有している。ＳＬＣＢ １６４は、テーブル６５４ のリファレンス６５６ 、６５８ 、６６０ によって参照される。
【０１４５】
図２１（ｃ）に対応する図２３（ｃ）では、ブライアンのトランザクションが存在するようになり、これがブライアンのＴＣＢ ６７０ として表されている。ブライアンのＴＣＢ ６７０ はゲールのサブデータベース制御ブロック６５２ を参照し、ブライアンのＴＣＢ ６７０ 即ちトランザクションのコンテキストデータベースはゲールのサブデータベース６５２ であることを示す。ブライアンは、ドキュメント２ 及び４ についてのロックを得るが、これらはＬＲＢ １６０−５及び１６０−６によって表されている。
【０１４６】
図２１（ｄ）の配置に対応する図２３（ｄ）では、アンヌのトランザクションが存在するようになり、ゲールのサブデータベースをそのコンテキストデータベースとして有している。これは、アンヌのＴＣＢ ６８０ のコンテキスト ＤＢ リファレンスのゲールのＤＢＣＢ ６５２への参照によって示されている。
【０１４７】
更に、アンヌはドキュメント２ 及び３ に対して所定の権利を有しており、これは、ドキュメント２ 及び３ のためのＬＲＢ １６０−７ 及び１６０−８ を参照するアンヌのＴＣＢ ６８０ によってデータ構造内で表される。ＬＲＢ １６０−７ 及び１６０−８ は、アンヌが有しているアクセス能力が読出し専用であるのか書込みもできるのかを示すためにそれらのフィールドをセットする。
【０１４８】
図２１（ａ）〜２３（ｄ）に関して記載した上記の例は、異なるドキュメントのロックと共有に関するものであった。しかし、本発明は、ファイル又はドキュメントレベルでの共有に限定されるものでなく、複数のユーザ等の間で単一のファイル、ドキュメント、設計図等を共有するために利用できるものである。単一のファイルやドキュメントや他のデータ・アイテムを、本明細書で開示したネスト化データベースのフレームワーク内で共有するようにした実施形態を達成することは、ロッキングの細分性（ｌｏｃｋｉｎｇ ｇｒａｎｕｌａｒｉｔｙ）に関連している。即ち、ロッキングデータ構造又はＬＣＢ がどの資源を表しているかに関係する。従って、本発明は、例えば、パラブラフレベル、センテンスレベル等、ファイル又はドキュメントのより小さい部分のロッキングを可能にし、更に、個々の単語、文字、又はビット毎にロッキングを行うことを可能にする。
【０１４９】
更に、ドキュメントプロセシング又はワードプロセシング環境以外では、設計図の異なる部分を ＣＡＤ／ＣＡＭ システム又は他のシテスム上で共有できる。
【０１５０】
図２４（ａ）〜２４（ｄ）により提示する例（及び、必要であれば前出の例）では、ブライアンのトランザクションとアンヌのトランザクションは実際にはゲールのトランザクションのサブトランザクションである。従って、ゲール、ブライアン、及びアンヌのトランザクションの各々は、ゲールのトップレベルのトランザクションと同一の細分性でロッキングを行うものととりあえず推定される。しかしながら、別の方法として、ゲールにセクションレベルでロックさせ、またこれと同時に、ドキュメント又はパラブラフレベルでロックする他のトップレベルのトランザクションを持つことも可能である。
【０１５１】
多細分性ロッキングの概念は知られているが、本発明では、多細分性ロッキングとネスト化データベースの概念の両方を一緒に用いてもよく、一般にこれらの概念は相互に直交している（例えば、互いに独立している）ものと考えられている。多細分性ロッキングに関しての更なる情報は、以下で参照されている Ａｎｆｉｎｄｓｅｎの論文から得ることができるであろう。
【０１５２】
図２４（ａ）〜２４（ｄ）の実施例に戻って、図２４（ａ）にゲールのテキストエディタの例示的なスクリーンイメージ７１０を示す。問題になっているテキストのドキュメントはセクション１、セクション２、セクション３、セクション４で示される４セクションを有する。図２４（ａ）において、ゲールは図示されたドキュメントの全てのセクションをロックしており、全ドキュメントの完全エディット能力を有する。各セクションにおいて、サンプルテキストが図示されているが、任意の所望のテキストを使用してもよい。
【０１５３】
図２４（ｂ）のスクリーンイメージ７２０もまたゲールのテキストエディタを示しているが、しかしこのイメージでは、ゲールはセクション２、３、４をサブデータベースに委託（ｄｅｌｅｇａｔｅｄ）してしまっており、セクション２、３、４を通じて斜線で示されているこれらのセクションは今はゲールのエディタ内でリードオンリーになっている。
【０１５４】
図２４（ｃ）のスクリーンイメージ７３０は、ブライアンのテキストエディタを示す。図２４（ｃ）に関しては、ブライアンはゲールのサブデータベース（そこで作業することがブライアンはゲールによってオーソライズされている）を介してゲールのドキュメントにアクセスした。ブライアンは、セクション２及び４上に書込みロックを問題なくリクエストし、その結果セクション２及び４はブライアンのエディタ内でエディット可能であるが、セクション１及び３はリードオンリーである。なお、ドキュメントのリードオンリーセクションを通じての斜線は、説明の目的だけのためであり、斜線がテキストにかけられているいる必要はない。しかしながら、好ましい一実施形態では、或るセクションはロックされており他のセクションはロックされていないことを示すことが望ましいかもしれない。これは、異なるタイプやロックのモードやアクセス能力に対してテキストの異なる色やテキストのバックグランドを利用することによって達成されるであろう。例えば、一つの色を各個人に割り当てることができ、各セクション又はドキュメントの他の部分は、データ上に書込みロックを有する個人又はグル−プ（ｅｎｔｉｔｙ）に従って色がつけられるであろう。或いは、単一の色がリードオンリーであるドキュメントのセクションを示すために利用されてもよい。
【０１５５】
最後に、図２４（ｄ）にアンヌのテキストエディタを示すスクリーンイメージ７４０を図示する。
【０１５６】
アンヌはゲールのサブデータベース（そこで作業することがアンヌはゲールによってオーソライズされている）を介してゲールのドキュメントにアクセスした。アンヌは、セクション３上に書込みロックを問題なくリクエストでき、その結果セクション３はアンヌのエディタ内でエディット可能であるが、セクション１、２、４はリードオンリーである。
【０１５７】
本発明は、明細書の教示に従ってプログラムされた一以上の従来の汎用ディジタルコンピュータを使用して差し支えなく実施され得ることは、コンピュータ技術の当業者であれば明白であろう。当業者にとっては明白であるように、適切なソフトウエアコーディングが、本開示の教示に基づいて、熟練プログラマーによって容易に用意できる。当業者にはすぐ明白となるように、本発明はまた、特定の集積回路のアプリケーションを用意すること又は従来のコンポーネント回路の適切なネットワークを接続することによって実施されてもよい。更に、本発明は、複数のコンピュータ、計算デバイス、他のタイプのデバイスを使用して実施されてもよい。これらのデバイスは、データ、命令、データのリクエスト、及びデータベースマネジメントシステムの運用に関係する他の任意の情報を伝達するために、如何なるタイプのネットワークを介して接続されてもよい。係るコンピュータネットワークは、必要に応じて、有線ネットワーク、電波、赤外線、又は超音波タイプネットワーク等の無線ネットワークを使用して実施されてもよい。汎用コンピュータの使用の代わりにあるいは追加として、本発明は、パーム・パイロット（Ｐａｌｍ Ｐｉｌｏｔ）、インターネットサーバ、特別目的コンピュータ、及び電話ブラウザを含む任意のタイプのインターネットブラウザ等のパーソナルディジタルアシスタントを含む任意のタイプのデバイスを使用して実施されることを含む。
【０１５８】
本発明は、本発明のプロセスを遂行するようにコンピュータをプログラムするために使用され得る命令を含む記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、磁気カードや光カードを含む任意のタイプのディスク、又はハードディスクドライブを含む電子命令を記憶するのに適している任意のタイプの媒体を含むことが出来るが、本発明の記憶媒体はこれに限られるものではない。また、本発明は、本明細書に記載されており、且つこのアプリケーションで論じられる何れかのメモリ又は保存媒体に記憶されてもよいデータ構造を含む。
【０１５９】
本発明は特定の好ましい実施形態を参照して記載されてきたが、当業者にとっては、本発明の範囲及び精神を逸脱することなしに、種々の変更が可能で同等物が要素の代用になれるということは明白である。例えば、本発明は、一メモリに記憶されたデータ構造を記載しているが、それはそのデータ構造を複数のメモリに記憶するのと同等であろう。更に、本発明は必要に応じて、データ構造を結合することもその範囲に含むものである。
【０１６０】
本発明は、発明者によって種々の出版物に従前記載されてきた技術及び理論の上に立ってなされた。これらの出版物としては、「Ａｐｏｔｒａｍ−アプリケーション指向のトランザクションモデル」、理学博士論文、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、１９９７年；「ネストされたデータベースによるマルチメディア会議での支持的共同作業」、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、ノルウェーコンピュータ科学会議議事録−ＮＩＫ’９６、１９９６、３１１−３２２頁；及び「ネストされたデータベースによる工学環境での共同作業サポート」、Ｏｌｅ Ｊｏｒｇｅｎ Ａｎｆｉｎｄｓｅｎ、ＣＥＥＤＡの議事録、１９９６、Ｐｏｏｌｅ、ＵＫ、３２５−３３０頁、が挙げられ、これらを本明細書の一部を構成するものとしてここに援用する。これらの出版物に引用されている参考文献の各々も同様に本明細書の一部を構成するものとしてここに援用する。これらの出版物中のアプリケーション及び説明の各々は、本発明によって実施されるか、又は本発明と一緒に利用されてもよい。更に、米国特許第５，９８３，２２５号及び第６，０４４，３７０号を含む本発明者による米国特許を本明細書の一部を構成するものとしてここに援用し、本発明と一緒に使用しても、又は本発明と別個に使用してもよい。
【図面の簡単な説明】
【図１】
図１は、本発明を実施するデータベースマネジメントシステムのブロックダイアグラムである。
【図２】
図２は、サブデータベースに分割される資源について追跡履歴を保持（ｋｅｅｐｉｎｇ ｔｒａｃｋ）するためのデータ構造を示す。
【図３】
図３は、複数のリンクされたロック制御ブロック及びロックリクエストブロックを示す。
【図４】
図４は、サブデータベース内のデータ・アイテムに関するロックを設けるために用いるサブデータベースロック制御ブロック（ＳＬＣＢ）を含むデータ構造を示す。
【図５】
図５は、各トランザクションが特定のデータベース又はサブデータベースに属することを示す。
【図６】
図６は、この特定の実施態様において、トランザクションがそれ自身のデータベース又はサブデータベース中の資源にのみアクセス可能であることを示す。
【図７】
図７は、データベース制御ブロック（ＤＢＣＢ）データ構造の例示的構成を示す。
【図８】
図８は、トランザクション制御ブロック（ＴＣＢ）データ構造の例示的構成を示す。
【図９】
図９は、階層中に実現させたサブデータベースの例を示す
【図１０】
図１０は、アクティブトランザクションフィールドをデータベース制御ブロックに用い、コンテキストデータベースとサブデータベースフィールドとをトランザクション制御ブロックに用いた例を示す。
【図１１】
図１１は、サブデータベース毎に一サーチテーブルが存在し、且つサーチテーブルがサブデータベースロック制御ブロックへのリファレンスを含む、別の態様を示す。
【図１２】
図１２は、サブデータベースロック制御ブロックがアレイやテーブル内に含まれている、例示的構成を示す。
【図１３】
図１３は、データベース制御ブロックとトランザクション制御ブロックとを単一の階層的データ構造アレンジメントとして実現可能であることを示す。
【図１４】
図１４は、ロック制御ブロックデータ構造の別の構成を示す。
【図１５】
図１５は、新しいサブデータベースを作出するためのフローチャートである。
【図１６】
図１６は、ユーザ・データの物理的動きを必要とせずに如何にサブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）するかを示すフローチャートである。
【図１７】
図１７は、図１１のデータ構造を用いてサブデータベースの要素を構成する（ｐｏｐｕｌａｔｅ）するための別の実施形態を示すフローチャートである。
【図１８】
図１８は、ネスト化データベースの存在下でのロックリクエストの取り扱いを示すフローチャートである。
【図１９】
図１９は、ロック制御ブロックが図１１の別の構造を有する時の、ネスト化データベースの存在下でのロックリクエストの取り扱いを示すフローチャートの別の態様である。
【図２０】
図２０は、サブデータベースの使用を終わるために用いるプロセスのフローチャートである。
【図２１（ａ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｂ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｃ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２１（ｄ）】
図２１（ａ）〜２１（ｄ）は、複数のユーザが単一のデータベースの使用を所望し、サブデータベースにオーガナイズされる４種のワードプロセッシング・ドキュメントをこのデータベースが有している場合の例を示す。
【図２２（ａ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｂ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｃ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２２（ｄ）】
図２２（ａ）〜２２（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）に対応して、図２１（ａ）〜２１（ｄ）の例が実施される際のデータ構造アレンジメントを示す。
【図２３（ａ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｂ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｃ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２３（ｄ）】
図２３（ａ）〜２３（ｄ）は、それぞれ図２１（ａ）〜２１（ｄ）の例に対応するが、各データベースに対してサーチテーブルあるいはアレイが存在するデータ構造アレンジメントを使用する場合を示す。
【図２４（ａ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｂ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｃ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【図２４（ｄ）】
図２４（ａ）〜２４（ｄ）は、一ドキュメントの複数セクションが、異なる読出し・書込み能力を有する複数の人々によって、ネスト化データベースを使用することによって共有される場合の例を示す。
【符号の説明】
１００ データベースマネジメントシステム（ＤＢＭＳ）
１０２ トランザクションマネージャ
１０４ ロックマネージャ
１０６ データプロセッサ（ＣＰＵ）
１０８ トランザクションテーブル
１１０ ロックテーブル
１１２ データベース
Claims (72)
- データ処理システムによってアクセスされるためのデータを保存するメモリであって、
トランザクションの情報を含むデータ構造と、
トランザクションのデータのロックの情報を含むデータ構造と、
複数のデータベースについての情報を含む複数のデータ構造と
を含み、前記複数のデータ構造の少なくとも一のもの、データベースデータ構造、が前記トランザクションと前記データとに関連付けられた、複数のデータベースの少なくとも一のものの情報を含む、メモリ。 - データベースデータ構造がトランザクションの情報を含むデータ構造と関連付けられた、請求項１に記載のメモリ。
- データベースデータ構造がトランザクションの情報を含むデータ構造へのレファンレスを含む、請求項２に記載のメモリ。
- トランザクションの情報を含むデータ構造へのリファレンスが、
所有トランザクションへのリファレンスを含む、請求項３に記載のメモリ。 - データベースデータ構造が、トランザクションの情報を含むデータ構造とは異なるデータ構造である、請求項４に記載のメモリ。
- データベースデータ構造が、データベース中でアクティブな少なくとも一トランザクションの表示（ｉｎｄｉｃａｔｉｏｎ）を保存するフィールドを有する、請求項１に記載のメモリ。
- トランザクションの情報を含むデータ構造が、データベースデータ構造との関連を示すフィールドを有する、請求項１に記載のメモリ。
- トランザクションの情報を含むデータ構造が、トランザクションの少なくとも一サブデータベースとの関連を示すフィールドを有する、請求項７に記載のメモリ。
- データベースデータ構造との関連を示すフィールドが、コンテキストデータベースとの関連を示す、請求項７に記載のメモリ。
- データベースデータ構造との関連を示すフィールドが、データベースデータ構造へのリファレンスを含む、請求項９に記載のメモリ
- データベースデータ構造との関連を示すフィールドが、データベースデータ構造へのポインタを含む、請求項１０に記載のメモリ。
- データベースデータ構造が、トランザクションの情報を含むデータ構造とは異なるデータ構造である、請求項１１に記載のメモリ。
- トランザクションの情報を含むデータ構造が、少なくとも一サブデータベースとの関連を示すフィールドを有する、請求項１に記載のメモリ。
- トランザクションの情報を含むデータ構造が、ロックの情報を含むデータ構造と関連付けられたフィールドを有する、請求項１に記載のメモリ。
- ロックの情報を含むデータ構造と関連付けられたフィールドが、ロックの情報を含むデータ構造へのリファレンスを含む、請求項１４に記載のメモリ。
- ロックの情報を含むデータ構造が、二以上の分離したデータ構造を有する、請求項１５に記載のメモリ。
- 二の分離したデータ構造が、ロック制御ブロック及びロックリクエストブロックを有する、請求項１６に記載のメモリ。
- ロックの情報を含むデータ構造へのリファレンスが、ロックリクエストブロックへのリファレンスである、請求項１７に記載のメモリ。
- ロックリクエストブロックが、異なるロックリクエストブロックへのリファレンスを含む、請求項１８に記載のメモリ。
- データのロックの情報を含むデータ構造が、データベースデータ構造と関連付けられたフィールドを有する、請求項１に記載のメモリ。
- データベースデータ構造と関連付けられたフィールドが、複数のデータベースのうちどのデータベースにロックが属しているかを示す、請求項２０に記載のメモリ。
- データベースデータ構造と関連付けられたフィールドが、データベースデータ構造へのリファレンスを含む、請求項２１に記載のメモリ。
- データベースデータ構造と関連付けられたフィールドが、データベースデータ構造へのポインタを含む、請求項２２に記載のメモリ。
- ロックの情報を含むデータ構造が、二以上の分離したデータ構造を有する、請求項１に記載のメモリ。
- 二の分離したデータ構造が、ロック制御ブロック及びロックリクエストブロックを有する、請求項２４に記載のメモリ。
- ロックリクエストブロックが、異なるロックリクエストブロックへのリファレンスを含む、請求項２５に記載のメモリ。
- ロックの情報を含むデータ構造が、許可されたロックの情報を保存する一以上のフィールドを有する一データ構造を含む、請求項１に記載のメモリ。
- 許可されたロックの情報を保存する一以上のフィールドが、許可されたロックの情報のビットマップを保存する、請求項２７に記載のメモリ。
- トランザクションのデータのロックの情報を含むデータ構造が、該データのロックを異なるデータベースに対する別のデータのロックと関連付けるフィールドを有する、請求項１に記載のメモリ。
- データのロックを異なるデータベースに対する別のデータのロックと関連付けるフィールドによってリファレンスされる、異なるデータベースに対する別のロックの情報を含むデータ構造
を更に含む、請求項２９に記載のメモリ。 - データのロックの情報を含むデータ構造が、ロックに関連付けられたデータベースの表示（ｉｎｄｉｃａｔｉｏｎ）を有する、請求項１に記載のメモリ。
- データのロックの情報を含むデータ構造が、ロックに関連付けられたデータベースへのリファレンスを含み、該リファレンスはロックに関連付けられたデータベースの表示（ｉｎｄｉｃａｔｉｏｎ）である、請求項３１に記載のメモリ。
- ロックに関連付けられたデータベースへのリファレンスがポインタを含む、請求項３２に記載のメモリ。
- データのロックの情報を含むデータ構造との関連を示す情報を含むサーチ用データ構造を更に有する、請求項１に記載のメモリ。
- サーチ用データ構造が、前記関連であるロックの情報を含むデータ構造へのリファレンスを含む、請求項３４に記載のメモリ。
- サーチ用データ構造が、前記リファレンスであるロックの情報を含むデータ構造へのポインタを含む、請求項３５に記載のメモリ。
- 前記サーチ用データ構造がハッシュテーブルを含む、請求項３４に記載のメモリ。
- 前記サーチ用データ構造がアレイ（ａｒｒａｙ）を含む、請求項３４に記載のメモリ。
- 前記サーチ用データ構造がテーブルを含む、請求項３４に記載のメモリ。
- 前記データベースデータ構造が、前記サーチ用データ構造へのリファレンスを含む、請求項３４に記載のメモリ。
- 前記サーチ用データ構造と異なる第二のサーチ用データ構造と、
前記第二のサーチ用データ構造をリファレンスする第二のデータベースデータ構造と
を更に含む、請求項４０に記載のメモリ。 - サーチ用データ構造の中にロックの情報を含むデータ構造が含まれる、請求項３４に記載のメモリ。
- トランザクションの情報を含むデータ構造と、データ構造と、データベースデータ構造とが同じ階層に含まれる、請求項１に記載のメモリ。
- トランザクションに関連付けられた他のデータ構造及び複数のデータベース構造をリファレンスするトランザクションに関連付けられたデータ構造と、
トランザクションの情報を含むデータ構造の一以上をリファレンスする複数のデータベース構造と
を更に含む、請求項４３に記載のメモリ。 - トランザクションの情報を含むデータ構造と、トランザクションのデータのロックの情報を含むデータ構造と、データベースデータ構造とが異なるデータ構造である、請求項１に記載のメモリ。
- データ・アイテムがロックされていることを表示する方法であって、
第一の階層レベルにおいて、第一の階層レベルに関連付けられた第一のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する段階と、
第二の階層レベルにおいて、第二の階層レベルに関連付けられた第二のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する段階と
を含む方法。 - 第一の階層レベルにおいて作成されたデータ構造と第二の階層レベルにおいて作成されたデータ構造との間に関連を作成する段階
を更に含む、請求項４６に記載の方法。 - 関連を作成する段階が、第一の階層レベルにおいて作成されたデータ構造のフィールドに、第二の階層レベルにおいて作成されたデータ構造をリファレンスするリファレンスを作成する段階
を含む、請求項４７に記載の方法。 - 第二の階層レベルにおいてデータ構造を作成する段階が、
データ構造を第二の階層レベルにおいて作成して、第二の階層レベルに関連付けられたデータベースへのリファレンスを含める段階
を含む、請求項４６に記載の方法。 - 第一の階層レベルにおいてデータ構造を作成する段階が、
第一の階層レベルにおけるデータ構造を、第一の階層レベルにおけるデータ構造が第二の階層レベルに関連付けられたデータベースへのリファレンスを含まないように作成する段階
を含む、請求項４９に記載の方法。 - 第一の階層レベルにおいてデータ構造を作成する段階が、
第一の階層レベルにデータ構造を、第一の階層レベルにおけるデータ構造が第一の階層レベルに関連付けられたデータベースへとの関連を含むように作成する段階
を含む、請求項４９に記載の方法。 - データ・アイテムに対するロックが存在するか否かを判断する方法であって、次の各ステップ、
（ａ） データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する段階と、
（ｂ） ステップ（ａ）でデータ・アイテムに対するロックが存在しないと判断された場合に、第一の階層レベルにおけるデータ・アイテムに対するロックを作成する段階と、
（ｃ） ステップ（ａ）でデータ・アイテムに対するロックが存在しないと判断された場合に、データ・アイテムに対するロックが第二の階層レベルに存在するか否かを判断する段階と、
（ｄ） データ・アイテムに対するロックが第二の階層レベルに存在しない場合に、データ・アイテムに対するロックを作成する段階と
を含む方法。 - 前記作成するステップ（ｂ）が、
（ｂ＋１） ロックを示す第一の階層レベルにおけるデータ構造を作成する段階を含む、請求項５２に記載の方法。 - 前記ステップ（ｂ）が、
（ｂ＋２） サーチデータ構造からロックを示す第一の階層レベルにおけるデータ構造までのリファレンスを作成する段階を更に含む、請求項５３に記載の方法。 - データ・アイテムがロックされていることを表示するシステムであって、
第一の階層レベルにおいて、第一の階層レベルに関連付けられた第一のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する手段と、
第二の階層レベルにおいて、第二の階層レベルに関連付けられた第二のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する手段と
を含むシステム。 - 第一の階層レベルにおいて作成されたデータ構造と第二の階層レベルにおいて作成されたデータ構造との間に関連を作成する手段
を更に含む、請求項５５に記載のシステム。 - 関連を作成する手段が、第一の階層レベルにおいて作成されたデータ構造のフィールドに、第二の階層レベルにおいて作成されたデータ構造をリファレンスするリファレンスを作成する手段
を含む、請求項５６に記載のシステム。 - 第二の階層レベルにおいてデータ構造を作成する手段が、
データ構造を第二の階層レベルにおいて作成して、第二の階層レベルに関連付けられたデータベースへのリファレンスを含める手段
を含む、請求項５５に記載のシステム。 - 第一の階層レベルにおいてデータ構造を作成する手段が、
第一の階層レベルにおけるデータ構造を、第一の階層レベルにおけるデータ構造が第二の階層レベルに関連付けられたデータベースへのリファレンスを含まないように作成する手段
を含む、請求項５８に記載のシステム。 - 第一の階層レベルにおいてデータ構造を作成する手段が、
第一の階層レベルにデータ構造を、第一の階層レベルにおけるデータ構造が第一の階層レベルに関連付けられたデータベースへとの関連を含むように作成する手段
を含む、請求項５８に記載のシステム。 - データ・アイテムに対するロックが存在するか否かを判断するシステムであって、次の各手段、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段と、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、データ・アイテムに対するロックが存在しないと判断した場合に、第一の階層レベルにおけるデータ・アイテムに対するロックを作成する手段と、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、データ・アイテムに対するロックが存在しないと判断した場合に、データ・アイテムに対するロックが第二の階層レベルに存在するか否かを判断する手段と、
データ・アイテムに対するロックが第二の階層レベルに存在しない場合に、データ・アイテムに対するロックを作成する手段と
を含むシステム。 - 前記データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、
ロックを示す第一の階層レベルにおけるデータ構造を作成する手段
を含む、請求項６１に記載のシステム。 - 前記データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、
サーチデータ構造からロックを示す第一の階層レベルにおけるデータ構造までのリファレンスを作成する手段
を含む、請求項６２に記載のシステム。 - データ・アイテムがロックされていることを表示するコンピュータ・リーダブル・プログラムコード手段を含むコンピュータプログラム製品であって、
第一の階層レベルにおいて、第一の階層レベルに関連付けられた第一のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する手段と、
第二の階層レベルにおいて、第二の階層レベルに関連付けられた第二のトランザクションによってデータ・アイテムがロックされたことを表示するデータ構造を作成する手段と
を含むコンピュータプログラム製品。 - 第一の階層レベルにおいて作成されたデータ構造と第二の階層レベルにおいて作成されたデータ構造との間に関連を作成する手段
を更に含む、請求項６４に記載のコンピュータプログラム製品。 - 関連を作成する手段が、第一の階層レベルにおいて作成されたデータ構造のフィールドに、第二の階層レベルにおいて作成されたデータ構造をリファレンスするリファレンスを作成する手段
を含む、請求項６５に記載のコンピュータプログラム製品。 - 第二の階層レベルにおいてデータ構造を作成する手段が、
データ構造を第二の階層レベルにおいて作成して、第二の階層レベルに関連付けられたデータベースへのリファレンスを含める手段
を含む、請求項６４に記載のコンピュータプログラム製品。 - 第一の階層レベルにおいてデータ構造を作成する手段が、
第一の階層レベルにおけるデータ構造を、第一の階層レベルにおけるデータ構造が第二の階層レベルに関連付けられたデータベースへのリファレンスを含まないように作成する手段
を含む、請求項６７に記載のコンピュータプログラム製品。 - 第一の階層レベルにおいてデータ構造を作成する手段が、
第一の階層レベルにデータ構造を、第一の階層レベルにおけるデータ構造が第一の階層レベルに関連付けられたデータベースへとの関連を含むように作成する手段
を含む、請求項６７に記載のコンピュータプログラム製品。 - データ・アイテムに対するロックが存在するか否かを判断するコンピュータ・リーダブル・プログラムコード手段を含むコンピュータプログラム製品であって、次の各手段、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段と、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、データ・アイテムに対するロックが存在しないと判断した場合に、第一の階層レベルにおけるデータ・アイテムに対するロックを作成する手段と、
データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、データ・アイテムに対するロックが存在しないと判断した場合に、データ・アイテムに対するロックが第二の階層レベルに存在するか否かを判断する手段と、
データ・アイテムに対するロックが第二の階層レベルに存在しない場合に、データ・アイテムに対するロックを作成する手段と
を含むコンピュータプログラム製品。 - 前記データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、
ロックを示す第一の階層レベルにおけるデータ構造を作成する手段
を含む、請求項７０に記載のコンピュータプログラム製品。 - 前記データ・アイテムに対するロックが第一の階層レベルに存在するか否かを判断する手段が、
サーチデータ構造からロックを示す第一の階層レベルにおけるデータ構造までのリファレンスを作成する手段
を含む、請求項７１に記載のコンピュータプログラム製品。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/628,728 US6751617B1 (en) | 1999-07-12 | 2000-07-28 | Method, system, and data structures for implementing nested databases |
| PCT/NO2001/000304 WO2002010978A2 (en) | 2000-07-28 | 2001-07-16 | Method, system and data structures for implementing nested databases |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004505380A true JP2004505380A (ja) | 2004-02-19 |
Family
ID=24520055
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002515631A Pending JP2004505380A (ja) | 2000-07-28 | 2001-07-16 | ネスト化データベースを実行するための方法、システム及びデータ構造 |
Country Status (10)
| Country | Link |
|---|---|
| EP (1) | EP1323071A2 (ja) |
| JP (1) | JP2004505380A (ja) |
| KR (1) | KR20030047996A (ja) |
| CN (1) | CN1539110A (ja) |
| AU (2) | AU2001272863B2 (ja) |
| BR (1) | BR0112967A (ja) |
| CA (1) | CA2416909A1 (ja) |
| MX (1) | MXPA03000756A (ja) |
| RU (1) | RU2003105686A (ja) |
| WO (1) | WO2002010978A2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009526324A (ja) * | 2006-02-10 | 2009-07-16 | オラクル・インターナショナル・コーポレイション | ロックによって管理されるリソースに対する予測的変更 |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004006046A2 (en) * | 2002-06-24 | 2004-01-15 | Xymphonic Systems As | Method for data-centric collaboration |
| US7899999B2 (en) * | 2007-06-27 | 2011-03-01 | Microsoft Corporation | Handling falsely doomed parents of nested transactions |
| US7890472B2 (en) * | 2007-09-18 | 2011-02-15 | Microsoft Corporation | Parallel nested transactions in transactional memory |
| CN101650646B (zh) * | 2009-09-22 | 2012-02-08 | 杭州华三通信技术有限公司 | 一种共享数据一致性的实现方法及装置 |
| US9760584B2 (en) * | 2012-03-16 | 2017-09-12 | Oracle International Corporation | Systems and methods for supporting inline delegation of middle-tier transaction logs to database |
| CN104572077B (zh) * | 2014-12-12 | 2018-03-06 | 百度在线网络技术（北京）有限公司 | 数据库事务的处理方法及业务系统 |
| KR102016417B1 (ko) * | 2016-01-29 | 2019-09-02 | 한국전자통신연구원 | 분산 파일 시스템을 채용한 스토리지 시스템에서 클라이언트 장치와 함께 파일의 분산 잠금을 관리하도록 구성되는 데이터 서버 장치 |
| CN111190908B (zh) * | 2018-11-15 | 2023-09-22 | 华为技术有限公司 | 一种数据管理方法、装置及系统 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4965719A (en) * | 1988-02-16 | 1990-10-23 | International Business Machines Corporation | Method for lock management, page coherency, and asynchronous writing of changed pages to shared external store in a distributed computing system |
| US5226143A (en) * | 1990-03-14 | 1993-07-06 | International Business Machines Corporation | Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager |
| JP2533266B2 (ja) * | 1991-06-14 | 1996-09-11 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 共用デ―タシステムにおけるデ―タ資源のロッキング方法及びシステム間のデ―タロック管理方法 |
| US6044370A (en) * | 1998-01-26 | 2000-03-28 | Telenor As | Database management system and method for combining meta-data of varying degrees of reliability |
| US5983225A (en) * | 1998-01-26 | 1999-11-09 | Telenor As | Parameterized lock management system and method for conditional conflict serializability of transactions |
-
2001
- 2001-07-16 AU AU2001272863A patent/AU2001272863B2/en not_active Ceased
- 2001-07-16 WO PCT/NO2001/000304 patent/WO2002010978A2/en not_active Application Discontinuation
- 2001-07-16 KR KR10-2003-7001266A patent/KR20030047996A/ko not_active Application Discontinuation
- 2001-07-16 JP JP2002515631A patent/JP2004505380A/ja active Pending
- 2001-07-16 MX MXPA03000756A patent/MXPA03000756A/es unknown
- 2001-07-16 CN CNA018135137A patent/CN1539110A/zh active Pending
- 2001-07-16 CA CA002416909A patent/CA2416909A1/en not_active Abandoned
- 2001-07-16 EP EP01952068A patent/EP1323071A2/en not_active Withdrawn
- 2001-07-16 RU RU2003105686/09A patent/RU2003105686A/ru not_active Application Discontinuation
- 2001-07-16 AU AU7286301A patent/AU7286301A/xx active Pending
- 2001-07-16 BR BR0112967-8A patent/BR0112967A/pt not_active IP Right Cessation
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009526324A (ja) * | 2006-02-10 | 2009-07-16 | オラクル・インターナショナル・コーポレイション | ロックによって管理されるリソースに対する予測的変更 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU7286301A (en) | 2002-02-13 |
| EP1323071A2 (en) | 2003-07-02 |
| CA2416909A1 (en) | 2002-02-07 |
| KR20030047996A (ko) | 2003-06-18 |
| CN1539110A (zh) | 2004-10-20 |
| BR0112967A (pt) | 2004-02-25 |
| WO2002010978A9 (en) | 2003-11-06 |
| WO2002010978A3 (en) | 2002-08-08 |
| WO2002010978A2 (en) | 2002-02-07 |
| MXPA03000756A (es) | 2004-11-01 |
| AU2001272863B2 (en) | 2004-11-18 |
| RU2003105686A (ru) | 2004-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6751617B1 (en) | Method, system, and data structures for implementing nested databases | |
| US6792432B1 (en) | Database system with methods providing high-concurrency access in B-Tree structures | |
| US6606626B1 (en) | Database system with lock manager enhancement for improving concurrency | |
| EP1540533B1 (en) | Controlling visibility in multi-version database systems | |
| US5448727A (en) | Domain based partitioning and reclustering of relations in object-oriented relational database management systems | |
| US5995973A (en) | Storing relationship tables identifying object relationships | |
| US7730032B2 (en) | Efficient queriability of version histories in a repository | |
| US5983225A (en) | Parameterized lock management system and method for conditional conflict serializability of transactions | |
| US5276872A (en) | Concurrency and recovery for index trees with nodal updates using multiple atomic actions by which the trees integrity is preserved during undesired system interruptions | |
| US5842196A (en) | Database system with improved methods for updating records | |
| US7028057B1 (en) | Versioned relational database system with an optimistic constraint model | |
| CA2537411C (en) | A database management system with efficient version control | |
| RU2413984C2 (ru) | Системы и способы манипулирования данными в системе хранения данных | |
| Lomet et al. | Access method concurrency with recovery | |
| Lomet et al. | Concurrency and recovery for index trees | |
| US20040225673A1 (en) | Range-clustered tables in a database management system | |
| AU2003227293A1 (en) | Database management system and method for conditional conflict serializability of transactions and for combining meta-data of varying degrees of reliability | |
| CA2143288A1 (en) | Data storage system with set lists which contain elements associated with parents for defining a logical hierarchy and general record pointers identifying specific data sets | |
| Taniar et al. | A taxonomy of indexing schemes for parallel database systems | |
| Jordan et al. | Precision locks | |
| US7596584B2 (en) | Predicate based group management | |
| JP2004505380A (ja) | ネスト化データベースを実行するための方法、システム及びデータ構造 | |
| JP4126843B2 (ja) | データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体 | |
| AU2001272863A1 (en) | Method, system and data structures for implementing nested databases | |
| US7321898B1 (en) | Locking mechanism for materialized views in a database system |