3. データベース設計基礎

データベース設計のための基礎手法や図法などの解説。

3.1. データベースの設計方法

3.1.1. データベーステーブルの設計

テーブルは基本的に以下のフローで設計します。

システム要件の確認
テーブル概要設計
テーブル詳細設計

システムの要件の確認

この工程ではシステムの要件と機能を明確化します。どんなデータを保存するのか、どういうアプリのためのデータベースなのかetc...より検討。

テーブルの概要設計

システムの要件と機能から必要となるデータのテーブルを大雑把に書きだします。機能一覧より処理のシナリオに沿ってデータを洗い出します。

テーブル詳細設計

このステップでは概要設計で洗い出したデータテーブルに以下の仕様を追加します。

日本語データ名(論理名)を英語(物理名)に変える
カラムに型を定義する
ER図を書きながら各テーブルを正規化する
制約条件やインデックスをつける

また注意としてカラム名やデータ名に予約語を用いてはいけないという暗黙の規則がある。

3.1.2. インデックス

検索キーになりうるカラムにつける番号です。主キーや外部キーにはつけません。

3.1.3. 制約条件

NOT NULL制約・・・列のデータがNULL値ではないことを保証する制約
ユニークキー制約・・・列のデータが重複しないことを保証する制約
外部キー制約・・・他のテーブルの列を参照し、その列にないデータを禁止する制約

外部キー制約の説明

3.1.4. 命名規則

テーブルやカラムの名称の命名のルールとして基本的には以下の通りです。

読んで意味の分かる名称を英語でつける
テーブル名・カラム名ともに大文字
単語のセパレータには_を使う
英語の長い連語(例: Purchase OrderならPO)は略称にする
テーブル名は複数形(s)

3.2. 作図

データベースの設計のためには非正規形の表の正規化を行う以外に、図の作成などを用いてデータベースの機能の設計や操作をまとめることができます。

3.2.1. DFD

DFDは「システムの機能」と「システムで扱うデータ」の流れを表現する図です。

DFDを作成する目的としては、

他のメンバーとシステムイメージを共有
既存システムの全体像を説明するのに活用
機能の漏れ、重複がないように分割
プロセスの詳細化

プロセスの詳細化を行うと、一度に検討するプログラム量が最小限になり、コーディング時に部分ごと集中して取り組むことができます。

例

3.2.2. CRUD図

システム開発において属人化を未然に防いだり影響調査のコスト圧縮のためにCRUD図という図を作成したりします。 CRUD図はSQLの4大命令に即した形で「Create」、「Read」、「Update」、「Delete」の操作がどのテーブルに対して行われているかを画面(機能やユースケース)ごとに記載する資料です。

省略形(意味)	SQL	説明
C(Create)	INSERT	データの追加
R(Read)	SELECT	データの参照
U(Update)	UPDATE	データの更新
D(Delete)	DELETE	データの削除

例

3.2.3. ER図

ER図はデータベースを設計する際に利用します。

ER図を作成することで、複数個所でマスタとなるデータをばらばらに持ってないか確認できたり、データの関連性を説明するのに活用することができます。 実体と関係という概念を用いてデータ構造を図にします。

要素	概要
エンティティ	データのまとまり。実体のあるもの(人、物、場所、金)だけでなく、概念(やりとり、分類)も対象となります。
アトリビュート(属性)	エンティティに関する情報です。
リレーション(関係)	「1対多」など数の関係を表します。
カーディナリティ(多重度)	「1対1」「1対多」「多対多」など

ER図のデータモデルの形態

ER図の初期形態

概念モデル: ものと出来事をエンティティ・リレーションシップとして表した図

ER図の中期形態

論理モデル: 概念モデルに情報を肉付けしたもの。属性(アトリビュート)・アイデンティファイア(主キー)・外部キーとかの要素が入る

ER図の最終形態

物理モデル: 特定の物理DB向けに論理モデルを変換する。データ型の追加とか、アルファベットに変換したりとかする

表的なER図の要素と物理データベース項目の関係は以下になります。

ER設計	物理データベース
エンティティ名	テーブル名
アトリビュート(物理名)	カラム名
アイデンティファイア	主キー制約
リレーションシップ	外部キー制約