データベース基礎入門｜テーブル設計の考え方を身につける

「データベースって、要するに大きいExcelの表でしょ？」——上司から「あの顧客リスト、ちゃんとしたデータベースにできる？」と言われたとき、そう思った方は少なくないはずです。けれども、その「大きい1枚の表」のまま運用を続けると、次のようなことが起こります。注文が増えるたびに「注文1・注文2・注文3…」と列を横に足し続け、4件目で列が足りなくなると同じ顧客をもう一度別の行にコピペする。引っ越しがあれば、その顧客の住所を散らばった全部の行で直す羽目になり、一部を直し忘れて食い違う。「（株）○○」と「株式会社○○」の表記ゆれで、同じ会社が二重に数えられる。こうした“しんどさ”の正体は、データの量でも操作の下手さでもありません。1枚の表に、役割の違う情報を何でも詰め込んでいることにあります。

この講座は、その手前にある土台——データを正しい「表（テーブル）」の形に設計する考え方だけに絞ってお話しします。最初に住み分けを宣言しておきます。1枚の表を関数で集計する操作はExcel基礎入門、クラウドで共有して共同編集する設定はスプレッドシート基礎入門、集めたデータから傾向を読む「目的→集計→表現」はデータ分析入門、設計した箱をもとに業務アプリを組むのはノーコードツール入門が、それぞれの正本です。本講座はそれら全部の手前で「箱の形（テーブル設計）」を整える回で、集計・操作・アプリ化の各論には立ち入りません。

この講座を終えると、次の3つができるようになります。データベースを「大きい1枚の表」ではなく役割ごとに分けた複数のテーブルを共通のIDで結び、同じ情報を1か所だけに持つ仕組みとして自分の言葉で説明できること（Excelの1枚シートとの違いを言えること）、役割の混ざった1枚の表を別テーブルに分けて主キーを立て、IDで結ぶところまで設計できること、そして重複の起きないテーブル構成図を紙1枚に作成できることです。覚えて帰る型は、役割で分ける → 主キーを立てる → IDで結ぶ → 重複を1か所に寄せる。本講座では、顧客と注文がごちゃ混ぜになった1枚のExcelシートを、顧客テーブルと注文テーブルに分け、顧客IDで結ぶ形に設計し直す、という同じ場面を全章で追いかけます。

データベースとは何か——Excelの1枚シートとの違い

データベースはテーブル・レコード・カラムでできた「ためる箱」

まず言葉を整理します。データベースとは、共有や再利用がしやすいように一定の形式で作成・管理されたデータの集合のことです（出典：IT用語辞典 e-Words「データベース（DB）とは」）。そして、いま最も普及しているのがリレーショナルデータベース（関係データベース、RDB）という方式です。これは、1件のデータを複数の項目の組として表し、その組を並べてデータをためていく方式で、項目を列、1件分を行とする表（テーブル）の形で示されます（出典：e-Words「リレーショナルデータベース（RDB / 関係データベース）とは」）。単に「データベース」と言うとき、多くはこの方式を指します。

表を構成する部品には名前があります。表そのものがテーブル、横方向の1件分がレコード（行）、縦方向の項目がカラム（列・フィールド）です（出典：e-Words「リレーショナルデータベース」）。顧客リストで言えば、表全体がテーブル、1社1行がレコード、「顧客名」「住所」「電話」といった見出しがカラム、ということになります。ここまでは、Excelの「表」「行」「列」とほぼ同じ感覚で構いません。「テーブル＝表」「レコード＝行＝1件」「カラム＝列＝項目」という3点セットを、まずそのまま頭に入れてください。この章から先は、共通例の「顧客と注文がごちゃ混ぜになった1枚シート」を題材に、この箱をどう組み直すかを順番に見ていきます。

リレーショナルデータベースは「役割で分けた複数の表をIDで結ぶ」形

違いが出るのはここからです。リレーショナルデータベースでは、実際のデータを1枚の大きな表に詰め込むのではなく、複数の表の集合として管理します。出典の説明でも、実際のデータベースは「顧客マスタ」「製品マスタ」「受注明細」のように複数の表に分け、「受注明細の顧客IDは顧客マスタを参照する」というように、表をまたいで同じ項目（ID）で対応付けて管理する、とされています（出典：e-Words「リレーショナルデータベース」）。つまり、役割の違う情報は別々の表に分け、共通のIDで結ぶのがこの方式の核です。

ここで「役割で分けるとかえって面倒では？」と感じるかもしれません。たしかに表が1枚から2枚に増えます。しかし、増えるのは表の枚数だけで、書く情報の総量はむしろ減ります。1枚シートでは同じ顧客の住所を注文の数だけ繰り返し書いていましたが、分ければ住所は1か所に1回書くだけで済むからです。「同じ情報を1か所だけに持つ」ことが、データベースという方式が目指している状態です。

なお、こうして設計したデータベースを実際に操作・検索するときには、SQLという問い合わせ言語を使うのが標準です（出典：e-Words「SQLとは」）。ただしSQLはあくまで「箱の形を決めた後に使う操作の道具」であって、本講座では立ち入りません。今回の主役は、その手前にある箱の形をどう設計するかです。SQLでうまく集計できないと悩む前に、そもそも箱が正しい形になっているか——多くのつまずきは、操作ではなく設計の段階にあります。

「Excelでできてるから同じ」というつまずき

ここでのつまずきは2つあります。1つは「Excelで管理できているのだから同じだ」という思い込みです。Excelの1枚シートは“1枚の表を操作・集計する”側、データベースは“役割で分けた複数の表を設計する”側で、立っている場所が違います。1枚シートのまま注文を増やすと列が横に伸び続け、同じ顧客が複数行に散らばる——冒頭の“しんどさ”は、まさに「分けるべきものを分けていない」ことから来ています。もう1つは「データベース＝特定の製品名」という思い込みです。本体は製品ではなく、役割で分けた複数のテーブルをIDで結ぶという設計の考え方そのものです。製品を選んだり構築したりするのは、設計が決まったずっと先の話です。

この章の確認（演習）

あなたが普段使っている1枚の表を1つ思い浮かべてください。その表の中に、役割の違う情報が何種類混ざっているかを書き出してみましょう（例：顧客の情報と、注文の履歴）。そのうえで、「この表はExcelの1枚シートと、データベースの複数テーブルのどちらの考え方で作られているか」を一言で説明してみてください。

テーブル・レコード・カラム——表を「役割」で分ける

1つのテーブルは1つの役割だけを持つ

設計の第一歩は「役割で分ける」です。データベース設計の基本ルールである第1正規形の考え方では、繰り返しグループを排除し、関連するデータのまとまりごとに別々のテーブルを作ることが求められます（出典：Microsoft Learn「データベース正規化の説明」）。言い換えれば、1つのテーブルには1つの役割（テーマ）だけを持たせる、ということです。

共通例で考えましょう。手元のごちゃ混ぜシートには、「顧客名・住所・電話」といった顧客そのものの情報と、「注文日・商品・金額」といった注文の履歴が同居しています。これは役割の違う2種類です。そこで、顧客の情報を集めた顧客テーブルと、注文の履歴を集めた注文テーブルの2つに分けます。顧客は1社につき1行、注文は1注文につき1行になります。

見分け方はシンプルです。その列が「顧客そのものについての情報か（住所・電話など、注文があってもなくても決まっている情報）」か、「注文1件ごとに変わる情報か（注文日・商品・金額など、注文のたびに別の値になる情報）」かを問います。前者は顧客テーブル、後者は注文テーブルです。同じ顧客が3回注文しても、住所や電話は3回とも同じはずです。だから住所を注文側に書くと同じ値が3回繰り返されてしまう——この「繰り返しが起きる列」は、役割の置き場所を間違えているサインだと考えてください。

1セルに1つの値——「注文1・注文2…」と列を横に増やさない

役割を分けると同時に直したいのが、繰り返し項目を列で横に増やす癖です。出典では、同じようなデータを入れるために1つのテーブルへ複数のフィールドを並べてはいけない、と明確に述べられています。たとえば1人の学生に複数のクラスがあるとき、「Class1・Class2・Class3」と列を横に足すのは設計上の問題で、別テーブルに分けて持つべきだ、とされています（出典：Microsoft Learn「データベース正規化の説明」）。これはまさに、冒頭の「注文1・注文2・注文3…」と列を足していた状態そのものです。1件＝1行、1項目＝1列、1つのセルには1つの値——この形に直すと、注文が4件目・5件目と増えても列を足す必要はなく、注文テーブルに行を1本ずつ足していくだけで済みます。

なお、こうした「重複や矛盾が起きないテーブル設計」「主キー・外部キーの考え方」「正規化の目的と手順」は、国家試験の知識体系でもデータベース設計の基礎として位置づけられています（出典：IPA 基本情報技術者試験シラバス）。本講座では番号のついた正規形を順に解説することはせず、役割で分ける・1セルに1つの値という最小限の規約だけを押さえます。

役割をまたぐ列を両方に重複させない

ここでのつまずきは、役割をまたぐ列を両方のテーブルに重複させてしまうことです。たとえば「顧客の住所」を注文テーブルにも書き込んでしまうと、同じ顧客の住所が注文の数だけ複製され、引っ越しのときに直す場所が一気に増えます。住所は顧客そのものの情報なので、顧客テーブルにだけ置く——この振り分けの判断が、第2章の肝です。

この章の確認（演習）

共通例の1枚シートの列（顧客名・住所・電話・注文日・商品・金額…）を、顧客テーブルと注文テーブルのどちらに置くか、1列ずつ仕分けしてください。判断の基準は「これは顧客そのものの情報か、それとも注文1件ごとに変わる情報か」です。仕分けが終わったら、どちらにも書きたくなった列がなかったかを振り返ってみましょう。

主キーとリレーション——IDでテーブルを結ぶ

主キーは「その1行を一意に指す目印」

役割で2つに分けたら、次は各テーブルに主キーを立てます。主キーとは、テーブルの中でレコード（行）を一意に識別できるように指定する列のことです。主キーに選んだ列は、すべての行が異なる値を持たなければならず、空（NULL）にもできません（出典：IT用語辞典 e-Words「主キー（PK / プライマリキー）とは」）。重複が許されず、空欄も許されない——これが目印として効く理由です。

「重複が許されない」と「空欄が許されない」の2つは、目印として欠かせない条件です。もし同じ値の行が2つあれば、その値で行を1つに特定できません。もし空欄があれば、その行は名指しできません。だから主キーは、必ず全行で違っていて、必ず埋まっている列でなければならないのです。

ここで大事なのが、何を主キーにするかです。出典では、行が次々に追加されるテーブルでは、識別のためだけに通し番号のような項目を設けて主キーにすることが多い、と説明されています。理由は、氏名のように意図せず重複してしまう値を避けるためです（出典：e-Words「主キー」）。共通例なら、顧客テーブルには連番の顧客ID（C001、C002…）、注文テーブルには連番の注文ID（O001、O002…）を立てます。「顧客名」を主キーにしないのは、「（株）○○」と「株式会社○○」のような表記ゆれや、同名の別会社で重複が起きるからです。名前は人にとって読みやすい一方、目印としては不安定——だからこそ、内容に意味を持たない連番のIDを別に立てる、というのが実務の定石です。これが、冒頭の二重カウントを根本から防ぐ一手になります。

別テーブルを指す列は名前ではなくIDで持つ

主キーが立ったら、2つのテーブルをIDで結びます。注文テーブルには「どの顧客の注文か」を顧客名ではなく顧客IDで持たせ、顧客テーブルを参照させます。この「別のテーブルの登録済みの値しか入れられないようにする」仕組みが外部キーです。出典には、まさに同じ構図の例があります——受注テーブルの顧客コードの列に、顧客テーブルの顧客コードを外部キーとして設定すれば、顧客テーブルに登録されていない顧客コードを誤って入力することを防げる、というものです（出典：e-Words「外部キー（FK）とは」）。こうして表と表を結ぶ関係づけがリレーションで、「受注明細の顧客IDは顧客マスタを参照する」という形で、複数の表をまたいで同じIDで対応付けます（出典：e-Words「リレーショナルデータベース」）。

この形にすると、何が変わるか。具体的に見ましょう。たとえば顧客ID「C001」の会社が3回注文していたとします。1枚シートのままなら、その会社の住所は3行に書かれていて、引っ越しがあれば3行とも直さなければなりません。注文が10回なら10行です。ところが顧客テーブルと注文テーブルに分け、注文テーブルが持つのは顧客ID「C001」だけ、という形にすると、住所は顧客テーブルのC001のその1行だけに書かれます。引っ越しのときに直すのは、何回注文していても1行きりです。表記ゆれによる二重カウントも、「（株）○○」か「株式会社○○」かに関わらず、同じ会社は同じ顧客ID「C001」で結ばれている限り、二重には数えられません。役割で分ける → 主キーを立てる → IDで結ぶ——ここまでで、冒頭のしんどさの大半は消えます。

この章の確認（演習）

共通例で、顧客テーブルに顧客ID、注文テーブルに注文IDを連番で割り振ってください。そのうえで、注文テーブルの各行に「どの顧客IDの注文か」を書き入れ、注文テーブルから顧客テーブルへ顧客IDでたどる線を図に描きます。最後に、「主キーに顧客名を使わなかったのはなぜか」を一言で説明してみましょう。

テーブル構成図を1枚に書く——重複なく“箱の形”を仕上げる

テーブル構成図は「表の数・列・主キー・結ぶID」を1枚にまとめたもの

設計の仕上げは、ここまで決めたことを1枚の図にまとめることです。図に書くのは、どんなテーブルがいくつあるか／各テーブルにどんな列があるか／各テーブルの主キーはどれか／どのIDでテーブルを結ぶかの4点です。こうした「データの関連を表現する」設計図は、E-R図と呼ばれる手法でも描かれ、構成要素・属性・関連や、1対1・1対多といった結びつきの数を表します（出典：IPA 基本情報技術者試験シラバス）。本講座では厳密な記法にはこだわらず、表名と列を箱で書き、主キーに印を付け、結ぶIDを線でつなぐ——その程度の手書きの図で十分です。ツールに触る前に、紙1枚で箱の形を決めきるのがゴールです。

「同じ情報は1か所だけ」で見直す

図ができたら、最後に「同じ情報が2か所以上に出ていないか」を点検します。これが設計の品質を決めます。出典では、データを整理してテーブルに分け関係を結ぶ正規化の目的は、冗長性（重複）と一貫性のない依存関係を排除することだと説明されています（出典：Microsoft Learn「データベース正規化の説明」）。なぜ重複が悪いのか。同じデータが複数の場所にあると、変更のときにすべての場所をまったく同じに直さなければならず、1か所でも直し忘れるとデータが食い違うからです。出典も、顧客の住所変更は、そのデータが顧客テーブルにだけ入っていれば簡単に実装できる、と述べています（出典：Microsoft Learn「データベース正規化の説明」）。冒頭の「引っ越しのたびに全部の行を直す」しんどさは、まさに住所が複数行に重複していたことが原因でした。

だから点検の合言葉は「同じことを2回書かない」です。具体的には、次の3点を順に見ます。1つ目、注文テーブルに顧客の住所や顧客名まで丸ごとコピーしていないか（コピーしているなら、顧客IDだけを残して住所・顧客名は顧客テーブルへ寄せる）。2つ目、「電話1・電話2」「注文1・注文2」のように繰り返し項目が列で横に増えていないか（増えているなら、別テーブルの行として持つ）。3つ目、どこにも持ち主のないあいまいな列が残っていないか（その列は本来どちらの役割かをもう一度問う）。見つけた重複は、その情報の持ち主のテーブル1か所に寄せます。重複を1か所に寄せる——これが設計4ステップの最後です。この点検を通すと、「ある事実は、どこか1つのテーブルの1行にだけ書いてある」という状態になります。それが、変更に強い箱の形です。

この章の確認（演習）

共通例のテーブル構成図を紙1枚に書き上げてください。顧客テーブルと注文テーブルの列を書き、それぞれの主キー（顧客ID・注文ID）に印を付け、注文テーブルの顧客IDから顧客テーブルへ線を引きます。そのうえで、「ある顧客が引っ越したとき、住所は何行直せば済むか」を、Before（ごちゃ混ぜの1枚シート）とAfter（分割後）で数えて書き比べてみましょう。差がそのまま、この設計の効果です。