(57)【要約】【課題】データベース自体を変更する必要なく物理的又は仮想的ユニバースにおける何かを表わすように設計されたユニバーサルデータベースシステムを提供する。【解決手段】データベースに追加されるべきいかなるデータもサポートする形態でデータを全ての関係においてモデリングしそして記憶するための再使用可能なデータ駆動型ユニバーサルデータベースモデル及びシステム。データベースシステムは、いかなる形式のデータ又はデータドライブもその関係において記憶するいかなる形式の用途に対しても実施できる。このシステムは、各々のノード及びそれ自体との接続により多対多の関係を有する複数のノードを含む。好ましくは、データベースシステムは、ソフトウェアで使用することも又はハードウェア形態で埋め込むこともできる不変のフォーマットである。【選択図】図２
2006053934.tif 000002
【特許請求の範囲】
【請求項１】
データベースシステムを形成する方法において、
ユーザ定義データを含む異なる特定特性(specific characteristic)を各々が表わす複数のデータ記憶ノードを確立するステップであって、前記複数のノードが、前記データベースシステムに追加されるべき全てのデータの共通の標準特性(denominator characteristics)を表わすようにするステップと、
リンクノードを使用して各ノードを他の各ノード及びそれ自身に接続することにより前記ノード間に多対多の関係を形成するステップであって、前記リンクノードが、識別と、そのリンクノードが接続する２つのノードに関するデータとを指定するようにするステップと、
各データム(datum)の特定ノード特性(specific node characteristics)及びユーザ指定特性(user-assigned characteristics)に基づいてデータムを分類するステップと、
各データムを、その対応特性(corresponding characteristics)を表わすノードに記憶するステップと、を備えた方法。
【請求項２】
前記複数のノードは少なくとも６個のノードを含む、請求項１に記載の方法。
【請求項３】
前記６個のノードは、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ及びｔｉｍｅの特定特性に対するユーザ定義データを指定する、請求項２に記載の方法。
【請求項４】
前記複数のノードは８個のノードを含む、請求項１に記載の方法。
【請求項５】
前記８個のノードは、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ、ｔｉｍｅ、ｑｕａｎｔａ及びｍｏｄｉｆｉｅｒの特定特性を伴うユーザ定義データを指定する、請求項４に記載の方法。
【請求項６】
ノード及びリンクノードをリンク−リンクノードと接続するステップを更に備えた、請求項１に記載の方法。
【請求項７】
前記リンク−リンクノードは、識別と、それが接続するノード及びリンクノードに関するデータとを指定する、請求項６に記載の方法。
【請求項８】
２つのノードのデータ間の関係を定義するステップを更に備えた、請求項１に記載の方法。
【請求項９】
前記関係は、類似、相違及び同一として定義される、請求項８に記載の方法。
【請求項１０】
データベースシステムを形成する方法において、
ユーザ定義データを含む異なる特定特性を各々が表わす少なくとも６個のデータ記憶ノードを確立するステップであって、その複数のノードが、前記データベースシステムに追加されるべき全てのデータの共通の標準特性を表わすようにするステップと、
リンクノードを使用して各ノードを他の各ノード及びそれ自身に接続すると共に、リンク−リンクノードを使用して前記ノードを前記リンクノードに接続することにより、前記ノード間に多対多の関係を形成するステップであって、前記リンクノードが、識別と、そのリンクノードが接続する２つのノードに関するデータとを指定し、そして前記リンク−リンクノードは、識別と、そのリンク−リンクノードが接続するノード及びリンクノードに関するデータとを指定するようにするステップと、
２つのノード又はリンクノードのデータ間の関係を定義するステップと、
各データムのユーザ指定特性に基づいてデータムを分類するステップと、
各データムをその対応特性を表わすノードに記憶するステップと、を備えた方法。
【請求項１１】
前記６個のノードは、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ及びｔｉｍｅの特定特性に対するユーザ定義データを指定する、請求項１０に記載の方法。
【請求項１２】
前記少なくとも６個のノードは、本質的に８個のノードで構成される、請求項１０に記載の方法。
【請求項１３】
前記８個のノードは、各々に対するユーザ定義データムと共に、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ、ｔｉｍｅ、ｑｕａｎｔａ及びｍｏｄｉｆｉｅｒの特定特性に対するユーザ定義データを指定する、請求項１２に記載の方法。
【請求項１４】
前記関係は、類似、相違及び同一として定義される、請求項１０に記載の方法。
【請求項１５】
データベースを有するコンピュータシステムにおいて、
メインメモリと、
プログラムされたプロセッサと、
各々に対してユーザ定義データを含む異なる特定特性を各々が表わす少なくとも６個のデータ記憶ノードを有する不揮発性記憶媒体であって、その複数のノードが、前記データベースに追加されるべき全てのデータの共通の標準特性を表わすような不揮発性記憶媒体と、を備え、
前記ノードは、リンクノードを使用して各ノードを他の各ノード及びそれ自身に接続し、前記リンクノードは、識別と、そのリンクノードが接続する２つのノードに関するデータとを指定し、前記ノード間に多対多の関係を形成し、
前記データは、前記ノードの特性に対応する各データムのユーザ指定特性に基づいて各ノードに記憶され、そして
前記プログラムされたプロセッサは、接続されたノードに含まれるデータ間の関係を定義するのに使用される、というように構成されたコンピュータシステム。
【請求項１６】
前記少なくとも６個のノードは、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ、及びｔｉｍｅの特定特性に対するユーザ定義データを指定する、請求項１５に記載の方法。
【請求項１７】
前記複数のノードは、ｂｅ、ｄｏ、ｈａｖｅ、ｓｐａｃｅ、ｅｎｅｒｇｙ、ｔｉｍｅ、ｑｕａｎｔａ、及びｍｏｄｉｆｉｅｒの特定特性に対するユーザ定義データを指定する本質的に８個のノードで構成される、請求項１５に記載の方法。
【請求項１８】
前記ノード及びリンクノードは、リンク−リンクノードで接続され、該リンク−リンクノードは、識別と、それが接続するノード及びリンクノードに関するデータとを指定する、請求項１５に記載の方法。
【請求項１９】
前記関係は、類似、相違及び同一として定義される、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データベース及びデータ記憶技術に係る。より詳細には、本発明は、データベース自体を変更する必要なく物理的又は仮想的ユニバースにおける何かを表わすように設計されたユニバーサルデータベースシステムに係る。
【０００２】
本出願は、２００４年８月４日に出願された米国プロビジョナル特許出願第６０／５９９，１９１号の優先権を主張する。
【背景技術】
【０００３】
データベースとは、コンピュータ又は他のマシンがデータを組織化された状態で記憶し検索するのに使用できる組織化された情報の集合である。データベースは、一般に、通常の構造を利用して、データを組織化された状態で記憶し、編成化しそして検索する。データベースは、必ずしもそうでないが、通常、コンピュータ又は他のマシン方法によりアクセスされるあるマシン読み取り可能なフォーマットで記憶される。
【０００４】
確かに、データベースは、良く知られていて一般に利用されている。実際に、それらは、全ての企業活動で共通である。というのは、いかなる企業も、顧客リストから会計データに至るまで、記憶して検索することを必要とする情報を有するからである。
【０００５】
データベースを分類する最も有効なやり方は、データベースに関連したプログラミングモデルによるものである。以前には多数の方法が使用されていた。近代的なバージョンに良く似たほとんどのデータベースは、最初に、１９５０年代に開発された。単一ファイルでの単純な記憶から、部屋いっぱいのディスクドライブに記憶される数百万の記録を伴う非常に大きなデータベースまで、広範囲な様々なデータベースが存在する。
【０００６】
フラットファイル(Flat File)
確かに、かつて形成された最初のデータベースは、そのほとんどが、ＥＮＩＡＣのようなシステムや他の初期のコンピュータシステムによりルックアップするのに使用されるテキストデータのリストのようなものであった。この形式のデータ記憶は、「フラットファイル」と称され、行ごとに非常に僅かなアイテムをもつ簡単なデータリストのショッピングリストをテキストドキュメントにタイプする場合に何を行うかというものである。これは、単純な環境では非常に有効であるが、より多くのデータが累積されるにつれて、関心のある何かを探索することが益々困難になる。更に悪いことに、そのとき、８Ｋ又は１６Ｋで多くのスペースと考えられる場合には記憶が不足し、従って、全てをできるだけ効率的にパックするように行わねばならず、長いリストが、通常、繰り返し情報を含むことになる（全てが同じ市及び州情報を有する市の住民リストのように）。
【０００７】
これらの初期の年代でも、あるデータ記録が繰り返しデータを含む場合にはデータ記憶を最適化することが必要になった。
【０００８】
更に、フラットファイルデータベースモデルは、効率的な記憶方法ではなく、次のモデルのはずみとなった。
【０００９】
ハイアラーキーモデル(Hierarchical Model)
データを、表示されたデータごとの線でデータの「テーブル」として知られたものに分離したものを、「記録」と称する。テーブルは、ある共通性及び構造により収集されたデータを含む。又、これらテーブルは、通常、異なるテーブルの記録間で共通の１つ以上の数値によって一緒に結合される。これは、正規化というものの第１の概念であり、これは、繰り返し情報の分類及び分離によりこのようなデータベースを最適化したものである。
【００１０】
ハイアラーキーモデルは、下位の関連データへ分岐するポインタ又は参照を使用することにより多数のテーブルを一緒に使用するのを許す。この形式の構造は、コンピュータディレクトリ構造に依然として使用されている。これは、固定ハイアラーキーにおける「親」及び「子」関係のシステムであった。これは、非常に厳格な設計であった。
【００１１】
子の記録を多数の親に適用でき、繰り返しの子データを生じるときには問題が生じる。というのは、このモデルは、親へ「戻る」（ルートに向かう）多数のリンクをサポートせず、多数のリンクは子の記録に向かってダウンする（ルートから離れる）だけだからである。又、親にもアタッチするまで子の記録を追加できないか、又は親を削除した場合に子の記録も全て除去されるという同様の問題もある。又、ハイアラーキーの中間で記録を見つけたい場合にも、最上部でスタートしなければならない。
【００１２】
又、分岐（ブランチ）は、別の「親」により既に「所有」されている子の記録には決してアタッチされない。例えば、大学の学部から２つのコースへダウンしそして各コースの学生へとダウンするブランチは、ある学生がある学部において２つ以上のコースをとり、従って、このモデルにおいて２つ以上の記録を有し（各コースに１つリンクされる）、主として多対多(many-to-many)の関係をサポートできないことによる繰り返しデータによりスペースを浪費することが分かる。
【００１３】
ネットワークモデル
ネットワークモデルは、クロスインデックスデータを追加し、（以前のモデルに対して）記憶が非常に効率的であるという点でハイアラーキーモデルに対する改良であった。その最良の例は、航空機座席予約システムである。
【００１４】
これは、複雑なデータ構造の構築を許すが、融通性がない上に、入念な設計を必要とし、基本的設計に関してインデックスを編成したプログラマーの「精神」を理解しないと分からない。ハイアラーキーモデルと同じ制約が多数ある。
【００１５】
関連モデル(Relation Model)
最終的に、関連データベースモデルの進歩がこれら問題の多くを解決した。これは、データベース設計者が指定した参照によって互いにリンクされるデータテーブルで構成される。これに伴い、データベースは、データベース設計者が創作のために選択できる任意の方法でリンクすることができ、設計者のイマジネーション又はロジックにより限定されるに過ぎない。関連データベースモデルは、データベースエンジンの創作者が予想する必要のないリンクをユーザが設計するのを許す。これは、数十年間にわたり標準となるに充分なほど、以前の方法より優れていた。関連データベースは、会社及び他の用途で非常に普及した。
【００１６】
関連モデルを使用すると、理論的には、正規化（「標準形(Normal Form)」と称する）を第１２標準形まで適用できるが、第５標準形を越えて進むことは稀であり、ほとんどの場合には、第３標準形までしか使用しない。正規化理論のもとでは、データを完全な一般的パッケージへと完全に抽象化することができる。問題は、これらパッケージが何であるか決定できないことであり、これは、おそらく、人々が上位レベル正規化をデータベースに稀にしか適用しない理由である。
【００１７】
関連モデルに伴う主たる問題は、全てに対して単一の解決策がないことである。全ての開発者は、本質的に、即座のニーズに対して新規な独特な解決策を創作し、（未知の将来の問題をサポートし得る設計を充分に考えたものがないので）これはしばしば将来的な問題を招く。又、各データベースが本質的に固有（ユニーク）である状態では、データの携帯性が最小であり、実際に、毎日のデータ共有工程だけで、年間、数百万時間及び数十億の資金を必要とする。
【００１８】
オブジェクトモデル
ある人々は、これらの問題は「オブジェクトモデル」と称される新規なモデルにより解決されると考えている。このモデルは、プログラミング言語から派生したオブジェクト指向の技術を使用して共通のエレメントへリンク可能な「オブジェクト」を形成するように試みる。理論的に、これは、データカプセル化、継承、多形性、及び他のオブジェクト指向の技術をサポートする。しかしながら、完全なアイデアとして、今のところ、これらの共通のオブジェクトが何であるか、又はそれらをどのように関連させるか解決されていない。
【００１９】
データベースの次元
各々の従来のモデルを再検討したが、あるパターンが見えてくる。フラットファイルデータベースモデル、又は全てのデータを単一テーブルの周りに集中させるものは、「一次元」データベースと考えることができ、これは、概観上、より複雑なシステムに対してキーワードサーチエンジン（ＧｏｏｇｌｅTMのような）を含む１つの一次テーブルに依存するデータベースモデルを包含する（依存性の少ない現在の多数のテーブルに関わりなく）。通常、キー次元の数を使用して設計の複雑さを分析することができる。
【００２０】
データベースが成長し、関連データベースへと進歩するにつれて、テーブルの数は増加したが、通常、他の全てのものがリンクされる一次テーブルは、常に、１つ又は２つであった。より複雑なデータベース設計では１つの中央テーブルが使用されず、他の全てのものがリンクされる２つ以上のデータテーブルが含まれる。これと同程度に簡単であるのが健全であるので、今日の最も複雑なシステムでもこの構造を越えるとは思われず、幾つかの適当な「複雑な」システムは、結局は、「二次元」データベースと考えることができ又はそのように称することのできる２つの一次テーブルに要約することができる。この形式は、一般に、非常に共通していて、今日使用される全てのデータベースの多くを表わすことができる。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、（通常の使用ではあまり表わされないが）もっと複雑なシステムがある。これらは、同じくらい重要な３つの一次テーブルのグループが存在して、これらに多数のより小さなテーブルがリンクされる「三次元」設計である。例えば、顧客、製品及び会計を中心としたこれら３つの一次テーブルが、より小さなサポートテーブルにより取り巻かれるようなビジネスシステムが包含される。奇妙にも、幾つかの会社のデータベースは、この設計を使用し、これを行う会社は、データベースをユニバーサルなものにするのではなく、１つのタスクに特有なものに設計する。
【００２２】
従来技術の各々は、それ以前のシステムを越えて進歩したと考えられる概念を有するが、従来のデータベースはいずれもユニバーサルなデータベースではなく、即ち物理的ユニバース及びそれらの全ての関連性においてデータのみにより、即ち同じコアデータ構造を使用して、何かを表わすことのできるデータベースではない。従って、データベース構造を、データそれ自体のように変更することが必要とされず、いかなる考えられるデータ関連性も、データベース構造を変更せずにデータの変更自体により示し得るように設計されたユニバーサルなデータベースが要望され続けている。本発明は、これらの要望を満足すると共に、他の関連する効果を発揮する。
【課題を解決するための手段】
【００２３】
本発明は、物理的又は仮想的ユニバースを表わすデータをサポートする形態でデータ及び全ての関係をモデリングしそして記憶するための再使用可能なデータ駆動リソースであるユニバーサルデータベースモデル及びシステムにある。本発明は、いかなる形式のデータも記憶できる標準的な不変フォーマットを使用し、そしていかなる形式のデータ又はデータドライブもその関係で記憶するいかなる形式の用途についても実施できる。
【００２４】
人間の精神を、最終的なデータベースモデルを含む最終的なコンピュータとして考えるべき場合には、それがある形式の情報（知覚）及びそれらの分析を無限数の組み合わせで記憶することに気付く。
【００２５】
最終的な問題は、現在考えられる以上に良好な精神の表示をいかに創造するかを解決することであった。確かに、新たなアイデアは、以前の「型」に適合しないので、基本的な構造（例えば、頭脳、又は精神の他のメカニズム）を簡単に再構築することが要求されるのではない。データの標準形態があり、本発明の結果に貢献するのは、この研究であった。
【００２６】
「ユニバーサル」であることが意図されるモデルの最も重要な項目は、実際の「ユニバーサル」エレメントの識別である。これは、従来の全ての努力の主たる弱点であった。共通のデータエレメントを有する場合には、理論的には、限定数の原子の形式から任意の形式の分子を構築するように、それらエレメントから何かを構築することができる。これら共通のデータエレメントは、本発明において識別され、定義される。
【００２７】
本発明によりデータベースシステムを形成する方法は、一般に、ユーザ定義データを含む異なる特定特性を各々が表わす複数のデータ記憶ノードを確立するステップを備えている。複数のノードは、データベースシステムに追加されるべき全てのデータの共通の標準特性を表わす。好ましくは、複数のノードは、少なくとも６個のノードで構成される。このような６個のノードは、Ｂｅ、Ｄｏ、Ｈａｖｅ、Ｓｐａｃｅ、Ｅｎｅｒｇｙ及びＴｉｍｅの特定特性に対するユーザ定義データが指定される。特に好ましい実施形態では、複数のノードは、８個のノードで構成され、追加の２つのノードは、Ｑｕａｎｔａ及びＭｏｄｉｆｉｅｒの特定特性を伴うユーザ定義データが指定される。
【００２８】
各ノードを他の各ノード及びそれ自身に接続することによりノード間に多対多の関係が形成される。これは、通常、リンクノードを使用することにより行われ、このリンクノードは、識別と、そのリンクノードが接続する２つのノードに関するデータとが指定される。更に、ノード及びリンクノードは、リンク−リンクノードで接続され、このリンク−リンクノードも、識別と、それが接続するノード及びリンクノードに関するデータとが指定される。
【００２９】
データベースシステムに追加されるべき各データムは、特定ノード特性に基づき、且つ各データムのユーザ指定特性を使用して分類される。各データムは、それに対応する特性を表わすノードに記憶される。
【００３０】
２つのノードのデータ間の関係が定義される。これらの関係は、通常、類似、相違及び同一として定義される。
【００３１】
通常、本発明のデータベースは、メインメモリと、プログラムプロセッサと、少なくとも６個のデータ記憶ノードをもつ不揮発性記憶媒体とを有するコンピュータシステム内で確立される。プログラムプロセッサは、接続されたノードに含まれたデータ間の関係を定義するのに使用されると共に、データベースエンジンとして働く。本発明のデータベースは、標準的な不変のシステム及びモデルであるのが好ましいので、本発明をハードウェア形態に合体することができる。これは、半導体及び他の電子フォーマットに埋め込むことができる。
【００３２】
本発明の他の特徴及び効果は、本発明の原理を一例として示す添付図面を参照した以下の詳細な説明から明らかとなろう。添付図面は、本発明を例示するものである。
【００３３】
定義
データベース
データを組織化された仕方で記憶し及び検索するのに使用でき、通常、コンピュータ又はコンピュータ化されたシステムにより利用される組織化された情報の集合。
【００３４】
論理的表示
論理的表示（又はビュー）とは、物理的又は構造的ビューではなく、モデルの概念的ビューを指す。論理的ビューにおいては、データの関係又はデータの背後にある技術的な実施ではなく、データの関係及びデータ自体がより問題となる。
【００３５】
物理的表示
物理的表示（又はビュー）とは、論理的表示ではなく、低レベルビューを指すが、データベースオブジェクトのテーブル、記録、フィールド又はデータ形式のような構造の厳密なレイアウトの定義については、そのようにならない。これは、構造に関して含蓄を伴う若干抽象化された表示であるが、融通性のある実施を許す。
【００３６】
構造的表示
構造的表示（又はビュー）とは、最低レベルのビューと、データベースの構造に必要な全ての観点とを指す。ここでは、テーブル、記録、フィールド又はデータ形式の定義のようなデータベース構造の厳密なレイアウトを指す。
【００３７】
エレメント
エレメントとは、データベースの一次の論理的原子の１つである。これは、記憶されているデータムの全てのデータ及び属性を含む。本書において参照するときには、主として、これら原子の論理的観点を指す。それらは、８つの形態の１つをとる。
【００３８】
１．Ｂｅ、Ｂｅｉｎｇｎｅｓｓ（Ｂ）：認識（又は識別される）の状態又は条件、或いは認識の分類の仮定。これは、識別であるか、又は何か（人又は物）を識別する何らかの仕方である。Ｂｅｉｎｇｎｅｓｓは、何かを識別するいずれかの又は全ての仕方を含むことができる。
【００３９】
２．Ｄｏ、Ｄｏｉｎｇｎｅｓｓ（Ｄ）：Ｄｏｉｎｇとは、アクション、機能、完成、目標の成就、目的の達成、又はスペース内の位置の変化を意味する。Ｄｏｉｎｇは、効果を生み出すアクションである。Ｄｏｉｎｇｎｅｓｓは、効果を生み出す条件である。Ｄｏｉｎｇｎｅｓｓは、いずれか又は全てのアクティビティを含むことができる。
【００４０】
３．Ｈａｖｅ、Ｈａｖｉｎｇｎｅｓｓ（Ｈ）：何かをもつことは、それにタッチし又は行き渡らせ、或いはその配列を指令できることである。Ｈａｖｉｎｇｎｅｓｓは、環境と通信する能力であると考えることができる。これは、何かに到達することができ、又は到達することが防止されないという概念である。何かを所有し又は所持するフィーリングである。Ｈａｖｉｎｇｎｅｓｓは、持ち、制御し又は知覚し得るいずれか及び全てのものを含むことができる。
【００４１】
４．Ｓｐａｃｅ（Ｓ）：これは、次元の観点である。これは、物理的な語では、点、線、面積、体積であり、又は論理的な語では、位置である。
【００４２】
５．Ｅｎｅｒｇｙ（Ｅ）：これは、フロー、分散又は峰としての潜在的又は運動的モーション又はパワーである。これは、いずれか及び全ての力、作用又は方向モーションを含むことができる。
【００４３】
６．Ｔｉｍｅ（Ｔ）：粒子（エネルギーを含む）の位置の機械的に追跡される変更の抽象的表明及び考慮。これは、ｔｉｍｅを参照することも含む（部分的又は全体的）。
【００４４】
７．Ｑｕａｎｔａ（Ｑ）：番号、数学及び方程式の抽象的エンティティとして定義される。ユニバースの概念的数字表示。これは、記号及び数学の世界である。
【００４５】
８．Ｍｏｄｉｆｉｅｒ（Ｍ）：英語では、これは、名詞に対する形容詞、又は動詞に対する副詞と考えられる。
【００４６】
本書において参照するときには、これら原子の論理的観点だけを指す。最初の６個のエレメントは、コア又は一次エレメントであり、このため、この設計は、６又は８個のエレメントとして表現されるＢＤＨ−ＳＥＴと時々称され、一方、ＢＤＨ−ＳＥＴ＋ＱＭは、暗示的に８エレメントシステムを表わす。
【００４７】
ノード
ノードは、エレメントの物理的表示である。ノードとエレメントとの相違は、エレメントを参照するときには、データをいかに使用するかをより多く説明し、一方、ノードは、データベース設計のより下位レベルのビューを示すことである。論理的関係（エレメント）においては、どのテーブルが２つのテーブルをリンクするかに関心がなく、それらがリンクされることだけに関心がある。物理的関係においては、リンクすること及び動的なテーブル構造のあるものに関心がより高い。以下、データベーステーブルの構造定義である。本書は、テーブルがここでの要求に適合すること以外、テーブルのフィールドごとのレイアウトを定義するものではないことを述べねばならない。常に、データは、時間ノードに記憶され、本書は、それらが何をすべきかだけを定義する。これをいかに実施するか及び必要なフィールドは、実施形態に基づく。
【００４８】
テーブル
テーブルは、構造アイテムである。データベースにおいては、これは、データ記録の二次元容器である。通常、テーブルは、「記録」と称される密接にリンクされたデータを収容するように編成される。
【００４９】
記録
記録は、構造アイテムである。これは、テーブルが表わすアイテムに関する特定データを含む一次元のテーブルデータである。又、時々、「行」とも称される。記録は、通常、この１つの共通データの属性である多数のフィールドを含む。
【００５０】
フィールド
フィールドは、構造アイテムである。これは、記録からの１つのデータムである。データベースにおいて、テーブルは、記録で構成され、そして記録は、フィールドで構成される。これらフィールドは、１つの記録から次の記録への同じフィールドに対して同じ形式のデータを含む。
【００５１】
データ形式
データ形式(Datatype)（「データの形式(Data Type)」と同様）は、記憶されたデータムの形態である。構造上の観点から、これは、整数、キャラクタ、ストリング、フローティングポイント、日付、等の形式でよい。しかしながら、本書では、データが、その構造で行うべきものをもたない定義された論理的形式のものである場合に、このようなデータの論理的表示を指す。このようなデータ形式は、「個人」、「名前」、「会社」、「市」、又は番号、例えば、「３３」を含んでもよく、ここでは、それがどんな構造形式であるかは問題でなく、それが使用可能な値を表わすことが問題である。
【００５２】
リンク
リンクとは、物理的なメカニックに関わらず２つのエレメントの関連の論理的観点である。これは、エレメントに対し、ノードへのリンクノードが何であるかというものである。リンクノードは、以下で詳細に説明する。
【００５３】
リンクノード
リンクノードとは、２つのノードの関連の物理的観点である。これは、多対多の関係を形成するためにこれらテーブル間の接続のメカニックの問題である。多対多の関係を形成する仕方は多数あるが、これらは、２つのノードテーブル間のテーブルにより、構造表示において最も一般的に管理される。本書では、多対多の関係の要求、及び他の論理的要求をサポートする以外、このリンクノードの構造上の実施は取り扱わない。
【００５４】
リンク−リンクノード
これは、ノード対リンクノードの関連である。２つのノード間の関連を定義するリンクノードをもつのと同様に、ノードがリンクノード自体に関連され、即ちリンク−リンクノードによって接続される条件も存在する。
【００５５】
分子
記憶容器の論理的表示に対してエレメントのような語を使用することを考慮し、これらの容器を多数の組み合わせで関連付けできることを理解しなければならないので、これらの組み合わせは、本書では「分子」と称される。
【発明を実施するための最良の形態】
【００５６】
本発明は、例示のために添付図面に示されて以下に詳細に述べるように、ユニバーサルデータベースシステム及び関連方法に係る。本発明のデータベースは、データベース構造を変更する必要がなく、データ自体を変更するだけでよいように設計される。データは、関係を定義し、そして考えられる関連性は、データベースの構造を変更せずに、データの変更自体によって示される。
【００５７】
本発明のデータベースは、物理的ユニバースにおける考えられるデータ、並びに考えられる関係及びロジックを表わすことができる。欠落データム又は関係は、既存のデータに影響することなく、いつでも含ませることができる。データム自体は、任意のソースからアクセスできるので、データベースにおいて繰り返されない。
【００５８】
エレメント（ＢＤＨ−ＳＥＴ）
他の全ての技術は、種々のテーブル、全ての独特の形式及びコンテンツと共に機能したが、主たる問題は、データの識別、及びその共通の分母への分類であった。それらに対してのみ、データを、使用可能な及び再使用可能な形態で適切に且つ充分に記憶することができる。ここに述べるデータベースは、これらの条件及びそれ以上を満足する。
【００５９】
第１のタスクは、これら共通のエレメントの識別及び分離を含む。オリジナルの共通エレメントは、Ｂｅｉｎｇｎｅｓｓ、Ｄｏｉｎｇｎｅｓｓ及びＨａｖｉｎｇｎｅｓｓであり、各エレメントは、それ自身を含めて、他の各々にリンクされる。更に、ＢｅｉｎｇｎｅｓｓはＳｐａｃｅに関連され、ＤｏｉｎｇｎｅｓｓはＥｎｅｒｇｙに関連され、そしてＨａｖｉｎｇｎｅｓｓはＴｉｍｅに関連されることが決定された。多数のＳｐａｃｅが、常に、大きなＢｅｉｎｇｎｅｓｓに関連される。多数のＥｎｅｒｇｙが、常に、Ａｃｔｉｖｉｔｉｅｓ（Ｄｏｉｎｇｎｅｓｓ）に関連される。Ｔｉｍｅは、常に、Ｏｂｊｅｃｔ（Ｈａｖｉｎｇｎｅｓｓ）に関連される。従って、リンクは、互いに他の各々と相互接続されたこれら６個を含むように拡張された。便宜上、このデータベースモデルは、ここでは、「ＢＤＨ−ＳＥＴ」として知られている各トリプレットにおける各一次エレメントの最初の文字で識別することができる。
【００６０】
Ｂｅｉｎｇｎｅｓｓ
Ｂｅｉｎｇｎｅｓｓは、おそらく、全てのノードの中の最も有用なもの、又は少なくとも最も使用されるものである。実際上全てのものが非常に多数のやり方で識別される。個人は、その名前、社会のセキュリティ番号、運転免許証番号、電話番号、ｅメールアドレス、指紋等で識別される。オブジェクトは、そのアイテム名、バーコード、ボックス番号、コンピュータ記録番号、等で識別される。実際に、これは、全ての中で最も冗長なエリアである。
【００６１】
当然、この形式のデータの記憶は、ストリングのような自由形態の容器又は別の多形性インターフェイスを必要とする。これは、各Ｂｅｉｎｇｎｅｓｓのデータ形式もユーザ定義されねばならないことを意味する全ての認識が創案されることを含む。これを行う種々の仕方が存在するが、その１つは、値に対してストリングをそしてデータ形式に対して別のものを使用するものでよい。
【００６２】
何かを識別する方法は多数あり、異なる言語を使用するものもあるので、これは、断然、エレメントの中の最も重要なものである。これらＢｅｉｎｇｎｅｓｓの関係は、食い違いである。
【００６３】
これらの関係の幾つかは、このデータベースシステムに必要な他のコンポーネントの幾つかの理解を必要とするので、本書の応用セクションで良好に表わされる。
【００６４】
Ｄｏｉｎｇｎｅｓｓ
Ｄｏｉｎｇｎｅｓｓは、一般に、これに伴う多数のＤｏｉｎｇｎｅｓｓを有する。１つのアクションは、完了すべき多数のステップを必要とすることがある。従って、Ｄｏｉｎｇｎｅｓｓは、Ｂｅｉｎｇｎｅｓｓに対して系統的ツリーがあるのと同様に、登るべき別のハイアラーキーである。ステップは、「モーターの再構築」のような全体的なタスクとしてステップのグループを定義するまで何かをいかに構築するかの単一の命令でよい。
【００６５】
Ｂｅｉｎｇｎｅｓｓを、多数の規格、言語、又は任意の形式のシステムにより多数の仕方で構築できるのと同様に、この形式のデータを記憶するための最も簡単な仕方の１つは、ここでも、値に対してストリング、そしてユーザ定義可能なデータ形式に対して別のものである。
【００６６】
Ｈａｖｉｎｇｎｅｓｓ
Ｈａｖｉｎｇｎｅｓｓは、世界へのインターフェイスである。記憶されるデータは、ある形態又は別の形態で、ここに記憶される。あるドキュメントは、Ｎａｍｅ（Ｂｅｉｎｇｎｅｓｓ）又はＤｏｃ  ＩＤ（Ｂｅｉｎｇｎｅｓｓ）を有してもよいが、これは、実際に、ドキュメントファイル自体であり、又は少なくともそれに対するポインタである。この構造は、いかなる形式の参照もサポートするに充分な融通性がなければならない。
【００６７】
技術的には、これは、人間がユニバースにいかにアクセスするかという視覚又は聴覚のような感覚と同様に、外部ユニバースへのアクセスも表わす。又、これは、真のユニバースにおいて何かを移動するためのコマンドのような制御インターフェイスでもある。
【００６８】
これは、ファイル名、又はある真のユニバースアクティビティを実行するためのコマンドのようなものの記述でよい（ロボットの場合のように）。もちろん、これは、何がインターフェイスされるかに基づいてユーザにより形式を定義しなければならないことも意味する。
【００６９】
このインターフェイスにおけるデータ（ファイルにおけるデータのような）の変更により、流入データを含む外部ユニバースと相互作用することができる。これは、本質的に、所有権又は相互作用に関してユニバースへの入力／出力バッファである。
【００７０】
上記事柄に伴い、ほとんどのＩ／Ｏは、パスしたデータに関するものである。コンピュータプロセッサは、データのブロックをいかに操作するかを定義する値を使用する。コンピュータ技術では、それ自身のバッファにおいて各々定義されたコマンド及びデータに関してハードウェアへ及びハードウェアからデータをパスすることは標準的である。ＳＣＳＩプロトコルは、コマンドバッファ及びデータバッファを備え、その各々は、データが充填され、そしてこれらバッファには単なる参照アドレスが処理のために送信される。そのとき、ＳＣＳＩコントローラは、コマンドバッファをルックアップし、データを読み取って、データバッファのデータで何をすべきか決定する。これは、コンピュータ技術における標準的手順である。
【００７１】
このモデルでは、コマンドと、参照により識別されたデータバッファとを使用することにより、同じことを実施できる。コマンドがコマンドバッファへストリングとしてパスされるかポインタとしてパスされるかは、関係がない。又、データがパラメータとしてコマンドストリングに供給されるか又は別のデータバッファとして供給されるかも、関係がない。入力及び出力に対して定義された標準があるので、厳密な実行方法には関心がない。
【００７２】
従って、考えられる最も簡単な方法を使用して、データエレメントは、値に対するストリング、及びデータ形式（コマンド、バッファ等）を定義するための別のストリングでよいことが考えられる。これらの対を構築して、コマンド及びデータバッファを定義してもよいし、或いは考えられるシステムに対して必要であるのと同程度のパスしたデータのラインを定義してもよい。
【００７３】
その一例として、ファイル名は、ファイルと考えるデータバッファへの参照ストリングである。もちろん、形式も「ファイル」であると仮定する。
【００７４】
Ｈａｖｉｎｇｎｅｓｓは、その最も簡単な形態において、値に対するストリングと、ユーザ定義可能なデータ形式に対する別のものとにより、簡単に表わすことができる。或いは、コマンド及びデータバッファのような対で使用することができ、バッファ自体は、どんなオペレーションか及び返送されるデータを定義する。
【００７５】
通常、Ｈａｖｉｎｇｎｅｓｓは、それら自身の値が関連付けられる。この実施形態は、全ての値をＱｕａｎｔａリンク（以下を参照）として表わすように選択してもよいが、これらの値は、ここでは、直接記憶することもできる。マス(mass)は、重みを有する。ファイルは、サイズを有する。アイテムは、量（カウント又は他の記述に関して）を有する。特定の実施形態の判断においては、これらの値は、Ｈａｖｉｎｇｎｅｓｓの一部分でもよく、或いは単にＱｕａｎｔａリンクとして関連されてもよい。
【００７６】
コマンド及びメッセージバッファとして設計するときには、これらは、ユーザ定義された単位でこれらバッファのサイズを指示してもよい。
【００７７】
Ｓｐａｃｅ：
Ｓｐａｃｅ（スペース）は、名前又は座標（任意のシステムの）によるものである。当然、形式は、ユーザが定義できるものでなければならない。ポイントのリストは、線、面積又は体積を定義することができる。名前の参照は、「ロスアンジェルス」、「パリ」、又は「ホンコン」のようなものを含んでもよいが、それらの物理的な境界を表わす座標によりこれらを定義してもよい。
【００７８】
ここでは、位置及び配向といったグループトリプレットにおいて６つの自由度を含む空間関係が定義される。スペース又は空間距離に対する参照は、このエレメントのドメインである。位置、測定、表面積、及び体積。
【００７９】
このデータに対する容器は、記述的参照（名前のような）及び詳細参照（座標）をサポートしなければならない。我々は三次元ユニバースに住んでいるので、座標の値の最小数は、３つの値であり、その各々は、それ自身の定義可能なデータ形式を有していなければならない。
【００８０】
３つのポイントだけで、あるポイントが定義されるが、ポイントは、別のトリプレットを構成するヨー、ピッチ及びロールを含む他の属性を有する。各用途が、両情報セットを必要とするのではないから、グループを、３つの値の１セットと、それらに関連したデータ形式（融通性のために番号又はストリングでよい）に限定する。
【００８１】
全ての参照は、他の何かに対するものであると考えられる。技術的に、「絶対」アドレスのようなものはない。参照された座標システムが回転する（惑星のように）場合には、座標も回転する（参照モーションを使用して）。
【００８２】
この場合には、任意の座標（３つの値の対）、別のファクタ、及び参照位置へ入る。想像上の世界では、これは、形成も定義も必要としないが、実際の世界では、他の空間座標が参照フレームを要求する。参照フレームは、３つの値の同じ対（６つの自由度）及びそれらに関連したユーザ定義可能なデータ形式を使用することになる。
【００８３】
記述的ストリング（「ロスアンジェルス」のような）を除いて、空間的値の最も基本的な構造は、３つの値（番号フォーマットの）及びそれらのユーザ定義可能なデータ形式（おそらくストリングでよい）である。
【００８４】
もちろん、何かを定義するのに各値を使用する必要はない。距離は、３つのうちの１つを使用するだけである。面積は、３つのうちの２つを含むことができる（高さと巾のような）。
【００８５】
Ｅｎｅｒｇｙ：
Ｓｐａｃｅ（スペース）は、位置であるが、Ｅｎｅｒｇｙは、Ｓｐａｃｅ内のモーションを表わす。力は、ベクトル化されたエネルギーである。これは、フロー、分散又は峰(Ridge)でよい。フローとしての運動であるときには、共通点からの力の分散として爆発を表現してもよい。換言すれば、全てのベクトルは、共通点（スペースとして更に定義することができる）から発散する。内破は、単に、これらのフローの収斂である。
【００８６】
Ｅｎｅｒｇｙの定義は、記述的名前又は参照座標に関してはＳｐａｃｅと同様である。モーションの空間的定義をここで定義する。位置に対する座標及び配向に対する角度を有するのと同様に、エネルギーも座標を有するが、これらはベクトルである。角度の値は、固定の配向ではなく回転に対するものである。
【００８７】
このエレメントにおいて、直線的速度、拡張又は方向が考えられる。ある時間にわたって別の速度に適用される速度である加速度は、単に、時間エレメントを含む同様のエレメントの別のリンクである。
【００８８】
従って、エネルギーは、速度及び力（ベクトル及び角度）に関してスペース（座標及び配向）に対して使用する同じトリプレットで構成されるが、モーションベクトルを、力自体とは個別のものとして考えることを希望してもよい。
【００８９】
もちろん、エネルギーはフローであり、そしてフローは、フロー、分散、又はフローの峰形態を含む幾つかの特性を有する。これらは、フローを適切に定義するためにエレメント構造に含まれねばならない。
【００９０】
Ｅｎｅｒｇｙは、それが何であると考えるかについて厳密に定義されないが、種々の形態を有することに注意するのが重要である。例えば、マネーは、エネルギーの一形態、即ち凝固された形態である。一週間働くこと（Ｅｎｅｒｇｙを使用するＤｏｉｎｇｎｅｓｓ）は、マネーと称する凝固された非流動形態に変換される。次いで、エネルギーのこの固体形態を、何か（車のガソリンのような）を購入してそれを再び作用させることにより、フローに変換して戻すように判断することができる。従って、ここでは、全ての会計が容易に適合する。
【００９１】
Ｅｎｅｒｇｙは、ある場所から別の場所へ流れる。「から」及び「へ」を使用することにより（構造上のフラグ又はベクトルに対する正／負の値として）、ある口座から別の口座への資金のフローを示すこともできる（口座は、もちろん、抽象的認識、即ちＢｅｉｎｇｎｅｓｓである）。
【００９２】
Ｔｉｍｅ：
Ｔｉｍｅ（時間）記憶は、いかなる形式のデータも（完全に又は部分的に）記憶するに充分なほど融通性がなければならない。Ｓｐａｃｅと同様に、名前又は時間それ自体により参照されてもよい。例えば、「ジュラ紀」、「ローマ時代」、「中世紀」は、全て、有効な時間参照である。
【００９３】
カレンダーは、同じでない。中国及びマヤのカレンダーを含む多数が存在するが、月や火星のようなものへマップするための将来のカレンダーも有する。
【００９４】
理想的な時間容器は、ユーザが、不完全な時間参照、及び単位又はデータ形式に対するそれら自身の定義を提示するのを許すものである。一般的に述べると、テキストストリングは、マップアウトされるときに、非常に良好に作用する。
【００９５】
又、もちろん、日、月、年、時、分及び秒（又はその任意の一部分）により時間を数値的に参照することもできる。理想的には、物理的構造は、これをサポートするものでなければならない。又、部分的データが存在するときにはそれを除去してはならない。例えば、月は分かるが日は分からない場合に、月の部分だけを記憶してもよい。何１０年代かは分かるが、厳密な年が分からない場合には、その時間成分を記憶することが許されねばならない。
【００９６】
Ｔｉｍｅは、幾つかのファクタ、即ち１）開始時間、２）期間、及び３）終了時間で構成される。通常、これら既知のファクタの少なくとも１つを有する（完全又は部分的に）。それらの２つを有する（完全に）場合には、第３のものを計算することができ、単に、将来の問合せにおける補助として含まれてもよい。しかし、データを、個人が有する程度に含ませるだけである。これは、エレメントに別のトリプレットとして記憶されてもよいし、或いは分離されてどの形式（開始又は変更／期間又は停止）かの指示子で識別されて記憶されてもよい。
【００９７】
もちろん、Ｔｉｍｅは、ユーザ定義可能である。これは、ある設計作用を生じさせるが、誰もが同じ時間参照を使用するのでないから、非常に価値のある努力である。地質学者の単位は、百万年であり、一方、核物理学者の単位は、１０億分の１秒である。
【００９８】
ここから、おそらく、潜在的な名前ストリング（例えば、「中世紀」）を含むか又はそれと結合された（重畳する）開始時間、持続期間、終了時間を含む簡単な構造を導出することができる。もちろん、各データ形式は、ユーザ定義型であると共に、ある値が不完全なことがあるというものである。不完全な時間は、例えば、１９８０年代に何かが起きたことは知っているが、厳密に何年か分からないというものである。明らかに、厳密に分からない場合に、厳密な値をシステムに入力することは望まない。これに対する１つの解決策は、これらの値をストリングとして記憶することである（例えば、「１９８＿」、省略された数字は、未知の年を表わす）。このように、１９８０年又は１９８４年に起きた何かをサーチして、対戦結果を見つけることができる（省略されたフィールドは、試合と考えられるので）。しかし、これは、不完全な時間データをいかに利用できるかを表わす多数の潜在的な解決策の１つである。
【００９９】
任意の形式のデータを表わす言語、ツール及び方法は非常に多数あるので、各フィールドの厳密な仕様及びエレメントのデータ形式を定義することは、本発明の目的ではない。これらの定義は、特定の実施形態に委ねるが、それらを使用のためにいかに定義できるかの例をここに説明する。
【０１００】
図１は、コアエレメントをノードとして示す。「エレメント」という語は、データベーステーブルの論理的記述を表わすのに使用され、一方、「ノード」は、データベーステーブルの物理的記述を表わすのに使用される。コンテンツのアクティブなテーブルについては、これは、本発明の範囲を越えるもので、本発明の応用に依存する。しかしながら、説明上、図１−７を参照すれば、一次の６個のコアノードには、次の参照番号が指定される。この図において、そして図面全体にわたり、全てのノードには、次の番号付け規定で１桁の番号が指定される。即ち、Ｂｅｉｎｇｎｅｓｓ又はＢｅには、参照番号１が、Ｄｏｉｎｇｎｅｓｓ又はＤｏには、参照番号２が、Ｈａｖｉｎｇｎｅｓｓ又はＨａｖｅには、参照番号３が、Ｓｐａｃｅには、参照番号４が、Ｅｎｅｒｇｙには、参照番号５が、そしてＴｉｍｅには、参照番号６が指定される。参照番号９は、一般に、ノード又はエレメントのいずれかを表わすのに使用される。
【０１０１】
図２を参照すれば、一次の６つのＢＤＨ−ＳＥＴノードの各々に対する接続、リンク又は論理的なフローが示されている。各ノードが各々のノード（それ自体、即ち以下に「フローゼロ」と識別されるものを含む）に接続されることに注意されたい。このようなフロー又はリンクに対する番号参照呼称は、ここでは、エレメント又はノードにより別のエレメント又はノードに対して論理的表示で呼称される。単一桁のエレメント／ノード参照番号（１−６）は、２桁の番号にするために、常に、第１桁の後方にゼロ（０）が詰め込まれたものとなる。図２の論理図では、第１及び第２のエレメント又はノードが相互接続されるときに、第２エレメント又はノードは、先導するゼロの後方の最後の桁となり、従って、ノード１及び２（Ｂｅｉｎｇｎｅｓｓ及びＤｏｉｎｇｎｅｓｓ）は、リンケージを１００２として示す。従って、Ｂｅエレメント又はノード１と、Ｓｐａｃｅエレメント又はノード４との間の接続線は、次のようになる。Ｂｅ１からＳｐａｃｅ４へ：１００４。Ｄｏ２とＳｐａｃｅ４との間の接続線は、２００４として表わされ、等々となる。残りのリンケージは、低い番号が高い番号の前に表わされるというこの番号付け規定に従う。
【０１０２】
リンクノード
１つのデータムはそれ自体意味のないものである。これは、同等の大きさの別のデータムと比較することでしか評価できない。これは、リンクノード及びリンク−リンクノードにより確立される関係の目的である。
【０１０３】
本発明のシステムの基本的な簡単さは、２つの形式の接続しか使用しないことである。ノード対リンクノード、及びリンクノード対リンクノードが、図３及び４に示されている。これらの接続は、全システムを形成するのに使用される。
【０１０４】
図３Ａを参照すれば、ノード間、ノードとリンクノードとの間、及びリンクノード間の論理的及び物理的接続又はリンクが示されている。ノード自体は単一桁の番号であるが、これらノード間のリンクノードは、それらが接続するノードの番号により識別され、従って、２桁の番号を形成する。例えば、ノード４（Ｈａｖｉｎｇｎｅｓｓ）とノード５（Ｓｐａｃｅ）との間のリンクは、リンク４００５として識別されるが、ノード４と５との間のリンクノードは、リンクノード４５として識別される。他の全てのリンクノードは、それらが接続するノードに対して同じ番号付け規定を使用する。
【０１０５】
更に、ノードは、リンクノードに物理的にアタッチされ、次いで、他のノードにアタッチされ、従って、物理的な接続は、単にノードからノードへのものではなく、むしろ、ノードからリンクノードへ、次いで、他のノードへというものである。従って、ノードとその相互接続リンクノードとの間の接続は、ノードリンク規定と同様に識別され、即ちこれは４桁番号である。リンク１００２がノード１をノード２に接続する（それらの間に暗示的リンクノード１２がある状態で）のと同様に、リンク１０１２がノード１をリンクノード１２に接続する（これは、別のリンク２０１２を使用してノード２へ接続する）。規定により、ノードは、単一桁とそれに続くゼロ（２桁を埋める）として識別され、一方、リンクノード（既に２桁）は、後でリストされる。例えば、ノード４とリンクノード４６との間のリンクは、リンク４０４６として識別される。他の全てのノード対リンクノード接続も、この規定に従う。
【０１０６】
図３Ｂは、更に、ノードを、他の２つのノード間のリンクノードに接続できることを示している。これは、「フロー３」と称される（これは、以下に詳細に説明する）。この接続は、５桁の番号を使用して表示される。別の接続のリンクノードに接続されたノードの高いレベルから、最初の桁は、３つのゼロが詰め込まれて、ノードを表わし、そして最後の２桁は、他のノード間のリンクノード番号を表わす。例えば、ノード１からリンクノード４６（ノード４と６との間）への「フロー３」接続は、リンク１００４６となる。ノード３とリンクノード２５との間の接続は、リンク３００２５となる。規定により、ノードが常に最初に来て、番号は常に増加順となる（即ち、２が５の前）。
【０１０７】
更に、このノードは、２つの他のノードを接続しているリンクノードに接続されるが、技術的に、ノードをリンクノードにリンクするための別のリンクノードが必要になる。この形式のリンクノードは、「リンク−リンクノード」（「フロー３」接続）と称される。このリンク−リンクノードへの又はリンク−リンクノードからの全てのリンクは、５桁の番号である。
【０１０８】
ノードは、「リンク−リンクノード」と称されるものによりリンクノードに接続される。既に確立された規定に従い、このリンク−リンクノードは、それがアタッチするコンポーネント、即ち一端のノード及び他端のリンクノード、の番号を受け取る。ノードは１桁でありそしてリンクノードは２桁であるから、３桁の識別子を有するリンク−リンクノードが生じる。例えば、ノード４及びリンクノード１３を接続するリンク−リンクノードは、リンク−リンクノード４１３である（規定により、ノードは、常に、リンクノードに先行する）。
【０１０９】
リンク−リンクノードへの接続は、ノードとリンク−リンクノードとの間の接続、並びにリンク−リンクノードとリンクノードとの間の接続を形成するので、これらの接続は、５桁の番号で表わされる。例えば、ノード３とリンクノード４５との間の接続は、ノードとリンク−リンクノードとの間にリンク３０３４５を生じると共に、リンクノードとリンク−リンクノードとの間にリンク４５３４５を生じさせる。規定では、ノード（末尾にゼロが埋め込まれる）又はリンクノードが最初の２桁を表わし、そしてリンク−リンクノードが残りの３つとなる。
【０１１０】
図４は、このシステムを構築するのに必要な全ての接続を示す。図４Ａにおいて、全てのノードは、ノード又はリンクノードのいずれかにアタッチすることができ、そして図４Ｂにおいて、全てのリンクノードは、ノード又は別のリンクノード（技術的には「リンク−リンクノード」）に接続することができる。一般に、これら２つの接続を最適化すると、システムが最適化される。
【０１１１】
データを記憶する一次ノードは、値及びデータ形式と時々称される異なる特定の特性（ＢＤＨ−ＳＥＴ）を表わすが、リンクノードは、識別と、リンクノードが接続する２つのノードに関するデータとが指定される。
【０１１２】
データを記憶する一次ノードは、値又はデータ形式と時々称される異なる特定の特性（ＢＤＨ−ＳＥＴ）を表わすが、リンクノードは、識別と、リンクノードが接続する２つのノードに関するデータとが指定される。
【０１１３】
図５は、図３Ａに示された接続形式を使用する全てのノード及びリンクノード接続の適用を示す。これは、全てのノードがリンクノードを経て他の全てのノードに接続されるところを示す。又、各ノードは、この図に示されるように、それ自身へのリンクノードを使用してそれ自身にもリンクされることにも注意されたい。
【０１１４】
全てのノードが他のノードにアタッチされると共に、これらノード間の全てのリンクノードにもアタッチされるので、図６は、単一のノードから行うことのできる全ての考えられる接続を示し、ここでは、このシステムの全てのリンクノード及びリンク−リンクノードに接続されるノード１により例示される。しかしながら、残りの一次ノード２−６も、上述したリンク形式に対する説明に基づき、リンクノードだけではなく全てのリンク−リンクノードへの同様の接続及びリンクを有する。これらは、図３Ａ及び３Ｂに示されたように、ノード及びリンクノードの全ての接続を表わす。この範例では、リンクノード及びリンク−リンクノードには、その識別と、非自己ノードを「他」のノードに接続するノード及びリンクノードに関するデータとが指定される。このような接続が図４Ｂに示されており、ここでは、リンクノード（参照番号９９で示す）が別のリンクノード（これも参照番号９９で一般に示す）にリンクされ又は接続されている。
【０１１５】
フロー
あるデータムから別のデータムへの関係は、４つの形式がある。これらは、０から３と番号付けされた「フロー」と称される。全てのリンクは、両方向である。
【０１１６】
フロー１は、図７Ａに示す「自己から他」である。これは、参照エレメントと何らかの他のエレメントとの間のリンクである。これは、本質的に、ソース参照を使用する他のエレメントへの「流出」形式の参照である。
【０１１７】
フロー１は、他のデータのサーチにおけるスタート点として使用でき、又はターゲット（他）が初期参照（自己）より関心が高い場合に初期参照（自己）を越えてデータのチェーンをたどるのに使用できる。関心は、参照（自己）を越える。
【０１１８】
フロー２は、図７Ｂに示された「他から自己」である。これは、別のエレメントと参照エレメントとの間のリンクである。これは、本質的に、「外部情報をそれ自身へ引っ張る」等のソース参照を使用する他のエレメントからの「流入」形式の参照である。
【０１１９】
フロー２は、他の既知のデータを使用して未知の自己を見出すか、又は他の経路を「サーチ」しない間に既知の参照（自己）に関する情報を収集するのに使用できる。通常、参照（自己）は、他の情報より関心が高い。関心は、参照（自己）に集中される。
【０１２０】
フロー３は、図７Ｃに示す「他から他」である。これは、エレメントと、他の２つのエレメントの関連性との間のリンクである。これは、一般に、他の２つのエレメント間の関係に対するある参照エレメント関連性を決定するのに使用される。この関係で多数のことを行い得るので、これについて以下で詳細に説明する。
【０１２１】
フロー０は、図７Ｄに示す「自己から自己」である。これは、自己への参照エレメントのリンクである。これは、一般に、情報のチェーン、或いはセットの年長性又はグループのような関係を決定するのに使用される。
【０１２２】
これら４つのフローは、任意のエレメントを別のエレメント（自己を含む）に関連付ける主たる方法である。
【０１２３】
図２は、論理的なフロー１及び２が一次の（６個の）エレメントに対していかに表わされるかを示す。図６は、フロー０、１及び２を含むように説明される６エレメントモデルに対する物理的表示である。
【０１２４】
しかしながら、フロー３は、ノードからいかなるリンクノードへも行うことのできる全ての接続を基本的に表わすので、表示が厄介である（コア６エレメントについても）。６ノードモデルの単一ノードでも、かなり複雑に見える。図示を簡単化しそして全てのフロー３接続を示すために、それらが層に分割されている。一次の６エレメント形態に対する層は、図８Ａから８Ｄにおいて分割されている。
【０１２５】
ロジック
以前のデータベースモデルの欠点は、任意のデータムと別のデータムとの３つの論理的関係を意味する完全な「論理的関連性」ではない関連性に基づいてデータをリンクする傾向があることである。
【０１２６】
このモデルは、全てのデータ関係にロジックが含まれることを要求する。
【０１２７】
ロジック自体により定義される関係には３つの形式がある。これらの関係は、次の通りである。
１）同一：これは、２つのデータムが互いに同じと考えられることを意味する。
２）類似：これは、２つのデータムが同一でも相違でもなく、何らかの仕方で関連することにより類似していることを意味する。
３）相違：これは、２つのデータムが同一でもなく何らかの仕方で類似もしていないと考えられることを意味する。
【０１２８】
ほとんどのデータベースは、同一又は類似のいずれかであり、相違であることは滅多にない関係を定義する。関係の正確な性質は、設計者によってほとんど決められる。このモデルでは、この情報が用途に委ねられず、データ構造内に明確に定義される。ここから、２つのデータム間の論理的な関係を導出する。
【０１２９】
全ての形式のデータ（物理的ワールド及び仮想的ユニバースにおける）と、本発明のユニバーサルデータベースシステムにより達成しなければならない全ての要求とに適合するために、若干の抽象的エレメントが追加された。即ち、参照ノード番号７が指定されたＱｕａｎｔａ、及び参照ノード番号８が指定されたＭｏｄｉｆｉｅｒのノードである。図９に示すこれら８個の一次ノードは、図１０−１２に示すように、当該リンク及びリンクノードを伴い、不変のユニバーサルデータベースモデル及びシステムを形成する。
【０１３０】
図９−１２における参照番号付けについては、上述した同じ規定が使用される。即ち、Ｑｕａｎｔａエレメント又はノードには、参照番号７が指定されたが、Ｂｅ−Ｑｕａｎｔａリンクノードには、参照番号１７が指定される。同様に、Ｍｏｄｉｆｉｅｒエレメント又はノードには参照番号８が指定され、そしてＤｏ−Ｍｏｄｉｆｉｅｒリンクノードには、参照番号２８が指定される。接続又はリンクは、上述したように、下位の番号のノード又はリンクノードが最初にリストされ、そして上位桁のノード又はリンクノードが最後にリストされ、ノードを参照する場合には、上述したように、番号に少なくとも１つのゼロを埋め込む。例えば、Ｑｕａｎｔａ（ノード７）と、Ｓｐａｃｅ−Ｔｉｍｅリンク（リンクノード４６）との間の接続線は、７０４６である。
【０１３１】
一次ノード１−８の相互接続が図１０に示されており、一次ノード間にフロー１及び２が示されている。図１１は、８個の一次ノードのフロー０、１及び２を示している。図１２Ａ−Ｅは、各々、８個のノードのフロー３の層１−５を示している。
【０１３２】
Ｑｕａｎｔａ
Ｑｕａｎｔａ（クオンタ）は、図１３Ａ−Ｄに示すように、３つの形態、（Ａ）定数、（Ｂ）変数、及び（Ｃ）方程式をとる。
【０１３３】
定数は、既知の数値又は値である。これは、マス(mass)又はカウントが明確に分かる場合にはＨａｖｉｎｇｎｅｓｓのマス又はカウントのような既知の量を記憶するのに使用される。
【０１３４】
変数は、値又はコンテンツが分からない場合のプレースホルダーである。これは、代数及び他の上位数学の基礎である。
【０１３５】
方程式は、他のものに対する任意のＱｕａｎｔａの値又は関連性を定義する式のより複雑なセットである。その一例は、Ｅ＝ＭＣ＾２であり、ここで、エレメントは「Ｅ」（変数）を含み、これは、「Ｍ」（変数）及び「Ｃ」（変数）を含むエレメントに更にリンクされ、これは、既知の定数値「２」を表わすパワーとして定義された定数にリンクされる。
【０１３６】
このような記憶方法を使用すると、標準的なエレメント関係を再使用して、値が既に解かれた経路を見出すことにより上位の数学方程式を解くことのできる数学的コンピュータを更に開発することができる。
【０１３７】
このエレメントに対して若干の使い方をリストするだけとする。
【０１３８】
定数として、Ｈａｖｉｎｇｎｅｓｓに関連して、カウント、マス、重み等に対してそれを使用することができる。Ｓｐａｃｅに関連して、長さ、面積又は体積に対してそれを使用することができる。Ｅｎｅｒｇｙに関連して、そのエレメントに記憶されたオリジナルエネルギーと共に含むための何かとして合成された値となる。
【０１３９】
変数として、Ｄｏｉｎｇｎｅｓｓに対し、アクション又は速度の未知の割合となる。Ｈａｖｉｎｇｎｅｓｓに対して、未知の量又はマスを再び考える。Ｓｐａｃｅに対して、値が未知であるときに、物の直線距離、面積及び体積を再び有する。
【０１４０】
方程式として、１つ以上の値が未知であるものを含む任意の形式の数学式を表わすことができる。幾つかのサンプルは、次の通りである。
Ｅ＝Ｍ＊Ｃ2
Ｆ＝Ｍ＊Ａ
Ａ＝Ｖ＊Ｔ
Ｖ＝Ｓ＊Ｔ
【０１４１】
上記リストにおいて、Ａは方程式から定義され、そして上記第２の式においてＡの値が分からない場合でも、それを得ることができる。というのは、（この説明上）解答できる別の方程式の出力としてもリンクされるからである。
【０１４２】
もちろん、次のものを含むという効果のある数学上使用される共通の関数があるので、変数に限定されない。
Ｓｕｍ（）
Ｃｎｔ（）
Ｍａｘ（）
Ｍｉｎ（）
Ｓｉｎｅ（）
Ｃｏｓｉｎｅ（）
Ｔａｎｇｅｎｔ（）
ＡｒｃＴａｎ（）
Ｌｏｇｉｒｉｔｈｍ（）
【０１４３】
通常、関数は、予め定義されたパラメータに適用され、これらパラメータは、関数定義にリストされたように、パラメータ形式を指示するリンクと共に関数ノードにリンクされる。適切に指定されると（方程式が他の方程式におけるそれらの参照にリンクされた状態で）、人為的技術を使用して既存の式から新たな方程式又は解を導出することができる。少なくとも、これは、この技術による暗黙の能力である。
【０１４４】
ここでも、このようなエレメントをいかに形成するかの例に戻る。厳密な数値のフィールドの場合に、数値データ形式を定義するだけであるので容易である。しかしながら、これは、非常に多形性の形式であるので、ストリングからの何かを使用してこれを、定義された形式（定数、変数、方程式又は関数）を使用する他のオブジェクト指向の構造へと構成することができる。ストリングは、エンジンにより単にパーズされるが、オブジェクト値は、それら自身の戻された結果に対して直接コールされる。データ形式は、ストリング又は他の指示子のように、ユーザ定義可能でなければならない。
【０１４５】
Ｍｏｄｉｆｉｅｒ
Ｍｏｄｉｆｉｅｒ（モディファイヤ）は、何かの属性を定義するのに使用される。犯罪シーンを調査する場合には（上記Ｂｅｉｎｇｎｅｓｓで述べたように）、誰かの記述（白人、男性、青い目、茶髪、等）を含むものを収集する。共通データの充分に大きな収集から、逃亡者を分離し、最終的に探索することができる。この例が、被疑者の名前をまだもたないと仮定して、図２２Ａに示されている。
【０１４６】
ほとんどの部分に対して、これは、形容詞（Ｂｅｉｎｇｎｅｓｓ、Ｈａｖｉｎｇｎｅｓｓ、Ｓｐａｃｅ、Ｅｎｅｒｇｙ、Ｔｉｍｅ）と考えられるが、Ｄｏｉｎｇｎｅｓｓについては、副詞と称される。（共通のモディファイヤをエレメントに結合し、Ｍｏｄｉｆｉｅｒを得ると共に、Ｍｏｄｉｆｉｅｒそれ自体をサーチ可能なエレメントにする。
【０１４７】
Ｍｏｄｉｆｉｅｒは、おそらく、構造に関して考慮するのが最も容易である。これは、記述としては、通常、何らかの言語で何かを記述するのに使用されるテキストである。このエレメントに対する構造は、このストリング、及びそのユーザ定義されたデータ形式をサポートしなければならない。
【０１４８】
構造及びデータベースエンジン
簡単化（ＮＬＮ、ＮＬＬ）
ほとんどのデータベースエンジンは、未知の標準的なテーブル構造に依存し、結局、いかなる開発者も、それら自身のテーブル及び機構を設計できるようにすることが予想される。独特のエレメントは僅かしかなく、それらは既知であるから、このようなシステムは、著しい努力を伴わずに設計及び構築でき、且つ動的テーブル又は機構で可能であるものを越えて、非常に最適化できると共に、おそらく、各々が独特の構造及び関係をもつ不可能なほど多数のテーブルに依存するシステムよりも遥かに効率的なものとなる。
【０１４９】
このシステムが基本的に簡単であるのは、図４に示すように、Ａ）ノードからリンクノード（ＮＬＮ）、及びＢ）リンクノードからリンクノード（ＮＬＬ）、の２つの形式の接続しか使用しないことである。これから、他の全てのものを構築することができ、これは、今日使用されているより複雑な解決策のコアシステム設計に比して遥かに簡単である。
【０１５０】
この技術を、８本の線を有するシリコンチップのようなハードウェア形態へと開発することができる。各線は、エレメントを指示する。線のいずれか１つ又は線のいずれかの組み合わせからの信号は、リンクノード又はリンク−リンクノードが指示される（以下のテーブルから）ところの特定のノードから何かを指示する。リードにおける信号の結果を使用して処理を指令することもできるし、或いはサーチ結果又はノード／リンクノード／リンク−リンクノードのアドレスを処理し又はそれにアクセスすることもできる。この標準的なモデルにより多数のより潜在的な使用をなすことができる。これら８個のエレメントが既知の形式の情報を包含すること、及びこれが２進数で行われることにより、これが非常に効率的なものとなる。
【０１５１】
信号発生器又はスイッチとして、この形式のハードウェアは、ＣＰＵが標準的なコンピュータにおいて行うのと同様の大量の外部データを容易に導出することができる。データのインテリジェントブリッジ及びディレクタとして、これは、分析プロセッサの非常に効率的な形態である。
【０１５２】
このようなチップの１つのバージョンは、どのエレメント、リンクノード又はリンク−リンクノードがアクションをとるべきかを解釈し又は参照するのに使用できる。その別のバージョンは、単に、サーチで一致をとるのに使用される２進信号のような結果の指示でよい。或いは、どの方向に進行すべきか指示するネットワークプロセスディレクタでもよい。
【０１５３】
このモデルは、多数の埋め込み型ハードウェア解決策をサポートする。又、これらの形式の解決策（上述した）は、ソフトウェア解決策としても機能し、ここで、ソフトウェアは、上述した機能を表わす。
【０１５４】
ノードマトリクス
上述した図に示したように、ノードそれ自体は、他の各々のノード（それ自体を含む）にリンクされる。従って、モデルの各ノードに対して、システム内の他の各ノード（それ自体を含む）によりそのノードへの接続が生じる。
【０１５５】
リンクノード（ＬＮ）マトリクス
ノードそれ自身は、他の各ノード（それ自体を含む）にリンクされる。従って、モデルの各ノードに対して、システム内の他の各ノードによりそのノードへの接続が生じる。
【０１５６】
このマトリクスは、これに似たものとなる（番号ではなくノード文字を使用する）。
テーブル１．１  ノード対リンクノードマトリクス（ノード文字による）
2006053934.tif 000003
【０１５７】
省略は、単に、既存のものの重複である。技術的に、ＢＴ及びＴＢは同じ接続であるが、これらは、上述したようにシーケンスプライオリティにおいて共通に参照される。このルールに適合するための制約は、実施上の問題であり、参照を再順序付けする能力をユーザに許可するかどうか決定することは、実施者に委ねる。
【０１５８】
それ自身を参照するノード（例えば、ＢＢ、ＤＤ、ＨＨ等）は、フロー０接続であり、一方、他のものは、フロー１又はフロー２接続である。
【０１５９】
リンク−リンクノード（ＬＬＮ）マトリクス
フロー３を形成するために、各ノードを、他の２つのノード（それ自身を含まない。というのは、これは、別のフローリンクノード接続により達成できるからである）を接続するリンクノードにもアタッチしなければならない。
【０１６０】
これに対するマトリクスは複雑である。各ノードに対して、テーブル１．１にリストされたリンクノードの１つへの接続がある。一次エレメント（最初の６つ）のみに対して、複雑なシステムと思われるもの、及び８ノードシステムに対してより複雑なもの、を形成する。
【０１６１】
システム全体に対するリンク−リンクノードのリストを以下に示す。
【０１６２】
テーブル３．１  Beingnessに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000004
【０１６３】
テーブル３．２  Doingnessに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000005
【０１６４】
テーブル３．３  Havingnessに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000006
【０１６５】
テーブル３．４  Space対するノード対リンク−リンクノードマトリクス
2006053934.tif 000007
【０１６６】
テーブル３．５  Energyに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000008
【０１６７】
テーブル３．６  Timeに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000009
【０１６８】
テーブル３．７  Quantaに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000010
【０１６９】
テーブル３．８  Modifierに対するノード対リンク−リンクノードマトリクス
2006053934.tif 000011
注：アスタリスク（＊）は、存在し得るが既に他のフローリンクとして実行する暗黙のフロー３リンク−リンクノードを表わす。
【０１７０】
アスタリスクで示すように、考えられるリンク−リンクノード関連性の幾つかは、他のフロー接続に既に存在する。既に存在するリンクノードへの別の接続をもつ必要があることは起こり得ないが、除外されることでもない。
【０１７１】
これは、（いずれかの上記テーブルで表わされたように）各ノードセットに対するノードの数だけＬＬＮカウントを減少する。
【０１７２】
テーブル４．１  アイテムカウント
2006053934.tif 000012
【０１７３】
これは大きな数のように思われるが、これは、本質的に境界をもたないシステムシステムを実行するのに必要な全体的な限界であることに留意しなければならない。この数と同程度のものが最初に考えられるが、何が実行できるかに比して依然として小さなものである。幾つかの能力を簡単に要約するために、以下の例について説明する。
【０１７４】
合併の最適化
現在のデータベース設計に伴う問題の１つは、合併に対して弱いことである。ＳＱＬ言語は、誰かが複雑な合併を試みるのを思いとどませる傾向がある。これに伴う問題は、データの合併は、ユニバースが最良に行う１つのもので、ユニバースの能力又はコンテンツを複写できるとそれ自身考えることを望むデータベースにおいてそれも表示しなければならないことである。この理由だけのために、この能力を最適化することが強く推奨される。このモデル設計が基本的に簡単であることを考慮すれば、これを達成できないと考える理由はない。又、ほとんどのデータベースエンジンは、本質的に、データベースのテーブルスペースの種々の位置に記憶されたデータをインデックスするので、全てのエレメント形式及び構造が定義されそして安定であるときには、最適化を行えない理由があってはならない。
【０１７５】
問合せ
シンタックス：問合せについての読者の理解を簡単にすると共に、主に関心のあるオブジェクトに焦点を置くために、本書では、標準的なＳＱＬシンタックスに対する記号の追加を使用する。ＳＱＬ言語は、若干制約があり、そしてこのシステムが要求する合併の形式及びこのモデルが暗示する他のものに対して確かに最適でない。
【０１７６】
エレメントの表示
エレメント自体は、次のように、それらの名前における最初の文字により識別される。Ｂ＝Ｂｅｉｎｇｎｅｓｓ、Ｄ＝Ｄｏｉｎｇｎｅｓｓ、Ｈ＝Ｈａｖｉｎｇｎｅｓｓ、Ｓ＝Ｓｐａｃｅ、Ｅ＝Ｅｎｅｒｇｙ、Ｔ＝ｔｉｍｅ、Ｑ＝Ｑｕａｎｔａ、Ｍ＝Ｍｏｄｉｆｉｅｒ。
【０１７７】
エレメント内のデータは、データ、次いで、データ形式の順序でカッコ内に表わされる。例えば、Ｂ（ジョー、個人）、又はＳ（ロスアンジェルス、都市）。
【０１７８】
この表示設計をエレメント自体に適用すると、次の表示の幾つかを得る。
「ｘ≡ｙ」（等価）これは、エレメントｘがエレメントｙにリンクされることを意味する。
「ｘ⊂ｙ」（サブセット）これは、エレメントｘがエレメントｙに対するサブセット（年少）であることを意味する。
「ｘ⊃ｙ」（スーパーセット）これは、エレメントｘがエレメントｙに対するスーパーセット（年長）であることを意味する。
「ｘ∪ｙ」（一体）これは、リンクされたエレメントｘ及びｙの組み合わせを意味する。
「ｘ∪」（単一テーブルで使用）これは、エレメントｘを通して「トンネルアップ」することを意味する（フロー０を参照）。
「ｘ∪（４）」これは、４つのレベルで「トンネルアップ」することを意味する。これは、任意の整数値でよい。
「ｘ∪！」これは、考えられる最高レベル、即ち最も上位のレベルへの「トンネルアップ」を意味する。
「ｘ∩ｙ」（交差）これは、リンクされたエレメントｘ及びｙの交差を意味する。
「ｘ∩」（単一テーブルで使用）これは、エレメントｘを通して「トンネルダウン」することを意味する（フロー０を参照）。
「ｘ∩（３）」これは、３つのレベルで「トンネルダウン」することを意味する。これは、任意の整数値でよい。
「ｘ∩！」これは、考えられる最低レベル、即ち最も下位のレベルへの「トンネルダウン」を意味する。
【０１７９】
次のＳＱＬ言語又はシンタックスは、上記例示的目的で設けられたものであるが、当業者であれば、他のソフトウェアコード又はシンタックスも使用できることが容易に理解されよう。例えば、ＸＭＬコードを使用して、上述した機能でノード及びデータを記述することができる。ＸＱｕｅｒｙのような他の言語も使用できる。実際に、全ての言語は、物理的ユニバース又は概念の表示であり、そしてこのモデルは、ユニバースにおける何かをサポートするので、いかなる言語（マシン、人間又はその他）もサポートできる。
【０１８０】
リンク表示
リンクノードは、それらが接続する２つのエレメントにより識別されるという点でエレメントと同様に表わされる。例えば、Ｂｅｉｎｇｎｅｓｓ−Ｈａｖｉｎｇｎｅｓｓリンクノードは、「ＢＨ」として識別され、或いはＳｐａｃｅ−Ｔｉｍｅリンクノードは、「ＳＴ」として識別される。規定により、文字の順序は、常に、本書においてエレメントが最初に定義されたのと同じ順序である。
【０１８１】
もちろん、リンクノード内のデータは、エレメントのデータとは異なり、従って、かっこは、この関係に特有のデータを含む。これは、論理的関係を含むと共に、片側で「従業員」そして他側で「雇い主」のようなリンクノードから各々の方向に特有の関連性を含むことになる。リンクノードに対する標準的な表示は、リンクノード自体内で定義される何かをそのかっこ内に入れることである。
【０１８２】
同一
「＝」（等号）この記号は、この記号の各側に表わされる２つのデータム又は他のリンクノードが互いに同一であると考えられることを意味する。
相違
「！」（感嘆符）この記号は、この記号の各側に表わされる２つのデータム又は他のリンクノードが互いに異なると考えられることを意味する。
類似
何かが類似していることを表わす仕方は多数あり、最も一般的なものは、次の通りである。
「〜」（ティルデ）この記号は、２つのデータムが非特定の仕方で互いに同様であることを意味する。
「＞」（より大きい）この記号は、２つのデータムが互いに同様で、左側のデータムが右側のデータムより大きいと考えられることを意味する。
「＜」（より小さい）この記号は、２つのデータムが互いに同様で、左側のデータムが右側のデータムより小さいと考えられることを意味する。
「⊂」（サブセット）この記号は、左側のデータムが右側のデータムのサブセットであるという点で２つのデータムが同様であることを意味する。左側のデータムは、右側のデータムに対して年少であると考えられる。
「⊃」（サブセット）この記号は、左側のデータムが右側のデータムのスーパーセットである（又はそれを含む）という点で２つのデータムが同様であることを意味する。左側のデータムは、右側のデータムに対して年長であると考えられる。
「∪」（一体）この記号は、両方が何か共通のものに含まれるという点で２つのデータムが同様であることを意味する。これは、両方、そしておそらく他のものを１つのセットに含ませる。
「∩」（交差）この記号は、２つのデータムが何かの交差を表わすという点で同様であることを意味する。
「⇒」（右矢印）この記号は、シーケンス内の次のデータムに対するポインタを表わす。
2006053934.tif 000013
【０１８３】
ここでも、当業者に明らかなように、表示は、付加的な記号を含むことができる。（必要に応じて、上述したものとは完全に異なる記号）。これら記号及び表示は、例示のために設けられている。含むことのできる他の例は、「以上(greater than or equal to)」、「以下(less than or equal to)」、等でよい。
更に、エレメントの名前を使用して（各エレメント名の最初の文字からの単一キャラクタ形態で）、適用エレメントを指示する。エレメント内のデータムは、かっこ内の標準表示を次のように使用する。
ｘ（ｙ）これは、エレメントｘがデータムｙを含むことを意味し、但し、ｙは、通常、データ及び形式について記述される。又、ｘは、上記エレメント名からの最初の文字である。
【０１８４】
この形式の表示は、各リンクされたエレメントのエレメント名の最初の文字を使用してリンクノードへ拡張される。例えば、エレメントＢｅとＨａｖｅとの間のリンクは、「ＢＨ」として表わされる。
ｘ（ｙ＊ｚ）これは、エレメントｙとエレメントｚとの間のフローを含むリンクノードｘを意味する。
【０１８５】
全てのリンクは、それがリンクするエレメントにより識別される（例えば、Ｂｅ対Ｈａｖｅリンクは、「ＢＨ」と称される。）又、これらのリンクは、リンク名の後にかっこ内に含まれた属性も含む。参照は、次のものを含む多数の形式のデータムを含む。
・  第１エレメントの記録ＩＤ
・  第２エレメントの記録ＩＤ
・  第２エレメントに対する第１エレメントの関係
・  第１エレメントの関係形式
・  論理的関係記号
・  第１エレメントに対する第２エレメントの関係
・  第２エレメントの関係形式
【０１８６】
かっこ内のこれらいずれかに対する参照は、参照の必要性により決定されるもので、一方、記録ＩＤは、記録を関係付ける何らかの方法がないとリンクできないので、暗示される。参照が必要でない場合には、それを識別しなければならない（例えば、「ＢＨ（ｒｅｌ１、ｔｙｐｅ１,＜,ｔｙｐｅ２,ｒｅｌ２）」は、「ＢＨ（ｒｅｌ１,,＜,,ｒｅｌ２）」となり得る）。これら参照エレメントの順序、或いはカンマ分離又はパージングの要求を定義することは、本書の範囲内ではない。簡単化のために、このリンクを、ここでは、３パラメータリンクとして使用するだけとする。
【０１８７】
リンクノードは、数学的等価記号（“≡”即ち３本の水平なバー）を使用してリンクされて示され、但し、以下の例において、このリンクに先行するエレメントは、「第１」エレメントと考えられ、そしてリンクの後続エレメントは、「第２」エレメントと考えられる。
Ｂ（“ジョー”,個人）≡ＢＢ（従業員,⊂,雇い主）≡Ｂ（“ＡＢＣ”,会社）
【０１８８】
リンク−リンクノード
先に述べたように、リンク−リンクノードは、別のリンクノードを経てノードをリンクノードへ接続するリンクノードである。これは、図７Ｃに示すように、フロー３リンケージの技術的形態である。接続自体は、図３Ｂにおいて９００９９として論理的に表わされ、これは、文字通り、「リンクノード９９（一般的リンクノード）に接続されたノード９（一般的ノード）」を意味する。
【０１８９】
共通使用の例は、Ｔｉｍｅを、個人（Ｂｅ）が特定の位置（Ｓｐａｃｅ）にいた時点へリンクすることである。このため、リンク−リンクノードを「Ｔ−ＢＳ（）」と表わし、ここで、かっこ内のパラメータは、更に、当該関係（いかなるリンクノードについても同じ）を記述する。
【０１９０】
リンク−リンクノードは、２つのノード間で行うのと同様に、ノードをリンクノードにアタッチするリンクノードに過ぎないから、シンタックス（リンク−リンクノード名以外の）は、他のいずれのリンクノードについても同じとなる。
【０１９１】
サンプル問合せ
通常の問合せは、次のようなものである。
フロー１：我々のトラックがある全ての都市をリストする
Ｂｅ                Ｓｐａｃｅ
フロー２：シアトルにある我々のトラックを全部リストする
Ｓｐａｃｅ          Ｂｅ
「トラック」が「我々のもの」と仮定すると、上記から、次のように見える問合せとなる。
Ｆ１：
SELECT S (city) FROM Space, Be
WHERE S (city) ≡ B (truck);
Ｆ２：
SELECT B (truck) FROM Be, Space
WHERE B (truck) ≡ S (city);
AND S (city) = “Seattle”;
この最後の問合せに、よりコンパクトなシンタックスを使用すると、次のように見える。
SELECT B (, truck) FROM Space, Be
WHERE B (, truck) ≡ S (“Seattle”, city);
【０１９２】
記号は、「等価」記号であり、等号ではないことに注意されたい。上述したように、これは、これら２つのテーブルが、供給されるデータに基づいてリンクされるという表示である。このように選択した場合に、リンクノードを参照に挿入することにより、リンクを特定のロジック又は関係に制限することもできる。
【０１９３】
もちろん、これらのスクリプトは、少なくとも、ＳＱＬを知っている者にとって馴染み易いと思われるが、言語ルールのあるものは、冗長であり、新たなシンタックスでは不必要である。例えば、上記最後の問合せにおいて、ＦＲＯＭテーブルを定義する必要性は、既に知られているものの繰り返しとなることに気付く。というのは、Ｂ（）及びＳ（）がこれを既に示すからである。従って、言語を次のように変換できる。
SELECT B (, truck)
WHERE B (, truck) ≡ S (“Seattle”, city);
又は、更に、次のように変換できる。
SELECT B (, truck)
WHERE ≡ S (“Seattle”, city);
【０１９４】
これは、この問合せについて知ることが必要な全てのものを示している。もちろん、多数のソースからデータを検索する場合には、より包括的なスクリプトを使用することが望まれる。
【０１９５】
フロー０及びトンネリング
所有するトラックのリストを作成することを希望しそして「我々の会社」が「ＡＢＣ」である先の幾つかの例では、これは、フロー０オペレーション（Ｂｅ対Ｂｅ関係）となる。次のことを行ってもよい。
ＡＢＣ会社により所有される全てのトラックをリストする
Ｂｅ                            Ｂｅ
Ｆ０：（フローゼロ）
SELECT B (, truck)
WHERE ≡ BB (“asset” ⊂ “owner”) ≡ B (“ABC”, company);
他の例は、次の通りである。
会社ＡＢＣの全ての従業員をリストする
Ｂｅ            Ｂｅ
ケーキを焼くのに必要な全てのステップをリストする
Ｄｏ                        Ｄｏ
第１のものは、次のようになる。
SELECT B (, person)
WHERE ≡ BB (employee, ⊂, . employer) ≡ (“ABC”, company);
第２のものは、次のようになる。
SELECT D (, step)
WHERE ≡ DD (step, ⊂, action) ≡ D (“Bake a cake”, action);
【０１９６】
「トンネリング」は、単に、これらエレメントを経てデータをループさせる方法に対して創案された名前である。単一ノードトンネルの例は、ボックス内のボックス内のボックスであり、探しているアイテム１が見つかるまでフロー０を使用して「トンネル」ダウンすることができる。どれほどダウンするかは問題でなく、そこまでダウンできることが重要である。又、親、祖父母、等々へと同様に「トンネル」アップすることもできる。
【０１９７】
上記で開発されたシンタックスの幾つかは、エレメントをリストするところのトンネリングのために特に設計されたものであり、そして年少又は年長形式のエレメントに向かってプライオリティを表わす記号表示で、データム１に関心がもたれる。
私の最も古い身内は誰か？
所与の形式の全てのデータは、単一ノード内にあるので、関心のある記録を簡単に探索できず、又、既に有している記録と記録との間の接続を簡単に探せない理由はない。
【０１９８】
フロー３及びデータマイニング
リンクノードに接続できること、又は簡単なリンク操作以外のものが要求されることが明らかである。このフロー、即ち図７Ｃに示す「他から他」は、このフローをサポートするのに必要な物理的リンクの追加、即ち既存のフロー１、２又は０リンクノードのいずれかに任意のノードを接続する別のリンクノードを生じさせる。図８Ａ−８Ｄの一次エレメント、及び図１３Ａ−１３Ｅの８エレメントシステムに対して相互接続が示されている。このようなフローは、次の問合せステートメントに表わされる。
誰かがグループのメンバーであったのはいつか？
Ｂｅ  Ｂｅ                          Ｔｉｍｅ
例えば、
ジョーがＸＹＺ製材所の従業員であったのはいつか？
Ｂｅ１  Ｂｅ２                          Ｔｉｍｅ
これは、数学的には、次のように表わすことができる。
Ｔ＝Ｂ１⊂Ｂ２
現在のＳＱＬは、次のようになる：（この例のためにテーブルフィールドに関する仮定をし、そして表現を簡単化するためにシンタックスに対する許容範囲を形成する）。
SELECT T.* FROM Time AS T, Be AS B1, Be AS B2, BB, T-BB
WHERE B1.name = “Joe”
AND B1.type = “person”
AND BB.BelD1 = B1.ID
AND BB.B1type = “employee”
AND BB.Assoc = “⊂”
AND BB.B2type = “employer”
AND BB.BelD2 = B2.ID
AND B2.name = “XYZ Lumber”
AND B2.type = “company”
AND T-BB.BBID = BB.ID
AND T.ID ≡ T-BB.TimeID;
明らかに、これは、何が簡単な要求のように思われるかについてのかなり長いステートメントである。簡単化されたＳＱＬは、次のようになる。
SELECT T() FROM Time, Be AS B1, Be AS B2
WHERE B1 (“Joe”, person) ≡ BB (“employee”, ⊂, “employer”) ≡
B2 (“XYZ Lumber”, company)
AND T ≡ T-BB (“employee”, “employer”);
或いは、会社（従業員、雇い主等）とどのような関係を有するか気にしない場合には、次のように逃れることができる。
SELECT T() FROM T-BB, Be AS B1, Be AS B2
WHERE B1 (“Joe”, person) ⊂ B2 (“XYZ Lumber”, company);
【０１９９】
この例では、２つのＢｅ記録間の関係が確立され、そして暗示ＢＢ関係が確立されると共に、Ｔ−ＢＢ使用からＴｉｍｅが暗示される。もちろん、より複雑な問合せ、又はフロー３から見たリンクノード（この例では、ＢＢ）がＴｉｍｅをノードの１つとして含む問合せに対して、それらの定義された関係がより明確であることが望まれる。
【０２００】
問合せを、他の数学式と同様に、数学方程式として書けることは興味深いことである。これは、おそらく、問合せ言語自体の進歩に適した効果である。
【０２０１】
データ構造の例
本発明のモデルを使用して、いかなる形式のデータ構造を形成することもできる。
【０２０２】
リンクされたリスト（単一／二重）
リンクされたリストは、ある順序で一緒にアタッチされたデータの単なるチェーンに過ぎない。もちろん、いかなるエレメントも他のエレメントにアタッチできるが、リストは、通常、１つ前のアイテム及び１つ後のアイテムとチェーンにされる。
【０２０３】
図１４Ａ−１４Ｇに示すように、リストを形成する方法は多数あるが、それらは、常に、「ルート(Root)」と称されるものでスタートする。ルートは、単に、リストを全体的に表わすのに使用される１つのデータアイテムである。これは、通常、データのリストにアタッチされるか、又はリストデータがそれにアタッチされる。このモデルでは、アタッチの仕方が本来２通りである。
【０２０４】
データチェーン自体は、手前の又は次のデータエレメントを伴わないデータエレメント或いはリンク参照によりチェーンの終わりに終了することもできるし（図１４Ｇに示すように）、或いは「ハンギング」リンクノード（１つのエレメントのみにアタッチされたリンクノード）にアタッチすべきを含むこともでき、この場合には、アタッチされない端は、現在のポインタ構造（データのない「次」又は「手前」のフィールドを埋めねばならない）に「ナル」値が通常使用されるのと同様に、リストの端と考えることができる。これは、他のいずれのデータ構造にも適用される。
【０２０５】
待ち行列（ＦＩＦＯ）
待ち行列（図１５に示す）は、単に、データが一端に追加されそして他端から除去されるリストである。これは、「ＦＩＦＯ」とも称され、「先入れ、先出し」を意味する。ＦＩＦＯリスト（何かを購入するために待っている人々の列のような）は、最初と最後のノードを知りそして最後のノードにデータを追加しながら最初のノードからデータを除去することだけを必要とする。これは、上記二重リンクリスト（１つのノードをルートノードとして使用する）からの構造を使用して容易に達成される。最初のデータムがノードに追加され、そしてそのデータムに他の全てがアタッチされる。データムを除去するときに、ポインタがリスト内の次のエレメントに再リンクされる。これは、標準的なデータ技術である。
【０２０６】
スタック（ＦＩＬＯ）
スタック（図１６に示す）は、単に、データが一端に追加されそして同じ端から除去されるリストである。これは、「ＦＩＬＯ」とも称され、「先入れ、後出し」を意味する。ＦＩＬＯリスト（上部のものを除去してから下部のものを除去しなければならない）は、最初と最後のノードが分かりそしてリスト内の最後の１つにデータを追加し又はそこからデータを除去することだけを必要とする。全てのポインタは、この関係を維持するように調整される。これは、標準的なデータ技術である。
【０２０７】
Ｂ−ツリー
Ｂ−ツリー（図１７に示す）は、データが単一ノードにアタッチされ、各ノードから２つ以下の「ブランチ」を伴うデータ構造である。３つ以上のノードがある場合には、全「ツリー」がポピュレートされるまで、余計なノードが、分岐するアタッチされたノードに対でアタッチされる。これは、最も遠いブランチまでのステップの数を制限するので、データのサーチ及び分類に対して一般的な構造である。これは、本発明により容易に作成することができ、標準的なデータ技術である。
【０２０８】
ヒープ
図１９を参照すれば、ヒープ（「ランダムツリー」を含むこともできる）は、ユーザが希望する形態で、データが追加され、変更され、又は削除される構造である。これらは、通常、システムの全容量及びリソースの参照を監視する以外、ほとんど命令を受けない。ランダムツリーの一例が図１８に示されている。これは、本発明により容易に作成でき、標準的なデータ技術である。
【０２０９】
リング
リング状リスト（図２０に示す）は、ルート以外の開始点も終了点ももたない円形リストである。これは、ルートノードを、リンクされたリストの開始点及び終了点として使用し、ここで、ルートは、ループの一部分であってもよいし、又はループの外部に位置してもよい（図示されたように）。この形式の構造は、リストをそれ自身にリンクし、そして１つのノードをルートとしてリングの内部又は外部にアタッチするだけで、本発明により容易に作成することができる。これは、標準的なデータ技術である。
【０２１０】
ハッシュテーブル及びディクショナリー
ハッシュテーブルは、どんなデータが到来するかにより通常アルファベット順に編成されたデータのリストである。人々のグループを使用し、それらの名前を取り上げることで、リストに名前を追加し、室内にいる全ての人々の完全なリストが得られるまでリストが埋められる。与えられたデータにより形成されるネイティブリスト以外、他の形式のインデックスを形成する試みは行われない。もちろん、本発明では、これは、データを挿入して埋めていく通常にリンクされるリスト構造と同程度に簡単である。これは、標準的なデータ技術である。
【０２１１】
他の構造
もちろん、多数の他のデータ構造も考えられ、例えば、ルートノードから分岐する多数のリンクに任意の形式のデータがアタッチされる本質的にランダムツリーである図１８に示すものがある。これは、標準的なデータ技術である。
【０２１２】
応用（エレメントによる）
Ｂｅ
系統
図２１Ａ及び２１Ｂに例示するように、系統の一例を包含する全形式の個人的関係を作成することができる。しかしながら、このデータベースモデルは、欠陥のある又は不充分なデータベース機構に関連した問題及びそれに関係する問題を防止できるが、ユーザが不適切な関連性を形成するのを防止するすべはない。この例では、ユーザは、関係する人々のハイアラーキーを形成し、そして子供を、２人の親間のリンクに接続するよう試みることを希望する。これは、誤ったデータ設計を招くことがある。というのは、決して存在し得ない結婚のような任意の関連性を経なければ子と親との間のツリーを容易に登ったり降りたりすることができないからである。又、親に到達するために、この関係を経て進みそしてそこから親ノードを発見しなければならない。これは、記憶されたデータ及び関係について不充分で且つ不合理である。
【０２１３】
より正確なバージョンが図２１Ｂに示されており、ここでは、各子供が自分の各親に直接関連付けられそして親が互いに関連付けられる。これは、親をルックアップし、次いで、サーチに関心のある者と同程度にアップ又はダウン方向に離れた次の親をルックアップするという簡単さでツリーを上ったり降りたりする。
【０２１４】
適切な系統では、完全なリストを得るまで何度でもアップ又はダウン方向にトンネル処理することができる。トンネル処理は、本発明において技術的に導入されそして示唆される。
【０２１５】
実際には、このモデルの能力に関わらず、良好なデータだけが与えられる。真の正しい関係をもつ何らかの論理的データ設定が依然必要である。
【０２１６】
個人
図２２Ａ及び２２Ｂを参照すれば、個人の典型的な定義について正しい及び誤ったデータ適用の別の例が示されている。通常、人々は、それらの名前で識別される。従って、名前を変更するときに何が起きるか？生じる事象は？或いは他の属性を変更した場合に、どんな認識に基づくか？これは、問題を引き起こし、個人の誤った使用又は認識となる。
【０２１７】
Ｂｅｉｎｇは、エンティティである。名前は認識であり、名前は変更できるので、誰かを識別する方法としては不充分である。又、犯罪調査では、それが誰であるかを知らずに犯罪に関する情報を収集することに関心がもたれる。この一般的なＢｅｉｎｇｎｅｓｓは、それまでに見つかっている全ての証拠にリンクされる。データベースが一致を見つけた場合には、そこで、名前を供給することができる。
【０２１８】
個人をより適切にモデリングするために、個人を、単に個人自体であるそれらの全ての属性から分離しなければならない。その後、それらに、名前や他の形式の属性がアタッチされる。
【０２１９】
これは、唯一分かっているのが、識別されない誰かが何かを行ったことである警察の仕事に特に有用である。これは、この個人を名前又は他のキー認識エレメントに一致させることができるまで行動及び他の各々の証拠断片にリンクされる「個人」記録である。
【０２２０】
図２２Ｂに示すように、人々が他の人々と同じ名前を共有することは一般的である。真のユニバーサルデータベースは、同じデータを２回記憶することによりスペースを浪費しないが、各個人を共通のデータエレメントにリンクしなければならない。このようにして、このようなデータに関する問合せを行って、特定の属性に関連した全ての人々を見つけることができる。これは、サーチを容易にする。
【０２２１】
認識は、おそらく、このデータモデルにおける別の非常にパワフルなエレメントで、他の設計に存在しないものである。図２３を参照すれば、ある個人がシアトル及びアトランタを訪れ、そして別の個人がニューヨーク及びロスアンジェルスを訪れたことが分かっているとする。その後、２人の個人が同じ個人であることが分かった。これは、これら２つの記録間に「同一（イコール）」関係を生成し、そして１人の個人について問合せすべき場合に、システムは、これらの認識を確認すると共に、全ての認識に沿って問合せを適用することもできねばならない。これは、Ｂｅｉｎｇｎｅｓｓについては、他のエレメントについて適用するのと同様に適用できない。Ｂｅｉｎｇは、必ずしも名前ではなく、そしてこのデータベースは複製データを記憶しないので、多数のＢｅｉｎｇを、実際の生活においてそうであるように、同じ名前にアタッチすることができる。
【０２２２】
認識
名前を個人のコア認識として使用してはならない（上述したように）ことを無視すると、図２３に示すように、種々の都市へ旅行した２人の人間がいることが想像される。一人は、名前が「ビル」で、もう一人は、名前が「ウイリアム」である。ビルは、シアトル、ロスアンジェルス及びデンバーを訪れ、一方、ウイリアムは、シカゴ、アトランタ及びニューヨークへ行った。
【０２２３】
ここで、ビルは、実際には、ウイリアムのニックネームであり、そして２人が実際には同じ人であることが分かったとする。これは、上述した「同一」関係を使用して２つの記録間に等号を生成する。
【０２２４】
このような状態では、ウイリアムに対する全ての将来の参照は、自分の「同等物」（認識「ビル」）も参照しなければならず、又、その逆のことも言える。換言すれば、これらは、本質的に同じ個人の記録であるかのように処理される。現在のデータベースシステムは、このように行わず、この等号は、同一のものとして存在するだけではなく、他のエレメント形式についても存在し、広く使用することができる。
【０２２５】
Ｄｏ
ステップのシーケンス
Ｄｏｉｎｇｎｅｓｓは、一般に、人間のＤｏｉｎｇｎｅｓｓを伴う。１つのアクションは、完了すべき多数のステップを必要とし得る。従って、Ｄｏｉｎｇｎｅｓｓは、Ｂｅｉｎｇｎｅｓｓが系統に対して存在するときのように登るべき別のハイアラーキーである。ステップは、図２４に示すように、何かをいかに構築し又は形成するかの単一の命令である。
【０２２６】
オリンピック
オリンピックは、夏及び冬のスポーツを含むアクションである。又、単一の競技に至るまでイベントと称する多数のサブアクションも含む。これは、図２５に示すようなハイアラーキーである。
【０２２７】
雇用
Ｂｅｉｎｇｎｅｓｓを、実際にはＤｏｉｎｇｎｅｓｓである何かであると定義することに注意を払わねばならない。雇用においては、あなたが何であるか定義するのは、通常、Ｄｏｉｎｇｎｅｓｓである。あなたが本を書く場合には、ライターである。映画を製作する場合には、プロデューサである。
【０２２８】
図２６において、個人及び会社を関連付けて有する。会社は、各々が異なるサラリーを受ける多数のジョブを有する。この個人は、ある日付で「雇用」と称する関係でそれ自身を会社にリンクする。又、個人は、退職するまでに長年にわたって多数のジョブを担当する。もちろん、その会社との「雇用」関係は終わりになるが、自身の「サラリー」を有する退職の新たな関係を通じてその会社と依然関連している。
【０２２９】
Ｈａｖｅ
目録
あなたの財産の目録は、ここでは、あなたのＨａｖｉｎｇｎｅｓｓのリストである。車、家、株、等々。或いは、図２７に示すような倉庫の在庫で、会社、倉庫、価格表、ＩＤリスト、製品リスト、価格及び製品を考慮するもの。説明上、製品は、認識及び価格の両方でインデックスされ、従って、いずれかの参照によりルックアップすることができる。アーカイブデータを含む在庫に関して知りたい多数の他のビジネス関係が存在する。
【０２３０】
ペーパーレスオフィスシステム
ファイルは、ドキュメント（ワードファイルのような）、ドキュメントのスキャンしたイメージ（イメージファイルのような）、ドキュメントのテキスト（任意の形式のテキストファイルのような）、等でよい。オーディオ又はビデオ又は他の媒体参照も含む。換言すれば、このデータベースのみを伴うペーパーレスオフィスシステムを容易に形成することができる。本発明を使用するペーパーレスオフィスシステムの例が図２８に示されており、このオフィスシステムは、ワード及びドキュメントインデックス、ドキュメント識別、ドキュメント、ワードリスト、及びイメージで構成され、これらは、全て、検索及び関連付けのために種々のノード及びリンクノードに記憶される。
【０２３１】
もちろん、ペーパーレスオフィスシステムは、倉庫に極めて類似していることが明らかであり、主たる相違は、それが製品ではなくドキュメントを記憶するものであり、そして価格や製品記述ではなくワードに関心があることである。他の点では、それらは、他の多数のやり方で極めて同様に取り扱うことができる。
【０２３２】
ファイルシステム
ファイルシステムは、単に、データを編成する方法に過ぎない。コンピュータファイルシステム（例えば、ハードドライブにおける）の場合には、迅速なサーチ及び検索のためにハードドライブ上にデータを編成するのに使用される簡単なデータ構造である。本発明は、いかなる形式のデータ構造もモデリングすることができ、且つコンピュータオペレーティングシステムのためのデータを記憶するのに使用される構造は、プリティ規格及びベーシックであるから、これらも本発明により複写することができる。実際に、ファイルが１つのビューにしかないディレクトリーの典型的なツリービューを使用するのではなく、ハードドライブ上にファイルデータを編成するための本発明のモデルを使用すると、ファイルの属性に一致する多数のビューにおいてファイルを探索することができる。例えば、友人の写真は、その友人に関連した都市又は他の属性と共に、「友人」と称するディレクトリーにできるだけ容易にファイルすることができる。
【０２３３】
又、別の観点から、データベースモデルを、通常「クラスター」と称する基礎的なシステムに合体することもできる。というのは、ハードドライブ上のブロックを表わすスペースを、「クラスター」又は「ファイル」或いは他のファイルシステムエレメントを表わすスペースエレメントへと容易にマップできるからである。
【０２３４】
インターネットファイル（例えば、ＨＴＭＬページ又はそれらのＵＲＬ）も言及したいので、ローカルファイルに説明が限定されるものではない。
【０２３５】
更に、装置のアクセスは、ハードドライブ（ドライブＣ：）が基準であるハードウェア又はファイルシステム、或いはそのハードドライブ上のあるブロック又はディレクトリーまで全面的に進めることができる。
【０２３６】
実際に、非ツリーディレクトリーシステムの考え方は、特に望ましいものである。このシステムに記憶される２つのディレクトリーは、同じファイルを指す（ディレクトリー「都市」のもとでピクチャー及びディレクトリー「友人」による別のリンク）。おそらく、日付又は他の何かにより、何かを物理的データにリンクするのに使用することが望まれる。
【０２３７】
データベースモデルは、ハイアラーキーモデルから離されて以来長いが、今日でも、ファイルシステム及びディレクトリーと共通のものはない。本発明を使用すると、他の形式のインデックス又はサーチシステムと同様の健全さにすることができる。
【０２３８】
知覚
知覚(perception)は、単に、環境からの入力である。技術的には、外界との全てのコンピュータ対話は、入力から出力へＨａｖｉｎｇｎｅｓｓのエレメントを経て進められる。これは、取得した膨大な量のデータの記憶として使用されるが、データベースモデルの残りは、このように取得したデータのインテリジェントな処理を表わす。
【０２３９】
実際に、このモデルは、人間の記憶及び精神のある観点と同程度の複雑さで何かに似ている非常に良好な記憶モデルを形成する。外界へのコマンドラインとして、Ｈａｖｉｎｇｎｅｓｓは、理想的なチャンネルである。
【０２４０】
インターフェイスとして、これは、外界を制御するリンクである。これは、オペレーションを実行するためにあるパラメータを（他のエレメント定義から）参照して通過させるある装置ドライバを含んでもよい。おそらく、これは、Ｓｐａｃｅリンクにより参照された物理的な位置へ何かを移動するための健全なコマンドである。
【０２４１】
よりインテリジェントなロボットをもつことに関心があり且つ知覚経歴データを有用な形態で記憶することのできるロボットの場合には、本発明は、確実にこれを実施できる。イメージ（像）を受け取ることはできるが、このイメージにおいて関心がもたれる唯一のものは（それが処理された後に）、幾つかの認識の座標（Ｂｅ）と、いつ（Ｔｉｍｅ）それらがこれらの位置（Ｓｐａｃｅ）にあるかである。もちろん、残りのいずれのエレメントも、モーションの追跡に関心があるのと同様に（Ｅｎｅｒｇｙ、Ｄｏ）、適用される。これに対する任意の記述の追加は、Ｑｕａｔｎｔａ及びＭｏｄｉｆｉｅｒエレメントも含む。
【０２４２】
Ｈａｖｉｎｇｎｅｓｓは、外界からの入力である。これは、処理されるまでは、ほとんど確実に生のデータで、（このデータベースモデルの）コンポーネントエレメントへと分析されていない。分析されると、このシステムの他の全てのエレメントに関して解釈される。
【０２４３】
Ｓｐａｃｅ
運搬
応用に関しては、Ｓｐａｃｅそれ自体について考える。倉庫内のボックスは、ＩＤ（バーコード又はラベルとしてのＢｅｉｎｇｎｅｓｓ）を有するが、物理的なスペースもそれに関連付ける。このスペースは、その中に何かを含む（Ｈａｖｉｎｇｎｅｓｓのように）。又、このボックスは、別の大きなボックス（それ自身のスペース定義及びＢｅｉｎｇｎｅｓｓを伴う）内にあってもよい。このボックスは、それを移動して、多数の他のボックスと共に又はその中に含ませることができる。図２９に示すように、ある国のある州のある都市において、パレットや、トラックや、列車等に存在する。Ｓｐａｃｅ対Ｓｐａｃｅのフロー０参照は、あるアクティビティに対して非常にパワフルである。
【０２４４】
図２９では、倉庫会社が在庫に若干のアイテムを有し、そして他の２つのアイテムを小売店へ運搬することが分かる。これは、これらアイテムに関連した全てのスペースの完全な積み重ねを示す。
【０２４５】
解決すべき最も複雑な全ての倉庫問題の１つは、パレットを「分割」できること、即ちあるパレットから若干の物を取り出してそれらを別のパレットへ移動させることである。これらの移動されるボックスに収容された全ての物を追跡しなければならないときには更に複雑になる。しかし、本発明が設定される仕方を見れば、１０００個のアイテムを収容するボックス（及びサブボックス）を、単一のアイテムと同様に簡単に移動することができる。その中身のどれがどこにあるか知るには、配送ビヒクルがどこにあるか見つけるだけでよい。トラックを使用してその中身を追跡するか、又はいずれかの中身を使用してトラックを追跡することができる。それらは、最も有用な仕方で適切に一緒に結合する。
【０２４６】
Ｅｎｅｒｇｙ
力は、ベクトル化されたエネルギーである。これは、フロー、分散又は峰でよい。運動がフローであるときには、図３０Ａに示すように、爆発を、共通点からの力の分散として表現してもよい。換言すれば、全てのベクトルは、共通点（これは、スペースとして更に定義できる）から発散する。内破は、図３０Ｂに示すように、これらフローの単なる収斂である。
【０２４７】
マネー及び会計
エネルギーは、それ自体厳密に定義されず、種々の形態をとることに注目するのが重要である。例えば、マネーは、エネルギーの一形態で、凝固された形態である。一週間働くと（エネルギーを使用したＤｏｉｎｇｎｅｓｓ）、これが、マネーと称される凝固された非流動形態に変換される。従って、全ての会計がここでは容易に適合する。
【０２４８】
エネルギーは、ある場所から別の場所へ流れる。「から」及び「へ」を使用することにより（構造上許されるどんな形態でも）、図３１Ａ−Ｃに示すように、ある口座から別の口座への資金のフローを示すことができ、これは、基本的な会計構造の単純な例を示す。
【０２４９】
オーダー、インボイス、購入オーダー及び購入は、単に、フロー又は潜在的なフローである。これらは、データのみに関して本発明により容易に表わすことができる。オーダーに変換されるＰＯの一例が図３３に示されており、ここで、ＰＯは、図の左側にあり、そしてオーダーアタッチメントは、図の右側にある。
【０２５０】
Ｔｉｍｅ
バッチ処理
バッチ処理は、単に、指示されたＴｉｍｅに適用されるアクティビティ（Ｄｏｉｎｇｎｅｓｓ）の定義である。Ｄｏｉｎｇｎｅｓｓが、実行すべきアクションのリストである場合には、バッチオペレーションを複雑な自動化のレベルまでほぼ改良する。
【０２５１】
自動化及びプログラミング
自動化は、単に、幾つかの事象の時間的な定義である。それらのあるものは、Ｓｐａｃｅ及びＥｎｅｒｇｙを含む。ロケットについては、図３４に示すように、ある速度（Ｅｎｅｒｇｙ）と共に、あるＳｐａｃｅにおけるある希望の時間のリストを与える。ロケット誘導システムは、タイマーがオンにクリックされたときにこれらのルールに適合するようにロケットを制御する。現在のロケット誘導システムは、このようなルールに基づいて機能し、この場合、市場の他のハードウェアと同じデータベースシステムからプログラムすることができる。図３４において、線２１０００１は、発射台の塔を表わし、そして線２１０００２は、宇宙船の飛行経路を表わす。
例えば、
ＤＯ：事象        ＴＩＭＥ        ＳＰＡＣＥ            ＥＮＥＲＧＹ
（分：秒）    （高度フィート）        （速度ｍｐｈ）
（距離マイル）                        
カウントダウン
発射                0:00                0      0               0
塔を越える          0:15              150      0             200
ロールプログラム    0:30            1,000      0             400
前MaxQ              1:00           35,000      6           2,000
スロットルバック
後MaxQ              1:15           52,800     10           4,000
スロットルアップ
ステージ１          4:00                -     100         10,000
ステージ２          9:00                -     200         12,500
メインエンジン遮断 12:00                -     350         17,000
【０２５２】
製造
通常の製造は、ある時間にエネルギーが印加される状態でスペース内の幾つかのＤｏｉｎｇｎｅｓｓで構成される。換言すれば、全て時間駆動である。自動車のボディーを溶接するロボットアームは、特定のＴｉｍｅに「溶接１」のアクション（ＤＯ）を実行するようにプログラムすることができ、これは、ロボットアーム（ＨＡＶＥ）を特定の位置に移動する（ＳＰＡＣＥ及びＥＮＥＲＧＹを使用して）ことより成り、これらの条件が満足されると、電気的アーク（ＥＮＥＲＧＹ）が印加されて、車体を溶接する。
【０２５３】
いかなる形式のコンベアシステムも、同じものが多い。本質的に全ての自動化製造をこのオペレーションから定義することができる。
【０２５４】
Ｑｕａｎｔａ
定数、変数及び方程式
ほとんどのデータベースは、定数だけを記憶する。明らかに、これらは、いずれのデータシステムにとっても最も重大である。しかし、世界は、定数以外の何物かで構成される。これらは、変数又は方程式として記憶され、絶えず変化する世界を表わすのに使用できる。Ｑｕａｎｔａのある簡単な形態が図１３Ａ−Ｄに見られる。
【０２５５】
変数の使用は、何かの値が未知のときである。確かに、プレースホルダーを使用して未知の値を表わすことができ、そしてこの未知の値まで結果を計算することができる。
【０２５６】
更に、未知の変数が単に変数ではなく、方程式の一部分として定義される場合には、これを使用して、それらの入力に基づく値を決定することができる。これは、このフィールドをより動的なものにする。
【０２５７】
これを拡張すると、次のような共通の変数を通る方程式のチェーンが作られる。
Ｆ＝Ｍ＊Ａ
Ａ＝Ｖ＊Ｔ
【０２５８】
但し、Ａは、２つの方程式に共通である。この場合に、方程式の一方が解けると（少なくともＡの値を決定する）、多くの場合にその他方を解くこともできる。
【０２５９】
計算マシンは、入力の任意の集合からより多くの回答を導出する助けとするように開発された全ての既知の方程式及びプログラムでプログラムすることができる。これは、潜在的に、方程式の任意の部分の入力を使用して他端における出力へと解くことのできる数学知識ベースである。
【０２６０】
関数
関数は、Ｑｕａｎｔａにおける特殊なケースである。実際に、スプレッドシートを非常に健全なものにし、これは、再使用可能なツールを使用して定義し、計算できるものである。このような関数は、サイン、コサイン、タンジェント及び他の多数の計算を含む。上記方程式をインテリジェントコンピュータシステムの設計及び開発に適用したのと同様に、このようなシステムの健全さを高めることもできる。
【０２６１】
Ｍｏｄｉｆｉｅｒ
個人的属性
Ｍｏｄｉｆｉｅｒは、何かの属性を定義するのに使用される。犯罪シーン（上記Ｂｅｉｎｇｎｅｓｓで述べた）を調査する場合には、誰かの記述（白人、男性、青い目、茶髪、等）を含むもの収集する。共通データの充分に大きな集合から、逃亡者を分離し、最終的に探索することができる。
【０２６２】
ほとんどの部分について、これは形容詞（Ｂｅｉｎｇｎｅｓｓ、Ｈａｖｉｎｇｎｅｓｓ、Ｓｐａｃｅ、Ｅｎｅｒｇｙ、Ｔｉｍｅ）と考えられるが、Ｄｏｉｎｇｎｅｓｓについては、副詞と称される。（これは、単に英語の語義。）共通のモディファイヤをエレメントに結合して、Ｍｏｄｉｆｉｅｒを再使用し、そしてＭｏｄｉｆｉｅｒ自体をサーチ可能なエレメントとする。
【０２６３】
他の例は、図３５に示されたように、自動車の記述的参照を含むことができる。車自体は、スタイル、製造、モデル、カラー等と称する多数の属性により更に示されたＨａｖｉｎｇｎｅｓｓについて記述される。自動車に関連付けられる多数の潜在的な属性及び関係がある。
【０２６４】
センテンスパージング及び変換
図３６を参照すれば、センテンスの文法的成分は、Ｍｏｄｉｆｉｅｒと称する記述項において定義することができる。センテンスのワードは、認識（本質的に物理的ユニバースにおける何かを表わす認識）でよいが、ワードそれ自体は、グラマーと称するものにより更に記述することができる。
【０２６５】
本質的に、センテンスの成分が識別されると、認識（ワードそれ自体）を置き換えることができ、そしてその新たな言語に適用できる文法的ルールを使用してセンテンスを再構成することができる。
【０２６６】
リンクされたワードリストを使用して、リスト上にリンクとして各定義（派生を含む）を有する特定の言語に対してディクショナリーを構築することができる。言語のディクショナリーは、図３７Ａに示すように、各ワードの全ての定義を含めて構成することができる。
【０２６７】
英語（及び他の言語）は、非常に同音異義の多い言語であるが、各定義は、技術的に、ワードそれ自体である。他の言語のワードが他の言語のワードにリンクされるときには、変換システムが形成される。このデータベースシステムは、この形式のシステムの構造を本来的にサポートする。図３７Ｂは、独特のワードを関連付けする（それらのロジックにより）１つの仕方を示す。
【０２６８】
その他の使用
サーチエンジン
今日使用されている現在のインターネットサーチエンジンは、「キーワード」サーチが標準であると考えられる。これは、テキストの本体（この場合にはインターネットのウェブページ）から全ての独特のワードを抽出し、そしてそれらの各ソースを参照するようにそれらをリストに保持することにより、行われる。これは、簡単な技術である。
【０２６９】
しかしながら、これは、インテリジェントなものではない。例えば、オレンジ（フルーツ）は、オレンジ（カラー）、オレンジ（都市）及びオレンジ（国）とは異なり、又、これらの各々は、ワード「オレンジ」でサーチすると一致し、望ましからぬ一致のページが得られ、探しているものに到達するまで選別しなければならない。
【０２７０】
その解決策は、ワードだけでなく、どのワード（定義により）が適用されたかによりそれらワードのより正確な分類を含ませねばならない。オレンジ（フルーツ）はＢｅｉｎｇｎｅｓｓであり、オレンジ（カラー）はＭｏｄｉｆｉｅｒであり、そしてオレンジ（都市又は国）はＳｐａｃｅであるから、望ましい情報の選択に向かって膨大な量の不要なデータを予め排除できる。本発明によりそれらが区別されたときには、フルーツをルックアップすることが非常に容易になる。
【０２７１】
６つの分離度
６つの分離度の理論は、人は、６人の平均距離で誰かに関連しているという仮説の理論である。ある人、その友人、彼等の友人、等は、地球上の全ての人を網羅するまでに、たった６つの接続だけである。
【０２７２】
この形式のシステムは、Ｂｅｉｎｇｎｅｓｓを他のＢｅｉｎｇｎｅｓｓにリンクすることにより生成できる。人を関連付ける仕方は多数あるが、この理論では、Ｂｅｉｎｇと別のＢｅｉｎｇとの接続だけに関心がある。
【０２７３】
セキュリティ
図３８を参照すれば、セキュリティの世界（例えば、エアポートスクリーニングシステムに対する）において、進路を歩いている個人を、既知の犯罪記録にある他の誰か、より詳細には、既知のテロリストに関連付けることが重要である。犯罪は、一般に、他の犯罪に関連しているので、この形式のサーチは、疑わしい個人を更なる調査のために取り出す上で非常に有効である。
【０２７４】
誰もが６つの分離度（６ＤＯＳ）で他の誰かにリンクされるので、これが何かを意味するのではない。それだけであるとシステムが報告した場合には、その個人は、おそらくＯＫである。しかし、関係が１つ又は２つの分離度であった場合には、確かに、その個人にはより大きな関心があり、進路から連れ出して、より厳密なチェックを行う。
【０２７５】
この形式のシステムでは、真の６ＤＯＳシステムと同様にＢｅｉｎｇｎｅｓｓ関連性を選択できるが、他のいずれかのエレメントを通して有するリンクの数をカウントするのにより有効であることが分かる。同じ時間に同じ町に住んでいる２人の人は、疑わしくない。しかし、同じ時間に多数の他の場所に住んでいる場合には、疑わしいことになる。これらエレメントのいずれかを使用して既知の犯罪へのリンクをもつことができ、リンク接続の数が、疑わしい人としてその個人に関心をもつ指示となる。
【０２７６】
ネットワーク構成
６ＤＯＳ理論を開発した人は、行先の厳密な認識を知る必要なく、方向接続のみを使用してある位置から別の位置へ何かを配送できるコンピュータ又は他のネットワーク、即ちインターネットに対してまだ行うことのできない何か、を形成することに関心があった。それらの希望は、受信者のｅ−メールアドレスではなく受信者の属性を知るだけでｅ−メールを配送できるようにすることであった。
【０２７７】
初期のシステムが機能しなかった理由は、人がサーチのための情報を知って記憶するのと同程度のインテリジェンスが各ネットワークに必要とされたことであった。この全体的システムの最も複雑な部分は、いかなる目的にも使用でき且ついかなる形式のデータも使用可能な形態で含む標準的なデータ記憶モデルを有する。本発明は、現在、このような偉業を果たし得る唯一知られたシステムである。図４０は、このモデルを使用してネットワークをよりインテリジェントにすると共に、全ての問合せに対して標準的なインターフェイスを与える（本発明で定義された共通のエレメントに基づいて）１つのこのような方法を示す。
【０２７８】
これは、本発明の設計が、編成され固定された一定数のエレメントにおいていかなるデータ形式もサポートするからである。このシステムと共に基本的なサーチ技術を使用すると、何かを見つけることが容易になる。本発明のようなインテリジェントなデータベースシステムを各ネットワークノードにアタッチし、そしてエレメントにより定義できる要求を供給すると、コンピュータでこのロジックを処理して、（エレメントにおける）一致する属性の数を決定し、そして最良の一致を、配送されるべきデータパケットに対する次の行先として返送することができる。
【０２７９】
データ移動
もちろん、本発明は、他の考えられるデータシステムのスーパーセットであるから、他の各々のシステムはそのサブセットである。従って、データの移動は、本発明のエレメント形式の１つで各テーブルフィールドをマークする一方、フィールド名をデータ形式として使用する（又はおそらくより正確で且つそれを明確に指示する）程度に簡単なものとなる。これを全ての既存のデータテーブルに対して行うと、全てのテーブルを読み取って適切なリンクを発生すると共に、オリジナルテーブルからの関係を引き継ぐという応用を開発することができる。
【０２８０】
データ記憶及び検索
本発明のデータベースモデルは、不変であるのが好ましく、情報処理の要点は、今や、記憶されたデータとなる。考えられるあらゆるものを全て包含するリストを形成することはできないが、本発明は、幾つかの重要な問題の解決を包含することを意図する。
【０２８１】
このモデルでは、データベースの構成自体ではなく、データがデータベースの主たる焦点となる。記憶されるものは、何を探しているのか見出せることが主に重要である。従来のシステムでは、何かを探すために、開発者と同程度に多数のテーブルフォーマットの詳細な知識が必要であった。しかしながら、ＢＤＨ−ＳＥＴモデルでは、問題が著しく簡単化される。ＢＤＨ−ＳＥＴシステムをサーチすることは、データ（Ｂｅ、Ｄｏ、Ｈａｖｅ、Ｓｐａｃｅ、Ｅｎｅｒｇｙ、Ｔｉｍｅ、Ｑｕａｎｔａ又はＭｏｄｉｆｉｅｒ）として、及びおそらくデータ形式としても、信じがたいほど簡単である。フルーツとしての「オレンジ」は、都市又は国又はカラーである「オレンジ」から予め区別される。これは、識別の第１レベルであり、多量の適用不能なデータを排除する。従って、サーチは、計算時間をあまり浪費せずに、より正確に当該情報に照準を向けることになる。関係のない結果を更に減少するために、問合せに付加的な情報（データレンジ又は位置のような）を追加するのが充分容易である。それだけでなく、非繰り返しアイテムのリストであるために、ノードの独特のアイテムのサーチにおいて、ターゲットとする主題が更に容易に見つけられる。何かに対する参照は、データ形式又は特性によっても更に正確にターゲットとすることができる。換言すれば、ノードは、サーチにより適した一致形式の限定リストにより正確に焦点を合わせるために、そのデータ形式（ここでは、論理的形式を意味し、構造上のフィールド形式を意味しない）によりサーチすることができる。
【０２８２】
特定のアイテムに対して何が潜在的に非常に多数のリンクであるかに関わらず、各ノードリストが完全に非冗長であることが、機械的な観点からサーチ努力を明確に減少させる。
【０２８３】
変化のロギング
データベース内の変化を追跡したい場合には、このモデルの各値を探すことになる。下半分にデータベースを示しそして上半分にログ自体を示す図３９に示されたように、本質的に、特定の時間に変化したもののピクチャーを撮影する。
【０２８４】
個人は、常に、変化しつつあるデータの一部であり、このため、半部分がそのエレメントにリンクされる。この概念を例示するために、インテリジェンスエージェンシーセキュリティシステムを考慮し、そして何かを変えつつある誰かは、サーチの一部分でなければならない誰かでもあることに気付く。
【０２８５】
データに対して取られるアクション（挿入、更新、削除）は、Ｄｏｉｎｇｎｅｓｓである。何が変化したかは、Ｈａｖｉｎｇｎｅｓｓである。いつ変化したかは、Ｔｉｍｅである。コンピュータターミナルの位置は、Ｓｐａｃｅである。ユーザの許可（力）は、Ｅｎｅｒｇｙである。Ｑｕａｎｔａ又はＭｏｄｉｆｉｅｒとして記憶できる他のファクタも考えられる。これらを全て一緒に結合し、変化した何かについて報告する。この形式のログ情報が典型的であるが、それを記憶する方法は、独特である。
【０２８６】
ＨＷ及びチップ一体化
本発明のデータベース設計は、標準的な不変のシステム及びモデルであるのが好ましいので、この技術をハードウェア形態で合体することができる。これは、大量の埋設データベースを再現する手段として半導体及び他の電子装置フォーマットに埋め込むことができる。既知のデータ要求をサポートするのに充分な融通性をもつこの形式の標準的な不変の技術は、ハードウェアの埋め込みに理想的である。
【０２８７】
以上、多数の実施形態を詳細に説明したが、本発明の精神及び範囲から逸脱せずに種々の変更がなされ得る。従って、本発明は、それらに限定されず、特許請求の範囲のみにより限定されるものとする。
【図面の簡単な説明】
【０２８８】
【図１】本発明のデータベースの一次ノードを示す概略図である。
【図２】本発明による一次データベースノード及び簡単なリンクの概略図である。
【図３Ａ】本発明による論理的及び物理的ノード対ノードリンクを示す概略図である。
【図３Ｂ】本発明による論理的及び物理的ノード対リンクノード接続を示す概略図である。
【図４Ａ】本発明により何かをリンクするのに必要な２つの形式のコア接続を表わす概略図である。
【図４Ｂ】本発明により何かをリンクするのに必要な２つの形式のコア接続を表わす概略図である。
【図５】本発明によるフロー０、１及び２に対する一次ノード及びそれらのリンクを示す概略図である。
【図６】本発明による単一ノードに対する全てのノード対リンクノード接続を表わす概略図である。
【図７Ａ】ノード自体又は他のノード／リンクノードにリンクされたノードの４つのフロー各々の論理的及び物理的ビューを表わす概略図である。
【図７Ｂ】ノード自体又は他のノード／リンクノードにリンクされたノードの４つのフロー各々の論理的及び物理的ビューを表わす概略図である。
【図７Ｃ】ノード自体又は他のノード／リンクノードにリンクされたノードの４つのフロー各々の論理的及び物理的ビューを表わす概略図である。
【図７Ｄ】ノード自体又は他のノード／リンクノードにリンクされたノードの４つのフロー各々の論理的及び物理的ビューを表わす概略図である。
【図８Ａ】本発明によるフロー３に対する一次ノード及びそれらのリンクを示す概略図である。
【図８Ｂ】本発明によるフロー３に対する一次ノード及びそれらのリンクを示す概略図である。
【図８Ｃ】本発明によるフロー３に対する一次ノード及びそれらのリンクを示す概略図である。
【図８Ｄ】本発明によるフロー３に対する一次ノード及びそれらのリンクを示す概略図である。
【図９】本発明の８エレメントデータベースを示す概略図である。
【図１０】本発明による８エレメントデータベースのノード及び簡単なリンクの概略図である。
【図１１】本発明によるフロー０、１及び２に対する８エレメントデータベース及びそれらのリンクを示す概略図である。
【図１２Ａ】本発明によるフロー３に対する８エレメントデータベースのノード及びそれらのリンクを示す概略図である。
【図１２Ｂ】本発明によるフロー３に対する８エレメントデータベースのノード及びそれらのリンクを示す概略図である。
【図１２Ｃ】本発明によるフロー３に対する８エレメントデータベースのノード及びそれらのリンクを示す概略図である。
【図１２Ｄ】本発明によるフロー３に対する８エレメントデータベースのノード及びそれらのリンクを示す概略図である。
【図１２Ｅ】本発明によるフロー３に対する８エレメントデータベースのノード及びそれらのリンクを示す概略図である。
【図１３Ａ】本発明を使用して形成できる定数、変数、又は方程式及び関数に関してデータを記述するためのＱｕａｎｔａの能力を示す概略図である。
【図１３Ｂ】本発明を使用して形成できる定数、変数、又は方程式及び関数に関してデータを記述するためのＱｕａｎｔａの能力を示す概略図である。
【図１３Ｃ】本発明を使用して形成できる定数、変数、又は方程式及び関数に関してデータを記述するためのＱｕａｎｔａの能力を示す概略図である。
【図１３Ｄ】本発明を使用して形成できる定数、変数、又は方程式及び関数に関してデータを記述するためのＱｕａｎｔａの能力を示す概略図である。
【図１４】本発明のデータベースを使用して形成されるリンクされたリストの多数の形式を示す概略図である。
【図１５】本発明を使用して形成される待ち行列データ構造の概略図である。
【図１６】本発明を使用して形成されるスタックデータ構造の概略図である。
【図１７】本発明を使用して形成されるＢ−ツリーデータ構造の概略図である。
【図１８】本発明を使用して形成されるランダムツリーデータ構造の概略図である。
【図１９】本発明を使用して形成されるヒープデータ構造の概略図である。
【図２０】本発明を使用して形成されるリングデータ構造の概略図である。
【図２１Ａ】本発明を使用して形成される、誤った及び正しい系統データ構造の概略図である。
【図２１Ｂ】本発明を使用して形成される、誤った及び正しい系統データ構造の概略図である。
【図２２Ａ】本発明を使用して個人のための適切な形態及び構造を示す概略図である。
【図２２Ｂ】本発明を使用して共通の認識（名前のような）に対する人々の関係を示す概略図である。
【図２３】本発明を使用して個人を共通の認識によりいかにリンクできるかを示す図である。
【図２４】本発明を使用してアクションステップをいかにリンクできるかを示す概略図である。
【図２５】本発明を使用してオリンピックのような活動をいかにリンクできるかを示す概略図である。
【図２６】本発明を使用して会社に対する従業員の正しい関係を示す概略図である。
【図２７】本発明を使用して形成できる簡単な倉庫在庫構造を示す概略図である。
【図２８】本発明を使用して形成できる簡単なペーパーレスオフィスシステムを示す概略図である。
【図２９】本発明を使用して典型的なパッケージング及び配送サイクル全体にわたり倉庫アイテムの探索をいかに簡単化するかを示す概略図である。
【図３０Ａ】本発明を使用して簡単なエネルギーフロー（爆発及び内破）を示す概略図である。
【図３０Ｂ】本発明を使用して簡単なエネルギーフロー（爆発及び内破）を示す概略図である。
【図３１Ａ】本発明を使用して簡単なエネルギーフローを示す概略図である。
【図３１Ｂ】本発明を使用して簡単なエネルギーフローを示す概略図である。
【図３１Ｃ】本発明を使用して形成できる会計及び資金移動に関して簡単なエネルギーフローを示す概略図である。
【図３２】本発明を使用して形成できるある簡単なビジネスデータ構造を示す概略図である。
【図３３】本発明を使用して形成できる購入オーダー及びオーダーデータ構造を示す概略図である。
【図３４】本発明を使用して形成できるロケット誘導プログラムに適用される自動化能力を示す概略図である。
【図３５】本発明を使用して形成できる自動車データを記述するためのＭｏｄｉｆｉｅｒの使用を示す概略図である。
【図３６】本発明を使用して形成できるグラマー及びセンテンスパージングの方法を示す概略図である。
【図３７Ａ】本発明を使用して形成できる簡単なディクショナリー構造を示す概略図である。
【図３７Ｂ】本発明を使用して形成できる簡単なワード関係を示す概略図である。
【図３８】セキュリティに対する本発明の適用を示す概略図である。
【図３９】本発明に基づく６エレメントバージョン及び８エレメントバージョンにおける変更ログを示す概略図である。
【図４０】ネットワーク及びネットワーク構成への本発明の適用を示す概略図である。
【符号の説明】
【０２８９】
１：ノード（Ｂｅｉｎｇｎｅｓｓ又はＢｅ）
２：ノード（Ｄｏｉｎｇｎｅｓｓ又はＤｏ）
３：ノード（Ｈａｖｉｎｇｎｅｓｓ又はＨａｖｅ）
４：ノード（Ｓｐａｃｅ）
５：ノード（Ｅｎｅｒｇｙ）
６：ノード（Ｔｉｍｅ）
７：ノード（Ｑｕａｎｔａ）
８：ノード（Ｍｏｄｉｆｉｅｒ）
１７：リンクノード（Ｂｅ−Ｑｕａｎｔａ）
２８：リンクノード（Ｄｏ−Ｍｏｄｉｆｉｅｒ）
４６：リンクノード（Ｓｐａｃｅ−Ｔｉｍｅ）
【図１】
2006053934.tif 000014
【図２】
2006053934.tif 000015
【図３Ａ】
2006053934.tif 000016
【図３Ｂ】
2006053934.tif 000017
【図４Ａ】
2006053934.tif 000018
【図４Ｂ】
2006053934.tif 000019
【図５】
2006053934.tif 000020
【図６】
2006053934.tif 000021
【図７Ａ】
2006053934.tif 000022
【図７Ｂ】
2006053934.tif 000023
【図７Ｃ】
2006053934.tif 000024
【図７Ｄ】
2006053934.tif 000025
【図８Ａ】
2006053934.tif 000026
【図８Ｂ】
2006053934.tif 000027
【図８Ｃ】
2006053934.tif 000028
【図８Ｄ】
2006053934.tif 000029
【図９】
2006053934.tif 000030
【図１０】
2006053934.tif 000031
【図１１】
2006053934.tif 000032
【図１２Ａ】
2006053934.tif 000033
【図１２Ｂ】
2006053934.tif 000034
【図１２Ｃ】
2006053934.tif 000035
【図１２Ｄ】
2006053934.tif 000036
【図１２Ｅ】
2006053934.tif 000037
【図１３Ａ】
2006053934.tif 000038
【図１３Ｂ】
2006053934.tif 000039
【図１３Ｃ】
2006053934.tif 000040
【図１３Ｄ】
2006053934.tif 000041
【図１４】
2006053934.tif 000042
【図１５】
2006053934.tif 000043
【図１６】
2006053934.tif 000044
【図１７】
2006053934.tif 000045
【図１８】
2006053934.tif 000046
【図１９】
2006053934.tif 000047
【図２０】
2006053934.tif 000048
【図２１Ａ】
2006053934.tif 000049
【図２１Ｂ】
2006053934.tif 000050
【図２２Ａ】
2006053934.tif 000051
【図２２Ｂ】
2006053934.tif 000052
【図２３】
2006053934.tif 000053
【図２４】
2006053934.tif 000054
【図２５】
2006053934.tif 000055
【図２６】
2006053934.tif 000056
【図２７】
2006053934.tif 000057
【図２８】
2006053934.tif 000058
【図２９】
2006053934.tif 000059
【図３０Ａ】
2006053934.tif 000060
【図３０Ｂ】
2006053934.tif 000061
【図３１Ａ】
2006053934.tif 000062
【図３１Ｂ】
2006053934.tif 000063
【図３１Ｃ】
2006053934.tif 000064
【図３２】
2006053934.tif 000065
【図３３】
2006053934.tif 000066
【図３４】
2006053934.tif 000067
【図３５】
2006053934.tif 000068
【図３６】
2006053934.tif 000069
【図３７Ａ】
2006053934.tif 000070
【図３７Ｂ】
2006053934.tif 000071
【図３８】
2006053934.tif 000072
【図３９】
2006053934.tif 000073
【図４０】
2006053934.tif 000074
【外国語明細書】
2006053934.tif 000075
2006053934.tif 000076
2006053934.tif 000077
2006053934.tif 000078
2006053934.tif 000079
2006053934.tif 000080
2006053934.tif 000081
2006053934.tif 000082
2006053934.tif 000083
2006053934.tif 000084
2006053934.tif 000085
2006053934.tif 000086
2006053934.tif 000087
2006053934.tif 000088
2006053934.tif 000089
2006053934.tif 000090
2006053934.tif 000091
2006053934.tif 000092
2006053934.tif 000093
2006053934.tif 000094
2006053934.tif 000095
2006053934.tif 000096
2006053934.tif 000097
2006053934.tif 000098
2006053934.tif 000099
2006053934.tif 000100
2006053934.tif 000101
2006053934.tif 000102
2006053934.tif 000103
2006053934.tif 000104
2006053934.tif 000105
2006053934.tif 000106
2006053934.tif 000107
2006053934.tif 000108
2006053934.tif 000109
2006053934.tif 000110
2006053934.tif 000111
2006053934.tif 000112
2006053934.tif 000113
2006053934.tif 000114
2006053934.tif 000115
2006053934.tif 000116
2006053934.tif 000117
2006053934.tif 000118
2006053934.tif 000119
2006053934.tif 000120
2006053934.tif 000121
2006053934.tif 000122
2006053934.tif 000123
2006053934.tif 000124
2006053934.tif 000125
2006053934.tif 000126
2006053934.tif 000127
2006053934.tif 000128
2006053934.tif 000129
2006053934.tif 000130
2006053934.tif 000131
2006053934.tif 000132
2006053934.tif 000133
2006053934.tif 000134
2006053934.tif 000135
2006053934.tif 000136
2006053934.tif 000137
2006053934.tif 000138
2006053934.tif 000139
2006053934.tif 000140
2006053934.tif 000141
2006053934.tif 000142
2006053934.tif 000143
2006053934.tif 000144
2006053934.tif 000145
2006053934.tif 000146
2006053934.tif 000147
2006053934.tif 000148
2006053934.tif 000149
2006053934.tif 000150
2006053934.tif 000151
2006053934.tif 000152
2006053934.tif 000153
2006053934.tif 000154
2006053934.tif 000155
2006053934.tif 000156
2006053934.tif 000157
2006053934.tif 000158
2006053934.tif 000159
2006053934.tif 000160
2006053934.tif 000161
2006053934.tif 000162
2006053934.tif 000163
2006053934.tif 000164
2006053934.tif 000165
2006053934.tif 000166
2006053934.tif 000167
2006053934.tif 000168
2006053934.tif 000169
2006053934.tif 000170
2006053934.tif 000171
2006053934.tif 000172
2006053934.tif 000173
2006053934.tif 000174
2006053934.tif 000175
2006053934.tif 000176
2006053934.tif 000177
2006053934.tif 000178
2006053934.tif 000179
2006053934.tif 000180
2006053934.tif 000181
2006053934.tif 000182
2006053934.tif 000183
2006053934.tif 000184
2006053934.tif 000185
2006053934.tif 000186
2006053934.tif 000187
2006053934.tif 000188
2006053934.tif 000189
2006053934.tif 000190