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

本 RDB

C.J.Date「データベース実践講義」を読んでみる。
面白そうなところを拾い読みしたが、実践というより理論に傾いた内容。
つまり、「既存のRDBを前提として、それをどのように使うと効果的か」を書いた本ではなく、「リレーショナルモデルから見て、既存のRDBの実装がいかにダメか」を書いた本になっている。
なので、読んだからといって今日の仕事に役に立つわけではない。

しかし、既存のRDBに対してこういう視点もあるのだ、ということを覚えておけば何かの役に立ちそう。
なので、へえと思ったことを何回かに分けてメモしておく。

リレーショナルモデルには「テーブル」と「ビュー」の区別はない

リレーショナルモデルでは、どっちもリレーションである。
我々がテーブルとビューを区別して扱っていること（例えば、ビューは更新できないとか、テーブルがないとビューを定義できないとか）には、理論的な根拠がない。各SQLベンダーの独自実装がそうなっているというだけのこと。
それで何か問題あるのかというと、

P-17
SQLベンダーは基底テーブルを物理的なストレージにほぼそのままマッピングしている。
それらの製品におけるデータの独立性は、リレーショナルモデルが論理的に実現し得る水準をはるかに下回っている。

とのこと。
「ビューだから重い」とか「ビューだから更新できない」とか、プログラマが考えなくてもよいRDB実装があり得るのか。


SQLはリレーショナルモデルをそのまま実装しているわけではない。所々ズレている

例えばテーブルはリレーションではない。重複行が含まれてもいいから。
リレーションは数学で言う集合なので、同一のタプルが含まれることはない。
このルールは UNION で採用され、SELECTでは採用されていない(＝UNIONのデフォルトは UNION DISTINCT で、SELECTのデフォルトは SELECT ALL)。
なので、

SELECT x FROM xxx where x=1

が10件hitし、

SELECT x FROM xxx where x=2

が5件hitしたとしても、

SELECT x FROM xxx where x=1
UNION
SELECT x FROM xxx where x=2

の結果は2件になってしまう。
この挙動を見て、UNIONというのはヘンな動きをするなあと思っていたが、理論的にはこっちが正嫡。SELECTの実装が鬼っ子。

SELECTには常にDISTINCTをつければいいんだよ派

C.J.DateはSQLがリレーショナルモデルからはみ出すのを嫌っているので、「SELECTには常にDISTINCTをつければいいんだよ」派。
「常にDISTINCTを指定すべきであるという筆者の提案に、レビュー担当のほぼ全員が口を揃えて反論した」ので、拗ねている。
最近この「SELECTには常にDISTINCTをつければいいんだよ」という意見をよく見る。
いつか常識になるか？

第6正規形、TransRelational Model

これがデータモデリングの極北か？

P-170
これは実装技術なので、本書では割愛する。
＜中略＞
「パフォーマンスのための非正規化」を行う必要がいっさいなくなる。
論理設計は文字通り、パフォーマンスといっさい関わりを持たなくなる。