【ゼロからわかる】DBの論理設計とは何か

 

 

今回の記事で身に付くこと

 

何も考えずに設計していくと、後々わけがわからなくなりがちです。全体像を掴んでから個別の内容を知ることで、理解が進み、既存のサービスのデータベースも理解しやすくなります。

データベース設計の全体像が知りたい方にはこちらがオススメ！

論理設計とは何か

論理設計とは「物理的な制約にとらわれずに机上でデータベース設計を考えること」です。

物理的な制約とは「データベースサーバーののメモリやCPU、データ型やインデックス」のことです。

つまり、最初は細かいことを抜きにして全体像をつくろうというのが論理設計です。

論理設計は大きく3つの工程に分かれています。

「聞いたことない言葉が3つもでてきた…とりあえず寝よう」とならないようにかみくだいて説明します。

エンティティの定義

エンティティの定義とは「データベースに保存する項目を決めること」です。

 

つくりたいシステムが社員情報管理であれば、まず社員情報が必要だなと考えます。社員情報には、氏名、社員番号、メールアドレス、部署名が必要だと決めていきます。

 

このように、システムに必要な項目を洗い出して、具体的な内容を決めていく作業がエンティティの定義です。

 

正規化

正規化とは「効率の悪いテーブルを分割していくこと」です。

 

効率の悪いとはどういうことでしょうか。例えば、先程の社員情報であれば、部署名がダブって登録されてきます。田中さんと佐藤さんが営業部であれば、2人とも営業部になります。

社員番号	社員名	メールアドレス	部署名
1	田中太郎	tanaka@tack.co.jp	営業部
2	佐藤二朗	sato@tack.co.jp	営業部
3	山田花子	yamada@tack.co.jp	総務部
4	斎藤裕子	saito@tack.co.jp	広報部

 

このとき営業部を営業チームに変更したいとしましょう。田中さんと佐藤さんはともに営業部なので2つのレコードを更新しないといけなくなります。営業部の社員が1000人いれば、1000レコードを更新しないといけなくなります。

 

これは非常に効率が悪いと言えそうです。社員情報から部署を切り分けておけば、部署名が営業部から営業チームに変わったときも１レコード変更するだけで済むようになります。

【社員情報】

社員番号	社員名	メールアドレス	部署id
1	田中太郎	tanaka@tack.co.jp	1
2	佐藤二朗	sato@tack.co.jp	1
3	山田花子	yamada@tack.co.jp	2
4	斎藤裕子	saito@tack.co.jp	3

【部署情報】

部署id	部署名
1	営業部
2	総務部
3	広報部

ER図

ER図とは「データ同士の関係性を表す図」です。

 

先程の社員情報と部署の関係をみると、２つのテーブルができそうです。社員から見れば部署は一つです。（他部署を兼務しないという前提。兼務を考えるとまた変わってきます。）田中さんは営業部のみということですね。

 

一方で部署から見た社員はどうでしょうか。営業部から見れば社員は複数人います。田中さんと佐藤さんが営業部に属していますよね。

 

このようなデータ同士の関係性を示した図がER図です。

なぜデータ同士の関係性を示す図を作成する必要があるのでしょうか。実際小さいプロジェクトではER図がない現場もありました。

 

その理由は、正規化をしていくとエンティティの数が増えてデータ同士の関係性を理解することが難しくなるからです。たくさんのテーブルができればできるほどそのつながりが見えにくくなります。

 

もちろんデータベースを作成した本人はわかります。しかし、あとからプロジェクトに参加した人がデータの流れを把握するのが非常に困難になります。

 

そうなると開発効率が落ちてしまったり、データベースを作成した人が辞めてしまったときに誰もわからなくなるということが起きてしまいます。

 

こうしたことを防ぐためにも、ER図を作成しておくのは非常に大事な作業なのです。

参考図書

今回参考にさせていただいたのは「達人に学ぶDB設計 徹底指南書」です。本を読めば新たな気付きがありますので、気になる方はぜひどうぞ！

 

 

まとめ

最後にまとめていきましょう！

論理設計とは「物理的な制約にとらわれずに机上でデータベース設計を考えること」

その流れは大きく３つありました。

 

正規化して不要な更新を避けたり、ER図を作成することで、誰が見てもすぐにデータの関係性がわかるようになることが狙いでした。

 

論理設計をしておくことで、次に行う物理設計もスムーズに行うことができます！