JPH09503326A - データの格納および取り出しの方法ならびにその装置 - Google Patents

Abstract

(57)【要約】 少なくとも２つの識別子の数値的連結からなるキーフィールドを有するレコードの作成を含むデータの格納および取り出しのための方法とシステムである。望ましくは、キーフィールドは実体形式の識別子と属性の識別子を含む。さらに望ましくは、実体形式たとえば「会社」等が一般的であり実体たとえば「ＡＢＣ有限会社」が特定されており、および属性たとえば「電話番号」は、実体の識別子を含む。数値は、リスト内のそれぞれのエントリに数値が予め割り当ててあるような単語および／または文章のリストから取得するのが望ましい。望ましくは、レコードの幾つかがデータを格納し、その他のレコードはデータ間の関連性の詳細を格納する。レコードの幾つかはデータを格納し、その他のレコードはデータ処理を制御することがよい。

Description

【発明の詳細な説明】 データの格納および取り出しの方法ならびにその装置 本発明は既知の概念とは基本的に異なり、従来の計算機に関連する多くの欠点 を緩和するような計算機へのアプローチの改良の実現のための基盤を提供する。 従来の計算機システムへのアプローチは、何が必要とされ、それをどのように 実装するかについての詳細な仕様の準備から始まるのが普通である。この初期段 階はしばしば困難が伴う。計算機システムで実際に要求されていることがシステ ムの少なくとも一部を運用するまで理解されないことも多い。さらに、多くのシ ステムは非常に大きく複雑なため、内部的には完全に首尾一貫したシステムの仕 様の作成さえも極めて困難になる。 従来の計算機システムを構築する第２段階はシステム仕様を専門のプログラマ に渡すことで、この段階でもしばしば困難に遭遇する。仕様書に記載された要求 の解釈または単なる実現にかかる潜在的な問題を別にすれば、従来の計算環境で 直面する最大の問題のひとつは、システムが何を行ない、どのように行なうかを 説明した解説書の生成と、その後の計算機プログラムの保守である。既存のシス テムの保守で頻繁にみられる問題は、既存のレコード構造に追加フィールドを加 えることが所望の場合に発生する。この場合、問題のレコードを含むファイルに アクセスする計算機システム内部の全てのプログラムが修正の対象となることが 多い。 これまでに行なわれた多くの研究では、現在のプログラミングに係る全ての労 力の８０％近くが既存のシステムの保守に費されており、残りのプログラミング 労力のわずか２０％だけが新規アプリケーションの開発に費すことが可能である ことが示されている。 もっとも基本的なレベルですら困難がある。たとえば、データを磁気媒体に記 録する場合、従来は固定長または可変長レコードのどちらかに記録している。特 に記録したデータの並べ替えが必要とされるおよび／または高速アクセスが所望 の場合、記録データにインデックスをつけた固定長レコードが好適である。イン デックスは本来のデータの一部として記録したり、またはこれとは別に記録する ことができる。インデックスは固定長である。固定長レコードは選択したレコー ド長に適合するようにデータを合わせなければならないと言う明白な欠点を有し ている。 計算機データベース・システムの工夫に相当以上の人的資源が投資されてきた 。この投資と該システムの一般化は現代社会における該システムの必要性を裏付 けるものである。システム要求はますます高度になり、これの１つの態様は多対 多の関連性の記録処理の要求となっている。幾つかの既知のシステムではこのよ うな要求に適合していると主張しているが、周知の限り、これらはどれも幾つか の制約および／または非常に複雑な処理条件を有すると思われる。 本発明は従来の計算機システムを支える概念とは別個の概念的アプローチを用 いて前述の欠点の全てを緩和しようとするものである。 本発明の１つの態様によれば、２つの数値を含むキーフィールドを有し、一つ は実体(entity)の種類を識別し、一つは識別した種類の実体の属性を識別するレ コードの構成を含むデータの構成と取り出しの方法が提供される。 本発明の別の態様によれば、３つの数値を含むキーフィールドを有し、一つが 実体の種類を識別し一つが識別した種類の実体を識別し、もう一つが実体の属性 を識別するレコードの構成を含むデータの格納と取り出しの方法が提供される。 本発明の別の態様によれば、数値が単語に割り当てられたルックアップ・テー ブルまたはファイルから取り出した数値を含むキーフィールドを有するレコード の構成を含むデータの格納および取り出しのための方法が提供される。 本発明の別の態様によれば、データレコードおよびレコードの構成を含み、該 レコードが共通ファイル内で該レコードのデータ処理および記録の流れを制御す るデータの格納および取り出しのための方法が提供される。 本発明の別の態様によれば、情報を含むキーフィールドを有するレコードとし てデータ間の関連性の詳細な格納を含み、この情報で関連性の詳細が格納される データを含むレコードのキーフィールドが識別できるようなデータの格納および 取り出しのための方法が提供される。 本発明の別の態様によれば上記５つのパラグラフのいずれかに記載した方法を 実施する装置が提供される。 本発明の実施例とその変化について、添付の図面を単なる例として参照しつつ 説明を行なう。図面において、 図１は本発明の実施例により作成した典型的なレコードである。 図２は本発明の実施例により作成した典型的なレコードのキーフィールドであ る。 図３はデジタル形式で圧縮英数字情報を格納するためのキーフィールドの一部 の使用法である。 図４ａと図４ｂは本発明の説明した実施例により形成した実際のレコードの例 である。 図５ａと図５ｂは一方において実体形式(entity type)と属性の関連性、また 他方において実体形式とアプリケーションの間の関連性を示す意味的ネットワー クである。 図６はアプリケーションとオペレータの間の関連性を示す意味的ネットワーク である。 図７は実体形式とシソーラス（類義語）項の間の関連性を示す意味的ネットワ ークである。 第１に、キーフィールドの構成のために選択した情報を説明する必要がある。 これはそれ自体が本発明の概念の重要な態様をなすためである。以下の説明にお いて幾つかの術語が参照を容易にするために用いられている。この術語の基盤は 次の通りである。 最初に情報の項目を考えたとき、問題の項目の種類を考える。これはすなわち 「実体形式」を考えることである。 次に、特定の項目それ自体を考える。すなわち「実体」を考える。 さらに、実体について何が既知かまたは何が既知であることを所望するかを考 える。すなわち実体の「属性」を考える。 ＡＢＣ有限会社と言う架空の会社に基づいた簡単な例を示す。 実体の形式は「会社」である。 実体は「ＡＢＣ有限会社」である。 ＡＢＣ有限会社の属性はこれの実際の「所在地」である。 ＡＢＣ有限会社の別の属性はこれの実際の「電話番号」である。 多くの異なる実体形式をシステム内に記録し、多くの実体が実体形式に存在し 、多くの属性がいずれかひとつの実体について存在することがあるのは明らかで ある。実体形式は実体形式を実体として考える場合それ自体が属性を有すること がある。たとえば、「所在地」と言う特徴は実体形式「会社」の属性と考えられ る、すなわち全ての会社は所在地を有する。 いずれかひとつの実体が幾つかの異なる実体形式に所属し、いずれか１つの属 性が１つ以上の実体形式の属性であることも真実である。たとえば、顧客であり 供給者でもある会社を考える。実体形式顧客と供給者の実体の値はどちらも同じ 、すなわち会社の実際の名称である。同様に、顧客住所と供給者住所の属性値も 同一である。しかし、供給者と顧客の呼出名称の属性値はどちらも別であると思 われる。 １つの実体が幾つかの異なった実体形式に属するような複雑な相互関係を維持 しようとした場合従来のシステムでは困難がみられる。つまり、それぞれの関連 性を個別に格納するのを避けようとし始めた場合である。必要とされるデータの 格納の大きさを別にしても、データを更新するのが必要となった時に発生する問 題のためそれぞれの関連性を個別に格納するのを回避することが強く所望されて いる。共通データは１回だけ格納されるのが望ましい。こうすると同じデータに ついて違うエントリ同士で矛盾が発生する危険はない。１つだけのエントリを更 新すればよくデータ・エントリが減少する。しかし、従来のシステムでこのよう な利点を実現するのは困難である。 別の簡単な例を考えてみる。 ＡＢＣ有限会社には１０名の従業員がいる。「会社」が実体形式、「ＡＢＣ有 限会社」が実体、「従業員名」が属性の説明、およびたとえば「ケビン・スミス 」が属性値であるとする。しかし、「従業員名」の値はそれ自体で実体であると 考えられる（これは実体「ＡＢＣ有限会社」の部分実体と考えられる）。つま り、実体（または部分実体）「従業員名」は、これの属性記述に「会社の電話番 号」を有することがある。それぞれの関連性が別々に記録された場合、それぞれ の従業員ごとに１回づつ、同じ電話番号が１０回記録される。さらに、電話番号 が変更された場合、１０か所の電話番号全てが同様に更新されない危険が大きい 。当然、電話番号は１回だけ格納する方が優れているであろう。しかし、属性の 説明「会社の電話番号」の属性値は実際には会社と従業員の間の関係の属性であ る。関係が壊れた場合、すなわちケビン・スミスがＡＢＣ有限会社の従業員であ ることをやめると、属性値（すなわち現在の電話番号）は明らかに有効でなくな る。実体「ケビン・スミス」は属性の記述「会社の電話番号」に新しい値を取る かも知れないが、ＡＢＣ有限会社との関係は壊れ、その結果として、明らかに、 その関係の属性（会社の電話番号）は有効でなくなる。関係を取り除くと属性も 除去される。これらの概念によるデータの記録は、従来のシステムにより実現さ れないものである。対照的に、本発明はこのような概念によるデータの格納を基 にしている。 「従業員名」の値に関連して前述したように、実体は部分実体を有することが ある。これは、関係（すなわちＡＢＣ有限会社による雇用）を排除した結果とし て属性が除去されたため、それまでの属性値（すなわち現在の電話番号）が除去 されても、「会社の電話番号」を「ケビン・スミス」が保持していることを記述 している認識から明らかである。「ケビン・スミス」が記述「会社の電話番号」 を有する属性を保持していることは、「ケビン・スミス」が実際に独立した実体 であると考えられることを表わしている。この特定の実体は、もともと、実体「 ＡＢＣ有限会社」の部分実体だった。部分実体「ケビン・スミス」は「自宅住所 」の記述のある属性を有することになるが、「自宅住所」はそれ自体が属性を有 することがある。一例としては「課税値」の記述を有する属性がある。「自宅住 所」の記述を有する属性の値は、それ自体が実体であると考えられる。ここで「 ケビン・スミス」は「ＡＢＣ有限会社」の部分実体であり、「自宅住所」は「ケ ビン・スミス」の部分実体である。これは実体の２つ下降するレベルと見なすこ とができる。本発明で説明する実施例においては、１０の９乗までの値が独立し た実体値を識別するために利用できる。１つレベルを下降すると、すなわち 部分実体の第１のレベルを考えると、さらに１０の９乗の値が利用できるように なる。実体値の最高レベルはそれぞれが関連した独立の部分実体レベルを有して おり、実体のそれぞれ１つ下のレベルで１０の９乗×１０の９乗の値というよう に格納できることが分る。 従来、磁気媒体上のレコードの物理的な位置を考える必要も多かった。これは ハッシュ・ルーチンを用い、レコードへのポインタがレコードの記録されている 磁気媒体上の物理的位置のアドレスに直接関係することから選択されたと思われ る。したがって、従来のシステムではレコードへのアクセスが磁気媒体上の物理 的位置の間の大幅な移動に関係することが多い。これは本発明を用いれば回避で き、結果的にアクセスおよび処理時間が改善される。 実際に格納されようとしている情報さらに、その情報に関係するまたはそこか らもたらされる知識の一般的な考察に戻ると、データベース内のレコードを単に 調べても、データの意味を示すものは何もない。つまり、レコードはデータのコ ンテキストを格納していない。本発明のシステムを使用と、レコードに記録され たデータはキーフィールドを用いてレコードを効率的に検索するような答を問す ることで取り出すことができる。つまり、何らかのレコードを取り出すとき、そ のレコードへの質問または航行(naviagtion)はデータを考察しているコンテキス トを定義したことになる。コンテキストがこのように定義されるので、レコード 自体には格納しなくとも良い。これは厳密に従来のデータ格納システムと対照的 である。さらに、最重要な点が得られる。すなわち、システムの残りに対して潜 在的な影響を考慮することなく、データベースのいずれか１つの独立した部分を 変更できる。つまり、システム全体の一貫性が担保されるために、個々の関係が 正しく格納されることを担保する必要しかない。これは従来のシステムに対して 非常に明らかなコントラストである。 従来のシステムでは、システムのいずれか１つの部分を変更する場合、システ ムの残り全体に対する潜在的な影響を考慮する必要がある。システムの一部分に 対する変更から発生する影響の全てを理解して充分に統御することは、人間の現 実的な能力を実際に越えていることが多い。最小限でも、従来のシステムでのこ のような変更は、単純にシステムを維持する上で巨大なオーバヘッドを招く。当 然、システムの維持に係る時間と労力をもっと生産性の高いところに費すことが できない。すなわちシステムの拡張または新規システムの構築に費せない。 この特徴の重要な態様は、独立したプログラム内ではなく、データベース内で 認証を行なうことである。 そのため、本発明によって実現されるものが従来コンピュータ・プログラム内 にコード化されていた規則や手順の効率的な格納であり、実際には格納データの 一部であることは明らかになろう。同時に、データのコンテキストはデータの一 部として格納されず、データ取り出しの処理それ自体から得られる。 すなわち、データ取り出し作業には内存する知識がある。しかしこのような知 識の存在、または非常にわずかでもこれの使用は、これまでに認識されていなか った。また、この知識を用いることにより、システム全体としての一貫性を維持 するために非常な努力を払う必要がないシステムの構築を行なうことの可能性は 、これまで認識されなかった。 レコードに到達するための径路は、格納データ間の航行と見なすことができる 。航行が行なわれるメカニズムは後述する。 本発明のシステムにおいては、レコードに到達するための径路のレコードを保 持するだけで、データベース内を「後ろ向き」に航行できるようになる。このよ うな機能は望ましいことが多い。これは従来システムでは一般に存在せず、存在 しても非常に複雑な規則と手順を適用することになる。 従来の計算環境においては、プロトタイプを構築して、提案されたアプリケー ションのデモおよび／または証明を行う。さらに、プロトタイプをコード化して 完全に作動するシステムに先行させる必要がある。一般に、コード化の段階はも っとも時間がかかりもっともエラーが発生し易い。本発明によれば、プロトタイ プ作成は「運用中の」システムで行なえ（システムの他の部分の統合性に対する 潜在的な影響がないため）、プロトタイプはすぐ所望のアプリケーションの最終 製品版になる。 これらの点とレコード位置に関して前述した利点（ＡＢＣ有限会社従業員の電 話番号の例）は、従来の計算技術に比較して大幅な高率の改善となる。データ取 り出しにかかるアクセス時間が改善される。アプリケーション開発時間は相当に 改善され、従来システムの保守のオーバヘッドと、本発明のシステムのほとんど 完全に保守が不要なことの間には、比較すべき点がほとんどない。 本発明によるさらなる利点も存在する。このような利点の１つは、システム全 体が非常に小さい「コア」システムによって制御されることである。コア・プロ グラムは従来の計算機ハードウェアの処理メモリー内に全体を格納できる（多数 ユーザがいる仮想またはページング・ハードウェア・システムであっても）。説 明する実施例はＩＢＭ製ＡＳ４００計算機に実装した。 本発明による別の利点はコア・プログラムの更新に関するものである。何時で もコア・プログラムを更新することが望ましいと考えられる場合、おそらくはあ るレコード形式に格納したデータとの関連で何らかの新しい処理形式を取ること ができるようにする場合、更新したコア・プログラムを容易に実装できる。一般 には、コア・プログラムへの更新が必要になることはまれなことである。しかし このような何らかの更新が必要であれば、アプリケーションの規則や手順を妨害 することなく処理できる。これは従来「アプリケーション・プログラム」と見な されるべきものが「プログラム」として扱われないためである。これらは、コア ・プログラムの一部を構成するものでも、または何らかの方法でコア・プログラ ムを変更するものでもない。従来のアプリケーション・プログラムの等価物は、 前述したように、データそれ自体の一部として本発明により効率的に格納され、 および／または、データ取り出しに関係するコンテキストまたは航行に内在する 一部として部分的に格納されている。 文書化の問題も大部分が回避されるが、これは従来の意味でのプログラムが事 実上存在しないためである。つまり、従来のシステムと比べ実際の文書は極くわ ずかである。 本発明のシステムにより逆転関係の定義の実装が可能である。これは本発明の 特に有利な特徴である。 ここで説明する本発明の実施例は、基本的に、各種のレコード形式が格納され ている単一のデータベース・ファイルの使用に関係する。レコードは固定長で、 固定長の比較的短いキーフィールドを有する。データは、典型的には、データの 間に存在する関係に関して格納される。データ処理は、データベース内に格納さ れたレコードを使用して行ない、従来の概念的観点およびプログラムの使用とは 明らかに対照的である。従来の構成に固有の重大な欠点は緩和され、さらなる利 点を得ることができる。 データベース内に格納されたレコードは、本発明によれば、キーフィールドに 後続の固定長レコードの残りに対して、多くの独立したデータ構造を有する。１ つの特定レコード形式内部に別の構造が存在しても良い。つまり、レコードの機 能にしたがってこれらを考慮するのが便利である。以下は、機能的に独立したレ コード形式である： 関連性(relationship)レコード、単純データ・レコード、オプション・レコ ード、メニュー・レコード、代理(surrogate)レコード、およびトランザクショ ン・レコード。 機能的には独立しているものの、これらのレコード形式はすべて同一の固定長 であり、全て同じキーフィールド構造を有するので、全て共通データベース内に 格納できる。 前述したように、データは関連性において格納されるのが典型的で、これに対 応するレコードをここでは関連性レコードと称する。場合によっては独立したデ ータを格納することがあり、単純データ・レコードをこの目的で使用する。オプ ション・レコードは、データ処理の制御に使用されるレコードに付与した名称で ある。実行すべき別の操作の選択はいわゆるメニュー・レコードを用いて行なう 。いわゆる代理レコードは相互参照する情報の記録に使用する。トランザクショ ン・レコードは独立の監査記録(audit trail)追跡を実装するために使用する。 監査はシステムに格納されるユーザ・データの本質的な部分ではない。これらの レコード形式は、全て同一データベース内に格納され、全て同一の基本構造を有 する。異なるレコード形式の形成と使用については後述するが、最初に、共通レ コード・フォーマットについて、特にキーフィールドについて説明を行なう。 簡単に言うと、本発明の本実施例で使用しているレコード長は長さが１２８バ イトである。このうち２８バイトを使ってキーフィールドを形成する。キーフィ ールドは、それぞれが長さ４バイトである７つのフィールドで構成され、そ れぞれ４バイトのフィールドが４バイト整数として記録される９桁の数字から構 成されている考えられる。前述のように、キーフィールドは数字から構成される 。すなわち純粋に数値である。しかし、キーフィールドは、現実の計算使用の多 くでは、英字または英数字データの識別に必要となる。本発明の実施例において 、別々のルックアップ・テーブルを英字または英数字と数値の間の変換の少なく とも大部分に使用する。本発明の利点の多くは、キーフィールドの各種部分の特 定の構造と意義によるものである。 前述したルックアップ・テーブルは、単語ディレクトリと見なすことができる ので以下そのように称する。キーフィールド各部の構造と意味は、データが関連 性においてシステムに格納されることに関係がある。 本発明の実施は単語ディレクトリの作成から始めることにより達成される。単 語ディレクトリは、従来のコンピュータ・データベースに一般に使用される相当 多数の単語および固有名詞を、英語およびその他アラビア文字を用いる言語で入 力して作成した。それぞれの単語には数字を割り当て、数値は従来のデータベー ス内に単語に関連して格納した。数字の記録に８桁を使用するものと定めて、単 語の最大数を１０の８乗個に設定した。最初の入力単語に数字を割り当てる上で 、単語はアルファベット順に並べ、０から１０の８乗の範囲にわたってほぼ均等 に数字の広がりが選択された。 システムのこの後の開発と運用において、システムに入力されるそれぞれの単 語は、単語ディレクトリ内にまだ存在していない場合には、単語ディレクトリに 追加する。 それぞれの単語に関係した数値は、記録しようとするデータ項目のキーフィー ルドまたはインデックスの形成の際に使用する。 本発明の明確な特徴の１つは、ユーザには可変長であるように見える固定長キ ーフィールドの使用にある。それぞれが１２８バイト長の固定長レコードを有す るように本発明の実装を作成することに決定した。第１の２８バイトはレコード のキーフィールド（またはインデックス）を形成する。しかし、本発明は可変長 レコードを用いて実装することもできる。 固定長キーフィールドは本発明の本実施例において、 −数値の態様でキーフィールド内にデータを格納する −単語ディレクトリを使用する −情報へのデータ還元を適用してキーフィールドを形成する −使用するデータを判定してキーフィールドを形成する ことにより実現される。 これらの段階を取ることで、本発明の概念はさらに独自の特徴を実現すること ができる。 このような格納がどのように行なわれるかの具体的な詳細に戻って、添付の図 面のうち図１から図３を参照する。それぞれのレコードは長さが１２８バイトで 、レコードのキーフィールドは、第１の２８バイトを使用することが想起されよ う。キーフィールドは、実体形式、実体、属性を識別するデータを含む。実体形 式、実体、属性のそれぞれの実際の値は、独立した１２８バイトのレコードとし て記録される。レコードの２８バイトのキーフィールドは、記録しようとするデ ータの実体形式、実体、および属性の数値の連結を用いて形成する。それぞれの 数値は長さが４バイトで９桁からなる。各４バイトは２×１０の９乗の異なる値 を取ることができる（＋と−の値が許容される）。したがって実体形式を識別す るためそれぞれ９桁の４バイトの選択で（実体についてと属性についても同数） システムのあらゆる実現可能な使用については充分であろうことが分る。実体形 式、実体、属性のそれぞれの数値は単語ディレクトリを用いて取得する（単語デ ィレクトリは実際の関連レコードのキーフィールドを作成するために使用する） 。 キーフィールドでは、記録しようとする項目の英数字（自然言語）の記述の格 納に２２桁を割り当てる。記述は数値の態様で格納されるので、可変長データ項 目として見えるような固定長格納フィールドを実現している。図２および図３は この目的で使用する２２桁を示している。実施例においては、第１の５つの「単 語」であらゆる項目の英数字記述を記録するのに充分であろうと決定した。この 選択を行ない、２２桁をこれの格納のために割り当てたので、これら２つは次の ような方法でもたらされる： 記述の第１の５つの単語の重要度は順次減少する。単語ディレクトリ内で独自 に単語を定義するために８桁を使用していることを想起すれば、５つの単語のそ れぞれについて格納される桁数は次のようになる。 第１の単語 ８桁（すなわち完全に記録） 第２の単語 ５桁 第３の単語 ４桁 第４の単語 ３桁 第５の単語 ２桁 合計 ２２桁 すなわち、データ圧縮により、格納値は第１の単語だけをユニークに識別し、 単語ディレクトリ内で１つ以上の単語と第２から第５の単語の伸張した値と適合 する可能性は、順次増加する。しかし、データベース内に格納されたレコードの アルファベット順並べ替え等キーフィールドに基づいた機能では、システムの制 約として許容するに充分な正しい結果が得られることが多い。 システムは２×１０の６乗の実体形式と、それぞれの実体形式について２×１ ０の９乗の実体と、それぞれの実体について２×１０の９乗の属性を格納できる 。 それぞれのレコードのキーフィールドまたはインデックスは連結した数値から 形成したユニークな数に基づく。すなわち、 実体形式＋実体 ＋属性 ＋説明 ４バイト＋４バイト＋４バイト＋２２桁 本発明の特に顕著な態様の拡張は、実体形式と属性の記述の数値連結だけを考 えれば、ユニークな数が得られることの新規な認識による。 すなわち、実体形式の番号 ＋属性の説明の番号 ４バイト ＋４バイト の結果からユニークな番号が得られる。このユニークな番号が代理番号の目的と 内容を定義するが、代理番号自体は定義しない。代理番号については後述する。 添付の図面の図１から図４は、本発明の説明した実施例により形成したレコー ドの例を示している。図面において、長さがそれぞれ４バイトの各種レコード・ フィールドを示す。このようなフィールドが最大１２個図示してあり（図４ａお よび図４ｂ）、参照を容易にするため、フィールドにはＡからＬまでのラベルを 記してある。フィールドＡからＧはキーフィールド、すなわちレコードの第１の ２８バイトを構成する。フィールドＨからＬは関連性レコードでレコードの最後 の２０バイトである。他のレコード形式はキーフィールドの後のレコードの残り の部分で異なったデータ構造を有するのが普通である。それぞれのフィールド内 部で個々の数字の桁は順番に１から９とする。つまり、レコードの第１桁目はＡ １で、レコードの最後の桁はＬ９と称する。この命名法は、参照を容易にするこ とのためだけのもので、本発明の実施例に何らかの意味を付与するものではない 。 図１は、本発明の実施例による関連性レコードの１２８バイト・レコードが、 ２８バイトのキーフィールドと、１５バイトの共用データと、８５バイトのユー ザ・データとでどのように構成されるかを示す。 図２は、それぞれ長さ４バイトの７つのフィールドから、２８バイトのキーフ ィールドがどのように形成されるかを示す。第１のフィールドは実体形式番号を 含む。第２のフィールドはバージョン番号を含む。第３と第４のフィールドは実 体番号と属性番号をそれぞれ含む。フィールドＥ、Ｆ、Ｇは数値の形態で異なる データ形式を含む。それぞれが４バイトのフィールドは９桁で構成されている。 フィールドＡは単なる実体形式番号以上のことを含んでいる。特に桁Ａ１、Ａ ８、Ａ９は特別な意味を有する。 桁Ａ１は値「０」、「３」、「５」または「８」を取る。値「０」はそのレコ ードがデータを含むことを表わす。値「３」は、そのレコードがメニューを定義 することを表わす。しかし、メニューはデータの特殊な形態である。本発明の実 施例で用いている別のレコード形式はオプション・レコードである。オプション レコードはプロセス制御に使用する。オプション・レコードは、他のレコード、 たとえば、単純データ、メニュー・レコード、またはその他のオプション・レコ ードを制御できる。オプション・レコードの桁Ａ１の値を得るには、「５」をデ ータまたはメニューを表わす値に加算する。つまり、桁Ａ１の値「８」はメ ニュー処理を制御するためのオプション・レコードを表わす。 フィールドＡがデータの他に実体形式番号を含むことはすでに述べた。詳しく は、実体形式番号は桁Ａ２からＡ７までの６桁だけを含む。桁Ａ８は、値「０」 または「９」を取ることができる。値「０」は実体識別子を表わし、値「９」は 実体形式内の属性の記述および／または属性値、すなわち部分実体を表わす。 桁Ａ９は、フィールドＥ、Ｆの識別子の形式、およびＧの第１の部分を表わす ために使用する。桁Ａ９は、値として、「０」、「１」、「２」、「３」、「４ 」、「５」、「６」、「７」および「８」のいずれかを取ることができる。それ ぞれの値の意味は次の通りである： ０−名前 ５−パラグラフ・ヘッドを １−数 持たないテキスト ２−日付 ６−使用せず ３−同義語 ７−非圧縮の８チャネル識別 ４−パラグラフ・ヘッドを ８−非圧縮の１０チャネル識別 持つテキスト ９−使用せず 値「０」は実体形式識別子、すなわち初期メニューおよび実体レコードを表わ す。この値は第２レベルのメニューまたは実体レコードには使用しない。 フィールドＢに格納されたバージョン番号は、特に、データが公開または非公 開のどちらかの指示を含む。ここの設定にしたがって、別のオペレータは、たと えば１つのレコードの「同じフィールド」から別の値を取り出すことができる。 これはまた、多国語のアプリケーションにも使用される、すなわち同じデータが 別の言語で格納される。 前述のように、フィールドＢはレコードのバージョン番号を記録する。フィー ルドＢに格納されている値（９桁全部が集合的に通常の１０進数を表わすものと 考えて）が００００１００００以下の場合、レコード全体の内容は公開アクセス に開かれている。フィールドＢの値が００００１００００より大きいかまたは等 しい場合、レコード全体の内容はフィールドＢに格納された値で識別されるユー ザ・グループのメンバに制限される。つまり、あるレコードの９９，９９９バー ジョンは、異なるユーザ・グループによるアクセスのために格納できる。 非公開データの概念は各種の方法で使用できる。これは格納されたユーザ・デ ータが複数の（ただし可変数の）固定長レコードから構成されており、ユーザ・ レコードが可変長に見えるユーザの視点で考えた場合に、特に利点となる。フィ ールドＢの内容は、非公開クレジット制御情報をそのレコードが含むことを表わ すように設定できる。適当なユーザ・グループのメンバーである（および適切な セキュリティ・レベル権限を有する）人だけが、そのレコードに含まれたデータ にアクセスできる。公開と非公開データの間の区別は、規則と手順の格納、すな わち従来のプログラムの等価物に関連して使用することもできる。これは、その レコード内のデータの一部が公開であり、データの一部は非公開アクセスだけで ある場合に重要である。フィールドＢの使用の例として、商業的に用意され該シ ステムで使用するための「アプリケーション・プログラム」に対して、公開デー タを表わすようにフィールドＢの内容を設定することがある。アプリケーション ・プログラムを補強するためにユーザが用意した何らかの拡張は、非公開データ として格納される。このようにして、アプリケーション・プログラムの後のリリ ースは、アプリケーション・プログラムの公開データであるとフラグを立てた部 分だけを上書きするようにして、安全に実装することができる。ユーザが定めた 拡張は、従来システムの通常の結果と同様に、更新プロセスで上書きされない。 非公開と公開のデータの間を区別するフィールドＢの可能な使用法のさらに別の 例は、レコード内に格納された「非公開」ヘルプ・テキストを識別するように区 別を使用することである。つまり、特定ユーザまたはユーザ・グループ向けのヘ ルプ・システムを非常に容易に実装できる。 フィールドＣとＤは、前述のように、それぞれ実体番号と属性記述番号を含む 。代理はレコード番号の１形式である。代理レコードでは、フィールドＣの値は 常に０で、図４Ｂに図示したレコードの場合がこれに相当する。実体形式番号と 属性番号の連結がユニークな番号を提供するとの認識からこの実施が行われてい る。このユニークな番号は、後述するようなデータベース内を航行するための代 理番号とともに使用する。 全てのレコードが単一のファイル内に格納されるが、キーフィールドは、ファ イル内のデータの異なるテーブルと共に、ユニークなレコードも当然識別すると 考えることができる。この意味で、フィールドＡ、Ｂ、Ｃ、Ｄは特定のテーブル を識別すると見なすことができ、またフィールドＥ、Ｆ、Ｇはテーブル内のレコ ードを識別すると考えられる。実際に、フィールドＥ、ＦおよびＧで構成されて いるレコード識別子は、実はレコード識別子の一部分である桁Ａ９でプレフィッ クスされている。 図３は、フィールドＥ、Ｆと、フィールドＧの最初の４桁を合わせて、ある種 の英数字情報のデータ圧縮により形成された２２桁をどのように格納して用いる かを示している。桁Ｇ５は、重複を区別できるようにするための接尾辞として用 いる。桁Ｇ６、Ｇ７、Ｇ８は第２の接尾辞として用いる。このレコード接尾辞に より、同じ関連性形式の同じレコードの間の複数の関連性の簡単な格納ができる ようになる。桁Ｇ９は、値「９」に設定される初期設定値に設定するのが普通で ある。桁Ａ９が値「０」を有する場合、フィールドＥ、Ｆ、Ｇ（最初の４桁）は 、圧縮名称または重複が許容される１８桁の非圧縮番号、または重複が許容され ない２２桁の番号を含むことができる。これらの異なる可能性はオプション・レ コードで記述される。桁Ａ９が値「１」を有する場合、フィールドＥ、Ｆ、Ｇ（ 最初の４桁）はＥに９桁の番号、または前述のように１８桁または２２桁の番号 を格納することができる。つまり、（ユーザの観点から）レコードが番号で識別 される場合、Ａ９が「０」に設定されているレコードは、フィールドＥ、Ｆ、Ｇ に圧縮名称が含まれている。Ａ９が「１」に設定されているレコードは番号（１ ８、１９、または２２桁）を含む。レコードが９桁の番号と１８桁の番号の両方 で識別される場合、桁Ａ９は「０」に設定され、フィールドＥ、Ｆ、Ｇ（最初の 部分）は１８桁を含む。 フィールドＥ、Ｆと、Ｇの最初の４桁だけは、レコードのＩＤが「名称」すな わち桁Ａ９が値「０」の場合、前述した圧縮英数字データ２２桁を含む。 オプション・レコードのフィールドＥは常にゼロである。 フィールドＥと同様に、フィールドＦの内容は桁Ａ９で制御されるレコード形 式に依存する。桁Ａ９が「０」の場合、フィールドＥ、Ｆは圧縮名称の２２桁の うちの第１の１８桁を含む。桁Ａ９が値「１」の場合、そのレコードの作成日が フィールドＥに記録されており、そのレコードの作成時間がフィールドＦに記録 される。桁Ａ９の値が「７」の場合、非圧縮８文字ＩＤのうち、フィールドＥは 最初の４文字、またフィールドＦは２番目の４文字を記録する。 特定のレコードが番号（桁Ａ９＝１）で識別される場合、フィールドＥと、Ｇ の最初の部分とに１８桁の名称が含まれていて、重複が許容されるか、または２ ２桁の名称が含まれない限り、フィールドＧの最初の４桁は「０」である。レコ ードが名称で識別される場合、フィールドＧの最初の４桁は２２桁の圧縮名称の 最後の４桁である。桁Ａ９が値「７」の場合、フィールドＧの最初の４桁はゼロ になる。桁Ａが値「８」の場合、フィールドＧの４バイトのうち最初の２バイト は非圧縮名称の最後の２バイトである。 ８文字の非圧縮名称と１０文字の非圧縮名称の間の相違は、８文字の使用では 重複の存在を許容しているが、１０文字の使用では重複の存在を禁止している点 である。しかし、重複関係は桁Ｇ６から桁Ｇ８を使って作成できる。本発明の説 明している実施例を実装するのに使用した特定の計算機（ＩＢＭ製ＡＳ４００） では、多数のオブジェクトが１０文字名称を用いて識別されている。 桁Ｇ５の値は通常は値「１」だが、非圧縮８文字ＩＤを使用した場合、すなわ ち桁Ａ９が値「７」を有するなら、接尾辞として使用して重複の存在を許容する ことができる。しかし、１０文字の非圧縮ＩＤを使用している場合、桁Ｇ５はフ ィールドの最初の２バイトの一部として使用され、非圧縮名称の最後の２バイト を格納する。 桁Ｇ６〜Ｇ８は、さらなる接尾辞として用いて、同じ２つのレコードの間で同 一形式の複数の関連性の格納ができるようにする。しかし、必要なら、桁Ｇ９を 第３の接尾辞として使用し、レコード内に余分なデータを格納できる。説明して いる実施例において、第３の接尾辞は使用されておらず、桁Ｇ９は初期設定値の 「９」に設定されている。 それぞれのレコードは、１つの属性の１回の反復、すなわち１つの属性値を含 み、これが幾つかのフィールドにまたがり、これが関連性でない場合には最大で ８５バイトが利用できる。これが関連性の場合には６５バイトが利用でき、これ に相互参照フィールドが加わる。桁Ｇ９は、１つの属性の１回の反復において記 録することのできるデータ量を拡張するために効率的に使用できる。桁Ｇ９に値 「９」を割り当てたレコード内に相互参照が記録されるので、対応するレコード 内で桁Ｇを値「８」に設定する必要はない。桁Ｇ５〜Ｇ８を使用して、８５バイ トの４倍プラス６５バイトを１つのレコードの１回の反復に使用できる。 本発明の説明している実施例のさらなる拡張では、レコードの「タグ」または 「オーバライド」として、Ｇ９に値「０」から「４」までを使用できる。これら の設定の詳細な潜在的用途については、本明細書で詳細に説明しない。 本発明の実施した実施例において、コア・プログラムは所定のキーフィールド について全てのレコードを読み取る、すなわち０から９までの範囲で桁Ｇ９の全 ての値の検索を含む。そのため、普通に１つだけしか存在しないとしても（Ｇ９ ＝「９」）、全てのレコードが一度に位置決めされる。これは処理時間を改善す る。 以下は基本的実体データのエントリの例である。電話番号の格納を考える。桁 Ａ９は値「０」に設定し、フィールドＥ、Ｆと、Ｇの第１の部分に記録される２ ２桁は「電話番号」を含み、接尾辞の部分と合わせて必要になれば重複が許容で きる。これは下位レベルではなく実体それ自体のエントリである。実体番号と属 性番号はどちらも０である。すなわち、フィールドＣおよびＤはどちらも０であ る。 関連性レコードでは、それぞれのレコードのユーザ・データ部分は、相互参照 として、全ての関連するレコードの、すなわち関連性が存在するデータを含むレ コードのキーフィールドの一部を格納する。関連レコードのキーの残りの部分は 、問題の相互参照を有するレコードがアクセスされるコンテキストから判定でき る。図４ａと図４ｂを参照する。相互参照データはフィールドＩ、Ｊ、Ｋおよび Ｌに記録される。フィールドＩは関連レコードのフィールドＡのコピーを含む。 フィールドＡ〜Ｇは常にキーフィールドで、フィールドＨ〜Ｌは相互参照を格 納するために使用するが、代理レコードの場合は別で、この場合、フィールドＨ は関連レコードの代理番号を含む。１つだけのレコードが記録される場合、たと えば関連性の格納の代わりに「身長」の実際の値が格納される場合、フィールド Ｈ〜Ｌはユーザ・データの格納に使用する。それ以外の場合、フィールドＨは問 題のレコードに直接関係する何らかのレコードの代理を含む。つまり、図４に図 示してある２つのレコードでは、フィールドＨの内容は同一である。実際に、両 方のレコードのフィールドＨに含まれる値は、実は２つのレコードの第１のもの の実体番号（すなわちフィールドＣの内容）である。 フィールドＩからＬの内容は、関連性の詳細を記録するかしないかに依存する 。格納しようとするデータが関連性を含まないが１つ以上のレコードを同時に格 納する場合、フィールドＩの内容は同時に書き込む他のレコードのフィールドＡ の内容と同一である。この状況では、フィールドＪ、ＫおよびＬの内容は他のレ コードのフィールドＪ、ＫおよびＬの内容とそれぞれ同一である。 フィールドＩ、Ｊ、ＫおよびＬは、レコードが代理レコードではなく、またそ のときに１つのレコードだけが記録されるのでなければ、相互参照を含む。後者 の場合、フィールドＩ〜Ｌはユーザ・データの一部を含む。代理レコードの場合 、関連性において、両方のレコードの代理番号が格納される。代理レコードのフ ィールドＪ〜Ｌは、第４のレコードが記録される場合の第４の書き込まれるレコ ードのキーフィールド（すなわちＥからＧ）の一部を含む。関連性レコード ＡＢＣ有限会社の電話番号の格納を考える。この情報を格納するためには、デ ィスクに３つのレコードが書き込まれる。これらのレコードとは、（１）代理レ コード，（２）電話番号のユーザ、（３）ユーザの電話番号、である。レコード ２とレコード３は実際は互いの逆である。 第１に代理レコードを書き込む。桁Ａ８の値は「９」に設定し、これでそのレ コードが代理レコードであることを識別する。実体番号はフィールドＣに書き込 まれ、属性番号はフィールドＤに書き込まれる。このように、キーフィールドが 構成できる。 フィールドＡの値は既知である。システム・レベルでは、ビジネスまたは電話 番号のどちらかを優先に（すなわちこれのもとに代理レコードが書き込まれる） 選択し、この選択はオプション・レコードで制御する。この場合、フィールドＡ の値は実体形式顧客を識別する。 フィールドＢはバージョン番号で、データが公開または非公開アクセスに利用 できるかどうか、また１つの言語または別の言語によるものかを単に記録してい る。 フィールドＣはゼロである。 フィールドＤは属性記述の圧縮形態を格納する、すなわち、音声用電話番号等 のメニュー選択にしたがう属性記述の代理を格納する。これは、フィールドＤの 内容が具体的には属性の代理番号である。 フィールドＥの内容は作成している関連性の代理番号である。 代理番号は次のように決定する。まず第１に、概念記録キーフィールドを用意 し、桁Ｅ１〜Ｅ９全てに値「９」を割り当てる。次に、データベース内にポイン タを位置付けするように試みる。後ろ向きに１つレコードを読み込んで、この実 体形式と属性の組み合せについての最後の代理レコードを特定する。フィールド Ｅの値に１を加え、直前の代理レコードがない場合には値は「１」となる。これ によってフィールドＥに新しい値ができる。これが、現在準備しているレコード を書き込む際に使用すべき代理番号となる。 フィールドＦの値は常にゼロである。 フィールドＧの内容は通常の実体レコードの場合と同一である。本発明の説明 している実施例の場合、代理レコードのフィールドＧの値は、重複代理を除くの で００００１００１９である。 フィールドＡ、Ｂ、Ｄの連結により提供される番号はユニークである。つまり 、フィールドＡ、Ｂ、ＤおよびＥの連結により提供される番号はユニークである 。特に重要なことは、代理番号はこれを適用するコンテキストにだけ関係するこ とである。フィールドＡ、ＢおよびＤの内容がそのコンテキストを定義する。つ まり、キーはフィールドＡ、Ｂ、Ｄおよび代理番号（フィールドＥ）から構成 される。つまり、本発明の実施例は９桁の代理番号により限定されない。 フィールドＨからＬは、代理により２つの関連レコードのいずれかまたは両方 のレコードが識別される場合、これらレコードの代理番号を含む。一般に、フィ ールドＨからＬは、３つではなく４つのレコードを同時に書き込もうとしない限 り、この目的で使用しない。大抵は３つのレコードだけが書き込まれる。しかし 、４つのレコードはさまざまな場合、たとえばメニューの準備のために書き込ま れる。この場合の４つのレコードは、代理レコード、属性値レコード、属性内の シーケンス番号、属性が現れるメニューの名称である。第２のレコードの書き込み（関連性の記録） 第２と第３のレコードとしてここで説明することは、何らかの重大な影響なし に事実上相互に入れ換えが可能である。 フィールドＡは実体形式番号（電話番号）を含む。 フィールドＢはバージョン番号を含む。 フィールドＣは実際の電話番号の代理である実体番号を含む。レコードの書き 込みに際して、代理が決定されて識別子として使用される。 フィールドＤは属性番号を含む。つまり、これは「音声用の電話番号」で属性 記述の代理である。 先の文章にしたがえば、記録処理はここで説明しているよりも複雑であること に注意すべきである。新規の実体または名称で識別される独立したデータについ ては、ワード・ディレクトリとの相互チェックおよびおそらくワード・ディレク トリへの新規レコードの書き込みが伴う。 フィールドＥ、ＦおよびＧの最初の半分は圧縮名称（すなわちＡＢＣ（有）） を格納するために使用する。フィールドＧの第２の半分は前述したように接尾辞 情報に使用する。 フィールドＨは代理番号で、代理レコードのフィールドＥの内容と同一である 。つまり、フィールドＨの値は全ての関連レコードで同一である（代理レコード だけは別で、そのレコード内に番号を２回記録する必要がない）。 フィールドＩは関連（すなわち第３の）レコードのフィールドＡと同じ値を有 する。すなわち、接頭辞と接尾辞のある実体番号である。 フィールドＥは桁Ｅ６からＥ９までが関連（すなわち第３）レコードの桁Ｇ６ からＧ９と等しく設定する。これは接尾辞である。つまり、何らかの重複が存在 するかを識別できる。この目的は重複が存在するときにキーを知ることである。 桁Ｅ２からＥ５は、ゼロ以外のとき、関連レコードのバージョン番号を含む。 これによって、関連レコードのフィールドＢの値が決定できる。これはグループ のユーザの番号である（実際に、ユーザ・グループの番号は通常フィールドＢの 実際の値である）。 桁Ｅ２からＥ５は全て値「０」を有することがあり、この場合、フィールドＢ の値はユーザ・グループ番号で、桁Ｅ２からＥ５のいずれかが０以外の値を有す る場合には、桁Ｅ２からＥ５は関連レコードのフィールドＢの値を含んでいる。 つまり、関連レコードの桁Ｂ６からＢ９はそれぞれ桁Ｅ２からＥ５に等しく、桁 Ｂ１からＢ５の値はゼロである。関連性の第３のレコード 第３のレコードは第２のレコードと同様に、ただし逆に書き込まれる。 第２と第３のレコードから分るように、代理レコードを識別できるが、相互参 照において、関連レコードの部分的なキーだけしか有していない。しかし、状況 によって、第２の（関連）レコードの完全なキーフィールドを決定することが可 能である。 これを実現するためには、第２のレコードのフィールドＥ、Ｆおよびフィール ドＧの最初の半分は、相互参照（第３レコードのフィールドＩからＬ）に記録さ れていないため、代理を使用することができない。 しかし、関連レコードの実体レコードを経由して失われた情報を含む第３レコ ード（またはもっと高いレベルの属性値代理）に到達またはこれを識別した。コ ア・プログラムのアレイは、実体レコードのフィールドＥ、ＦとフィールドＧの 第１の半分の内容を記録している。コア・プログラムは９９レベルまでの完全な 履歴を保持している（これのデータ格納を使用する）。これによってシステム 内のバックトラキングが有効になる。９９レベル以上は１次格納ファイルを使用 することによって追跡できる。 フィールドＡからＧは２８バイト使用する。ユーザ・データには（関連性の格 納録について考えているように）さらに６５バイトを使用する。通常、共通デー タに１５バイトを割り当てる（これにはトランザクション番号を含む。ＡＳ４０ ０の相対レコード番号機能は使用しない）。フィールドＨの４バイトは代理番号 を含む。残りの１６バイトは相互参照情報を含み、フィールドＩからＬに記録さ れる。 説明した構成の利点は、ＡＢＣ有限会社が社名を変更した場合、第３レコード のキーは電話番号を変更しないことである。第２レコードは当然変更を行なう。 つまり、本発明のシステムは下位レベルを全て消去して関連データを全て再入 力する必要があるようなシステムとは対照的に、多レベルのデータ記録を提供す る。本発明において、すでに有効でない下位レベルを簡単に「移動」することが 可能であり、これ以後の全てのレベルも、代理番号が変化しないので、「自動的 に」移動する。属性値は１つの実体形式および属性記述から別のものへ移動する 。対照的に、すでに有効ではない下位レベルを「移動」するのではなく書き直す べきであれば、代理番号は変化する。 先行のパラグラフで説明した構成は、実体形式番号、属性番号、およびバージ ョン番号の連結から形成した値全体を変更する場合、このユニークな番号によっ て使用される代理番号がすでに発行されていることがあるので、機能しない。 本発明により実現された性能上の利点は、何時でも一度にシステムが極めてわ ずかなレコードを読むだけで良いことである。ユーザの生産性に対してこれは非 常に有益である。全体として、システムは簡単で少ない段階しか使用しない−− 実行すべき処理段回数が、ユーザに注意力を失わせるに足るほど長い時間かかる ことのある、従来のほとんどのシステムとは対照的である。仮想システム・コン ピュータ・ハードウェアにおいて、本発明は非常にわずかなページングしか使用 しない。オプション・レコード 本発明においてはデータとともに格納されている、従来はコンピュタ・プログ ラム内にコード化されていた、規則および手順を参照する。これは、キーフィー ルド内の４バイトの実体形式番号を空白のままにしたレコードを用いて都合よく 実現した。参照を容易にするため、このようなレコードをオプション・レコード と称する。オプション・レコードは、データ取り出し径路を定常化するために使 用できる。つまり、オプション・レコードの内容を用いて、特定の入力に応じて どのレコードがアクセスされるかを決定できる。これはシステム内の「相対的」 セキュリティの実装に使用できる。ターム「相対的」は、セキュリティの何らか の妥協の可能性を意味するものではなく、むしろ逆である。相対的セキュリティ は、従来のシステムではしばしば所望されているが滅多に実現されない。これは 、システムの単一のユーザに異なるレベルのセキュリティを、特に動的に割り当 てる能力である。セキュリティ・レベルは使用するアプリケーションによって変 化することがある。当然オプション・レコード内の１桁を割り当てることで何ら かの特定の機能に対して１０レベルのセキュリティを割り当てることができる。 多数の異なる機能に対してセキュリティを制御するために多数のセキュリティ・ コードが格納される。 オプション・レコードは、特定のテーブルで使用する有効なレコード識別子を 定義するために使用する。オプション・レコードは、データが表示される方法の 決定に使用される。オプションレコードは代理番号の割り当て制御に使用される 。オプション・レコードは後続のレコード間に適用されるインターバル番号の制 御に使用される。つまり、代理レコードのインターバルは「１」に設定され、パ ラグラフのヘッダのまたはテキストの短い名前のインターバルは「１００００」 に設定される。 テキストは、代理により識別されてからパラグラフのヘッダ・シーケンス番号 または文書内のパラグラフ番号で識別され、さらに、第１の５単語で識別される 。テキストは関数ではなくレコード形式（構造）である。テキストは初期入力に おいて割り当てられた代理番号により識別されるシーケンス内に格納される。そ の結果、シーケンス番号または単語のどちらかを変更しつつテキストの独自の 識別を保持することができる。 テキストはデータベース内に統合され別個に処理されないことは注意すべきで ある。 参照番号はバッチ処理の優先順位を設定するために使用できる。 これらの機能の形式は全てオプション・レコードで制御される。オプション・レコードのキーフィールド 実体形式、実体、属性には初期設定値(default)を設定できる。この目的は必 要なオプションレコードの個数を減少することである。しかし、アドレスのため のオプション・レコードは、実体形式に初期設定値を設定するが属性は特異的で ある。 メニュー・レコードを用いて、どの初期値およびどのオプション・レコードを 使用すべきか指定する。 桁Ａ１の値に「５」を加えて、オプション・レコードがデータに関するものか メニューに関するものかを識別する。 桁Ａ２からＡ７は実体形式番号を格納するが、初期設定はゼロである。 桁Ａ８は、本発明の説明している実施例では使用せず、「０」または「９」の どちらかに設定する。これは使用するデータ・レコード内と常に同一である。 桁Ａ９は値「１」に設定するが、これはレコードがオプション番号で識別され るためである。 フィールドＢはバージョン番号を含む。これはゼロのことがあり、オプション ・レコードで決定される。一般的機能だが、別のユーザには別の規則をコード化 することができる（たとえばスプレッドシートの単一「セル」内で）ため、非公 開と公開データの間の識別はオプション・レコードで特に有用である。この機能 はオプション・レコードのユーザ・バージョンの識別にも使用でき、見つけた場 合にはユーザ・バージョンでこれの公開バージョンをオーバライドできる。 フィールドＣは実体番号を含み、オプション・レコードでは通常ゼロである。 フィールドＤは属性番号を含む。オプション・レコードでは、フィールドＤの 値はテーブルに特殊な特性が要求されない限りゼロで、そのような場合には特定 の属性と関連するのが普通である。たとえば、アドレスのオプション・レコード 内で郵便番号により識別されるアドレスがこれに相当する。 フィールドＥ、Ｆは値がどちらもゼロである。 フィールドＧはオプション・レコードの番号を含み、桁Ｇ１からＧ５を使用す る。本発明の説明している実施例において、オプション・レコードの重複は許容 されないので、桁Ｇ６からＧ８はそれぞれが値「００１」を割り当てられる。桁 Ｇ９には値「９」を割り当てる。 オプション・レコードは相互参照フィールドを含まない。つまり、ユーザ・デ ータの格納に８５ビットが利用できる。これは、第２のレコードを書き込み、桁 Ｇ９を「９」ではなく「８」に設定することで、１７０バイトに拡張できる。つ まり、データベース全体を再構築する必要なしに大幅な変更を行なうことができ るような１つの例である。 オプション・レコードは特定のアプリケーションと関連することができる。こ のような使用では、アプリケーション番号はキーフィールドの一部として、便宜 的にフィールドＣに格納される。 オプション・レコードはオプション・レコードを適用するテーブルへのアクセ スを制御するフィルタと見なすことができる。オプション・レコードの使用 オプション・レコードはアクセスを閲覧だけ、すなわち、編集を除外するよう に制限するために使用できる。安全なアクセスのために、アドレスの変更を実装 する必要がある場合、別のオプション・レコードを提供してこの機能を有効にす る。 オプション・レコードは終了プログラムの識別に使用できる。さらに、オプシ ョン・レコードを使用して、本発明のシステムを使用して、記録されていないデ ータ・ファイルの本発明のシステムによる読み込みを、終了プログラムを使用し て制御することができる。 オプション・レコードは、ユーザのセキュリティ・レベルに動的変化を実施す るために使用することがある。 それぞれのレコードの共通データ領域内に、レコード識別子として３文字を割 り当てる。これら３文字のそれぞれには、ＡからＮまでの文字または「０」から 「９」までまたは何らかの特殊文字を割り当てることができる。つまり、許容可 能な識別子の総数は４０の３乗である。しかし、識別子はレコードの特定の構造 たとえば名称に関連するので、これは識別子の総数を６４，０００種類に制限す るものではない。これらはレコード形式、すなわち属性値の形式である。先頭の 実体における識別子の総数は６４，０００である。同様に、先頭の属性以下で可 能なエントリの総数は６４，０００で、そのそれぞれが１０億まで繰り返し可能 である。 オプション・レコードは、新規レコードを追加した時に３文字のレコード形式 コードを定義する。 一般に、エントリ・テーブルを取り出す。すなわち、オプション・レコードで 定義されているように、同じレコード形式を有するものだけではなく、（セキュ リティの対象となる）全てのレコードを受信する。 データベース内の単一のテーブルについて、多数のオプション・レコードが存 在できる。すなわち、別のレコード形式が単一テーブル内に許容できる。 オプション・レコード内では、１バイトが存在し、この１バイトは、そのオプ ション・レコードを使用してデータベースに追加されるレコード内に記録された 名称の長さを制御する。従来は、２４文字の長さの名称ではなく２５文字の長さ の名称を変更する、または許容する上で、非常に大きなオーバヘッドがあったが 、本発明ではデータをディスクへ書き込むときに別のオプション・レコードを使 用するだけである。名称の長さは書き込まれるレコードの共用データ領域の一部 である。 オプション・レコードは実行制御の実施にも使用できる。この点で、オプショ ン・レコードはトランザクションの境界を設定するために使用できる。より特定 すれば、１つのオプション・レコードは実行制御の開始シーケンスを記録し、別 のオプション・レコードが実行制御プロセスの完了を制御できる。従来の構成で は、挿入点のどちらかの側で手順段階の結果に注意を払わなければ、実行制御手 順に余分な段階を挿入することは不可能である。このような結果への配慮は本発 明の構成を用いると回避できる。 オプション・レコードは、同時に取り出そうとするレコード数の制御に使用す る。オプション・レコード内の１文字をこの目的で使用し、結果的に表示される レコード数は０から９までの範囲で、０を低い方ではなく高い方にして、制御で きる。 オプション・レコードは、パラグラフの見出しとパラグラフのテキストの制御 に使用できる。つまり、長い名称または短い名称（あらゆる長さまたは２５６文 字）の表示に使用できる。 オプション・レコードは、長い名称が存在するかどうかを定義するために使用 可能である。 一般的に言うと、表示画面上の１行は１レコードに等しい。この構成では、長 い名称はレコード当たり１行で、名称は長さ１０，０００行になり得る。 オプション・レコードは、処理の制御、たとえば要求された情報へのアクセス が拒否された場合に、ユーザへメッセージを表示するために使用できる。同様に 、オプション・レコードは、処理の流れの制御、たとえばユーザをメニューまた は主関連実体レコードに復帰させるために使用できる。 オプション・レコードで実現し得る処理制御は極めて柔軟である。たとえば、 電話番号の入力時にその電話番号の所有者を識別して処理をメニューに切り替え 、その所有者の他の属性を検査のために選択できるようなオプション・レコード の実現も非常に簡単である。 オプション・レコードは、別のテーブルをアクセスするために使用する次のオ プション・レコードの個数を含むことができる。 メニュー・レコードもオプション・レコード数を含む。この数を使用するオプ ション・レコードの数に加えると、処理に使用する実際の数が得られる。 トランザクション処理はブール代数論理の実装に使用できる。たとえば、５つ のエントリを含むテーブルを考える。表示制御文字が値「１」に設定された場合 、処理は１つのレコードを検索する。トランザクション処理を制御するオプショ ン・レコードは、レコードが見つかった場合または見つからなかった場合に取る べき動作を規定する。つまり、オプション・レコードはデータベース内のデ シジョン・メーカとして設定できる。 一例として、注文システム内の価格の更新を考える。時刻によって変化する価 格を実現したいとする。これは日付と時刻がスタンプしてあるキーフィールドを 用いて、すなわちフィールドＥを日付にまたフィールドＦを時刻に設定すること で実現できる。日付の９桁目は、日付が正しく格納されたかのチェックのために 使用する。フィールドＦの最初の桁は、時刻の記録の正確さのチェックのために 使用する。オプション・レコードは、現在の日付および時刻と比較して有効なキ ーフィールドを有するレコードが特定できるまで、テーブルを後ろ向きに読み込 むように設定される。このシステムを使用すると、新しい価格を入力した時、価 格の有効期限を簡単に実現できる。つまり、事実上時間的に後ろ向きに読み込ん で、トランザクションの日付以前のもっとも新しい日付と時刻に記録された価格 を検索する。これは１つの日付から別の日付までの価格に有効な日付範囲を設定 するのが通常である従来のシステムとは対照的である。このようなシステムでの 問題点は、トランザクションの日付がデータベース内に記録された価格の日付範 囲外にある場合に、どのような処理を適用するかである。しかし、本発明による 実施例において、新しい価格が入力されるとすぐに価格は冗長かつ無効になるの で、有効期限の日付をコード化することが必要である。これら後の全てのトラン ザクションはすぐに新しい価格で行なわれる。同様に、割引、市場セクタ等を「 コード化」することができる。 この「処理」の全てがデータベース自身内にコード化され、データベース自身 で行なわれることは重要である。従来の意味では、「プログラム」に処理が格納 されたり、「プログラム」により制御されない。新しい割引をたとえば何に適用 するかを指定するように、データベース内に剰余レコードを書き込めば良い。こ れは重複データベースを設定する（新しい価格をコード化する）ことが通常必要 とされ、価格の変更を適用するために複製を原本に置き換える時間まで、２つの コピーの間でデータベース相互の一貫性を維持するのが困難な従来システムの大 きな欠点の１つを回避する。 オプション・レコードは、エラー・トラッピングと同様の方法で、処理を制御 するために使用する。つまり、ユーザの問い合せに対して１つもレコードがみつ からないまたは１つ以上のレコードがみつかった場合、システムの応答がオプシ ョン・レコードで制御される。さらなる処理もオプション・レコードにより制御 できる。たとえば、問い合せに応答して、選択されたデータ項目が取り出されな い場合、オプション・レコードにより、そのデータをデータベースに実際に追加 する選択肢をユーザに対して提示することができる。同様に、オプション・レコ ードにより、要求されたデータ項目が取り出されたときに、次の処理段階へ自動 的に進むまたは進まない様に設定できる。たとえば、アドレスを入力した場合、 システム内で実際にそのアドレスが位置付けられていることをユーザに通知する ことの利益はほとんどない。次の処理段階に進み、関連する名前を取り出し、チ ェックのためにユーザにその名前を提示する方がさらに有益であろう。実際に、 オプション・レコードをメニューとともに使用する概念は手順の作成の概念につ ながる。手順は多数の順次処理段階を実行し、それぞれの段階の個別に満たされ る条件に依存する。これは、それぞれの間で自動進行を有する「１エントリ」メ ニューの形態と考えられる。 共通データ領域フォーマットは他のレコードと同様である。 前述したように、オプションレコード内で１桁の数が表示またはアクセスしよ うとするレコード数を制御する。この桁が値「１」を有する場合、オプション・ レコードは自動進行を指定し、オプション・レコードが手順となったことになる 。 手順はデータ入力を促すために使用できる。たとえば、一度の１つのレコード にアクセスするメニューを使用している場合、オプション・レコードを使用して 特定のレコードの存在をチェックし、これが見出せない場合には値を入力するよ うに促す。 初期設定のオプション・レコードは、実体形式、実体、属性に関連するフィー ルドのそれぞれの値がゼロに設定してある。しかし、別の初期設定レベルを実現 することが可能で、この場合、これらのフィールド内の値は全てゼロではなくな ることがある。たとえば、属性を空白のままにしない場合、属性番号はゼロでは なくなる。 フィールドＬはオプション・レコード番号を含む。メニュー 本発明によりデータベース内のレコードにアクセスするには、実体形式番号と 属性番号を指定する必要がある。実際に行なわれる処理はオプション・レコード の使用が多く関係し、メニュー・レコードによりアクセスされるオプションレコ ード番号の使用が含まれる。メニュー・レコードも、実体または属性レベルで初 期設定値として選択肢を取るべきかを示すためにコード化してもよい。オプショ ン・レコードの桁Ａ１は値「５」以上を有する。つまり、オプション・レコード を形成するにはオプション・レコードでアクセスまたは制御するレコードの形式 の桁Ａ１の値に「５」を加える。レコード形式コード、上記で参照した３文字の レコード形式コードは文字「Ｆ」から始まる。この３文字のレコード形式コード は、データベース内のそれぞれのレコード内の共通データの一部である。文字「 Ｆ」はコードの最初の文字としてどのデータ構造を使用すべきかを表わす。 フィールドＣの値は、アプリケーション関連メニュー・レコードのアプリケー ション番号となる。フィールドＣの値は、アプリケーションと無関係のメニュー でゼロとなる。対応するオプション・レコードはメニュー・レコードがどの形式 であるべきかを決定する。 メニュー・レコードは値「２」または「３」を有する桁Ａ１で識別する。値「 ２」はそのメニュー・レコードが現在位置への径路を制御するためのものである ことを表わし、値「３」はレコードの選択または発見の後の径路を制御するため のものであることを表わす。 メニュー・レコードのキーフィールドは、他のレコード形式で一般に前述した のと同じように構成するが、桁Ａ１の値は別である。たとえば、メニューの名前 を実体形式としてコード化する。 メニュー・レコードの共通データ領域は通常のレコード形式と同じフォーマッ トを有する。 レコードの共通データ領域に配置された３文字のレコード形式コードは、第１ の文字が終了プログラム名の一部であるようなフォーマットを有する。たとえば 、終了プログラムに関連して、３文字のレコード形式コードの第１の文字はプ ログラム名の第４の文字と同一である。この命名法を用いると、全ての終了プロ グラムは、第１の文字がＥ（Ｅｒｒｏｓ−−本発明のシステムにつけた名称−− を表わす）で、２文字のバージョン番号が続く名前を有する。つまり、別のレコ ード・データ構造を追加したい場合、コア・プログラムの本体を変更する必要は なく、終了プログラムを単に追加するか既存のプログラムを組み込むだけである 。トランザクションのサマリー トランザクション・レコードはそれぞれのトランザクションに対して書き込ま れる。トランザクション・レコードは実体形式番号がゼロに設定される。桁Ａ１ は値「０」となるが、これはデータ・レコードであるためである。桁Ａ８は「０ 」である。桁Ａ９は、これが番号であるので値「１」となる。 トランザクション番号は、フィールドＤの全ての桁を値「９」に設定してから 、最後のトランザクション番号がみつかるまで後ろ向きに読み込むことで生成す る。値「１」を最後のトランザクション番号に追加して新しいトランザクション 番号を形成する。この処理は代理番号の生成に関して前述したのと同様である。 典型的には、トランザクション・レコードは詳細を格納する。たとえば：ユー ザ番号、会社、部門、日付と時刻、アプリケーション番号等。トランザクション ・サマリーの使用により「やり直し(undo)」機能の実装が簡単にできる。航行(Navigation)および閲覧(Browse)機能 実体形式、実体、属性の間を移動してデータベース内を閲覧または航行するこ とができる。キーフィールドを使用し、特に属性のフィールドＩからＬにより、 実体形式と識別子を識別できる。フィールドＩに格納された値は実体形式を識別 する。すなわち、関連レコードで桁Ａ８が「８」に設定してある場合を除いて、 属性の相互参照フィールドに値「９」を有することと比較して、関連レコードの フィールドＡの値を識別する。関連レコードのバージョン番号は桁Ｉ２からＩ５ の検査で決定できる。これらの桁が全て値「０」の場合には、関連レコードの フィールドＢはユーザ番号を有する。しかし、桁Ｅ２からＥ５が全てゼロではな い場合には、関連レコードの桁Ｂ１からＢ５はゼロで、桁Ｂ６からＢ９はそれぞ れ桁Ｅ２からＥ５の値を有する。 このように、関連レコードのフィールドＡとＢの値が求められる。 関連レコードの実体番号と属性番号、すなわちフィールドＣとＤの値はゼロで ある。これはデータ・ツリーの開始点（または頂点）を考えているためである。 一般に、フィールドＥとＦの値は、属性レコードと関連レコードの間で不偏で ある。しかし、フィールドＪの最後の４桁が関連レコードのフィールドＧの最後 の４桁の値を示す。これも通常は変更なしを表わす。 このように、関連レコードのキーフィールド全体はコンテキストから構成され ている。さらに、関連レコードのキーフィールドを構成するこの処理は前向きま たは後ろ向きどちらかの方向に使用できる。 属性を用いるだけで非常に簡単に実現できる。たとえば、全てのメッセージを 単にリストするだけの「メッセージ」と、注目している特定のユーザへ送ったメ ッセージだけをリストする「受信したメッセージ」の間の差を考える。コンテキスト 特定のコンテキスト、つまり特定の問い合せの結果としてだけ、データにアク セスできる。このように、特定レコードの内容をみる場合、そのレコードに格納 された情報のコンテキストは既知である。さらに、情報はコンテキストから外へ は出ない。アプリケーション構造 アプリケーションはデータベース全体に対するフィルタと見なすことができる 。たとえば、データベースのサブセットを送り状処理に割り当てたいとする。ア プリケーションは送り状処理に関連するレコード、手順等へのアクセスができる 。 アプリケーションは実体形式である。添付の図面の図５ａと図５ｂの意味ネッ トワークに図示してある。 メニューは、アプリケーション内のそれぞれの実体形式に関して利用できる属 性をフィルタする。このように、属性は１回記録するだけで良い。 全ての属性にアクセスしたい場合、アプリケーション非依存メニュー（すなわ ちフィルタなし）を使用する。これはアプリケーション・プログラム内に必要な 属性を「コーディング」する従来の方法とは対照的である。全体の概念は「コー ド化プログラム」とは異なる処理を行い、処理は実際のデータの格納の一部にな る。 アプリケーションの例を添付の図面の図６に示した意味ネットワークで図示し た。アプリケーションは、実体形式「アプリケーション」が利用できる「セキュ リティ」(security)である。実体形式の属性は「に許可される」（authorised t o）である。これもそれぞれのアプリケーション内にセキュリティがコード化さ れる従来の構成とは対照的である。 オペレータはアクセスできるアプリケーションだけを使用できるが、これはオ ペレータがユーザとして適当な属性を有するため、すなわちデータと規則が基本 的に同一と見なされることによる。つまり、ユーザはデータ間を航行するのと同 じ方法で規則間を航行する。 システム内ではスタートアップ・アプリケーションも利用できる。このアプリ ケーションは、コア・プログラムを変更せずにスタートマップ手順を変更するこ とができるものである。「許可アプリケーション」(application authorized)属 性が実行可能なアプリケーションをリストする。アプリケーションをリストした 後、データベースの航行を開始する。 この技術を用いると、入れ子構造にしたアプリケーションを簡単に実装でき、 セキュリティ・チェックをそれぞれのレベルに含めることができる。 同様に、新しい文書作成アプリケーションをコード化することが可能である。 このようなアプリケーションは著者名等のデータを要求する手順を含むことがで きる。ファイル １つだけのファイル（またはデータベース）が必要である。それぞれのレコー ドのキーフィールドはユニークであるから、１つ以上のファイルを作成する必要 がない。しかし、運用上の理由から、データベースを幾つかの別のファイルに分 割することが望ましいこともある。たとえば、ユーザ・データを公開データから 分離するためにこのような分割を行ないたいことがある。同様に、アプリケーシ ョン定義データをアプリケーションが適用されるデータから分離するために、こ のような分離を行ないたいことがある。このように、分散のために、アプリケー ションが適用されるユーザ・データを上書きすることなく、アプリケーションを 変更することができる。したがって、第三者の「ソフトウェア」は従来のシステ ムと直接類似した方法で本発明のシステムを用いて実装可能である。 １つ以上のファイルを作成することが望ましいような状況の別の組み合せはデ ータの破棄またはアーカイブを行ないたい場合である。これはデータがメッセー ジまたは文書を含む場合に特に適用し得る。 １つ以上のファイルを作成することが望ましいような他の例は、ユーザ・デー タが特定の分野または形式に関する、たとえば美術品に関するデータベースの場 合である。 １つ以上のファイルを作成することが望ましいようなさらに別の例は、設定デ ータを格納しようとする場合で、たとえばコンピュータ端末のリストと、これら の端末からコンピュータにアクセスできるオペレータのリストについて等である 。 本明細書で説明した本発明の実施例において、全体で７つの別のファイルを使 用した。これらのファイルは： （１）単語ディレクトリ （２）ユーザ・データ （３）非公開データ （４）公開アプリケーション・データ（例えば国名のリスト等） （５）公開アプリケーション・データ；汎用ではなく特定（技術史） （６）アプリケーション定義（類義語辞典（シソーラス）を含む） （７）構成（コンフィギュレーション）ファイル （８）メッセージ・テキスト・ファイル （９）トランザクション・サマリー システムの他の唯一の部分はコア・プログラムで、これは１ＭＢ以下の命令を 含む。類義語辞典 （シソーラス：thesaurus） 類義語辞典の重要な特徴は、単語ディレクトリ・ファイルから区別されている ことである。類義語辞典は主データベースの一部をなし、「類義語辞典」が実体 形式である。類義語辞典は（何らかの言語の）文章を含むが、単語ディレクトリ は、これと対照的に、独立した単語だけを含む。データベースのアプリケーショ ン構造を定義するために、使用される全ての術語を類義語辞典に最初に入力して おく必要がある。この処理の一部として、代理番号が割り当てられる。 システム全体で識別子として使用される全ての単語は、単語ディレクトリに含 める必要がある。しかし、単語ディレクトリ全体を類義語辞典が必ずしも含まな くても良い。 類義語辞典は用語の集中リポジトリである。データベース構造を定義するのに 必要な全ての用語が類義語辞典に含まれる必要がある。つまり、新しい実体形式 を追加するには、その実体形式の名前を類義語辞典に入れることが最初に必要で ある。これが添付の図面の図７に図示した意味ネットワークで図示してある。 次に、特定の名前が実体形式かを調べるために類義語辞典にアクセスできる。 類義語辞典は標準的な単語と分節の使用を強制する。すなわち、桁Ｇ５は重複 を許容するが、それぞれが別の代理番号を有することになる。 単語ディレクトリと類義語辞典の間の対比の一例としては、単語ディレクトリ は単語「赤」を１回だけ記録する。類義語辞典は単語「赤」を数回記録すること がある。たとえば第１の項目は色として、第２の例は政治に関連して等である。 したがって、類義語辞典を調べて、単語「赤」の考えられる意味のリストを取り 出すことができる。 類義語辞典により、単語「赤」に関して、システム内に存在する他の知識を見 つけ出すことができる。 類義語辞典は全てのトランザクション処理では使用されない。たとえば、属性 記述「である」(in a)を考えてみる。フレーズ「である」は類義語辞典から取り 出せるが、データベース内の航行は、すぐである。それは、処理がその最初の類 義語辞典参照から実体形式を介して実体へとなるからである。表現「類義語辞典 」は実体形式で、「実体形式」は類義語辞典に含まれている。マルチ・ユーザ・グループ １つのシステム上で、マルチ・ユーザ・グループに対応することが可能である 。個人ユーザ・データのために別のファイルを作成して、新規ユーザ・グループ を簡単に追加できる。レコードの検索では、コア・プログラムは常にユーザ・グ ループ番号を参照する。 １つのユーザ・グループのメンバーは、別のユーザ・グループのメンバーにメ ッセージを送信できる。 キーフィールドの一部としてユーザ・グループ番号を使用すると、固有のセキ ュリティが実現される。別のユーザ・グループに属するデータ間の交差アクセス は実現されない。つまり、他のグループのデータへのアクセスを防止するのもそ の逆も非常に簡単である。これは関連レコードのキーフィールドの一部であるた めである。コア・プログラムの構造 （１）「要求処理」プログラム。動作インタフェース本体。 （２）データベースにアクセスするメイン・プログラム。全体の制御プログラ ム。これは他のプログラムを全て呼び出せる。 （３）「データベース更新」プログラム。オペレータにテキスト処理インタフ ェースも提供する。 （４）終了プログラム：ＥＲＲＯＳまたはユーザ定義のたとえば、maths/prin ting/の別画面表示。終了プログラム 終了プログラムは、一部はすでに触れたように、以下の命名法を便宜的に採用 している。終了プログラムの第１の文字は常に文字Ｅ（ＥＲＲＯＳ−−本発明の システムに関して使用する名称−−を表わす）である。第２の文字はプログラム のリリース番号を表わす。第３の文字はプログラムの修正を表わす。第４の文字 は、この終了プログラムにより処理するレコード形式の３文字レコード識別子の 第１の文字である。終了プログラムの第５の文字はプログラムのバージョン番号 を指定する。この文字は、ＡからＺまでの何らかの文字または０から９までの範 囲の何らかの数字または特殊文字を割り当てられる。終了プログラム名の第６か ら第１０までの文字はユーザ・グループ番号を表わす。これをゼロとして、あら ゆるユーザ・グループで利用可能なことを表わすことができる。 ユーザ独自のオプション・レコードは、どのバージョンのプログラムを使用す べきか、および特定のユーザ・グループについてそのオプション・レコードから 呼び出されるそのプログラムが自身のユーザー・グループか、または共有利用可 能なバージョンかを指定する。 この命名法によれば、同一プログラムの別のバージョンの混同を回避するのが 簡単にでき、全てのノードがそれぞれのユーザ・グループについて、プログラム のどのバージョンを使用するかを定義できる。これは、異なる画面描画等の簡単 な選択またはもっと難解な要求を組み込むことができる。 終了プログラムはプログラム・ライブラリに含めることができる。プログラム ・ライブラリにつける名前は、望ましくは以下の命名法を用いるべきである。ラ イブラリ名の第１の文字は文字Ｅである。第２の文字はリリース番号を表わす。 第３の文字は変更を表わす。第４の文字は変更レベルを表わす。この命名法はあ る種のコンピュータのハードウェア形式で特に有用である。たとえば、ＩＢＭ社 製ＡＳ４００装置は、それぞれのジョブが関連したライブラリ・リストを有する ようなライブラリ・リストを使用する。 本発明によるシステムの大きな利点は、必要とされるメモリー常駐コード（コ ア・プログラム）の量が小さいことである。実際に、この利点は、コア・プログ ラムが充分に小さいことによるもので、たとえばＩＢＭ社製ＡＳ４００等の装置 のメモリー内に常駐できる。したがって、プログラムのページングの必要性が大 幅に回避される。ヘルプ・システム 実体形式としてヘルプ・ファイルを指定することにより、オンライン・ヘルプ 機能が容易に実装できる。つまり、実体形式「ヘルプ」、実体「業務」属性「電 話番号」により「業務」と「電話番号」の間の代理レコードを形成し、このレコ ードがその組み合せの説明を含む。実体形式は別のコンテキストで考えた場合に 実体になるので、ヘルプ・システムを実装するためにコア・プログラムで必要と される処理は極くわずかである。ヘルプ・テキストはそれぞれの個別の実体に対 してではなく特定の実体形式で記録する。 ヘルプ・メニューはアプリケーション固有である必要がない。 ヘルプ・システムの使用は、データベース内に記録された他の種類のデータへ のアクセスと同じである。前述したのと同じ方法で関連レコード間を航行する。 上記のオンライン・ヘルプ・システムは、完全に独立したオンライン・ヘルプ ・データベースとこれに関連するプログラムの組を作成するような、従来の方法 を完全に回避するものである。 上述の本発明の説明は、１９９３年１０月４日付英国特許出願第９３２０４０ ４．８号に記載されたものである。該日付以降、各種の変更が実装され、試験さ れた。これらの変更のうちで特に、前述したオプション・レコードが前述のメニ ュー・レコードと統合された実施例があった。原理は変わらないが、単一のレコ ード形式を前述の２つのかわりに使用する。別の変更はさらに、データを記録す るための代理レコードの使用であった。前述のように、代理レコードは代理番号 を記録するために存在しており、これはシステムの主要な内部識別子と考えるこ とができる。しかし、代理レコード内にさらにデータを記録することができる。 このような追加データは、代理レコードが関連するレコードの内容に関連すべき で、望ましくは関連レコードの内容で表示すべきである。 １９９３年１０月以降本発明の初期の実施が独立して試験された。このような 試験は、従来のプログラミング技術と比較して、新規アプリケーション（すなわ ち「プログラム」の一種）の開発効率を５００％またはそれ以上に改善すること を意図したものであった。テストによれば、完成したアプリケーションの動作速 度においても同程度の改善が報告された。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，Ｎ Ｚ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＩ，ＳＫ ，ＴＪ，ＴＴ，ＵＡ，ＵＳ，ＵＺ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．少なくとも２つの識別子の数値連結から成るキーフィールドを有するレコー ドの作成を含むデータの格納と取り出しの方法。 ２．前記キーフィールドは、実体形式の識別子と属性の識別子を含む請求項１に 記載の方法。 ３．前記キーフィールドは、請求項２に記載したものおよび実体の識別子を含む 少なくとも３つの識別子の数値連結である請求項２に記載の方法。 ４．前記キーフィールドの一部は、前記レコードの非キーフィールド部分の構造 を表わす先行の請求項のいずれかに記載の方法。 ５．リスト内のそれぞれのエントリに数値が予め割り当ててある単語および／ま たはフレーズのリストから、数値が得られる先行の請求項のいずれかに記載の方 法。 ６．前記レコードの幾つかはデータを格納し、前記レコードの他のものはデータ 間の関連性の詳細を格納する先行の請求項のいずれかに記載の方法。 ７．前記レコードの幾つかはデータを格納し、前記レコードの他のものはデータ 処理を制御する先行の請求項のいずれかに記載の方法。 ８．情報項目の記録は３つのレコードの作成と記録に関連し、そのそれぞれが他 の２つのレコードを識別することのできる識別子を含む先行の請求項のいずれか に記載の方法。 ９．前記キーフィールドは英数字の記述から得られる番号を含み、前記番号は単 語のリストから得られ、前記リストにおいて、リストのそれぞれのエントリに対 して数値が、前記第１の後の英数字の記述における単語に割り当てられている重 要性が減少するように、予め割り当ててある先行の請求項のいずれかに記載の方 法。 １０．少なくとも２つの識別子の数値連結から成るキーフィールドを有するレコ ードを形成する手段を含むデータ格納および取り出しシステム。