データベース設計の位置付け

「データベース設計」という言葉の定義はあいまいで、論理設計と物理設計であるとする場合と、概念設計と論理設計と物理設計であるとする場合があります。

きちんとデータベースを学んだ人であれば「あー…」と思うかもしれませんが、意外とエンジニアの多くはテーブル設計やSQL、INDEXを学ぶことはあっても、データベース設計全体を学ぶ人というのはかなり希少です。

だから人によってデータベース設計の定義が変わるのは仕方がないかも知れません。

概念設計でシステム開発における業務分析を行ない、システムに依存しない論理的かつ正規化されたデータモデルを作成します。

論理設計では、アプリケーションからの性能要求を考慮し、必要があれば非正規化を行ないます。また、データベースの論理的な構造（テーブル）と索引（インデックス）を決定します。さらに、利用者から見たデータ構造（ビュー）も作成します。

つまり、概念設計で理想的なデータモデルを作成し、論理設計でより実践的なデータモデルへと発展させていく必要があるのです。これらの一連の流れを総じて「データモデリング」と定義します。

また、通常のデータベース設計では最終的にデータベースシステムを構築するために、物理的な配置を決定する物理設計までを行ないます。

概念設計とは

企業の情報資源を整理し、業務システムにおいて管理すべき対象を明確にする設計作業です。このとき必要なのは次の３つのスキルです。

　･事業戦略
　･業務知識
　･データを整理するスキル

ここでは一事象一元管理(データの一元化）を重視し、ハードウェアやソフトウェア、アプリケーションから独立した安定したモデルを作ります。

まず企業やシステムのあるべき姿を考えながら、管理すべき対象となる情報群を洗い出します。

たとえば、給与が支払われるためには給与計算をしなければいけませんが、そのためには「基本給」「手当て」「残業単価」「時間外労働時間」などを管理しなければいけませんよね。これは（よほどブラックでなければ）どこの会社でも恐らく同じだろうと思います。

つまり、5000人の会社でも50人の会社でも業務が同じであれば管理すべき対象は同じなので、同じモデルが適用できるはずです。

このとき処理速度や使い勝手を意識する必要はありません。なぜならシステムが遅いか速いかは、そのシステムを稼働させるコンピュータの選択次第で変わってくるからです｡

１GBのメモリを搭載したコンピュータで遅いシステムでも、16GBのメモリを搭載したコンピュータで稼働すれば満足のいく速さが保証されるかもしれません。このような、ハードウェアやソフトウェアに依存することを業務概念をイメージしている段階で検討する必要はありません。

したがって、

　「テーブルを結合すると遅いから、この値は重複して持とう」
　「データ量が多いから分割しておこう」

などは概念設計で考えることではありません。必ず考えて欲しいのは、

　「管理すべきデータを正しく維持管理できる構造はどういう構造か」

ということです。データベースは正しいデータが維持管理されていなければ、速くても使いやすくても意味がないのです。

論理設計とは

データベースの論理的な構造を表現する作業です。「論理的な」とは、性能の良いデータベースを設計するために、概念設計の結果であるデータ構造（概念ER図）を基に処理機能やユーザー要件を考慮し、求められる性能が出ないと考えられるものに対して、主に

　索引の作成
　重複項目および導出項目の追加
　非正規化

を検討します。概念設計で作成したモデルは正しくデータを維持管理するためには理想的な形です。しかし、概念設計のモデルは正規化された構造であるため、そのままではテーブルの結合が多発し、レスポンスが低下する可能性があります。そこで、実際の使われ方から、最も効率の良い使われ方を検討する必要が出てくるのです。

非正規化とは、正規化を否定するものではありません。索引を定義することで高いレスポンスが維持できると判断できるなら、必ずしも非正規化する必要はありません。また、論理設計ではレスポンスのことだけではなく、同時利用性やセキュリティ（可用性や完全性）なども考慮します。

性能（時間効率性）の良いデータベースを考える論理設計では、仮にユーザー要件で「全社員の給与計算は1時間以内に終わらせて欲しい」と要望があった場合、1時間は60分なので単純に計算すると50人の会社では１人当たりの給与計算に１分ちょい要しても良いことになります（1分×50人だと50分で済んでしまいますからね）。

そのため、このような場合に限っては概念設計のままの構造でもユーザー要件を満たすことができるかもしれません。

では一方で、5000人の会社の場合はどうでしょうか。60分は3600秒なので1人の計算に１秒を要していたのではユーザー要件を満たすことができません。そこで概念設計で考えたテーブル構成に対して索引の追加や非正規化を行ない、要件を満たす性能が出るように性能面において最適な形へと変更していかなければならないのです。

そのため、「給与計算」という業務内容は同じでも、論理設計ではユーザー要件を満たすためにテーブルや索引の定義は同じになるとは限らないのです。

物理設計とは

システム要件に合わせて物理的な検討を加味する作業です。「物理的」とは要するに「実際にデータベースにデータが配置できる状態」まで設計するということです。具体的には論理設計の成果物（論理ER図）を基に、RDBMSに応じたデータの物理配置を検討します。

このとき、処理速度や記憶領域の効率化を図るために、RDBMS固有のオブジェクトの検討や領域管理パラメータ値の定義を行ないます。さらに、信頼性や可用性の向上を考慮した物理構成を検討します。

物理設計の目的は、

　ハードウェア資源を効率的に使用し、
　ユーザー要件を満たす性能を実現する

ことです。バックアップを中心とした障害時に備えた運用が可能なデータベースを設計しなければいけません。

また、データアクセスを高速化するための手段も考えておく必要があります。他にもI/O分散、障害時の損失範囲、バックアップやリカバリに要する時間、運用単位などに配慮した上で、データの入ったテーブル（データの入れ物）をどのように分けて配置するかを考える必要があります。

データベース製品によっては、同じディレクトリに物理的なファイルを配置しなければいけない場合もあれば、異なるディスクに配置しても構わない場合もあります。当然ディスクやメモリというリソースの使い方も異なるので、使用する製品の特徴を最適な形で生かすための設計が必要なはずです。

たとえば、Oracleではテーブルと索引を別々のファイルに格納し、それぞれのファイルを異なるディレクトリに配置することができます。一方、PostgreSQLのバージョン7.4までは、データベースファイルを異なるディレクトリに配置することはできませんでした。つまり、使用する製品やバージョンによって物理設計は異なるのです｡

もし、データベースを設計する前にOracleを使うことが決定しているのであれば、論理設計と物理設計は同時に行なうことができないでしょうか。あるいは概念設計、論理設計、物理設計と段階を踏まなくとも、すべてを１つのフェーズで行なえそうです。

しかし、残念ながらそれをやるとリスクだらけになります。

なぜなら、変化する企業のニーズや業務に対応するには適切な設計書が必要だからです。基本的にデータは延々と蓄積され続けるため、データベースは成長し続けます。データにはライフサイクルがあり、登録したままの状態ではなく、更新され、やがて不要となる時期も訪れます。

システムの拡張、変更要求も頻繁にあるはずです。
このとき、

　「管理するべきものが増えるのならばどの段階から見直せば良いのか｣
　「レスポンス劣化が早急な課題なら、どこから考え直せば良いのか」

などは適切な設計書があるからこそ「再現性」が保証されるわけです。設計書がなければ、どんな定義で、どんな設定で、どんなパラメータになっているのか一つひとつ調べないとわからない上に、その調査からたった１つでも項目が漏れているとまったく同じ環境を用意することができないリスクを抱えてしまいます。

もし開発時の設計担当者がそのまま保守運用などを担当していればその人の記憶に頼れますが、基本的にプロジェクトが解散した時点で別のプロジェクトへ移ってしまうのが一般です。設計書という記録が残っていなければ、もう誰にも頼れないことだって普通にあり得るのです。

もし設計書が残ってさえいれば、「人」に依存することなく過去の経緯がわかり、適切な対応ができるようになります。そう言った観点からも、まとめてバーッとやってしまうのではなく、きちんと段階を踏んで、しっかりと設計書を残しながら進めることをオススメします。