【データベース設計】基本的な流れ

データベース設計は、下記の流れで進めます。

概念設計

データベース化したい要件に登場する情報をざっくりとまとめて整理します。

• どのようなカテゴリの情報があるか？（例えば、ユーザー情報、貸出端末情報等）
• テーブル間で関連があるか？

専門用語で、テーブル名は「エンティティ」、列名は「属性」、リレーションを「関係」とも呼んだりするのであわせて覚えておきましょう。

この段階では、十分に顧客ヒアリングをするようにしましょう。

注意点

顧客の間でも意見が割れる可能性がありますが、その場合は概念設計の結果が変わってしまいかねません。

その場合は、十分に話し合って頂き、意見をまとめてもらいましょう。

ER図にまとめる。

概念設計の成果物としては、ER図としてまとめることが一般的です。ER図については下記の記事でも解説しています。

【データベース設計】ER図について

ちなみに、この時点では、まだどのＤＢＭＳ製品を使うかまでは考えません。

論理設計

「概念設計」で明らかになった各情報について整理していきます。

具体的には下記の作業を行います。

多：多の分解

下記のように、RDBは、「多：多」の関係をうまく扱うことができません。（理由としては、テーブルを結合させる際に、重複した値が入っていると、結合結果が増えてしまうためです。）

なので、「多：多」は、「1：多」同士に分解してあげる必要があります。

キーの整理

キーには、「主キー」、「外部キー」等がありますが、特に重要なのが「主キー」です。

もし、主キーが設定されていない、もしくは、不適切に設定されてしまっているような主キーを見つけた場合は、「人工的なキー」の導入も視野に入れましょう。

正規化

この作業が論理設計における中心的な作業になり、「非正規形」になっているテーブルを、「第三正規形」まで持っていく作業になります。

正規化については、下記の記事で解説しています。

【データベース設計】正規化について

物理設計

どの、ＤＢＭＳ製品を使うかまで考えて、具体的に各テーブルの列の設定を決めていき、それを元にどれくらいの性能が必要なのかという、ハードウェア的な要素まで決定させます。

1.テーブルを定義する。（インデックス等も踏まえて。）

まずは、テーブルの物理設計をしなければなんともなりません。具体的には、下記のような項目を決めます。

• データ型
• インデックス
• 制約
• デフォルト値

【データベース設計】テーブルを作る際の基本ルール

２．ハードウェアのサイジングを行う。

詳しくは、下記の記事で解説しています。

【データベース設計】ハードウェアのサイジング（容量と性能）を決める。（物理設計）

３．ストレージの冗長構成を決定する。

やはり、データベースは、重要なデータを扱うので、データの安全性を高めることは必須になります。

その際には、「RAID」という技術を使うことが一般的です。どのRAIDを使えばよいかは下記の記事で解説しています。

【データベース設計】ストレージの冗長構成(RAID)の決定（物理設計）

4.物理的なファイルの構成を検討する。

ここでは、実際にデータベースに伴う物理的なファイル容量を加味して、どのような物理構成にするのが望ましいか検討します。

詳しくは、下記の記事で解説しています。

【データベース設計】ファイル容量の検討

設計（というかＤＢ設計）の心構え

最初から完璧な設計を求めず、変更があればためらわずテーブル設計を変更すること。