データベースの設計は、次の手順で行います。
- 概念データモデルを作成する
- 導入するDBMSに合わせて論理データモデルに変換する
本記事では、データモデルの説明をします。次の記事で、続編として正規形の話をします。
これらの記事により、テーブル設計を行う際に最低限の基準が分かると思います。
具体例から大雑把に学びたい方は、テーブル構造を考える③（具体例）へどうぞ。
データモデル
データベースを構築する範囲を対象世界と呼び、対象世界をモデル化したものがデータモデルです。データモデルを作成することをデータモデリングと言います。対象世界を抽象化し、概念データモデル（概念モデル）を作成します。概念データモデルをデータベースとして実装可能な論理データモデル（論理モデル）へと変換します。
概念データモデル
概念データモデルは、対象世界のデータ構造を概念的に捉えた結果を表現したモデルです。概念データモデルの記述にはER図 が良く用いられます。ER図は、Entity（実体） と Relationship（関連） から構成されます。Entityは管理対象とするデータの集合体を、RelationshipはEntity間のつながりを表します。
Relationshipにおける多重度をカーディナリティと呼びます。カーディナリティは、あるEntityが保持する1件のデータが、関連するEntityの何件のデータに対応するかということを表しています。
以下の図は、Entity間を直線で結んでRelationshipを表しています。
論理データモデル
論理データモデルは、データとデータ間の関係を論理的に表現したもので、そのままデータベースとして実装可能なデータモデルとなっています。論理データモデルには、DBMSがデータを保持するための論理構造に応じて、関係モデル（リレーショナルモデル）、階層モデル、ネットワークモデルなどがあります。
データベース設計
先に説明したように、データベースは以下の手順で作成します。
- 概念データモデルを作成する
- 導入するDBMSに合わせて論理データモデルに変換する
論理データモデルとして、関係モデルを採用することを前提に、それぞれの手順について説明します。
概念データモデルの作成
最初に、管理対象とするデータを対象世界から抽出し、Entityとして定義します。抽出するデータは、商品、取引先などのように実態が物理的に存在するデータだけでなく、売上、出荷などのように物理的な実態が存在しないデータについても検討します。概念データモデルを作成するときのポイントは、「対象世界はどうあるべきか」、「対象世界ではどのようなデータを保持すべきか」という視点で業務を俯瞰的に捉えながらデータを抽出することです。
Entityを抽出できたら、Entityごとに主要な属性（データ項目）を明確にします。詳細な属性は論理データモデルの作成で洗い出すので、Entityを具現できる最低限の属性で十分です。例えば、Entiry「商品」であれば、商品コードと商品名程度でよいと考えられます。以下の図では、Entityを長方形で表し、Entityの名称を上段に、主要な属性を下段に示しています。
次に、Entity間のRelationshipを明確にします。EntityとEntityの間に関係がある場合、Entity間に線を引きます。合わせて、カーディナリティも明確にしておきます。
論理データモデルへの変換
次に概念データモデルを論理データモデルに変換します。基本的には1つのEntityが1つの表に対応します。しかし、多対多のRelationshipが存在すると、そのままでは関係モデルとして取り扱うことができません。多対多の関係を解消するためには、多対多の関係を持つEntityの間に新たなEntity（連関Entity）を追加し、多対多の関係を1対多、多対1の関係に置き換えます。先ほどの図における商品と売上の関係であれば、例えば売上明細というEntityを追加して多対多の関係を解消します。1件の売上明細には1つの商品が含まれ、1件の売上明細はいずれか1つの売上に含まれるので、商品と売上明細の関係が1対多、売上明細と売上の関係が多対1となります。
多対多の関係が解消できたら、各Entityが保持する詳細な属性、属性のデータ型やデータ長などを明確にしていきます。続いて、各Entityが冗長なデータを保持しないように正規化を行い、論理データモデルが完成します。正規化の詳細については、次回に説明します。
