概念設計・論理設計・物理設計の違いとは

データベースの設計は、概念設計・論理設計・物理設計の順に進みます。概念設計で管理する対象と関連を描き、論理設計で表と主キーを決め、物理設計でディスクへの置き方を決めます。

例には、通信販売の顧客と注文を使います。RDBの表と3層スキーマを知っていると、この先の話が分かりやすくなります。次の図は、同じデータが段階を進むたびにどう形を変えるかを示しています。

先の段階ほど、使う製品と記憶装置の事情に近づきます。概念設計はDBMSに依存しない形で描き、物理設計は使うDBMSとディスクに合わせて決めます。どこからDBMSに合わせるかは資料によって違います。この点は、論理設計の節で説明します。

概念設計では、業務で管理する対象と、対象どうしのつながりを決めます。通信販売なら、管理する対象は顧客と注文です。1人の顧客は何度も注文できるので、顧客と注文は1対多で結びます。

管理する対象をエンティティ、つながりをリレーションシップと呼び、E-R図で描きます。概念設計は、DBMSに依存しない形でデータの関連を表す設計で、表す方法にはE-R図とUMLがあります。

概念設計でできる図を、概念データモデルと呼びます。表の形は、この段階ではまだ決めません。

キーをどの段階で決めるかは、資料によって違います。ElmasriとNavatheの教科書は、E-R図の段階で、値が重ならない属性をキー属性として描きます。一方、AWSの解説は、主キーと外部キーを論理データモデルに含めています。

論理設計では、E-R図を表の形に置き換えます。顧客は顧客表に、注文は注文表になります。行を1つに決める主キーには、顧客番号と注文番号を選びます。顧客番号のような番号の付け方を決める作業を、コード設計と呼びます。1対多の線は、多の側の注文表に顧客番号の列を足し、外部キーにすることで表します。

論理設計では、データの重複や矛盾が起きないように表を設計します。重複のない表に分ける手順が正規化です。論理設計でできる表の形を、論理データモデルと呼びます。

どこからDBMSに合わせるかは、資料で分かれる

ElmasriとNavatheの教科書は、論理設計を、特定のDBMSのデータモデルに合わせる段階としています。一方、AWSの解説は、論理データモデルをプラットフォームに依存しないものとして説明し、エンティティを表に対応付ける作業を物理データモデルの手順に入れています。ここでは、表・主キー・外部キーを決める段階を論理設計とします。

物理設計では、論理設計で決めた表を、ディスクにどう置くかを決めます。磁気ディスク上にどんな形式で記憶するかといった、物理的な構造を考えます。ディスク容量の見積り、論理データ構造のマッピング（論理設計で決めた構造を物理的な構造に割り当てること）、性能評価もこの段階の作業です。

物理設計では、列のデータ型とサイズ、索引も決めます。顧客番号で注文を探すことが多いなら、注文表の顧客番号にインデックスを付けます。データ型や索引まで決めた形を、物理データモデルと呼びます。

性能のために表をあえてまとめることを非正規化といいます。非正規化をどの段階で行うかは、資料によって違います。物理設計の作業とする資料もあれば、AWSの解説のように、論理データモデルを作る手順に正規化と非正規化を並べる資料もあります。

データ型をどの段階で決めるかも、資料によって違います。AWSの解説のように、データ型を物理設計の側に置く資料があります。一方、ElmasriとNavatheの教科書は、概念設計の段階で、属性ごとにデータ型に当たる値の集合を決めています。

ディスク容量は、1行の長さ × 行数で見積もる

注文表の1行を平均100バイトとし、1日に2,000件の注文が5年分たまるとします。行数は、2,000件 × 365日 × 5年で3,650,000行です。容量は、100バイト × 3,650,000行 ＝ 365,000,000バイトで、約365MBです。

実際の見積りでは、索引が使う領域も足します。1行の長さにも、列の値のほかに、NULLかどうかを表す印のようなDBMSの管理情報が加わります。

次の図には、顧客と注文の例で設計の途中に決めることを8つ並べました。1つ選ぶと、その作業がどの段階に当たるかが光り、理由が表示されます。

図では、表と主キーを決めるのは論理設計、データ型と索引を決めるのは物理設計としています。同じ表に関わる作業でも、表をどう分けるかは論理設計、表をあえてまとめるのは物理設計の作業です。論理設計は重複と矛盾をなくすことを目指し、物理設計は性能などの要件を満たすことを目指すからです。ただし、前に書いたとおり、非正規化を論理設計に含める資料もあります。

概念設計と概念スキーマは、名前が似ていても指すものが違います。設計の段階は作業の順番による分け方で、3層スキーマはDBMSに定義するデータの層の分け方です。3層スキーマの概念スキーマは、論理設計で決めた表の定義に当たります。

ElmasriとNavatheの教科書の図も、論理設計の結果を概念スキーマ、物理設計の結果を内部スキーマとしています。ただし同じ教科書は、概念設計で作る図も概念スキーマと呼んでいます。概念スキーマという語を見たら、設計の段階の話か、3層スキーマの話かを確かめる必要があります。

データモデルとは、データの構造と関連を表すための決まりです。概念データモデルと論理データモデルは、先に説明したとおり、それぞれ概念設計と論理設計で作ります。論理的なデータ構造を表すデータモデルには、関係モデル・階層モデル・網モデル・グラフ型があります。

このうち関係モデルは、データを表の形で表すモデルで、RDBが採用しています。データベースの種類は、データベースとはの記事で説明しています。

• IPA「平成26年度 過去問題」（データベーススペシャリスト試験 春期 午後II 問1の出題趣旨と採点講評）
• R. Elmasri, S. B. Navathe「Fundamentals of Database Systems」第3章のスライド
• AWS「論理データモデルと物理データモデルの違い」