「一般的には、第3正規形まででよい」の根拠は何か？(3)

RDB

前回までのまとめ

  • 自分には正規化理論の再入門の必要が。いろいろ考え違いをしているので正さなくてはならない。
  • 勘違いの一例。
    • ×「BC正規形を第4正規形に分解して自然結合すると、それまで存在しなかった行が出現することがあるので、分解しない方がよい」
    • ○「どのように分解して自然結合しても、それまで存在しなかった行が出現するならば、そこには多値従属性がない。つまり、もともと第4正規形だった」
  • 非第4正規形の表をテーブルとして実装するのは、およそあり得ない。非第4正規形であるということは、２つの異なる概念の直積にすぎないということ。この点に限って言えば「第3正規形までで十分」なわけがない。

推移的関数従属性の勘違いを正す＝サロゲートキーの導入は非正規化ではない

もう一つ勘違いを発見した。
例えば商品コードを商品マスタのPRIMARY KEYにして、いろんなテーブルで商品コードをFOREIGN KEYにしていると、現実世界で商品コードの振り直しがあった場合、すごい面倒なことになる。
そこで、現実世界に誰にも認知されていない連番などのサロゲートキーをPRIMARY KEYとし、外部キー参照はその連番に対して行うことで、現実世界の変更に強いデータ構造にする。
で、このサロゲートキーは、正規化理論から見ると、一種の非正規化になるのだと、昨日まで思っていた。
なぜなら、
完全正規形である商品マスタに、

商品マスタ　{ 商品コード(PK), 商品名, 単価 }

サロゲートキーを導入すると、

商品マスタ　{ 商品ID(PK), 商品コード(UNIQUE), 商品名, 単価 }

商品ID --> 商品コード --> 商品名
商品ID --> 商品コード --> 単価
という推移的関数従属が発生し、第2正規形になってしまうから ... と。
非正規化しても更新時異状が発生しないのはなぜだろう、とずっと疑問に思っていた。


で、推移的関数従属の定義を調べなおすと、やっぱり勘違いしてました。
正確な定義はこう:

X,Y,ZをリレーションスキーマRの異なる属性とする。Rには次の3つの制約が成立しているとする。
X ---> Y
Y -/-> X
Y ---> Z
すると、これから次の2つの制約が成立する。
X ---> Z
Z -/-> X
このような時、ZはXに推移的に関数従属するという。

商品マスタにサロゲートキーを導入した場合は、上記の「Y -/-> X」を満たさない、つまり
商品ID --> 商品コード
商品ID <-- 商品コード
なので、推移的関数従属とは呼ばない。
またこの時、これ以上分解しなくても更新時異状は発生しない。
ということは、完全正規形のテーブルにサロゲートキーを追加しても、完全正規形のままだということ。

整理すると

整理すると、
×「推移的関数従属を放置しても更新時異状が発生しない場合がある」
○「放置しても更新時異状が発生しないなら、それは推移的関数従属ではない」

更新時異状が起きる条件は何か

なんというか、話が細かすぎるので、もうちょっと大枠で理解したい。
正規化の目的は、更新時異状の解消のため。
では、更新時異状が起きる条件は何かというと、俺理解では、１つのテーブルに複数の事実を収容している時。
ある本に、非第3正規形の例としてこんな社員マスタが載っていたが、

社員マスタ　{ 社員番号, 社員名, 所属支店, 支店所在地 }

ここには「社員の存在」と「支店の存在」という2つの事実が混在しているがために、追加・更新・削除時に更新時異状が発生しうる。
なので次のように第3正規形に分解することになっている。

支店マスタ　{ 支店コード, 支店名, 支店所在地 }
社員マスタ　{ 社員番号, 社員名, 所属支店コード }

ところで、分解後の社員マスタには1つの事実だけが収容されていると言えるのだろうか。
T字形ER手法では、この社員マスタには「配属」というeventが混入していると見なす。で、所属支店コードを社員マスタに置くのは「愚行」とされている。

「配属」という別の事実が混入しているのに、更新時異状が起きない理由は、所属支店コードがnull値可能であるから。
仮にNOT NULL制約があるのであれば、配属の決まっていない社員を登録できない、という問題が生じる。
つまり、教科書的な正規化は、null値を許容せざるを得ない。
nullの何がいけないのか、なぜCodd自身が"Fatal Flaws in SQL"とまで言っているのか、いまいち身にしみて感じることができていない。
ここも整理しなくてはならない。

今回のまとめ

やっぱり、完全正規形じゃなければ更新時異状があるし、更新時異状があるならそのテーブルは multi facts in 1 place になっているのではないか。だったら、常に完全正規形まで分解せざるを得ないのではないか。「第3正規形まででよい」わけがないのではないか。