2004年 1月16日 サブセット 間の リレーションシップ >> 目次 （作成日順）
　　●　QUESTION 　　1つの セット のなかの サブセット 間には リレーションシップ が成立するか。
　　▼　ANSWER 　　原則として、成立しない。
2009年 2月 1日 補遺 　



　1つの セット のなかの サブセット 間の リレーションシップ は、原則として、「再帰」 として記述するのが正しい。1つの セット のなかで、サブセット 間の リレーションシップ を記述する例としては、いわゆる 「HDR-DTL」 構造があるが、特殊形である。というのは、Ｔ字形 ER手法が タイプ 理論を使わなかったので、「関係 ＝ モノ （2つの モノ の関係が、そのまま、1つの モノ になること）」 を記述するには──すなわち、「HDR-DTL」 構造を記述するには──、特殊形を使わざるを得なかったから。

　たとえば、以下を例にする。

　品目
　｛品目番号、品目名称、品目区分 コード、・・・｝ [ R ]

　
　品目のなかで、製品と半製品と原材料が記述され、それらは区分 コード を使って区分されているとする。
　区分 コード があれば、サブセット を生成するが、製品構成 （部品構成） は 「再帰」 を使って記述される。

　　品目 [ R ]＿＿＿｛品目番号 (R)、品目番号 (R)｝ [ 品目. 品目. 再帰 ]
　　　｜
　　　× 品目区分 コード
　　　│
　　　├｛品目番号、品目名称、品目区分 コード、・・・｝ [ 製品 ]
　　　│
　　　├｛品目番号、品目名称、品目区分 コード、・・・｝ [ 半製品 ]
　　　│
　　　└｛品目番号、品目名称、品目区分 コード、・・・｝ [ 原材料 ]

　
　ちなみに、１つの認知番号のなかで、「階 （型）」 の違う モノ が扱われていて、しかも、区分 コード が定義されていないなら、サブセット は記述されない。たとえば、事業所 コード のなかで、事業所と部門が混ざっている、とする （事業所と部門を見わけるために、たとえば、認知番号のなかで値として D が記述されていれば、部門とする）。
　とすれば、組織構成を記述するには 「再帰」 しかない。

　事業所
　｛事業所 コード、事業所名称、・・・｝ [ R ]

　事業所. 事業所. 再帰
　｛事業所 コード (R)、事業所 コード (R)｝ [ 再帰 ]

　この記述を、そのまま、読めば、事業所の間で、所轄関係が成立しているように判断するかもしれない。事業所 コード のなかに部門 コード が混ざっている、ということは、アトリビュート・リスト に記述されるべきであって、データ 構造として記述されない。なぜなら、部門を認知する コード がないから──事業所 コード のなかで意味を付与しているにすぎないので、アルゴリズム として扱われるから。

　事業所 コード のなかに部門が混ざっていることを注意するために、以下のような構造 （サブセット 間の リレーションシップ） を記述した、とする。

　　事業所 ｛事業所 コード、事業所名称、・・・｝ [ R ]
　　　｜
　　　×
　　　│
　　　├｛事業所 コード、事業所名称、・・・｝ [ 事業所 ]
　　　│　　　｜
　　　｜｛事業所 コード (R)、事業所 コード (R)｝ [ 事業所. 部門. 対照表 ]
　　　│　　　｜
　　　└｛事業所 コード、事業所名称、・・・｝ [ 部門 ]

　
　　この記述は 「ルール 違反」 である（！）　この記述はＴ字形 ER図ではない。
　　なぜなら、サブセット を生成する正当な コード がない。しかも、2項関係として、同じ認知番号が （R） とされるのは 「再帰」 であって、「対照表」 ではない。

　　小生が意味論を毛嫌いする理由は、この点にある。たとえば、「現実世界の記述」 として、事業と部門という主体があって、それぞれの主体集合の間には リレーションシップ が成立して組織が構成されているというふうに、概念設計のなかで記述しても、論理設計では、事業所 コード の再帰としてしか記述されない。概念設計の アウトプット を論理設計の データベース 構造として変換することは徒労だと小生は思っている。部門 コード を定義するのが 「現実の世界を正しく記述する」 ことになると言うのであれば、そんなことは、事業所 コード の乱れとして認識されている。

　　概念設計と論理設計の間には、共通の論理形式などない。概念設計が データベース 化の対象を扱うというのであれば、論理設計のなかで、データベース 化の対象として認知番号を付与されて モノ がそうであって、なんらかの認知番号 （主体として認知するための判断基準） を付与されていない モノ は データベース 化の対象にはならない。認知番号を付与された モノ （entity） は、現実世界のなかで認知された モノ （事象、事物） の 「影」 かもしれない。この影を注視すればよい。そうすれば、影を写している モノ （事象、事物） を判断することができるし、それぞれの企業が、事業のなかで、モノ （事象、事物） を、どのように観ているのか、という文化 （モノ の見かた）も判断できる。

　


[ 補遺 ] （2009年 2月 1日）

　サブセット 間に リレーション が存在するという現象は、関数としたら、多値関数です──あるいは、ふたつの関数の合成 [ 合成関数 ] です。そして、その合成関数が entity を示すのであれば、その entity は、クラス 概念 （具象 カテゴリー、ファンクター） として説明しなければならないでしょうね。サブセット 間の リレーション は、セット 概念 （部分集合の概念） のみでは説明できない。

　本 エッセー で示した例は、サブセット 間に リレーション が存在する現象ではなくて、個体指定子 （entity-setter） の値が間違っている現象を なんとか サブセット 形態で対応しようとした例です──そして、それは、本 エッセー のなかで説明したように、間違った対応法です。とういうのは、モデル は、「妥当な構造」 と 「真とされる値」 の ふたつを実現しなければならないのですが、TMD （Ｔ字形 ER図） は、あくまで、「妥当な構造」 を示す形式的構成図であって、「真とされる値」 は アトリビュート・リスト で記述されるべきです。この ふたつ （「妥当な構造」 と 「真とされる値」） を混同してはいけない。本 エッセー で例示した 「部門」 を、もし、「事業所」 との関係のなかで定立したいならば、当然ながら、「部門」 を entity として認知しなければならないし、「部門」 を個体として認知するのであれば、コード 体系のなかに部門 コード を定義するように エンドユーザ と協議すべきでしょうね。

　なお、本 エッセー のなかで、「影」 などという文芸的な比喩を使っていますが、当時、私は、いまだ、「関数」 を的確に把握していなかったので、そういう曖昧な比喩を使ったのでしょうね。モデルは、以下に示す手続きで構成されます。

　　　「合意」 された認知 → 「L-真」 の構成 → 「F-真」 の験証

　その手続きを図式で示せば、以下のとおり。

　　　　　　　　　　　　　　　　　　（F-真）
　　┌──────────────────────────────────┐
　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　┌───────┐　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　│　　　　　　　│　　　　　　　　　　　　　　　　│
　　│　　　　　　　　─┘　　　　　　　└─　　　　　　　　　　　　　　　↓
　　y （形式的構造）　←　　　　f　　　　←　x （語彙） ← 「情報」 ← 現実的事態
　　　　　　　　　　　─┐　（L-真）　　┌─
　　　　　　　　　　　　│　　　　　　　│
　　　　　　　　　　　　└───────┘

　すなわち、「情報 （帳票、画面など）」 を input にして構成される モデル は、およそ、「影」 などではなくて、モデル は、かならず、現実的事態に対して以下の 「T-文 （真理条件）」 で テスト されて 「真」 を問われるはずです。

　　　　文 「p」 が真であるのは、時刻 t において、事態 p と一致するとき、そして、そのときに限る。

　したがって、「影」 などという言い訳がましいことを言わなくても宜しい。




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