2009年10月16日 「実践編-5 コード 体系方式」 を読む >> 目次にもどる
2018年 8月 1日 補遺  


 

 本編では、TMD (TM Diagram、T字形 ER図) の作成法として、「コード 体系方式」 を説明しています。

 「コード 体系方式」 は、「データ 転記法」 とも云います。というのは、ひとつずつの 「データ」 の 「意味」 を判断して、entity を作ってゆく やりかた なので。

 「コード 体系方式」 の ルール は、前回説明した 「命題論理方式」 と同じで、以下のとおりです。

 (1) 「××番号」 「××コード」 の 「個体指定子」 を左側に記入する。

 (2) それ以外の 「性質 (の述語)」 を右側に記入する。

 
 「コード 体系方式」 は、これらの ルール を (「命題論理方式 [ 情報仕訳法 ]」 で使っている 「仕訳帳」 を はしょって、) ひとつずつの 「データ」 に適用しているだけです。

 ちなみに、「コード 体系方式」 を私は、近年、ほとんど指導しなくなりました。というのは、「コード 体系方式」 では、ひとつずつの 「データ」 の 「意味」 を知っているということが前提になるので──「コード 体系方式」 では、最初の段階で entity を生成しないので、たとえば、その 「情報」 のなかに個体指定子が出てこないにもかかわらず、それぞれの 「データ」 を元にして恣意的な entity を作ってしまう危険性があって、「ユーザ 言語を変形しないで 『形式的構造を構成する』」 という TM の モデル 観を軽視されるかもしれないので──、(それらの データ を直接に扱っている エンドユーザ を除けば、) システム・エンジニア には使いにくい やりかた でしょうね。「コード 体系方式」 は、「(分析対象になっている) 情報」 を事業過程のなかで実際に伝達している ユーザ が使うとき、そして、そのときに限る、としています。

 なお、(実践編-6 から実践編-10 まで 「練習問題」 を使った作図例を具体的に示しているので、本 エッセー で説明することを省略して、) 次回は実践編-11 を説明します。 □

 



[ 補遺 ] (2018年 8月 1日)

 本文中で、「コード 体系方式」 を使わない理由を述べていますが、この後で [「赤本」 を出版した後で ] 更に わかったことは、「命題論理方式」 のほうが 「『関係』 の網羅性」 を検証するのに適しているということです。

 当時 [「赤本」 を出版する以前 ]、「『関係』 の網羅性」 を検証するために マトリックス 表を使っていたのですが (「赤本」 120ページ 参照)、「命題論理方式」 の仕訳帳を使ったほうが効率的だということに気付きました──マトリックス 表を わざわざ作成しなくても、「命題論理方式」 の仕訳帳を使って 「『関係』 の網羅性」 を検証できることが わかった。それ以来、私は セミナー で 「命題論理方式」 しか説明しなくなった次第です。それと同時に、「命題論理方式」 という言いかたもしなくなりました──「情報」 の中から モノ (存在) を認知する やりかた としか説明しなくなりました。






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