2001年10月15日 リレーションシッフ゜　の検証 >> 目次 （作成日順）
　　●　QUESTION 　　どの entity の間に リレーションシッフ゜ が成立するか判断する基準はあるか。
　　▼　ANSWER 　　ある。　entity の マトリックス を作成すればよい。
2006年11月16日 補遺 　




　「『関係の論理』 の テーフ゛ル （aRb を検証する テーフ゛ル）」 を画面ごとに作成すればよい。


具体例： 以下の画面例を使う。
受注入力画面
顧客番号：××××
受注番号：××××		 顧客名称：××××××××××
受注日　：××××-××-××
品目コート゛ 品目名称 受注数 品目単価
×××× ×××××××××× 999 9,999



　以下の 3つの identifier が認知できる。
　（1） 顧客番号
　（2） 受注番号
　（3） 品目 コート゛

　したがって、以下の 3つの entity が認知される。
　（1） 顧客
　（2） 受注
　（3） 品目

　そこで、以下のような、entity 間の マトリックス を作成する。
　（1） entity を縦列と横列に並べる。
　（2） マトリックス の対角線よりも上にある欄は使用しない。
　（3） それぞれの縦列を使って、関係が成立するかどうか調べる。


リレーションシッフ゜ の検証表
　 顧　客 受　注 品　目
顧　客 再帰？
受　注 ○ 再帰？
品　目 ？ ○ 再帰？



　以上の マトリックス から判断できることは、以下の 2点である。
　（1） それぞれの 「再帰」 を生成するのかしないのか。
　（2） 「顧客」 と 「品目」 の間には、対照表 （「validation-rule」） が成立するのかしないのか。

　以上の 2点を、その画面を使う エント゛ユーサ゛ に訊けばよい。



[ 補遺 ] （2006年11月16日）

　「リレーションシップ の検証表」 は、「情報」 ごとに作るのが コツ である。というのは、1つの 「情報」 は、まとまった 「意味」 を伝達するための単位として設計されることが多いので、文脈のなかで、entity の関係 [ 関係の意味 ] を検証しやすいから。たとえば、受注入力という文脈のなかでは、「品目」 の再帰は、「代替品目」 を示すかもしれないが、ほかの 「情報」 では--たとえば、生産過程では--、「部品構成表」 を示すかもしれない。
　実地の データ 設計では、リレーションシップ は、以下の手順で作成する。

　（1） まず、「情報」 のなかで明示的な リレーションシップ を構造図のなかに記述する。
　（2） 次に、「リレーションシップ の検証表」 を作成して、リレーションシップ の網羅性を検査する。

　データ 構造図として大切な点は、リレーションシップ が一つの取りこぼしもないように、網羅性を検証されていなければならないという点である。




　 << もどる HOME すすむ >>
　 データ解析に関するＦＡＱ