2022年 1月15日 「12.2 直積と 『コッド 関係 モデル』」 を読む >> 目次に もどる


 システム・エンジニア や プログラマ が データベース に係わる仕事をしていて コッド 正規形を知らないなんてことは有り得ないし、コッド 正規形は 1970年代に (集合算を前提にして) 「一般手続き」 となっているので、今さら 本節で コッド 正規形を説明する必要もないでしょう (コッド 正規形の議論は、今から遡れば 50年近く過去の話です)。コッド 論文を基底にして リレーショナル・データベース (RDB) が マーケット に現れたのが 1970年の終わり頃です、そして 1980年代に RDB は世界中に普及しました──ひょんなことから 1980年代前半に私は世界初の RDB を日本に導入普及する仕事に就いた。RDB は日本に先例がなかったので、私は、RDB を世界で初めてつくった ADR 社 (米国) に たびたび 出張して、RDB の internals を直接指導してもらいました。RDB を日本に普及する際、当初、世間から強烈な抵抗があった (私が勤めていた会社内ですら、RDB に対して スゲー 抵抗があった、当時の 「思い出」 話を綴れば ゆうに一冊の書物をかくことができるでしょう-笑)。そして、その後、RDB は世界中で導入された、今更 RDB とあえて言わなくても、現代では データベース といえば RDB でしょう。

 コッド 氏は数学者です。コッド 氏がつくった関係 モデル のことを コッド の Set theory (集合論) と云うこともある。コッド 氏は、直接集合を使って、n-項 (多項) の関係式でもって モノ (現実的世界の事実) を表しました。n-項関係式は次のとおりです──

    R{ s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn ∧ P (s1, s2,・・・, sn) }.

 この直積集合の一般式は 「選択公理」 を使って説明できます──すなわち、「それぞれの 『空でない』 集合 (set) から、それぞれ一つずつ元 (element) を選んできて、それらの元を 『並べたら』[ P (s1, s1,・・・, sn) で示されている並び ]、それも集合 (tuple、タプル) となる」 ということ。N-項関係を一組にした式を タプル (tuple) と云います。タプルに値が充足された状態を テーブル (table) と云います、テーブル のそれぞれの項の縦列を column と云い、テーブル の横列 (すなわち、行) のことを row と云います。

 正規形はタプルで記述されますが、テーブル として値が充足されたとき、ひとつの集合の元 (メンバー) は縦列に列挙されているので、集合算は 構文論として column をひとつの単位 (logical view) とします、複数の column を単位として view を構成することもできる。いっぽうで、モノ (現実的世界の事実) としての 「意味」 は、R{ s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn ∧ P (s1, s2,・・・, sn) }が記述しています。すなわち、コッド 正規形では、項の演算 (構文論) は縦列でおこなわれ、モノ の意味 (意味論) は横列 (行) で記述される、というのが基本です。しかも、数学では、モノ が一意であるかどうかをさておいて、モノ を一意にする アルゴリズム があるというのが モノ (すなわち、無定義語としての項) の扱いかたです。したがって、直積集合の全体が一意であればいいということです。コッド 正規形では、R{ s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn ∧ P (s1, s2,・・・, sn) } が全体として一意であればいいということ。ここで問題となるのが コッド が導入した primary-key です。

 今さら言うまでもないと思うのですが、念のために言っておけば、テーブル は flat file です。数学では、モノに対してキー(index-key)という「データを効率的に検索するための索引情報」は考えない。コッド 氏が導入した primary-key は、構文論的にはタプルの関数従属性を検証するための最小値の項であって、意味論的にはタプルをひとつの モノ とみなすための個体指定子としての役割なのです。しかも、構文論が先で意味論は後という論理的意味論のおいては、primary-key の値が一意かどうかは正規形が整って値が充足されてみなければわからない、primary-key の値が一意であるという前提 (仮定) に立って正規形を作っているだけです。しかも、コッド 氏は、「関係」 は 「関数」 f (x1, x2,・・・, xn) とみなしているので、x1, x2,・・・, xn は大小関係で並んでいなければならないし、それらの項の起点となる primary-key は最小値でなければならないのですが、実際の データ の値は大小関係では並べられない──たとえば、氏名・年齢・住所などの値は、大小関係で並べられない。だから、コッド 氏は、正規形では数学的な 「関係 (relation)」 という語を使っているけれど、厳正に言えば、実際の データ は大小関係で並べられないので、「関係」 の代わりに日常語の 「関連 (relationship)」 という語を使ってもかまわない、というふうに論文 (チューリング 賞受賞のときの記念講演を起稿した論文) のなかで言ったのです。単純に言い切ってしまうなら、(数学の論文を執筆するのでないのなら──言い替えれば、実務的には──) 「関係」 でも 「関連」 でも どっちでもかまわない、あえて言うなら、データ の 「並び」 を意識していれば 「関係」 を使えばいい、ということ。「関係」 と 「関連」 について、ぐだぐだ言っている人たちがいるそうだけれど、学問 (学術論文) 上の議論であれば それらを厳正に使い分けなければならないけれど、実務的には 「関係」 「関連」 の どちらを使っても宜しい。

 さて、primary-key が、意味論上、個体指定子を表すのであれば、直積集合 R{ s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn ∧ P (s1, s2,・・・, sn) } において、その他の項すべて (属性値集合のすべて) を包括する項です──たとえば、従業員 { 従業員番号、氏名、年齢、住所、・・・} において、primary-key の従業員番号は、従業員そのものを表していて、{氏名、年齢、住所、・・・} を包括する項です、だから 従業員番号を使って他の項 {氏名、年齢、住所、・・・} に対して構文論上 「1-対-1」 対応 (関数従属性) を問うことができる。言い替えれば、R{ s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn } において、primary-key の s1 は R そのものを指示しているということです──つまり、primary-key は、クラス f (x) なのです。しかし、データ (値) としては、primary-key は他の項と同じ階に属する。この階の ズレ が意味論では大きな論点になる。

 モデル TM は、コッド 正規形の primary-key の役割に注目しました──モデル TM では、コッド 正規形を T字の記法で記述します、そして コッド 正規形の primary-key を個体指定子とみなして、T字の左側に記述して、その他の項は (T字の) 右側に記述します。モデル TM では、T字の右側に定義される項は コッド 正規形に準じていればいいと考えています。モデル TM が モデル 作成技術として重視したのは T字の左側 (個体指定子) です。その個体指定子を項にして、現実的事態の 「構造」 (項と項との関係) を記述することを モデル TM は目的としています。したがって、意味論的には、モデル TM は コッド 正規形に比べて、階が一つ上なのです。しかも、項の 「並び」──すなわち、事業活動 (プロセス) の先行-後続 関係──を明らかにして事業構造を写像するので、個体指定子を event (出来事・取引・行為) と その補集合に区分けして、event を 「並べる」 という関数を使っています。モデル TM では、「関係」 を 「関数」 とみなしていて、「関連」 という語を使わない。モデル TM は、コッド 正規形を拡張した モデル 作成技術なのです。コッド 正規形という手本がなければ、モデル TM は決して生まれていなかった、、、コッド 博士に感謝しています。 □

 




  << もどる HOME すすむ >>
  目次にもどる