2005年 8月 1日 基準編-9 リレーションシップ は アクセス・パス >> 目次にもどる
2010年 7月 1日 補遺  

 

 基準編-9 は、いまになって読み返せば、文の歯切れはよいが、考えかたの歯切れが悪い。
 リレーションシップ は、アクセス・パス である、というふうに割り切りなさい、と記述しているが、もっと親切に述べるのであれば、リレーションシップ の網羅性を、ここで記述すべきだった、と思う。たとえば、以下のように。

 

┌───────────────────────┐
│        受注照会画面         │
│                       │
│ 顧客番号:×× 顧客名称:××××××   │
│ 受注番号:×× 受注日:××××-××-×× │
│                       │
│ 品目コード 品目名称  受注数  品目単価 │
│  ×××  ××××   99   999 |
└───────────────────────┘

▼ リレーションシップの検証表
┌────┬────┬────┬────┐                 
│    │ 顧客 │ 受注 │ 品目 │                 
├────┼────┴────┴────┤                 
│ 顧客 │ 再帰           │                 
├────┼────┐         │                 
│ 受注 │  ○ │ 再帰      │                 
├────┼────┼────┐    │                 
│ 品目 │    │  ○ │ 再帰 |                 
└────┴────┴────┴────┘                 

┌─────────────────────────────────┐
│リレーションシップの検証                     │
├───────────────┬─────────────────┤
│               │                 │
│成立している関係を記述する。  │成立していない関係を検証する。  │
│(○を使って記述する。)   │(成立するかどうかを検証する。) │
│               │                 │
├───────────────┼─────────────────┤
│               │                 │
│顧客と受注は成立している。  │顧客と顧客の再帰は可能か?    │
│受注と品目は成立している。  │顧客と品目の関係は可能か?    │
│               │受注と受注の再帰は可能か?    │
│               │品目と品目の再帰は可能か?    │
│               │                 │
├───────────────┴─────────────────┤
│(1)3つの entity 間に成立する関係の可能態は6つである。    │
│(2)現実に成立している関係は2つである(1/3の成立である)。 │
│(3)関係(ビジネス・ルール)の可能性として2/3の余地がある。 │
└─────────────────────────────────┘

 
 リレーションシップ は、アクセス・パス である、というふうに割り切りなさい、と述べた理由は、事業過程そのものを対象にして、個体のあいだに成立する 「関連」 を、すべて、把握することは、われわれ (システム・エンジニア) には、できないのだから、管理過程のなかで使われている 「情報」 を対象にして、「情報」 のなかで、しかじかの個体が、ほかの個体に対して、どのような 「関連」 を考えられているか、という点を理解するように促しているのである。
 「情報」 のなかに記述されている 「関連」 は、「明示的 (explicitly)」 である。したがって、それらの 「関連」 は、データ 構造のなかで示されなければならない。

 いっぽう、「情報」 のなかで認知されている entity のあいだに、(「明示的」 ではないが、) 「可能態」 として成立する 「関連」 があるかもしれない。言い換えれば、いまの管理過程のなかで、いくつかの entity のあいだで、「関連」 を認知していないが、もし、それらのあいだで、あらたな 「関連」 を認知すれば、あらたに、「有意味な情報」 を作ることができるかもしれない。いわゆる 「現状把握と改善案提言」 ということを考えるなら、やはり、ここで、「リレーションシップ の検証表」 を述べるべきだった、と思う。 □

 



[ 補遺 ] (2010年 7月 1日)

 「黒本」 で述べた 「リレーションシップ は アクセス・パス である」 という記述は、のちに、「赤本」 で導入した 「(導出的な) L-真」 (生成規則、構文論)・「(事実的な) F-真」 (指示規則、意味論) を使って、正確に整えられました。したがって、「赤本」 以後では、(「黒本」 で記述した) 「リレーションシップ は アクセス・パス である」 などという粗雑な言いかたをしないようになりました。

 無論、リレーション は、「有向 グラフ」 において 「道」 なので、「path」 ですが、TM (および、TM’) では、リレーションシップ という語を使わないで、関係主義の 「関数」 を強く意識して、リレーション という語を使っている点──用語の使いかたを変えたこと──を注意していてください。





  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む