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) 画面 {S1, S2, ....Sn}.
 (2) DA {DA1, DA2, DA3}.

 DA1 は S1 を、DA2 が S2 を、DA3 が S3 を担当したとする。そして、S1 を資料にして作った データ構造のなかに、以下の テーブル があったとする。

    受注1 {受注番号、品目コード (R)、顧客番号 (R)、受注日、受注数}.

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

    受注2 {受注番号、顧客番号 (R)、受注数}.

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

             ┌─────────────────┐
             │       受 注      E│
             ├────────┬────────┤
             │受注番号    │        │
             │        │        │
             │        │        │
             └────────┼────────┘
                      |
                      × null
                      |
          ┌───────────┴───────────┐
          |                       |
 ┌────────┴────────┐     ┌────────┴────────┐
 │       受 注       │     │       受 注       │
 ├────────┬────────┤     ├────────┬────────┤
 │受注番号    │受注日     │     │受注番号    │受注数     │
 │品目コード(R)│受注数     │     │顧客番号(R) │        │
 │顧客番号(R) │        │     │        │        │
 │        │        │     │        │        │
 │        │        │     │         │        │
 └────────┴────────┘     └────────┴────────┘
 そして、サブセット が サブセット として周延しているかどうかを検証しなければならない。
 受注1 は 「F-真」 だが、受注2 は (受注1 から導かれる) 「L-真」 にすぎない。したがって、受注2 は、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 すすむ >>
  「T字形ER データベース設計技法」を読む