2006年 6月16日 応用編-10 対照表が マスター・ファイル ?! >> 目次に もどる
2011年 5月16日 補遺  


 本節は、いま、読み返してみると、「赤本」 (「データベース 設計論──T字形 ER」、2005年出版) の最終 ページ に示した 「組 オブジェクト」 に通じる論点をふくんでいる。本節では、以下の例を示している。

  会社
  {会社 コード、会社名称}

  部門
  {部門 コード}

  会社. 部門. 対照表
  {会社 コード (R)、部門 コード (R)、部門名称}

 
 [ 前提 ]

  (1) 会社 コード の値として、A と B がある。

  (2) 会社 コード の値として、01 と 02 がある。

   (2)-1 01 は 「経理部」である。
   (2)-2 02 は 「総務部」である。

  (3) (会社 コード、部門 コード) の値として、

   (3)-1 A01 は 「経理部」である。
   (3)-2 B01 は 「総務部」である。

 
 以上の構成では、部門 コード 01 が指示している対象は、(会社 コード との組のなかで、) 「経理部」 と 「総務部」 となって、それぞれ、相違する対象である。したがって、部門 entity のなかに、部門名称を記述することができない。ゆえに、対照表が 「resource」 として作用している。

 「赤本」 の最終 ページ に示した例は、以下の構成である。

  銀行
  {銀行 コード、銀行名称}

  支店
  {支店番号、支店名称}

  銀行. 支店. 対照表
  {銀行 コード (R)、支店番号 (R)、銀行支店名称}

 
 この例では、支店番号は、たとえば、「虎ノ門支店」 のように名称をもっている。ただし、虎ノ門支店といっても、A 銀行の虎ノ門支店もあれば、B 銀行の虎ノ門支店もある。したがって、「F-真」 を示す個体指示は、「銀行. 支店. 対照表」 が担う。

 
 さて、以上の 2つの例では、事実的な 「F-真」 を示す構成は、いずれも、対照表である。しかし、部門 entity と支店 entity では役割が違う。支店 entity は、正確に言えば、個体を指示しないが、名称入力を省力化する コード として使われている。言い換えれば、入力の簡便性を実現するために導入された コード である。しかし、部門 コード は、入力の簡便性のために導入されている訳でもないし、部門 entity は個体を指示する訳でもない。

 「銀行. 支店. 対照表」 は 「組 オブジェクト」 になるが、「会社. 部門. 対照表」 は 「組 オブジェクト」 にならない。「会社. 部門. 対照表」 では、ひょっとしたら、みずからの組織のなかで使っていた部門 コード──適用区域が限られていた部門 コード──を、(適用区域を超えて) 「連結」 向けに流用したがために生じた混乱かもしれない。 □

 



[ 補遺 ] (2011年 5月16日)

 本 エッセー で述べた例は、対照表が 「event」 とも 「resource」 とも判断できない典型例のひとつです。そして、対照表は、元来、「集合 オブジェクト」 の性質をもつのですが、ときに 「組 オブジェクト」 の性質をもつという典型例のひとつです。対照表の こういう性質は実地に使う場合に便利と云えば便利なのですが、ロジック 上 説明するのが とても難しい。

 対照表の この性質を きっちりと判断するためには、たぶん、タイプ 理論 (theory of types) を導入して、階を 1つ上にあげればいいのでしょうが、TM は セット 概念を使って第一階で演算することを基本形にしているので、タイプ を使わない。もし、タイプ を導入すれば、TM を根柢から作り直さなければならない。ただ、現時点で、TM は、2点を除いて──「event」 概念・「resource」 概念の導入と 多値関数の ファンクター を除いて──整合的で、かつ、実地の使用において ききめ を実証しているので、TM を根柢から作り直す必要性を私は認めていない。したがって、対照表が 「組 オブジェクト」 の性質を示す場合には、それはそれでいいと思う。

 勿論、「レーヴェンハイム・スコーレムの定理」 が示すように、タイプ を導入して他の公理系を作ることもできると思うのですが、今の私には それを探究する──タイプ を前提にした他の理論体系を作る──ほどの熱意がないので、だれか それを作ってくれることを期待します。







  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む