Ｔ字形 ER手法では、関係の論理を、関数 （多項述語論理） として扱わないことは、すでに、述べてきたので、本稿では再録しない。本稿では、以下の点を検討する。

　（1） モノ と モノ との関連 （リレーションシップ） が成立していることを、いかにして、判断するのか。
　（2） リレーションシップ を、すべて、網羅していることを、いかにして、証明するのか。

　モノ と モノ との関連 （リレーションシップ） を認知するためには、--モノ を認知するときと同じように-- 以下の 2つの やりかた が提示されている。

　（1） 意味の対象説 （言葉の意味は、現実の世界を写像している、ということ）
　（2） 意味の使用説 （言葉の意味は、言葉が使われている文脈のなかで成立する、ということ）

　（1） を前提にすれば、データ 間の関連は、現実世界 （言語外現実） を観察しなければならない。（2） を前提にすれば、事業のなかで使われている 「情報」 を材料にすればよい。

　
● 「コード 体系」 は私的言語ではない。

　事業のなかで伝達される情報は、自然言語を使っている。自然言語の伝達を効率的に実現するために、人為的な コード 体系が導入されてきた。モノ に対して認知番号を付与するという習慣 （制度） が、初めて、導入されたのは、いつ頃なのか、そして、そういう制度が導入されたとき、最初、どういう モノ に対して、コード を付与したのか、という点を、小生は知らないが、少なくとも、自然言語を使って伝達することに比べたら、人為的な認知番号を使ったほうが、効率的であるので、コード が使われてきたことは、想像できる。

　コード 体系の歴史を調べることは、興味深い研究課題になる、と思う。
　コード が、すでに、記述されている モノ に対する 「略称」 として使われはじめたのか、それとも、（まだ、記述されていない モノ に対して、自然言語と同じように） 「指示語」 として使われはじめたのか、それとも、「暗号」 として使われはじめたのか、、、。そして、そのなかのいずれであれ、コンピュータ の データ として、キー や indexing （あるいは、データ そのもの ）のなかに転用されているうちに、コンピュータ の キー 概念が、コード 体系に対して影響を及ぼすようになってきて、コード 体系と データ 設計が、たがいに影響しながら、コード 体系が変質してきた歴史を調べることは、興味深い研究課題である。認知科学を専門にしている人たちのだれかが、コード 体系という地味ではあるが、認知の大きな論点になる テーマ を研究してほしい、と思う。「記号論」 の テーマ としてではなくて、事業のなかで使われている データ に対する 「コード 体系制度の実証研究」 を、だれか、やってほしい、と思う。

　さて、（コード 体系の歴史的実証研究を除外しても、） 事業のなかで使われている情報には、自然言語と人為的に設置された コード 体系がある。そして、コード 体系のなかに記述されている コード を、情報のなかで、管理番号として使い、情報が伝達される。つまり、コード 体系は、「合意された」 管理番号表であり、「私的に」 従うことはできない。

　コード が論点となるのは、コード の適用範囲である。たとえば、商品番号を使って商品を記述する際、商品として記録される個々の データ （属性値） は、なにか、という点である。商品名称や重量や単価なのか、さらには、製造日も対象になるのか、という点である。言い換えれば、どういう データ 項目を、「商品」 として記録するか、という点である。この判断が、意外に、むずかしい。たとえば、製造日は、「製造」 のなかで記録される データ 項目であって--当然、「商品番号」 も 「製造」 のなかで記録されるが--、「商品」 には帰属しない、という判断もできる。
　1つの認知番号 （管理番号） のなかで、どういう データ 項目が記録されるか、という点は、entity の認知に関する論点である。

　
● 1つの情報のなかで、複数の認知番号があれば、リレーションシップ を明示している。

　認知番号 （管理番号） が モノ を示しているのであれば、1つの情報のなかで、複数の認知番号 （管理番号） が記述されているなら、それらの認知番号の間には、関連が成立している、と判断できる。したがって、リレーションシップ が成立している判断規準として、情報のなかで 「明示されている」 認知番号の関連を使えばよい。

　1つの情報のなかで明示されている認知番号を辿れば、リレーションシップ を確実に定立することができる。ただし、その やりかた は、リレーションシップ の網羅性を保証している訳ではない。
　たとえば、1つの情報として、受注入力画面があって、顧客番号と受注番号と商品 コード が記述されていた、とする。この情報のなかでは、「顧客と受注」 および 「受注と品目」 の間に、リレーションシップ が成立していることを読み取ることができる （顧客番号 --> 受注番号 --> 商品 コード）。ただし、顧客と商品の間にも、リレーションシップ が成立しているかどうか、を明示的に記述してはいない。ひょっとしたら、或る顧客が、或る商品を購入したとき、割引率を適用するという ルール があるかもしれない。

　リレーションシップ の網羅性を保証するためには、1つの情報のなかで記述されている entity の マトリックス を作成して、リレーションシップ の可能態を、すべて、検証しなければならない （具体的なやりかたは、69ページ を参照されたい）。

　明示された リレーションシップ は、「情報」 のなかの認知番号を、順次、辿ればよい ことを前述したが、実際には、「情報」 のなかで記述されている リレーションシップは、 以下の いずれかの状態のなかで示される。

　（1） 「構造化」 型
　（2） 「非構造化」 型

　「構造化」 型の典型的な情報として以下を示す。

　┌──────────────────────
　│　顧客番号...　顧客名称...
　│　受注番号...　受注日...
　│　商品番号...　商品名称...　受注数...
　│

　「構造化」 型は、それぞれの entity が、構造化設計 （関係 モデル 風に言えば、 包摂関係） のなかで、「並べられている」 形態である。たとえば、「顧客 --> 受注 --> 商品」 などのように。

　「非構造化」 型の典型的な情報として以下を示す。

　┌──────────────────────
　│　顧客番号...　顧客名称...
　│　住所コード...　
　│　会社コード...
　│　役職コード...
　│

　「非構造化」 型は、最初に記述された認知番号に対して、ほかの認知番号が、それぞれ、 対応するような形態である。たとえば、「顧客 --> 住所、顧客 --> 会社」のように。 言い換えれば、住所 コード と会社 コード のあいだには、関係はない。

　したがって、認知番号を、順次、辿ったとしても、リレーションシップ を、かならずしも、 正確に示すことにならない点に注意されたい。正確な リレーションシップ は、「リレーションシップ の検証表」 （69ページ） を作成しなければ把握できない。