2005年10月 1日 作成 推移従属性 と 「みなし entity」 >> 目次 (テーマ ごと)
2009年11月 1日 補遺  


 
● コッド正規形 (第三正規形)

 コッド 正規形では、関数従属性が、推移従属性として作用しないのが第三正規形である。


       関数従属性   推移従属性
      ┌<1対1>┐ ┌<1対1>┐
      │     ↓ │     ↓
   ┌──┴───┬───┴──┬──────┐
   │  キー  │  属性  │  属性  │  第三正規形
   ├──────┼──────┼──────┤
   │   a  │   b  │   c   │  {a, b}. {b, c}.
   │      │      │      │
   └──────┴──────┴──────┘

 
 たとえば、以下を考えてみる。

 {従業員番号、従業員名称、・・・、部門 コード、部門名称}.

 この形では、以下の関数従属が成り立っている。

 (1) 従業員番号 --> 従業員名称、・・・、部門 コード、部門名称
 (2) 部門 コード --> 部門名称

 
 したがって、第三正規形は、以下のようになる。

 {従業員番号、従業員名称、・・・、部門 コード (R)}.
 {部 門コード、部門名称}.

 なお、従業員 タプル のなかの部門 コード は、「外来 キー (foreign-key)」 である。

 
● みなし entity (推移従属性の除去)

 さて、以上の考えかたを応用して、以下の例を考えてみる。

 {受注番号、受注日、受注数、・・・、直送先名称、直送先住所}.

 
 なお、直送先名称 (の値) は 「一意」 である、とする (primary-key として使う、とする)。
 コッド 正規形では、(推移従属性に従って、) 以下のように、タプル は分割される。

 {受注番号、受注日、受注数、・・・、直送先名称 (R)}.
 {直送先名称、直送先住所}.

 
 TM では、以下のような構造になる。

 {受注番号、受注日、受注数、・・・}.
 {受注番号 (R)、直送先名称、直送先住所}.

 
 コッド 正規形では、直送先住所は、一度、記録されたら、重複は起こらないが、TM では、(みなし entity として扱っているので、) 直送先名称・直送先住所は、受注番号のつど、記録されることになる。もし、直送先住所を、つど、入力することを回避して、つねに、名称 ファイル あるいは 「resource」 として扱いたいのであれば、代替的な認知番号として継承している 「受注番号 (R)」 に対して、(同意された)「認知番号」 を──たとえば、「直送先 コード」とか──付与するように問うのが TM の考えかたである。

 TM が、「みなしentity」 の認知番号として、もとの entity の認知番号を継承した理由は、つねに、個体の 「認知」──つまり、コード 体系のなかで、同意された 「認知」──を問うためである。もし、直送先名称を、認知番号の代用とすることが同意されているなら──言い換えれば、直送先 コード の代わりとして、直送先名称を使うのであれば──、TM でも、文法に従って、以下の構造となる。

 {受注番号、直送先名称 (R)、受注日、受注数、・・・}. [ E ]
 {直送先名称、直送先住所}. [ R ]

 
● 推移従属性 と 個体の認知

 TM は、以下の点を、体系の起点としている。

 Entity である = Df 認知番号が付与されている対象である。

 
 推移従属性に対しても、この規約は適用されている。
 さきの例 (直送先) でいえば、{受注番号 (R)、直送先名称、直送先住所} は、受注のつど、直送先を記述していることを示していて、もし、そういう やりかた が妥当ではない、と判断するのであれば、直送先に対して、「resource」 として、なんらかの同意された認知番号を付与することを迫るのが、TM の考えかたである。



[ 補遺 ] (2009年11月 1日)

 TM では、拙著 「赤本」 以後、「認知番号」 を 「個体指定子 (entity-setter)」 という言いかたに改めました。というのは、「認知番号」 という言いかたでは、「○○ 番号」 「×× コード」 以外を認めないような印象を与えるので。「○○ 番号」 「×× コード」 以外でも、「認知番号」 (すなわち、指示語) として使う場合があります。たとえば、

 { 商品略称、商品名称、・・・ }.

 この構成では、「商品略称」 が 「認知番号」 です。
 「『○○ 番号』 『×× コード』 以外は 『認知番号』 にならない」 という謬見を抱かれないようにするために、「認知番号」 を 「個体指定子」 に変えた次第です。

 逆に、「「○○ 番号」 「×× コード」 であっても、「個体指定子」 にならないで、単なる 「名称 ファイル」──入力を簡便にするために導入された コード──にすぎないこともあります。たとえば、拙著 「赤本」 218ページ で示した 「支店 コード」 の例を参照してください。

 さて、本 エッセー で示した { 直送先名称、直送先住所、・・・ } において、「直送先名称」 を 「個体指定子」 にすることは争点となるでしょうね。たとえば、「直送先名称」 として、以下のような様々な記述で入力された場合に、それらが同一であることを判断するのは難しいでしょう。

 (1) 株式会社 エス・ディ・アイ [「株式会社」 と 「エス・ディ・アイ」 のあいだに スペース 有り ]
 (2) 株式会社エス・ディ・アイ [「株式会社」 と 「エス・ディ・アイ」 のあいだに スペース 無し ]
 (3) (株) エス・ディ・アイ    [「株式会社」 の略語を使う ]
 (4) 株式会社SDI
 (5) 株式会社 SDI
 (6) (株) SDI

などなど。

 こういう名称が 「備考」 欄に記入される名称であれば たいした問題点にはならないのですが、上述したような { 直送先名称、直送先住所、・・・ } の第三正規形において、直送先名称が primary-key として使われるのであれば、大問題でしょう。名称記入法の規約を徹底的に守るようにするのも一法ですが、ユーザ にとっては不便でしょうね。とすれば、名称を コード 化したほうがいいでしょう。ただし、システム・エンジニア が勝手に コード 化してはいけない──言い換えれば、ユーザ が仕事で使っていないような語彙を モデル のなかに導入してはいけない。コード 化するのであれば、かならず、ユーザ の 「同意」 を得なければならない。なぜなら、モデル は、「現実的事態」 を コンピュータ のなかに形式化するのが目的であって、事業の 「意味」 に対して形式的構造を与えるのであれば、ユーザ 言語を変形しないというのが原則だから。

 TM の 「みなし entity」 は、「F-真」 の個体 (「事実」 との対比で 「真」 が実現されている個体) を認知するのが第一目的ですが、「F-真」 として認知された個体 (みなし entity) に対して 「個体指定子」 を付与するかどうかは、ユーザ と協議してください。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識