2005年 8月 1日 |
基準編-9 リレーションシップ は アクセス・パス |
|
2010年 7月 1日 補遺 |
|
┌───────────────────────┐ │ 受注照会画面 │ │ │ │ 顧客番号:×× 顧客名称:×××××× │ │ 受注番号:×× 受注日:××××-××-×× │ │ │ │ 品目コード 品目名称 受注数 品目単価 │ │ ××× ×××× 99 999 | └───────────────────────┘ ▼ リレーションシップの検証表 ┌────┬────┬────┬────┐ │ │ 顧客 │ 受注 │ 品目 │ ├────┼────┴────┴────┤ │ 顧客 │ 再帰 │ ├────┼────┐ │ │ 受注 │ ○ │ 再帰 │ ├────┼────┼────┐ │ │ 品目 │ │ ○ │ 再帰 | └────┴────┴────┴────┘ ┌─────────────────────────────────┐ │リレーションシップの検証 │ ├───────────────┬─────────────────┤ │ │ │ │成立している関係を記述する。 │成立していない関係を検証する。 │ │(○を使って記述する。) │(成立するかどうかを検証する。) │ │ │ │ ├───────────────┼─────────────────┤ │ │ │ │顧客と受注は成立している。 │顧客と顧客の再帰は可能か? │ │受注と品目は成立している。 │顧客と品目の関係は可能か? │ │ │受注と受注の再帰は可能か? │ │ │品目と品目の再帰は可能か? │ │ │ │ ├───────────────┴─────────────────┤ │(1)3つの entity 間に成立する関係の可能態は6つである。 │ │(2)現実に成立している関係は2つである(1/3の成立である)。 │ │(3)関係(ビジネス・ルール)の可能性として2/3の余地がある。 │ └─────────────────────────────────┘ いっぽう、「情報」 のなかで認知されている entity のあいだに、(「明示的」 ではないが、) 「可能態」 として成立する 「関連」 があるかもしれない。言い換えれば、いまの管理過程のなかで、いくつかの entity のあいだで、「関連」 を認知していないが、もし、それらのあいだで、あらたな 「関連」 を認知すれば、あらたに、「有意味な情報」 を作ることができるかもしれない。いわゆる 「現状把握と改善案提言」 ということを考えるなら、やはり、ここで、「リレーションシップ の検証表」 を述べるべきだった、と思う。 □
|
[ 補遺 ] (2010年 7月 1日) 「黒本」 で述べた 「リレーションシップ は アクセス・パス である」 という記述は、のちに、「赤本」 で導入した 「(導出的な) L-真」 (生成規則、構文論)・「(事実的な) F-真」 (指示規則、意味論) を使って、正確に整えられました。したがって、「赤本」 以後では、(「黒本」 で記述した) 「リレーションシップ は アクセス・パス である」 などという粗雑な言いかたをしないようになりました。 無論、リレーション は、「有向 グラフ」 において 「道」 なので、「path」 ですが、TM (および、TM’) では、リレーションシップ という語を使わないで、関係主義の 「関数」 を強く意識して、リレーション という語を使っている点──用語の使いかたを変えたこと──を注意していてください。 |
|
|||
|