2008年 5月 1日 「技術編-3 データ の認知 (entity とは)」 を読む >> 目次に もどる
2013年 5月 16日 補遺  


 本節の題名が 「データ の認知 (entity とは)」 となっていますが、(本書を出版したあとで、) 「個体の認知」 という言いかたに変えている点を、まず、注書きしておきます。

 さて、TM (T字形 ER手法の改良版) では、entity (個体) は、以下のように定義されています。

   entity である =Df認知番号を付与された対象である。

 この定義をどうして導入したかを述べる前に、「理論編」 で述べた以下の諸点を確認しておいてください。

 (1) モデル と 3 つの世界
 (2) 「真」 概念 (「L-真」 と 「F-真」)
 (3) 経営過程 (事業過程と管理過程)
 (4) 実体主義と関係主義

 TM は、事業過程のなかで伝達されている 「情報」 を対象にして、「情報 (画面、帳票、レポート など)」 のなかで示されている 「意味」 を分析して──「文法」 に従って、まず、「L-真」 を構成して──、次に、その 「意味」 が現実的事態と対比して、「F-真」 になっているかどうかを験証するように体系が組まれています。そして、「情報」 のなかで伝えられている 「意味」 は、勿論、「言語」 を使っているので、「言語」 を分析するために、TM は、モデル として、以下の体系を整えています。

 (1) 語彙 (ロジック の語彙、観察述語)
 (2) 文法

 語彙のなかで、(ロジック の語彙を除いた) 観察述語が、与件の 「情報」 に記されている語彙です。したがって、「情報」 のなかで使われている 「単語」 が語彙となります。言い換えれば、「情報」 の分析 (あるいは、解析) とは、いくつかの 「単語」 が並べられて、どのような 「意味」 を構成しているか、という点を調べることです。それらの単語のなかで──それらの単語の ほとんどが 「自然言語」 の語彙ですが──、いちぶ、人為的に付与された 「コード (あるいは、番号)」 が導入されています [ たとえば、「商品 コード」 とか 「従業員番号」 とか 「受注番号」 など ]。これらの 「コード」 は、しかじかの個体を指示するように、しかも、事業過程に関与している人たちの全員が同じ個体を指示できるように、「合意された (あるいは、従わなければならない)」 個体指示子として 「使われています」。

 TM は、この個体指示子を、(「理論編」 で検討した諸説を前提にして、) 「対象の認知手段」 として、しかも、「合意された認知手段」 として使っています。したがって、TM は、以下の手続きで、現実的事態を記した 「『情報』 の意味」 を記述構成します。

 (1) 「合意された対象 (個体)」 を作る。
 (2) 「合意された対象」 を前提にして、文法にしたがって、「L-真」 を構成する。
 (3) 「L-真」 の構成は、「真理条件」 に従って、「F-真」 を験証される。

 つまり、「『合意』 → 『L-真』 → 『F-真』」 という手続きで 「『意味』 を構成する (記述する)」 のが TM の手続きです。この手続きの起点になるのが、「個体の認知」 しかも 「合意された認知」 です──言い換えれば、事業過程のなかで伝達されている 「意味」 は、一人 (あるいは、数人の) システム・エンジニア の価値観 (あるいは、私智・憶測) で構成 (あるいは、記述) されるものではない、という点を強調しておきます。

 いったん、現実的事態を 「正確に」 記述したあとで、その 「『意味』 の構造」 の妥当性を問えば良い。
 その妥当性は、以下の 2 点から験証されます。

 (1) 「構造」 そのもの-の無矛盾生・完全性
 (2) 「構造」 の環境適用力

 以上の 2 点は、「構造 (構成)」 の妥当性に関する検討事項ですが、「構成」 の前提になっている個体 (あるいは、個体指示子のありかた) の妥当性も、勿論、問うべきでしょうね。 □

 



[ 補遺 ] (2013年 5月 1日)

 「個体の認知」 という主要概念は、「主題と条件」 に変更されました。
 したがって、entity は、次の様に構成されます。

   { 主題, 条件1,・・・. 条件n }.

 その様に変更した理由は、「情報」 分析である事をいっそう明らかにするためです。ユーザ の営んでいる事業を知らないで、事業を語る事はできないでしょう。ユーザ の体験は、「情報」(事前報告、進捗報告、事後報告) に記述されています。その 「情報」 を再構成して、「情報」 を現実的事態と結びつける (事実的な F-真を験証する) のが モデル です。そのためには、先ず、ユーザ たちのあいだで申し送りしている テーマ を定立しなければならない。そして、テーマ は、ユーザ が立てたものでなければならない。それが個体指示子 (主題) です──たとえば、「商品番号」 や 「受注番号」 など。ユーザ の事業を分析するのだから、システム・エンジニア が勝手な コード を持ち込んではいけない。

 モデル をそういうふうに見做 (みな) せば、「主題」 や 「条件」 を数学的な 「項」 として考えることができるので、モデル を記号演算の体系として整える事ができます。すなわち、{ 主題, 条件1,・・・. 条件n } を命題として、「主題」 と 「条件」 とのあいだの関数 (モノ の区分) と、それぞれの 「主題」 のあいだの関数 (モノ の並び、「関係」) を考えることができます。「主題」 と 「条件」 のあいだの関数は、コッド 正規形が明らかにしています──私もその考えかたを継承します。
 TM の特徴は、それぞれの 「主題」 のあいだの関数を明らかにした事です。





  << もどる HOME すすむ >>
  目次にもどる