C.J.Date 批判 - 有限会社アイティーコンサルティング

Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
Out of Date（関数従属性編）
（有）アイティーコンサルティング
米谷共比古
はじめに
C. J. Date 著 “An Introduction to Database Systems”は，
「古典にして MUST」だと
いう評価が定着しているらしい．拙論では，同著で使われている例題を俎上に載せて，そ
れらに対する別解（正解）を提示することにより，同著が「でたらめにして Must NOT」
であることを示す．
なお，同著の和訳も出版されているが，英語力が定かではなく，かつ，データベースの
初心者の集まりである某研究会のメンバーが分担翻訳したもので，さらに，監訳者の手抜
きで，術語の訳も統一されておらず，そもそも日本語として何が書いてあるかよくわから
ないので，本文中の引用は，原典（6th Ed.－最新版を新本で買うだけの価値が見いだせな
いので，古本で済ませた）から直接訳出した．
Date に限らず，関係理論をはじめとする従来理論の共通の欠点は，実装を保証しないと
いう無責任（卑怯といっても過言ではない）－あるいは，自理論によるモデルを実装でき
ないのは DBMS 側の欠陥であるといわんばかりの傲慢－にある．本論で提示した別解（正
解）には必ず実装例を添付してあるので，よくよく吟味されたい．
データモデルの作成に際しては，実体・関連の列挙に止まらず，制約条件もすべて考慮
に入れる必要がある．例題の別解中でも言及しているが，「同一人物が同一時刻に複数の場
所にいることはあり得ない」というような暗黙の制約を見逃しがちなので，注意が必要で
ある．さらに，上記のような制約を，関数従属性を用いて表現する方法も紹介する．読者
は，Codd も Date も，さらには，彼らの追随者達も見逃していた関数従属性の本当の使い
方をも知ることができるであろう．関数従属性では，仮に正しく使用したとしても，現実
の問題に太刀打ちできないのに，その正しい使い方を知らないとは，何をか言わんや．論
理的には，否定の否定は肯定であるが，関係理論陣営にとっては残念なことに，間違った
方法論の使い方を誤っても，正しい結果は得られない．
本論の表題 “Out Of Date” は，以下の 3 つの意味を含んでいる：

例題は Date の著書からの引用（Quotes Out Of Date’s）
．

Date は時代遅れである（Date is Out of Date）
．

Date から脱却しよう（Get Out of Date !）
．
なお，本稿は，関数従属性を使用する問題に限定するものとし，多値従属性を使用する
問題は別稿に譲る．
［参考］本稿で取り上げた例題の“正解”を Microsoft SQLServer で実装したものを，次
の URL に掲示している：http://predex.jp/ForNovices/OutOfDate_1.zip
1
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
例題１時間割（TIMETABLE）［原著 p.282］
［9.13］関係時間割（TIMETABLE）は，下記の属性を持つ：

Day of week：曜日（月－金）

Period：1 日の内の時限あるいはコマ（1－8）

Classroom：教室番号

Teacher：教官名

Lesson：授業名
タプル { D:d, P:p, C:c, T:t, L:l }は，d 曜日の p 時限に教室 c で教官 t が授業 l を教えると
いうことを表す．1 回の授業は，1 時限に収まる．1 週に行われる全授業は各々一意の授業
名を持つ．この関係ではどのような関数従属性が成立するか？また，候補キーを列挙せよ．
［Date の解］候補キーは：L，DPC，DPT．
［筆者補足］従って，成立する関数従属性は：L→DPCT，DPC→LT，DPT→LC．
Date の解の問題点
Date の解から導出される関数従属性は，それぞれ，次のような意味を持つ：
① L→DPCT：全授業が各々持つ一意の授業名 L が 1 つ決まれば，その授業が開講される
曜日 D，時限 P，教室 C，教官 T（の組合せ）が 1 つ決まる．
② DPC→LT：1 つの教室 C は，1 つの曜日 D・時限 P には， 1 人の教官 T が 1 つの授
業 L で使うことしかできない．
③ DPT→LC：1 人の教官 T は，1 つの曜日 D・時限 P には， 1 つの教室 C で 1 つの授
業 L しかできない．
上記の関数従属性の中で，②と③は現実に存在する物理的制約の表現である．さらに，こ
の制約は，まさしく物理的であるがゆえに，L を除外しても成立することに注意されたい－
② DPC→T： 1 つの教室 C には（そこで如何なる授業 L が行われるかに関わらず）
，1 つ
の曜日 D の 1 つの時限 P には， 1 人の教官 T しかいない．
③ DPT→C： 1 人の教官 T は（彼が如何なる授業 L を行うかに関わらず）， 1 つの曜日
D の 1 つの時限 P には，1 つの教室 C にしかいない．
（勿論，推移律による導出も可能である：②DPC→LT→T, ③DPT→LC→C）
．
それに対して，①では，授業名 L は，天下り的に与えられていることに注目されたい．
そこで，②と③をそれぞれ，Armstrong の公理系によって加工してみよう：
② DPC→LT
⇒
DPCT→LT
⇒ DPCT→LT→L ⇒ DPCT→L
（両辺に T を添加しても右辺は不変）（自明）
③ DPT→LC
⇒
DPCT→LC
（推移律）
⇒ DPCT→LC→L ⇒ DPCT→L
（両辺に C を添加しても右辺は不変）
（自明）
（推移律）
いずれからも，関数従属性 DPCT→L “曜日・時限・教室と教官が決まれば，授業が決ま
る”が得られる．これは，②と③の物理的制約のいずれか１つを満たせば，その後の追加
演算を経て，授業が決まることを示す．すなわち，授業の一意名（キー）として DPCT を
使うことができることを意味する．
2
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
一方，①から，L→DPCT であるから，結局，L と DPCT は，1 対 1 の関係にあること
になる．ここで，授業名 L は，天下り的に与えられていたことを想起していただきたい．
さて，そもそも授業名 L の一意性は何を根拠に保証されるのであろうか？換言すれば，
一意の授業名はどのようにして作成されるのであろうか？例えば，授業名 L が単純な連番
であると仮定すると，重複なく連番を付与するにはどうしたらよいのであろうか？答えは
上記の記述にある：DPCT と 1 対 1 になるように連番を付与する以外に方法はないのであ
る．これが，Date が犯した，とんでもない勘違いである．すなわち，L→DPCT は本末転
倒であり，これを容認すれば，ニワトリが先か卵が先かという循環論法に陥る．
［注意］実際には，実体（モノ）に対しても同様の方法で識別子が付与される．学生の
識別子として氏名だけでは不十分（同姓同名が存在する）なので，生年月日まで含めて（そ
れでも重複を避けられないなら，さらに本籍を追加する，etc.）各人を識別した上で，簡便
のため学生番号を付与するのである．しかし，構成の最小要素（element/component）で
ある実体は分解（decomposition）の対象とはならないのに対して，関連（実体同士の間だ
けでなく，実体と関連，関連同士などの間の関連も全て含む）は，構成物（composition）
であり，分解の対象となる．分解可能な構成物に分解不能なキーを与えるのは，矛盾であ
る．構成物は，構成要素の組成（組合せ）によって，一意に識別されるべきである（“モノ
だって分子や原子，さらには素粒子に分解できるではないか”という純粋に科学的な議論
はさておく－とりあえず，モノは名詞，コトは述語で語られる．このとき，述語の名詞形
“授業”から本来の述語“授業する”を抽出するのがポイントである－述語抽出法という
方法論の命名はこれに由来する）
．
述語抽出法の立場からは，実体（モノ）と関連（コト）は，名詞と（単）文の関係にあ
る．さらに，関連同士の高階の関連は，従属節を含む複文に対応する．
あるいは，実体と関連の間の関係は，中学理科で学んだ元素（酸素 O，水素 H）と化合
なぞら
物（水 H2O）の関係に擬えることができる．高階の関連は，いわば，高分子化合物である．
別解（真正の解）
上の解説で“煙に巻かれた”ような思いを抱かれた読者もおられよう．実際，Date は読
者を煙に巻いているのである（というよりも，Date 自身が五里霧中にあるという方が正鵠
を射ている）
．そこで，この煙霧を吹き払うために，次のように条件を変えてみよう：Date
の問題で使われている授業(L)を，科目(J)に置き換える．さらに，簡単のため（むしろ，こ
ちらの方が難しいので，Date は追随できないかも）
，１人の教官が複数の科目を担当し，１
つの科目を複数の教官が担当する（科目対教官＝多対多）とする．こうすれば，科目と授
業は別物になる－科目はモノ（実体）
，授業はコト（関連）であるから当然である．すなわ
ち，授業とは，科目を担当する教官がある曜日・時限にある教室でその科目を教えるコト
を指す－“教官は，自分が担当する科目を，ある曜日・時限に，ある教室で，授業する” ．
3
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
［9.13 改］関係時間割（TIMETABLE）は，下記の属性を持つ：

Dayofweek：曜日（月－金）

Period：1 日の内の時限（1－8）

Classroom：教室番号

Teacher：教官名

subJect：科目名
タプル { D:d, P:p, C:c, T:t, J:j }は，d 曜日の p 時限に教室 c で教官 t が科目 j を授業する
ということを表す．1 回の授業は，1 時限に収まる．
［1 時限の授業では，1 人の教官が 1 つ
の科目を教える．また，1 人の教官が複数の科目を担当するし，1 つの科目を複数の教官が
担当する．
］
図 1 に示す実体関連図では，関連授業する JTDPC について，DPC を主キーとし，TDP
に一意索引(Unique Index)を設定することにより，上記の 2 制約を実現している：
(1) 1 つの曜日(D)・時限(P)には，1 つの教室(C)では，1 人の教官(T)が 1 つの科目(J)しか
授業することはできない．すなわち，D(曜日) P (時限) C(教室) が決まれば，授業する
科目(J)と教官(T) －どの科目をどの教官が授業するか－が一緒に決まる：
DPC→JT．
(2) 1 人の教官(T)は， 1 つの曜日(D)・時限(P)には，担当する 1 科目(J)を 1 つの教室(C)
でしか授業することはできない．すなわち，教官(T)曜日(D)時限(P)が決まれば，授業
する科目(J)と教室(C)－どの科目をどの教室で授業するか－がそれぞれ決まる：
TDP→J, TDP→C．
［注意］(2)の 2 つの従属性の従属項（右辺）をまとめて TDP→JC としてはならない．(1)
の JT は関連（意味のあるかたまり）担当するであるのに対し，J（科目）と C（教室）は，
授業するで出会うまで，
“赤の他人”だからである．どうしても一緒に記述したければ，TDP
→J｜C （縦棒｜は OR を表す）とでもするしかない．図 1 の実装で，DPC を主キーに，
TDP を代替キーにしているのには，このような理由による． 2 つとも“対等の”候補キー
であるという理由で，TDP を主キーに，DPC を代替キーにする解は，例え結果（効果）は
同じであっても，モノゴトの成立ちを弁（わきま）えない“誤”解である．
授業する
JTDPC
UNIQ INDEX
日時室
DPC
担当する
JT
科目
J
日時
DP
教官
T
図 1
曜日
D
時限
P
教室
C
時間割の正解
以上が，関係理論陣営が知らない，関数従属性の正しい使い方である．
4
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
上の解法からお分かりのように，図 1 に示す＜授業(する)＞という最上位の関連は，底辺
の実体（モノ）から下位の関連を経て階層的（ボトムアップ）に構成されるコトであり，
先天的に存在するモノではない．高階の実体関連図では，モノ＝実体，コト＝関連となり，
コト＝関連は，モノ＝実体を起点とする再帰的構造を成す．さらに，関係理論との決定的
相違は，高階の関連は，低階の関連の実行時結合によって生成されるものではなく，低階
の関連は高階の関連（が成立するため）の必要条件である，ということである．すなわち，
＜授業する＞という関連が成立するためには，＜担当する＞と＜日時室＞という関連が成
立していることが必要であり，＜担当する＞という関連が成立するためには，
［科目］と［教
官］という実体が存在することが必要である．同様に，＜日時室＞が成立するためには，
＜日時＞，
［教室］が存在することが必要である．．
．したがって，高階の実体関連図を実装
した関係データベースでは，実体・関連の挿入は，低階から高階へ，削除は，高階から低
階へと行われなければならない（実際，実装においては，低階の関連が存在しない状態で
高階の関連を挿入しようとしたり，高階の関連を残したまま低階の関連を削除しようとす
ると，RDBMS が参照整合性エラーを通知する）
．
この特徴ゆえに，キー（識別子）は，実体にのみ付与され，関連のキーは，低階の関連
（最低階の関連は実体に他ならない）のキーの連結で表現される－図 1 の実体・関連の記
号内の英大文字の連結が，それぞれの実体・関連のキーの成分－components－と成立（な
りたち）－composition－を同時に表すことに注意されたい．
授業（する）というコトに先天的なキーを付与する Date の方法論は，コトとモノとを区
別できないという致命的な欠陥を先天的に抱えている．
図 1 の実体関連図は，次の文章の図式表現である：
［教官］は，自分が＜担当する＞［科目］を，＜定められた＞［曜日・時限］に，＜定
められた＞［教室］で，＜授業する＞．
（述語＜定められた＞は通常省略される）
．
さらに，関連を数学的述語1で表記すれば，上記の文章は，述語の入れ子で表現できる：
授業する（担当する（教官，科目）
，日時室（日時（曜日，時限）
，教室））
＜授業する＞とは，
［教官］が，＜担当する＞［科目］を，＜定められた＞［曜日，時限］
に＜定められた＞［教室］で行うコトである．
ただし，残念ながら，述語記法では，成分と成立は表現できるが，実体関連図と異なり，
多重度までは表現できない．しかし，モノゴトの成立を見るにはこれで十分であろう．本
技法では，従来の技法と異なり，実体・関連の構成は多重度の影響を受けない――多重度
は，関数従属性(functional dependency)に依存(depend)する関係理論では，決定的な役割
を担うが，本技法では，枝葉末節である．
1
数学的述語は，引数の値によって真偽が定まる．高階の数学的述語は，直下の低階の述語がすべて真の
ときのみ真となると定める．
“授業する”は，
“担当する”と“日時室”がともに真であるときのみ真とな
り，
“担当する”は，
“教官”と“科目”がともに真である（＝実在する）ときのみ真となる，etc., etc.,…
別の表現をすれば，低階の述語は高階の述語の必要条件である：“授業する”が真であるためには，
“担当
する”
と
“日時室”
がともに真であることが必要である，etc., etc.,… RDBMS の参照整合性制約は，
（RDBMS
の開発者は夢想だにしなかったであろうが）このような数学上の必要条件を実装したものである．
5
Copyright © 2014 by IT Consulting Co., Ltd.
例題２
All Rights Reserved
試験の成績順位（EXAM）［原著 pp.311-312］
候補キーの重複の 3 番目かつ最後の例は，属性学生(Student), 科目(subJect), および成
績順位(Position)を持つ関係試験（EXAM）に関するものである．試験のタプル{S:s, J:j, P:p}
は，学生 s が科目 j の試験を受けてクラス内で順位 p を獲得した，ということを示す．本例
については，以下の制約が成立するものと仮定する：同一の順位はない．すなわち，同一
科目において，複数の学生が同一順位を獲得することはない．
このとき，関数従属性は図 10.16 に示されるようなものとなる．
S
J
P
and
S
J
P
図 10.16 関係試験（EXAM）における関数従属性
ここには，またしても，2 つの重複する候補キー，すなわち，{S,J} と {J,P}がある．な
ぜなら，(1)学生 S と科目 J が与えられれば，対応する順位 P は唯 1 つに限定されるし，同
様に，(2)科目 J と順位 P が与えられれば，対応する学生 S は唯 1 人に限定されるからであ
る．しかしながら，この関係は，これらの候補キーが唯一の決定子であるため，BCNF で
ある．読者は，この関係については，本章ですでに論じたような更新異常が発生しないこ
とを確かめられたい．このように，重複する候補キーは，本章でこれまで我々が論じてき
た類の問題に必ずしもつながるわけではない．
Date の解の問題点
Date の考察（仕様記述）は，誤りである－というのが，言い過ぎだとしても，少なくと
も，特に図示は，舌足らずである．なぜなら，図 10.16 を数式で表現すれば，次のように
しかならないからである：
SJ→P and JP→S．
正しい仕様記述は，次のようでなければならない（Date の図解では，下線部の指定が曖
昧である）
：
(1) 学生 S と科目 J が与えられれば，その科目 J における順位 P は唯 1 つに限定される．
(2) 科目 J と順位 P が与えられれば，
その科目 J を履修した学生 S は唯 1 人に限定される．
以上を図示すれば，とりあえず，図 2 を得る（Date は，図 10.16 は図 2 を表記したもの
だと強弁するであろうが）
．
図 2
S
J
J
P
正しい関数従属性の図示の試み
ところが，図 2 においても，上で欠落を指摘した「SJ の J と JP の J は同じ科目を表す」
という根本的な制約は未だに明示されていない（同図における 2 本の→の出発点と到着点
によくよく注目されたい）
．そこで，図 3 のように書き換える．同図は，{SJ→JP}∧{JP→
6
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
SJ }，すなわち，{SJ←→JP}という関数従属性を表す：
S
図 3
J
P
正しい関数従属性の図示
しかし，図 3 の図解でも，まだ不十分である．順位 p は，科目 j ごとに存在する－数学
の 3 位は宮本，英語の 3 位は佐々木，国語の 3 位は吉岡である．したがって，上述の仕様
は，正確には，次のように言い換えなければならない：
任意の科目(J)が与えられれば，
その科目(J)における順位(P)の学生(S) を 1 人特定できるし，
その科目(J)における学生(S)の順位(P)を 1 つ特定できる．
すなわち，各科目(J)について，学生(S) と順位(P)は 1 対 1 に対応する．
これを図示すれば，図 4 を得る．同図が表す関数従属性は，J{S←→P} とでも記述する
ことができよう．
J
S
図 4
以上で見てきた
P
真に正しい関数従属性の図示
{SJ←→JP}＝J{S←→P}
という式の変形は， SJ＋JP＝J{S＋P}
と
いう中学校数学のレベルのものである！
MS SQLServer 2008~／MS Access 2010 での実装例を図 5 に示す．残念ながら，図 4
の図示をそのまま実装することはできないので，実装は，図 3 による．
UNIQ INDEX
SJP
Student
図 5
Position
subJect
“試験の順位”SJP の実装例
① 実体（キーを持つ）は，学生（Student）と科目（subJect）だけとし，順位（Position）
は，関連履修する SJ の非キー属性 P とする．関連履修するの主キー属性は S と J で
あるので，同一学生が(異なる時限に実施される)同一科目を重複履修することはできな
い：SJ→P．
② 関連履修するには，科目（subJect）と順位（Position）から成る Unique Index を追
7
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
加する．順位 P は，関連履修する SJ の非キー属性でありながら，Unique Index によ
り，科目（subJect）内での一意性が保証される： JP→S．
本例で使用した Unique Index は，関係理論では代替キー（alternate key）と称してい
るものの実装である．
なお，図 5 で，SJP という関連（に対応する関係）さえあれば，Student と subJcet，
Position という実体（に対応する関係）は不要であろう，という指摘は，浅薄である．確
かに，Position は属性でもよい（実際，同図では，属性の記号を用いて表現されている）．
しかし，Student と subJcet がそれぞれ独自に持つ非キー属性を関連 SJP の属性にするこ
とはできない（重複が発生する）
．このため，Student と subJcet は，例え，それらが，関
数従属性の決定項（左辺）に出現しなくとも，独立の実体でなければならない．
関数従属性を使用する際の前提は，論議領域の全てのデータ項目が提示されていること
である．しかし，教科書の例題等では，紙幅の制約から，論議領域の全容が提示されるこ
とはむしろ稀である．したがって，われわれには，提示された問題“の行間に暗黙裡”に
含まれる諸条件をも汲み取る力が要求されることを銘肝しなければならない．この能力は，
現場でのユーザ要件の吸い上げ段階では，必須である（エンドユーザは，彼らにとって暗
黙裡の―語る必要がない―条件を語ってはくれない）．
予想されるであろう Date 陣営からの反論とそれに対する論駁を以下に掲げる：
［反論］図 10.16 は，タプル{S:s, J:j, P:p} についての図示であるから，図 3 と同じものを
表すと考えるべきである．また，実装を図示すれば，結局，図 10.16 になるではないか．
［論駁］ならば，初めから図 3 を提示すべきであろう．後出しジャンケンとはこのことで
ある．一歩譲って，そうであるとしても，図 4 まで行けたであろうか？
別解（大山鳴動して鼠一匹）
図 10.16 の 2 つの関数従属性 SJ→P，JP→S の両辺にそれぞれ J を添加した後，J の重
複（添加した J は，もともと含まれていた J と同じものである）を除去すれば：
SJ→P ⇒ SJJ→JP ⇒ SJ→JP，
JP→S ⇒ JJP→JS ⇒ JP→SJ．
その結果，SJ→JP ∧ JP→SJ，すなわち，SJ←→JP という 1 対 1 の関数従属性を得る．
さらに，{SJ←→JP}＝J{S←→P} という変形から，図 4 を得る．逆に，元の関数従属性は，
自明として導出される： SJ→JP→P； JP→SJ→S．
この例に限らず，先の例でも示されたように，アームストロングの公理系(Armstrong’s
Axioms)は，極めて強力であり，関係理論陣営には猫に小判である．
8
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
別解（真正の解）
ここまでは，関係理論の手法のみを用いた解を提示してきたが，本節では述語抽出法に
よる別解（真正の解）を提示する．
提示された問題文から，以下のような述語（関連）を抽出することができる．
① 学生は科目を履修する：履修する（学生，科目）
② 科目は順位を用意する：用意する（科目，順位）
③ 学生は，科目の順位（の 1 つを）取得する：取得する（学生，科目，順位）
，
ただし，学生が取得する科目の順位は，自分が履修する科目が用意した順位である．即ち，
③’学生は，自分が履修する科目が用意した順位を取得する：
取得する（履修する（学生，科目）
，用意する（科目，順位）
）
以上の述語に多重度を加味して，高階の実体関連図を描けば，図 6 を得る：
取得する
SJP
履修する
SJ
学生
S
図 6
用意する
JP
科目
J
順位
P
“試験の順位”の高階の実体関連図
図 6 の実体関連図では，SJ←→JP という 1 対 1 の関数従属性が，SJ←＜SJP＞→JP と
いう多重度の指定で表現されている．実装では，関連取得するのキーは，
（その内部で関数
従属性が成立するか否かに関わらず）SJP であるため，その成分の SJ と JP の各々に一意
索引を設定して代替キーとすることで，SJ→JP ∧ SJ←JP を実現する．
応用問題
制約条件を次のように変更した場合の解を示せ：
順位に代えて，優・良・可・不可の 4 段階評価による成績を用意する．したがって，1 人の
学生が 1 つの科目について取得する成績（評価）は 1 つであるが，どの科目にも，同一段
階の成績（評価）を取得する学生が複数人存在し得る．
［関係理論の解］
SJ→P：学生と科目が決まれば，成績が 1 つ決まる（田中は数学が良）．
JP→→S：科目と成績が決まれば，複数の学生が決まる（数学が可の学生は鈴木と佐藤）
．
S→→JP：学生が決まれば，科目と成績が複数決まる（田中は数学が良で英語が可）
．
以上のような関数従属性と多値従属性は指摘されるであろうが，関係理論は，JP→→S; S
→→JP という双方向多値従属性を扱う術を持たないので，どのように分解されるかは筆者
の想像の及ぶところではない（さらに極言すれば，関係理論派は，自理論で解ける―しか
し実際には解けないのであるが―範囲の例題しか提示しない）．
9
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
［述語抽出法による解］
履修する対用意する＝多対 1 となる．図 6 の実体関連図において，SJ←→JP すなわち
J(S←→P) という 1 対 1 の関数従属性を，SJ→JP すなわち J(S→P) という多対 1 の関
数従属性に変更して図 7 を得る．実装では，図 6 の関連取得するのキーの成分の SJ と JP
に設定されていた一意索引のうち，JP の索引を撤去して SJ の索引だけを残せばよい．な
お，関連取得するのキーは SJP のままである．
取得する
SJP
履修する
SJ
学生
S
図 7
用意する
JP
科目
J
成績
P
“科目の成績”の高階の実体関連図
図 6 と図 7 を対比すれば，関数従属性は，DB スキーマの根幹（全体の枠組み）にかか
わる性質ではなく，枝葉末節にすぎないことが分かる．これは，関数従属性（functional
dependency）に依存（depend）する設計法からは正しい設計は得られないことを示す．
［発展問題］
図 7 中の関連取得する SJP には，
［関係理論の解］で与えた関数・多値従属性：SJ→P，
JP→→S，S→→JP が全て含まれていることを確認せよ．
結語
述語抽出法の立場からは，関数従属性だけではモデル化対象の現実世界を十分に記述す
ることはできない（別稿で論じるが，多値従属性は関数従属性を逆に眺めたものでしかな
い（X→→Y ⇔ Y→X）ので，関係理論では，関数従属性が全てである）．しかし，関係理
論派の旗手である Date は，関数従属性の正しい使い方さえもマスターしていない．
参考文献
[1]Date, C. J. : “An Introduction to Database Systems,” 6th Ed., Addison-Wesley
(1995)
10
Copyright © 2014 by IT Consulting Co., Ltd.
All Rights Reserved
付録
本稿の例題を Microsoft SQLServer 2014 で実装したものの Backup ファイルを以下の
URL に掲示してあるので，download 後，解凍してお試しあれ：
http://www.itconsult.co.jp/ForNovices/OutOfDate_1.zip
1. Microsoft SQLServer 2014 DataBases Backup データ
Date01TimeTabe
時間割（図 1 の実装例）
Date02ExamOriginal
試験の順位（図 6 の実装例）
Date02ExamExtended
科目の成績（図 7 の実装例）
2. テストデータ（Excel ファイル）
OutOfDate_1
上記 3 つのデータベースのテストデータを含む
（2014/06/07 脱稿）
11

Download Report