2009年 8月16日 | 「実践編-1 リレーションシップ の検証表」 を読む | >> 目次にもどる |
2018年 6月 1日 補遺 |
(1) 「リレーションシップ の検証表」 (「関係」 の網羅性)
(2) 「アトリビュート・リスト」 (「制約・束縛」 の網羅性)
いずれの リスト も、「網羅性」 を配慮しています──「リレーションシップ の検証表」 では、「『関係』 の網羅性」 を、「アトリビュート・リスト」 では、「『制約・束縛』 の網羅性」 を配慮しています。ちなみに、「アトリビュート・リスト」 は、次回の 「実践編-2」 で述べます。
さて、「リレーションシップ の検証表」 は、「すべての entity のあいだの すべての 関係」 を調べるために用意された リスト です。すなわち、「a と b は 『関係がある』」 と断言できると同時に、「a と c は 『関係がない』」 ということも明言できなければ、言い換えれば、「関係がある」 と推測される事態のみを前提にして 「形式的構成」 を作っても完全性を実現できないでしょう。
「リレーションシップ の検証表」 は、「情報 (たとえば、画面や帳票など)」 ごとに作成します。具体的な作成法は、「赤本」 に示した例を参照してください。「リレーションシップ の検証表」 を 「情報」 ごとに作る理由は、ひとつの 「情報」 は、ひとつの・まとまった単位の 「意味」 を示しているので、「関係」 (あるいは、「関係」 の意味) を確実に把握できるからです。
たとえば、「赤本」 に示した例で、「顧客. 顧客. 再帰表」 を検討していますが、この再帰表は、例示された 「受注照会」 の文脈では、「しかじかの顧客と、かくかくの顧客は、ひとつの家族の構成員たちである」 ことを示しているかもしれないのですが、もし、「請求照会」 という 「情報」 (文脈) であれば、「しかじかの顧客からの受注は、かくかくの顧客が支払う」 ということを意味するので、「文脈」 のなかで 「意味」 を確認して 「関係」 を検討しなければならないでしょう。「『関係』 の意味」 は、つねに 「文脈」 のなかで示されるので、「情報」 ごとに 「リレーションシップ の検証表」 を作るしかない。
「リレーションシップ の検証表」 は、事業を 「改善」 するときにも有用な リスト です。たとえば、もし、「a と c のあいだには 『関係がない』」 と 「今の事業のなかで」 判断されたとしても、もし、そういう 「関係」 を導入して新たな事態を構成した場合に事業を 「改善」 できるのであれば、そういう 「関係」 を導入したほうがいいでしょう。ただし、そういう 「改善案」 は、「現実を正確に記述したあとで」 おこなうべきであって、「現実」 の記述と 「改善案」 の導入を ごっちゃにしてはいけない。
□ |
[ 補遺 ] (2018年 6月 1日)
本文中では、「リレーションシップ の検証表」 と記しているように、いまだ リレーションシップ という語を使っていますね。本文を綴った時が 2009年 8月なので、拙著 「モデルへの いざない」 (2009年 2月出版) を上梓した後なので、(リレーションシップ という語ではなくて) リレーション という語を使って当然なのに、どうして リレーションシップ という語を使っているのだろうか、、、我ながら謎です。「赤本」 では、いまだ 「黒本」 の用語を継承していたのかもしれない。現在、私は リレーションシップ (関連) という語を使わないで リレーション (関係) という語を使っています。というのは、「いざない」 以後、TM では、関係文法において、「関数 (関係)」 (並びを構成する規則) を かなり強く意識しているので。 その用語法のほかについて、本文に綴られている意見は現在も変わっていない。 ちなみに、「黒本」 では、リレーション という語を使うことはしないと私は宣言して、リレーションシップ という語を使うことを勧めていました。そして、「赤本」 では、「関連」 を 「関係」 とみなして使うとしています [「赤本」 の 68 ページ 参照されたい ]。「赤本」 は、今から振り返れば、新旧混成の産物になっていますね (苦笑)──現時点から観れば、過度的な (進化途上の) 中間物です。 |
<< もどる | HOME | すすむ >> | |
目次にもどる |