SQLの設計に必要な4つの手順とは?わかりやすい図を使って解説!


SQLの基礎はわかったけど、設計はどうやればいいんだろう……?
SQLの設計方法や具体的な手順を知りたいな……

SQLの基礎ができるようになっても、自分で設計を始めると躓いてしまう人は多いです。基礎を学ぶときは設計済みのケースがほとんどなので、考え方から学ぶ必要があります。

ただ、考え方といっても何から始めればいいの?と思う人が、ほとんどなのではないでしょうか。

こんにちは!フリーランスエンジニア兼テックライターのワキザカです。

この記事では、SQLの設計に必要な4つの手順について解説します!

設計方法の概念を解説するだけでなく、実際に設計するサンプルも用意しています。これから設計方法を学びたい人におすすめです。

この記事はこんな人のために書きました。

  • SQLの設計に必要な知識を学びたい人
  • SQLの設計を1人で出来るようになりたい人

SQLの設計をする4つの手順とは?

まず、SQLの設計をする4つの手順について解説します。

  • 要件の明確化
  • エンティティの定義
  • 正規化の実行
  • ER図の作成

それぞれ詳しく解説しますね。

SQLの設計手順1:要件の明確化

1つ目は、要件の明確化です。

何となく考えたデータだと、必要なデータが漏れてしまう可能性がありますよね。そのため、必要なデータを洗い出していきます。


必要なデータを洗い出す

まずはざっくり箇条書きでも良いので、洗い出していきましょう。

ある程度洗い出せたら、次にエンティティを定義していきます。

SQLの設計手順2:エンティティの定義

2つ目は、エンティティの定義です。

要件だけでは、具体的なテーブルイメージが湧かないですよね。そのため、テーブルの定義をしていきます。

具体的には、以下のようなイメージですね。


テーブル定義のイメージ

要件の明確化で洗い出したデータを、テーブルで考えていきます。

細かい粒度は気にせず、テーブルを洗い出していきましょう。

SQLの設計手順3:正規化の実行

エンティティの洗い出しが終わった直後では、データ操作・管理がしやすい構造になっていません。

そのため、「正規化」をしてテーブルの構造を整えていきます。

たとえば、以下のようなイメージです。


正規化のイメージ

正規化前の部署経費一覧テーブルには、「部署コード」「部署名称」のデータが1つのテーブルに入っていました。ただ、部署コードで紐づければ取得できる項目ですよね。

このように、1つのキーで取得できる項目を、主キーと言います。主キーで取得できる項目が他にもあれば、別テーブルで管理するイメージで、正規化をしていきます。

ちなみに主キーの考え方については、以下でも詳しく解説しています。読むと理解が深まるので、先に読んでおくのがおすすめです!

【SQL入門】PRIMARY KEY(主キー)制約とは?追加や削除についても解説
更新日 : 2019年4月1日

SQLの設計手順4:ER図の作成

4つ目は、ER図の作成です。

エンティティとして洗い出したものの、繋がりがわかりにくいですよね。具体的に言うと、「部署経費一覧テーブルの部署コードを使えば、部署テーブルから部署名称が取得できる」という、繋がりがわかりづらいです。

そのため、以下のようにER図を作成し、繋がりをわかりやすくしましょう。


ER図のイメージ

部署経費一覧テーブルと部署テーブルは、多対1で紐づいています。

部署経費一覧テーブルには、同じ部署コードのデータが複数ありますよね。ただ、部署テーブルには同じ部署コードのデータが1つしかありません。

このように、テーブル間の繋がり + 繋がり方の割合(1対1、1対多、多対1、多対多)を表すのが、ER図です。

簡単なSQLの設計をやってみよう!

ここまで、SQLの設計手順について考え方をメインに解説しました。

ここからは、1つの事例をもとに設計する手順を解説しますね。

今回はサンプルとして、「請求データを管理するツール」を作るときのSQL設計をしていきます。


請求データを管理するツールのイメージ

画面からデータを入力し、登録ボタンをクリックすることでデータを登録するツールです。上記は登録画面のみ載せてますが、登録したデータを検索・更新・出力などもできることを想定しています。

SQLの設計手順を、1つずつ解説します。

要件の明確化

まずは、要件を明確化していきます。

今回のサンプルだと、最低限以下は必要ですよね。


請求データ管理ツールで必要なデータの例

  • 登録データ(No、請求書番号、発行日...)
  • 得意先一覧


このように、まずはざっくりと必要な要件を洗い出していきます。

エンティティの定義

要件が明確化できたら、エンティティの定義を考えていきましょう。

画面に一覧データがあるので、一覧データのレベルでエンティティの定義をしていきます。


画面の一覧データから必要なエンティティを定義

上記のように、画面に必要なデータをまずはテーブル化していきます。

正規化の実行

ただこれだと管理がしづらいので、次に正規化をしていきます。

正規化は、以下のようなイメージででデータを操作・管理しやすい形に変えていく作業です。


正規化のイメージ

今回の例で言うと、以下のように正規化ができます。


請求データ一覧テーブルを正規化した例

この例では、「得意先コード」「得意先名称」が請求データ一覧テーブルに含まれていたのを、得意先一覧テーブルに分けています。

ここからさらに、テーブルの繋がりをわかりやすく定義していきます。具体的には、ER図化して繋がりを明確化していきます。

ER図の作成

ER図は、次のようにデータの繋がりをわかるように書くイメージでした。


ER図のイメージ

これを参考に「請求データ一覧」「得意先一覧」テーブルをER図化すると、次のようになります。


請求データ一覧テーブルと得意先一覧テーブルのER図

請求データ一覧テーブルの得意先コードと、得意先一覧テーブルの得意先コードの繋がりがわかりやすくなりましたよね。このように、ER図を完成させれば設計は完了です。

SQLの設計の失敗例から学ぶ、成功させるコツとは?

次に、SQLの設計を成功させるコツについて、以下3つの視点で解説します。


SQLの設計を成功させるコツ

  • いきなりER図を考えない
  • 要件の明確化は粒度を考えない
  • 正規化についての理解を深める


それぞれ解説しますね。

成功させるコツ1:いきなりER図を考えない

1つ目は、「いきなりER図を考えない」です。

SQL設計のゴールがER図と知ると、いきなりER図を考えようとする人が稀にいます。

設計になれている人なら出来るかもしれませんが、必要なデータに抜け漏れが発生しがちです。テーブルを作った後に抜け漏れが見つかってしまうと、直すのが大変になってしまいます。

少しめんどくさいかもしれませんが、要件の明確化からはじめるようにしましょう。

成功させるコツ2:要件の明確化は粒度を考えない

2つ目は、「要件の明確化は粒度を考えない」です。

要件の明確化をするときに、粒度に迷って時間がかかってしまう人がいます。

時間を書けることは悪くありませんが、いつまでたっても次の設計に移れないと...時間がもったいないですよね。

エンティティの定義でテーブルの粒度に自然となるので、要件の明確化は粒度にこだわらないようにしましょう。まずは、洩れなくデータを洗い出していくことが重要です。

成功させるコツ3:正規化についての理解を深める

3つ目は、「正規化についての理解を深める」です。

今回は正規化を簡単な概念・考え方で解説しましたが、正規化はもっと細かい考え方があります。

第一正規化、第二正規化、第三正規化のように正規化する方法・考え方がわかれているため、もっと正確に設計をしたいなら正規化への理解が必須です。

深く学びたい方は、以下の本がおすすめです!

達人に学ぶDB設計 徹底指南書 | Amazon

DB設計の方法を1から細かく解説しているためわかりやすい。
情報を網羅的に学んでいきたい方に、おすすめです。

まとめ

今回は、SQLの設計に必要な4つの手順について解説しました。

慣れるまでは大変かもしれませんが、SQLの設計の知識はSQLを書くときにも使えます。

ぜひ、簡単な設計からでいいので挑戦してみてくださいね!

書いた人

Sanshiro Wakizaka

北海道出身の30歳で、フリーランスエンジニア兼テックライターとして活動中。新卒入社したメーカー系のIT企業で、システムエンジニアとして約5年勤務。

Webアプリ、業務アプリ開発において、要件定義 ~ 運用保守まで様々な経験あり。また3歳の娘がいる1児のパパで、日々娘との時間を確保するために仕事を頑張っています!

侍エンジニアでは、【誰でもわかるレベルのわかりやすさ】を意識して、記事を執筆中。

あなたの目的に合わせた
SAMURAI ENGINEERの運営サービス

SAMURAI ENGINEER Pro

未経験でも挫折しないプログラミングスクール

詳細はこちら

SAMURAI ENGINEER Plus

日本最大級のサブスク型オンラインITスクール

詳細はこちら

SAMURAI ENGINEER Freelance

「一人で稼げる」スキルを身につける

詳細はこちら