JPH11502330A - オブジェクト指向データベースと非オブジェクト指向データ機構を統合するオブジェクトデータ指向データ記憶装置統合環境 - Google Patents

Abstract

(57)【要約】 非オブジェクト指向データ記憶装置（22）にアクセスし、オブジェクトアプリケーションとの統合を行うシステム。分散型オブジェクトデータシステム及びオブジェクトデータベース管理システム（ODBMS）（20）を使用するアプリケーションに、外部データ記憶装置への透過性インタフェース（26）が備えられている、統合環境が実現される。ODBMS（20）を通じてデータにアクセスするアプリケーションは、オブジェクトに変換される外部データを含んでいる外部データ記憶装置の中のデータを操作することができる。記憶管理アプリケーションプログラムインタフェース（SMAPI）（24）は、オブジェクトのハンドリング、参照、繰り返し及び索引付け、オブジェクトトランザクション実現、及びキャッシュハンドリングのための機能インタフェースを実現する。SMAPIは、外部データ記憶装置（22）を採用するためのクラスを実現し、外部データを、OODBMS（20）を使用して操作することができるオブジェクトに変換する外部記憶マネージャを含んでいるモジュラーアーキテクチャの一部である。

Description

【発明の詳細な説明】 名称 オブジェクト指向データ記憶統合環境 発明の技術分野 本発明はコンピュータデータベースに関し、詳細にはオブジェクト指向データ ベースと非オブジェクト指向データ機構の統合に関する。 発明の技術的背景 コンピュータシステムアプリケーションで使用するためのデータの永続的記憶 のためには現在様々な手段及び方法論が存在している。周知のデータベース管理 システム（DBMS）は、たとえデータを使用又は生成したプログラムが終了された 後であっても使用するために（「永続性」）、例えばディスク、テープ等のよう な、持久記憶装置へのデータの記憶を簡単にしている。永続性に加えて、DBMSは 基本的に「同時制御」を提供し、従って、ユーザーは相互に妨害したり、データ の保全を危険にしたりせずに、データベースをきょうゆることができ、システム （ハードウエア又はソフトウエア）の故障の際にデータ保全を保護及び復元する ための機能を「回復する」ことができる。DBMS「照会」機能は、データレコード の内部にいくつかの特定の特性又はフィールドを指定することによってユーザー が大容量のデータにアクセスすることを可能にし、一方、いくつかのデータへの アクセスを制限するために、「機密保護」機能が一般的にはDBMSに組み込まれて いる。周知のDBMSはデータベースの中のデータの特性および関係を記述するため に「スキーマ」管理を支援する。 DBMS技術の進展とともに、上記のような基本的機能性は維持及び拡張されてき たが、一方では、データの複雑性及び処理性能要件は増大しているのである。「 関係型」DBMSとして知られている商業データ処理に適用される１つのタイプのデ ータ管理技術が、全てのデータがまるで表に定様式化されているかのように編成 されており、その表の列が表のフィールド又は定義域を表し、表の行が表のフィ ールド又は定義域の値を表すという点で比較的単純化された形でモデル化されて いる。データは表として論理的に編成されているが、しかしそのままの形で物理 的に記憶されているわけでは必ずしもない。関係型データベースユーザーは、ど のようにデータベースが物理的に構成されているのかを知る必要はなく、 言語インタフェース又は「構造化照会言語」（SQL）によってデータへのアクセ ス及びデータの更新を行うことができる。 科学及び技術問題の解決に関連するデータの相対的複雑性、及び、実ワールド にモデル化された複雑なデータ構造及びデータエンティティーの展開の結果とし て、「オブジェクトDBMS」（ODBMS）又は「オブジェクト指向DBMS」（OODBMS） として知られている新世代のDBMSが開発されるに至った。ODBMSは関係型モデル には適合しないが、しかしオブジェクトエンティティーを記憶及び操作するため に実質的に同じ機能性（つまり、永続性、同時制御、回復、機密保護、照会機能 、及びスキーマ管理）を提供する。オブジェクトエンティティー又は「オブジェ クト」は、実ワールドエンティティーをモデル化した複雑なモデル構造であり、 クラスにおいて対応付けられており、その情報的特徴（属性）及び機能的特徴（ 挙動）によって識別される。C++及びSmall Talkのようなオブジェクト指向プロ グラミング（OOP）言語を使用して、オブジェクトが実現される。実ワールドエ ンティティーをモデル化した複雑な特殊化データ構造又はオブジェクトを定義す ることによって、データの抽象化のレベルが、アプリケーションをアプリケーシ ョンのユーザーが記述したのと同じ条件で効率的に実現することができる点まで 高められるので、プログラム開発をより簡単かつより自然に行うことができる。 オブジェクトはより簡単にタイプに分類可能であり、タイプはサブタイプ/スー パータイプ階層において簡単に相互に対応付けられる。OOP言語は、限定された 事前定義タイプによって拘束されることがないように、プログラマーがデータタ イプを柔軟に定義することを可能にする。OOP言語は、他のクラスから属性及び/ 又は挙動を「引き継ぐ」ことができるクラスの形で対応付けることができる。複 雑なオブジェクトデータ構造及びタイプは関係型DBMSモデルによっては支援され ないが、しかし、オブジェクトの直接記憶及び操作を簡単にし、オブジェクトを 表にマッピングする必要のないODBMSによって支援される。 関係型DBMS及びオブジェクトDBMSは現在は共存しており、一方が他方に完全に 取って代わる可能性はほとんどない。それぞれのタイプのDBMS（つまり、関係型 及びオブジェクト）はそれぞれ特定のアプリケーションに最適であり、例えば、 関係型DBMSは、保険及び銀行業界のような、事前定義タイプのビジネスデータの 処理に最適であり、オブジェクトDBMSは、コンピュータ援用設計及びコンピュー タ援用ソフトウエア技術において使用されるような、実ワールドエンティティー についてモデル化された拡張可能データ構造に最適である。しかしながら、既存 の関係型データ記憶装置にはかなりの投資がすでに行われている ことと、オブジェクトアプリケーションへと向かう連続的な動向及び評価の高ま りから、オブジェクト技術と関係型技術とを統合することが必要になっている。 関係型データとオブジェクトデータの統合の必要が生じるのは、データが関係 型モデルに従って管理されていた/いるコンテクストにおいてオブジェクト指向 プログラミングの特徴を利用するたために、新しいオブジェクト指向アプリケー ションが実現される状況においてである。オブジェクトプログラミングを関係型 データベースと統合する周知の手段は、オブジェクト指向プログラムへのアクセ スが簡単なオブジェクトデータに関係型DBMSの中の全ての関係型データを変換す る手動プログラミングを行うことを含んでいる。しかしながら、そのような変換 には相当の労力が必要であるのに加えて、一般的には、関係型データへのアクセ スを要求し続ける非オブジェクト指向アプリケーションプログラムが存在してい る。従って、欠点として、冗長データ記憶装置を有することが必要になることが あり、その結果、資源が二重になり、オーバヘッドが大きくなる。それに加えて 、DBMSの関係型及びオブジェクトバージョンを更新及び維持するタスクは、更新 を実質的に同時に協調させなければならず、異なる環境においては繰り返さなけ ればならないことがあるという点に問題がある。たとえ関係型データベースにア クセスする既存のプログラムの全てがオブジェクト指向プログラミング言語で書 き換えられたとしても、そのような変換方式は費用がかかり、複雑で、時間を食 うことになる。 予測可能入力フォーマットでのオブジェクトデータベースへのデータのインポ ートを可能にする標準化インポート/エクスポート機構が知られている。インポ ート/エクスポート機能は、その実現には関係型データのスキーマ又はフォーマ ットの知識を必要とするプログラムである。それに加えて、関係型データ要素は 、ODBMSによって管理することができるODBMSの内部のオブジェクトにマッピング しなければならず、ODBMSはその結果としてマッピングされた関係型データ要素 を管理する。しかしながら、関係型環境とオブジェクト環境の間を通過させなけ ればならないデータを表示するためには事前定義フォーマットが必要であるとい う点で、このような機構は柔軟性を欠いている。インポート/エクスポート機構 は翻訳機構としては有効に働くのであるが、関係型データが維持されている事前 定義フォーマットに厳密に従わなければならず、そうしなければオブジェクトへ のマッピングも、ODBMSによる管理も行うことはできない。オブジェクト言語プ ログラムが表よりはむしろオブジェクトに近い形で関係型データを関係型データ ベースから検索することを可能にするSQLゲートウエイの形の翻訳技術が知られ ている。プログラマーは必要とする特定のデータ の編成又はスキーマを知っていなければならず、一般的には元の関係型フォーマ ットに非常に近いフォーマットでしかデータを使用することができない。関係型 連データベースの表に対して作用するSQLステートメント又は要求を実現するた めには、プログラマーはオブジェクト指向プログラミング言語を使用している。 SQLゲートウエイはOOP言語ステートメントをSQLステートメントに変換し、表の 行又は関係型データをオブジェクトに変換する。このようなメカニズムは、アプ リケーションプログラマーが関係型データベースシステムとオブジェクトデータ ベースシステムとの技術的相違点を認識し、それに適応することを要求する。SQ L、関係型パラダイム及びオブジェクト指向パラダイムの理解を要求するするSQL ゲートウエイを使用するためには、プログラマーはアプリケーションコードを書 かなければならない。ゲートウエイが単一の一貫性のあるアプリケーションプロ グラムインタフェースを通じて異なる関係型データ記憶装置への統一的アクセス を提供することはない。 さらに、たしかにゲートウエイはオブジェクトと関係型連データ構造との効果 的な変換を行いはするが、オブジェクトを識別する手段を支援することはなく、 それが、アプリケーションによるデータ要求をすでにキャッシュされたデータに よって満足することができるかどうかを決定するのを困難にしている。この結果 、アプリケーションの性能に悪影響を与えるデータ記憶装置への冗長アクセスが 行われたり、データ繰り返しの問題が生じたりすることがあり、そのどちらにつ いても、防止又は対処のためには、かなりの追加的オーバヘッド及びアプリケー ションのコーディングが必要である。さらに、ゲートウエイのスキーマ情報は関 係型フォーマットで外部データ記憶装置の中に保全されている。そのようなスキ ーマへの実行時間アクセスには、そのような情報をOOP言語として使用可能にす るために、アプリケーションレベルにおける追加的プログラミングが必要である 。 発明の概要 本発明は、非オブジェクト指向データ記憶装置にアクセスし、オブジェクトア プリケーションとの効果的な統合を行うための方法及び装置を提供する。分散型 オブジェクトデータベース及びオブジェクトデータベース管理システム（ODBMS ）を使用するアプリケーションに、ロケーション透過性を実現するような方式で 外部データ記憶装置へのインタフェースが備えられている、統合環境が実現され る。ODBMSを通じてデータにアクセスするアプリケーションは、マッピングされ 、オブジェクトアプリケーションによる使用のためにオブ ジェクトに変換される外部データを含んでいる外部データ記憶装置の中のデータ を操作することができる。 記憶管理アプリケーションプログラムインタフェース（以下、“SM API”と呼 ぶ）は、オブジェクトをハンドリングし、オブジェクトを参照し、オブジェクト の繰り返し及び索引付けを実現するための機能インタフェースを実現する。SM A PIは、OOP言語ときちんと統合されている単一の一貫性のあるODBMS APIを実現す ることによって外部データ記憶装置へのアクセスを統一する外部記憶マネージャ を含んでいるモジュラーアーキテクチャの一部である。外部記憶マネージャは、 外部記憶装置を採用するための基礎を提供するクラスを実現し、外部データをマ ッピングし、ODBMSを使用するアプリケーションによって操作可能なオブジェク トに変換する。オブジェクトアイデンティティーを外部データに割り当てるため にはキーが使用され、アプリケーションによってすでにキャッシュされているデ ータをそのキーによって識別し、同じデータに対する繰り返し要求に応じてキャ ッシュの中に配置することが可能になる。 発明の特徴には、オブジェクトデータベース管理システムによる、様々なパラ ダイム、スキーマ及びファイルフォーマットを有する非オブジェクトデータベー スを含んでいる外部データ記憶装置へのアクセス能力の提供が含まれている。ア プリケーション開発担当者は単一のオブジェクト指向プログラミングパラダイム を使用し、アプリケーションによって使用されるデータを記憶するために使用す る基本的記憶機構とは無関係に、そのアプリケーション定義域のオブジェクトモ デルに集中することができる。多種多様な外部記憶装置へのアクセスのために、 ユーザー定義記憶管理コンポーネントを開発することができる。柔軟性、拡張性 、及びアプリケーションコードの再使用というオブジェクト技術の利点は、非オ ブジェクトデータ記憶装置へのインタフェースとしてのオブジェクトアプリケー ションにおいてその真価を認めることができる。既存のデータベース及びファイ ルシステムへの投資は維持しつつ、オブジェクト指向アプリケーションへの転換 が可能になるのである。 発明のその他の特徴、効果および局面は、ONTOS DB 3.0『レファレンスマニュ アル』第１巻「クラスライブラリ」、ONTOS DB 3.0『開発担当者用ガイド』、ON TOS DB 3.1『外部記憶管理ガイド』、ONTOS DB 3.1『拡張可能記憶管理ガイド』 、及び付属書Ｉ、IIに説明されており、その全てが引例としてここにも記載され ている。 図面の説明 発明は、添付図面と関連づけられている下記の詳細な説明によってより完全に 理解されよう。 第１図は、クライアント・サーバアーキテクチャを有する分散型オブジェクト データベースのブロックダイアグラムである。 第２図は、発明によるモジュラーア−キテクチャ統合環境のブロックダイアグ ラムである。 第３図は、発明によるオブジェクト指向データ記憶装置統合環境の実現の一例 の場合のオブジェクトデータ構造のオブジェクトモデルのダイアグラム表示であ る。 第４図は、発明によるオブジェクト指向データ記憶装置統合環境の実現の例の 場合の関係型外部記憶装置の関係型データ構造のダイアグラム表示である。 第５図は、発明による外部記憶マネージャによって保全される記憶場所に一般 的には保持される情報のサンプルであり、どのようにしてそのような情報がオブ ジェクトモデルのスキーマレベル構造と連結されるかを図示している。 第６図は、RDB照会にマッピングされるオブジェクト照会を実現するプロセス のダイアグラム表示である。 第７図は、どのようにイテレータ及び関連のタイプマップオブジェクトがRDB 照会カーソルから結果を抽出するための協調し、それをキーに処理するのかを示 したダイアグラム表示である。 第８図は、キーからオブジェクトを構成するプロセスを図示したものである。 第９図は、発明による統合環境におけるオブジェクトの中のデータの記憶のダ イアグラム表示である。 第10図は、発明による統合環境における外部関係型データベースからのオブジ ェクトの削除のダイアグラム表示である。 詳細な説明 非オブジェクトデータ記憶装置の統合の図示実施例は、本発明の被譲渡人であ るONTOS社の製品であるONTOS DBのような分散型データベース環境において実現 することができ、ネットワーク全体にデータベースを分散させるためにクライア ント・サーバアーキテクチャを使用している。第１図に示されたような、このよ うなクライアント・サーバアーキテク チャは、C++又はSmall Talkのようなオブジェクト指向プログラミング（OOP）言 語で書かれたアプリケーション又はプログラム10を含んでいる。アプリケーショ ン10は、アプリケーションプロセス12としてのネットワーク内のワークステーシ ョンのプロセスの中でランする。アプリケーションプロセス12はアプリケーショ ン又はプログラムコード10、及び分散型データベース機構のクライアント部14を 含んでおり、クライアント部14は分散型データベース機構のクラス及び機能の範 囲内で実現され、アプリケーション10に対して有効な透過性を有している。 アプリケーション10は、分散型データベース機構を使用する場合には、クライ アント部14を通じて、ネットワークのどこか他の場所のホスト機によってランす る１次サーバ16と呼ばれる別のプロセスと通信する。１次サーバ16は分散型デー タベース機構の１次マネージャであり、自らのデータベース領域を管理し、同じ 分散型データベースの他の領域を管理する２次サーバ18と通信する。 アプリケーション10が、分散型データベース機構によって管理されるオブジェ クトのようなデータを要求した場合には、オブジェクトはクライアント14によっ て要求され、サーバ16によって検索され、クライアント14に送られる。オブジェ クトはクライアントアプリケーションの仮想メモリの中に「活動化」され、C++ 構造のようなOOP構造として操作される。アプリケーション10は、これらのオブ ジェクトによって仕上げられた場合には、これらの目的を「非活動化」し、これ らのオブジェクトによって使用されたメモリを任意に割り当て解除し、クライア ント14に戻す。クライアント14は、分散型データベースのそれぞれの領域におい てオブジェクトに変更を加えるサーバ16、18にオブジェクトを送る。 第２図によれば、オブジェクトアプリケーション10は、以下に記述してあるよ うに、オブジェクトハンドリング、参照ハンドリング、繰り返し及び索引付け、 及びトランザクションハンドリングに関連するタスクを実行するために、ODBMS 20の分散型データベース機構を使用している。アプリケーション10は一般的には C++の形のOOP言語ステートメントを、ODBMSの中のデータにアクセスし、データ を操作するためのデータ操作言語（DML）として利用しているが、同時にODBMSに は、非オブジェクトデータ又はオブジェクトアプリケーションに関連したものと は実質的に異なるスキーマのデータに関して要求される機能性を実現するために 、外部データ記憶装置22へのインタフェースが備えられていなければならない。 ONTOS DBを含んだ図示実施例においては、引用文献に詳細に記述されているよ うに、開 記憶マネージャアプリケーションプログラムインタフェース（“SM API”）が記 憶管理用の総称プロトコル又は関数を定義するアプリケーションプログラムイン タフェース（API）又は開ベースクラスを提供するモジュラーアーキテクチャが 実現される。オブジェクトハンドリング、参照ハンドリング、繰り返し及び索引 付け、及びトランザクションハンドリング活動を簡単にするために、SM API 24 は本質的に複数のAPIを実現する。SM API 24からなる関数は付属書Ｉに記載され ている。オブジェクト、参照、トランザクション、並びにインデックス及び拡張 子を含んだコンストラクトを支援する限りにおいては、広範なオブジェクト指向 プログラミング・データ管理システムを発明に適応させることができる。 図示実施例のODBMS 20の中のオブジェクトは、アプリケーション10定義域の中 で発見されるオブジェクト（人々、場所、概念、及びその他の物）を表すデータ の単位である。オブジェクトは、実行時において決定することができるタイプ（ 彼等が何であるのか、例えば「野球選手」）を有しており、通常はいくつかのタ イプ特有データ（「名前」、「打撃成績」、「身長」、「入団年度」のような、 測定基準、色、ラベル、記述等）、及びそれと関連したいくつかのタイプ特有挙 動（彼等が何をすることができるのか、彼等によって/彼等に対して何をするこ とができるのか、「プレイボール」、「三振」、「練習」、「トレード」）を有 している。 オブジェクトの読み取り及び活動化、並びにデータ記憶装置へのオブジェクト の書き込み及び入力を含めたオブジェクトハンドリングタスクは、オブジェクト ハンドリングメンバ機能によって実現される。図示されたONTOS DBにおいては、 あらゆるオブジェクトは、事例化によって、SM APIベースクラスの記憶マネージ ャ事例に割り当てられる。関連記憶マネージャ事例は当初は新たに例示されたオ ブジェクトのために適当なメモリロケーションを割り当てる役割を有している。 オブジェクトのステータスは、オブジェクトハンドリングインタフェースの中の 機能を使用して照会することができる。オブジェクトの記憶マネージャには、メ モリ又はODBMSの中のオブジェクトを操作するための機能も含まれている。オブ ジェクトの記憶マネージャは、活動化、非活動化、データベースからの削除、及 び割り当て解除のようなオブジェクト操作の実行を実現する。 すでに述べたように、図示実施例におけるODBMSによってハンドリングされる 各オブジェクトは、SM API 24の記憶マネージャ事例に割り当てられ、操作され る。記憶マネージャは、メモリ内オブジェクト又は永続性オブジェクトのいずれ かを指し示すことを可能にしてくれる機構又は参照を有していなければならない 。従って、あらゆるオブジェクトは、それ を指し示すことができる特性又は検索を有している。参照とは、あるオブジェク トを別のオブジェクトと対応付けることができる結合である。例えば、「野球選 手」を表すオブジェクトは、それを「野球チーム」、「練習スケジュール」、及 び/又は「野球のユニホーム」を表すオブジェクトのようなその他のオブジェク トと結合する参照を有することができる。 繰り返し及び索引付け操作は、そのタイプ及び/又はデータに基づくオブジェ クトへの高速アクセスを簡単にする索引及び拡張子の使用と関連がある。ODBMS は一般的には処理のためにデータベースの中のオブジェクトについてアプリケー ションを繰り返すことを可能にする機構を含んでいる。ONTON DBにおいては、引 用文献に記載されているように、データベーススキーマの中のタイプの事例とし て表されているオブジェクトについての繰り返しを行うために、索引及び拡張子 が使用される。 タイプとは、その事例と呼ぱれるその他のエンティティーの状態、挙動及び適 用性を定義するオブジェクトの種類である。タイプは事例の（その他のオブジェ クトの）状態をその特性によって、動的挙動をその手順によって指定し、新しい 事例を構築する手段を指定する。図示実施例におけるONTOS DBのタイプも、その タイプの全ての事例にアクセスするために、そのタイプの事例をディスク及び任 意のイテレータからメモリの中に入れる際に使用される情報を提供する。 同様に、図示実施例のONTOS DBを含めた先行技術による一般的なODBMSにおい て支援されている索引も、そのデータの一部は分かっているが、そのアイデンテ ィティーが分かっていない場合には、オブジェクトへの高速アクセスを可能にす る。例えば、各「野球選手」を打率の順にリストアップしている構造の場合には 、リーグの最高及び最低の打者（リストの最上位及び最下位）への高速アクセス が可能である。拡張子は、そのデータとは無関係に、周知のタイプの全てのオブ ジェクトへの高速アクセスを可能にする。例えば、全ての「投手」のリストによ って、全ての「野球選手」のリスト、又はもっと悪い、「野球選手」、「チーム 」、「チームマネージャ」、「球場」等を含んだ全ての野球関連オブジェクトの 膨大なリストへのアクセスよりは高速で全ての投手にアクセスすることが可能に なる。 トランザクションはオブジェクト指向データベースのコンテクストにおける操 作であり、ODBMSによって実現され、その場合、データベースの個別の修正は、 全体として行われる（「コミット」される）か、又は全く行われない（「放棄」 される）単一の大きな修正に総合される。全てのクライアントアプリケーション データベース操作は、ODBMS、又は図示 実施例のONTOS DBによって実現されるトランザクションの形で行われる。 一般的なODBMSにおいては、トランザクションは１つ以上のオブジェクトに関 する操作のアトミックセットと呼ばれる。「アトミック」とは、トランザクショ ンの内部での操作が、まるで全て行われたのか、又は全く行われなかったかのよ うに処理されることを意味している。「野球選手」の例を続けると、試合が行わ れて、試合における選手及びチームの統計データの全てがそれに応じて更新され るか、又は試合が雨のため中止になり、選手及びチームの記録は全て変更されな いままであるかのいずれかであるので、各「試合」をトランザクションと対応付 けることができるのである。 オブジェクトハンドリング、参照ハンドリング、索引及び拡張子、及びトラン ザクションは、ここで説明されている図示モジュラーインプリメンテーションに おけるSMAPI 24によって適応させられる一般的なODBMSコンストラクトである。S M API 24が絶対要件ではなく、この図示実施例に含まれているONTOS DBの１つの 特徴であることが評価されるべきであろう。発明を実施するためには、コンスト ラクト及び上記の一般的なODBMSのコンストラクトを操作するための機能を、下 記の発明による外部記憶マネージャ機構26の「フロントエンド」APIにおいて支 援するだけでよい。この図示実施例では、ONTOS DBはSM API 24の形式および機 能によってそのような支援を行う。 これらのコンストラクト、及びこれらのコンストラクトを操作するために定義 された操作はAPIまたは「フロントエンド」を外部記憶マネージャ機構26に供給 する。この「フロントエンド」APIはAPIからオブジェクト指向データベースプロ グラミングシステムまで区別不能であるので、外部記憶マネージャ機構26は、ま るで全てのデータが真のオブジェクトデータベースから透過的にアクセスされる かのように、アプリケーション10を通常のオブジェクト指向パラダイムにおいて 可能にする。特に、データ記憶機構の各々にアクセスが行われるので、アプリケ ーション開発担当者はインタフェース要件に関わる必要がない。 図示実施例においてはSM API 24からなる機能は、特定の機構の外部データ記 憶装置22の特定の要件に合わせるために、下記のように、専用外部記憶マネージ ャ28を呼び出す。本質的に、外部記憶マネージャ機構26は、SM API 24またはそ の他のODBMS APIの総称機能性と外部データ記憶装置22又は様々なスキーマ及び フォーマットを有する外部データベース及びファイルの特定要件との間に柔軟性 のある拡張可能なアダプタを供給する。 ここに説明されている外部記憶マネージャ機構26は、オブジェクトのタイプ及 びデータ、その他のオブジェクトに対するその参照、オブジェクトが参加するト ランザクション、及 びオブジェクトに迅速にアクセスするための索引及び拡張子の使用に焦点を合わ せている。これらの「フロントエンド」コンストラクトの各々は、外部記憶マネ ージャ26機構によって、使用可能な外部記憶装置22又はデータ記憶サブシステム によって直接支援される１つ以上の「バックエンド」コンストラクトの中にマッ ピングされる。総称フロントエンドコンストラクトを使用して書かれたアプリケ ーションは様々な操作をコンストラクトに適用する。これらの操作は、支援され ている外部データ記憶装置22又はデータ記憶機構に固有の操作にタスク指名を行 うか、又はデータ記憶機構への前のアクセスから先行技術によってキャッシュさ れたデータを使用して外部記憶マネージャ機構26を内部操作することによって、 外部記憶マネージャ26機構によって均一に実現される。 外部データ記憶装置22と直接通信する外部記憶マネージャ28の「バックエンド 」は、固有のコンストラクトのセット、つまり、バックエンドコンストラクトを 備えたAPIからなる。ODBMS APIと同一になるように設計されている「フロントエ ンド」とは違って、「バックエンド」APIには新規性があり、特定のパラダイム 又は基準と同一になることを意図したものではない。その代わりに、「バックエ ンド」コンストラクトは、広範なデータ記憶機構及びそのAPIにおいて使用され る共通な種類のコンストラクトに一般的に対応することを意図している。バック エンドコンストラクトの各々は、バックエンドAPIにおいては、固有性の高い要 件を有してはいるが、データ記憶機構のコンテキストにおけるこれらの要件の実 現に広範なバリエーションをまだ許容する「総称」又は「抽象」コンストラクト として表示される。これらの共通のバックエンド又は外部データ記憶機構APIコ ンストラクト及びその要件は下記のように定義される。 記憶マネージャー特定データ記憶機構を表示する専用オブジェクト。各々のそ のようなデータ記憶機構には、下記のその他のデータ記憶機構コンストラクトの 大部分又は全ての実現を支援することが予想される。これらのコンストラクトの 各々の実現は通常は特定のデータ記憶機構のコンテキストの中でしか妥当しない 。データ記憶機構の実例はディスクファイル及び特定関係型データベースである 。 レコード−データ記憶機構の中に入口を形成する１つ以上の関係型データ片。 「レコード」の許容可能なバリエーションとしては、「物理レコード」、「物理 レコードのネットワーク又は階層」、「物理レコードの集合」、又は「永続性オ ブジェクト」がある。レコードは、アプリケーションに提示されるオブジェクト データ及びオブジェクトタイプ情報の基礎を供給する。 キー−特定のレコードと対応付けられている（その他の）データをどのように したら更新することができるかとは無関係に、そのレコードを識別するために使 用することができる１つ以上のデータ項目を含んでいるオブジェクト。「キ−」 の許容されるバリエーションとしては、「ディスクアドレス」、論理レコードID 」、「１次キー（単純又は複合）」、「階層的経路」、「ネットワーク経路」、 又は「永続性オブジェクトid」がある。キーは、オブジェクトアイデンティティ ーの基礎及び操作されているオブジェクトを参照する能力を供給する。オブジェ クトは、オブジェクトに対応付けられたデータの実ロケーションに対応するよう に作成されるので、キーは「大急ぎで」作成される。 タイプマップ−レコードとオブジェクトとの間の変換を定義するオブジェクト 。タイプマップは、レコードベース記憶データをオブジェクトベースアプリケー ションデータとして表示し、アプリケーション（バック）の中で更新又は生成さ れたオブジェクトベースデータを記憶のためにレコードベースデータに変換する ための基礎を供給する。一般的には、データ記憶機構当たり、及びデータが記憶 されるフォーマット又はレコードタイプの数とは無関係にその機能によってデー タが記憶されるオブジェクト当たり１つのタイプマップが存在している。類似の データ記憶機構又は類似のタイプのオブジェクトデータにアクセスするタイプマ ップは、実現技術の異なる部分を供給することができる。各々のタイプマップは 、下記の例に関して記述されているようなキー及びオブジェクトを構築する際に 使用されるキーレイアウト情報及びオブジェクトレイアウト情報を含んでいる。 分散型トランザクション−変更のセットが完全なトランザクションを構成して いるとアプリケーションが決定した場合に通知すべきトランザクション処理を支 援するあらゆるデータ記憶機構を許容するプロトコル。 分散型索引イテレータ及び共通索引−そのデータの一部は分かっているが、そ のキーが分かっていない場合に、レコードへの高速アクセスを行うために、索引 構造を支援し、これらの索引構造を使用するあらゆるデータ記憶機構を許容する プロトコル。索引構造を支援しないデータ記憶機構には、その代わりに外部記憶 マネージャ機構によって記憶されたキーベース「共通」インデックス構造を使用 すること、又は完全を期するためにアクセスの代替（低速）形態を供給すること が許容される。 分散型拡張子イテレータ及び共通拡張子−アプリケーションが特定のタイプの オブジェクトの全てを処理することを試みた場合に、適当なオブジェクトを作り 出すこの能力を使用するために、オブジェクトタイプに対応した全てのレコード についての繰り返しを支援 するあらゆるデータ記憶機構を許容するプロトコル。この能力を支援しないデー タ記憶機構には、その代わりに外部記憶マネージャ機構によって記憶されたキー ベース「共通」拡張子構造を使用することが許容される。 個々の外部記憶マネージャ28によって操作され、外部データ記憶装置22によっ て支援されるバックエンドコンストラクトのセットに一般的なODBMSのフロント エンドコンストラクトをマッピングする外部記憶マネージャ機構の操作は、付属 書IIに記載されている機能の抽象クラスによって行われる。このような操作は、 オブジェクトアプリケーションが使用するために、外部データ記憶装置の中にOD BMSデータを記憶するか、又はODBMSの中に外部データを記憶するアプリケーショ ンのための記憶管理のための基礎を供給する。 外部記憶マネージャ機構26は、個々の外部記憶マネージャ28によって操作され 、外部データ記憶装置22によって支援されるバックエンドコンストラクトのセッ トへの一般的なODBMSのフロントエンドコンストラクトのマッピングを簡単にす るために、それと対応付けられた貯蔵所30を含んでいる。貯蔵所30は、個々の外 部データ記憶装置22の中に記憶されたデータの構造を直接的に反映しているオブ ジェクトのスキーマローディング及びスキーママッピング用のアプリケーション 固有領域を含んでいる。貯蔵所のスキーマローディングにおいては、貯蔵所30の 中に記憶されるそのようなオブジェクトは、外部データ記憶装置22のスキーマに 従って記憶されるデータのレコード構造を表示するために生成される。外部デー タ記憶装置のレコード定義とそれらのレコード構造を表示する貯蔵所30の中のオ ブジェクトの間では、１対１マッピングが行われる。 スキーママッピングにおいては、レコード定義は、例えばONTOS DBを含んだ図 示実施例の場合のオブジェクトクラス定義又はオブジェクトタイプのような、オ ブジェクトAPIコンストラクトと対応付けられる。この図示実施例においては、 スキーママッピング機構は、OOPアプリケーションタイプと対応付けられた記憶 マネージャオブジェクト及びタイプマップを生成するために使用される。タイプ マップには、数値特性マップ、参照特性マップ及びセット特性マップとして編成 されているオブジェクトレイアウト（第５図、54）情報が含まれている。数値特 性マップは関係型データ記憶カラムをオブジェクト特性にマッピングする。参照 特性マップは外部/関係型キーをオブジェクト参照値特性にマッピングする。セ ット特性マップは遠隔外部キーをセット数値特性にマッピングする。 一般的には、外部データ記憶装置の表の数は、アプリケーションの要件に従っ てマッピングが行われるように選択される。各々の選択された表について、スキ ーママッピング機 構は新しいタイプを生成し、生成された各々のタイプについて記憶マネージャの 中にタイプマップを生成する。タイプマップは表を個々の記憶マネージャオブジ ェクトのタイプにリンクする。 各々の選択された表の各々のカラムについて、スキーママッピング機構は適当 な特性を生成し、対応付けられたタイプマップのオブジェクトレイアウト部の中 に数値特性マップを生成する。表の中の各々の外部キーについて、スキーママッ ピング機構は適当な特性を生成し、適当なタイプマップの中に参照特性マップを 生成する。 この表を参照する各々の外部キーについて、スキーママッパは適当な特性を生 成し、タイプマップの中にセット特性マップを生成する。従って、スキーマロー ディング中に貯蔵所30の中に生成/ロードされたオブジェクトによって表示され る外部データ記憶装置22のデータレコード構造は、適用可能OOPアプリケーショ ン10のオブジェクト構造にマッピングされる。 外部記憶マネージャ機構の役割は、操作されているデータがオブジェクト指向 データベース又はその他のいずれかの種類のデータ記憶機構の中に実際に記憶さ れているかどうかとは無関係に、オブジェクト指向データベースアプリケーショ ンコードを現状のままで働かせることにある。外部記憶マネージャは、上記のよ うに、アプリケーションコードが多重データ記憶機構の全域に分散されたデータ の相補セットについて同時に操作を行うことも可能にするOOPメッセージベース コンポーネントからなるアーキテクチャの中で実現される。アプリケーションに おいて使用され、フロントエンドAPIにおいて提示されるオブジェクトモデルの 中で指定されている操作の各々についてのバックエンドコンポーネントをベース にした実現を置換することによって、柔軟性が実現される。これを実証するため に、以下では、アプリケーションプログラムの各々のステップにおける外部記憶 マネージャの働きの詳細な解析に続いて、オブジェクト指向データベースアプリ ケーション用の疑似コードのいくつかのサンプルを提示する。各々のステップは 、下記の項目の説明によって解析する。 そのオブジェクト意味−アプリケーション開発担当者が意図したフロントエン ド操作。これらの操作は純オブジェクト指向データベースプログラミングシステ ムにおける単純システム操作として直接的に実施される。 そのマップ化実現−１つ以上のデータ記憶機構に対応付けられたコンポーネン トへのメッセージの送信を含んでいることが多い、外部記憶マネージャ機構が踏 むステップ。 そのコンポーネント実現（必要に応じて）−バックエンドコンストラクトへの フロントエンドコンストラクトのマッピングのプロセスで送られてきたあらゆる メッセージに対する一般的外部データ記憶コンポーネントの応答。異なる外部デ ータ記憶機構についてのコンポーネント実現は、各々のデータ記憶機構に固有の データフォーマット及びアクセス手順に従って当然異なるものになり、当業者に は理解されよう。説明のために、この例は、SQLを通じてアクセスされている特 定関係型データベース（RDB）をベースにした単一外部データ記憶機構を仮定し ている。 アプリケーションコード例は野球データベースの例を進展させたものであり、 第３図に示された小さなデータサンプルに記載されたオブジェクトモデルを仮定 している。オブジェクトモデルは下記のような情報を含んでいる。オブジェクトモデル この例においては、発明による統合環境の一般的実現におけるように、オブジ ェクトアプリケーション用のオブジェクトモデルは、オブジェクトアプリケーシ ョンと統合すべき外部データ記憶装置の中に記憶されたデータのデータ表示とは 全く異なっている。この場合には、関係型データベーススキーマが統合される。 第３図のオブジェクトモデルによる小さな関係型データサンプルが第４図に示さ れている。 例は、外部関係型データ記憶装置の中に記憶された下記の関係型スキーマを使 用している。 例１ 下記の疑似コード例は、オブジェクト指向データベースアプリケーションにお けるいくつかの一般的な処理を示したものである。 疑似コードによって表示されたアプリケーションを起動すると、トランザクシ ョンが下記のコードによって開始される。 １． start_a_transaction（）； このプログラムトランザクションが有効である間に完全に可視であるろうと不 可視であろうと、プログラムの中で続くあらゆる更新が単一アトミック操作の一 部として取り扱わ れ、いずれかの他のプログラムのトランザクションにおいて同時に行われたあら ゆる更新がODBMSによって単一アトミック操作として取り扱われるように、トラ ンザクションを開始するものとする。 外部記憶マネージャ機構26はトランザクションの開始を記録し、このトランザ クションの範囲内に将来のあらゆる操作を含めることを現在活動中の全てのデー タ記憶機構（それまではなし）に通知する。この時点では、アプリケーションに よるトランザクションの開始に対する外部データ記憶装置22による応答はない。 次のアプリケーションコード： ２． query ql（“EACH pitcher WITH current_season_losses＝0”）； は、そのcurrent_season_losses属性が０である全ての投手の照会を開始するた めに、ODBMS照会プロセッサを呼び出す。current_season_lossesに関する索引を 使用し、データ処理を促進するために、ODBMSの照会オプティマイザが照会を編 成する。 外部記憶マネージャ機構26は、当該の実現において管理される外部データ記憶 装置22と対応付けられたオブジェクトを含んだ貯蔵所30を維持する。外部記憶マ ネージャ機構貯蔵所は、外部記憶マネージャ機構26によって管理される外部記憶 装置22の各々と対応付けられた専用（外部）記憶マネージャオブジェクト28を含 んでいる。外部記憶マネージャ機構26は、投手オブジェクトに関するデータを含 んでいる特定の関係型データベース（RDB）を管理することを決定するために、 その貯蔵所30に照会を行い、パラメータ“current_season_losses”に対応付け られた索引操作に参加する。 投手オブジェクトに関するデータを含んでいるRDBに対応付けられた記憶マネ ージャオブジェクトは貯蔵所から検索され、活動状態にされる。現索引照会に参 加するために、その記憶マネージャオブジェクトには外部記憶マネージャ機構26 からメッセージが送られる。このメッセージを囲んでいるプロトコルは、関連記 憶マネージャがイテレータオブジェクトを検索することを予想している。次に、 技術としては周知の一般的なイテレータオブジェクトプロトコルは、関連記憶マ ネージャがそうすることを指示するメッセージを受け取った場合には、一連の数 値が消耗されるまで、一連の連続的数値を作り出すことを関連記憶マネージャに 要求する。 上記のような貯蔵所30は、その対応付けDBMSを通じて、外部データ記憶装置に 関連づけられた記憶マネージャオブジェクトを含んでいることに加えて、外部記 憶マネージャ機構26によって使用されるコンフィギュレーション情報も含んでい る。第５図は、一般的には 外部記憶マネージャの貯蔵所の中に保持されている、本図示実施例による情報の サンプル、及びどのようにしてそのような情報がオブジェクトモデルのスキーマ レベルコンストラクトと結合されるかを示している。外部データ記憶装置の中に 記憶されたデータのレコード構造に対応付けられている貯蔵所の中のオブジェク トは、ODBMS APIのフロントエンドコンストラクトと外部データ記憶装置のバッ クエンドコンストラクトをリンクする関係を定義している。 この例によるタイプである投手40、チーム42及び地区44に対応付けられた索引 及び拡張子を含んでいる、ODBMSアプリケーションに関連したフロントエンドコ ンストラクトは、貯蔵所30の中で定義されたタイプマップバックエンドコンスト ラクトを通じて、外部関係型データにマッピングされる。フロントエンドOOPタ イプ40、42、44は、投手のタイプマップ46、チームのタイプマップ48、及び地区 50のタイプマップを含んでいるバックエンドタイプマップオブジェクトと対応付 けられている。 貯蔵所の中のタイプマップの各々は、個々のOOPタイプ及びタイプマップコン トラクトと対応付けられており、キーを記述している構造情報、又は特定のRDB レコードを識別するために使用することができるデータ項目を含んでいるオブジ ェクトから構成されているキーレイアウト情報52を含んでいる。キーレイアウト 情報も、特定のRDBレコードを識別するために使用することができるデータ項目 を含んでいるオブジェクトを記述するために、下記のように、タイプマップが大 急ぎでキーを生成するプロセスを記述した情報を含んでいる。 オブジェクトレイアウト情報54も貯蔵所30の中のタイプマップコンストラクト に含まれている。オブジェクトレイアウト情報54は、上記のように、オブジェク トアプリケーションのニーズに対応して外部データ記憶装置の照会を通じて外部 データ記憶装置から集められたデータを使用してオブジェクトを構築することが できる情報を含んでいる。外部記憶マネージャ機構26は、アプリケーション10に よって含意されるタイプのデータを含んでいる外部データ記憶装置22を識別した 場合には、アプリケーションによって使用されるフロントエンドコンストラクト に従って、貯蔵所30の中のタイプマップにメッセージを送る。メッセージは、以 下に詳細に記述してあるように、総称データベース機能性を実現し、外部データ 記憶装置に向けられ、オブジェクト及びキーを構築するために必要とされるデー タに関連する照会構文テンプレートを呼び出す。 第６図には、RDB照会にマッピングされるオブジェクト照会を実現するプロセ スが示されている。この例においては、イテレータは、そのcurrent_season_los ses属性がゼロである 全ての投手を要求する、ODBMSアプリケーションによるオブジェクト照会（ql） として行われた照会の連続的な結果（投手オブジェクトの参照）を出すことを予 想されている。 このメッセージに対する外部記憶マネージャの応答は、一般的には、照会に関連 するタイプ（投手）を記録し、そのタイプに適したタイプマップを選択し、外部 記憶マネージャイテレータ60を作り出すことが予想されるタイプオブジェクトに メッセージを送るというものである。 外部RDBと対応付けられている新たに活動状態になった外部記憶マネージャ28 は、アプリケーショントランザクションがすでに進行中であることを検出する。 応答として、この外部記憶マネージャ28は外部RDBとの結合を確立し、RDBに対し て“START TRANSACTION”コマンドを出し、RDBを更新する（第６図には示されて いない）。タイプマップオブジェクトは、外部記憶マネージャイテレータオブジ ェクト60を参照することによって索引照会に参加するために、メッセージに応答 する。技術としては周知のように、イテレータオブジェクト60は、RDBへの照会 に対応付けられるように構築されており、一般的には、そのような照会64のステ ータスと対応付けられた「照会カーソル」を参照する。RDB照会の正確なフォー マットについては以下で検討する。 アプリケーション疑似コード： ３． while（there_are_more_results_from（ql）； は、照会から出て来る結果が（継時的呼び出しの場合に、さらに結果が）あるか どうかを決定するために、オブジェクトステータスのチェックを行う。 このステートメントの実行の度毎に、作り出すべき結果がさらにないかどうか を決定するために、イテレータ60にはメッセージが送られる。もしイテレータ60 がそれ以上の結果を有していることを示した場合には、外部記憶マネージャ28は 「真」ステータスフラグを復帰させる。もしイテレータが（それ以上の）結果を 有していないことを示した場合には、外部記憶マネージャ28は、その他の参加記 憶マネージャ（この例では、なし）によって作り出されたその他のイテレータに 向かう。結果を作り出すイテレータがもうそれ以上ない場合には、外部記憶マネ ージャ28は「偽」ステータスフラグを復帰させる。 イテレータに送られたメッセージは、（もしすでに開始されていない場合には ）RDB照会を開始し、照会カーソルのステータスを決定するために、イテレータ をその対応付けタイプマップと協力させる。イテレータは、RDB照会が（それ以 上の）結果を有しているかどうかを示すフラグを復帰させる。照合の結果として の１つ以上の投手オブジェクトが存在す ることを前ステートメントにおいて確認した後に、次の結果へのアクセスが下記 のコード行を通じて行われる。 ４． pitcher p＝the_next_result_from（ql）； その結果、外部記憶マネージャは、現れようとしている結果を有していること を示した最後のイテレータにメッセージを送る。第７図に示されており、それに 関して以下で検討されているように、このメッセージは外部記憶マネージャイテ レータに次の結果用のキーを作成させる。 第１のメッセージへの応答として、イテレータ60及び対応付けタイプマップオ ブジェクト46は、RDB照会カーソルから結果を抽出し、それをキーに加工するた めに協力する。照会の形態は、自ら及び投手オブジェクトを一意的に識別するこ とができるキーを構築するのに十分なデータを作り出すようなものである。これ は、キーの対応付けオブジェクト及びPITCHERレコードのNAME文字列を生成する 能力を有しているタイプマップへの逆参照から構成されることになる。この例に おける照会は、下記のものとすることができよう。 タイプマップ機能はキーを生成し、それがアプリケーションによって現在使用 されているその他の全てのキーに関して一意であることをチェックする。もし一 意ではない場合には、つまり、もし既存のキーの複製である場合には、新しいキ ーは直ちに廃棄され、その場所ではそれが突き合わせを行った既存のキーが使用 される。キーの突き合わせは、メッセージをキーに送ることによって行われ、一 意キーを構成しているものを決定する際の柔軟性を最大限に高めることができる 。この例においては、複製は、同じタイプマップ及びおなじNAME文字列の検索を 有するキーとして定義されることになる。一意キーは外部記憶マネージャ機構に 戻される。 第８図に示されているように、外部記憶マネージャは、キーと対応付けられた 投手オブジェクトを作り出すために、第２のメッセージをキーに送る。キーに送 られたメッセージは、その対応付けオブジェクトがアプリケーションによってす でにアクセスされているかどうかをキーにチェックさせる。もし対応付けオブジ ェクトがアプリケーションによってすでにアクセスされている場合には、キーは 、（そのアドレスがキーにおいてキャッシュされる）既存のオブジェクトを作り 出す。キー及び投手オブジェクトの一方又は両方がア プリケーションのメモリキャッシュの中に常駐している場合には、外部記憶マネ ージャ28は既存のオブジェクトをアプリケーション用のメモリの中に位置指定す るだけでよい。従って、キャッシュからそのオブジェクトアイデンティティー又 はキーを通じて要求データ/オブジェクトにアクセスすることによって、データ 記憶装置への冗長アクセス及びデータ複製に伴う問題が回避される。 第８図は、もし対応付けオブジェクトがアプリケーションによってまだアクセ スされていない場合には行われなければならない、オブジェクトをキーから構築 するプロセスを示している。キーは、オブジェクトを生成する必要性を示してい るメッセージを、キーを生成したタイプマップに送る。このメッセージによって 、タイプマップはキー及びタイプマップ情報をベースにした照会70を生成し、こ の照会70はRDBに向かい、対応付けオブジェクトを生成するために必要なデータ を集める。オブジェクトを生成するために集められるデータとしては、キーから のデータ、キー（第８図には示されていない）を作り出した源照会からキャッシ ュされたエキストラデータ、及び/又はRDB照会からのデータがある。集められた データは、OOPアプリケーションによって予想されるオブジェクトレイアウトに 従って定様式化され、タイプマップ情報の一部として貯蔵所の中に記憶される。 定様式化すべき情報は、あらゆる属性、及び構築されつつあるオブジェクトの タイプによって定義されるその他のオブジェクト（参照対象）のあらゆる参照を 初期化するのに十分なものでなければならない。属性の初期化は簡単であり、現 在のオブジェクト指向プログラミングシステム及びアクセスが行われている現在 のデータ記憶機構によって支援される数字及び文字列フォーマットの変動を説明 するだけでよい。 構築されつつあるオブジェクトの参照の初期化はもう少し複雑である。参照対 象オブジェクトを一意的に示すために、初期化はキーを構築する能力に依存して いる。参照対象のタイプマップは実際にそのようなキーを構築する。各々の参照 対象74のキーを構築するために、十分なデータが集められる。照会からのそのよ うな十分なデータ及び参照対象と対応付けられたタイプマップのキーレイアウト 情報を使用して、キーが構築される。参照対象のキーが一意であることが検証さ れる。もし一意ではない場合には、つまり、既存の複製が存在する場合には、キ ーは（現在構築中のオブジェクトのキーについて行われたのと全く同様に）直ち に削除され、それに続く操作において既存の複製と交換される。一意キーオブジ ェクト76のアドレスは、新しく構築されたオブジェクトに組み込まれる参照値の 基礎を形成する。 「投手」の例においては、「投手」オブジェクトは下記のように構築すること ができる。 １．name属性はキーのNAME文字列から設定される。 ２．player_number属性は、キーのNAME文字列値（ここでは...によって示され る）を使用する下記の照会によって検索されたデータから設定される。 ３．current_season_losses属性は、同様に、キーのNAME文字列値（ここでは. ..によって示される）を使用する下記の照会によって検索されたデータから設定 される。 ４．current_season_wins属性は、上記のステップ３における照会をベースに して設定される。 ５．plays_for参照は、対応データ（TEAM_NAME）がキーの中に形成される場合 を除いて、上記のステップ２における照会をベースにして設定される。 タイプ及びチーム用のタイプマップを貯蔵所から検索し、所定のTEAM_NAMEを 有するチームオブジェクトに対応するキーを要求しているそのタイプマップにメ ッセージを送ることによって、このキーは構築される。plays_for参照は、この キーのアドレスを使用して初期化される。 もしそのようなODBMS機能性が使用可能であり、その方が高い性能が得られる のであれば、技術としては周知であるが、上記の照会を単一JOIN照会に組み合わ せることもできる。これによって結果が変わることはない。さらに、キーを構築 するために源照会が実行された場合には、これらの照会によって検索されたデー タの一部又は全てを検索及びキャッシュすることもできる。これによってオブジ ェクトへの最初のアクセスの際の性能を高めることができるが、ただし、キー及 びオブジェクトがすでに存在しており、アプリケーションによるアクセスが行わ れている場合には、作業が複雑になり、使用されないデータが検索される可能性 がある。 全ての属性及び参照が初期化された状態で、キーは新しいオブジェクトのアド レス/ロケーションをキャッシュし、このアドレスを外部記憶マネージャに復帰 させる。 疑似コード行： ５． team the_team＝the_pitcher.plays_for； は、アプリケーション開発担当者が参照を通じて投手オブジェクトからチームオ ブジェクトへと横断することを意図していることを示している。 外部記憶マネージャは、参照がキーをベースにしており、キーの対応付けオブ ジェクトを作り出すメッセージをキーに送るのを検出する。 チームに対応する各々のキーにメッセージが初めて送られた時には、上記のよ うに、投手オブジェクトが構築されたのと類似の方式でチームオブジェクトを生 成するために、キーは照会を出す。（そのcurrent_season_losses属性がゼロで ある投手が複数同じチームにいたので）同じキーが後にそのメッセージを受け取 った場合には、キーは初めて検索されたチームオブジェクトのキャッシュされた アドレスを単に復帰させるだけである。チームキーからチームオブジェクトを構 築するプロセスは、第８図に関してすでに記述したように、投手オブジェクトを 構築するプロセスに類似している。 処理コード： は、I/O機能によってオブジェクトが印刷中であるという属性になる。この時点 では、オブジェクト属性は通常は外部記憶マネージャ機構によらないでオブジェ クト指向プログラミングシステムによってアクセスされる。 最後に、この例に関しては、トランザクションは下記のコードを通じて委託さ れる。 ７． commit_a_transaction（）． 最後のトランザクション開始後に行われたあらゆる変更がその他のトランザク ションに対してアトミックにアクセス可能になり、他のトランザクションによっ て行われたあらゆる変更がこのプロセスに対してアクセス可能になる。外部記憶 マネージャ機構はトランザクションの終了を記録し、そのトランザクションを委 託することを全ての（その他の）現在活動中の全てのデータ記憶機構に通知する 。RDBシステムと対応付けられている外部記憶マネージャは、RDBにアトミックに 影響を与えるために、“COMMIT TRANSACITON”ステートメントを発する。 例２ 外部記憶マネージャ機構は、アプリケーションによって行われたあらゆる更新 も記憶されたデータに反映させる。これは下記の例に示されているが、そこでは 、この図のRDB外部データ記憶装置の中で新しい投手が生成され、もう１人の投 手のチームが変更されている。 代表的な疑似コードは下記の通りである。 より詳細には、これらのステップは下記のように分類される。下記のコード： １． start_a transaction（）； は、例１と同じ効果を有している。さらに、例１と同様に、下記のコード： ２． query pitcher_query（“THE pitcher WITH name＝‘John Smi th’”）； は、上記のように、索引式照会を開始するために、ODBMS照会プロセッサを呼び 出す。 従って、特定のRDBデータが投手オブジェクトに関するデータを含んでおり、 名前に関する索引操作に参加していることを決定するために、外部記憶マネージ ャ機構26はその貯蔵所30に照会を行う。RDBと対応付けられている記憶マネージ ャオブジェクト28は貯蔵所から検索され、活動状態にされる。現索引照会に参加 するために、記憶マネージャオブジェクト28にはメッセージが送られる。このメ ッセージを囲んでいるプロトコルは、記憶マネージャ28がイテレータオブジェク トを参照することを予想している。このメッセージに対す る外部記憶マネージャ28の応答は、一般的には、照会に関連するタイプ（投手） を記録し、そのタイプに適したタイプマップを選択し、外部記憶マネージャイテ レータを作り出すことが予想されるタイプオブジェクトにメッセージを送るとい うものである。イテレータオブジェクトプロトコルは、記憶マネージャが何らか のメッセージを受け取った場合には、一連の数値が消耗されるまで、一連の連続 的数値を作り出すことを記憶マネージャに要求する。この場合には、照会（投手 オブジェクトの参照）の継時的結果を作り出すことがイテレータには予想されて いる。 関係型外部データ記憶装置22（RDB）と対応付けられている新たに活動状態に なった外部記憶マネージャ28は、アプリケーショントランザクションがすでに進 行中であることを検出する。応答として、この外部記憶マネージャ28は外部RDB との結合を確立し、“START TRANSACTION”コマンドをRDBに対して出し、RDBを 更新する。タイプマップオブジェクトは、対応付け記憶マネージャイテレータオ ブジェクトを参照することによって索引照会に参加するために、メッセージに応 答する。イテレータオブジェクトは、RDBへの照会に対応付けられるように構築 されており、一般的には、そのような照会のステータスと関連づけられた「照会 カーソル」を参照する。RDB照会の正確なフォーマットについては以下で検討す る。 下記のコード： ３． pitcher smith−he_next_result_from（pitcher_query）； は照会の単一結果にアクセスする。外部記憶マネージャ機構26は、照会に対する 応答としての結果を有していることを示したイテレータにメッセージを送る。こ のメッセージは、上記のように、イテレータに次の結果のキーを作り出させる。 外部記憶マネージャ機構26は、（これも上記のように）キーの対応付けオブジェ クトを作り出すために、第２のメッセージをキーに送る。 第１のメッセージへの応答として、イテレータ及び対応付けタイプマップオブ ジェクト46は、RDB照会カーソルから結果を抽出するために協力する。照会の形 態は、自ら及び投手オブジェクトを一意的に識別することができるキーを構築す るのに十分なデータを作り出すようなものである。これは、キーの対応付けオブ ジェクト及びPITCHERレコードのNAME文字列を生成する能力を有しているタイプ マップへの逆参照から構成されることになる。この例における照会は、下記のも のとすることができよう。 この照会の場合には、キーに関して要求されるデータが照会に送り込まれるデー タと同じであることから、照会は記述されたオブジェクトが存在することを確認 する役割を果たす。タイプマップはキーを構築し、それがアプリケーションによ って現在使用されているその他の全てのキーに関して一意であることをチェック する。もし一意ではない場合には、つまり、もし既存のキーの複製である場合に は、新しいキーは直ちに廃棄され、その場所ではそれが突き合わせを行った既存 のキーが使用される。キーの突き合わせは、メッセージをキーに送ることによっ て行われ、一意キーを構成しているものを決定する際の柔軟性を最大限に高める ことができる。この例においては、複製は、同じタイプマップ及びおなじNAME文 字列の参照を有するキーとして定義されることになる。一意キーは外部記憶マネ ージャ機構に戻される。 キーに送られるメッセージは、ステップ（又はコード行）４に関して例１に記 述されたのと同じ効果を有している。 索引照会を開始するために、照会プロセッサは下記のコードによって呼び出さ れる： ４． query team_query（“THE team WITH name＝‘Tigers’”）； 外部記憶マネージャ機構26は、投手データを処理するためにそれが活動化させ たものと同じ外部記憶マネージャもチームデータを記憶していることを決定する ために、その貯蔵所30に照会を行う。上記のように、照会結果を作り出すことが できるイテレータを作り出す現索引照会に参加するために、記憶マネージャオブ ジェクト28にはメッセージが送られる。 名前によってチームにアクセスするために要求される処理は、名前によって投 手にアクセするために使用されたものと同一であるが、ただし、照会に指定され たRDB表（PITCHER VS．TEAM）、並びに記憶され、オブジェクトに定様式化され た属性及び参照データの詳細は除くものとする。 照会の単一結果は下記のコードの実行時にアクセスされる： ５． team tigers＝the_next_result_from（team_query）； 処理は、投手照会に関してすでに検討されたものと同一である。外部記憶マネ ージャ機構26は、結果を有していることを示したイテレータにメッセージを送る 。このメッセージ は、イテレータに次の結果のキーを作り出させる。外部記憶マネージャ機構26は 、キーの対応付けオブジェクトを作り出すために、第２のメッセージをキーに送 る。 どの属性及び検索を初期化するためにどの表及び属性が照会されたかの詳細の 違いを除けば、この場合も処理は投手照会の場合と同じ構造に従う。 下記のコード： ６． smith plays_for＝tigers； の実行時に、投手スミスからそのチームまでのplays_for参照は、チームオブジ ェクト、タイガースを指し示すように設定される。いくつかのオブジェクト指向 データベースプログラミングシステムにおいては、トランザクションが委託され た場合にはシステムが記憶の中のオブジェクトの表示を再生するように、そのよ うな更新操作はオブジェクトを自動的にマークする。 この図のこの事例においては、外部記憶マネージャ機構26は、チームオブジェ クト、タイガースに対応付けられたキーのアドレスをベースにした値の参照を再 初期化する。 下記のコード： ７． store（the_pitcher）； は、第９図に示されているように、加えられた変更を反映するために、永続性記 憶の中の投手オブジェクトの表示を再生する。あらゆる更新オブジェクトを自動 的にマークするオブジェクト指向データベースプログラミングシステムにおいて は、このステートメントがアプリケーションプログラマによってコーディングさ れることはない。その代わりに、システムは各々の更新オブジェクトに関するこ の機能性をトランザクションを委託する（ステップ14以下）際の暗黙の第１ステ ップとして呼び出す。呼び出しが暗黙であれ明示的であれ、予想される機能性は 同じである。 外部記憶マネージャ機構26は、オブジェクトを構築するために使用される対応 付けデータ記憶機構の中のデータを再生するために、キー80に要求するオブジェ クトに対応付けられたキーにメッセージを送る。キーは、キー及びオブジェクト を生成したタイプマップ82にこのメッセージを送る。 タイプマップ82は、上記のように、オブジェクトを生成した変換の逆を適用す る。第９図に示されているように、オブジェクトの属性及び参照の中に記憶され た各々のデータ片は、データ記憶機構の中の対応するレコードを再生するために 使用しなければならない。投手オブジェクトの場合には、TEAM_NAME属性値を抽 出するためには、そのplays_for参照 のチームオブジェクト参照対象に対応付けられたキー84にアクセスしなければな らない。その他の属性値は投手オブジェクトの属性から抽出される。各々の“.. .”が投手オブジェクトから抽出された実属性値を表示しているところでは、結 果コマンドが実行されることになる。 その後、新しい投手オブジェクトが下記のコードの実行時に生成される： ８． pitcher the_rookie＝create_a_new_pitcher_amed“Jackie Jo nes”； 外部記憶マネージャ機構26はプロセスのこのステップでは呼び出す必要はない 。しかしながら、もしどのデータ記憶機構が新しいオブジェクトを記憶するのか に関して少しでも曖昧さがある場合には、システム又はアプリケーションがその 決定を行わなければならない。オブジェクトを初めて記憶又は参照する必要があ る場合には、この決定が役立つことになる。同じタイプのオブジェクトに関する データを記憶するシナリオ支援多重データ記憶機構における新しいオブジェクト の生成が、アプリケーション開発担当者が基礎となる記憶機構を意識しなければ ならない唯一のケースである。 新しいオブジェクトの様々な属性及び参照は下記のコード行によって初期化さ れる。 外部記憶マネージャ機構26は同様に単純属性アクセスには関与せず、単純属性 アクセスはアプリケーションプログラム及び/又は関連外部データ記憶装置に委 ねられている。外部記憶マネージャ機構は参照対象のキーのアドレスをベースに した参照を単に初期化するだ けである。 下記のコード： 13． store（the_rookie）； は、このオブジェクトに関するデータを外部データ記憶機構に書き込む役割を果 たす。上記のように、いくつかのシステムにおいては、このステップは、トラン ザクションを委託する第１ステップとして、ユーザーに代わってシステムによっ て、あらゆる更新オブジェクトに関して呼び出すことができる。その他のシステ ムにおいては、このステップは明示的ステップである。いずれのケースも、処理 は同じである。 外部記憶マネージャ機構26は、オブジェクトに対応付けられたキーがまだ存在 していないことを検出する。この機構は、オブジェクト及び（その目的データ記 憶機構用の）その目的外部記憶マネージャに対応するタイプマップにメッセージ を送ることによって、キーを構築する。オブジェクトを記憶するために、機構は メッセージをそのキーに送る。キーは、キーを生成したタイプマップにメッセー ジを送る。 タイプマップは、オブジェクトの固定属性をベースにした、この例では投手名 属性をベースにしたキーを構築する。タイプマップは、既存のオブジェクトデー タを再生するために使用されるものと類似の手順を使用して、新しいオブジェク トデータを記憶する。相違点は、データ記憶機構によって要求されるあらゆるデ ータについてデフォルト値を指定しなければならないかもしれないが、オブジェ クトモデルの中には相似形がないということにある。オブジェクトモデルの中に 表示される情報と外部データ記憶機構の中に表示される情報との間の緊密な通信 を維持することによって、この問題は時々は回避することができる。例えば、pl ay_for参照のキーから派生した投手属性及びTEAM_NAME値をベースにして、下記 の照会が発せられることになる： 最後のトランザクション開始後に行われたあらゆる変更がその他のトランザク ションに対してアトミックにアクセス可能にし、他のトランザクションによって 行われたあらゆる変更がこのプロセスに対してアクセス可能にするのは、下記の コードである。 14． commit_a_transaction（）； 外部記憶マネージャ機構はトランザクションの終了を記録し、そのトランザク ションを委託することを全ての現在活動中の全てのデータ記憶機構に通知する。 応答として、RDB用の外部記憶マネージャは、RDBに対して“COMMI TRANSACITON ”ステートメントを発する。 例３ オブジェクトデータベースから投手オブジェクトを取り除くためには、下記の プログラムが使用されることになる。 ステップ１〜３及び５は、例２に記述したものと同じ効果を有している。 下記のコード： ３． pitcher smith_the_next_result_from（pitcher_query）； はデータベースからオブジェクトを削除する。第10図に示されているように、外 部記憶マネージャ機構26はオブジェクトのキー90にメッセージを送る。キーはタ イプマップ92にそ のメッセージを送る。 タイプマップ92は、“...”によって表示されるキーの中のデータをベースに した下記のSQLコマンドを発する： 第10図に示されているように、これによって外部関係型データベースからのオ ブジェクトの削除が行われる。 発明による統合環境の上記の図示実現は、関係型パラダイムとオブジェクトパ ラダイムの間に柔軟性のあるインタフェースを実現することによって、外部関係 型データとODBMSとを効果的に統合する。 たしかに上記の図示実施例は、関係型データベースからのデータがオブジェク トアプリケーションにマッピングされる例を含んではいるが、発明により逆を効 果的に実現することができることと、発明により階層及びネットワークデータベ ース、単純データファイル、その他のオブジェクト指向データベース、又はこれ らのフォーマットの組み合わせを含めたその他のタイプの記憶機構にアクセスす ることができることが高く評価されるべきであろう。 さらに、上記の機能性は 、マッピングされた関係型データから生成されたオブジェクトの除去、RDBのコ ンテキストにおいてオブジェクト照会を実現するためのイテレータ及びRDB照会 カーソルの構築、関係型データからオブジェクトを構築するためのキーの構築、 オブジェクト及び関係型データの更新/変更を例証しているが、特に、すでに開 示された機能及びコンセプトを使用して追加的機能性を実現することができるこ とが高く評価されよう。 上記のように、たしかに技術としては周知のイテレータが特定の外部記憶マネ ージャと対応付けられて使用されてはいるが、発明による外部記憶管理を共通イ テレータプロトコル、又は特定のタイプの記憶マネージャをサーブするイテレー タによって実現することができることが高く評価されよう。 発明をその図示実施例との関連で説明及び記述してきたが、発明の精神及び範 囲を逸脱しない限りは、その形態及び詳細についての様々なその他の変更、省略 及び追加を行うこともできる。 付属書Ｉ オブジェクトハンドリングの実現 □ オブジェクトハンドリング支援 概要 クライアントアプリケーションは、それが使用する各OC_Object事例に記憶マ ネージャ事例を割り当てる。従って、低レベル記憶詳細をハンドリングするため に記憶マネージャに依存することができるので、アプリケーションはより高レベ ルでオブジェトをハンドリングするために解放される。より高いレベルでは、ど のオブジェクトが永続的に、どんな状態で、どの程度の期間記憶されるのかを決 定するために、アプリケーションはOC_Object及びOC_Referenceインタフェース を使用する。 OC_Objectの記憶マネージャは、オブジェクトの永続性アイデンティティー（ そのOID）、その永続性表示（現在記憶されているものとしてのそのデータ値） 、及びその永続性ロケーション（例えば、クラスタリング）をトラッキングする 。下記のマッピングについてもトラッキングを行う。 ・メモリ内オブジェクトとオブジェクト参照の間 ・永続性アイデンティティーとオブジェクト参照の間 ・永続性アイデンティティーとメモリ内オブジェクトの間 記憶マネージャは、どのようにしてオブジェクトがメモリと永続性記憶との間 で伝達されるかについても決定する。 オブジェクトとその記憶マネージャとの関係 オブジェクトハンドリング機能を適切に働かせるためには、これらの機能を、 オブジェクトを管理する記憶マネージャ事例について呼び出さなければならない 。 □ オブジェクトハンドリング機能 OC_StorageManagerのオブジェクトハンドリングインタフェースは、OC_Object のステータスを照会する機能を有している。さらに、オブジェクトのメモリ内状 態及び永続性状態を更新し、２つの状態の間で翻訳を行う機能も含んでいる。 非実現機能 これらのオブジェクトハンドリング機能は純粋仮想であり、従って、記憶管理 開発担当者によって実現されなければならない。 メモリ割り当て virtual void* allocateObj(long sz，OC_Type* theType， OC_Object* where，OC_Clustering howNear）； 新しいオブジェクトを割り当て、初期化する。オブジェクトのサイズをszによ ってバイトで指定し、そのOC_Type* をtheTypeによって指定する。 OC-StorageManagerの実現に応じて、クラスタリングオブジェクト及び近似性 をそれぞれ設定するために、allocateObj()はwhere及びhowNear引数を使用する ことがある。クラスタリング及びクラスタリングレベル（OC_defaultClustering 、OC_sameArea、及びOC_samaSegment）の解釈はOC_StorageManager実現従属性で あり、従って、allocateObj()はクラスタリング引数を必要に応じて使用するこ ともあるし、全く使用しないこともある。 OC_StorageManager資源が削除された場合には、この機能は例外OC_SystemLimi tationを申し立てる。このような資源の例が、固定サイズキャッシュを有する記 憶マネージャ用のメモリ内参照又はオブジェクトスペースである。 この機能はOC_Object::operator new()によって呼び出される。 virtual void deallocateObj(void* ent); OC_Objectベース事例である、*entによって使用されたメモリの割り当てを解 除する。 この機能はOC_Object::operator delete()によって呼び出される。 deallocateObj()の実現はallocateObj()の実現に対して相補的であるものとす る。例えば、もしallocateObj()が特定のプールからのメモリを割り当てる場合 には、deallocate Obj()はそれを同じプールに復帰させる ものとする。 オブジェクトステータス照会 virtual OC_Boolean isObjModified(Object* obj); もし*objが修正済みとマークされている場合には、OC_trueを復帰させる。も しそうではない場合には、OC_falseを復帰させる。以下のmarkObjModified()の 記述を参照。 もしオブジェクトの自己参照が妥当であると認識されていない場合には、isOb jModifiedはOC_NoSuchRef例外を申し立てる。 この純粋仮想機能はOC_Object::isModified()によって呼び出され、もしOC_En tityがOC_Objectである場合には、OC_Entity::isEntityModified()によって呼び 出される。 オブジェクト操作 virtual void putObj(OC_Object* obj); *objの現メモリ内状態をデータベースにおく。 もしオブジェクトの自己参照が妥当であると認識されていない場合には、putO bj()はOC_NoSuchRef例外を申し立てる。もしオブジェクトが永続的に削除された 場合には、putObj()はOC_ObjectWasDeleted例外を申し立てる。もし参照対象に 対するロックの獲得によってアプリケーションの現トランザクションが別のトラ ンザクションを待つことになる場合には、putObj()はOC_WaitException例外を申 し立てる。もし参照対象に対するロックの獲得によってトランザクションが放棄 される場合には、putObj()はOC_TransacitonWasAborted例外を申し立てる。もし putObj()がトランザクションの外側に呼び出される場合には、putObj()はOC_NoT ransaction例外を申し立てる。 変更が行われるトランザクション中には、putObj_()によってオブジェクトの 永続的状態に加えられる全ての変更はそのトランザクションのコンテキストの範 囲内においてのみ可視にされるものとすることに注意すること。もしトランザク ションへのチェックポイントの設定又はトランザクションの委託に成功した場合 には、変更を後続のトランザクションに対して可視にするものとする。もしトラ ンザクションが放棄された場合には、トランザクション中にオブジェクトの永続 的状態に加えられた全ての変更を廃棄するものとする。 virtual void deleteObj(OC_Object* obj); データベースから*objを削除する。 もし*objの自己参照値が妥当であると認識されていない場合には、deleteObj( )はOC_NoSuchRef例外を申し立てる。もし参照対象に対するロックの獲得によっ てアプリケーションの現トランザクションが別のトランザクションを待つことに なる場合には、deleteObj()はOC_WaitException例外を申し立てる。もし参照対 象に対するロックの獲得によってトランザクションが放棄される場合には、dele teObj()はOC_TransacitonWasAborted例外を申し立てる。 この機能はOC_Object::deleteObject()によって呼び出される。 virtual void destroyObj(OC_Object* obj); メモリからの割り当て解除のために*objを準備する。もしabortedがOC_trueに 設定されている場合には、destroy()が例外ハンドラ放棄の結果としてすでに呼 び出されている。このクラスのデストラクタから又は派生クラスのdestroy()機 能からを除いては、この方法は直接呼び出されないものとする。 この機能はOC_Object::destory()によって呼び出される。 virtual void markObjModified(OC_Object* obj); *objを修正済みとしてマークする。 この純粋仮想機能はOC_Object::markModified()によって呼び出される。任意 修正フラギングスキーマにおけるOC_Objectメンバ機能markModified()、unmarkM odified()、及びisModified()の使用に関する提案については、『レファレンス マニュアル』第Ｉ巻「クラスライブラリ」を参照。 virtual void unmarkObjModified(OC_Object* obj); 上記のmarkModified()によって、*objに関する修正フラグセットをアンセット する。 この機能はOC_Object::unmarkModified()によって呼び出される。 ヘルパ機能 これらの実現オブジェクトハンドリング機能は、記憶管理開発担当者によって 実現される機能によって呼び出すことができる。 オブジェクト活動化 OC_Object* defaultActivateObj(OC_Object* obj， OC_Type* theType，unsigned long objSelfRef); 初期化されてはいるが、非活動状態であるオブジェクトのためのメモリ位置指 定である、*objを活動化するために必要な最終的処理を行う。引数theTypeはオ ブジェクトについてのOC_Typeを指し示さなければならない。objSelfRef引数は 、活動化すべきオブジェクトについての自己参照でなければならない。 defaultActivateObj()によって行われる処理は、活動化コンストラクタラッパ 機能の位置指定及び呼び出し、利用可能なvtblを有していないOC_Typesの事例に ついてのvtblシミュレーション、及び記憶マネージャ及び*objについての自己参 照値の初期化を含んでいる。 この機能は通常はOC_StorageManager::getReferent()機能の終わり頃に呼び出 される。 ハッシュキー検索 virtual unsigned long getObjHashKey(OC_Object* obj); *objについてのハッシュキー値を発見、計算又は生成する。この値は、非配列 OC_Dictionary又はOC_Setのメンバのような集合体へのキーとしての働きを行う 場合に、オブジェクトをハッシュするために使用される。 この機能はOC_Object::getEntityHashKey()によって呼び出される。 もしgetObjHashKey()をリファインする場合には、下記の基本的ガイドライン に従うものとする。 ・getObjHashKey()は特定のオブジェクトについては常に同じ値を復帰させるも のとする。この要件はオブジェクトの寿命に関係する。 ・最高の性能を得るためには、多重オブジェクトがその下位ビットについての値 が同じハッシュキーを有する確率を最低にするものとする。その目的のために、 OC_Aggregateによってハッシュすべきn個のオブジェクトと対応付けられたハッ シュ値が、下記の式から結果の一様な分布を作り出すものとする。 mudulo 2^m ここに、mは下記の式が成り立つような最小の正の整数である。 2^m+3＞n ここに、nはハッシュキー値である。 エンティティー初期化 void initializeEntityPiece(OC_Entity* ent， unsigned long refVal); *entについての参照値をrefVal引数に設定し、*entの記憶マネージャをこれに 設定する。 この機能をallocateObj()及びgetReferent()の実現に使用することを希望する ことがあるかもしれない。しかしながら、initializeEntityPiece()の機能性を 含んでいることから、initializeInstance()及びdefaultActivateObj()の方がよ り役立つと感じるかもしれない。void initializelnstance(unsigned long refV alue， char* startOfInstance，OC_Type* entType); 生成又は活動化時のオブジェクトの中の全ての持ち越し及び組み込みオブジェ クトについての全ての自己参照値及び記憶マネージャ値を更新する。 この機能をOC_StorageManager::allocateObj()及びOC_StorageManager::getRe ferent()の実現に使用することを希望することがあるかもしれない。しかしなが ら、initialize Instance()の機能性を含んでいることから、defaultActivateOb j()の方がより役立つと感じるかもしれない。 OC_Primitiveメモリ割り当て virtual void* allocatePrim(long sz，OC_Type*theType， OC_Object* where，OC_Clustering howNear); OC_Primitiveについて割り当てるメモリにポインタを復帰させる。sz引数は割 り当てるべきバイト数であり、theTypeはオブジェクトのタイプである。where及 びhowNear引数はクラスタリングオブジェクト及び近似性をそれぞれ指定する。 この機能はOC_Primitive::operator new()によって呼び出される。 virtual void* deallocatePrim(void* prim); OC_Primitive又はOC_Primitiveオブジェクトの一部であるprimによって指し示 されたメモリを割り当て解除する。 この機能はOC_Primitive::operator delete()によって呼び出される。もしdea llocatePrim()をリファインする場合には、その実現がallocatePrim()の実現と の互換性を有することを確認すること。 参照ハンドリングの実現 □ 参照ハンドリング支援 概要 参照ハンドリングは最も重要な記憶管理特徴領域の１つである。この章におい ては、OC_Reference及びその参照対象が同じ記憶マネージャに属している基本的 参照ハンドリングについて説明する。第５章「SM間参照翻訳及びエクスポート」 においては、参照対象の記憶マネージャがOC_Referenceとは異なる記憶マネージ ャ間参照ハンドリングが取り扱われている。 メモリ内参照はメモリ内オブジェクト又は永続性オブジェクトのいずれかを参 照することができる。永続性検索は永続性オブジェクトしか参照することができ ない。 参照値 参照値及び自己参照値 OC_Entity派生クラスのあらゆる事例は、自己参照又はself refと呼ばれる特 性を有している。この特性は、クライアントキャッシュの持続期間中のそのメモ リ内状態において、それ自体へのエンティティーを識別する。あらゆるOC_Refer ence事例は、その参照値又はref valと呼ばれる類似の特性を有している。その 特性はクライアントキャッシュの持続期間中にOC-Referenceへの参照対象を識別 する。 あらゆるOC_StorageManager事例は、その記憶マネージャによって管理される 全てのエンティティーを表示する自己参照値のセットを初期化及び維持する。あ らゆるOC_StorageManager事例は、その記憶マネージャによって管理される全て のエンティティーを参照する参照値のセットも初期化及び維持する。 各OC_StorageManager事例は、その参照検索値を対応エンティティへのポイン タに翻訳し、及びクライアントキャッシュの持続期間中に参照検索対象へのこの 参照検索値のマッピン 及びクライアントキャッシュの持続期間中に参照検索対象へのこの参照検索値の マッピングを維持する方法について責任を負っている。 各記憶マネージャも、それが管理している各オブジェクトのステータスにその 参照値をマッピングする責任を負っている。そのようなOC_StorageManager照会 の結果を含めるために参照されるステータスは、isObjModified()及びisReferen tInDB()として機能する。 参照スペース 参照値及び自己参照値特性のいずれも32ビット（unsigned long）構造であり 、その中で８ビットはONTODS DB用に予約されており、24ビットは参照の記憶マ ネージャが使用することができる。参照値又は自己参照値の記憶マネージャ部は そのreference spaceと呼ばれ、エンティティーへのマッピングのために２²⁴（ 約1600万）種類の値を含むことができる。 第４−１図は参照値又は自己参照値構造を示したものである。 第４−１図 32ビット参照値（OC_Reference内）又は自己参照値（OC_Entity 内） 開発担当者派生OC_StorageManagerサブクラスの場合には、この構造はオブジ ェクトの永続性状態にも適用される。将来は、OC_StorageManagerは異なる方法 で永続性参照値を表示するかもしれない。 参照値の制御 記憶マネージャ内参照の場合には、永続性OC_Referenceについての参照値は、 （参照対象の記憶マネージャでもあるOC_Referenceの記憶マネージャによって制 御される。しかしながら、メモリ内OC_Referenceについての参照値は参照対象の 自己参照値と常に同じである。 記憶マネージャ間参照の場合の参照値の制御はこのスキーマとは若干異なって いる。第５章「SM間参照翻訳及びエクスポート」において、SM内検索と記憶マネ ージャ間参照との比較が行われている。 □ 参照ハンドリング機能 クラスOC_Referenceは、OC_Referenceを管理しているOC_StorageManagerサブ クラス事例に対応機能を呼び出すために実現される多数の機能を有している。OC _StorageManagerの基本的参照ハンドリング機能は、OC_Referenceの参照対象の ステータスを照会する機能、及びOC_Reference又はその参照対象のステータスを 変更するための操作機能を含んでいる。 非実現機能 全ての参照ハンドリングメンバ機能は、OC_StorageManagerに関しては純粋仮 想であると定義され、従って、記憶管理開発担当者は、その任様に従って、いず れかのサブクラスから参照ハンドリングメンバ機能を実現しなければならない。 参照対象ステータス照会 virtual OC_Boolean isReferentActive(OC_Reference* ref); もし*refの参照対象が活動中である場合には、OC_trueを復帰させる。もしそ うではない場合には、OC_falseを復帰させる。もし参照値が妥当であると認識さ れていない場合には、isReferentActive()はOC_NoSuchRef例外を申し立てる。 この機能はOC_Reference::isActive()及びOC_Reference::getActiveReferent( )によって呼び出される。 virtual OC_Boolean isReferentDeleted(OC_Reference* ref); もしオブジェクトが永続的に削除された場合には、OC_trueを復帰させる。も しそうではない場合には、OC_falseを復帰させる。もし参照値が妥当であると認 識されていない場合には、isReferentDeleted()はOC_NoSuchRef例外を申し立て る。 この機能はOC_Reference::isDeleted()及びOC_Object::isDeleted()によって 呼び出され、もし事例がOC_Objectである場合には、OC_Entity::isEntityDelete d()によって呼び出される。 virtual OC_Boolean isReferentInDB(OC_Reference* ref); もし*refの参照対象がすでにデータベースに置かれている（しかも、永続的に 削除されていない）場合には、OC_trueを復帰させる。もしそうではない場合に は、OC_falseを復帰さ せる。もし参照値が妥当であると認識されていない場合には、isReferentInDB() はOC_NoSuchRef例外を申し立てる。 この機能はOC_Reference::isInDB()及びOC-Object::isObjectInDB()によって 呼び出され、もし事例がOC_Objectである場合には、OC_Entity::isEntityNew() に呼び出される。 virtual OC-Boolean isReferentNew(OC_Reference* ref); もし*refの参照対象が現キャッシュ内に生成されている（しかも、永続的に削 除されていない）場合には、OC_trueを復帰させる。もしそうではない場合には 、OC_falseを復帰させる。もし参照値が妥当であると認識されていない場合には 、isReferentNew()はOC_NoSuchRef例外を申し立てる。 この機能はOC_Reference::isNew()及びOC_Object::isObjectNew()によって呼 び出され、もし事例がOC-Objectである場合には、OC_Entity::isEntityNew()に 呼び出される。 参照対象検索機能 virtual OC_Entity* getReferent(OC_Reference* ref， OC_LockType lock); 参照対象が現在活動中であるかどうかにかかわらず、*refの参照対象を示すポ インタを復帰させる。もし必要な場合には、getReferent()が参照対象を活動化 し、ロックタイプlockによってロックする。 下記の表は、getReferent()によって申し立てられることがある例外、及び例 外申し立ての条件を示したものである。 この機能はOC_Reference::getReferent()によって呼び出される。 virtual OC_Entity* getReferentIfActive(OC_Reference* ref); もし*refが活動中である参照対象を有してる場合には、*refの参照対象を示す ポインタを復帰させる。もしそうではない場合には、0を復帰させる。もし参照 値が妥当であると認識されていない場合には、isReferentIfActive()はOC_NoSuc hRef例外を申し立てる。 この機能は、isReferentModified()、getReferentIfActive()及びgetActicveR eferentのようなOC_Referenceメンバ機能によって呼び出される。 ロック機能 virtual OC_LockType getReferentLockType( OC_Reference* ref); ref*のロックタイプを復帰させる。もし参照値が妥当であると認識されていな い場合には、getReferentLockType()はOC_NoSuchRef例外を申し立てる。 この純粋仮想機能はOC_Reference:getReferentLockType()及びOC_Object::get LockType()によって呼び出され、もし事例がOC_Objectである場合には、OC_Enti ty::getEntityLockType()によって呼び出される。 virtual OC_LockType getReferentLockType(OC_Reference* ref, OC_LockType lock); *refの検査対象に対するOC_LockType lockのロックを獲得又は更新する。もし 参照値が妥当であると認識されていない場合には、lockReferent()はOC_NoSuchR ef例外を申し立てる。 この機能はOC_Reference:lockReferent及びOC_Object::lockObject()によって 呼び出され、もし事例がOC_Objectである場合には、OC_Entity::lockEntityによ って呼び出される。 参照操作機能 virtual void discardReference(OC_Reference* ref, OC_Boolean persistently); *refの参照値を廃棄し、0に設定する。OC_Trueのpersistently引数のパスによ って、discardReference()が参照対象に対する全ての永続性参照と対応付けられ ている全てのリソースを解放する。参照対象に対する全てのメモリ内参照と対応 付けられている全てのリソースは、persistently引数とは無関係に解放される。 もし参照値が妥当であると認識されていない場合には、discardReferent()はO C_NoSuchRef例外を申し立てる。 discardReference()機能は、いずれかのOC_Referenceが今後使用することのな い参照値について以外には呼び出してはならないものとする。もし参照が外向き である（つまり、参照対象の記憶マネージャがOC_Referenceと異なっている）場 合には、discardReference()は、参照の記憶マネージャによって使用される参照 値を廃棄する前に、参照対象の記憶マネージャによって使用される参照値を廃棄 する。 もし参照対象が割り当て解除又は永続的に削除された後にアプリケーションが この機能を呼び出さない場合には、記憶マネージャは参照値と参照対象との対応 付けを続ける。このデフォルト挙動は、いずれかの他のオブジェクトについての 参照値の再使用を防止することによって、ダングリングで曖昧な参照を防止する 。この挙動の１つの欠点は、もはや使用されることのない参照値についての支援 を維持するためにオーバヘッドが必要なことである。もう１つの欠点は、貯蔵マ ネージャ当たりキャッシュ期間当たり参照対象が２²⁴（約1600万）という制限が あることである。現参照値がもはや使用されていないことを記憶マネージャに知 らせることによって、discardReference()の呼び出しがこれらの欠点を解消し、 参照値の24ビット参照スペース部の再使用を可能にする。 この機能はOC_Reference::discardValue()によって呼び出される。 注意：アプリケーションが後に使用するかもしれない別のOC_Referenceと同じ値 を有する*ref引数付きdiscardReference()を呼び出さないように注意すること。 ヘルパ機能 これらの実現ヘルパ機能は、記憶マネージャ開発担当者によって実現される機 能によって呼び出すことができる。 自己参照値検索 static unsigned long getEntSelfRefValue(OC_Entity* ent); *entの自己参照値を復帰させる。自己参照値は、記憶マネージャによって定義 及び維持されるデータ構造に対するキーとして役立つので、記憶マネージャ開発 担当者はこの機能をOC_Object及びOC_Reference関連照会及び更新機能の中で使 用することができる。 参照対象検索 virtual OVC_Argument getReferentAsArgument( OC_Reference* ref); *refの参照対象をOC_Argumentとして復帰させる。もし参照対象がtype char* 又はintとして記憶されている場合には、復帰させられたOC_Argumentはその値に よって直接初期化される。 この関数の目的は、OC_Primitive派生クラスのオーバヘッドなしで、参照値を OC_Argumentに変換することにある。 下記の表は、getReferentAsArgument()によって申し立てられることがある例 外、及び例外申し立ての条件を示したものである。 ＳＭ間参照翻訳及びエクスポートの実現 □ ＳＭ間参照翻訳及びエクスポート支援 概要 あらゆる記憶マネージャは、その他の記憶マネージャの制御の下にある永続性 及び非永続性OC_Referenceを自らの参照スペースに翻訳することができなければ ならない。記憶マネージャは、自らのオブジェクト及びその他の記憶マネージャ の制御の下にあるオブジェクトに対するOC_Referenceのエキスポートのハンドリ ングも行わなければならない。 OC_StorageManagerについて定義された記憶マネージャ間参照翻訳及びエクス ポート機能は、異なる記憶マネージャによって制御されるオブジェクトが相互に 参照を行うことを可能にする。この参照翻訳及びエクスポートインタフェースが ない場合には、物理的データベース当たり１つの記憶マネージャ事例しか使用す ることができない。 ＳＭ間参照用の参照値 第４章「参照ハンドリングの実現」は32ビット参照値構造を記述したものであ る。この構造は記憶マネージャ間参照値にも使用される。 しかしながら、参照がメモリ内であろうと永続性であろうと、記憶マネージャ 間参照用の参照値は常にOC_Referenceのマネージャによって制御される。記憶マ ネージャ内参照の場合には、永続性OC_Reference用の参照値も（参照対象の記憶 マネージャでもある）OC_Referenceの記憶マネージャによって制御されるが、し かしメモリ内OC_Reference用の参照値は参照対象の自己参照値と常に同じである ことを忘れないこと。 ＳＭ間参照の分解 記憶マネージャ間参照の分解は、１つ以上のその他の記憶マネージャによって すでに翻 訳されている参照の分解を簡単にする２階層アーキテクチャをベースにしている 。その他の記憶マネージャの参照スペースへの介入翻訳がいかに数多く行われて いたとしても、２階層アーキテクチャによって、参照を与えられた記憶マネージ ャは参照対象の源参照値及びその記憶マネージャもアイデンティティーのレコー ドも受け取る。 □ ＳＭ間翻訳及びエクスポート機能 OC_StorageManagerの記憶マネージャ間索引翻訳インタフェースは、その他の 記憶マネージャ事例によってハンドリングされるオブジェクトに対するOC_Refer enceを翻訳し、その他の記憶マネージャ事例にOC_Referenceをエクスポートする 機能を有している。 非実現機能 これらの記憶マネージャ間参照翻訳/エクスポート機能は純粋仮想であり、従 って、記憶管理開発担当者によって実現されなければならない。 virtual unsigned long translateRefValue( Oc_Entity* referent); これとは別の記憶マネージャに所属する*referentについてのメモリ内参照値 を復帰させる。 translateRefValue()の呼び出しの後には、OC_StorageManagerはtranslateRef Value()復帰を外向き参照として、つまり、別の記憶マネージャの制御の下にあ るOC_Entityとしての*referentへの参照として認識する。 参照値が、参照を始める記憶マネージャ及び*referentの自己参照値をコード 化することに注意すること。 その結果として、translateRefValue()実現は、特定の時点に存在している記 憶マネージャから独立している。 参照対象の記憶マネージャがOC_Referenceと異なっている場合には、この機能 はOC_Reference::reset()、OC_Reference::init及びOC_Referenceコンストラク タによって呼び出される。 外向き参照であるか、又は別の記憶マネージャによって翻訳され、この記憶マ ネージャに戻された、この記憶マネージャから始めれた参照である参照値を復帰 させる。oldRefValue引数は翻訳のための参照値である。oldContext引数はoldRe fValue（oldContextをこれとすることができる）についての記憶マネージャを指 し示す。 もしoldRefValue値が*oldContextのコンテキストにおいて妥当であると認識さ れていない場合には、translateRefValueはOC_NoSuchRef例外を申し立てる。 参照値が参照を始める記憶マネージャ及びoldRefValueをコード化すべきこと に注意すること。その結果として、translateRefValue()実現は、特定の時点に 存在している記憶マネージャから独立している。 *oldContextがOC_Referenceの記憶マネージャと異なっている場合には、この 機能はOC_Reference::reset()、OC_Reference::init及びOC_Referenceコンスト ラクタによって呼び出される。 virtual OC_Boolean compareReferences(OC_Reference* rl, OC_Reference* r2);もしr1及びr2が同じ又は等しい参照対象を有している場 合には、OC_Trueを復帰させる。もしそうではない場合には、OC_falseを復帰さ せる。もしいずれかの参照対象の値が妥当ではない場合には、compareReference ()はOC_NoSuchRef例外を申し立てる。 この機能はOC_Reference::compare()によって呼び出される。 ヘルパ機能 これらの実現記憶マネージャ間参照翻訳/エクスポート機能は、大部分のOC_St orage Magagerベースサブクラスに共通である複雑な処理を行う。これらの機能 は上記の機能を実現するために使用することができる。 参照値を、それを始めた記憶マネージャに対応付けられた形態に翻訳する。参 照はこの記憶マネージャによって管理されるが、多くの参照はすでに別の記憶マ ネージャによって管理されている。参照値をsimpleRefValue引数としてパスし、 この記憶マネージャを指し示す（これに割り当てられた）ポインタをsimpleSMと してパスする。もし参照値が別の記憶マネージャによって始められた場合には、 関数はOC_Trueを復帰させる。その場合には、関数は親記憶マネージャを指し示 すポインタをsimpleSMの中に復帰させ、単純化差参照値を（パスされた同じ値と 一致することがある）simpleRefValueの中に復帰させる。 注：下記の３つの機能はまだ使用に供することができない。完璧を期するために 、ここに記載されたものである。 この機能はONTOS DB Release3.1によっては利用することができない。記憶マ ネージャ*referenceによって、メモリ内参照値refValueを永続性参照toBeSetに 翻訳することが指定されている。 この機能はONTOS DB Release3.1によっては利用することができない。もしrep lace PersistentReference()がすでに無条件にoldValueをnewValueと交換してい る場合には、OC_Trueを復帰させることが指定されている。owner引数は、oldVal ue及びnewValue両用の記憶マネージャを指し示している。 この機能はONTOS DB Release3.1によっては利用することができない。永続性 参照 toBeResolvedと同じ参照対象については、記憶マネージャ*referencerによって 管理されるメモリ内参照の参照値を復帰させることが指定されている。 繰り返し及び索引付けの実現 □ 繰り返し及び索引付け支援 概要 あらゆるOC_StorageManagerサブクラスは、拡張子を有するOC_Typeの事例及び 索引付き特性を有するOC_Typeの事例としてオブジェクトを処理するための支援 を行う。拡張子及び索引付き特性の詳細については、『開発担当者ガイド』、及 び『レファレンスマニュアル』第１巻「クラスライブラリ」のOC_Property及びO C_Typeクラスのエンティティーを参照。 記憶管理開発担当者は、繰り返し及び索引付け効率をOC_StandardSM及びOC_Gr oupクラスによって得られるものよりも高くするために、OC-StorageManager機能 を実現する。この節には、副拡張子及び副索引の２つの支援特徴、及びその使用 法が記述されている。この節では、共通及び特殊化副拡張子及び索引を含んだ操 作に対する記憶管理支援の提供についても検討される。 完全性及び一意性 拡張子及び索引の繰り返しの完全性 現開論理データベースの中に存在しない記憶マネージャ付きオブジェクトは、 その拡張子及び索引の繰り返しには参加しない。従って、処理をあるタイプの全 ての事例に拡張するためには、単一論理データベースの中に全てのそれらの事例 及びその記憶マネージャを記憶しなければならない。 索引付き特性についての限定的大域一意性 現開論理データベースの中に存在しない記憶マネージャ付きオブジェクトは、 その索引の繰り返しには参加しないので、索引付き特性についての値の一意性は 、現開論理データベースの中に存在する記憶マネージャに所属しているオブジェ クトに対してだけしか保証 されない。この結果は「限定的大域一意性」と呼ばれる。 記憶マネージャを含んでいる領域が現データベースに追加された場合には、追 加された領域内の１つ以上のオブジェクトが、すでにデータベースの中に存在す る値の複製である値を有している可能性がある。この複製は、一意であると定義 されたこれらの特性についての一意性制約条件を犯すことになる。 複製は度々行われるわけではないので、ONTOS DBは楽観的アプローチを採用し 、条件の検出及び修正はアプリケーションに委ねている。もしそのような複製が アプリケーションにとって有害である場合には、アプリケーションは、問題が起 こった場合にはそれを検出し、修正するコードを含んでいるものとする。下記の 例はそのようなコードの基礎として提案されている。 副拡張子特徴 共通及び特殊化副拡張子 ONTOS DBは各拡張子を、単一記憶マネージャに所属するオブジェクトからなる 副拡張子に分割する。副拡張子特徴は記憶管理開発担当者が特定の記憶管理マネ ージャについて「特殊化副拡張子」処理」行うことを可能にする。多くの記憶マ ネージャは、ONTOS DBによって供給されるデフォルトである「共通副拡張子」実 現によってきちんとサーブされる。しかしながら、特定にカスタム記憶マネージ ャの場合には、特殊化副拡張子の方がより正確な結果及び優れた性能が得られる かもしれない。 注：もし直接タイプが拡張子を有している場合には、ある事例はその直接タイプ に関してたった１つの副拡張子（共通又は特殊化）のメンバにしかなることがで きない。その事例は、拡張子を有しているその直接タイプのスーパータイプの各 々に関してもたった１つの副拡張子のメンバにしかなることができない。 特殊化副拡張子を使用すべき時期 単一操作として多くのオブジェクトにアクセスする記憶マネージャの場合には 、カスタムイテレータが有利なことがある。例えば、短期間の内に要求されそう な多数のオブジェクトを識別し、その全てに直ちにアクセスする特殊化機能を支 援する記憶マネージャを考えてみよう。その記憶マネージャの副拡張子の繰り返 しは、１度に１つずつアクセスするために個々のオブジェクトへの参照を使用す るデフォルト繰り返しよりは高速になる。 特殊化副拡張子の実現 特殊化副拡張子を実現するためには、イテレータクラスをクラスOC_Iterator から派生させなければならない。各々の副拡張子について記憶マネージャに所属 するオブジェクトを最も効果的に繰り返すためには、クラスメンバ機能を実現す る。さらに、記憶マネージャについてgetIterator()機能（３つのシグナチュア ）を実現する。そうすれば、各々が特殊化イテレータクラスの事例を指し示すポ インタを復帰させる。 実現の結果、アプリケーションが、タイプの拡張子を繰り返すために、OC_Typ e::getIterator()によって復帰させられたイテレータを使用した場合には、ONTO S DBは各々の副拡張子について記憶マネージャにgetIterator()を呼び出す。そ の記憶マネージャに所属するオブジェクトを与えるために、ONTOS DBは復帰イテ レータを使用する。 新しいオブジェクト用の一時的副拡張子 ONTOS DBは、所属している記憶マネージャとは無関係に、新しく生成された非 保管オブジェクトを自動的に含む特殊な一時的副拡張子も定義する。拡張子の繰 り返しは一時的副拡張子の繰り返しを含んでいる。 一時的副拡張子は全ての新しいオブジェクトを含んでいるので、新しいオブジ ェクトを排除するためには全ての特殊化副拡張子を実現するものとする。 副索引特徴 記述 特性索引は、それぞれ異なる記憶マネージャ事例によって管理される副索引に 分割することができる。異なる記憶マネージャ及びそのオブジェクトは異なるデ ータベース領域に記憶することができるので、副索引付けは、現論理データベー スの中の領域の中に記憶されているオブジェクトに対する繰り返しによるアクセ スを制限を支援する。 副索引特徴は記憶管理開発担当者が特定の記憶管理マネージャについて「特殊 化副索引」処理を行うことを可能にする。多くの記憶マネージャは、ONTOS DBに よって供給されるデフォルトである「共通副素引」実現によってきちんとサーブ される。しかしながら、特定にカスタム記憶マネージャの場合には、特殊化副索 引の方がより正確な結果及び優れた性能が得られるかもしれない。 注：もしOC_Typeの事例が索引を有している場合には、タイプの索引付き特性の 各々についての索引当たりたった１つの副拡張子（共通又は特殊化）のメンバで あるものとする。 特殊化副索引の実現 特殊化副索引を実現するためには、イテレータクラスをクラスOC_Iteratorか ら派生させなければならない。副索引について記憶マネージャに所属するオブジ ェクトを最も効果的に繰り返すためには、クラスメンバ機能を実現する。さらに 、記憶マネージャについてgetIterator()機能（３つのシグナチュア）を実現す る。そうすれば、各々が特殊化イテレータクラスの事例を指し示すポインタを復 帰させる。 実現の結果、アプリケーションが、タイプの副索引を繰り返すために、OC_Typ e::get Iterator()によって復帰させられたイテレータを使用した場合には、ONT OS DBは各々の副索引について記憶マネージャにgetIterator()を呼び出す。その 記憶マネージャに所属するオブジェクトを与えるために、ONTOS DBは復帰イテレ ータを使用する。 共通副拡張子及び共通副索引による操作 全ての副拡張子又は全ての副索引に特殊化副拡張子を供給するわけでなはない 記憶マネージャは、共通副拡張子又は共通副索引をそれぞれ取り扱ういくつかの 操作を支援しなければならない。OC_StorageManagerは、次の節に記述されてい る、これらの操作用のヘルパ 機能を定義する。 記憶マネージャは、事例が生成された場合には、要求通りに、事例を共通副拡 張子及び共通副索引に追加し、データベースに置かれた場合には、事例の索引を 更新する責任を負っている。記憶マネージャは、事例が削除された場合には、そ の事例を拡張子及び索引から取り除く義務も負っている。これらの操作を支援す るために、OC_StorageManagerは、「共通副拡張子メンバシップ」及び「共通副 索引メンバシップ」に記述されているヘルパ機能を有している。 これらは、事例を共通副拡張子及び共通副索引に追加し、事例を拡張子及び索 引から取り除く相補ヘルパ機能の対である。 拡張子の場合には、対の中の一方の機能は所定のタイプにだけ適用され、他方 の機能は所定のオブジェクトの直接タイプ及びそのタイプのスーパータイプに適 用される。もし記憶マネージャがオブジェクトのタイプ階層の中の１つ以上にタ イプについて特殊化副拡張子を使用していない場合には、これらの機能対の各々 の中の第２のバリアントを使用するものとする。 相補拡張子関連ヘルパ機能の対の例がaddToCommonExtension()及びaddToAllCo mmon Extension()である。addToCommonExtension()機能は所定のタイプについて の拡張子にだけ事例を追加する。addToAllCommonExtension()機能は直接タイプ の共通副拡張子及び全てのタイプのスーパータイプについての共通副拡張子に事 例を追加する。 索引の場合には、追加又は除去機能の一方のバリエーションは所定の索引付き 特性（例えば、addToCommonIndex()）だけに影響を与え、他方のバリエーション は全ての索引付き特性（例えば、addToAllCommonIndex()に影響を与える。 副拡張子及び副索引の繰り返し OC_StorageManagerは、次の節に記述されている多数のヘルパ機能を通じて、 副拡張子及び副索引の繰り返しへの参加を取り扱う操作を支援する。 効率のために、OC_IndexIterator機能は、副拡張子又は副索引の繰り返しへの 参加者として使用可能にされる記憶マネージャにだけ呼び出される。大部分の記 憶マネージャは、生成又は活動化された場合には、要求通りに、特殊化繰り返し への参加者として利用可能にされる。削除された場合には、参加者として使用不 能にされるものとする。「副拡張子 繰り返し参加」及び「副索引繰り返し参加」の項に記述されている非実現機能は 、副拡張子繰り返しび副索引繰り返しへの参加を使用可能及び使用不能にするた めにそれぞれ実現されなければならない。これらの項には、記憶マネージャが繰 り返しへの参加者であるかどうかを決定するためのONTOS DBについての照会機能 も記述されている。 □ 繰り返し及び索引付け機能 非実現機能 これらの繰り返し及び索引付け機能は純粋仮想であり、従って、記憶管理開発 担当者によって実現されなければならない。 イテレータ検索 virtual OC_Iterator* getIterator(OC_Type* theType, OC_LockType lock); この記憶マネージャの*theTypeの拡張子の副拡張子についてのOC_Iteratorを 指し示すポインタを復帰させる。繰り返しによって活動化される事例についての ロックタイプを指定するためには、lock引数を使用する。 この記憶マネージャの*theTypeに関する特性*thePropの副索引についてのOC_I teratorを復帰させる。第１のオーバロードのために、復帰イテレータは、value の値に等しい特性値を有する事例を発生させる。第２のオーバロードのために、 復帰イテレータは、start及びendによって指定された範囲内の特性値を有する事 例を発生させる。３つのgetIterator()オーバロードの最後のために、OC_trueの yieldInOrder引数は、復帰イテレータが事例を *propについての昇順値の形で発生させることを指定する。yieldInOrderをOC_fa lseに設定することは、発生順が未定であることを意味している。lockタイプは 、繰り返しによって活動化される事例についてのロックタイプを指定する。 ３つのgetIterator()機能はOC_InstanceIteratorメンバ機能によって呼び出さ れる。この３つのgetIterator()機能は、指定されたOC_Type又はOC_Propertyに ついての繰り返し又は索引参加者としてそれぞれ使用可能にされている記憶マネ ージャにだけ呼び出される。このスキーマは、参加者として使用可能にされてい ない記憶マネージャが指定されたOC_Typeの事例を有していないか、又はOC_Type についての共通副拡張子及び索引に全ての事例をすでに追加しているという仮定 をベースにしている。 事例カウント照会 virtual unsigned long getInstanceCount(OC_Type* theType); もし特殊化副拡張子を使用する場合には、この記憶マネージャに所属する*the Typeの事例の近似カウントを復帰させる。もし*theTypeもそのスーパータイプの いずれも拡張子を有していないか、又はこの記憶マネージャが共通副拡張子を使 用する場合には、getInstanceCount()は0を復帰させる。 この機能は、OC_Type::numInstance()によって、OC_Typeについての繰り返し 参加者として使用可能にされている記憶マネージャにだけ呼び出される。 ヘルパ機能 これらの実現繰り返し及び索引付け機能は、大部分のOC_StorageManagerベー スクラスに共通である複雑な処理を実行する。これらの機能はオブジェクト操作 を実現するために使用することができる。 共通副拡張子メンバシップ static void addToCommonExtension(OC_Type* theType, OC_Object* theObj); *theTypeについての共通副拡張子に*theObjを追加する。 static void addToAllCommonExtension(OC_Object* theObj); その直接タイプの共通副拡張子及び全てのOC_Typeのスーパータイプについて の共通副拡張子に*theObjを追加する。 static void removeFromCommonExtension(OC_Type* theType, OC_Object* theObj); *theTypeについての共通副拡張子から*theObjを除去する。 static void removeFromAllCommonExtension(OC_Object* theObj); その直接タイプの共通副拡張子及び全てのOC_Typeのスーパータイプについて の共通副拡張子から*theObjを除去する。 共通副索引メンバシップ static void addToCommonIndex(OC_Type* theType, OC_Property* theProp，OC_Object* theObj): *索引付き特性*thePropについての共通副索引に*theObjを追加する。*theType 引数は無視される。 static void addToAllCommonIndexes(OC_Object* theObj); *theObjついての全ての索引付き特性についての全ての共通副索引に*theObjを 追加する。 static void removeFromCommonIndex(OC_Type* theType, OC_Object* theObj); *theTypeについての共通副拡張子から*theObjを除去する。*theType引数は無 視される。 static void removeFromAllCommonIndexes(OC_Object* theObj); theObjついての全ての索引付き特性についての全ての共通副索引から*theObj を除去する。 static void updateCommonIndex(OC_Type* theType, OC_Property* theProp，OC_Object* theObj); 索引付き特性*thePropについての共通副索引の中の*objを更新する。更新には 、現索引エンティティーの追加、及びもはや使用されないエンティティーの除去 が含まれる。*theType引数は無視される。 static void updateAllCommonIndexes(OC_Object* theObj); *Obj_についての全ての索引付き特性についての全ての共通副索引の中の*obj を更新する。更新には、現索引エンティティーの追加、及びもはや使用されない エンティティーの除去が含まれる。*theType引数は無視される。 static void checkAllIndexes(OC_Object* theObj); *Objに関する全ての一意性特性についての索引の一意性をチェックする。もし checkAllIndexes()が非一意値を発見しなかった場合には、OC_NotUnique例外を 申し立てる。 副拡張子繰り返し参加 OC_Boolean isIterationParticipant(OC_Type* theType); もしこの記憶マネージャが*theTypeについての副拡張子繰り返しへの参加者で ある場合には、OC_Trueを復帰させる。もしそうではない場合には、OC_falseを 復帰させる。OC_InstanceIterator機能は、繰り返し参加者として使用可能にさ れている記憶マネージャにだけOC_StorageManager::getlterator()機能を呼び出 す。 OC_Boolean enableIterationParticipation(OC_Type* theType); *theTypeについての副拡張子繰り返しへの参加者としてこの記憶マネージャを 使用可能にする。効率のために、OC_InstanceIterator機能は、繰り返しへの参 加者として使用可能にされる記憶マネージャにだけOC_StorageManager::getIter ator()機能を呼び出す。 OC_Boolean disableIterationParticipation(OC_Type* theType); *theTypeについての副拡張子繰り返しへの参加者としてこの記憶マネージャを 使用不能にする。OC_InstanceIterator機能は、繰り返しへの参加者として使用 可能にされる記憶マネージャにだけOC_StorageManager::getIterator()機能を呼 び出す。 副索引繰り返し参加 OC_Boolean isIndexParticipant(OC_Type* theType); もしこの記憶マネージャがタイプ*theTypeに関する特性*Propについての特殊 化副索引の繰り返しへの参加者である場合には、OC_Trueを復帰させる。もしそ うではない場合には、OC_falseを復帰させる。 OC_IndexIterator機能は、特性についての特殊化副索引の繰り返し参加者とし て使用可能にされている記憶マネージャにだけOC_StorageManager::getIterator ()機能を呼び出す。 void enableIndexParticipation(OC_Type* theType, OC_Property* theProp，OC_Boolean ordered, OC_Boolean isUnique): タイプ*theTypeに関する特性*Propについての特殊化副索引の繰り返しへの参 加者として この記憶マネージャを使用可能にする。もし*Propが索引を有していない場合に は、enableIndexParticipation()が索引を生成し、orderedがOC_trueである場合 には配列し、isUniqueがOC_trueである場合には一意にする。 この記憶マネージャが特殊化副索引を実現する各々の特性についてのenableIn dexParticipation()を呼び出す。 void disableIndexParticipation(OC_Type* theType, OC_Property* theProp); タイプ*theTypeに関する特性*Propについての特殊化副索引の繰り返しへの参 加者としてこの記憶マネージャを使用不能にする。 トランザクション及びキャッシュハンドリングの実現 □ トランザクション及びキャッシュハンドリング支援 概要 あらゆるOC_StorageManagerサブクラスは、トランザクション及びキャッシュ ハンドリングが行われる前後に行う必要がある処理を提供しなければならない。 記憶マネージャ開発担当者は、もしあれば、記憶マネージャのトランザクション 及びキャッシュハンドリング機能を実行する必要があるというタスクを識別する 責任を負っている。 並行オブジェクトＩＤ割り当て 並行アプリケーションによって同時オブジェクト生成を支援する必要があるサ イトにおいては、オブジェクトID(OID)の割り当てを管理するために、アプリケ ーションはOC_OIDSpaceオブジェクトを生成し、使用しなければならない。OC_OI DSpaceクラスは複製の危険のないOIDの並行割り当てを可能にする。 クラスOC_OIDSpaceは『レファレンスマニュアル』第１巻「クラスライブラリ 」に記載されている。このマニュアルに述べられているように、アプリケーショ ンはOC_instantUpdateLockのOC_LockTypeによってOC_OIDSpaceを活動化しなけれ ばならない。アプリケーションは使用の直後にOC_OIDSpaceにputObject()も呼び 出さなければならない。 記憶マネージャ割り当て解除 管理しているオブジェクトのいずれかがメモリ内にある間は、OC_StorageMana ger事例を決してメモリから割り当て解除してはならないものとする。『開発担 当者ガイド』の「記憶管理」の章がこの制限に関する情報をアプリケーション開 発担当者に提供している。 □ トランザクション及びキャッシュハンドリング機能 全てのトランザクション及びキャッシュハンドリング機能は、OC_StorageMana gerと類似の名前を有する関連Client Library自由機能によって呼び出される。 一例がOC_Storage Manager::startTransaction()機能である。その処理に終わり には、OC_transactionStart()はOC_StorageManagerクラスの各々の活動中事例に startTransaction()を呼び出す。 アプリケーションコードも要求された場所にこれらの機能を呼び出すことがあ る。 非実現機能 これらの機能は純粋仮想であり、従って、記憶管理開発担当者によって実現さ れなければならない。 トランザクションハンドリング virtual void startTransaction(); この機能はOC_transactionStart()の終わりに各々の活動中記憶マネージャに 呼び出される。 通常は、新しいトランザクションが開始された後に、アプリケーションは、そ のオブジェクトを管理するために必要な記憶マネージャを構築しなければならな い。しかしながら、トランザクションが開始されたときに１つ以上の記憶マネー ジャがすでに存在していることがある。記憶マネージャが存在することができる のは、先行トランザクションがOC_keepCache設定によって終了させられたから、 又は記憶マネージャがあらゆるトランザクションの外側に生成されたからである 。 OC_StorageManager::startTransaction()処理は、記憶マネージャがトランザ クションの開始時に存在しているかいないかとは無関係に、各々の記憶マネージ ャについて実行されなければならない。さらに、startTransaction()は、各々の オブジェクトについてのトランザクション当たり１回だけ実行するものとする。 これらの要件は下記のアプローチを使用することによって満たすことができる。 １．startTransaction()が実行しなければならない処理を実行するために、各々 の記憶マネージャクラスに関する機能を定義する。この機能は、例えばstartXAP rocessing() と呼ばれることがある。（あるいは又、各々のクラスに同じ目的を有する別の機 能を与えることもできる。） ２．各々のクラスについて、ステップ１に記述されたstartXAProcessing()機能 を実現する。 ３．その唯一のアクションがstartXAProcessing()機能を呼び出すことにある通 り抜け機能としてstartTransaction()を実現する。 ４．startXAProcessing()の呼び出しを含めるために、記憶マネージャクラスの コンストラクタをコード化する。 これらのステップを踏むことによって、記憶マネージャがトランザクションの 開始時に存在しているのか、又はトランザクション中に生成されたのかとは無関 係に、各々の記憶マネージャについて同一の処理が実行されることになる。 virtual void abortTransaction(); この機能はOC_TransactionAbort()の開始時に各々の活動中記憶マネージャに 呼び出される。 virtual void checkpointTransaction(); この機能はOC_TransactionCheckpoint()の開始時に各々の活動中記憶マネージ ャに呼び出される。 virtual void commitTransaction(); この機能はOC_TransactionCommit()の開始時に各々の活動中記憶マネージャに 呼び出される。 キャッシュハンドリング virtual void cleanCache(); もしキャッシュ処置がOC_CleanCacheに設定されている場合には、CleanCache( )は、キャッシュクリーニング操作の一部として、OC_TransactionCommit()又はO C_TransactionAbort()の実行中に各々の活動中記憶マネージャに呼び出される。 データベース閉鎖 virtual void closeDatabase(); この機能はOC_Closeの開始時に各々の活動中記憶マネージャに呼び出される。 記憶管理機構の管理 □ タスク概要 記憶管理業務管理担当者の役割は、記憶マネージャの生成、構成、使用及び削 除のタスクの管理を含んでいる。（「記憶マネージャ」という用語はOC_Storage Managerベースクラスの事例を意味していることを忘れないこと。）いくつかの 記憶管理機構の場合には、これらのタスクが関連のコンポーネントクラスの事例 にも関係している。 記憶マネージャの構成及び使用の管理は、特定のOC_StorageManagerクラス及 びそれがサーブする記憶管理機構に固有のものである。従って、このガイドでは 記憶マネージャの構成及び使用の問題は取り扱わない。しかしながら、全ての記 憶マネージャの生成及び削除に際して考慮すべきいくつかのポイントがある。こ れらのポイントが以下の２つの節で取り扱われる。 □ 記憶マネージャを生成すべき時期 記憶マネージャの範囲及び数の決定 新しい記憶マネージャを生成すべき時期は、予期記憶マネージの範囲（それに 所属することができるオブジェクトの数）及び並行して存在することができる記 憶マネージャの数という２つの要素によって大きく影響される。 これらの２つの要素は相互依存している。記憶マネージャの範囲が大きくなれ ばなるほど、必要な数が少なくなり、その逆の関係も成り立つ。各々のOC_Stora geManagerベースクラスは範囲及び数に関して自己トレードオフを行わなければ ならない。下記は、記憶マネージャの範囲及び数を決定する場合に考慮に入れる べき事柄である。 参照スペース及び処理 範囲及び数の両方に影響を与える１つの制限が、そのOC_Reference参照値構造 によって定義されるような記憶マネージャの参照スペースである。 もし多重記憶マネージャの使用を計画している場合には、範囲は、要求される 記憶マネージャ間参照の量によって影響される。オブジェクトの数が記憶マネー ジャの中の使用可能参照の数よりもはるかに少ないことが予想される小さなデー タセットは、単一記憶マネージャとの対応付けのための強力な候補である。特定 の記憶マネージャの使用可能参照スペースが、OC_Reference構造によって得られ る理論的最大スペースよりもかなり小さいものに制限されることがあることに注 意すること。記憶マネージャクラスがその参照スペースを区分、構造化又は配列 する場合には、この制限が導入されることがある。 記憶マネージャの数を制限する際の主モチベーションは通常は記憶マネージャ 間参照をハンドリングするために必要な処理の量である。もし１つの部分からも う１つの部分への参照がめったに行われることがないように、潜在的に大きなデ ータセットを２つ以上の部分に分割することができる場合には、各々の部分の中 のオブジェクトを異なる記憶マネージャ事例によって生成する強力なケースとな る。 資源制限 時には、記憶マネージャの数は、特定の記憶マネージャが大量のメモリ又はデ ィスク資源を消費することによって制限される。 永続性ＳＭ間参照の性能 記憶マネージャ事例の数を制限する追加的な要素が、永続性記憶マネージャ間 参照の支援用のONTOS DBの現記憶マネージャ識別アルゴリズムである。このアル ゴリズムは、データベースの核領域内のOC_Listの中に各々の記憶マネージャ事 例の参照を記憶する。大きなOC_Listの中の要素へのアクセスに関係する時間及 びメモリオーバヘッドは、OC_Listの中のその要素の位置とほぼ比例している。 従って、非常に多くのその他の記憶マネージャの生成の後に生成された記憶マネ ージャの効率は若干低下する可能性がある。 大部分のアプリケーションの場合には、このオーバヘッドの影響は無視するこ とができる。その影響が目立つのは、数100もの記憶マネージャを生成するアプ リケーションの場合に限られる。たとえそのようなアプリケーションにおいても 、もしアプリケーションが永続性記憶マネージャ間参照を含んだオブジェクトに 頻繁にアクセするするのでない場合には、その影響は最小限のものであると思わ れる。 □ 記憶マネージャの削除に関する警告 もし所属しているオブジェクトがまだ活動中である可能性がある場合には、メ モリからOC_StorageManagerベースクラス事例を割り当て解除してはならない。 もし所属しているオブジェクトがまだ存在しているか、又は他の記憶マネージ ャに所属しているオブジェクトによってまだ参照される可能性がある場合には、 データベースからOC_StorageManagerベースクラス事例を削除してはならない。 □ OC_StorageManager 機能 下記は、記憶管理業務管理担当者のタスクを支援するOC_StorageManager機能 である。 コンストラクタ及びディストラクタ OC_StorageManager(char* name＝(char*)OC_null); サブクラスコンストラクタだけからしか呼び出されないOC_StorageManagerコ ンストラクタ。argument nameを有する記憶マネージャに任意に名前を指定する こともできる。 OC_StorageManager(OC_APL* theAPL); OC_StorageManager活動化コンストラクタ。 -OC_StorageManager(); OC_StorageManagerディストラクタ。 管理メンバ機能 void destroy(OC_Boolean aborted); 割り当て解除のためにこの記憶マネージャを準備する。もしabortedがOC_true に設定されている場合には、destroy()は例外ハンドラ放棄の結果としてすでに 呼び出されている。このクラスのディストラクタから、又は派生クラスのdestro y()機能から以外は、この方法が直接呼び出されることはないものとする。 unsigned short getAreaNumber(); 開論理データベース用の核領域のID番号を復帰させる。 virtual OC_Type* getDirectType(); この記憶マネージャのOC_Typeを指し示すポインタを復帰させる。 unsigned short getID(); このOC_StorageManager事例についての一意性IDを復帰させる。 付属書II OC_CleanupObj-OC_Entity-OC_Object-OC_ExternalKey ＯＣ＿ＥｘｔｅｒｎａｌＦｒｅｅＦｏｒｍＫｅｙ クラスOC_ExternalFreeFormKeyは、ONTOS DB 3.0クライアントアプリケーシ ョン用に外部記憶管理を開発するために使用することができる任意の外部記憶管 理製品の一部として利用可能である。 記憶マネージャ開発担当者は、OC_ExternalFreeFormKey及びそれから派生し たクラスについての機能の多くを実現する責任を負っている。 OC_ExternalFreeFormKeyは、OC_ExternalFreeFormKeyから派生したクラスに ついての広範なオプションを許容するアーキテクチャの中で、そのベースクラス であるOC_ExternalKeyに関して定義された機能のいくつかを実現する。 使用法 ‡include”External.h” シノプシス コンストラクタ及びディストラクタ OC_ExternalFreeFormKey OC_Entity* referent=(OC-Entity*)0); OC_ExternalFreeFormKeyについてのコンストラクタ。任意引数referentは、 このキーが表示するエンティティーを指し示している。 OC_ExternalFreeFormKey(OC_APL* theAPL); 活動化コンストラクタ。 〜OC_ExternalFreeFormKey(); OC_ExternalFreeFormKeyについてのディストラクタ。 メンバ機能 virtual OC_ExternalSM* getExternalSM(); このOC_ExternalFreeFormKeyと対応付けられたOC_ExternalSMを復帰させる 。 virtual OC_Object* getProtoObj(void*，dataStruct, OC_Type* objType); 初期化されているが、非活動中のOC_Objectを復帰させる。引数dataStruct は、オブジェクトを表示している自由形式データ構造である。その値はOC_Exter nalFreeFormKey::getReferentText()の呼び出しによって得ることができる。 引数objTypeもオブジェクトを表示している。その値はOC_ExternalFreeForm Key::getTypeOfObj()の呼び出しによって得ることができる。 virtual OC_Object* getReferent(OC_ExternalSM*&，extSM, OC_Type*&，OC_LockType); このOC_ExternalTypeMappedKeyの参照対象を指し示すポインタを復帰させる 。詳細な記述については、OC_ExternalKey:getReferent()に関する入口を参照。 virtual void* getReferentText( OC_ExternalSM*&，extSM，OC_LockType lock); 活動化すべきオブジェクトをOC_ExternalFreeFormKeyクラス実現に固有のフ ォーマットで表示している自由形式データ構造を指し示すポインタを復帰させる 。extSM引数は オブジェクトの記憶マネージャであり、lock引数はオブジェクトについてのロッ クのタイプである。 virtual OC_Object* getProtoObj(void* dataStruct); OC_ExternalFreeFormKey:getReferentText()の呼び出しによってその値を得 ることができる自由形式データ構造であるdataStructによって記述されるオブジ ェクトのOC_Typeを復帰させる。 下記も参照 関連クラス OC_ExternalSM、OC_ExternalTypeMap、及びOC_ExternalKey。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中の外部キーに関する検討を参照。 OC_CleanupObj-OC_Iterator-OC_InstIterator ＯＣ−ＥｘｔｅｒｎａｌＩｎｄｅｘＩｔｅｒａｔｏｒ クラスOC_ExternalIndexIteratorは、ONTOS DB 3.0クライアントアプリケー ション用に外部記憶管理を開発するために使用することができる任意の外部記憶 管理製品の一部として利用可能である。 OC_ExternalInstIteratorから派生したクラスOC_ExternalIndexIteratorは 、イテレータの対応付けOC_ExternalTypeMap事例によってマッピングされたオブ ジェクトに関する索引付き特性の繰り返しを行う。 使用法 ‡include”External.h” シノプシス コンストラクタ OC_ExternalIndexIteratorコンストラクタ。第１のオーバロードは事例のデ ータメンバをリセット()によって達成されるのと同じ状態に初期化する。 コンストラクタの引数は下記の通りである。 source この事例を生成したOC_ExternalTypeMapを指し示すポインタ。 type イテレータが復帰させるオブジェクトのタイプを指し示す ポインタ。 prop 繰り返すべきOC_Propertyを指し示すポインタ。 value イテレータがオブジェクトを復帰させるために必要とする propの値。 lock 繰り返しにおけるオブジェクトについてのロックのタイプ。 cursorData 繰り返しの状態を追跡するためのデータを含んでいる、実現 固有オブジェクトを指し示すポインタ。 yieldInOrder 特性値の昇順で索引を発生するOC_rueの値。 start 索引の範囲内の最初の値。 end 索引の範囲内の最後の値。 メンバ機能 OC_Argument getEnd(); 繰り返し範囲の最終索引を復帰させる。もし繰り返しがある特性について同 一の単一値を有する全てのオブジェクトのためのものである場合には、getEnd() は単一値を復帰させる。 OC_Property getProperty(); 繰り返しについての特性を指し示すポインタを復帰させる。 OC_Argument getStart(); 繰り返し範囲の開始索引を復帰させる。もし繰り返しがある特性について同 一の単一値を有する全てのオブジェクトのためのものである場合には、getStart )は単一値を復帰させる。 OC-Boolean getYieldsInOrder(); もしイテレータが索引順に索引を発生する場合には、OC_trueを復帰させる 。もしそうではない場合には、OC_falseを復帰させる。 OC_Boolean getYieldsRange(); もしイテレータが索引の範囲を発生する場合には、OC_trueを復帰させる。 もしそうではない場合には、OC_falseを復帰させる。 OC_Boolean moreData(); このクラスについては実現されていない。 下記も参照 関連クラス OC_ExternalSM、OC_ExternalTypeMap、OC_ExternalKey、OC_Iterator、及び OC_ExternalInstIterator。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中のタイプマッピングされたオブジェク トの反復の実現に関する検討を参照。 OC_CleanupObj-OC_Iterator- ＯＣ＿ＥｘｔｅｒｎａｌＩｎｓｔＩｔｅｒａｔｏｒ クラスOC_ExternalInstIteratorは、ONTOS DB 3.0クライアントアプリケー ション用に外部記憶管理を開発するために使用することができる任意の外部記憶 管理製品の一部として利用可能である。 OC_Iteratorから派生したクラスOC_ExternalInstIteratorは、イテレータの 対応付けOC_ExternalTypeMap事例によってマッピングされたオブジェクトに関す る索引付き特性の繰り返しを行う。 使用法 ‡include”External.h” シノプシス コンストラクタ OC_ExternalInstIteratorコンストラクタ。コンストラクタの引数は下記の 通りである。 source この事例を生成したOC_ExternalTypeMapを指し示すポインタ。 type イテレータが復帰させるオブジェクトのタイプを指し示すポイ ンタ。 lock 繰り返しにおけるオブジェクトについてのロックのタイプ。 cursorData 繰り返しの状態を追跡するためのデータを含んでいる、実現固 有オブジェクトを指し示すポインタ。 メンバ機能 void* getCursorData(); OC_ExternalInstIteratorコンストラクタにcursorData引数としてパスされ たポインタを復帰させる。もしコンストラクタが0に等しいcursorDataによって 呼び出された場合には、きの機能は0を復帰させる。 virtual OC_ExternalTypeMap* getSource(); このOC_ExternalInstIteratorを生成したタイプマップを指し示すポインタ を復帰させる。 virtual OC_Type* getType(); このOC_ExternalInstIteratorが繰り返すOC_Typeを指し示すポインタを復帰 させる。 virtual OC_Boolean moreData(); もし繰り返すべきより多くのデータが存在する場合には、OC_trueを復帰さ せる。もしそうではない場合には、OC_falseを復帰させる。 virtual OC_Argument operator()(); もしあれば、次の事例を復帰させる。 このクラスには不要である。いずれかの呼び出しはOC_NotImplemented例外 を申し立てる。 virtual OC-Boolean seek(long offset，OC_SeekType sType); OC_ExternallnstIteratorはこれを必要としない。そのデフォルト実現はOC_ Not Implemented例外を申し立てる。 virtual char* yieldStringValue(); OC_ExternalInstIteratorはこれを必要としない。そのデフォルト実現はOC_ Not Implemented例外を申し立てる。 virtual OC_Entity* yieldEntityValue(); もしあれば、次の事例を復帰させる。 OC_ExternalInstIteratorはこれらの機能を必要としない。そのデフォルト 実現は OC_NotImplemented例外を申し立てる。 下記も参照 関連クラス OC_ExternalSM、OC_ExternalTypeMap、OC_ExternalKey、OC_Iterator、及び OC_ExternalIndexIterator。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中のタイプマッピングされたオブジェク トの反復の実現に関する検討を参照。 OC_CleanupObj-OC_Entity-OC_Object- ＯＣ−ＥｘｔｅｒｎａｌＫｅｙ クラスOC_ExternalKeyは、ONTOS DB3.0クライアントアプリケーション用に 外部記憶管理を開発するために使用することができる任意の外部記憶管理製品の 一部として利用可能である。 OC_ExternalKeyは、記憶管理開発担当者がサブクラス化しなければならない 抽象クラスである。 OC_ExternalKeyサブクラスは、外部データ記憶装置の中に記憶されたオブジ ェクトの永続性アイデンティティーをカプセル封じする。記憶管理開発担当者が OC_ExternalKey自体をサブクラス化することが可能である。しかしながら、OC_E xternalKeyのONTOS供給サブクラス、OC_ExternalMappedKey及びOC_ExternalFree FormKeyのサブクラス化の方が通常は利点が大きい。 使用法 ‡include”External.h” シノプシス コンストラクタ及びディストラクタ OC_ExternalKey(OC_Entity* referent＝(OC_Entity*)0); OC_ExternalKeyについてのコンストラクタ。任意引数referentは、このキー が表示するエンティティーを指し示している。 OC_ExternalKey(OC_APL* theAPL); 活動化コンストラクタ。 〜OC_ExternalKey(); OC_ExternalKeyについてのディストラクタ。 メンバ機能 virtual void deleteReferent(); データベースからこのOC_ExternalKeyの参照対象を除去する。記憶マネージ ャ開発担当者はこの機能を実現しなければならない。 virtual unsigned long getEntityHashKey(); このOC_ExternalKeyの参照対象についてのハッシュキー値を復帰させる。記 憶マネージャ開発担当者はこの機能を実現しなければならない。 virtual OC_Object* getReferent(OC_ExternalSM*& sm, OC_Type*& type，OC_LockType lock); このOC_ExternalKeyの参照対象を指し示すポインタを復帰させる。復帰参照 対象は初期化されているが、非活動中である。つまり、そのデータメンバはオブ ジェクトの永続性表示からすでに初期化されているが、その活動化コンストラク タはまだ実行されていない。この機能は、extSM引数によって、参照対象の記憶 マネージャを指し示すポインタも復帰させる。さらに、type引数によって、参照 対象のOC_Typeを指し示すポインタ も復帰させる。lock引数は参照対象につい てのロックのタイプである。 記憶マネージャ開発担当者はこの機能を実現しなければならない。 virtual unsigned long getReferentHashKey(); このOC_ExternalKeyの参照対象を指し示すハッシュキー値を復帰させる。デ フォルト実現は同じ値をOC_ExternalKey::getEntityHashKey()として復帰させる 。 virtual void lockReferent(OC_LockType lock); このOC_ExternalKeyの参照対象に関する指定OC_LockTypeのロックを獲得又 は更新する。ロックのダウングレード効果のない既存のロックの再獲得を試みる 。記憶マネージャ開発担当者はこの機能を実現しなければならない。 OC_setLockBuffering()又は類似の機能によるロックバッファリングオプシ ョンの設定は外部記憶マネージャを有するオブジェクトには効果がないことに注 意すること。 virtual OC_Boolean operator==(OC_Entity& key); もしこのOC_ExternalKey及びキーによって参照されたOC_ExternalKeyが複製 事例である場合には、OC_trueを復帰させる。もしそうではない場合には、OC_fa lseを復帰させる。キーは、このOC_ExternalKeyと同じOC_ExternalSM事例と対応 付けられなければならない。しかしながら、２つのキーが異なるOC_ExternalTyp eMapsによって生成されていることもある（パラメータ引数のタイプは内部最適 化だけを目的とするOC_Entityである。キー引数はタイプOC_ExternalKeyでなけ ればならない。 記憶マネージャ開発担当者はこの機能を実現しなければならない。 virtual void putReferent(); データベースの中にこのOC_ExternalKeyの参照対象の現状態を記憶する。も し参照対象がすでにデータベースの中に存在している場合には、putReferent() はそれをオブジェクトの現状態と取り替える。 記憶マネージャ開発担当者はこの機能を実現しなければならない。 下記も参照 関連クラス OC_ExternalSM及びOC_ExternalTypeMap。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中の外部キーの実現に関する検討を参照 。 OC_CleanupObj-OC_Entity-OC_Object-OC_StorageManager- ＯＣ−ＥｘｔｅｒｎａｌＳＭ クラスOC_ExternalSMは、ONTOS DB 3.0クライアントアプリケーション用に 外部記憶管理を開発するために使用することができる任意の外部記憶管理製品の 一部として利用可能である。 OC_ExternalSMは、記憶管理開発担当者がサブクラス化しなければならない 抽象クラスである。 OC_ExternalSMは、外部データ記憶装置の中にONTOS DBデータを記憶する、 及び/又はONTOS DBの中に外部データを記憶するアプリケーションについての記 憶管理の基礎としての役割を果たす。外部データ記憶装置は、様々なパラダイム 及びスキーマを有する非ONTOS DBデータベース、及び様々なフォーマットのファ イルを含んでいる。 OC_ExternalSMは、外部記憶マネージャクラスを定義するための推奨開始点 である。OC_ExternalSMは、そのベースクラスであるOC_StorageManagerと同じイ ンタフェース（メンバ機能）を有している。外部記憶マネージャの開発に関して は、OC_ExternalSMはそのベースクラスに比べて下記の２つの利点を有している 。 ・OC_ExternalSMは、広範なOC_ExternalSMベースクラスをサーブする機能性に よって、OC_StorageManager定義仮想機能の多くを実現する。大部分の外部記憶 マネージャに対して、これらのONTOS供給実現の大部分は必要な機能性を供給す る。 ・多くのOC_ExternalSM機能は、OC_ExternalSM機能の呼び出しをOC_ExternalK ey又はOC_ExternalTypeMap派生クラスに関する機能の呼び出しに翻訳する。単一 OC_ExternalSMとしての、このコンポーネントクラス支援コード再使用への機能 の委任は、単一クラスのいくつかの事例又は異なるコンポーネントクラスのいく つかの事例を使用することがある。 使用法 ♯include″External.h″ シノプシス コンストラクタ及びディストラクタ OC-ExternalSM(char* name=(char*)OC_null); OC_ExternalSMについてのコンストラクタ。nameは任意オブジェクト名であ る。 OC_ExternalSM(OC_APL* theAPL); 活動化コンストラクタ。 〜OC_ExternalSM(); OC_ExternalSMについてのディストラクタ。 メンバ機能 void abortTransaction(); 記憶マネージャ開発担当者は、OC_transactionAbort()の開始時に呼びされ るこの機能を実現する。 void activate(OC_Object* obj，OC_Type* theType, OC_ExternalKey* key; 初期化されているが、非活動中であるオブジェクトについてのメモリロケー ションであるobjを活動化させるために必要な最終処理を実行する。引数theType は、オブジェクトについてのOC_Typeを指し示さなければならない。key引数は、 活動化すべきオブジェクトについてのOC_Typeを指し示さなければならない。 activate()によって実行される処理は、活動化コンストラクタラッパ機能の 位置指定及び呼び出し、利用可能なvtblを有していないOC_Typesの事例について のvtblシミュレーション、及び記憶マネージャ及び*objについての自己参照値の 初期化を含んでいる。 void addTypeMap(OC_Object* obj，OC_Type* theType, OC_ExternalTypeMap* theMap); theTypeによって指定されたOC_Type用の記憶マネージャについてのOC_Dicti onaryに、外部タイプマップであるtheMapを追加する。 virtual void afterKeepCache(); OC_ExernalSMはこれを必要としないので、空実現。 virtual voidallocateObj(long sz，OC_Type* theType, OC_Object* obj，OC_Clustering clustering); その他の処理の実行に追加して、allocateObj()は、スペースを割り当てる ために、大域機能::operator newを使用する。 注：もしallocateObj()再実現する場合には、deallocateObj()も相補アルゴリ ズムによって必ず再実現すること。 virtual void beforeKeepCache(); OC_ExernalSMはこれを必要としないので、空実現。 virtual void checkpointTransaction(); 記憶マネージャ開発担当者は、OC_transactionCheckpoint()の開始時に呼び されるこの機能を実現する。 virtual void cleanCache(); メモリからこの記憶マネージャ事例、及び全てのその対応付けOC_ExternalK ey及びOC_ExternalTypeMap事例を削除する。OC_ExternalSMを削除する前に、cle anCache();は活動中OC_ExternalKey及びOC_ExternalTypeMap事例を繰り返し、メ モリから削除する。 virtual void closeDatabase(OC_Boolean cleanAll); 記憶マネージャ開発担当者は、OC_close()の開始時に呼びされるこの機能を 実現する。 virtual void commitTransaction(); 記憶マネージャ開発担当者は、OC_transactionCommit()の開始時に呼びされ るこの機能を実現する。 virtual OC_Boolean compareReferences(OC_References* rl, OC_References* r2); もしr1及びr2が同じ参照対象を参照する場合には、OC_trueを復帰させる。 virtual void deallocateObj(void* inst); その他の処理の実行に追加して、deallocateObj()は、スペースを割り当て 解除するために、大域機能::operator deleteを使用する。 注：もしdeallocateObj()再実現する場合には、allocateObj()も相補アルゴリ ズムによって必ず再実現すること。 virtual void deleteObj(OC_Object* obj); データベースから、objによって指し示されたOC_Objectを削除する。 もしobjが対応付けOC_ExternalKeyを有していない場合には、deleteObj()は 、それがデータベースに置かれたことのない新しいオブジェクトであることを決 定し、従って、それを削除されたものとして簡単にマークする。 もしobjが対応付けOC_ExternalKeyを有してる場合には、deleteObj()オブジ ェクトのOC_ExternalKeyにdeleteReferent()の洗練を呼び出す。 virtual void destroyObj(OC_Object* obj); メモリからの割り当て解除についてのobjによって指し示されたOC_Objectを 準備する。 virtual void discardReference(OC_Reference* ref, OC_Boolean persistently); 参照対象に対応付けられたOC_ExternalKeyにオペレータdeleteを呼び出すこ とによって、refによって指し示された参照を削除する。もしpersistently引数 がOC_trueである場合には、この機能はrefの参照対象への永続的参照に対応づけ られた全ての資源も開放する。 virtual unsigned long getInstanceCount(OC_type* type); この記憶マネージャによって記憶されるOC_Type typeを有する事例の近似カ ウントを復帰させる。もしこの記憶マネージャが共通拡張子機構を使用するか、 又はtypeもそのスーパータイプも拡張子を有していない場合には、0を復帰させ る。 virtual OC_Iterator* getIterator(OC_type* type, OC_LockType lock); この記憶マネージャによって制御されるOC_Typeを有する事例についてのイ テレータを復帰させる。OC_LockType lockによって活動化事例をロックする。 virtual OC_Iterator* getIterator(OC_type* type, OC_Property* prop，OC_Argument start，OC_Argument end, OC_LockType lock); この記憶マネージャによって制御される、指定OC_Propertyについての指定O C_Typeの事例についてのイテレータを復帰させる。特性についての値の範囲を設 定するために、引数start及びendを使用する。イテレータはOC_LockType lockに よって活動化事例をロックする。 OC_Dictionary* getMaps(); この記憶マネージャについての外部タイプマップのOC_Dictionaryを復帰さ せる。この機能は、OC_ExternalSM機能であるaddTypeMap、romoveTypeMap及びge tYTypeMapによって呼び出される。 virtual unsigned long getObjHashKey(OC_Object* obj); objによって指し示されたOC_Objectについてのハッシュキー値を復帰させる 。objが、非配列OC_Dictionaryのような、集合体オブジェクトの中でキーとして の働きを行う場合には、ハッシュキー値が使用される。 virtual OC_LockType getObjLockType(OC_Object* obj); objについて最後に獲得又は更新されたロックのタイプを復帰させる。もし ロックが適用可能なOC_ExternalSM機能（getReferent()、lockReferent()、putO bj()又はdeleteObj()）の１つによってロックが設定されていない場合には、こ の機能はOC_noLockを復帰させる。 virtual OC_Entity* getReferent(OC_Reference* ref, OC_LockType lock); refの参照対象を指し示すポインタを復帰させる。もし参照対象がすでに削 除されている場合には、getReferent()はOC_ObjectWasDeleted例外を申し立てる 。lock引数は参照対象について使用するためのロックのタイプである。 virtual OC_LockType getReferentLockType( OC_Reference* ref); refの参照対象について最後に獲得又は更新されたロックのタイプを復帰さ せる。もしロックが適用可能なOC_ExternalSM機能（getReferent()、lockRefere nt()、putObj()又はdeleteObj()）の１つによってロックが設定されていない場 合には、この機能はOC_noLockを復帰させる。 virtual OC_ExternalTypeMap* getTypeMap(OC_Type* theType); OC_Type theTypeについての外部タイプマップを指し示すポインタを復帰さ せる。 virtual OC_Boolean isObjDeleted(OC_Object* obj); もしobjによって指し示されたOC_ObjectがOC_ExternalSM::deleteObj()によ ってすでに永続的に削除されている場合には、OC_trueを復帰させる。もしそう ではない場合には、OC_falseを復帰させる。 virtual OC_Boolean isObjInDB(OC_Object* obj); もしobjによって指し示されたOC_Objectがデータベースの中にある場合には 、OC_trueを復帰させる。OC_Objectがデータベースの中にあるのは、下記の２つ の判定基準が満たされている場合である。 ・objがOC_ExternalSM::defaultActivateObj()によって活動化されたか、又は OC_ExternalSM::putObj()によって非活動化された。 ・objがOC_ExternalSM::deleteObj()によって後に削除された。 一方又は両方の条件が満たされていない場合には、この機能はOC_falseを復 帰させる。 virtual OC_Boolean isObjModified(OC_Object* obj); もしobjによって指し示されたOC_Objectが修正済みとすでにマークされてい るか、又は未修正と後にマークされなかった場合には、OC_trueを復帰させる。 もしうではない場合には、OC_falseを復帰させる。 virtual OC_Boolean isObjNew(OC_Object* obj); もしobjによって指し示されたOC_Objectが新しい場合には、OC_trueを復帰 させる。OC_Objectが新しいのは、下記の条件の全てが満たされている場合に限 られる。 ・objがOC_ExternalSM::allocateObj()によって生成された。 ・objがOC_ExternalSM::deleteObj()によって削除されていない。 ・objの生成以降まだOC_ExternalSM::cleanCacheの呼び出しが行われていない 。 もしこれらの条件の１つ以上が満たされていない場合には、この機能はOC_f alseを復復帰させる。 virtual OC_Boolean isReferentActive(OC_Reference* ref); もしrefの参照対象が活動中である場合には、OC_trueを復帰させる。参照対 象が活動中であるのは、下記の判定基準の全てが満たされている場合である。 ・このOC_ExternalSMによって管理された。 ・OC_ExternalSM::allocateObj()によって生成されたか、又はOC_ExternalSM: :getReferentのデフォルト実現によって呼び出される()ヘルパ機能によって活動 化された。 ・OC_ExternalSM::destroyObj()によって削除されていない。 もし参照対象が全ての条件を満たしていない場合には、この機能はOC_false を復帰させる。 virtual OC_Boolean isReferentDeleted(OC_Reference*); もしrefの参照対象がデータベースから削除されていない場合には、OC_true を復帰させる。参照対象がデータベースからすでに削除されているのは、下記の 判定基準の全てが満たされている場合である。 ・参照対象がOC_Primitiveではない。 ・参照対象が、OC_ExternalSM::deleteObj()によってすでにデータベースから 削除されているか、又は、OC_ExternalSM::cleanCache()の最後の呼び出し以降 、オブジェクトを活動化する試みの際にOC_ObjectWasDeleted例外を申し立てた ことがあるOC_Object又はディセンダントである。 もし少なくとも１つの判定基準が満たされていない場合には、この機能はOC _falseを復帰させる。 virtual OC_Boolean isReferentInDB(OC_Reference* ref); もしrefの参照対象がデータベースの中にある場合には、OC_trueを復帰させ る。参照対象がデータベースの中にあるのは、下記の判定基準の１つが満たされ ている場合である。 ・参照対象がOC_Primitiveである。 ・参照対象がOC_Object又はディセンダントであり、OC_ExternalSM::getRefer ent()によって活動化されたか、又はOC_ExternalSM::putObj()によって非活動化 され、 OC_ExternalSM::deleteObj()によって後に削除されなかった。 もしいずれの条件も満たされていない場合には、この機能はOC_falseを復帰 させる。 もしデータベースの中にあるかどうかを決定するために必要な場合には、こ の機能は非活動中参照対象を活動化することがある。 virtual OC_Boolean isReferentModified(OC_Reference* ref); もしrefの参照対象が修正済みとマークされている場合には、OC_trueを復帰 させる。参照対象が修正されたとマークされるのは、下記の判定基準の全てが満 たされている場合である。 ・参照対象がOC_Primitiveではない。 ・もし参照対象がOC_Object又はディセンダントである場合には、最後に修正 済みとマークされて以降、参照対象がまだ未修正とマークされたことがない。 ・もし参照対象がOC_Object又はディセンダントである場合には、最後に修正 済みとマークされて以降、参照対象がまだ割り当て解除されたことがない。 もし参照対象が全ての判定基準を満たしていない場合には、この機能はOC_false を復帰させる。 virtual void lockObj(OC_Object* obj，OC_LockType lock); objをlockによって指定されたロックタイプによってロックするか、又はobj の現ロックをlockによって指定されたロックタイプに更新する。もしlockObj() の実行が成功した場合には、lockが新しいキャッシュされたロックタイプになる 。 例えば、OC_writeLockによって現在ロックされているオブジェクト用のOC_r eadLock、又はあらゆるオブジェクト用のOC_noLockのような、現ロックのロック タイプよりも力の 弱いロックタイプによって呼び出された場合には、この機能には何の効果もない 。 OC_setLockBuffering()又は類似の機能によるロックバッファリングオプシ ョンの設定は外部記憶マネージャを有するオブジェクトには効果がないことに注 意すること。 virtual void lockReferent(OC_Reference* ref, OC_LockType lock); refの参照対象をlockによって指定されたロックタイプによってロックする か、又は参照対象の現ロックをlockによって指定されたロックタイプに更新する 。もしockObj()の実行が成功した場合には、lockが新しいキャッシュされたロッ クタイプになる。 例えば、OC_writeLockによって現在ロックされているオブジェクト用のOC_r eadLock、又はあらゆるオブジェクト用のOC_noLockのような、現ロックのロック タイプよりも力の弱いロックタイプによって呼び出された場合には、この機能に は何の効果もない。 OC_setLockBuffering()又は類似の機能によるロックバッファリングオプシ ョンの設定は外部記憶マネージャを有するオブジェクトには効果がないことに注 意すること。 この機能は現在は使用不能である。 virtual void markObjModified(OC_Object* obj); objによって「修正済み」と指し示されたOC-Objectをマークする。 virtual void putObj(OC_Object* obj); objによって指し示されたOC_Objectをデータベースに置く。 もしオブジェクトが対応付けOC_ExternalKeyを有していない場合には、putO bj()あｈオブジェクトのタイプと対応付けられたOC_ExternalKeyMapにgenerateK ey()を呼び出す。 もしオブジェクトが対応付けOC_ExternalKeyを有していない場合には、この 機能はキーを（OC_ExternalKeyMap::generateKey()を呼び出すことによって）生 成し、データベースに置く。 OC_setLockBuffering()又はOC_setBuffering()のような機能によるロックバ ッファリングオプションの設定は外部記憶マネージャを有するオブジェクトには 効果がないことに注意すること。 void removeTypeMap(OC_Type* theType, OC_ExternalTypeMap* theMap); theTypeによって指定されたOC_Type用の記憶マネージャについてのOC_Dicti onaryから、外部タイプマップであるtheMapを除去する。 この機能は現在は使用不能である。 この機能は現在は使用不能である。 virtual void startTransaction(); 記憶マネージャ開発担当者は、OC_transactionStart()の開始時に呼び出さ れるこの機能を実現する。 virtual unsigned long translateRefValue( OC_Entity* referent); referentについてのメモリ内参照値を復帰させる。 OC_StorageManagerはtranslateRefValue()復帰を外向き参照として、つまり 、別の記憶マネージャの制御の下にあるOC_Entityとしての*referentへの参照と して認識する。 もし妥当であると認識されない場合には、translateRefValue()はOC_NoSuch Refを申し立てる。 外向き参照であるか、又は別の記憶マネージャによって翻訳され、この記憶 マネージャに戻された固有参照である参照値を復帰させる。oldRefValue引数は 翻訳のための参照値である。oldContext引数はoldRefValue（oldContextをこれ とすることができる）についての記憶マネージャを指し示す。 もしoldRefValueがoldContextのコンテキストにおいて妥当であると認識さ れていない場合には、translateRefValueはOC_NoSuchRef例外を申し立てる。 virtual void unmarkObjModified(OC_Obj* obj); objによって指し示されたOC_Objectから「修正済み」マークを除去する。 virtual OC_ExternalKey* validateKey(OC_ExternalKey* key); もし引数キーが一意性である場合には、機能にパスされたものと同じポイン タを復帰させる。もしキーが一意性ではない場合には、OC_ExternalKeyを複製す るためのポインタを復帰させる。 下記も参照 関連クラス OC_StorageManager、OC_ExternalKey及びOC_ExternalTypeMap。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中の主EMSクラスのの実現に関する検討 を参照。 OC_CleanupObj-OC_Entity-OC_Object- ＯＣ−ＥｘｔｅｒｎａｌＴｙｐｅＭａｐ クラスOC_ExternalTypeMapは、ONTOS DB 3.0クライアントアプリケーション 用に外部記憶管理を開発するために使用することができる任意の外部記憶管理製 品の一部として利用可能である。 OC_ExternalMapは、記憶管理開発担当者がサブクラス化しなければならない 抽象クラスである。 OC_ExternalMapサブクラスは、特定のオブジェクトタイプに固有の処理を実 行する。 単−OC_ExternalMapサブクラスは１つ以上のOC_ExternalSMサブクラスを支 援することがある。 使用法 ‡include”External.h” シノプシス コンストラクタ及びディストラクタ OC_ExternalTypeMap(OC_ExternalSM* sm，OC_Type: theType); 記憶マネージャsmによって管理されるtheTypeの事例の処理を実行する、OC_ ExternalTypeMapについてのコンストラクタ。 OC_ExternalTypeMap(OC_APL* theAPL); 活動化コンストラクタ。 〜OC_ExternalTypeMap(); OC_ExternalTypeMapについてのディストラクタ。 メンバ機能 virtual void cleanup(OC_ExternalInstIterator* iter); iterと対応付けた全ての資源を回復するために、このOC_ExternalTypeMapを 使用可能にする。この機能はOC_ExternalInstIterator::〜OC_ExternalInstIter ator()によって呼び出される。 virtual void* discardKeyText(void* dataStruct); dataStructによって指し示されたデータ構造と対応付けられた全ての資源を 解放する。dataStruct引数はOC_ExternalKeyの状態を表示する。その値はOC_Ext ernalKey::getObjText()から得る。 virtual OC_ExternalKey* generateKey(OC_Object* obj); 現在及び将来のトランザクションにおいてOC_Object objを一意性識別及び 活動化することができるOC_ExternalKeyオブジェクトを復帰させる。 OC_ExternalSM* getExternalSM() このOC_ExternalTypeMapが対応付けられているOC_ExternalSMを復帰させる 。 virtual unsigned long getInstanceCount(OC_Type* type); このOC_ExternalSMによって記憶されるタイプの事例の近似カウントを復帰 させる。このカウントは、タイプの各々の事例（直接及び間接の両方）のカウン トを正確に含んでいる。 この３つのシグナチュアは全て、OC_Iteratorベースクラスの事例を指し示 すポインタを復帰させる。この３つ全てについて、イテレータはOC_LockType lo ckによって活動化事例をロックする。 第１のオーバロードのために、イテレータはtypeの各々の事例を正確に１度 復帰させる。 第２のオーバロードのために、もし事例のpropについての値がvalueに等し い場合には、イテレータはtypeの各々の事例を復帰させる。 第３のオーバロードのために、もし事例のpropについての値がstart及びend によって指定された範囲内にある場合には、イテレータはtypeの各々の事例を復 帰させる。もしyieldInOrderがOC_trueに設定されている場合には、イテレータ は事例をpropについての昇順値の順序で復帰させることになる。形で発生させる ことを指定する。もしyieldInOrderがOC_falseである場合には、事例は未配列の 状態で復帰させられる。 virtual OC_ExternalKey* getKey(void* dataStruct); 新しいOC_ExternalKeyオブジェクトを指し示すポインタを復帰させる。引数 dataStructは、OC_ExternalKeyの状態を表示しているデータ構造である。その値 はOC_ExternalTypeMap::getKeyText()を呼び出すことによって得る。 virtual void* getKeyText(OC_ExternalInstIterator* iter); virtual void* getKeyText(OC_ExternalIndexIterator* iter); iterによって指し示されたOC_ExternalInstIterator（第１のシグナチュア ）又はOC_ExternalIndexIterator（第２のシグナチュア）からその参照対象を得 るために発見又は構築されるべきOC_ExternalKeyの状態を表示しているデータ構 造を復帰させる。復帰構造の内容の定義及びフォーマットはOC_ExternalTypeMap クラス実現に固有のものである。 固有のOC_ExternalTypeMap実現に応じて、復帰データ構造はOC_ExternalKey の参照対象の状態に関する情報も含んでいることがある。そのような情報は、参 照対象に対する 推定緊急要求をハンドリグする際に役立てることができる。参照対象の活動化の 際に使用するためのそのような情報をキャッシュする手段を提供するのは、記憶 マネージャプログラマの責任である。 OC_Type* getMappedType(); OC_ExternalTypeMapによってマッピングされたOC_Typeを復帰させる。 extKeyによって指定された外部キーの参照対象を復帰させる。復帰OC_Objec tは初期化されているが、非活動中である、つまり、そのデータメンバはオブジ ェクトの永続性表示からすでに初期化されているが、その活動化コンストラクタ はまだ実行されていない。lock引数は活動化すべき参照対象についてのロックの タイプである。 この機能は２つの引数も正しい場所に復帰させる。この２つの引数は、記憶 マネージャのアドレスのC++参照であるsm、及び参照対象のOC_Typeを指し示すポ インタのアドレスのC++参照であるtypeである。 virtual unsigned long getObjHashKey(OC Object* obj); objと永続的に対応付けられているハッシュキー値を復帰させる。 virtual void* getObjText(OC_ExternalKey* extKey, OC_LockType lock); 外部データ記憶装置から活動化されるべき、extKeyの参照対象の状態を表示 しているデータ構造を指し示すポインタを復帰させる。復帰構造の内容の定義及 びフォーマットはOC_ExternalTypeMapクラス実現に固有のものである。lock引数 は活動化すべき参照対象についてのロックのタイプを指定する。 virtual OC_Object* getProtoObj(void* dataStruct); 初期化されているが、非活動中である、つまり、そのデータメンバはオブジ ェクトの永続性表示からすでに初期化されているが、その活動化コンストラクタ はまだ実行されていないオブジェクトを指し示すポインタを復帰させる。引数da taStructは、OC_ExternalKey::getObjTextによって復帰させられた構造であるも のとする。 もしextKeyが対応付けOC_ExternalSMオブジェクトについての全ての外部キ ーのセットの内部において一意性である場合には、validateKey()はextKeyをOC_ ExternalSMのキーに追加し、extKeyを復帰させる。もしextKeyが一意性ではない 場合には、validateKey()は複製キーを指し示すポインタを復帰させる。 繰り返しにおける次の値を復帰させる。この機能は、moreData()によって、 iterによって指し示されたパスOC_ExternalInstIterator（第１のシグナチュア ）又はOC_ExternalIndexIterator（第２のシグナチュア）に復帰させられる。 下記も参照 関連クラス OC_ExternalSM、 OC_ExternalKey、 OC_ExternalInstIterator及びOC_Exter nalIndexIterator。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中の外部タイプマッピングの実現に関す る検討を参照。 OC_CleanupObj-OC_Entity-OC_Object-OC_ExternalKey ＯＣ−ＥｘｔｅｒｎａｌＴｙｐｅＭａｐｐｅｄＫｅｙ クラスOC_ExternalTypeMappedKeyは、ONTOS DB 3.0クライアントアプリケー ション用に外部記憶管理を開発するために使用することができる任意の外部記憶 管理製品の一部として利用可能である。 記憶マネージャ開発担当者は、OC_ExternalTypeMappedKey及びそれから派生 したクラスについての機能の多くを実現する責任を負っている。 OC_ExternalTypeMappedKeyは、OC_ExternalTypeMapクラスと密接に対応付け られたアーキテクチャの中で、そのベースクラスであるOC_ExternalKeyに関して 定義された機能のいくつかを実現する。外部キークラスの中で、OC_ExternalTyp eMappedKeyは外部キークラスの開発を最も支援する。 使用法 ‡include”External.h” シノプシス コンストラクタ OC_ExternalTypeMappedKey(OC_ExternalTypeMap* theTypeMap, OC_Entity referent); 対応付けタイプマップを指し示す引数theTypeMap、及びキーオブジェクトが 対応付け られているエンティティーを指し示す引数referentを有する、OC_ExternalTypeM appedKeyについてのコンストラクタ。 OC_ExternalTypeMappedKey(OC_APL* theAPL); 活動化コンストラクタ。 メンバ機能 virtual OC_Object* getReferent(OC_ExternalSM*&, OC_Type*& OC_LockType lock); このOC_ExternalTypeMappedKeyの参照対象を指し示すポインタを復帰させる 。詳細な記述については、OC_ExternalKey::getReferentに関する入口を参照。 OC_ExternalTypeMap* typeMap(); このOC_ExternalTypeMappedKeyを生成したOC_ExternalTypeMapを指し示すポ インタを復帰させる。 下記も参照 関連クラス OC_ExternalSM、OC_ExternalTypeMap及びOC_ExternalKey。 関連ドキュメンテーション ONTOS DB『外部記憶管理ガイド』の中の外部キーの実現に関する章を参照。

【手続補正書】特許法第１８４条の８ 【提出日】１９９６年５月２０日 【補正内容】 明細書 名称オブジェクト指向データベースと非オブジェクト指向データ機構を統合する オブジェクトデータ指向データ記憶装置統合環境 発明の技術分野 本発明はコンピュータデータベースに関し、詳細にはオブジェクト指向デー タベースと非オブジェクト指向データ機構の統合に関する。 発明の技術的背景 コンピュータシステムアプリケーションで使用するためのデータの永続的記 憶のためには現在様々な手段及び方法論が存在している。周知のデータベース管 理システム（DBMS）は、たとえデータを使用又は生成したプログラムが終了され た後であっても使用するために（「永続性」）、例えばディスク、テープ等のよ うな、持久記憶装置へのデータの記憶を簡単にしている。永続性に加えて、DBMS は基本的に「同時制御」を提供し、従って、ユーザーは相互に妨害したり、デー タの保全を危険にしたりせずに、データベースをきょうゆることができ、システ ム（ハードウエア又はソフトウエア）の故障の際にデータ保全を保護及び復元す るための機能を「回復する」ことができる。DBMS「照会」機能は、データレコー ドの内部にいくつかの特定の特性又はフィールドを指定することによってユーザ ーが大容量のデータにアクセスすることを可能にし、一方、いくつかのデータへ のアクセスを制限するために、「機密保護」機能が一般的にはDBMSに組み込まれ ている。周知のDBMSはデータベースの中のデータの特性および関係を記述するた めに「スキーマ」管理を支援する。 DBMS技術の進展とともに、上記のような基本的機能性は維持及び拡張されてき たが、一方では、データの複雑性及び処理性能要件は増大しているのである。「 関係型」DBMSとして知られている商業データ処理に適用される１つのタイプのデ ータ管理技術が、全てのデータがまるで表に定様式化されているかのように編成 されており、その表の列が表のフィールド又は定義域を表し、表の行が表のフィ ールド又は定義域の値を表すという点で比較的単純化された形でモデル化されて いる。 請求の範囲 １．外部データ記憶装置インタフェースを有する外部データ記憶装置の中に記憶 された非オブジェクト構造化データを、ODBMSアプリケーションインタフェース によってオブジェクトデータベース構造を処理する少なくとも１つのオブジェク トアプリケーションと統合する装置において、 オブジェクト、参照、索引、拡張子及びトランザクションを含んでいる複 数の第１インタフェースコンストラクトからなり、記憶マネージャ機構と該少な くとも１つのオブジェクトアプリケーションの間でオブジェクトデータ構造を伝 送するために、該ODBMSアプリケーションインタフェースとの通信を行う該複数 の第１インタフェースコンストラクトのハンドリングを簡単にする、該ODBMSア プリケーションインタフェースと該記憶マネージャ機構との間の第１インタフェ ースと、 該第１インタフェースに応答し、該複数の第１インタフェースコンストラ クトの少なくともいくつかを受け取り、オブジェクトデータ構造を該外部データ 記憶装置への記憶用の非オブジェクト構造化データに変換するためと、非オブジ ェクト構造化データを該少なくとも１つのオブジェクトアプリケーション用のオ ブジェクトデータ構造に変換するために、該複数の築１インタフェースコンスト ラクトの該少なくともいくつかを複数の第２インタフェースコンストラクトにマ ッピングする積分マッピング機構と、 該複数の第２インタフェースコンストラクトからなり、該記憶マネージャ 機構と該外部データ記憶装置の間で非オブジェクト構造化データを伝送するため に該外部データ記憶装置インタフェースとの通信用の該複数の第２インタフェー スコンストラクトのハンドリングを簡単にする、該マッピング機構と該外部デー タ記憶装置の間の第２インタフェースと を含んでいる、該ODBMSアプリケーションインタフェース及び該外部データ記 憶装置に応答する記憶マネージャ機構 からなることを特徴とする装置。 ２．該外部データ記憶装置が少なくとも１つの関係型データベースである請求の 範囲１に記載の装置。 ３．該記憶マネージャ機構が該複数の第１インタフェースコンストラクトの該少 なくとも いくつかを複数の第２インタフェースコンストラクトの少なくともいくつかにマ ッピングするための情報を記憶する貯蔵所を含んでいる請求の範囲１に記載の装 置。 ４．該貯蔵所が該外部データ記憶装置の中に記憶されたデータの構造を記述して いるスキーマ情報を含んでいる請求の範囲３に記載の装置。 ５．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトが詰外部データ記憶装置の中に記憶された特 定のレコードを識別するキーコンストラクトを含んでいる請求の範囲２に記載の 装置。 ６．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトが非オブジェクト構造化データとオブジェク トデータ構造の間の変換を定義するタイプマップコンストラクトを含んでいる請 求の範囲２に記載の装置。 ７．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトが非オブジェクト構造化データとオブジェク トデータ構造の間の変換を定義するタイプマップコンストラクト、及び該外部デ ータ記憶装置の中に記憶された特定のレコードを識別するキーコンストラクトを 含んでいる請求の範囲２に記載の装置。 ８．各々の該タイプマップコンストラクトが該外部データ記憶装置の中に記憶さ れたデータから個々のキーコンストラクトを構築するためのキーレイアウト情報 を含んでいる請求の範囲７に記載の装置。 ９．各々の該タイプマップコンストラクトが該外部データ記憶装置の中に記憶さ れたオブジェクトレイアウトデータから個々のオブジェクトを構築するためのオ ブジェクトレイアウト情報を含んでいる萼求の範囲７に記載の装置。 10．該貯蔵所が該貯蔵所の中の情報を管理するデータベース管理システムを含ん でいる請求の範囲３に記載の装置。

Claims (1)

1. 【特許請求の範囲】 １．外部データ記憶装置インタフェースを有する外部データ記憶装置の中に記憶 された非オブジェクトデータを、ODBMSアプリケーションインタフェースによっ てオブジェクトデータベース構造を処理する少なくとも１つのオブジェクトアプ リケーションと統合する装置において、 オブジェクト、参照、索引、拡張子及びトランザクションを含んでいる複 数の第１インタフェースコンストラクトからなり、記憶マネージャ機構と該少な くとも１つのオブジェクトアプリケーションの間でオブジェクトデータ構造を伝 送するために、該ODBMSアプリケーションインタフェースとの通信を行う該複数 の第１インタフェースコンストラクトのハンドリングを簡単にするように構成さ れている、該ODBMSアプリケーションインタフェースと該記憶マネージャ機構と の間の第１インタフェースと、 該第１インタフェースに応答し、該複数の第１インタフェースコンストラ クトの少なくともいくつかを受け取り、オブジェクトデータ構造を該外部データ 記憶装置への記憶用の非オブジェクトデータに変換するためと、非オブジェクト データを該少なくとも１つのオブジェクトアプリケーション用のオブジェクトデ ータ構造に変換するために、該複数の第１インタフェースコンストラクトの該少 なくともいくつかを複数の第２インタフェースコンストラクトにマッピングする マッピング機構と、 該記憶マネージャ機構と該外部データ記憶装置の間で非オブジェクトデー タを伝送するために該記憶マネージャ機構と該外部データ記憶装置インタフェー スの間の通信を簡単にする該外部データ記憶装置インタフェースと通信するよう に構成されている該複数の第２インタフェースコンストラクトからなる、該マッ ピング機構と該外部データ記憶装置の間の第２インタフェースと を含んでいる、該ODBMSアプリケーションインタフェース及び該外部データ記 憶装置に応答する記憶マネージャ機構 からなることを特徴とする装置。 ２．該外部データ記憶装置が少なくとも１つの関係型データベースである請求の 範囲１に記載の装置。 ３．該記憶マネージャ機構が該複数の第１インタフェースコンストラクトの該少 なくともいくつかを複数の第２インタフェースコンストラクトの少なくともいく つかにマッピング する情報を記憶する貯蔵所を含んでいる請求の範囲１に記載の装置。 ４．該貯蔵所が該外部データ記憶装置の中に記憶されたデータの構造を記述して いるスキーマ情報を含んでいる請求の範囲３に記載の装置。 ５．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトが該外部データ記憶装置の中に記憶された特 定のレコードを識別するキーコンストラクトを含んでいる請求の範囲２に記載の 装置。 ６．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトがレコードとオブジェクトデータ構造の間の 変換を定義するタイプマップコンストラクトを含んでいる請求の範囲２に記載の 装置。 ７．該第２インタフェースが該外部データ記憶装置と直接通信を行い、該複数の 第２インタフェースコンストラクトがレコードとオブジェクトデータ構造の間の 変換を定義するタイプマップコンストラクト、及び該外部データ記憶装置の中に 記憶された特定のレコードを識別するキーコンストラクトを含んでいる請求の範 囲２に記載の装置。 ８．各々の該タイプマップコンストラクトが該外部データ記憶装置の中に記憶さ れたデータから個々のキーコンストラクトを構築するためのキーレイアウト情報 を含んでいる請求の範囲７に記載の装置。 ９．各々の該タイプマップコンストラクトが該外部データ記憶装置の中に記憶さ れたデータから個々のオブジェクトを構築するためのオブジェクトレイアウト情 報を含んでいる請求の範囲７に記載の装置。 10．該貯蔵所が該貯蔵所の中の情報を管理するデータベース管理システムを含ん でいる請求の範囲３に記載の装置。