関数従属性と更新時異常

この投稿、近いうちに削除します。もう少し、うまくまとめて再度アップするつもり。

リレーション R 上の属性で、A が決まると B も決まるとき A → B と書く。このとき A を決定項、B を従属項という。決定項、従属項は属性の組み合わせでもよく、A → {B,C}、{A,B} → C、{A,B} → {C,D,E} もある。

A → {B,C} と A → B かつ A → C は同じことである。が、{A,B} → C と A → C かつ B → C とは同じではない。

A → A および {A,B} → A は自明。従属性を考えるときは自明な従属性は除いていい。

すべての属性が従属するような決定項をキーという。キーが複数の属性から成り立つ場合、その一部がそれ以外の部分に依存することがあってはいけない（既約）。キーでない、またはキーの一部でない属性を非キー属性という。キーは複数存在することもあるので、候補キーともいう。

ここで、関数従属性と更新時異常との関係について考えてみる。

データベースというのは「モデルのモデル」すなわち、現実のビジネスに対するユーザの見方（ユーザのデータモデル）のモデルであった。したがって、リレーション上の関数従属性もユーザのデータモデルを反映している。

更新時異常とは、更新したときにユーザのデータモデルと不整合を起こす、または不整合を防ぐために何らかの異常な操作をしなくてはならないことだと定義できそう。

候補キーでタプルを識別し、更新・削除することは、結局ユーザデータモデル上で対応するインスタンスを更新・削除することに対応する。リレーション上で更新・削除されるのも１つのタプルだけであり、異常はない。

しかし、キーでない関数従属性の決定項でタプルを更新しようとすると、ユーザモデルでは更新されるべきインスタンスが１つに決まるはずだが（ユーザの頭の中にあるビジネスの見方に矛盾がない限りそうであるはず）、リレーション上では１つに決まらず複数のタプルを更新しなくてはならない場合がある。挿入しようとしても、決まらない属性があるのでタプルが決まらず、リレーションに挿入することができない。

したがって、このような更新時異常は、リレーション上の関数従属性の決定項がすべて候補キーになっていれば起こらない。こういうリレーションが、Boyce-Codd 正規形であり、ここまで正規化されると、関数従属性に起因する更新時異常は発生しなくなる。