データベース正規化・非正規化

データ・モデリングの普及団体，DOA+コンソーシアムはこのほど，リレーショナル・データベース管理システム（RDBMS）の処理性能に関する実証試験を行い，調査結果を公開した。「データを正規化してデータベースに実装すると，処理性能が低下する」という"誤解"を正すため，実証実験を行ったという。

「DBを正規化すると遅くなる」は誤解，実証実験の結果が公開に (ITpro)

正規化（非正規化）すると早く（遅く）なる、という命題の立て方はどうかと思うのですけどね。

実証実験の結果，データベース上の単一テーブルを対象に検索した場合，いずれのパターンも2〜3ミリ秒で処理を終えた。一方，3つ程度のテーブルにわたりデータを検索した場合，正規化したパターンでは，5000万件のデータを90ミリ秒で検索できた。だが，非正規化したパターンでは，500万件のデータ検索に14秒かかった。

テーブルを非正規化したい理由としては、ユーザー／プログラマが結合操作を嫌う、というのは、よくあるんじゃないですかね。ですので、比較するなら、1テーブルに非正規化・集約したテーブルから検索する場合と、正規化した3テーブルを結合してから検索する場合とを比較するのが、妥当ではないかと思うのですが。この場合、得られるものが全く同じとすれば、非正規化の方が、おそらく処理速度は早くなるでしょうね。

非正規化というのは、正規化がまずあって、行なうものであるわけでして。非正規化によってメリットが得られないのであれば、それを非正規化というのは、どうなんでしょうね。単なる、”失敗作”であろうと思うのですが。

この手の話というのは、よくあるわけでして：

• オブジェクト指向では、すべてをオブジェクトにするのが正しい。よって、使用する全ての項目について、クラス定義を行なう（しかも、それがリモート・オブジェクトだったり）。
• 関数呼び出しをすると、呼び出しのコストの分、処理が遅くなる。よって、関数は使わずに、ひとつのルーチンにすべてを詰め込む。

設計というのは、相反する要求の間のトレードオフを考慮しつつ、最適な解を見つけ出そうとする活動なわけでして、一律にこうすべき、ああすべきなどとはいえないと思います。与えられた要件とその優先順位によって、解は異なるでしょう。

データベースの正規化というのは、データベースの拡張性・柔軟性を最大限に引き出すための、設計手法ですよね。それによって、失われるものというのは：

• 検索の処理性能
• 単純さ、あるいは、理解のしやすさ

といったものになると思います。

この二つは関係があって、デザインがプログラマにとって、複雑で理解しにくいものになっていたり、データの取得方法として、クエリを何通りにも書けたりすると、プログラマが性能の悪いクエリを書く可能性は、それだけ高まります。SQLクエリというのは、本番データ上で、実行してみなけりゃわからないところがあるのも現実です。コストペース・オプティマイザのように、データの統計情報によって、実行パスが変わるような場合は特に。

単純さ、理解のしやすさという点でも、テーブルの結合操作というのは、結構嫌われるのですよ。データベースの 正規化 vs 非正規化 というのは、オブジェクト指向でいう、小クラス主義 vs 大クラス主義 に通じるものがあるんじゃないですかね。

最後の手法が軽そうで良いなと思ってAPIリファレンスを眺める。

すると、javax.toolsがいかにも面倒そうなのでうんざりする。このうんざり感の原因には小クラス主義（1責務1インターフェイスあるいは、サブジェクト主義と名付けたくなる何か）にあるのだなということがわかる。

つまり、目的主義でAPIを眺めると、その目的にたどりつくまでのステップが多過ぎる。

その一方で、1責務1インターフェイスというのは、ケチのつけようがない考え方だと考えている自分にも気づく。

Javaのメタプログラミング (L'eclat des jours)

データベースにも、ファサドを作る方法というのはあって、ビューやストアド・プロシージャを使えば良いのですが。これはこれで、また新たな問題をもちこむことになるんですよね。

そんな単純な話じゃないよ、ということで。