「C.J.Dateの　データベース実践講義」からいつか役に立ちそうな話をメモ(2)

本 RDB

一応読了。
へぇと思ったところと、その他思いついたことをメモする。

ORDER BYはリレーショナル演算子ではない

理由は、タプルに並び順のあるもの＝リレーションではないものを返すから。
とはいえ、DateはORDER BYを否定しているわけではない。
便利な道具をリレーショナルモデルの上に積み増すことは、まったく問題ないと考えている。
しかし、積み増した道具が土台のリレーショナルモデルを破壊するなら、その導入には絶対反対の立場を取る。
例えば、ORDER BYはあっても構わないが、ビューの定義にORDER BYを含めることには反対する*1。
outer join否定論も同様。outer joinは便利だが、SQLの世界にnullを呼び込んでしまうのでDateは否定している。

第6正規形とnull

第6正規形の定義は以下の通り。

関係変数Rは、自明でない結合従属性を1つも満たさない場合に限り、第6正規形である。

つまり、これ以上分解すると元に戻せなくなる、というところまで分解した状態が第6正規形。
例えば、社員マスタが第5正規形になっているとする。

社員マスタ = { 社員コード, 社員名, 住所, 自宅電話番号, 携帯電話番号 }

ここで、社員名, 住所, 自宅／携帯電話番号は、それぞれ社員コードに完全関数従属している。
また、携帯を持っていない社員のレコードでは、携帯電話番号はnullになっているものとする。
これを第6正規形に分解すると、こうなる。

社員マスタ = { 社員コード, 社員名 }
社員住所 = { 社員コード, 住所 }
社員自宅電話番号 = { 社員コード, 自宅電話番号 }
社員携帯電話番号 = { 社員コード, 携帯電話番号 }

この時「ある社員が携帯を持っていない」という事実は、「社員携帯電話番号」上にレコードがない、ということにより表現される。
つまり、第5正規形（まで）ではnullで表現されていた事態が、第6正規形ではnullを使わずに表現できる。
基底テーブル上に null が発生してしまう理由の一つは、ライフサイクルの異なるデータ項目を1つのテーブルに収容するから。
第6正規形では、全てのテーブルでデータ項目のライフサイクルが揃うので、nullが発生することはなくなり、unknown・undefinedは常にレコードの不在として表現される。
こうまでしてnullを排除しようとする理由は、今理解しようとしている最中です。

データ独立とインメモリDB

上記の第6正規形をそのまま実装形にしたら、いろいろ問題がありそうに見える。

  • 社員情報一式を取り出す単純なクエリが、joinの嵐になってしまう。記述が面倒くさい。
  • たくさんjoinしたらパフォーマンスが低下するのではないか。

ポイントは、正規化は論理設計の領域の話題だということ。
Dateの回答は「論理設計はパフォーマンスには一切関係ないから、いいんだ」というもの。

P-169
原則的に、論理設計はパフォーマンスと何ら関係がない。だが、論理設計が
物理設計に1対1でマッピングされるとしたら、その結果は明らかである。

我々が普段パフォーマンスを考慮して論理設計しなくてはならないのは、既存のRDBMSが

  • リレーション -> ファイル
  • タプル -> レコード
  • 属性 -> フィールド

という固定的なマッピングを行っているから。
これをやられてしまうと、(本来RDBの目的であるはずの)データ独立性が失われてしまう。
論理的なデータ構造が、物理構造を無視して決められなくなってしまう。
で、TransRelational Modelで実装形を作れば上記の問題が解決するよ、と宣言している。
TransRelational Modelについては別の本を読んでね、とのこと。


ところで。最近インメモリDB実戦投入の話をよく聞く。
これ、データ設計に対するインパクトはどんなものなのだろう。
仮に、インメモリDBによって create view や join のコストを気にしなくてよくなるのだとすれば、実装形の設計の自由度がグンと増すだろう。
第6正規形で実装しても、プログラミングしやすく、また十分なパフォーマンスを挙げるデータベースが作れるのかも。

*1:ビューの定義にORDER BYを含められる「有名な製品」があるのだそうだ。どれだろう