━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第25回 データベース設計
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前回、データベース設計が不要だったシステムのお話をしましたが、やはり
データベースはきちんと設計した方がいいですね。
というのも、業務系システムの場合、最大の資産はデータだからです。
業務系システムでは、データを効率的に登録するために入力画面、適切に取
り出すために検索画面や出力帳票があると言えます。
そのため、稼動後であっても、プログラムはユーザーの利便性に合わせて修
正することはありますが、データベースの方を修正することはほとんどあり
ません。
ですから、データベース設計は特に質の高さを求められるのですが、現状は
まともに使えないようなものが非常に多いです。
私がよく見かける失敗が、リレーショナルデータベースなのに正規化がされ
ていないため、複雑なSQLを書かねばならず、処理時間ががやたらと掛かっ
たり、メンテナンス性が低いというものです。
このようになってしまう理由は、正規化を理解していないことです。
第３正規形になっていない理由を尋ねると、必ずといっていいほど「この方
が速度が早いから」などと言います。
確かに、取得したいデータによっては正規化を進めない方が早く検索できる
場合があり、その手法は「正規化崩し」などと言われています。
「正規化崩し」は、一旦は第３正規形にした後、パフォーマンスを考えつつ
も仕様を損ねないかの検討を行い、問題が無いときに一つ前の形に戻してい
く方法です。
ところが、問題のあるデータベースの場合、ほとんど検討が行われずに、単
に正規化が行われていないだけのことが多いのです。
「正規化崩し」ではなく「正規化崩れ」とでも言ったほうがよさそうです。
そのため、仕様変更や仕様追加が発生すると、途端に扱いにくいデータベー
スになってしまうのです。
●そもそもデータって
私たちの世界では、データが溢れています。
このメールマガジンの文章だってデータですし、読者の皆さんに関する様々
な情報（身長、体重．．．等）もデータです。
データは、他のデータと関連があり、時間で変化したり、大きさが変化した
りすることもあります。
また、文字であったり、絵であったり、熱であったり、形もバラバラです。
このため、データをどうやって分類していくかの研究がデータベースの始ま
りでした。
初期のデータベースは、ツリー構造や網構造になっていたとのことで、それ
ぞれの要素から別の要素のアドレスを保持する方法だったようです。
ポインタ使いまくりで扱いづらそうですね。
現在では、1970年頃にIBMのコッド博士が論文で発表した「関係モデル」が
主流です。（一般的に多く使われているという意味で、データモデルとして
正解という意味ではありません）
「関係モデル」はデータの関係に着目し、二次元表で数学的に表現すること
で、ポインタを使わずに問い合わせをすることができるようになりました。
（詳しい使い方は次回以降に説明します）
正規化とは、データを分類・整理するためのルールなので、しっかりと理解
しておきたいものです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━