2004年 3月16日 作成 「基準編第10章 (関係の論理)」 を読む >> 目次に もどる
2006年12月16日 更新  




「意味の対象説」 と 「意味の使用説」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 情報のなかに記述されている認知番号を使って entity を定立して、同様にして、情報のなかに記述されている明示的な関連を使って リレーションシップ を措定して、4つの推論 ルール を使って 「構造」 を組めば、だれが作成しても、同じ スキーマ (diagrammatic representation) になる
 コード 体系は、私的言語ではない。 □

 



[ 補遺 ] (2006年12月16日)

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

 (1) 「構造化」 型
 (2) 「非構造化」 型

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

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

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

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

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

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

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

 





  << もどる HOME すすむ >>
  「論理データベース論考」を読む