2006年 6月16日

応用編-10　対照表が マスター・ファイル ?!

>> 目次に もどる

2011年 5月16日 補遺

　本節は、いま、読み返してみると、「赤本」 （「データベース 設計論──Ｔ字形 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 銀行の虎ノ門支店もある。したがって、「Ｆ-真」 を示す個体指示は、「銀行. 支店. 対照表」 が担う。

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

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

[ 補遺 ] （2011年 5月16日）

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

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

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

<< もどる

HOME

すすむ >>

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