はじめに

業務で0からシステム開発を行ったり、客先PJでのDB設計に関わる中で、感覚として「こうした方が開発しやすいしいいんじゃない？」というふんわりしていたDB設計について、正しい知識と根拠を持ちたいと思いこの本を手に取りました。
DB設計に関しては今後どれだけ色んな技術が発展しても腐らない知見だと思うので、将来の自分に向けて情報をまとめました。

対象者

未来の自分
駆け出しエンジニアの同志

スコープ対象

達人に学ぶDB設計徹底指南書~初級者で終わりたくないあなたへ~(以下本書)に記載されているDB設計への考え方

スコープ外

各RDBでの挙動、実装コード、マニュアルについて

用語定義

データ設計: データベースに保存するデータの設計。一般的なデータベース設計とほぼ同義。(以下DB設計)

#1 なぜDB設計が大切なのか

プログラムはシステム開発の過程で大きく変わっていくのに対し、データはあまり変化しません（永続的）。データの意味や形式がしっかり決まっていれば、プログラム間で共用しやすく、業務要件の変更にも柔軟に対応できます。そのため、現在ではプログラム中心（POA）ではなくデータ中心（DOA）のアプローチが主流となっており、DB設計はシステム開発において非常に重要な役割を担っています。

DB設計はシステム開発の中心

#2 DB設計におけるスキーマについて

一般的に以下の3つのレベルに分けられます。

外部スキーマ (外部モデル) / システム利用者が見る情報
概念スキーマ (論理データモデル) / 開発者が見る、設計する情報
内部スキーマ (物理データモデル) / DBMSが見る、利用する情報

詳細は省きますが、簡単に解説すると外部スキーマと内部スキーマに変更があっても、間に概念スキーマが入ることで互いに影響を受けないようにするための緩衝材の役割をしています。

#3 論理設計と物理設計

論理設計

論理設計とは、概念スキーマを定義することです。

論理設計のステップは以下の通りです。

エンティティの抽出
エンティティの定義
正規化
ER図の作成

以下それぞれのタスクについての解説です。

1. エンティティの抽出

エンティティとはデータの集合体、例えば「顧客」や「社員」、「店舗」など、システム開発において必要なデータのことを指し、これらを洗い出す作業をエンティティの抽出といいます。
これらは要件定義にも重なる部分があるため、顧客やシステム利用者と要件を詰めていく中で、どのようなエンティティが必要であるかを検討する必要があります。

2. エンティティの定義

エンティティはデータを属性という形で保持するが、例えば、「社員」というエンティティを抽出した場合、属性として「名前」や「社員番号」などが考えられます。
エンティティは通常、複数の属性を持ちます。
テーブルにおける「列」と同義と考えると分かりやすいかもしれません(社員テーブルに対して、どのような列を置くか)

3. 正規化

データのCRUD操作が整合的に行えるようにエンティティを整える事。
論理設計においては最も重要な部分であり、1~5段階までレベルがあります。
次の記事で1~3レベルの正規化についての解説と練習問題を交えてまとめておくので、良ければそちらも参考にしてください。

4. ER図の作成

正規化を行うとエンティティの数が増え、関係性がぱっと見で分かりにくくなります。
その問題を解決するために、ER図というものを作成して、エンティティ同士の関係性を視覚的に分かりやすく示したものです。

論理設計では正規化が一番大切であり、正規化を理解すれば、論理設計を理解したものといっても過言ではない！！

物理設計

物理設計とは、内部スキーマを定義することであり、論理設計を受けて、データを格納するための物理的な領域や格納方法を定める工程です。
物理設計のステップは以下の通りです。

テーブル定義
インデックス定義
ハードウェアのサイジング
ストレージ冗長構成決定
ファイルの物理的配置決定

物理設計に隣接して、バックアップ設計とリカバリ設計というのがあります。
これらを含めた物理設計の詳細については、本書のメイントピックではないのでここでは割愛しますが、非常に重要な内容ではあるので、気になる方は本書で確認ください。

最後に

次の記事で正規化についてまとめていますので、良ければこちらもご覧ください