データベース設計の基本的な位置付け

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

概念設計でシステム開発における業務分析を行ない、システムに依存しない業務の流れに則したエンティティの流れや構成をデータモデルとして作成します。

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

つまり概念設計で理想的なデータモデルを作成し、論理設計でより実践的なデータモデルへと発展させていく必要があるのです。

これらの一連の流れを総じて「データモデリング」と定義します。

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

概念設計

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

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

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

概念設計の作業工程

概念設計ではまず企業やシステムのあるべき姿を考えながら、管理すべき対象となる情報群（エンティティ）を洗い出します。

給与が支払われるためには給与計算をしなければいけませんが、そのためには基本給、手当て、残業単価、時間外労働時間などを管理しなければいけません。これはどの会社でも恐らく同じだろうと思います。つまり10000人の会社でも100人の会社でも業務が同じであれば管理すべき対象は同じなので同じモデルが適用できるわけです。このように抽象化して定義化することをモデリングといいます。

このとき、処理速度や使い勝手を意識する必要はありません。

なぜならシステムが遅いか速いかは、そのシステムを稼働させるコンピューターや用いるアーキテクチャの選択次第で変わってくるからです｡１GBのメモリしか搭載していないコンピュータで遅いシステムでも、16GBのメモリを搭載したコンピュータで稼働すれば満足のいく速さが保証されるかもしれません。

このような、ハードウェアやソフトウェアに依存することを概念設計で検討する必要はありません。したがって、

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

などは概念設計で考えることではありません。

概念設計で考えて欲しいのは「管理すべきデータを正しく維持管理できる構造はどういう構造か」です。データベースは正しいデータが維持管理されていなければ速くても使いやすくても意味がないのです。

論理設計

論理設計とはデータベースの論理的な構造を表現する作業です。

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

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

を検討します。

概念設計で作成したモデルは、正しくデータを維持管理するためには理想的な形です。しかし概念設計のモデルは正規化された構造であるため、そのままではテーブルの結合が多発し、レスポンスが低下する可能性があります。

そこで性能改善を検討する必要が出てきます。

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

論理設計の作業工程

性能の良いデータベースを考える論理設計では、仮にユーザー要件で「全社員の給与計算は1時間以内に終わらせて欲しい」と要望があった場合、1時間は60分なので単純に計算すると50人の会社では１人当たりの給与計算に１分かけても良いことになります。そのためこのような場合に限っては概念設計のままの構造でもユーザー要件を満たすことができるかもしれません。

一方、5000人の会社の場合はどうでしょうか。

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

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

　

物理設計とは

物理設計とは、システム要件に合わせて実装可能にするための物理的な検討を加味する作業です。

物理設計では、論理設計の成果物（論理ER図）を基にRDBMSに応じたデータの物理配置を検討します。このとき、処理速度や記憶領域の効率化を図るためにRDBMS固有のオブジェクトの検討や領域管理パラメータ値の定義を行ないます。

さらに、信頼性や可用性の向上を考慮した物理構成を検討します。

物理設計の目的はハードウェア資源を効率的に使用し、ユーザー要件を満たす性能を実現することです。バックアップを中心とした障害時に備えた運用が可能なデータベースを設計しなければいけません。また、データアクセスを高速化するための手段も考えておく必要があります。

物理設計の作業工程

物理設計ではI/O分散、障害時の損失範囲、バックアップやリカバリに要する時間、運用単位などに配慮した上でデータの入ったテーブルをどのように分けて配置するかを考える必要があります。

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

各工程の重要性

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

しかし、残念ながらそれはやってはいけないことなのです。

なぜなら変化する企業のニーズや業務に対応するには適切な設計書が必要だからです。

ひょっとすると目の前にあるプロジェクトのなかでモノづくりをするだけなら可能かもしれません。ですが、お客さまのビジネスは何年も続きます。その間、データは蓄積されますからどんどんデータベースは成長します。

データにはライフサイクルがあり、登録したままの状態ではなく更新され、やがて不要となる時期も訪れます。システムの拡張、変更要求も頻繁にあるはずです。

また保守開発などもあるでしょうし、ビジネスが続く限りリプレース（再構築）する時期もあるでしょう。その時、設計が残っていなければ余計なコストをかけなければならなくなることでしょう。迷惑を一身に背負うのはいつも客です。

このとき、

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

などは適切な設計書があるからこそ対応できるのです。

そもそも、議論すべきことが整理されないままはじまる会議はなかなか終わらないものです。それと同じです。今、何を議論するべきかを整理し、１つずつ片付けていく必要があるのです。データベース設計に限った話ではありませんが、段階を経て整理し、整理した内容を文書や記録として残すというのはそう言う責務を果たすということなのです。