チェスの盤上

先日、改めてデータベース(DB)設計について学び直しました。RDB(リレーショナル・データベース)と呼ばれる、最も標準的に使われているデータベースです。

今回は、その際に読んだ「達人に学ぶDB設計 徹底指南書」「SQLアンチパターン」の2つの書籍が素晴らしかったので、今回はその中から、データベースの論理設計についてを紹介していきたいと思います。

データベースの論理設計は以下の4ステップで進めていきます。

1.エンティティの抽出
2.エンティティの定義
3.正規化
4.ER図の作成

この記事では、各チャプターを使って、「論理設計とは何か」や、4つのステップについて詳しく説明していきたいと思います。

論理設計とは

システムの世界では「論理」という言葉がよく登場しますが、それは、日本語の意味である「整合的で筋道が通っている」という意味ではなく、「物理層の制約にとらわれない」という意味で使います。

物理層の制約とは、データベースサーバーのCPUパワーや、ストレージのデータ格納場所といった、より具体的で実装レベルの条件のことです。

データベース設計を行う際は、まずはこういった物理層の制約は脇において、論理設計から進めていきます。

ステップ1|エンティティの抽出

エンティティは、日本語で「実体」と訳します。具体的には「顧客」や「社員」「店舗」「車」といった、物理的制約を伴わないものも含まれます。

リレーショナル・データベースでは、こうした現実世界のエンティティを、最終的に「テーブル」という物理的単位で格納していくことになります。

そのために、まずは、システムのためにどのようなエンティティが必要になるかを抽出することが論理設計の第一ステップです。

「これは要件定義と重なるところが多いぞ」と気づいた方もいらっしゃるのではないでしょうか。

ご名答です。このエンティティ抽出は、ある程度、顧客やシステム利用者と要件を定義していく中で実施することになります。

ステップ2|エンティティの定義

エンティティを抽出した後は、各エンティティがどのようなデータを保持するかを決める必要があります。

エンティティはデータを属性という形で保持します。これはDBテーブルにおける列(カラム)と同義だと考えてください。

リレーショナル・データベースでは、二次元表に近い「テーブル」というフォーマットでエンティティを保持しますが、各表がどのような「列」を持つかということを定義するのがこの作業です。

ここで特に重要なのは、「キー」という列を定義することです。キーとは、ある特定の列の値を決定するための列のことです。

キーは、「テーブルに重複行を作らない」ために設定される主キー(primary key)と、「2つのテーブルを関係づける」ために設定される外部キー(foreign key)とに分けられます。

ここでは、キーについての詳細については省きますが、上記2種類のキーを適切に設定することは、データベース設計のアンチパターンを防ぐためにとても重要です。

ステップ3|正規化

正規化は、エンティティについて、システムでの利用がスムーズに行えるよう整理する作業です。

特に、正規化は更新(CRUDなど)が整合的に行えるように、エンティティのフォーマットを登録することが目的です。

リレーショナル・データベースの論理設計においては、この正規化が最も重要な土台をなします。

正規化に関しての詳細は、とても長くなってしまいそうなので、また別の記事で紹介したいと思います。

ステップ4|ER図の作成


ER図は、Entity-Relationship Diagramの略です。正規化を行うと、エンティティの数が増えます。

これは第3章で、正規化を学ぶとわかりますが、物理的な観点から見ると、正規化とは、エンティティ(テーブル)を細かく分割していく作業だからです。

すると、そのままではエンティティ同士の関係が把握しにくくなります。大規模システムになると何百という数のエンティティが作られます。

こうした大量のエンティティの関係を把握するためにER図は使われます。

ER図を作成することで、それぞれのテーブルがどういう意味を持っていて、テーブル同士が互いにどういう関係にあるのかということが把握できるようになります。

まとめ

・論理設計とは、物理層の制約にとらわれず、机上で行える
・データベースの論理設計は4つのステップに分けられる
・ここでの論理設計をもとに、物理設計が行われる

ちなみに、DB設計時のセルフチェック用に、以下のようなチェックリストを作りました。

よければ参考に使ってみてください。