« Quality は従属変数 | トップページ | 「もっと勉強してください」 »

2008年4月19日 (土)

データベース正規形とSQL

データベース設計でテーブル正規化を行なう理由のひとつは、リレーショナル演算をスムーズに行なえるようにしたいからですね。つまり、データ処理を、もっぱらSQLを使って行なう、という設計戦略になるかと思います。

しかしながら、リレーショナル・データベースのテーブルをフラットファイルや、あるいは、索引付きファイルとして扱っても、それはそれで、ひとつの設計の考え方といえます。この場合、SQLの力を有効に使うことは難しくなりますので、データ処理は、もっぱら、ホスト言語となっている、なんらかのプログラミング言語を使って行なうことになるでしょう。テーブルは、リレーショナル・モデルではなく、本当に単なる”ファイル”である、というわけです。

正規化したテーブルが、プログラマに嫌がられるのは、リレーショナル・モデルが敬遠されているということであり、ひいては、SQLを使ってデータ処理をするのを嫌がっている、という見方ができます。

プログラマがSQLを嫌う理由は、本質的には、SQLが逐次実行型のプログラミング言語ではないから、かもしれませんね。メジャーなプログラミング言語のパラダイムとは、大分異なっているのは確かです。SQLというのは、”集合型言語”とでもいうべきものでありまして、独特のパラダイムを持っています。集合演算を中心とした言語、というのは、他にあまりないような気がしますね。関数型言語のリスト処理などは、近いとは思います。こちらもあまりプログラマには親しまれてはいませんね。

リレーショナル・モデルを使わないのなら、 RDBMSを使うのは、選択ミスともいえるわけですが。 RDBMS が一番入手しやすいという現実がありますからね。リレーショナル・モデルを使わなくても、トランザクション管理、メタデータ管理、 バックアップ、 レプリケーションなど、 DBMSで使いたい機能というのはあるわけでして。昔のように、TPモニタ(Transaction Processing Monitor)と、索引付きファイルとでOLTPを実現する、なんていうのはないでしょう。

|

« Quality は従属変数 | トップページ | 「もっと勉強してください」 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/20369183

この記事へのトラックバック一覧です: データベース正規形とSQL:

« Quality は従属変数 | トップページ | 「もっと勉強してください」 »