前の記事では、データベースから上手にデータを抜き出す「SQLの小技」を紹介しました。
ここまでの話で、「データの抜き方」はなんとなくイメージできたかと思います。
では、そもそもそのデータは、データベースの中に「どんな形で」保存されているのでしょうか。
「データベースの設計」とか「正規化（せいきか）」という言葉を聞くと、なんだか急に難しそうな、専門家だけの領域に思えますよね。
でも、本質はものすごくシンプルです。
一言でいうと、
「机の引き出しや、会社の書類を、後から探しやすいように綺麗に整理整頓するルール」
のこと。
今回は、難しい専門用語はなるべく机の奥に片付けて、大人のための「どこよりも分かりやすいデータベース設計の基本」を、身近な例で解説します。
なぜデータベースは「整理整頓」が必要なのか？
データベースの設計が悪いと、どれだけ優れたSQLを知っていても、データを上手に抜くことができなくなります。
一番分かりやすいダメな例が、「1枚のExcelシートに、何でもかんでも全部書き込んでいく」という、会社の現場でよくある力技の運用です。
例えば、会社の「注文管理」を1枚の表でやろうとすると、こんな面倒なことが起こります。
- Aさんが買い物をするたびに、Aさんの「住所」や「電話番号」を何度も何度も同じ表に書き込まないといけない
- Aさんの引っ越しで住所が変わったら、過去の何百件ものデータをすべて手作業で書き換えないといけない（どれか1つを書き忘れたらデータがバラバラになる）
- 手入力が多すぎて、ある行では「Bスーパー」、別の行では「Bすーぱー」と、文字の揺れが発生して集計できなくなる
努力はしているのに、やればやるほど泥沼にはまっていく。
これが「設計のルール」を知らないことで起きる悲劇です。
解決策は「書類の仕分け」。表を2つに分けるという知恵
このドタバタを解決するために、データベースの世界では「同じことを何度も書かないように、表を役割ごとに別々に分けよう」というルールがあります。
「同じ情報を、あちこちの表で保持しない」ということ。
これが、専門用語でいう「正規化（せいきか）」の第一歩です。
先ほどの「注文管理」の例なら、力技で1枚にするのではなく、次の2つの表にスパッと仕分けます。
- 「お客様名簿」の表（お客様のID、名前、住所、電話番号だけを記録する）
- 「注文履歴」の表（いつ、どのお客様IDが、何を、いくらで買ったかだけを記録する）
こうして分けておけば、お客様が100回買い物をしても、住所や電話番号を書くのは「お客様名簿」の最初の1回だけで済みます。
住所が変わったときも、名簿の1箇所を書き換えるだけで、過去の注文データまで一瞬ですべて綺麗に繋がります。
この「表を分ける考え方」は、データベース経験者ならスッと入ってきます。
しかし、一般のユーザーさんにとっては、ピンとこないことが多いのです。
これを今読んでいるあなたも、そうだったりして。
なので、データベース導入時の説明で「えっ」という顔をよくされます。
お客様の登録はここで、商品の登録はここで、税率の登録はここで、・・・と、表が多くなるのでややこしく、まどろっこしく感じられるようです。まあ、たしかにね。
そこで実例を示して納得していただくのも、データベース技術者の大事な仕事！
「ここで住所を1か所変えたら、ほら、ここの住所も、ここの住所も、全部変わってるでしょ」
「ほんまや！便利やなあ～～～！」
これ、これ。この言葉を聞くと嬉しくなるのは、何年やってても同じです。
（データベースという仕組みを私が発明したのではなく、私も利用者なのですけどね）
2つの表を繋ぐ「鍵（ID）」の重要性
「表をバラバラに分けちゃったら、後から『誰が何を買ったか』が分からなくなるんじゃない？」
その通りです。
だからこそ、分けた表同士を繋ぐための「共通の番号（ID）」が必要になります。
会社の書類でも、顧客番号や商品コードが付いていますよね。
データベース設計の基本は、「名前」ではなく「番号」で表と表を紐付けることです。
（私たち一般ユーザーは、通常、これらの番号を意識したり、覚えておく必要はありません。それでいいのです）
SQLを使ってデータを引っ張るときは、この「番号」をヒントにして、パソコンの裏側で2つの表をつなげて画面に表示させています。
設計が綺麗なデータベースは、この番号の繋がり（リンク）が一本の美しい線のようにつながっています。
40代以降の経験者がデータベース設計で有利な理由
実は、プログラミングのコードを書くこと以上に、この「データベースの設計」は、人生経験がある大人の方が圧倒的に得意な分野です。
なぜなら、この作業に一番必要なのは最新のIT知識ではなく、
「業務の全体の流れを見渡す力」や「物事を整理整頓する段取り力」だからです。
- 「このデータとあのデータは、後から一緒に集計したくなるはずだな」
- 「ここにこの項目がないと、現場の事務の人が困るだろうな」
こうした、実務の「先回りをした優しさ」をデータベースの形に落とし込めるのは、若い人よりも、社会の現場をたくさん見てきた40代、50代、60代の強みです。
派手さはありませんが、じわじわと市場価値が下がらない、本当に強いスキルになります。
まとめ：仕組みが分かれば、ITはもっと面白くなる
今回は、データベース設計の「仕分けのルール（正規化）」について、概要をお話ししました。
「1枚の表に詰め込まず、役割ごとに分けて、番号で繋ぐ」
これさえ頭に置いておけば、今後のIT学習の理解度が5倍に跳ね上がります。
本を読んだ時にも、「あ、だからこの表は分かれているんだな」と、裏側の意図が読めるようになるからです。
「この表の分け方のコツを、もっと具体的なパズル感覚で学んでみたい」
「自分の得意な業務知識を活かして、在宅でデータ設計の相談に乗れるようなスキルを目指したい」
そう思ったら、一度プロのカリキュラムを覗いてみてください。
私が「倒れそうで倒れない歩み」の最初の踏み台として紹介しているCodeCampの無料カウンセリングでは、現役のエンジニアが、あなたのこれまでの仕事経験を聞いた上で、「どの順番で設計の知識を足していけば、一番仕事に繋がりやすいか」を客観的にアドバイスしてくれます。
➔ [無料] CodeCampのカウンセリングで大人のIT学習についてプロに相談してみる焦らず、引き出しを一つずつ整理するように、あなたのペースで進んでいきましょう。
