JPH02501514A - 属性データ モデル データベースを使用するソフトウエア応用プログラムを結合する方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 属性データモデルデータベースを使用するソフトウェア応用プログラムを結合す る方法関連出願 本発明は、１９８８年４月１３日にニドワード・Ｓ・ロウリーによって出願され たＵ、Ｓ、Ｓ、Ｎ　１８］、１０５号、名称“単一の革純な原素を用いたデータ 構造を有するデータ処理システム”に関連する。

発明の背景 本発明は、一般的にはデータベースの分野に関し、より特定的には若干の応用プ ログラムによる共通データベースの使用に関する。

多くの異なる応用プログラムは、あるコンピュータシステムにおいて他のプログ ラムと情報を共有し、或は交換しなければならないことが多い。一つの注目すべ き例は、製品の設計及び製造に援助を与える一組の相互作用するコンピュータプ ログラムである。

これらの相互作用するプログラムは、典型的には製品の開発に使用される計算機 援用設計（ＣＡＤ）プログラム及び製造支援システム（ＣＡＭ）プログラムを含 む。

これらのシステムにおいては、１つの応用プログラムからの出力データカ月つ或 はそれ以上の他の応用プログラムの入力データであることが屡々である０例えば 、回路基板のデザインを開発するのに使用されるＣＡＤプログラムの出力データ は、デザインされた回路基板の製造を容易ならしめるＣＡＭプログラムの入力デ ータとして使用することができる。

しかしながら、ある応用プログラムからの出力データを別の応用プログラムのた めの入力データとして機能させるためには、両心用プログラムはこのようなデー タの転送が行われ得るように設計されていなければならない、出力データは、そ のデータを操作する応用プログラムによって使用を容認できる形状で１！備され 、提示されなければならない、このようにして通信する応用プログラムを“結合 された”と呼ぶ。

ソフトウェア応用プログラム対間で結合を行うのは比較的簡単な仕事である。こ のような結合は単に、結合しようとする２つの応用プログラムの一方或は両方を 変更するだけでよい。

一方、幾つかの他の応用プログラムを結合させる場合には、プログラムの数が増 すにつれてますます複雑になって来る。しかし若干のプログラムを結合すること は珍しいことではない。例えば、集積回路を設計するための１つのＣＡＤプログ ラムを回路基板を設計するための別のＣＡＤプログラムと、及びこれらの基板を 製造するためのＣＡＭプログラムと結合する必要があり得る。

典型的には、１つの応用プログラムと他の若干の応用プログラムとの結合は、第 １のプログラムを他の各プログラムと結合可能ならしめるように設計することに よって達成する。しかし、この設計戦略は各プログラムの入力要求に関する詳細 な知識を必要とし、また新しい応用プログラムが付加される度毎に第１の応用プ ログラムの再設計を必要とするかも知れない、その代りとして、もし他の応用プ ログラムを第１の応用プログラムと結合させるために再設計するものとすれば、 同様な問題が発生する。

変形として、第１の応用プログラムと他の応用プログラムとを結合させるために 変換プログラムを使用することが可能である。

しかし、他のプログラムが追加されると、別の変換プログラムを設計しなければ ならない。

結合を達成するためにこれらの変換プログラムを使用し、応用プログラムを再設 計するためには相当な時間、努力及び費用を必要とする。この時間、努力及び費 用は、結合すべきプログラムの数と共に劇的に増大する。

付加的な変換プログラムの必要性を排除するために、異なるプログラムがアクセ ス可能なある領域内のメモリにデータを記憶させる共通データベースが採用され ている。共通データベースを使用するシステムは、各応用プログラムが共通デー タベースとのインターフェイスを有しているだけでよい。これらのインターフェ イスは、応用プログラムによって出力されたデータを共通データベースに記憶さ せるためのフォーマントに変換し、その共通データベースからのデータを応用プ ログラムが受入れ得るフォーマントに変換する。データを記憶するものとして知 られている或は使用されている共通データベースシステムは、例えば′関係”、 “機能′、及び“コーダシル”データモデルを含む。

従来のデータモデルを使用する共通データベースシステムは、上述のプログラム 結合の発端の問題を解消するが、従来のデータモデルは結合されるプログラムに 別のプログラミング上の及び性能的な諸問題をもたらす。従来のデータモデルに よってもたらされるプログラミング及び性能の諸問題に関する一つの検討がチャ ールス・Ｗ、バックマンの合衆国特許４，６３１，６６４号に記載されているの で参照されたい。

従って、本発明の目的は、付加的な変換プログラムの必要性及び複雑さを減少さ せるか或は応用プログラムの再設計を減少させるような技法で共通データ構造を 使用して若干の応用プログラムを結合させる方法を提供することである。

また従来のデータモデルを使用する共通データベースシステムが遭遇する実際的 な性能問題を解消するプログラム結合方法を提供することも本発明の目的である 。

本発明の別の目的は、応用プログラムによる共通データ構造へのアクセスを管理 する手段を提供することである。

本発明の更に別の目的は、補助メモリを有するデータ処理システムに容易に応用 可能な共通データ構造を提供することである。

本発明の更に別の目的は、応用プログラム情報の複雑な相互関係を表わすことが 可能な単一原素エレメントのみを使用して、応用プログラム内の情報を表現する ことである。

本発明の別の目的及び長所は以下の説明から、或は本発明の実行から理解される であろう。

光里ｑ景！ 上述の目的を達成するために、及び実現され且つ以下に説明する本発明の目的に よれば、複数の応用プログラムによってアクセスされるデータ構造は単一原素デ ータエレメント即ち属性データ対象から創製される０本発明によれば、応用プロ グラムを実行するデータプロセッサも、該データプロセッサに接続されているメ モリ内にデータ構造を創製する。このデータ構造は、応用プログラムから発せら れノードデータ及びノードデータ記述子を含むデータを使用して作成される。即 ち、データ構造を作成（創製）する方法は、前記データプロセッサが実行する： 各ノードデータ毎に異なる属性データ対象を作成し；各属性データ対象毎にこれ らの属性データ対象から選択することによってホールドされた関係に従ってこれ らの属性データ対象を階層的に編成し；各属性データ対象と単一のホールダデー タ対象との間に階層的なホールドされた関係が存在するようにホールダデータ対 象を作成する諸段階を含む。

本方法は更に、属性データ対象の中から選択された属性データ対象のための関連 データ対象を選択することによって、少なくとも１つの前記ノードデータ記述子 に組合わされているノードデータから作成された属性データ対象の中の選択され たもののために非階層的関係を確立する段階をも含む０選択された各関連データ 対象は、対応する選択された属性データ対象を作成したノードデータのノードデ ータ記述子を表わす、これらの選択された属性データ対象を関係データ対象と呼 び、また関連データ対象を伴わない属性データ対象をエレメントデータ対象と呼 ぶ。

本方法は更に：少なくとも１つの属性データ対象をホールドする関係を有し且つ 何れの属性データ対象ともホールドされた関係を有していない頂点データ対象を 作成し：属性データ対象のための属性ファイルを作成し：各属性データ対象を属 性ファイル内へ挿入する諸段階をも含む。

また本発明によれば、本方法は：各属性データ対象毎に、その属性データ対象に ホールドされた関係を有する１つの属性データ対象を指示するホールディングポ インタを前記属性ファイル内に挿入し；属性データ対象間の非階層的関係を表わ す関連ポインタを属性ファイル内に挿入する諸段階を含む。

本明細書に添付され、本明細書の一部をなしている添付図面は本発明の実施例を 示しており、説明と共に本発明の原理を教示する。

図面の簡単な説明 第１図は本発明によるデータ処理システムの例を示し、第２図は本発明によって 教示される属性データ対象の例を示し、第３図は本発明の属性データモデルの使 用を説明するために用いられる回路を示し、 第４図は属性データモードに従って第３図の回路を表わすためのデータ構造を示 し、 第５Ａ図は本発明の好ましい実施例によるソフトウェアシステムの若干の成分の ブロック線図、 第５Ｂ図は本発明の別の実施例によるソフトウェアシステムの若干の成分のブロ ック線図、 第６図は本発明による複数ファイルを含むデータ構造を包含するメモリシステム の内容の一部を示し、第７図は本発明の好ましい実施例においてポインタとして 使用される３２ビツトロングワードを示し、第８図は第６図に示す属性ファイル の構成要素部分のより詳細なブロック図、 第９図は第８図に示すエレメント見出しブロックのブロック図、第１０Ａ図及び 第１０Ｂ図は第８閾に示す関係サブブロックの好ましい実施例のブロック図、 第１１図は第８図に示す“ホールドされた”エレメントサブブロックの好ましい 実施例のブロック図、第１２図は第８図に示す複数関係見出しブロックのブロッ ク図、第１３Ａ図及び第１３Ｂ図は第８図に示す２種類の複数関係サブブロック の好ましい実施例のブロック図、第１４図は第８図に示すインスタンスルートブ ロックの好ましい実施例のブロック図〜 第１５図は第６図に示すディクショナリファイルの好ましい実施例のブロック線 図、 第１６図は第１５図に示す頂点ブロック或は文脈ブロックの何れかの好ましい実 施例の基本構造及び内容に関するブロック図、第１７図は第１５図に示すエレメ ント型ブロックの好ましい実施例のブロック図、 第１８図は第１５図に示す属性型ブロックのブロック図、第１９図は本発明によ る索引技ブロックの好ましい実施例のブロック図、 第２０図は第１９図に示す索引技見出しブロックの好ましい実施例のブロック図 、 第２１図は第１９図に示す索引結果ブロックのブロック図、第２２図は第８図に 示す索引ディレクトリプロンクの好ましい実施例のブロック図、 第２３Ａ図及び第２３Ｂ［Ｆは本発明によりエレメントデータ対象を作成するた めの好ましい方法に包含される諸段階を示す流れ図、 第２４ＡＩｌａ及び第２４Ｂ図は本発明により関係を作成するための好ましい方 法に包含される諸段階を示す流れ図、第２５図は本発明により関係を消去するた めの好ましい方法に包含される諸段階を示す流れ図、 第２６図は本発明によるエレメントデータ対象の消去に包含される諸段階を示す 流れ図、 第２７Ａ図及び第２７Ｂ図は本発明により共通データ構造にアクセスする好まし い方法に包含される諸段階を示す流れ図、第２８区は本発明によりキー値を使用 して共通データ構造にアクセスする別の好ましい方法に包含される諸段階を示す 流れ図、第２８Ａ図は索引結果ブロックを示し、第２９図は本発明による共通デ ータ構造１４０′の好ましい実施例の詳細なブロック線図、 第３０図は第２９図に示す制御回路のポインタ／カウンタ区分の好ましい実施例 のブロック図、 第３１図は１２９ｖｊＪに示すバージョンプロフタのブロック図、第３２閏は第 ２９図に示すスイッチブロックのブロック図、第３３図は本発明によるデータ構 造１４０′の更新に包含される諸段階を示す流れ閏、 第３４図は第３３図に示す好ましい引き渡しルーチンの流れ回、第３５Ａ図、第 ３５Ｂ図、及び第３５Ｃ図はそれぞれ第３４図に示す引き渡しルーチンに伴う初 期ハウスキーピング手順、中間ハウスキーピング手順、及び最終ハウスキーピン グ手順の流れ図、及び 第３６図は本発明により共通データ構造１４０′の所望バージョンにアクセスす るための流れ図の好ましい実施例を示す。

〔実施例〕

以下に添付図面に基いて本発明の現在では好ましい実施例に関して詳細に説明す る。

Ａ、ｆ゛デー　告 第１図は、中央処理装置（ＣＰＵ）１１０及び１２０を含むデータ処理システム １００の図である。ＣＰＵｌｌ０は標準的で周知の如何なる中央処理装置であっ ても差支えなく、またメモリ１２０は磁気コア、半導体ＲＡＭ、Ｉ気ディスク及 び磁気テープ、或は他の如何なる周知メモリ装置をも含むことができる。またＣ ＰＵＩ　１０は、応用プログラムを同時に実行できる若干の独立して走る中央処 理装置を表わすこともできる。第１図に示すように、応用プログラム１３０．１ ３２及び１３４はＣＰＬＩＩＩＯによって交互に実行される。第１図にはＣＰＬ ｌｌ　１０は応用プログラム１３０を実行し、応用プログラム１３２及び１３４ はメモリ１２０内に記憶されているように示されている。

本発明によれば、応用プログラム１３０，１３２、及び１３４は、属性データモ デルに基づく共通データ構造１４０を共有する。

属性データモデルは、単一原素の種々組合せとして応用プログラム１３０．１３ ２及び１３４によってアクセスされる情報の全てを表わす、一般的に応用プログ ラム１３０．１３２及び１３４は、属性データモゾール或は別の何れかのフォー マントでデータを包含するそれら自体のデータベースを有する。もし応用プログ ラム情報が属性データモデルフォーマントでなければ、それは後述する手段によ って該フォーマントに変換される。このようにするとデータ構造１４０は各応用 プログラム１３０．１３２、及び１３４によってアクセス可能となる。

共通データ構造１４０は、応用プログラムによって作成され、アクセスされる独 特なデータ構造であるため、より一般的なデータベースシステムとは異なる。属 性データモデルは、その草−原素として属性即ち属性データ対象を使用する。こ れは他の複数の属性とのその関係に間するある階層情報を包含し、また非属性関 係を表わすために属性を°指し示す”ことができる。

第２図は属性データ対象２００の例を示す、属性データ対象２００の他の属性デ ータ対象との階層関係は、その関係を如何に考えるかに依存して、ホールドして いる或はホールドされている関係として表わされる。一般には各属性データ対象 は他の１つの属性データ対象だけにホールドされている（即ち他の１つの属性デ ータ対象によってホールドされ得る）関係を有することができるが、各属性デー タ対象は他の若干の属性データ対象をホールドする（或はホールドすることがで きる）関係を有することが可能である。

各属性データ対象２００はホールダ属性データ対象２１０と階層的に関係づけら れている。ホールダ属性データ対象は、属性データ対象２００をホールドしてい る関係を有する属性データ対象である。反対に、属性データ対象Ａ２００は、属 性データ対象２１０にホールドされている関係を有する。

非階層関係即ち指し示しの関係は、属性データ対象によって表わされる情報間の 関係を表わす、若干の属性データ対象は、指し示しの関係を表わすために単一の 関連属性データ対象と関係付けることもできる。関連属性データ対象２２０は、 属性データ対象２００によって表わされる情報と非階層関係を存する情報を表わ す。

各属性データ対象２００は、属性データ対象２００と、属性データ対象２００が ホールドしている関係を有している属性データ対象、並びに属性データ対象２０ ０が“指し示している′関連属性データ対象との間の関係を表わす型データと関 係付けることもできる。

属性データ対象が本発明により従わなければならない規則は僅かしかない、各属 性データ対象は若干の他の属性データ対象をホールドすることはできるが、各属 性データ対象は他の属性データ対象だけにしかホールドされた関係を有すること ができない。即ち、各属性データ対象は単一のホールダ属性データ対象しか有し ていないのである。

一つの種類の属性データ対象、即ちエレメントデータ対象即ちエレメントは、分 離した関連属性データ対象を有していない。何故ならばこれらのエレメントはそ れら自体を′指し示している°、即ち各エレメントがそれ自体の関連であると考 えられるからである。別の種類の属性データ対象、即ち関係データ対象は、単一 の分離した関連属性データ対象に関係付けられている。各属性データ対象は、複 数の属性データ対象のだめの関連属性データ対象であり得る。

属性データモデルにおける基本は、単一原素エレメント、即ち属性が他のデータ ベース内の複雑な情報を表わすことができるという思想である。属性とは、１つ の事物は別の事物に属するとするイデアを表わす０例えば、通常は自動車の属性 には、その色、そのエンジン、及びその所有者が含まれる。ある原素としての属 性の周辺に複雑なデータベースを編成することは、あるデータベースが基本的に は属性の収集であるという概念を表わしている。

共通データベース１４０はこの概念の具体的表示である。

前述のように、エレメント即ちエレメントデータ対象はそれら自体に関連する属 性データ対象であり、換言すればホールダ属性データ対象のみを有していて、分 離した関連属性データ対象は有していない、あるエレメントは、ある自動車、あ るエンジン、ある乗算器回路のあるバージョン、或はある信号を表わすことがで きる。あるエレメントにホールドされた関係を有する複数のエレメントは、例え ばそのエレメントによって表わされている事の内部構造を表わすことができる。

例えば、もしあるエレメントがエンジンを表わしているものとすれば、エンジン を表わしているそのエレメントにホールドされた関係を有する他の複数のエレメ ントはピストン、シリンダ、及びピストンリングを含むことができる。

データ構造１４０の各実施例は、別の属性データ対象にホールドされた関係を有 していない１つの属性データ対象を有している。

この属性データ対象は頂点或は頂点属性データ対象と呼ばれ、少なくとも１つの 他の属性データ対象をホールドする。唯一の頂点属性データ対象、及び各属性デ ータ対象に対して１つのホールダの要求に加えて、データ構造１４０の各実施例 は本発明による属性データ対象の形態を有する。この形態は、必ずしも必要とは しないが、頂点から開始することによって、及びホールドしている関係の他の属 性を一時に１つ加えることによってこの形態を作成することができるようになっ ている。この制限が階層を作り、例えば第１の属性データ対象が第２の属性デー タ対象をホールドする関係を有し、第２の属性データ対象が第３の属性データ対 象をホールドする関係を有し、そして第３の属性データ対象が第１の属性データ 対象をホールドする関係を有するようなある円或はループ形態となるのを阻止す る。このような形態は本発明による階層ではない。

上述のような関係即ち関係データ対象は、その属性データ対象自体とは異なる関 連属性データ対象に関係付けられたある属性データ対象である。関係は、複数の エレメントにホールドされた関係を有することができる０例えば、もしあるエレ メントがある乗算器回路を表わしているものとすれば、１つの関係はそのエレメ ントをその乗算器の先行バージョンたらしめることができる。更に、関係は、他 の関係とホールドしている及びホールドされた関係を有することができる０例え ば、もし第１の関係属性データ対象が乗算器の部品番号に属しているものとすれ ばこの第１の関係属性データ対象は、部品番号を乗算器に割当てたデータを第１ の関係属性データ対象に属さしめた第２の関係属性データ対象をホールドするこ とができる。

属性データモデルは例を用いると理解し易い、第３図は３人力ＡＮＤゲート３２ ０及び２人力ＡＮＤゲート３３０を含む回路を示す、ＡＮＤゲート３２０の入力 は３２２．３２４及び３２６であり、ＡＮＤゲート３３０の入力は３３２及び３ ３４である。

ＡＮＤゲート３２０の入力３２２はＡＮＤゲート３３０の出力３３６によって駆 動され、ＡＮＤゲート３３０の入力３３４はＡＮＤゲート３２０の出力３２８に よって駆動されている。

第３図の回路は多くの異なるデータモデルに従って表わすことができる０例えば 、もしそれが関係データモデルによって表わされるものとすれば、ゲート、入力 及びゲートの負荷に関する分離した表が存在しよう、これらの表は他の表内のエ ントリの識別名を包含している臀である。

第４図は、本発明の属性データモデルに従って第３図の情報を表わすデータ構造 ４００を示す、データ構造４００は第１図の共通データ構造１４０内に記憶させ ることが可能である。

データ構造４００は頂点４１０を含み、頂点４１０は前述のように他の何れの対 象にもホールドされた関係を有していない、更に頂点４１０は、文脈であること もできるＣＰＵ属性データ対象４２０をホールドする（即ちホールドする関係を 有する）、この文脈は属性データ対象の命名を容品にしく何故ならばこれらの名 前は命名された対象をホールドする文脈内のみに意味を有するからである）、ま た第３図の回路及び信号のようにその文脈に関連する属性データ対象をホールド する関係を確立するための構造である。

ＣＰＵ属性データ対象４２０は、回路エレメントである属性データ対象４３０及 び４４０をホールドする。属性データ対象４３０は第３図の回路を表わす、属性 データ対象４３０自体は、ゲートエレメントである２つの属性データ対象４５０ 及び４６０をホールドする。ゲートエレメント４５０自体は、ビンエレメントで ある４つの属性データ対象４８０．４８２．４８６及び４８８をホールドする。

このようにして階層的にホールドする関係が第３図の情報に付諜される。

第４図に示すように、第３図からの他の情報も階層的に編成される。頂点４１０ は他のエレメントの名札を表わすエレメント４６２．４６４．４６６．４６８． ４９０、及び４９２もホールドし、また属性データ対象４２０（ＣＰＬＩ要素） は信号エレメントを表わすエレメント４７０．４７２．４７４、及び４７６をホ ールドする。

属性データ対象の階層配列は、集合的に概念的対象を表わす属性データ対象を包 含するのに用いられる“包含の木”をもたらす。

ルート属性データ対象或は包含の木のルートと呼ばれる属性データ対象の包含の 木は、そのルートによってホールドされた（即ち直接的にホールドされた）全て の属性データ対象を含み、また包含のり木内の他の何れかの属性データ対象によ ってホールドされた（即ち間接的にホールドされた）全ての属性データ対象をも 含む、直接的にホールドされた、或は別の属性データ対象によって間接的にホー ルドされた属性データ対象は、該別の属性データ対象から、或は該別の属性デー タ対象の包含の木の中に°包含され”でいると言われる。ある包含の木において は、その木によって表わされる概念的対象はそのルートに一致する。この包含の 木内の他の全ての属性データ対象は成分、リストに載せられた項目、或は木によ って表わされる概念的対象内の関係のような概念的サブ対象を表わす、包含の木 の中の属性データ対象はその包含の木の外側の属性データ対象との関係を表わす こともできる。

第４図において、回路エレメント４３０に関する包含の木は、ゲートエレメント ４５０及び４６０、及び回路エレメント４３０及びゲートエレメント４５０によ ってホールドされている関係データ対象（即ち、エレメント４４０及び４６８を 指し示している関係データ対象、及びエレメント４６２を指し示している関係デ ータ対象）、エレメント４５０によってホールドされているエレメント（！ｐち ビンエレメント４８０．４８２．４８６及び４８８）、及びビンエレメント４８ ０及び４８８によってホールドされている関係データ対象（即ちエレメント４６ ４．４７０．４７２及び４６６を指し示している関係データ対象）を含む。

詳細を後述するように、包含の木を使用すると、複雑な対象を消去するような操 作が腸略化される０例として、ある対象の消去は対応する包含の木の共通データ 構造からの除去を包含する０本発明によれば、その木の中の全ての属性データ対 象を迅速に識別することが可能であり、従来のデータベースに広く用いられてい る自動ごみ集めによってもたらされるランダムな休止を排除することができる。

第４図は他の若干の属性データ対象をも含み、これらは第４図には属性データ対 象として表わされている第３図内の各事物を記述する情報を表わす。例えば、属 性データ対象４３０は名前“ＸＹＺ”を指し示す間係≠−タ対象をホールドして いる。この関係データ対象は関連属性データ対象として“ＸＹＺ”を有している ９名前“ｘＹｚ″はエレメント４６８である。同様にして、エレメント４５０は 、第４図にはエレメント４５０として表わされている第３図のＡＮＤゲートの番 号（３２０）であるエレメント４６２を指し示す関係データ対象を有している。

第４図は更に他の関係を示している６例えばＳｌ及びｓ２のような信号を表わす エレメント４７０．４７２．４７４、及び４７６は、一連の関係として表わされ ているリンクされたリストに編成されている。更に、属性データ対象４８０は属 性データ対象４７０を指し示す関係をもホールドしており、この対象によって表 わされている信号が対象４５０によって表わされているゲートへの１つの入力で あることを示している。エレメント４７０によってホールドされているエレメン ト４８０を指し示す関係によって、逆関係も表わされている。属性データ対象４ ７０によって表わされている信号の名前は、属性データ対象４７０によってホー ルドされ名札“Ｓｌ”を表わしている属性データ対象４９０を指し示している関 係によって表わされている。

整数３５或は文字“Ｋ”のような簡単な定数はエレメントであり、頂点によって ホールドされた単一の属性データ対象によって表わすことが好ましい、また文字 列を、頂点によってホールドされたエレメントとすることも好ましい、しかし、 文字列エレメントはその構成文字対象に対する関係のリストをホールドする。即 ち、例えば、列“ＣＡＴ”はあるエレメントデータ対象によって表わすことがで き、このエレメントデータ対象は他の３つのエレメントデータ対象即ちエレメン ト、即ち文字“Ｃｏ、“Ａ′、及び“Ｔ”に対する第１の関係を保持する０文字 列“ＣＡＴ”を形成するためのこれらの文字エレメントの順序付けは、第１の関 係をあるリストに編成する第２の関係によって表わすことができる。

例えば、“ＣＡＴ”から“Ｃｏまでの関係は、関連データ対象が“ＣＡＴ”から “Ａ”までの関係である関係をホールドする。

Ｂ、ソフトウェアユーティリティ編 第５Ａ図は本発明の好ましい実施例によるソフトウェアシステムの若干の成分の ブロック線図である。これらの成分のあるものの動作に関しては後章で説明する 。第５Ａ図に関しては、これらの成分の各成分の主機能及びこれらの成分の他の 成分に対する関係を説明するに留める。

第１図に示す共通データ構造１４０は、主データベース５１０及び従データベー ス５２０を含むことが好ましい、共通データベース１４０に対する何等かの更新 は主データベース５１０に対して行われ、後刻そのコピーが従データベース５２ ０の次のパージョンを形成する。

第５Ａ図において、５３０及び５６０は、第１図の応用プログラム１３０．１３ ２及び１３４のような２つの応用プログラムを表わす０本発明によれば、データ 処理システムは、特定された関係データ対象の関連属性データ対象を共通データ 構造から検索する手段を含む、第５Ａ図に示す応用プログラム５３０に関しては 、検索プログラム５８０がこの検索機能を遂行する。従データベース５２０は、 実際のデータを応用プログラム５３０及び５６０に供給する。

検索プログラム５８０の部分の実施例の詳細は後章で説明する。

しかし、要約すれば、応用プログラム５３０は検索プログラム５８０に対して関 係データ対象を特定し、その特定された関係データ対象の単一の或は複数の関連 データ対象を請求する０次で検索プログラム５８０はその特定された関係データ 対象に関して従データベース５２０をサーチする。特定された関係データ対象が 得られると、検索プログラム５８０はこの或はこれらの関連属性データ対象をコ ピーし、関連データ対象を応用プログラム５３０に適用できるフォーマ７）に配 置するのに必要な何等かの変換を遂行し、そしてフォーマントされた関連データ 対象を応用プログラム５３０に渡す。

本発明のデータ構造は、特定された属性データ対象にホールドされた関係を有す る全ての属性データ対象を、共通データ構造から検索する手段をも含む、再び、 第５Ａ図に示す好ましい実施例の検索プログラム５８０はこの型の検索を遂行す る。その動作を説明すれば、応用プログラム５３０は属性データ対象を特定し、 この特定された属性データ対象にホールドされている他の全ての属性データ対象 を請求する０次で検索プログラム５８０はその要求を適切なフォーマントに変換 し、この特定された属性データ対象が位置付けされるまで従データベース５２０ をサーチする。特定された属性データ対象が位置付けられると、検索プログラム ５８０はこの特定されたデータ対象によってホールドされている全ての属性デー タ対象のコピーをめる０次で検索プログラム５８０はこれらのホールドされた属 性データ対象を応用プログラム５３０に適用できるフォーマントに変換し、変換 されたこれらの属性データ対象を応用プログラム５３０へ送る。

本発明によれば、データ処理システムは、特定された型の全ての属性データ対象 から共通データ構造情報を検索する手段をも含む０例えば応用プログラム５３０ からの請求に応答して、検索プログラム５８０は特定された型の金属性データ対 象に関して従データベース５２０内の共通データ構造１４０をサーチする。これ らの特定された属性データ対象を見出すと、これらの属性データ対象は抜出され 、適切なフォーマントに変換され、検索プログラム５８０へ送られる。

検索プログラム５９０は、検索プログラム５８０と同一の機能を遂行することが 好ましい。検索プログラム５８０と５９０との間の唯一の機能差は、情報の応用 プログラム５３０及び５６０への送り方に過ぎない。例えば、検索プログラム５ ９０は上述した一連の検索を遂行し、得られたデータを応用プログラム５６０に 通するフォーマントに変換し、このデータをファイル５９５内へ書込むことがで きる。応用プログラム５６０はファイル５９５から検索されたデータを続出す。

更に本発明によれば、新らしい属性データ対象を、それらをホールドする属性デ ータ対象となることが望ましい属性データ対象の識別から、共通データ構造内に 作成する手段をも含む、この作成手段は、ある関連データ対象の識別から新らし い属性データ対象を作成し、作成された関係データ対象を形成させる手段も含む 。

第５Ａ図は、本発明の好ましい実施例により新らしい属性データ対象を共通デー タ構造１４０内に作成する種々の方法を示す。

例えば、応用プログラム５３０は、該プログラム５３０内のデータベースから必 要情報を受けているコンバータプログラム５４０を使用し、主データベース５１ ０内に共通データ構造を形成するのに必要な情報を抜出し、ホールダ属性データ 対象及び関連データ対象を決定することによって属性データ対象を作成する。コ ンバータプログラム５４０はこれらの属性データ対象を主データベース５１０へ 送って記憶させる。

別の例として、応用プログラム５３０のデータベース内に作られた情報を、以下 のようにして主データベース５１０へ送ることができる。先ず、応用プロンラム ５３０は更新同期装置５５０へある要求を送る。この要求は所望の更新を特色付 ける情報を含む。

次で更新同期装置５５０は、応用プログラム５３０からの情報を使用して共通デ ータ構造１４０内に属性データ対象を作成することによって主データベース５１ ０を変更するようにコンバータプログラム５４０に通知して主データベース５１ ０を変更させる。

更新同期装置５５０は、更新要求内の特色付は情報に従って主データベース５１ ０内に属性データ対象を作成するのにも使用できる。

コンバータプログラム５７０は、コンバータプログラム５４０と同一の機能を遂 行することが好ましい。第５Ａ図に示すコンバータプログラム５４０と５７０と の間の唯一の差異は、応用プログラム５６０からの情報の送られ方である。応用 プログラム５６０は先ずファイル５６５内へデータを書込む。コンバータブ口グ ラム５７０は、更新同期装置５５０から信号を受けた後、ファイル５６５を読み 、ファイル５６５内のデータに従って主データベース５１０の共通データ構造１ ４０内に属性データ対象を作成する。

主データベース５１０の変更、及びコンバータプログラム５４０及び５７０への 信号送信は、主データベース５１０の共通データ構造１４０及び従データベース ５２０が応用プログラムによって使用されている間でも主データベース５１０が 規則通りに且つ非中断的に更新されるように更新同期装置５５０によって遂行さ れる。コンバータプログラム５４０或はコンバータプログラム５７０による主デ ータベース５１０に対する変更が完了すると、主データベース５１０の共通デー タ構造１４０のコピーが従データベース５２０の新バージョンとして利用可能と なり、この新バージョンに検索プログラム５８０及び５９０がアクセス可能とな る。

本発明は、共通データ構造から特定された属性データ対象を除去する手段をも含 む、これは時には消去動作として知られており、共通データ構造が階層的データ 構造であるために容易に遂行される。好ましい実施例においては、コンバータプ ログラム５４０のようなデータベース変更プログラムは、先ず応用プログラム５ ３６から受けた要求に応答して特定された属性データ対象を位置付ける０次でコ ンバータプログラム５４０はその属性データ対象を共通データ構造１４０から除 去する。

更に、応用プログラム５３０は、特定された属性データ対象を除去することを要 求できるだけではなく、その属性データ対象に関する包含の木全体を除去するこ とを要求することも可能である。

応用プログラム５３０からのこれらの要求に応答して、コンバータプログラム５ ４０はこの特定された属性データ対象を位置付けする。またコンバータプログラ ム５４０は、この特定された属性データ対象によってホールドされている全ての 属性データ対象の位置付けも行う、コンバータプログラム５４０は、ホールド関 係を検査して初めに特定された属性データ対象によって直接的に或は間接的にホ ールドされている全ての属性データ対象を位置付けしながら包含の木を通って行 く、コンバータプログラム５４０は位置付けした全ての属性データ対象を共通デ ータ構造１４０から除去する。

第５Ｂ図は、共通データ構造１４０′内のソフトウェアシステムの諸成分の変形 実施例のブロック線図である。破線によって囲まれている要素、即ち応用プログ ラム５３０、コンバータプログラム５４０及び検索プログラム５８０は、第５Ａ 図の対応要素と木質的に同一である。

第５Ｂ図の共通データ構造１４０′は主データファイル５１５及びスナップショ ットデータファイル５２５を包含する。共通データ構造１４０の従データベース ５２０と同様に、共通データベース１４０′は主データファイル５１５の少なく とも１つのバージョンの完全コピーを包含する。しかし、従データベース５２０ とは異なり、スナップショットファイル５２５は更新済の主データファイル５１ ５の複数部分を記憶することによって主データファイル５１５の複数のバージョ ンを表わすように設計されている。

これに対して従データベース５２０は主データベース５１０の現行バージョンの 完全コピーを表わすように設計されている。共通データ構造１４０′は、共通デ ータ構造１４０′の制御に必要なデータ、及び若干の応用プログラムによる構造 １４０′への同時アクセスを回正するための若干のロックを含む制御ファイル５ ５５をも含む、これらのロックの中の変更ロック５６８及びＤＢＣロック５６９ の２つを示してあり、これらの詳細に関しては後述す更に、共通データ構造１４ ０′と第５Ｂ図に破線によって示すソフトウェアとの間のインターフェイスを提 供する記憶管理ソフトウェア５６６が示されている。記憶管理ソフトウェア５６ ６の複数の部分の好ましい実施例の詳細は後述する。

Ｃ１共゛データベースのデータ構浩表六本発明の好ましい実施例においては、共 通データ構造１４０或は１４０′は、プログラム１３２及び１３４のような応用 プログラムと共にメモリ１２０内に記憶される。この配列は、共通データ構造１ ４０の複数のファイル内への好ましい編成的な構造として第６図に示しである。

第６図に示すように、メモリ１２０の共通データ構造１４０部分は属性ファイル ６００、ディクショナリファイル７００及び索引ファイル８００を含むことが好 ましい。これらのファイルを詳細に説明する前に、システム全体の理解を容易な らしめるために、ファイルの機能に関して概要を説明する。

属性ファイル６００は全ての属性データ対象を、より正確には各属性データ対象 毎のメモリ領域或はデータエントリを含むことが好ましい、属性ファイル６００ の好ましい実施例においては、エレメントデータ対象及び関係データ対象の両者 を含む属性データ対象は、プログラム１３０．１３２及び１３４のデータベース 内の情報と矛盾がないように編成される０例えば、詳細を後述する技法において は、データベースのノードデータ及びノードデータ記述子はエレメントデータ対 象及び関係データ対象に対応し、所望の属性データ対象へのアクセス及びそれら の識別を容易ならしめるように計画された論理的技法で階層的なホールド関係を 属性データ対象に付課する。

ディクショナリファイル７００は、頂点及び他の文脈のためのデータエントリ、 並びに属性ファイル６００内の属性データ対象の型を記述する情報を含むことが 好ましい、頂点及び文脈のためのデータエントリは属性ファイル６００内に記憶 させても差支えないが、ディクショナリファイル７００は主として読出し専用フ ァイルとして取扱われ、また頂点及び文脈データは一般的に変化するものではな いために、本発明の好ましい実施例においてはディクショナリファイル７００内 に記憶させである。

索引ファイル８００は、属性ファイル６００内の属性データ対象に迅速なアクセ スを得るためにＣＰＵＩ　１０が使用する情報を含むことが好ましい、索引ファ イル６００は、データ構造１４０の利用効率を高めるために、実際の多くのデー タ構造１４０の実施例を利用するように設計されている。

本発明の好ましい実施例においては、共通データ構造１４０内の属性ファイル６ ００、ディクシツナリファイルア００、及び索引ファイル８００は、ディスクの ようなメモリ１２０の“永久”メモリ区分内に保持されている。ＣＰＵ１１０が ファイル６００゜７００及び８００の若干の部分にアクセスする必要を生じた時 は、ＣＰＵＩ　１０はこれらの部分を半導体ＲＡＭメモリのような一次メモリへ 転送する。永久メモリは一次メモリに比して比較的大きく、ＣＰＵＩ　１０は永 久メモリと一次メモリとの間のデータの流れを周知の仮想メモリ技術を使用して 、且つ以下に説明する好ましい技法で管理することが好ましい。

共通データ構造１４０内の各ファイル内のデータはマクロへ一ジに集群させるこ とが好ましい、各マクロページは、１つのファイルの相接する６４にバイト部分 であり、このファイルは５１２バイトの１２８ページからなる０本発明の実施例 においては、属性ファイル６００、ディクショナリファイル７００、及び索引フ ァイル８００は１６にマクロページまで記憶可能にしである。

本発明の好ましい実施例においては、属性ファイル６００、ディクショナリファ イル７００、及び索引ファイル８００内の標準単位は４バイト即ち３２ビツトか らなるロングワードである。ファイルのページ或はマクロページは、典型的には 各々数ロングワードの群からなる数ブロックを含む、このロングワードはポイン タとして使用されることが多い。

第７図は、ポインタとして使用される３２ビツトのロングワード６１５を示す、 好ましい実施例においてはＣＰＵＩ　１０が共通データ構造１４０のファイル内 の各データプロツク毎にロングワードポインタを誘導する。

好ましい実施例によれば、ロングワードポインタ６１５は最左ビット即ち一時的 フイールド６１６を含み、このフィールドはこのポインタが“指し示す”メモリ のブロックが永久データ構造の一部ではないか否かを表わし、永久データ構造の 一部ではない場合にはポインタの残余は一部メモリ内のブロックの仮想アドレス である。第７図に示す他のフィールドは、ブロックが永久メモリ内に位置付けら れた永久データ構造の一部であって、必要に応じて一部メモリへ転送される場合 にのみ適用されるものである。

種類フィールド６１８は２ビツト長であり、ロングワードポインタ６１５が指し 示すブロックの種類を指定する０例えば、好ましい実施例においては、このフィ ールドは指し示されたブロックが属性ファイル６００１デイクシツナリフアイル ア００、或は索引ファイル８００であることを表わす。

次のフィールド、即ちＲフィールド６２０は１ビツト長である。

Ｒフィールド６２０は、付加的な種類のポインタを本発明に使用できるようにす るために、現在では保留されている。

ロングワードポインタ６１５の最後のフィールドはオフセントフィールド６２２ であり、ロングワードポインタ６１５の最古の２８ビツトからなる。オフセント フィールド６２２は、参照された情報の位置を参照されたブロックを包含するフ ァイルの始めからのロングワードオフセットとして特定することによって該情報 を識別する。

好ましい実施例に使用されるポインタは本発明の効果に必要とされるものだけで はない０例えば、ポインタは対応項目の位置を直接的に表わすことも可能であり 、或はその位置を間接アドレッシング或は索引を付したアドレッシングのような 手順を介して間接的に表わすことも可能である。

１、層性スニ不ｙ 第８図は、属性ファイル６００の構成要素部分のより詳細なブロック図である。

属性ファイル６００は若干のエレメントブロックを含む、しかし簡略化のために 、またこの項の説明の都合上１つのエレメントブロックのみを図示してあり、エ レメントブロンクロ０２によって表わされている属性データ対象を以下に“表示 されたエレメント３と呼ぶ、このエレメントブロックは属性ファイル６００の好 ましい実施例におけるエレメント属性データ対象を表わすための基本データ単位 である。エレメントブロック６０２は、１つのエレメント見出しブロック６０４ ．１つ或はそれ以上の関係サブブロック６０６　（随意）、及び１つ或はそれ以 上の°ホールドされた”エレメントサブブロック６０８　（随意）を含むことが 好ましい、エレメント見出しブロック６０４に続くエレメントブロック内の相接 するサブブロックの数及び型に関する情報はディクショナリファイル７００によ って或はコンパイラの使用を通して与えることが好ましい、これらのブロック及 びサブブロックの詳細に関しては後述する。

属性ファイル６００は、複数関係ブロック６１０をも含むが、簡略化の目的から それらの１つのみを図示しである。各複数関係ブロック６１０は、データ構造１ ４０内の非階層的関係を表わす１つ或はそれ以上の関係データ対象に関するデー タを包含する。

複数関係ブロック６１０は、１つの複数関係見出しブロック６１２及び１つ或は それ以上の複数関係サブブロック６１４を含むことが好ましい。これらのブロッ ク及びサブブロックの詳細も後述する。

最後に、属性ファイル６００は、複数のインスタンスルートブロック６２５及び 複数の索引ディレクトリブロック６３０を含むが、簡略化のためにそれぞれ１つ しか図示してない、これら２つのブロックの詳細に関しても後述する。

第９図は、本発明の好ましい実施例におけるエレメント見出しブロック６０４の ブロック図である。この実施例においては、データ構造１４０内の各属性データ 対象は、エレメント見出しブロック６０４のようなエレメント見出しブロックに よって表わされる０図示のように、エレメント見出しブロック６０４は６つのロ ングワード９００．９２０．９２５．９３０．９３５、及び９４０を含む。

ロングワード９００は空フィールド９０５、大きさフィールド９１０、及び類フ ィールド９１５を含むことが好ましい、大きさフィールド９１０はエレメント見 出しブロック６０４内のロングワードの数を示す、類フィールド９１５は、ブロ ック６０４がエレメント見出しブロックであることを指示する。

ロングワード即ち型限定ポインタ９２０は表示されたエレメントのエレメント型 情報を包含する。型情報は、例えば頂点、他の文脈、及びこれらの文脈のための 識別名を確立することが可能な特別なコンパイラを使用することによって、若干 の他の手段に共通データ構造を利用可能ならしめている。

次のポインタ９２５及び前のポインタ９４０は、表示されたエレメントと同一の ホールダ属性データ対象を有する属性データ対象のエレメントブロックの位置を 指定する。本発明の好ましい実施例においては、同一のホールダ属性データ対象 を有する共通型の属性データ対象は、これらのロングワードポインタの使用によ ってリンクされる。次のポインタ９２５及び前のポインタはこのようなリンクを 行う。

エレメント見出しプロンクロ０４のホールダボインタ９３０及び参照ポインタ９ ３５は、表示されたエレメントと属性ファイル６００内に表わされている他の属 性データ対象との間の階層的にホールドされた関係及び非階層的関係をそれぞれ 指示する。ホールダボインタ９３０はある属性データ対象のエレメント、即ち表 示された属性データ対象がホールドされた関係を有する“ホールダ対象”を指し 示す。即ち、ホールダボインタ９３０は、エレメントブロック６０２によって表 わされる属性データ対象をホールドしている属性データ対象のエレメントブロッ クを指し示す。

参照ポインタ９３５は、属性ファイル６００内の複数関係ブロック（例えば第８ 図のブロック６１０）のシーケンスの最初を指し示す。これらの複数関係ブロッ クは、表示されたエレメントが関連データ対象であるという関係をホールドして いる属性データ対象を指示する。複数関係ブロックの詳細を以下に説明する。

対象ブロック６０２（第８図）の関係サブブロック６０６及び“ホールドされた ”エレメントブロック６０８は、エレメント見出しブロック６０４に接する相接 したサブブロックであることが好ましい、各対象ブロック毎に、若干の関係サブ ブロック及び若干の“ホールドされた”エレメントサブブロックを設けてよい。

関係サブブロック６０６は、表示されたエレメントによってホールドされている 単独関係の関連属性データ対象を特定する。“ホールドされた”エレメントサブ ブロック６０８は、表示されたエレメントとホールドされた関係を有する属性デ ータ対象を特定する０表示された対象の関係サブブロック６０６及び“ホールド された”エレメントサブブロック６０８は、多分混乱した順序で出現しよう。

第１０Ａ図及び第１０Ｂ図は、関係サブブロック６０６の好ましい実施例のブロ ック図である。関係サブブロック６０６は２種類の情報の１つを包含することが 好ましい、もし関係サブプロ。

り６０６が関係ポインタであれば、それはロングワード即ち関係ポインタ１００ ０　（第１０Ａ図）として現われ、単一の関連属性データ対象のエレメントブロ ック、或は表示されたエレメントによってホールドされた関係にある若干の関連 属性データ対象を戯れかを特定する。

変形として、関係サブブロック６０６は、数或は日付、或は記号列を識別する数 値／列識別名であってもよい。もし関係サブブロック６０６が数値或は日付識別 名であれば、それは二重ロングワードとして現われる。＠別名１０５０は文字列 に関する属性データ対象を表わすエレメントブロックを指し示すポインタであっ ても、或はそれ自体が整数、或は浮動点定数或は日付であってもよい。

第１１図は、第８図に示す“ホールドされた”エレメントサブブロック６０８の 好ましい実施例のブロック図である。サブブロックロ０８はロングワードポイン タ１１００．１１１Ｏ１及び１１２０を含む、ロングワード即ち最初ポインタ１ １００は、表示されたエレメントとホールドされた関係を有する属性データ対象 の選択された順序内の最初のエレメントデータブロックを識別する。もし１つの 属性データ対象だけがその関係を有していれば、最初ポインタ１１００はその属 性データ対象を識別する。ロングワード即ち最後ポインタ１１１０は、上述のよ うな属性データ対象の選択された順序の最後を識別するが、もし１つのホールド された対象だけが存在する場合には、最初の属性データ対象を識別することにな る０表示された対象とホールドされた関係を有する属性データ対象の選択された 順序とは、これらの“ホールドされた”属性データ対象の次のポインタ及び前の ポインタによって限定されるリンケージである。

ロングワード即ち索引ポインタ１１２０は、索引ディレクトリブロックを指し示 すポインタである。これらのブロックの詳細は後述するが、その説明から索引ポ インタ１１２００機能は理解されよう。

前述のように、複数関係ブロック６１０は、若干の関連属性データ対象を識別し なければならない場合に効果的な参照手段となる。各複数関係ブロック６１０は 、１つの複数関係見出しブロック６１２及び１つ或はそれ以上の複数関係サブブ ロック６１４を含む。

第１２図は、本発明の好ましい実施例による複数関係見出しブロック６１２のブ ロック図である。複数関係見出しブロック６１２はロングワード１２００．１２ １０．１２２０、及び１２３０からなる。ロングワード１２００は、使用フィー ルド１２０３、エントリフィールド１２０５、大きさフィールド１２０７、及び 類フィールド１２０９を含む。使用フィールド１２０３は、有効ポインタを包含 できる見出しブロック６１２の複数関係サブブロック６１４の最後のサブブロッ クを指示する。エントリフィールド１２０５は、複数関係ブロック６１０内に含 まれる見出しブロック６１２に続く相接する複数関係サブブロック６１４の数（ これらのサブブロックがポインタを包含すると否とに拘わらず）を包含する。大 きさフィールド１２０７及び類フィールド１２０９はそれぞれ、複数関係ブロッ ク６１０内のロングワードの数、及びこの見出しブロックが複数関係見出しブロ ックであることを指示する。

ビットマスクフィールド１２３０は、どのサブブロック６１４が有効ポインタを 包含しているかを指示する。即ち、使用フィールド１２０３は有効ポインタを有 し得る相接するサブブロックの最大数を指示するが、これらの全てのポインタが 有効である必要はない、ビットマスクフィールド１２３０はこの後者の情報を供 給する。

複数関係ブロックは、同一のホールダ属性データ対象を有する属性データ対象の エレメントブロックのリンケージと同様にしてリンクされている。即ち、見出し ブロック６１２は、複数関係ブロックの選択された順序内の次の及び前の複数関 係ブロックをそれぞれ特定する次のロングワードポインタ１２１０及び前のロン グワードポインタ１２２０を含む、この順序内の複数関係見出しブロックは全て 同一ホールダ属性データ対象によって使用される。

第１３Ａ図及び１３Ｂ図は、２種類の複数関係サブブロック６１４の好ましい実 施例のブロック図である。もし関連属性データ対象が列数字、或は日付以外のエ レメント属性データ対象であれば、関係ポインタ１３００はその属性データ対象 のエレメントブロックを指し示すロングワードである。もし関連属性データ対象 が数、或は日付、或は文字列であれば、浮動点数、或は日付、或は文字列を表わ すブロックを指し示すのに数値７列フィールド１３１０が使用される。

本発明の教示によるエレメントブロック６０２及び複数関係ブロック６１０の作 成及び使用の詳細を以下に説明する。容易に理解できる如く、上述の属性ファイ ル６００のデータ構造表示は、本発明による属性データモデルの原理を実現して いる。

インスタンスルートブロックの内容及び構造を第１４図に示す。

エレメント型の１インスタンス”とは、全てが同一のエレメント型を有し且つ全 てが同一のホールダ属性データ対象を有している一組の属性データ対象を云う、 これらの群の属性データ対象を屡々参照することが決定されている。即ち、イン スタンスルートブロックは、これらの属性データ対象にアクセスする効率的なメ カニズムを提供するために開発されたのである。インスタンスルートブロック６ ２５を属性ファイル６００内に位置付けることによって、このブロックを本質的 には読出し専用のディクショナリファイル７００内に位置づけるよりも容易に動 的に更新することが可能になる。

インスタンスルートブロック６２５は、該ブロックロ２５内のロングワードの数 を指示する大きさフィールド１４１３、及び該ブロック６２５がインスタンスル ートブロックであることを指示する類フィールド１４１６を含むロングワード１ ４１０を含む。

インスタンスルートブロックロ２５は、何れかの線内の最初の属性データ対象を 指示する最初ポインタ１４２０、及び最後の属性データ対象を指示する最後ポイ ンタ１４３０をも含む、ボインタ１４２０及び１４３０は、これらの属性データ 対象のエレメント型ブロック（ディクシツナリファイルア００に関連して後項で 説明する）の位置を識別することが好ましい。

ブロックロ２５の索引ポインタ１４４０は、属性ファイル６００内の索引ディレ クトリブロック（後述）を指し示し、それによって属性データ対象のリンクされ たリストの各インスタンス、インスタンスルートブロック６２５のポインタ１４ ２０及び１４３０によって特定される最初と最後の対象へ容易にアクセスするこ と第１５図は、ディクショナリファイル７００の好ましい実施例のブロック線図 である。この好ましい実施例においては、ディクショナリファイル７００内の共 通データベース構造の部分は頂点ブロック７０２、他の文脈ブロック７０４及び ７０６、エレメント型ブロック７１０及び７１２、属性型ブロック７１４及び記 号表７１６を含む。

頂点ブロック７０２は、頂点データ対象を表わす特別な種類の文脈ブロックであ る０本発明の属性データモデルの基本規則によれば、頂点対象は文脈或は属性デ ータ対象をホールドするが、それ自体が文脈或は属性データ対象によってホール ドされることはない。

文脈ブロック７０４及び７０６は、第４図に関して説明したＣＰＵ４２０のよう な文脈を表わすのに使用される。エレメント型ブロック７１０及び７１２は、そ れぞれ、属性ファイル６００内の属性データ対象の異なる型を表わす、属性デー タ対象の各異なる型缶に、対応するエレメント型ブロックが存在することが好ま しい、属性型ブロック７１４は、特定された型の属性データ対象とこれらの属性 データ対象の関連との間に存在する関係の型に関する情報を含む、記号表７１６ は、ディクショナリファイル７００の種々のブロックによって表わされている頂 点、文脈、エレメント型、及び属性型のための識別名を包含する。

上述のように、頂点ブロック７０２、及び文脈ブロック７０４及び７０６はディ クショナリファイル７００内ムニ記憶させることが好ましい、何故ならば、ディ クショナリファイル７００は通常は読出し専用ファイルだからである。極めて類 領し、従って以下に一緒に説明する頂点ブロック７０２、及び文脈ブロック７０ ４及び７０６は一般に変更されることはなく、従ってこれらは主として読出し専 用ファイルである。

第１６図は、頂点ブロック７０２、或は文脈ブロック７０４或は７０６の何れか の好ましい実施例の基本構造及び内容のブロック図である。頂点ブロックと文脈 ブロックとが酷イ以しているため文脈ブロックのファイル構造のみを説明するが 、頂点ブロックのファイル構造も類似であることを理解されたい。

文脈ブロック７０４において、ロングワード１６００は大きさフィールド１６０ ３及び類フィールド１６０６を含む、大きさフィールド１６０３は文脈ブロック ７０４のロングワードの数を指示し、類フィールド１６０６はこのブロックが頂 点ブロック或は文脈ブロックの何れかであることを指示する。

ロングワード即ち名前ポインタ１６１０は、ブロック７０４によって表わされて いる頂点或は他の文脈のための識別名を特定する記号表７１６のエントリを識別 する（第１４図参照）ロングワード即ち包含された最初の文脈ポインタ１６２ｏ は、文脈ブロック７０４によってホールドされた一組の文脈の最初の文脈ブロッ クを差し示す、以下に説明するポインタ１６３ｏ及び１６４０は、頂点ブロック ７０２においては空である。

文脈ブロック７０４においては、ロングワード即ち次のポインタ１６３０は上述 の順序付けられた組の文脈の中の次の順序の文脈を指し示す、ロングワード即ち ホールダボインタ１６４０はブロック７０４０文脈をホールト′シている文脈或 は頂点の文脈ブロック或は頂点ブロックを指し示す。

ロングワード即ち最初のエレメント型ポインタ１６５０は、順序付けられたエレ メント型ブロックの中の最初のブロック、例えばブロック７１０或７１２を指し 示す。この順序付けられた組のエレメント型ブロックは、文脈ブロック７０４に よって表わされる文脈によってホールドされている属性データ対象のエレメント 型を表わす、この順序付けられた組は、エレメント型ブロックに関して後述する ようにリンクされたリストであることが好ましい。

ロングワード即ち最初の記号ポインタ１６６０は、ブロック７０４によって表わ される文脈によってホールドされている他の文脈、対象或は関係の順序付けられ た組の記号の中の最初の記号として指定されている記号表７１６のエントリを識 別する。

頂点データ対象或は文脈属性データ対象が包含の木の最初の、即ち頂上部分とな ることが好ましい。文脈内の特定されたエレメントの属性データ対象へのアクセ スは、頂点から包含の木へ進入し且つ所望の属性データ対象が見出される文脈ま で木を通って進行することによって達成することができる０本発明の好ましい実 施例においては頂点及び文脈はディクショナリファイル７００内の頂点ブロック 及び文脈ブロックによって表わされているから、頂点或は文脈を通してデータ構 造の好ましい実施例内へ進入するには、ディクショナリファイル７００内の頂点 ブロック或は文脈ブロックに記憶されている情報にアクセスする必要がある。本 発明による別の実施例においては、ディクショナリファイルを通るアクセスを必 要としないであろう。

第１７図は、エレメント型ブロック７１０或は７１２のようなエレメント型ブロ ックの好ましい実施例のブロック図である。この説明の都合上、エレメント型ブ ロック７１２のみを説明するが、エレメント型ブロック７１０も同一成分を有し ていることを理解されたい。

属性ファイル６００内のエレメントの冬型毎に、ディクショナリファイル７００ 内にエレメント型ブロック７１２が存在する。

好ましい実施例においては、ある型のエレメントを属性ファイル６００内に作成 するためには、その型のエレメントが存在し得ることの宣言を前置しなければな らない。特定された型の対象の存在を表わすためのメカニズムがエレメント型ブ ロック７１２である。

エレメント型ブロック７１２は、属性ファイル６００内の若干のエレメントブロ ックに関する一般的パラメータ、例えばこれらのエレメントブロックの長さに関 する情報及び所与のエレメント型のインスタンスに関する情報を包含する。

エレメント型ブロック７１２の内容及び構造は第１７図に示す通りである。エレ メント型ブロツク７１２内に含まれているのは、大きさフィールド１７０３及び 類フィールド１７０６を有するロングワード１７００である。他のデータブロッ クの場合と同様に、大きさフィールド１７０３はエレメント型ブロック７１２内 のロングワードの数を指示し、また類フィールドはブロック７】２がエレメント 型ブロックであることを指示する。

ロングワード即ちノードフオームフィールド１７１０は、エレメント型ブロック ７１２によって特定される型の属性データ対象が所定の順序を有しているか否か 、及びこの型のエレメントが文脈によってホールドされているのか或は他のエレ メントによってホールドされているのかを指示する。ロングワード即ち名前ポイ ンタ１７２０は、この型の属性データ対象の名前即ち識別名を有する記号表７１ ６のエントリを指し示す、インスタンス長フィールド１７３０は、ブロック７１ ２によって特定される型の属性データ対象のエレメントブロック６０２の長さを 特定する。

前述のように、同一の文脈によって包含される（即ち同一文脈の包含の木の中に ある）属性データ対象の型のためのエレメント型ブロックは、順序付けられた組 の中に編成することが好ましい。

実際にはこれらのブロックは、次のエレメント型ブロックを特定するロングワー ド即ち次のポインタ１７４０を使用してリンクすることが好ましい。

ロングワード即ち文脈ポインタ１７５０は、ブロック７１２によって特定される 型のエレメントが包含されている文脈ブロック或は頂点ブロックを指し示す、ロ ングワード即ちインスタンスポインタ１７６０は、属性ファイル６００内のこの 型のエレメントの各インスタンスへのアクセスを提供するポインタを包含する属 性ファイル６００内のインスタンスルートブロックを指し示す。

エレメント型ブロック７１２の残余のフィールドには、ロングワード即ち属性ポ インタ１７７０が含まれる。属性ポインタ１７７０は、このエレメント型によっ て包含される関係型の最初の関係型を指し示す。

ディクショナリファイル７００は、エレメント型ブロック７１２によって特定さ れる型の属性データ対象とそれらの関連属性データ対象との間に存在し得る関係 の型を特定するためのメカニズムをも提供する。このメカニズムは、ブロック７ １４　（第１５図参照）のような属性型ブロックを含む。

第１８図は、本発明の好ましい実施例による属性型ブロック７１４のブロック図 を示す、属性型ブロック７１４はロングワード１８００．１８１０．１８２０． １８３０．１８４０．１８５０、及び１８６０を含む、ロングワード１８００は 、ブロック７１４内のロングワードの数を指示する大きさフィールド１８０３及 びそのブロック７１４を指示する類フィールド１８６０を包含する。

ロングワード即ちスタイル表示フィールド１８１０は、属性データ対象との関係 を特定する技法を表わす０本発明の好ましい実施例によれば、属性データ対象と それらの関連属性データ対象との間の関係は直接的に或は間接的に特定すること ができる。直接的に特定された関係即ち単独関係の場合には、エレメントブロン クロ０２内の関係サブブロック６０６（第７図及び第１０Ａ図参照）は関連属性 データ対象を指し示すポインタを包含する０間接的に特定された関係即ち複数関 係の場合には、参照された対象の対象ブロック６０２からアクセスされた複数関 係ブロック６１０の複数関係サブブロック６１４（第８図及び第１３図参照）は 関連属性データ対象を指し示すポインタを包含する。

ブロック７１４のロングワード即ち名前ポインタ１８２０は、属性型ブロック７ １４のための記号表７１６内の識別名エントリを指し示す、ロングワード即ちオ フセントフィールド１８３０は、この型の関係を表わす関係サブブロック６０６ のエレメントブロック６０２の始まりからのオフセント、或はこの型のエレメン トを表わすホールドされたエレメントサブブロック６０８のオフセントを包含す る。

所与のエレメント型のための属性型ブロックは、他のリンクされたブロックに関 して説明したようにして次のポインタ１８４０によってリンクされる。ロングワ ード即ちホールダボインタ１８５０は、属性型ブロック７１４によって特定され る関係の型をホールドする属性データ対象の型のエレメント型ブロック７１２を 指し示す、ロングワード即ち関連型ポインタ１８６０もエレメント型ブロックを 指し示すが、このエレメント型ブロックは属性型ブロック７１４がある関係に一 致する場合に関連属性データ対象の型を特定するエレメント型ブロックである。

（３）見■スニ盃土 索引ファイル８００は、共通ホールダボインタ対象を共有する属性データ対象に アクセスする別の効率的な且つ直接的な手段を提供する。即ち、索引ファイル８ ００は、独特なキー値が割当てられている若干の属性データ対象にアクセスする ための手段を提供する。

好ましい実施例においては、索引ファイル８００は木構造を有する少なくとも１ つの索引に編成される若干の索引技ブロックからなる。索引の枝ブロックは、そ れぞれが異なる組のキー値に対応する葉ブロックを含む。ある属性データ対象の ための各キー値は異なる組のキー値の１つだけの中にあるので、１つの葉ブロッ クだけがそのキー値との一敗を有し、そのキー値が割当てられている属性データ 対象を有する。

葉ブロックは複数のポインタを含み、各ポインタはその葉ブロックのキーイ直と 、その割当てられたキー（直のようなキー値を有する属性データ対象の属性ファ イル６００内の位置とに対応する。

所望の属性データ対象への迅速アクセスは、その所望の属性データ対象のキー値 を有する索引を挿入し且つ索引の木構造を通り該キー値と所望の属性データ対象 を指し示す対応ポインタとを有する葉ブロックに至る独特の経路を探知すること によって達成される。

従って好ましい実施例においては索引の木構造は、この木構造内への入口を提供 する根ブロックを含む、この根ブロックは複数の技ブロックへ“枝分れ”し、各 枝ブロックは若干の葉ブロックが対応する複数組のキー値の異なる、重なり合わ ない群に対応する。技ブロックは、根ブロックから１或はそれ以上の中央技ブロ フクを通り単一の葉ブロックに至る独特な経路を提供するように編成される（こ の葉ブロックはこの独特な経路が存在する対応組のキー値を有する）、根ブロッ ク、中央核ブロック及び葉ブロックをこのように編成すると、所望の対象のキー 値を含む対応組のキー値を有する葉ブロックを迅速に位置付けすることができる 。

それにより、そのキー値として該キー値を有する属性データ対象を指し示すポイ ンタは、その属性データ対象自体の位置付けと同様に、迅速に位置付けすること が可能である。

索引の根技、中央核及び葉ブロックは索引技ブロックによって表わすことが好ま しい、第１９図は索引技見出しブロック８２０及び若干の索引技サブブロック８ ３０からなる索引技ブロック８１０を示す。

第２０図は索引技見出しブロック８２０のブロック図である。

好ましい実施例においては、技見出しブロック８２０はロングワード２０００． ２０２０．２０４０、及び２０６０を含む、ロングワード２０００は核種類フィ ールド２００４、キー値フィールド２００８、大きさフィールド２０１２及び類 フィールド２０１６を含む。

核種類フィールド２００４は、索引技ブロック８１０が根ブロック、中央昧或は 葉ブロックの何れであるのかを特定する。キー値フィールド２００８は、サブブ ロック８３０において特定されているキー値の数を指定する。大きさフィールド ２０１２は枝ブロック８１０内のロングワードの数を指示し、類フィールド２０ １６はブロック８１０が索引技ブロックであることを指示する。

同一の幹ブロックを有する異なる索引技ブロック８１０が、同一の幹の指定され た次の技ブロックを指し示すロングワード即ち次のポインタ２０２０、及び同一 の幹の指定された前の枝ブロックを指し示すロングワード即ち前のポインタ２０ ４０を通してリンクされている。ロングワード即ち幹ポインタ２０６０は、索引 技ブロック８１０の幹ブロックを指し示す。

好ましい実施例においては、索引技見出しブロック８２０にはｌ或はそれ以上の 索引技すブプロンクが相接して後続している。

第２１図に示す索引技すブプロフク８３０はロングワード即ちキー値ポインタ２ １００及びロングワード即ち葉／対象ポインタ２１５０を含むことが好ましい、 キー値ポインタ２１００はあるキー値をホールドしている位置属性ファイル６０ ０を特定する。

もし索引ブロック８１０が葉枝ブロックであれば、その葉／対象フィールド２１ ５０はサブブロック８３０内の対応キー値フィールド２１００によって表示され たキー値を有する属性ファイル６００内の属性データ対象のエレメントブロック ６０２を指し示す、そうではなく、もし索引技ブロック８１０が技ブロックであ れば、葉／対象フィールド２１５０は葉ブロックに至る独特な経路内の技ブロッ クを指し示し、そのキー値の組は該枝ブロックのための組の群内にある。

好ましい実施例においては、各索引技ブロック８１０は順序付は索引として、或 はアクセス用索引としての何れかに用いられる。

順序付は索引は、規定の順序付は規則に従ってエレメントをリス６２５或はホー ルドされたエレメントサブブロックロ０８によって説明したように、エレメント のリスト内の場所に迅ｉ！ムこアクセスすることができる。アクセス用索引は、 現存するエレメントにキー値を使用して迅速にアクセスするために使用される。

本発明の好ましい実施例においては、順序付は及びアクセス用の両索引共、属性 ファイル６００の構成内容に関して概要説明した（第７図参照）索引ディレクト リブロック６３０の使用を必要とする。索引ディレクトリブロック６００のブロ ック図を第２２図に示す。

索引ディレクトリブロック６３０は、ロングワード２２１０．２２５０、及び２ ２８０を含む、ロングワード２２１０は大きさフィールド２２３０及び類フィー ルド２２４０を含み、これらのフィールドはそれぞれ索引ディレクトリブロック ６００内のロングワードの数及びこのブロック６００が索引ディレクトリブロッ クであることを指示する。ロングワード即ち順序付はポインタ２２５０は、ある 順序付は索引のインスタンスルートブロックを識別し、ロングワード即ちアクセ ス用ポインタ２２８０はアクセス用索引のルート技ブロックを指示する。

属性データ対象に迅速にアクセスするための索引を指定する索引ディレクトリブ ロック６３０へのアクセスは、インスタンスルートブロックロ２５或は“ホール ドされた°対象サブブロックロ０８の何れかを通して得られる。ある文脈によっ てホールドされている属性データ対象に関して、インスタンスルートブロック６ ２５の索引ポインタ１４４０は索引ディレクトリブロック６３０を指し示し、そ れによって特定された文脈によりホールドされた属性データ対象に容易にアクセ ス可能ならしめることが好ましい。

別の属性データ対象によってホールドされている属性データ対象に関しては、索 引ディレクトリブロック６３０は、ホールドされた対象の指定された最初と最後 の対象を特定する“ホールドされた”対象サブブロック６０８の索引ポインタ１ １２０を使用してアクセスされる。アクセス動作の詳細に関しては後述する。

Ｄ、データベースを 本発明の好ましい実施例を使用すると、作成、消去及びアクセスのような若干の 基本的データ操作を以下に説明する好ましい方法に従って容易に、且つ効率的に 遂行することができる。以下の説明では、コンパイラ或はディクショナリ７００ の使用によろうとよるまいと、属性データ対象の作成に必要な頂点或は文脈のよ うな若干のデータが既に共通データ構造１４０或は１４０′内に存在しているも のと仮定する。また、作成すべきエレメント及び関係、及び作成すべきエレメン ト及び関係に関するエレメント型及び関係型が既にデータ構造１４０に対して特 定されており、従って適切なエレメント型ブロック及び関連型ブロックが既に作 成されているものとする。

（１）王土ノ漫仁Ｕ１戊 第２３Ａ図及び第２３Ｂ図は、本発明によるエレメントデータ対象（“新エレメ ント”）を作成する好ましい方法の流れ図２３００である。応用プログラム１３ ２及び１３４に関して説明したように、これらのプログラムはメモリ１２０内に 共通データ構造１４０を形成するために必要な情報を包含しているか、或は本発 明の属性データモデルに従ってそれらのデータベースが既に編成されている。

もし応用プログラムデータベースを本発明の属性データモデルに変換するａ・要 があれば、エレメントを作成するためにこれらのプログラムから必要とされる情 報は“ノードデータ”の形状である。作成すべき属性データ対象は、応用プログ ラムからのノードデータに一致していてもよいし、或は作成のために特別に誘導 してもよい、従って、エレメントデータ対象の作成は応用プログラムからノード データの抜出し、及びノードデータから作成すべきエレメントデータ対象に一致 する型の決定を包含する（ステップ２３０５）。この抜出しの例は次項で説明す る。

一旦新エレメントの型が決定されると、新エレメントのエレメントブロンクロ０ ２の長さであるインスタンス長は、新エレメントの現存エレメント型ブロック７ １２のインスタンス長フィールド１７３０を参照することによって決定すること ができる（ステップ２３１０）。

インスタンス長が決定されると、エレメントブロック６０２のために記憶スペー スを利用できるか否かを調べるべく一部メモリが検査される。もし記憶スペース が存在しなければ、そのエレメントブロックのために一部メモリスペースが作ら れる（ステップ２３２０）、永久メモリ及び−次メモリにおけるＣＰＵＩ　１０ による記憶スペースの管理の詳細は後述するが、当分野の技術者には容易に理解 できる仮想メモリ及びマンピング技術を包含する。

−次メモリ内にエレメントブロック６０２のだめの記憶スペースが位置付けされ る、或は作成されると、そのスペースは新エレメントのエレメントブロック６０ ２のために割当てられる（ステップ２３２５）、次でＣＰＵＩ　１０はこの割当 てられた一部メモリスペースを指し示すポインタを形成する（ステップ２３３０ ）。

次で、新エレメントとそのホールダ属性データ対象との間にホールドされた関係 が存在するように、新エレメントのためのホールダ属性データ対象を選択する（ ステップ２３３５）、このホールダ属性データ対象の選択によって、ホールダ属 性データ対象のエレメントブロック６０２の°ホールドされた”対象サブブロッ ク６０８内に最初ポインタ１１００．最後ポインタ１１１０、及び索引ポインタ １１２０を位置付けすることが可能となる（ステップ２３３５）。

最初ポインタ１１００、最後ポインタ１１１０、及び索引ポインタ１１２０は、 新エレメントの存在を、今ホールダ属性データ対象によってホールドされたエレ メントとして表わすように更新することができる。勿論、新エレメントがホール ダ属性データ対象によってホールドされた最初のエレメント或は最後のエレメン トでなければ、これらのフィールドの更新は必要としない。

サブブロック６０８ポインタを位置付けした後、新属性データ対象のエレメント ブロック６０２内のエレメント見出しブロック６０４０次のポインタ９２５、前 のポインタ９４０及びホールダボインタ９３０を使用して新エレメントを新エレ メントと同一のホールダを有する他のエレメントのエレメントブロックにリンク し、新エレメントのホールダ属性データ対象を指示する（ステツ７”２３４０） 、これは新対象の対象見出しブロック６０４内にホールダボインタ９３０を位置 付けすることによって行われる。このホールダボインタ９３０は、作成されつつ ある対象のホールダ属性データエレメントのエレメントブロック６０２を見出し 得るメモリ領域を指し示す、更に、この新属性データ対象と同一のホールダ属性 データ対象を有する他の属性データ対象を指し示すエレメントポインタは、次の ポインタ９２５及び前のポインタ９４０として与えられる。もし新エレメントが 唯一のホールドされた属性データ対象であれば、エレメント見出しブロック６０ ４の次のポインタ９２５にポインタは与えられず、前のポインタ９４０としての 対象ポインタは存在しない。

既に位置付けされているホールダ属性データ対象の“ホールドされた１エレメン トサブブロツク６０８の最初ポインタ１１００、最後ポインタ１１１０、及び索 引ポインタ１１２０は、新エレメントの存在を表すように、またホールダ属性デ ータ対象との“ホールドされた°関係を表わすように更新される（ステップ２３ ４５）　。

これらの更新に関して、もし新対象がホールダ属性データ対象によつホールドさ れている最初の属性データ対象であれば、ホールダ属性データ対象のエレメント プロフクロ０２を指し示すポインタが最初ポインタ１１００に与えられる。また 索引ポインタ１１３０も、もし適切であれば、索引ディレクトリブロック６３０ を識別するように更新される。

方法２３００における新エレメントの作成を完了させるためには、エレメントブ ロック６０２の他のフィールドを初期化しなければならない０例えば、新属性デ ータ対象のエレメント見出しプロ、り６０４の型限定ポインタ９２０には、新エ レメントの型を特定するディクショナリファイル７００内のエレメント型ブロッ ク７１２を指し示すポインタのような適切なポインタを設けなければならない、 新エレメントの“ホールドされた”エレメントサブブロック６０８及び関係サブ ブロック６０６は、新属性データ対象が他の属性データ対象にホールドされるか 或は関係を有するに至る時点に初期化される。

（２）回五立作底 第２３Ａ図及び第２３Ｂ図に示す諸ステンブはエレメントデータ対象を作成する のに充分であるが、関係データ対象を作成するためには付加的な諸段階を必要と する。第２４Ａ図及び第２４Ｂ図は、新エレメントと関連属性データ対象との間 の関係を作成する際に包含される諸段階を示す流れ図２４００を示す、前述のよ うに、応用プログラムデータベース内のノードデータ記述子を、ある関係を形成 するのに使用することができる。変形として、応用プログラムの１つによって遂 行される計算によって関係を形成させることもできる。即ち、応用プログラムの １つからのノードデータ記述子を、関係属性データ対象を作成するのに使用する ために抜出すことができる。この抜出し機能の詳細に関しては後述する。ノード データ記述子を抜出す時、関係データ対象の関連属性データ対象となるべき適切 な属性データ対象を選択する。

抜出し及び選択が完了すると、次に適切なエレメントブロック６０２内の関係サ ブブロック６０６が識別される（ステップ２４０５）　。

エレメントブロック６０２内の関係サブブロック６０６の位置から、ホールダ属 性データ対象と関連属性データ対象との間の関係の性質（即ち複数関係か或は単 独関係か）を決定することができる（ステップ２４１０）。

もし関係が単独であれば、ホールダ属性データ対象から関連データ対象までのポ インタが対応エレメントのエレメントブロックの関係サブブロック６０６内に与 えられる。もし関係が複数であれば、複数関係ブロック６１２を指し示すポイン タがその関係サブブロック６０６内に与えられる０次で関連データ対象を指し示 す関連ポインタが、対応エレメントのエレメントブロック６０２内のポインタに よって識別された複数関係ブロック６１２内に与えられる。

もし新関係が単独であれば、ホールダ属性データ対象の関係サブプロンクロ０６ （第８図、第１０Ａ図及び第１０Ｂ図参照）が既にポインタを包含しているか否 かを決定しなければならない（ステップ２４２０）、もしこれも真であれば、関 係サブプロ。

り６０６内に特定されている先行関係が消去され、それによって新単独関係を作 成することが可能となる（ステップ２４２５）まで関係の作成は一時的に休止さ れる。関係サブブロック６０６が関連属性データ対象を指し示すポインタを包含 していない場合には、この関係のための関連属性データ対象を指し示す対象ポイ ンタが入手され、関係サブブロック６０６内へ配置される（ステップ２４３０） 。

もし作成すべき関係が単独でなければ、既に割当てられていない場合には、新関 係データ対象を特定するために複数関係ブロック６１０が割当てられる（ステッ プ２４３５＞、新関係のための複数関係ブロックを指し示すポインタが適切な関 係サブプロンクロ０６内へ配置される（ステップ２４４０）。

次に、割当てられた複数関係ブロック６１０の複数関係サブブロック６１４（第 ８図、第１３Ａ図及び第１３Ｂ図参照）、及び複数関係ブロック６１０を指し示 すポインタにリンクされている他の複数関係ブロック内の複数関係サブブロック ６０６が走査される（ステップ２４４５）、前述のように、複数関係ブロック６ １０は次のポインタ及び前のポインタによってリンクされているので、走査はこ れらのポインタを使用して進行することが好ましい。

走査された複数関係サブブロック６１４の何れも自由でなければ（ステップ２４ ５０）、自由複数関係サブブロック６１４を包含する複数関係ブロックが割当て られる（ステップ２４５５）。

サブブロックは、もしそれが関連データ対象の対象ブロック６０２を指し示す有 効ポインタを包含していなければ自由である０次で新たに割当てられた複数関係 プロンクロ１０は新対象の他の複数関係ブロック６１０とリンクされる（ステッ プ２４６０）。

新複数関係ブロック６１０の割当て及びリンクを行った後、或はもレリンクされ た複数関係ブロックの１つ内の自由サブブロックが位置付けられたのであれば、 間違データ対象を指し示すポインタが入手され複数関係ブロック６１０の自由複 数関係サブブロック６１４内に配置される（ステップ２４７０）。次に、或は単 独関係のポインタが入手された後、関連のポインタが複数関係ブロック６１０の １つ内に配置される。このブロックロ１０は、ホールダ属性データ対象のエレメ ントブロンクロ０２のエレメント見出しブロック６０４の参照ポインタ９３５か らアクセスされるブロックである（ステップ２４７５）。

（３）Ｘ五汎去 この項は所与のエレメントによってホールドされた所与の型の全ての関係の消去 を説明する。関係消去は、属性データ対象をその関連属性データ対象に関係付け るポインタをホールドするのに使用されるスペースのメモリを自由化することを 含む。第２５図はある関係を消去する好ましい方法に含まれる諸段階を説明する 流れ図２５００である。

先ず、関係のホールダ属性データ対象及び関連属性データ対象を関係付けるのに 使用する関係サブブロック６０６が、関係型あオフセット１８３０を使用して位 置付けされる（ステップ２５０５）　。

次に、関係が単独であるか否かを関係型に従って決定する（ステップ２５１０） 、もし単独であれば、関連のエレメントブロンクロ０２の参照ポインタ９３５内 に特定されている複数関係ブロック６１０が走査され、型が数値、日付、或は記 号列でない場合には、この関係のホールダ属性データ対象を指し示す対象ポイン タが見出される（ステップ２５１５）。次でホールダ属性データ対象を指し示す 対象ポインタが、関連のエレメントブロック６０２の参照ポインタ９３５によっ て指し示された複数関係ブロックからクリヤされる（ステップ２５２０）。最後 に、関連属性データ対象を指し示すポインタを包含するホールダ属性データ対象 内のサブブロック６０６が、指し示された列データと共にクリヤされる（ステッ プ２５２５）。

もし消去すべき関係が単独関係でなければ、関連型が数値、日付或は列でない場 合には、ホールダ属性データ対象の複数関係ブロック６１０が走査される。この 走査の目的は、指示された関連属性データ対象のエレメントブロック６０２の参 照ポインタによってアクセスされる複数関係ブロック６１０を位置付けすること であり、これらの関連属性データ対象は、消去すべき関係のホールダ属性データ 対象の適切な型の複数関係ブロック６１０内の関連ポインタによって指し示され る関係属性データ対象である（ステップ２５３５）、次に、これらの関連属性デ ータ対象ブロックの参照ポインタ９３５によってアクセスされる複数関係ブロッ ク６１０が走査されてホールダ属性データ対象を指し示すポインタが見出される （ステップ２５４０）。

ホールダ属性データ対象を指し示すポインタが複数関係ブロックロ１０内に見出 されると、関連属性データ対象を指し示すホールダボインタはビットマスクフィ ールド１２３０内の対応ビットをリセフトすることによって不活動ならしめられ る。このビットマスクフィールド１２３０は、ホールダ属性データ対象を指し示 すポインタが見出される複数関係ブロック６１０の複数関係見出しブロックロ１ ２内に見出される。最後に、走査された複数関係ブロック６１０のためのスペー スは、指し示された何等かの列データと共に回収され、関係サブブロックはクリ ヤされる（ステップ２５４５）。

（４）工±ノじζ１１夫 第２６図は、エレメント対象を消去する諸段階を説明する流れ図である。このエ レメントがアクセスされた後、消去すべき対象の複数関係ブロック６１０を、消 去すべきエレメントの参照ポインタ９３５から入手する（ステップ２６１０）。

次に、このエレメントを指し示すポインタは、複数関係ブロック及びこれらの複 数関係ブロックからアクセスされる関係サブブロックから消去される（ステップ ２６２０）。

これらのポインタを消去した後、このエレメントによってホールドされた全ての 単独関係及び複数関係が消去され（ステップ２６４０）、このエレメントに組合 わされている複数関係ブロックによって使用されていたスペースも自由化される （ステップ２６５０）、このエレメントによってホールドされている全てのエレ メントブロックはこの手順の繰返し使用によって消去される。

次で、このエレメントによってホールドされているエレメント即ち対象が消去さ れる（ステップ２６５５）、次に、消去されつつあるエレメントブロック内の索 引ポインタ１１２０によって指し示されている索引が自由化される（ステップ２ ６６０）、消去されつつあるエレメントのエレメントブロックは同一のホールダ を有スる他のエレメントのエレメントブロックから切離される（ステップ２６７ ０）、最後に、このエレメントのためのスペースが回収される（ステップ２６８ ０）。

（５）−一　へのアクセス 上述の好ましいデータ構造の編成から、及び上述のエレメント及び関係を作成し 消去する好ましい方法から、エレメント及び関係へアクセスする異なる方法が明 白となるであろう、勿論、このアクセス方法は望まれる情報の型に依存し、好ま しい実施例におの経路を示している。

第２７Ａ図及び第２７Ｂ図は、所与のエレメントにホールドされた関係を有する エレメント或はそのエレメントの若干の関係の関連の何れかを見出すために、共 通データ構造１４０或は１４０′にアクセスする好ましい方法を説明する流れ図 ２７００を示す。

流れ図２７００によって表わされている手順は、ホールドされたエレメント及び 複数の属性データエレメントの関係の関連を得るのにも使用できる。以下に説明 する方法は唯一の方法ではなく、単に本発明の目的を遂行するのに使用できる複 数の方法の複数の型の一例にしか過ぎない。

流れ図２７００は、共通データ構造１４０の作成中に、コンパイラ或はＲ４ｇ、 シた種類の言語処理ソフトウェア（コンバータプログラム５４０及び５７０内に 含まれる）が各識別名毎に仮想アドレス或はオフセントを発生したものと想定し ている。更にこの流れ図２７００は、共通データ構造がこの仮想アドレス或はオ フセントをメモリ１２０の共通領域内に位置付けされているアドレス表内に配置 しており、従うて第５Ａ図及び第５Ｂ図に示す検索プログラム５８０及び５９０ のような検索プログラムがアクセス可能になっているものとしている。これらの 検索プログラムは通訳プログラムであることが好ましいが、コンパイラのような 他の如何なる型の言語処理ソフトウェアであっても差支えない。

更に、流れ図２７００は、その実行に先立って、所与のエレメントの関連或はホ ールドされたエレメントにアクセスするための仮想アドレスが、取出すべき関係 或はエレメント（まとめて属性と呼ばれる）に対応する属性型ブロック７１４の 仮想アドレスを有しているとして既に検索されているものとしている。この、或 はこれらの所与のエレメントはホールダと呼ばれる。

流れ図２７００において最初に行われる決定は、所与の型のホールダの関係が単 独か或は複数かである（ステップ２７０５）。

もし単独であれば次の決定は、アクセスすべき（単数或は複数の）エレメント或 は（単数或は複数の）関係の第１の或は次のホールダが存在するか否かである（ ステップ２７１０）、もしこのようなホールダが存在しなければ、完了標識がセ ントされて全てのホールダに対するサーチが完了したことを指示しくステップ２ ７１５）、アクセスルーチンの実行が完了して無結果で戻される（ステップ２７ ２０）。

もし次のホールダが存在していれば、属性型ブロックからのオフセントフィール ド（例えば第１８図に示す１８３０）を使用してホールダのエレメントブロック のスタートからのオフセントを見出し、望まれる関係或はエレメントのエレメン トブロックを指し示すポインタを見出す（ステップ２７２３）、次でこの次のホ ールダのエレメントブロックが、メモリ１２０の共ｉ１９Ｍ域内のアドレス表か らの仮想アドレスを使用することによって検索される（ステップ２７２５）、次 に、この特定のホールダの関係或はホールドされたエレメントが存在するか否か を見出す決定を行わなくてはならない（ステップ２７３０）、もし存在すれば（ 即ち、もし適切なポインタが０でなければ）、所望の属性の属性型ブロックの仮 想アドレスがその属性にアクセスするために検査される（ステップ２７３５）、 非０ポインタが存在する場合には、所望の関連或はホールドされたエレメントに 関する情報が戻される（ステップ２７４５）。

もし適切なポインタがＯであれば（ステップ２７３０）、次のホールダ属性デー タ対象のエレメントブロック内には所要の関係或はエレメントは存在しない、こ の場合、もし複数のホールダが特定されれば、戻すべき関係或はエレメントを有 するホールダが見出される（ステップ２７１０．２７２３、及び２７２５）か或 はそれ以上のホールダが存在しなくなる（ステップ２７１０．２７１５、及び２ ７２０）の何れかまでサーチが続行される。

もし、初期決定において属性型が複数であることが見出されると（ステップ２７ ０５）このアクセスの実行が、最初のコメンシングであるか（即ち全式コメンシ ングの検査であるのか）或は少なくとも新ホールダエレメントのコメンシング検 査であるかの決定が行われる（ステップ２７５０）、もしそうであれば、単独属 性型の場合のように、次の決定は次のホールダが存在するか否かである（ステッ プ２７５１）。もし否であれば完了標識がセットされ（ステップ２７５５）、無 結果の戻りがなされる（ステップ２７６０）。

もし次のホールダが存在すれば、この次のホールダのエレメントブロックが検索 され（ステップ２７６３）、そのエレメントブロックから関係ブロック６１０が 存在するか、或は次のホールダの最初のホールドされたエレメントが存在するか の決定が行われる。これは次のホールダのエレメントブロックを検査することに よって決定される（ステップ２７６６）、もし次のホールダの属性が存在しなけ れば以後のホールダが入手され、属性を有するホールダが得られるまで（ステッ プ２７５１及び２７６３）或はそれ以上ホールダが存在しなくなるまで（ステッ プ２７５１．２７５５及び２７６０）検査される。

属性型ブロックから、これらの属性が関係であるか否かの決定が行われる（ステ ップ２７７３）。もし諾であれば、次の関係が対応する複数関係ブロックから検 索される（ステップ２７７６）。

この複数関係ブロックのアクセスに伴うのは、アクセスすべき複数関係ブロック から次の関係の軌跡を保持する“場所標識°である。これは、流れ図２７００内 のルーチンが各アクセスにおいて１つの結果に戻るだけであるからなされるので ある。複数関係ブロック６１０からの最後の関係が得られると、°場所標識”は 次の問合せを関係の存在の中へ導びくか、或は得るべきエレメントに否を返答さ せる。関係が得られる度毎に“場所標識”は次の位置へ更新され、この手順から の戻りが指示された結果を伴ってなされる（ステップ２７８０）。

もし所望の属性がエレメントとして見出されるか、或は検査がコメンシングでな ければ（ステップ２７７３）、そのエレメントがホールダのホールドされた関係 を有するエレメントのリンクされたリストの最初のものであるか否かの決定が行 われる（ステップ２７８３）、もし否であれば、次フィールド９２５を用いて現 在のエレメントの直前にアクセスされたエレメントから次のホールドされたエレ メントが入手される（ステップ２７８６）。アクセスすべきエレメントの中で次 に係るエレメントの軌跡を保持している異なる“場所標識”はホールドされた対 象の次の対象を指し示すように更新される０次で標識付き結果を伴って戻りがな される（ステップ２７８０）。

もし所望のエレメントがホールドされたエレメントの中の最初のエレメントであ れば（ステップ２７Ｂ３）、オフセントポインタ及びホールダ属性データ対象の エレメントブロックを使用してホールドされた対象ブロックが入手され、適切な 場所１ｍが初期化される（ステップ２７９０）、次で標識付き結果と共に戻りが なされる（ステップ２７８０）。

第２８図は、アクセス手順の別の例である。第２８図の流れ図２８００は、索引 ファイル８００及びキー値を使用して属性データ対象を見出すのに使用する。こ の流れ図２８００もアクセスの一方法に過き゛ず、本発明を限定するものではな いことを銘記すべきである。

ある属性データ対象を識別し、見出すためにキー値を使用する場合には、そのキ ー値に関して索引ディレクトリブロック　（第８図の索引ディレクトリブロック ６３０参照）がサーチされる（ステ、プ２８１０）。もしそのキー値が見出され なければ（ステップ２８２０）、第２８図のルーチンから結果を伴わずに戻りが なされる（ステップ２８３０）。

もしあるキー値が見出されれば、第２８Ａ図に示すように、以下の価にセントさ れた４つのロングワードからなる索引結果ブロックが作成される（ステップ２８ ４０）。最初の葉ノード２８９１は所望のキー値の最初の発生を包含する葉索引 技ブロック８１０のポインタにセントされる。最初の葉索引２８９２は、葉索引 技ブロック内の最初の発生である索引技ブロック８１０内の索引技サブブロック ８３０の順序数を包含する。同様に、最Ｖ！葉ノード２８９３及び最終葉索引２ ８９４はそれぞれ、所望のキー値の最終発生に係るポインタ及び順序数を包含す る。索引結果ブロック２８９０は、索引ファイル８００を使用するアクセスのた めにだけ作成される一時的データ構造である。

次に索引結果ブロック２８９０を使用して（単数或は複数の）所望エレメントの アドレスが見出される。もしキーが唯一であれば最初の発生及び最終発生は同一 である。もし、順序付は索引の場合のようにキーが唯一でなければ、索引技ブロ ックがリンクされているために、索引結果ブロック２８９０を使用して完全組の 有効結果を見出すことができる。属性データ対象を指し示すポインタは結果ブロ ックを使用して見出される。

もしキー価が見出されれば、それは対応する属性データ対象のための属性データ ファイル６００内にアドレスを包含しているであろう、この手順の戻りは標識付 き結果を伴ってなされる（ステップ２８６０）。

Ｅ、デー　、し、　び・ 本発明によれば、第５Ａ図及び第５ＢＩＦに示すプログラム５３０及び５６０の ような応用プログラムによって使用される情報は共通データ構造１４０　（或は １４０’）の編成に適合させなければならない、多くの場合、応用プログラムは それら自体のデータヘースに特有な表現で既に書かれており、他の場合には応用 プログラムは本発明によって編成された属性データ対象を既に使用しているかも しれない。

抜出し及び変換のプロセスは、応用プログラムデータベースからのデータを共通 データ構造１４０　（或は１４０’）に変換する方法に関する。第５Ａ図及び第 ５Ｂ図に示すように、コンバータプログラム５４０及び５７０は応用データベー スからデータを取り、これらのデータをこれらのデータベース内のフォーマント から共通データ構造１４０（或は１４０’）に適当なフォーマントに置換する。

各応用プログラムデータベース毎に本発明による共通データ構造を編成するには 幾つかの方策がある。応用プログラムデータの共通データ構造に対する編成及び 変換は、応用プログラムデータベース内のデータの内容、及び共通データ構造の 予期される使用法に依存しよう。

共通データ構造の編成、従って抜出し及び変換も、絶対的且つ確定的な規則に従 う必要はない、その代り、この項では本発明の実施を望む人々に対して一般的な 指針及び設計考察を説明する。

当業者ならば、好ましいデータ構造及びアクセス、作成及び消去の好ましい方法 の完全な説明から、不当な実験を行うことなく付加的な指針及び設計考察は明白 であろう。

極めて屡々、本発明による共通データ構造の構築における第一の関心事はエレメ ントデータ対象の選択である。エレメントデータ対象に選択されることが多い応 用プログラム内の情報をノードデータと呼ぶことができる。一般にノードデータ は、データベース内の“対象′或は“実体′の何れかである“事物”を含む。従 って、言語の部分として見れば、エレメントデータ対象は名詞によって記述され ることが最も相応しいデータである。例えば、ノードデータは回路、ゲート、エ ンジンの部分、或は人物のような物理的対象を含むことができる。ノードデータ はタイムラインエントリ成は綴込み日時のような事象をも含むことができる。ノ ードデータの別の例は、イデア及び性格のような概念である。

一旦エレメントが選択されると、エレメント間のホールディング関係が確立され る。これらのホールディング関係の決定は、通常はエレメントの間のある階層を 表わす、エレメント自体の選択におけるのと同様に、殆んどの場合、ホールディ ング関係によって表わされる階層の決定は唯−無二ではない。ホールディング関 係の決定は、データの予想される使用を考慮することも好ましい。

２つのエレメント間の（或はあるエレメントとある関係との間の）関係の存在は 、このような関係が必ずしも共通データ構造内のホールディング関係を表わすこ とを意味するものではない、この関係は、関係データ対象によって指示される非 階層的関係によって表わすこともできる。

ホールディング関係によって最も屡々表わされる関係の型は、団体の役員のよう なある自然階層を表わしたり、或は機械の部品、本の章、或は川内の都市のよう な事物の構成部分を表わす。ホールディング関係は、１つの事物の別の事物によ る所有を表わすこともできる。

しかし、一旦ホールディング関係が決定されると、通常は文脈を選択しなければ ならない、前述のように、文脈は、属性データ対象の名前がこれらの対象をホー ルドしている文脈内のみの意味しか有していないので、属性データ対象の名前付 けを援助するための構成概念である。文脈は、照合の便宜を図るべく関連する属 性データ対象の集群を表わすため、及び特定された用語の使用を許容するために 使用されるべきである。例えば、印刷回路基板に関する設計情報をＶＬＳＩチッ プに関する設計情報からの異なる文脈内へ編成して何れかの応用領域においては 周知の専門用語を衝突させることなく使用可能にすることができる。第３図及び 第４図に示す例においては、′ゲート”なる語は、これら２つの応用領域におい て異なる意味を持たせることができる０分離した文脈を使用することによって、 ′ゲート”という同一の語は各文脈において異なる意味を持ち得るのである。

また、若干の文脈の層を持つこともできる１例えば、第１の文脈は、バージョン トランキング及びプロジェクト管理のような一般的応用概念に係る対象を包含す ることができる。第１の文脈によってホールドされている複数の文脈の各々は、 機械的或は電気的のような特定の技術に関する属性対象を包含することができる 。

通常は、その後に関係が決定される。ノードデータをエレメントとして割当てた 後に残される情報は、通常はのこのノードデータの関係或は属性に係り、もしこ れが階層的なホールディング関係を表わしていないならば一般的にそのノードデ ータの記述子を表わしているものと考えることができる。関係の目的は、属性デ ータ対象の間に存在する非階層的関係を表わすことである。これらの関係は元の 応用データが表わしているノードデータとそれらの記述子との間の関係を表わす ために、これらを適切な対象に組合せるように作成される。関係によって表わさ れることが好ましいノードデータ記述子の例には、信号へのゲートの接続、回路 の設計者の識別、及びプロジェクト針面における種目の接続が含まれる。

データ編成の最終段階は、型の決定及びキー値の選択を包含する。属性の′型付 け”は一般的に、エレメント及び関係の指定、及びホールディング関係の指定を 伴う、型は一般的に、エレメント及び関係が既に集群されている組を表わし、ま たこれらの線内のエレメント或は関係の共通性を記述する。

キー値の選択もデータに依存する。キー値は主としてアクセスへの援助として使 用されるので、キーの決定及び選択は共通データ構造１４０或は１４０′の予想 される用法に従うべきである。

更に、キー値の使用は、応用プログラムデータベース内の情報の順序付けを表わ してこれらの情報の応用プログラムによる使用を容易ならしめることができる。

コンバータプログラム５４０及び５７０の詳細はそれぞれ応用プログラム５３０ 及び５６０の要求に対して特定のものであり、これらのコンバータプログラムに よって遂行される以下の例は上述の指針を説明するものである。もし応用プログ ラム５６０が第３図に示す回路を生成するのであれば、ファイル５６５　（第５ Ａ図）は回路を記述する以下の情報を包含しよう。

１）　ＡＤＤ　３−１−Ａ、３２０゜ ２）　ＡＤＤ　３２０．３２２／５２ ３）　３２０．３２４ ４）　３２０．３２６ ５）　３２０．３２８／５１ ７）　ＡＤＤ　２−１−Ａ；　３３０；８）　ＡＤＤ　３３０．３３２ ９）　３３０．３３４／５ｔ １０）　３３０．３３６／Ｓ２ このファイルの非空白の各行はノードデータを表わす０行１）は３人力ＡＮＤゲ ート３２０の作成を要求する０行２）乃至行５）は、ゲート３２０のピン３２２ ．３２４．３２６及び３２８の作成を要求する０行７）は２人力ＡＮＤゲート３ ３０の作成を要求する０行５）及び９）はピン３２８が信号“Ｓ１″によってピ ン３３４に接続されていることを指示している。同様に、行２）及び１０）はピ ン３２２が信号“Ｓ２”によってピン３３６に接続されていることを指示する。

コンバータプログラム５７０は、ファイル５６５を読み取り、先行項に記載した 操作を使用して第３図の回路を表わす共通データ構造１４０或は１４０′を作成 するように設計することができる。このようにして作成された共通データ構造の 部分が第４図に示されているものである。各“事物”　（即ちゲート及びピン或 は信号）はエレメントである。ホールディング関係はこの作成中に潜在する階層 ・・・・・・最初がＡＮＤゲート、次でピン或は信号・・・・・・を表わす、信 号接続及び名前のような残余の関係は“関係”として作成される。

Ｆ、に１１理 予想できるように、本発明による実施例を実現するのに必要な記憶量は極めて大 きくなり得る。この項においては、必要な記憶量を減少させるが如き便宜を図る ための共通データ構造１４０′の維持、更新及びアクセス方法に関する記憶管理 技術の好ましい実施例を説明する。記憶管理技術のこの好ましい実施例はまた、 応用プログラムによるメモリ１２０のデータ構造１４０′へのアクセス及び該構 造１４０′の更新の容易且つ効率的手段となるようにも設計されている。

記憶管理技術に関しては、主データファイルのコピー５１５、スナップデータフ ァイル５２５、及びロック５６８及び５６９を有する制御ファイル５５５を含む 共通データ構造１４０′を示す第５Ｂ図のシステムに基いて説明することとする 。記憶管理ソフトウェア５６６は共通データ構造１４０′内の諸ファイルを制御 する。

第２９図に共通データ構造１４０′の実施例の詳細をブロック線図で示す、第２ ９図は、第５Ｂ図の主データファイル５１５に対応する主データファイル２９０ ０を含む。マクロページ０〜３を含むように図示しである主データファイル２９ ００は、共通データ構造１４０′の最新バージョンに一致している。この最新バ ージョンとは、現在変更されつつあるバージシンか或は最も新しく変更されたバ ージョンの何れかのことである。

第２９図に示すように、主データファイル２９００内の各マクロページは２つの 部分からなる関連番号を付したエントリを有している。エントリの基数はマクロ ベージ番号を表わし、エントリの指数部分はバージョン番号を表わしている。バ ージョン番号は、車−のユーザによって更新されたデータベースのバージョンを 表わす、好ましい実施例によれば、より新しいバージョンが常に古いバージョン よりも高い番号を有している。マクロページの合計数はデータベースの合計の大 きさに依存する。

スナップショットデータファイル２９１０は第５Ｂ図のスナップショットデータ ファイル５２５に対応するものであり、若干のスロット０−５を含む、各スロッ トの１つはマクロページを包含し、主データファイル２９００の現行バージョン 或は該ファイルの先行バージョンの何れかからのマクロページの１つに対応する 。

スナップショット２９１０内に未だ維持されている主データファイル２９００の 先行バージョンからのマクロページは、未だに活動しているバージョンのための ものである。もし現在、あるバージョンのマクロページにアクセスしている少な くとも１つの応用プログラム或はユーザが存在すれば、そのバージョンは未だ活 動に付した番号付きエントリの基数は主データファイル２９００内の対応マクロ ページの値を表わし、指数部分はそのマクロページのバージョンを表わす。

主データファイル２９００が更新された後、変化した主データファイル２９００ からのこれらのマクロページはスナップショットデータファイル２９１０のスロ ット内にコピーされる。このコピイングは、スナップショットデータファイル２ ９１０内に記憶されている主データファイル２９００からのマクロページの複数 のバージョンを考慮している。スナップショットデータファイルは不確定に成長 させてはならないから、詳細を後述するハウスキーピングルーチンに頬って古い マクロページは廃棄する。

スナップショットデータファイル２９１０の若干のスロットは“自然スロット” と呼ばれる。°自然スロット”は、対応するマクロページ番号と同一のスロット 番号を有するスナップショットデータファイル２９１０内のスロットを云う、こ れは、スナップショットデータファイル２９１０が始めに主データファイル２９ ００の内容を受けた時のスナップショットデータファイル２９１０の状態である 。全てのマクロページがそれらの自然スロットにあるこの初期状態が、効率のた めに望ましいのである。

データベース制御装置（ＤＢＣ）２９２０は記憶管理機能を制御する。ＤＥＣ２ ９２０は第５Ｂ図の制御ファイル５５５に対応する。要約すればＤＥＣファイル ２９２０はデータ構造１４０′の変更、及びそのデータ構造へのアクセスを制御 する。ＤＢＣ２９２０は、データ構造への変化の軌跡を管理し保持することによ って、また変更ロック（第５Ｂ図参照）の使用によりｌユーザだけがデータ構造 のマクロページのバージョンに変更を行うことができることを保証することによ って、データ構造１４０′の変更を制御する。ＤＢＣファイル２９２０は、全て の活動マクロベージの位置の軌跡を保持することによって、またＤＢＣロフク（ 第５Ｂ図参照）を介して若干のユーザが衝突するのを阻止することによって、デ ータ構造へのアクセスを制御する。

ＤＢＣ２９２０は４つの主成分を包含する。一つの成分はポインタ／カウンタ区 分２９２２であって、ＤＢＣ２９２０の他の部分が何処に所在するかを指示する 。別の成分はハフシュ表２９２４であって、スナップショットファイル２９１０ 内の活動マクロベージを位置付けする手段となっている。バージョンブロック区 分２９２６は、フ゛ロンク２９３０．２９４０、及び２９５０のようなバージョ ンブロックを包含し、これらのブロックはデータ構造１４０′の異なるバージョ ンに関する情報を包含する。スイッチブロック区分２９２８は、２９３２．２９ ３４．２９３６．２９３８．２９４２．２９４４．２９５２．２９５４．２９５ ６及び２９５８を例として示しである区分ブロックを包含し、これらは活動マク ロページに関する情報を包含する。属性ファイル６００及び索引ファイル８００ 内の変化に対して、Ｎ類の異なるスイッチブロックを使用することが好ましい。

しかし、もし属性ファイル６００及び索引ファイル８００内の情報が単一ファイ ル内に所在しているれば、一種類のスイッチブロックを必要としよう、以下の説 明においては、スイッチブロックに関する説明は属性ファイル６００或は索引フ ァイル８００の何れにおける変化にも適用されるものとする。

第３０図は、ポインタ／カウンタ区分２９２２の好ましい実施例の詳細を示す。

第３０図に示すように、ポインタ／カウンタ区分２９２２は、ユーザカラン）３ ００５、及び他の若干のフィールド及びポインタを包含することが好ましい。ユ ーザカウント３００５は、共通データ構造１４０′にアクセスしている或は該構 造を変更しつつあるユーザの合計数を指示する。新ユーザが共通データ構造１４ ０′にアクセスすることを希望する度毎に、記憶管理ソフトウェアはＤＢＣロッ クを入手し、ユーザカウントフィールド３００５を増進させ、ＤＢＣロックを戻 す。この場合のＤＢＣロフクの目的は、複数のユーザがユーザカウントに同時に アクセスしてそれを不適切に増進させるのを阻止することである。

ロールバンクバージョン番号フィールド３０１０及びロールバンクバージョンポ インタ３０１５はロールバンク機能に関連する。

この機能によってユーザは、共通データ構造１４０′のあるバージョンに対して 行った若干の変更を撤回することが可能になる。

ロールバンクは、ユーザによって共通データ構造１４０′に行われつつある変更 が未だに進行中である間に限って発生する。ロールバックは、変更を遂行してい るユーザが変更を伴う進行を望まずに変更開始前の状態の主データファイルを回 復するのを望むことを“自然的に“決定したために、或はあるエラーのために変 更を完了させることが不可能となったの何れかによって発生する。

好ましい実施例においては、ロールバンクされつつあるバージョンはユーザによ って特定された変更に従って完全に変更されている。以下に説明する記憶管理及 び更新段階は実行されるが、共通データ構造１４０′のこのロールバックすべき バージョンは他のユーザが利用することを不能にする。ロールバンクすべきバー ジョンが作成された直後に新バージョン、即ちロールバンクバージョンが作成さ れる。このロールバンクバージョンは、区分２９２８内のスイッチブロック及び スナップショットデータファイル２９１０の使用によって、ロールバンクすべき バージョンがもたらした全ての変更を取消す、従って、ロールバック後には、ロ ールバンクされたバージョンの主データファイル２９００はロールバンクシーケ ンスが開始される前の状態に戻っている。

スナップショットデータファイル２９００は、ロールバックすべき主ファイル２ ９００の作成前の状態には戻らない。ロールバンク後、スナップショットデータ ファイル２９１０はロールバックされた°悪いバージョン°と新しい現行バージ ョンの２つの付加的バージョンを包含している。しかし、前述のように、ユーザ は“悪いバージョン゛を読むことは不能であり、新しい現行バージョンは初めに “悪いバージョン９によって変更されたマクロページのコピーである。′悪いバ ージョン”はロールバンクの完了時に既に廃物になっており、後述するハウスキ ーピングルーチンによって削除されよう。

ポインタ／カウンタ区分２９２２においては、ロールバンクバージョン番号３０ １０は“悪いバージョン”を“ロールバンク”しつつあるバージョンの番号を表 わし、ロールバンクバージョンポインタ３０１５はそのバージョン番号のバージ ョンブロックを指し示す。

区分２９２２の次のバージョン番号３０２０及び次のバージョンポインタ３０２ ５は、現在更新中の、或はもし現在更新中のバージョンが存在しなければ次に更 新されるバージョンの、何れかである共通データ構造１４０′のバージョンを表 わす。

現行バージョン番号３０３０及び現行バージョンポインタ３０３５は、現在読み 出すことが可能な最新バージョンを表わす、これはスナップショットデータファ イル２９１０内で利用可能な最新バージョンである。最古バージョン番号フィー ルド３０４０及び最古バージョンポインタ３０４５は最も古い活動バージョンを 表わす、フィールド３０４０及びポインタ３０４５は、共通データ構造１４０′ が更新され廃物（即ち不活動）バージョンが自由化されると変化する。

初期バージョン番号３０５０は、“チェックポイント”と呼ぶ事象が発生する時 点に存在する共通データ構造１４０′のバージョンを表わす、エラー回復の目的 のために、主データファイル５１５内の共通データ構造１４０′の内容はチェッ クポイントに１換される。この１チエフツクポイントバージヨン”はデータ構造 １４０′の内容の一部若しくは全部の消失或は破棄の後にシステムの動作を続行 させるのに使用することができる。

初期バージョン番号３０５０は、最新のチェックポイントが発生した時のスナッ プショットデータファイル２９１０内の最新バージョンを指示する。

ハツシュ表２９２４は、詳細を後述する技法で活動マクロページにアクセスする ための手段を提供する。ハツシュ表２９２４はｉｓのハツシュ表であることが好 ましく、従って詳細な説明は省略する。ハツシュ表２９２４は、各マクロページ の最新バージョンに対応するスイッチブロックを指し示すポインタを包含するこ とが好ましい。前述のように、各スイッチブロックはその早期バージョンにリン クされている。従って、ハツシュ表２９２４を通して進入することによってユー ザはスナンプショントデータファイル２９１Ｏ内の各マクロページの全ての活動 バージョンを位置付けすることができる。バージョン領域２９２６は、第２９図 に示す複数のバージョンブロック２９３０．２９４０、及び２９５０を含むこと が好ましい。これらの各バージョンブロックは第３１図のバージョンブロック３ １００に示すフィールド及びポインタを含むことが好ましい。

バージョンブロック３１００は、該バージョンブロック３１００が係っているバ ージョンの番号を識別するバージョン番号フィールド３１１０を含む、このフィ ールドは、第２９図にもバージョンブロック２９３０．２９４０、及び２９５０ のそれぞれの上部にＮｏ、　１　、Ｎｏ、　２及びＮｏ、　３によって図式的に 示しである。

バージョン使用カウントフィールド３１２０は、バージョンブロック３１００に 対応するバージョンに現在アクセスしているユーザの数を表わす、ユーザが新バ ージョンを創始することを希望する度毎に、バージョンブロック３１００のバー ジョン使用カウントフィールド３１２０は１だけ増加される。ユーザがそのバー ジョンで終了すると、使用カウントフィールド３１２０は１だけ減ぜられる。バ ージョン使用カウント３１２０の目的は、最早アクセスされなくなったのでもし 新しい主データファイル２９００の新バージョンが利用可能となればマクロペー ジをこれらの新バージヲンに置換可能であるバージョンを識別することである。

新バージョンフィールド３１３０は、主データファイル２９００の次に最新のバ ージョンのためのバージョンブロックを指し示す。

フィールド３１３０内のポインタは、第２９図においてバージョンブロック２９ ３０がバージョンブロック２９４０を指し示し、バージョンブロック２９４０が バージョンブロック２９５０を指し示すように図式的に示したある型のリンクを 実現する。

新バージョンフィールド３１３０に係っているのは、主データファイル２９００ ０次のバージョンのバージョンブロックを逆方向に指し示す古バージョンフィー ルド３１４０である。即ちこれらのバージョンブロック間のリンケージは双方向 性である。第２９図に示すように、バージョンブロック２９５０はバージョンブ ロック２９４０を指し示し、バージョンブロック２９４０はバージョンブロック ２９３０を指し示している。

最終変更バージランフイールド３１５０は最新の最初に変更された対応バージョ ンのマクロページを指し示すポインタを包含する。このフィールドのａ能の詳細 に関しては後述するが、要約すればある特定バージョンに関してマクロベージが 変更される最初の時点に、そのマクロページの１次の更新フィールド”はバージ ョンブロック３１００の最終変更バージョンフィールド３１５０の内容を包含す るように変化し、バージョンブロックの最終変更バージョンフィールドはこのマ クロページを指し示すように変化する。バージョンブロック３１００の最終変更 バージョンフィールドは当初は０にセントされる。各マクロページが最初に変更 される最初の時点に、各マクロページはこのバージョンにおいて変更されたマク ロページのリストの冒頭にリンクされる。従って、最終変更バージョンフィール ドは最も新しい最初に弐更されたマクロページを指し示すのである。

この手順の理由はデータ操作の効率にある。新マクロページが最初に変更される 時、−次メモリ内のスペースを節約するためにその直前に変更されたマクロペー ジがディスクに戻されて配置されている可能性が極めて大きい、単に１つのポイ ンタを更新するためにディスクからこのマクロページを検索するのは非効率的で ある。バージョンブロックは常に一部メモリ内に所在しているのであるから、バ ージョンブロック３１００の対応フィールドを更新する方が容易である。

最初の属性スイッチフィールド３１６０及び最初の索引スイッチフィールド３１ ６５はそれぞれ、対応するバージョンのために最初に作成された属性ファイル及 び索引ファイルのためのスイッチブロックを指し示す、勿論、もし属性ファイル 及び索引ファイルが混合されていれば、これらのフィールドの一方のみが必要と なる。

バージョンブロック３１００は４つのバージョン初期マクロベージ番号フィール ド３１７０．３１７５．３１８０及び３１８５を含めて完成される。初期属性マ クロベージ番号フィールド３１７０は、そのバージョンの開始時の属性ファイル ６００に対応する主データファイル２９００の最高マクロベージ番号を識別する 。第２９図の例で云えば、フィールド３１７０内の番号は３である。

初期スナップショットマクロベージ番号フィールド３１７５は、そのバージョン の開始時の属性ファイル６００のスナップショットファイル２９１０内の最高マ クロページ番号を包含する。第２９図の例を用いればこのフィールドは数５を包 含する。

初期索引マクロベージ番号ファイル３１８０及び初期スナップショット索引マク ロベージ番号フィールド３１８５は、ファイル３１７０及び３１７５と同等の機 能を有するが、索引ファイル８００の主データファイル及びスナップショットデ ータファイルに係っている。索引ファイル８００の主データファイル及びスナッ プショットデータファイルは図示してないが、属性ファイル６００の主データフ ァイル及びスナップショットデータファイルと同一であることが好ましい、勿論 、索引ファイル８００が属性ファイル６００と混合されていれば、フィールド３ １８０及び３１８５は必要ない。

データベース制御ファイル２９２０のスイッチブロック区分２９２８は、第２９ 図に示すブロック２９３２．２９３４．２９３６．２９３８．２９４２．２９４ ４．２９５２．２９５４．２５９６及び２９５８のようなスイッチブロックを含 む、第３２図のスイッチブロック３２００は、これらのスイッチブロックの一例 である。スイッチブロックの好ましい実施例３２００は、属性ファイル６００及 び索引ファイル８００のためのスイッチブロックに通用される。もし単一の属性 ／索引ファイルが存在するのであれば、１つの型のスイッチブロックだけが存在 する。

スイッチブロック３２００は、そのスイッチブロックが存在するバージョン番号 を識別するバージョン番号フィールド３２１０を含む、この番号は第２９図にも 各スイッチブロックの右上隅に番号で示しである。

スイッチブロック３２００は、スイッチブロック３２００が対応するバージョン のバージョンブロックの位置を識別するバージョンポインタ３２２０を包含する ことが好ましい０次のフィールド即ちマクロベージ番号フィールド３２３０は、 主データファイル２９００内の、或は索引ファイル８００の同等主データファイ ル内の対応マクロベージを識別する。マクロベージスロット番号３２４０は、ス イッチブロック３２００に対応するマクロページのバージョンを記憶しているス ナップショットデータファイル２９１０　（或は索引ファイル８００のスナップ ショットデータファイル）のスロット番号を識別する。

スイッチブロック３２００内の次の２つのフィールドは新バージョンフィールド ３２５０及び古バージョンフィールド３２６０であり、これらはそれぞれスイッ チブロック３２００が対応している主データファイル２９００内の同一マクロベ ージの現在は最新のバージョン、及び現在は最新ではないバージョンに対応する スイッチブロックを指し示すポインタを包含する。これらのフィールドの使用に 関しては共通データ構造１４０′へ如何にしてアクセスするかを説明する時に詳 述するが、これらのフィールドの使用例は第３３回を参照すれば理解できる。

マクロページにアクセスするためには、所望のマクロベージ番号を有するハフシ ュ表２９２４に進入し、そのマクロページの最新バージョンに対応するスイッチ ブロックを指し示すポインタを入手する。そのマクロページより以前のバージョ ンを得るためには、マクロページの所望バージョンのスイッチブロックが位置付 けされるまで古いバージョンポインタ３２６０の使用を続行する。

スイッチブロック３２１０は、同一バージョンのための次のスイッチブロックを 識別する次のスイッチポインタ３２７０も包含する０次のスイッチポインタ３２ ７０が遂行するリンクは、第２９図ではスイッチブロック２９５２．２９５４． ２９５６、及び２９５８間、及びスイッチブロック２９４２及び２９４４間、及 びスイッチブロック２９３２．２９３４．２９３０、及び２９３８間に右に向い た矢印によって図式的に示されている。スイッチブロック３２００の最後のフィ ールドは、スイッチＢフラグフィールド３２８０であり、スイッチＶ分副スロッ トフラグを含む、このフラグは前述のロールバンクエラー回復に使用される。こ のフラグは、別のスイッチブロックがこのスイッチブロックと同一であることを 指示する０例えば、マクロページＸのバージョンｎはスロットｙであり得る。従 ってマクロページＸのバージョンｎ＋２もスロットｙであり得、これらのバージ ョンはロールバンクの直前と直後の同一状態に対応する。

上述の共通データ構造１４０′を理解すれば、本発明の共通データ構造に関して 説明した作成及びアクセス手順は、本発明の特定実施例に関して理解できよう。

第３３図乃至第３６図に示す流れ図３３００．３４００．３５００．３５２０． ３５３０、及び３６００は、第２９図乃至第３２図に示す共通データ構造１４０ ′を更新し、該構造にアクセスする好ましい方法を示す。第３３図乃至第３６図 の手順は記憶及び管理ソフトウェアによって遂行することが好ましい。

第３３回の手順の発端は、変更ロック及びＤＥＣロックを入手することである（ ステップ３３１０）、変更ロック５６８の目的は、任意の一時点に１つの応用の みが共通データ構造１４０′を変更することを保証することである。ＤＢＣロン ク５６９の目的は、任意の一時点に１つの応用のみがデータベース制御ファイル ２９２０を変更することを確実にすることである。

次に、新バージョンブロックをこの特定バージョンのために作成する（ステップ ３３１５）、これでＤＢＣロンクを戻すことができる（ステップ３３２０）。

次の段階は、次に行う変更は無マークマクロページ（即ちこのバージョンマクロ ページにはそれ以前に変更は行われていない）に対するものか否かを決定するこ とである（ステップ３３２５）。

もし諾ならば、若干の行動を起さなければならない。

先ず、応用はＤＢＣロック５６９を入手する（ステップ３３３０）。

次にバージョンブロック３１５０の最終変更フィールドの現行内容を、そのマク ロページの次に更新されるフィールドヘコビーする（ステップ３３３５）、次で そのマクロページを指し示すポインタをバージョンブロックの最終変更バージョ ンフィールド３１５０ヘコピーする（ステップ３３４０）、最後に、ＤＥＣＥＣ ロック５６戻す（ステップ３３４５）。

次の変更が無マークページに対するものでなければ、或はマクロページをバージ ョンブロックにリンクした後に、そのマクロページへの変更を行うことが可能で ある（ステップ３３５０）、その後、それ以上変更するものが存在するか否かが 決定される（ステップ３３５５）。もし諾ならば、このプロセスは、次に行う変 更が無マークページに対するものか否かの質問（ステップ３３２５）に戻されて 反覆される。もしそれ以上の変更が行われないならば、引き渡しルーチンが呼び 出され（ステップ３３６０）、主データファイル２９００のマクロページがスナ ップショットデータファイル２９１０へ記憶され、またデータ構造１４０′のこ のバージョンが他の応用プログラムによってアクセス可能になったことを指示す る。

第３４図は引き渡しルーチンの好ましい流れ図である。第１段階はＤＥＣロック を入手することである（ステップ３４５０）。

次に、バージョンブロック３１００内の最終変更フィールド３１５０が０に等し いか否かの決定を行わなければならない（ステップ３４１０）。もし諾ならば、 変更は行われなかったのである。もし最終変更バージョンポインタが０に等しく なければ、変更が行われたのであり、初期ハウスキーピングを遂行しなければな らない（ステップ３４１５）、このハウスキーピングの詳細に関しては後述する 。

次に、最終変更バージョンポインタによって指し示されるマクロページを検索し なければならない（ステップ３４２０）、次でこの検索されたマクロページのス ロット番号を、該マクロページが記憶されるスナップショットデータファイル２ ９１０のスロット番号を指示するように更新しなければならない（ステップ３４ ２５）。

このスロット番号は、スナップショットデータファイル２９１０の自由スロット の記憶及びソフトウェア５６５によって包含されている成る種のリスト内にある ことが好ましい。

次に、スイッチブロックとバージョンとのリンケージを確認しくステップ３４３ ０）、上記マクロページを適切なスロット番号で主データファイル２９００から スナンプショソトデータファイル２９１０内ヘコピーする（ステップ３４３５） 。次で、ハツシュ表２９２４をこの変更されたマクロページの最新バージョンの スイッチブロックを指し示すように更新し、そのスイッチブロックを同一マクロ ページのスイッチブロックより以前のバージョンへリンクする（ステップ３４４ ０）。

この更新の後に、現行マクロページの次の更新フィールドを入手する（ステップ ３４４５）。もしこの次の更新フィールドが０に等しくな（変更された別のマク ロページが存在していることを指示していれば（ステップ３４５０）、次に更新 されるマクロページが入手され、適切なスイッチブロックへのエントリで始まる 手順が反覆される（ステップ３４２５）。

現行マクロページの次の更新フィールドがＯであれば、変更されるマクロページ はそれ以上存在しないことになり、中間ハウスキーピングが遂行される（ステッ プ３４６０）。この段階は、最終変更バージョンフィールドが０である場合（ス テップ３４１０）にも遂行される。この中間ハウスキーピングの詳細も後述する 。

次に、データベース制御ファイル２９２０のポインタ／カウンタブロック２９２ ２内の現行バージョン番号３０３０及びバージョンブロックポインタフィールド ３０３５が更新される。これが引き渡し点であり、この時点で他の応用が主デー タファイル２９００の最新バージョンを利用可能になる（ステップ３４６５）。

次で最終ハウスキーピングが遂行され（ステップ３４７０）、ＤＢＣロフク及び 変更ロックが戻される。（ステップ３４７５）。

第３５Ａ図乃至第３５Ｃ図は、第３４図の引き渡しルーチンの初期、中間及び最 終ハウスキーピング段階に伴う手順を示す、第３５Ａ図に示す流れ図３５００は 初期ハウスキーピングに対応し、第３５Ｂ図に示す流れ図３５２０は中間ハウス キーピングに対応し、そして第３５Ｃ図に示す流れ図３５４０は最終ハウスキー ピンクに対応する。

初期ハウスキーピング手順における第１段階は古くなったバージョンブロック及 びスイッチブロックを削除することである（ステップ３５０５）、あるバージョ ンブロックは、それが最新のバージョンではない時に、及びバージョンユーザカ ウントフィールド３１２０によって指示されるように、現行ユーザが存在しない 時に古くなるのである。削除は、これらのスイッチブロック及びバージョンブロ ックのリンクを切離すことによって、及びこれらのリンクを切離されたブロック に対応するメモリを自由ブロックのリストに載せることによって発生する。

次で主データファイル２９００の大きさがスナップショットデータファイル２９ １０の大きさと比較される。もし、新マクロページが主データファイル２９００ に付加されていて生データファイル２９００がスナップショットデータファイル ２９１０よりも大きければ、スナップショットデータファイル２９１０を相応に 増大させなければならない（ステップ３５１０）、これを行った時に、スナップ ショットデータファイルに付加したマクロページを、主データファイルに付加し た対応マクロベージのための自然スロットのリストにも載せる。

流れ図３５２０に示す中間ハウスキーピングの第１段階は全ての不法侵入者を退 去させることである（ステップ３５２５）、この不法侵入者とは別の現存マクロ ベージのための自然スロット内にあるマクロベージである０例えば、もしマクロ ページ３のための自然スロット（換言すればスロット番号３）が３に等しくない マクロページを有していれば、そのマクロページはスナップショットデータファ イル２５１０内の何処か他へ移動させられる。

次に、空白の自然スロットに対応するマクロページをこれらの自然スロット内に 移動させる（ステップ３６３０）、本実施例においては、マクロベージ番号３の 最新バージョンを見出し、その自然スロット内へ戻して挿入する。

最終ハウスキーピングにおいては、古くなったバージョン及びスイッチブロック の削除作用のみが行われる（ステップ３５４５）。

第３６図は、あるマクロページの所望のバージョンにアクセスする好ましい実施 例の流れ図３６００である。最初の段階においては、所望のマクロページの最新 バージョンの位置を決定するためにハツシュ表がサーチされる（ステップ３６１ ０）、次に、もしハツシュ表がそのマクロページの位置を指示すれば、そのマク ロページのバージョン番号を試験してそれが所望のバージョン番号よりも小さい か或は等しいかを見る（ステップ３６２０）、これは、既に１つのバージョンと 共に動作している応用プログラムは他の全てのマクロページの同一バージョンに アクセスし続けなジにアクセスしている時には他の若干のバージョンは完了して いるかも知れないから、現行バージョンが適切なバージョンではないかも知れな い。

もし現在アクセスしているマクロページのバージョン番号が応用プログラムのバ ージョン番号よりも大きければ、行ったのと同一の試験によって次に古いバージ ョンマクロベージを見出すためにスイッチブロックポインタがアクセスされる（ ステップ３６３０）。

一旦適切なバージョンが見出されると、所望のマクロページのためのスイッチブ ロックを使用してそのマクロページのためのスナップショットデータファイル２ ９１０内の位置を指し示す（ステップ３６４０）。

ハツシュ表内に入口が見出されなければ（ステップ３６１０）、そのマクロベー ジ番号自体をそのマクロページにアクセスするためのマクロページのスロット番 号として使用する（ステップ３６４０）、次でこのルーチンから出て行く。

Ｇ、適−！ 当業者ならば本発明の範囲或は思想から逸脱することなく本発明に種々の変更を 施し得ることは明白である。従って本発明は本発明の変更及び変化を、それらが 請求の範囲内及び法律的に権利を付与された同等物に入るならば、それらも包含 することを企図するものである。

阜ノ［ｉｌ １棒 葬５※図 茅ｇ図 ヂヂロ 誉１０Ａ（２１ 茅／２１！ 茅７５（２） 茅１９０ ２Ｑ６０ 茅２２の 茅２３．Ａ口 ￥−２３Ｂ図 亮２１ＬＡ国 卒２１ｔ６図 五２ｑ閏 ≠２６ｊｉ ≠２８（２） 賽Ｚ８Ａ国 業テ１と苫スぐ７０ヲ７ 茅３０」 ノで一シコン１Ｏ−ｙ７　μ邊ｑ 弄３２匡 邦５ハロ 英３Ｇ辺 手続補正書（方式） ％式％ ３、補正をする者 事件との関係　出願人 ５、補正命令の日付　平成２年１月３０日国際調査報告 ＋−１−−−ｍ−１ａ−肯−−−ＮｏＰＣＴ／ＵＳ８９１０１５４１Ｉ＃Ｉ−− ｊｌ、−Ｍ拳ＩＡ−−１１−１−−ｍ、ＰｃＴ／ＬＩ５８９１０１５４１国際調 査報告

Claims (1)

1. 【特許請求の範囲】 １．データ処理装置によって実行される複数の応用プログラムによってアクセス されるデータ構造を、データ処理装置に結合されているメモリの中に、これらの 応用プログラムから取得される複数のノードデータ及びノードデータ記述子を含 む応用データから作成するために： （ａ）前記各ノードデータ毎に複数の異なる属性データ対象を作成し； （ｂ）各属性データ対象毎に、各属性データ対象と単一のホールダデータ対象と の間に階層的にホールドされた関係が存在するようにホールダデータ対象を前記 複数の属性対象から選択することによって、前記複数の属性データ対象をホール ドされた関係に従って階層的に編成し； （ｃ）少なくとも１つのノードデータ記述子を伴うノードデータから作成された 前記属性データ対象の中の選択された属性データ対象に関して、前記選択された 属性データ対象の関連データ対象を前記属性データ対象から選択された属性デー タ対象の作成に使用されたノードデータのノードデータ記述子を表わすし、選択 された各関連データ対象を選択された属性データ対象に対応させることによって 非階層的関係を確立し、前記選択された属性データ対象を関係データ対象と呼び 、前記関連データ対象を有していない属性データ対象をエレメントデータ対象と 呼び； （ｄ）前記属性データ対象の少なくとも１つをホールドする関係を有し、且つ何 れの属性データ対象にもホールドされた関係を有していない頂点データ対象を作 成し；（ｅ）前記属性データ対象のための属性ファイルを作成し；（ｆ）前記各 属性データ対象を前記属性ファイル内に挿入し；（ｇ）前記各属性タータ対象毎 に、その属性データ対象にホールドされた関係を有する属性データ対象の１つを 指し示すホールディングポインタを前記属性ファイル内に挿入し；そして（ｈ） 前記属性データ対象間の前記非階層的関係を表わす関連ポインタを前記属性ファ イル内に挿入する前記データ処理装置によって実行される諸段階を具備する方法 。 ２．前記属性ファイルが前記各属性データ対象毎に対象ブロックを含み； 前記属性データ対象を前記属性ファイル内に挿入する段階が、異なる各属性デー タ対象毎に対象見出しブロックを作成し、そして 対象ブロックに関する情報を対象見出しブロック内に挿入する 諸副段階を含む請求の範囲１記載の方法。 ３．ホールディングポインタを前記属性ファイル内に挿入する段階が、 各対象ブロックに対応する属性データ対象のための、且つその属性データ対象が ホールドされている関係を有する属性データ対象の対象ブロックの属性ファイル 内の位置を識別するホールディングポインタを前記各対象ブロック内に挿入する 副段階を含む請求の範囲２記載の方法。 ４．前記対象見出しブロックの選択された組がリンクされ；前記方法が更に、 リンケージポインタを前記選択された組内の各対象見出しブロック内に挿入する 副段階をも具備する請求の範囲２記載の方法。 ５．前記対象ブロックの選択された対象ブロックがホールドされた対象サブブロ ックをも含み； 更に、 各選択された対象ブロックの属性データ対象にホールドされた関係を有する属性 データ対象の対象ブロックを指し示すホールドされたポインタを各選択された対 象ブロックの前記ホールドされた対象サブブロック内に配置する副段階をも具備 する請求の範囲２記載の方法。 ６．関連データ対象の前記各対象ブロックの選択された対象ブロックが関係サブ ブロックを含み； 関連ポインタを前記属性ファイル内に挿入する段階が、各関係データ対象の関連 属性データ対象を指し示す前記関連ポインタの１つをその関係データ対象の前記 関係サブブロック内に挿入する副段階を含む 請求の範囲２記載の方法。 ７．若干の関係データ対象のための対象ブロックが複数の関連ポインタを識別す る複数関係サブブロックを含み；若干の関連データ対象のために、関連ポインタ を挿入する副段階が、前記複数関係サブブロックの１つを指し示すポインタを若 干の関連データ対象のための関係サブブロック内に挿入する副段階をも含む 請求の範囲６記載の方法。 ８．前記若干の関係データ対象のための対象ブロックが複数関係見出しブロック を含み； 前記方法が更に、前記若干の各関係データ対象毎に、その関係データ対象に対す る各関連属性データ対象毎に有効複数関係サブブロックを作成し、そして作成さ れた複数関係サブブロックが有効であることを表わす標識を複数関係見出しブロ ック内に配置する諸副段階をも含む請求の範囲７記載の方法。 ９．各関連データ対象毎に複数関係見出しブロックをリンクする副段階をも含む 請求の範囲８記載の方法。 １０．前記各属性データ対象を複数の対象型の１つとして識別し；前記各対象型 のための議別名を特定し；前記各対象型毎の記憶領域を包含し、その対象型に伴 う情報を保持するディクショナリファイルを作成し；そして各対象型のために特 定された識別名、及びその対象型とその対象型のために特定された識別名との間 の名前ポインタを含むその対象型に伴う情報を前記記憶領域内に挿入する諸段階 をも具備する請求の範囲１記載の方法。 １１．識別名と関連情報とを記憶領域内に挿入する段階が、同一の属性データ対 象にホールドされている関係を有する全ての属性データ対象のための記憶領域に 関係している対象型を有する属性データ対象を前記属性ファイル内に挿入する段 階を含む請求の範囲１０記載の方法。 １２．前記ディクショナリファイルの記憶領域が前記各対象型毎に対象型ブロッ クを含み、前記方法が前記各対象型ブロック内に前記対象ブロックの順序を付す ためのリンケージポインタを配置する段階を含む請求の範囲１０記載の方法。 １３．前記各対象型ブロック内に、それらの型の属性データ対象が順序付けられ ているか否かの標識を配置する段階をも含む請求の範囲１２記載の方法。 １４（ａ）前記頂点データ対象のための第１のファイルを作成し；そして （ｂ）前記頂点データ対象のための第１のファイル内に、前記頂点データ対象に ホールドされている関係を有する属性データ対象を識別するホールディングポイ ンタを挿入する諸段階をも具備する請求の範囲１０記載の方法。 １５．前記第１のファイルが前記ディクショナリファイルである請求の範囲１４ 記載の方法。 １６．（ａ）前記属性データ対象の若干に、前記属性ファイル内のこれら若干の 属性データ対象へ迅速にアクセス可能ならしめるための独特なキー値を割当て； （ｂ）前記各キー値が１つの組の中のみに存在するように、それぞれが異なる組 のキー値に対応する葉ブロックを作成し；（ｃ）前記各葉ブロック内に、それら の葉ブロックに対応して割当てられたキー値の１つを有する各属性データ対象の 属性ファイル内の位置を指し示すポインタを挿入し；そして（ｄ）前記各キー値 の組の中から特定の葉ブロックのキー値に対応するキー値を割当てられている所 望の属性データ対象の位置を得るために、前記各組のキー値に対応する葉ブロッ クの迅速な決定を行うようにキー値の組に従って前記葉ブロックを編成する 諸段階をも具備する請求の範囲１記載の方法。 １７．前記索引ブロックを編成する段階が、該ブロックを少なくとも１つの木構 造内で順序付ける副段階を含む請求の範囲１６記載の方法。 １８．前記索引ブロックを木構造内で順序付ける副段階が：（ａ）前記木構造内 へのエントリを提供する木構造の根ブロックを作成し； （ｂ）それぞれが前記キー値の組の重なり合わない異なる群に対応する複数の枝 ブロックを作成し； （ｃ）前記各組のキー値の重なり合わないキー値群を通る独特な経路を提供する ように前記枝ブロックを編成し；そして（ｄ）前記各独特な経路が、所望属性デ ータ対象に割当てられたキー値を含み特定の経路を提供したキー値の組に対応す る葉ブロックに達するように、前記葉ブロック及び前記枝ブロックを編成する 諸副段階を含む請求の範囲１７記載の方法。 １９．前記若干の属性データ対象の中の特定された対象に関して、該対象に与え られたキー値の索引ブロックに達する経路を包含する木構造を識別する索引ディ レクトリブロックを前記属性ファイル内に構築する段階をも含む請求の範囲１８ 記載の方法。 ２０．前記ホールダポインタを前記属性データファイル内に挿入する段階が： 各属性データ対象の対象型を決定し； 各エレメントデータ対象の対象型に従って、前記属性ファイル内の属性ファイル 領域を各エレメントデータ対象及び前記ホールディングポインタに割当て； 前記属性データ対象の１つを包含する各属性ファイル領域を指し示す対象ポイン タを誘導し； 各ホールダデータ対象を指し示すポインタとして、各ホールダデータ対象にホー ルドされた関係を有する少なくとも１つのエレメントデータ対象のために前記対 象ポインタを設け；そして 各属性データ対象のための前記属性領域内の各属性データ対象のためのホールダ ポンイタとして、各エレメントデータ対象の前記ホールダデータ対象を包含する 前記属性ファイル領域の１つを指し示すポインタを設ける 諸副段階を具備する請求の範囲１０記載の方法。 ２１．前記ホールディングポインタを前記属性データファイル内に挿入する段階 が、 同一の対象型である各属性データ対象毎の前記属性ファイル領域内に、その属性 データ対象と同一の型の属性データ対象の１つのために少なくとも１つの対象ポ インタを含ませることによって、同一の対象型である属性データ対象の選択され た組をリンクする 副段階をも具備する請求の範囲２０記載の方法。 ２２．前記属性データ対象の選択された組をリンクする段階が、第１の対象ポイ ンタとして、属性データ対象の各組の最初の組を指し示すポインタを設ける 副段階を含む請求の範囲２１記載の方法。 ２３．属性データ対象の選択された組をリンクする段階が、第２の対象ポインタ として、属性データ対象の各組の最後の組を指し示すポインタを設ける 副段階をも含む請求の範囲２２記載の方法。 ２４．前記属性データ対象の組が、エレメントデータ対象だけしか含まない請求 の範囲２３記載の方法。 ２５．前記ホールダポインタを前記属性データファイル内に挿入する段階が、 同一のホールダデータ対象を有する各属性データ対象毎の前記属性ファイル領域 内に、その属性データ対象と同一のホールダデータ対象を有する属性データ対象 の１つのために少なくとも１つの対象ポインタを含ませることによって、同一の ホールダデータ対象にホールドされた関係を有する属性データ対象の選択された 組をリンクする 副段階をも具備する請求の範囲２０記載の方法。 ２６．前記属性データ対象の選択された組をリンクする段階が、第１の対象ポイ ンタとして、属性データ対象の各組の最初の組を指し示すポインタを段ける 副段階を含む請求の範囲２５記載の方法。 ２７．属性データ対象の選択された組をリンクする段階が、第２の対象ポインタ として、属性データ対象の名組の最後の組を指し示すポインタを設ける 副段階をも含む請求の範囲２６記載の方法。 ２８．前記属性データ対象の組が、エレメントデータ対象だけしか含まない請求 の範囲２７記載の方法。 ２９．関連ポインタを前記属性ファイル内に挿入する段階が：前記エレメントデ ータ対象の第１の組の１つにホールドされた関係を有する前記関係データ対象の 各第１の対象毎に、その関係データ対象に係る関連属性データ対象がそのエレメ ントデータ対象のための属性ファイル領域内で特定されているか否かを決定し； 前記第１の組内の各エレメントデータ対象毎の関連ポインタとして、そのエレメ ントデータ対象にホールドされた関係を有する関係データ対象に係る関連属性デ ータ対象の対象ポインタを選択し、第１の関係データ対象に係る関連属性データ 対象がそのエレメントデータ対象の属性ファイル領域内で特定されているエレメ ントデータ対象の各第１の組毎に、そのエレメントデータ対象の属性ファイル領 域内に選択された関連ポインタを挿入し； 前記関係データ対象の１つがホールドされた関係を有している前記各第１の組の エレメントデータ対象毎の属性ファイル領域内に、その関係属性対象の関連属性 データ対象がその属性データ対象の属性ファイル領域内で特定されていない時に は、そのエレメントデータ対象のための属性ファイル領域内の関連データ対象領 域を割当て；そして そのエレメントデータ対象の関連データ対象領域内に、その関連データ対象のた めの関連ポインタとして、前記選択された関連属性データ対象の対象ポインタを 段ける諸副段階をも具備する請求の範囲２０記載の方法。 ３０．複数の応用プログラムを実行する少なくとも１つの中央処理装置、及び前 記応用プログラムに共通するデータ構造を包含するメモリを含むデータ処理シス テムにおいて、前記共通データ構造は複数の属性データ対象を有するデータ構造 を包含し、各属性データ対象は他の１つの属性データ対象に、或は頂点に階層的 にホールドされた関係を有し、前記属性データ対象の中の選択された対象は非階 層的関係を有し、各属性データ対象は該対象にホールドされた関係にある他の属 性データ対象のためのメモリ領域を指し示すポインタを含む組合わされたメモリ 領域を有し、前記属性データ対象の所望の１つを前記データ構造に加えるために ： 前記所望の属性データ対象のためのメモリ領域を作成し；ホールダ属性データ対 象として、前記所望の属性データ対象がホールドされた関係を有する属性データ 対象の１つを位置付けし； 前記ホールダ属性データ対象のためのメモリ領域内に、前記所望の属性データ対 象のメモリ領域を指し示すポインタを加え；そして 前記所望の属性データ対象と、前記ホールダ属性データ対象にホールドされた関 係を有する他の属性データ対象とをリンクする 前記中央処理装置によって実行される諸段階を具備する方法。 ３１．複数の応用プログラムを実行する少なくとも１つの中央処理装置、及び前 記応用プログラムに共通するデータ構造を包含するメモリを含むデータ処理装置 において、前記共通データ構造は複数の属性データ対象を有するデータ構造を包 含し、各属性データ対象は他の１つの属性データ対象に、或は頂点に階層的にホ ールドされた関係を有し、前記属性データ対象の中の選択された対象は他の属性 データ対象と非階層的関係を有し、各属性データ対象は組合わされたメモリ領域 を有し、前記属性データ対象の所与の対象と前記属性データ対象の関連対象との 間に所望の非階層的関係を作成するために：前記関連属性データ対象の位置を決 定し；前記所与の属性データ対象のメモリ領域にアクセスし；そして 前記所与の属性データ対象の前記メモリ領域内に、前記関連属性データ対象位置 を指し示すポインタを配置する前記中央処理装置によって実行される諸段階を具 備する方法。 ３２．前記所望の非階層的関係は所定の型の関係の１つであるように選択され、 前記メモリシステムは前記非階層的関係の型及び前記属性データ対象のためのメ モリ領域内の何処に前記型の関連属性データ対象を指し示すポインタが見出され るかを識別し、ポインタを配置する段階が； 前記所望の非階層的関係の型を決定し；前記型領域内に、前記所望の非階層的関 係の型の関係のための前記メモリ領域の位置を見出し；そして前記非階層的関係 型に関して見出された前記所与の属性データ対象のメモリ領域内に前記ポインタ を配置する諸副段階を含む請求の範囲３１記載の方法。 ３３．複数の応用プログラムを実行する少なくとも１つの中央処理装置、及び前 記応用プログラムに共通するデータ構造を包含するメモリを含むデータ処理シス テムにおいて、前記共通データ構造は複数の属性データ対象を有するデータ構造 を包含し、各属性データ対象は前記属性データ対象の中の単一のホールダ属性デ ータ対象に、或は頂点に階層的にホールドされた関係を有し、前記属性データ対 象の中の選択された対象は非階層的関係を有し、各属性データ対象が、 前記属性データ対象の同一ホールダ属性データ対象にホールドされた関係にある 属性データ対象を指し示すシーケンスポインタ、 前記属性データ対象の中の前記ホールダ属性データ対象を指し示すホールダポイ ンタ、及び その属性データ対象が非階層的関係を有している属性データ対象の何れかの関連 属性データ対象を指し示す関連ポインタを包含する組合わされたメモリ領域を有 し、前記属性データ対象の中の所望の属性データ対象のためのメモリ領域を消去 するために： 前記所望の属性データ対象のためのメモリ領域を位置付けし；前記関連ポインタ を消去し； 前記ホールダ属性データ対象のためのメモリ領域を位置付けし； 前記所望の属性データ対象のためのホールダポインタの１つを消去し； 前記所望の属性データ対象を指し示すポインタの何れかを除去するように前記シ ーケンスポインタを調整し；そして前記所望の属性データ対象にホールドされた 関係を有する、或は包含の木属性データ対象の中の別の属性データ対象にホール ドされた関係を有する属性データ対象の全ての包含の木内の属性データ対象のた めのメモリ領域を消去する前記中央処理装置によって実行される諸段階を具備す る方法。 ３４．複数の応用プログラムを実行する少なくとも１つの中央処理装置、及び前 記応用プログラムに共通するデータ構造を包含するメモリを含むデータ処理シス テムにおいて、前記共通データ構造は複数の属性データ対象を有するデータ構造 を包含し、各属性データ対象は他の１つの属性データ対象に、或は頂点に階層的 にホールドされた関係を有し、前記属性データ対象の中の選択された対象は他の 関連属性データ対象と非階層的関係を有し、各属性データ対象はその関連属性デ ータ対象と非階層的関係を有する関連属性データ対象の何れかを指し示す関連ポ インタを包含する組合わされたメモリ領域を有し、前記各関連データ対象毎の組 合わされたメモリ領域はその関連属性データ対象と非階層的関係を有する属性デ ータ対象を指し示す非階層的関係ポインタを包含し、所与の属性データ対象と関 連属性データ対象との間の所望の非階層的関係を消去するために：前記所与の属 性データ対象のためのメモリ領域を位置付けし；前記所与の属性データ対象のた めのメモリ領域内の前記所与の関連属性データ対象を指し示す関連ポインタを位 置付けし；前記関連ポインタを使用して前記所与の関連属性データ対象を位置付 けし； 前記関連属性データ対象のためのメモリ領域内の前記所与の属性データ対象を指 し示す非階層的関係ポインタを位置付けし；前記非階層的関係ポインタを消去し ；そして前記関連ポインタを消去する 前記中央処理装置によって実行される諸段階を具備する方法。 ３５．データ構造を更新してデータ構造の新バージョンを作成するために使用さ れ且つ一連のベージに分割されている主データファイルと、前記データ構造の異 なるバージョンにアクセス可能ならしめ且つそれぞれが前記主データファイルの ベージの１つを包含するのに充分に大きい複数のスロットからなる副ファイルと を包含するメモリシステム内に記憶されているデータ構造の異なるバージョンを 管理する方法であって：前記データ構造の新バージョンを発生して前記主データ ァイル内の０或はそれ以上のベージを変更し；前記データ構造の各新バージョン 毎に、前記データ構造の新バージョンに関する情報を包含する新バージョンブロ ックを作成し； 前記データ構造の新バージョンの発生により変更された前記主データファイルの 各ベージ毎に、対応し且つ独特なスイッチブロックを作成し； 前記副ファイル内に、前記データ構造の新バージョン内の変更された前記主デー タファイルからの各ベージをコピーし；そして 前記各スイッチブロック内に、各スイッチブロックに対応するベージの識別名、 ベージが変更されたバージョン、及び変更されたぺージをコピーした副ファイル 内のスロットを挿入する諸段階を具備する方法。 ３６．前記ベージの中の同一ぺージに対応するスイッチブロックをリンクし；そ して 前記主データファイル内の各ベージに対応する少なくとも１つのスイッチブロッ クを位置付けする表を構築する諸段階をも含む請求の範囲３５記載の方法。 ３７．データ構造の異なるバージョンを記憶し、管理するメモリシステムであっ て； データ構造の新バージョンを作成するために、一連のベージに分割され且つデー タ構造の最新バージョンを包含する主データファイル手段； 前記主データファイル手段に結合され、外部からのアクセスに備えて前記データ 構造の異なるバージョンを保持するためにそれぞれが前記主データファイルのベ ージの１つを保持するのに充分な大きさの複数のスロットを包含する副ファイル 手段；及び 前記主データファイル手段と前記副ファイル手段とに結合され、前記メモリシス テムの管理に必要な情報を記憶し、且つそれぞれが前記データ構造の異なるバー ジョンに関する情報を包含する複数のバージョンブロック、及びそれぞれが前記 データ構造のバージョンの１つと、対応するバージョン中に変更された前記デー タ構造内のあるベージとに対応し、それぞれがそのスイッチブロックに対応する ベージのための識別名、そのベージが変更されたバージョン、及び変更されたペ ージをコピーした前記副ファイル手段内のスロットを包含する複数のスイッチブ ロックを含むデータベース制御ファイル手段 を具備するメモリシステム。 ３８．前記スイッチブロンク手段が前記ベージの中の同一のベージに対応するス イッチブロックに関するリンクをも含み、前記メモリシステムが更に、 前記主データファイル手段内のベージの１つに対応する少なくとも１つのスイッ チブロックを位置付けするためのマッピング情報を包含する表 をも具備する請求の範囲３７記載の方法。 ３９．中央処理装置に結合され、頂点、前記中央処理装置によって実行される応 用プログラム内の異なるノードデータにそれぞれ対応する複数のエレメント、前 記各エレメントに関して他の１つのエレメント或は頂点のみがそのエレメントを ホールドする関係を有するように制限された前記エレメント間の階層的ホールデ ィング関係、及び前記エレメントに係る非階層的関係を含むデータ構造を包含す るメモリシステムであって：前記各エレメントに関する情報を包含し、且つ前記 エレメントに関する識別情報を包含する見出し部分、前記各エレメントが前記ホ ールディング関係の１つを有するエレメントを識別するホールディングポインタ 、及び前記非階層的関係を特定する関係識別名を含むエレメント記憶手段；及び 前記頂点に関する情報を包含し、且つ 前記頂点のための識別名情報、及び 前記頂点とホールディング関係の１つを有するエレメントを指し示すポインタ を含む頂点記憶手段 を具備するメモリシステム。 ４０．前記データ構造は、前記頂点にホールドされた関係を有する少なくとも１ つの文脈を含み； 前記少なくとも１つの文脈は、少なくとも１つの前記エレメントをホールドする 関係を有し； 前記各少なくとも１つの文脈は包含の木に対応し、前記包含の木はそのエレメン トがホールドする関係を有する全てのエレメント及び前記少なくとも１つの文脈 の包含の木内のエレメントの中の他のエレメントがホールドする関係を有する何 等かの他のエレメントを含み、前記各エレメントは前記少なくとも１つの文脈の １つだけの包含の木の中に含まれており；前記エレメントに、前記少なくとも１ つの文脈の包含の木内のエレメントが、異なる少なくとも１つの文脈の包含の木 内のエレメントの名前と異ならせる必要がない独特の名前を付け；前記メモリは 更に 前記少なくとも１つの文脈を包含し、且つ前記少なくとも１つの文脈のための識 別名情報、及び前記各少なくとも１つの文脈をホールドする関係を有するエレメ ントを指し示すエレメントポインタをも含む文脈記憶手段 をも含む請求の範囲３９記載のメモリシステム。 ４１．前記エレメントの若干はそれぞれ複数のキー値の異なるキー値に組合わさ れ、前記メモリが更に： 前記複数のキー値を包含し、且つ 前記キー値の重なり合わない副組を順序付けた態様で配置する索引記憶部分、及 び 前記各キー値毎に、そのキー値に組合わされているエレメントのための識別情報 の前記エレメント記憶手段内の位置を特定するキー値ポインタ をも含む索引記憶手段；及び 前記各キー値を包含する前記索引記憶手段の前記部分を識別する索引ポインタ をも含む請求の範囲３９記載のメモリシステム。 ４２．前記エレメント及び関係の若干が異なる型に組合わされ、前記メモリが更 に： 前記エレメント及び関係の型に関する情報を包含し、且つ前記エレメントの各型 毎に、その型のエレメントに関する情報を包含するエレメントフィールド、及び 前記関係の冬型毎に、その型の関係に関する情報を包含する関係フィールド を含むディクショナリ記憶手段；及び 所望のキー値を包含する前記索引記憶手段の部分を識別する索引ポインタ をも含む請求の範囲３９記載のメモリシステム。 ４３．共通データ構造へのアクセスを維持し提供するデータ処理システムであっ て： 頂点、それぞれが中央処理装置によって実行される応用プログラム内の異なるノ ードデータに対応する複数のエレメント、前記各エレメントに関して他の１つの エレメント或は頂点のみがそのエレメントをホールドする関係を有するように制 限された前記エレメント間の階層的ホールディング関係、及び前記エレメントに 係る非階層的関係を含む前記共通データ構造を介してデータを交換する複数の応 用プログラムを実行する中央処理装置； 前記中央処理装置に結合され、前記共通データ構造を包含し、且つ 前記各エレメントに関する情報を包含し、且つ前記エレメントに関する識別情報 を包含する見出し部分、前記各エレメントが前記ホールディング関係の１つを有 するエレメントを識別するホールディングポインタ、及び前記非階層的関係を特 定する関係識別名をも含むエレメント記憶手段； 前記頂点に関する情報を包含し、且つ 前記頂点のための識別名情報、及び 前記頂点にホールドされた関係の１つを有するエレメントを指し示すエレメント ポインタ をも含む頂点記憶手段 をも含むメモリ を具備するデータ処理システム。 ４４．共通データ構造へのアクセスを維持し提供するデータ処理システムであっ て： 頂点、それぞれが中央処理装置によって実行される応用プログラム内の異なるノ ードデータに対応する複数のエレメント、前記各エレメントに関して他の１つの エレメント或は頂点のみがそのエレメントをホールドする関係を有するように制 限された前記エレメント間の階層的ホールディング関係、及び前記エレメントに 係る非階層的関係を含む前記共通データ構造を介してデータを交換する複数の応 用プログラムを同時に実行する複数の中央処理装置； 前記中央処理装置に結合され、前記共通データ構造を包含し、且つ 前記各エレメントに関する情報を包含し、且つ前記エレメントに関する識別情報 を包含する見出し部分、前記各エレメントが前記ホールディング関係の１つを有 するエレメントを識別するホールディングポインタ、及び前記非階層的関係を特 定する関係識別名をも含むエレメント記憶手段； 前記頂点に関する情報を包含し、且つ 前記頂点のための識別名情報、及び 前記頂点にホールドされた関係の１つを有するエレメントを指し示すエレメント ポインタ をも含む頂点記憶手段 をも含むメモリ を具備するデータ処理システム。