2006年 9月 1日

応用編-15　サブセット の擬態 （その 2）

>> 目次に もどる

2011年 8月 1日 補遺

　本節では、「最適化 （optimization）」 を扱っている。

　「最適化」 とは、同一 キー 構成の テーブル を統合する作業をいう。
　たとえば、以下を考える （青色の文字は、キー primary-key を示す）。

　　（1） ｛従業員番号、従業員名称、...｝.
　　（2） ｛部門コード、部門名称、...｝.
　　（3） ｛従業員番号、入社日｝.

　（1） では、従業員番号は従業員名称に対して 「1 対 1」 の関数従属性が成立しているし、（3） でも、従業員番号は有給休暇日数に対して 「1 対 1」 の関数従属性が成立している。したがって、（1） と （3） は、（関係 モデル の関数従属性を前提にすれば、） 構文論上、同じ主体を指示しているので、以下のように統合するのが正しい。

　　　　　｛従業員番号、従業員名称、入社日、...｝.

　さて、実地の データ 設計では、1つの アプリケーション （たとえば、生産管理など） に対して、DA （Data Analyst） が、複数、参加して、データ 構造を設計する。たとえば、以下を考える。

　（1） 画面 ｛S₁, S₂, ....S_n｝.
　（2） DA ｛DA₁, DA₂, DA₃｝.

　DA₁ は S₁ を、DA₂ が S₂ を、DA₃ が S₃ を担当したとする。そして、S₁ を資料にして作った データ構造のなかに、以下の テーブル があったとする。

　　　　受注₁ ｛受注番号、品目コード (R)、顧客番号 (R)、受注日、受注数｝.

　また、S₂ を資料にして作った データ構造のなかに、以下の テーブル があったとする。

　　　　受注₂ ｛受注番号、顧客番号 (R)、受注数｝.

　DA たちの データ 設計が終了したなら、手分けして作成された データ 構造は 1つに まとめなければならない。その際、「同一の認知番号」──キー と言っていない点に注意されたい──を付与された個体 （entity） は、以下のように、サブセット として扱う。

　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　│　　　　　　　受　注　　　　　　Ｅ│
　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　│受注番号　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　×　null
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　　　受　注　　　　　　　│　　　　　│　　　　　　　受　注　　　　　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│受注番号　　　　│受注日　　　　　│　　　　　│受注番号　　　　│受注数　　　　　│
　│品目コード（Ｒ）│受注数　　　　　│　　　　　│顧客番号（Ｒ）　│　　　　　　　　│
　│顧客番号（Ｒ）　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

　そして、サブセット が サブセット として周延しているかどうかを検証しなければならない。
　受注₁ は 「F-真」 だが、受注₂ は （受注₁ から導かれる） 「L-真」 にすぎない。したがって、受注₂ は、view であって、データ 構造として構成することは妥当ではないので、除去すれば良い。

　さて、さきほど、「認知番号」 は 「キー ではない」 と注意した。以下の 「みなし entity」 を考えてみる。

　　（1） ｛従業員番号、従業員名称、...｝.
　　（2） ｛従業員番号 (R)、入社日｝.

　「みなし概念」 は、TM の文法を超えて、意味論を強く適用した概念である。すなわち、TM では、「event」 および 「resource」 という意味論上の概念が導入されているが、さらに、entity に対して、意味論を強く適用して、1つの entity のなかで、「event」 の性質と 「resource」 の性質が co-locate しないようにした技術が 「みなし概念」 である。

　もし、関係 モデル を前提にして、構文論上、primary-key に対する関数従属性を適用すれば、「みなし entity」 は、「最適化」 の対象となって統合されなければならない。しかし、TM' 上 （意味論上）、従業員番号と従業員番号 (R) は、「ちがう個体を指示する」 とされるので統合しない──正確に言うなら、統合されて co-locate 状態になっていた性質を、逆に、切り離している。そのために、TM では、entity を 「認知」 する判断手段として、キー という概念を使わないで、「認知番号」 とした次第である。 □

[ 補遺 ] （2011年 8月 1日）

　取り立てて補足説明はいらないでしょう。

<< もどる

HOME

すすむ >>

「Ｔ字形ＥＲ データベース設計技法」を読む