2009年 8月16日 「実践編-1 リレーションシップ の検証表」 を読む >> 目次にもどる

 

 「実践編」 の一番はじめに 「リレーションシップ の検証表」 を置いています。「実践編」 において私が重視したかった点は、以下の 2点です。

 (1) 「リレーションシップ の検証表」 (「関係」 の網羅性)

 (2) 「アトリビュート・リスト」 (「制約・束縛」 の網羅性)

 いずれの リスト も、「網羅性」 を配慮しています──「リレーションシップ の検証表」 では、「『関係』 の網羅性」 を、「アトリビュート・リスト」 では、「『制約・束縛』 の網羅性」 を配慮しています。ちなみに、「アトリビュート・リスト」 は、次回の 「実践編-2」 で述べます。

 さて、「リレーションシップ の検証表」 は、「すべての entity のあいだの すべての 関係」 を調べるために用意された リスト です。すなわち、「a と b は 『関係がある』」 と断言できると同時に、「a と c は 『関係がない』」 ということも明言できなければ、言い換えれば、「関係がある」 と推測される事態のみを前提にして 「形式的構成」 を作っても完全性を実現できないでしょう。

 「リレーションシップ の検証表」 は、「情報 (たとえば、画面や帳票など)」 ごとに作成します。具体的な作成法は、「赤本」 に示した例を参照してください。「リレーションシップ の検証表」 を 「情報」 ごとに作る理由は、ひとつの 「情報」 は、ひとつの・まとまった単位の 「意味」 を示しているので、「関係」 (あるいは、「関係」 の意味) を確実に把握できるからです。

 たとえば、「赤本」 に示した例で、「顧客. 顧客. 再帰表」 を検討していますが、この再帰表は、例示された 「受注照会」 の文脈では、「しかじかの顧客と、かくかくの顧客は、ひとつの家族の構成員たちである」 ことを示しているかもしれないのですが、もし、「請求照会」 という 「情報」 (文脈) であれば、「しかじかの顧客からの受注は、かくかくの顧客が支払う」 ということを意味するので、「文脈」 のなかで 「意味」 を確認して 「関係」 を検討しなければならないでしょう。「『関係』 の意味」 は、つねに 「文脈」 のなかで示されるので、「情報」 ごとに 「リレーションシップ の検証表」 を作るしかない。

 「リレーションシップ の検証表」 は、事業を 「改善」 するときにも有用な リスト です。たとえば、もし、「a と c のあいだには 『関係がない』」 と 「今の事業のなかで」 判断されたとしても、もし、そういう 「関係」 を導入して新たな事態を構成した場合に事業を 「改善」 できるのであれば、そういう 「関係」 を導入したほうがいいでしょう。ただし、そういう 「改善案」 は、「現実を正確に記述したあとで」 おこなうべきであって、「現実」 の記述と 「改善案」 の導入を ごっちゃにしてはいけない。 □

 



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