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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要件の明確化

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

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

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

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

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

エンティティの定義

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

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

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

正規化の実行

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

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

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

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

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

ER図の作成

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

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

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

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

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

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

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

それぞれ解説しますね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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