データベースの設計技法とSQL
さて、最初のほうでRDBの基本的な考え方は、数学の集合論に基づいていることは述べた。システムの対象となる領域（データベースで管理する対象）をうまく集合論的なグループで分類できれば、RDBはその威力を発揮するし、逆にそこがうまくいかないと本来のメリットを享受することはできず、パフォーマンスやメンテナンスなどの面で問題にぶつかることになる。
では、基本的なテーブルの構造を見ていこう（図5）。
RDBの各テーブルは、通常プライマリキーというテーブルの各行を一意に識別するキー項目を必ず持つ。プライマリキーはユニーク（そのテーブル内において同じ値が存在しない）である必要があり、NULL（何もない）値を取ることができない。設計上はそのような制約を満たす列をプライマリキーとする必要があり、そのような制約を満たすものがないときは新たにコード体系を見直してそのようなコードを起こす必要がある。
また、検索上よく使われる項目などには、インデックスを設定し検索動作を高速にすることも行われる。
 |
|---|
| 【図5】テーブル構造 |
外部参照項目は、ほかのテーブルに存在していない限り存在が許されない値を持つ列のことである。
データベースが適切に設計されていれば、シンプルなSQLで目的とする検索結果を得ることができる。RDB設計の基本は「正規化」にある。正規化とは、データ項目の集まりを、データ項目そのものの意味や内容を分析して、正確に定義することにより分解・統合し、重複や不足のないデータ構造にしていく過程である。
正規化には第5正規化までのステップが定義されているが、通常は第3正規化までで十分である。たいていのデータベースの設計技法関連の本を読んでも第3正規化までで解説は打ち切られている。
それぞれのステップは表1のように定義される。これらの過程で、主キーがまったく同じテーブルがあれば、それらは同じテーブルとして結合する。このような過程を経てRDBの論理設計が完了していくことになる。実際に各テーブルやインデックスをどのように配置するかは、物理設計の段階で決定していくことになるが、物理設計は採用するデータベースアーキテクチャに大幅に左右されることになるので、ここでは触れないでおく。
| 第1正規化 | 繰り返し構造の除去と主キーの明確化 |
| 第2正規化 | （主キーが複合キーの時）複合キーの一部のみに従属する項目を別テーブルとして分離する |
| 第3正規化 | キー以外の項目で、ある項目に従属している項目があれば、それを別テーブルとして分離する |
最近ではシステムの構造はUML＊6で記述し、RDBMS自体もORDBMSとして、繰り返し構造を許容するなどの動きも見られる。正規化の設計技法は、「同じ意味のデータは1カ所で管理する」というルールを守るためのものであり、元々はデータベース設計の技法としての意味があるのだが、正規化という概念自体はERP＊7にも通じる経営あるいは大きな組織の運営自体に対する改善の意味合いもあるものである。 また、SQLは正規化されたデータに対して、その表記法を有効に活用できるようになっているので、トランザクション処理を伴うシステムや、SQLデータベースエンジンを用いる限り、正規化のテクニックは必要だと筆者は考えている。これらの設計の部分もすでに大量に書籍や情報が出回っているし、その概略を述べるだけでも与えられたページを遙かにオーバーしてしまうだろう。実際にRDBを単なるSQL付きのISAM＊8以上のものとして使おうと考えている方々は、ぜひ、RDBの設計関連の技法についても調べて勉強していただきたい。間違いなくシステム設計に関する視野が広がるはずだ。
