データベース設計の核心_主キーと外部キーの謎

こんにちは。ザディープダイブへようこそ。さて、今回あなたが 共有してくださった資料ですが、これはデータベースの基本についての対話形式のテキストですね。 ええ、そうです。先輩の秋さんと後輩の海さんのやり取りで 話が進んでいくので、すごく読みやすいんです。 あ、本当だ。これはいいですね。 専門的な内容もこういう形式だとすっと頭に入ってきそうです。 で は 早速 これ を 一緒 に じっくり と 読み解い て いき ましょ う か 。 今回 の ミッション は そう です ね 。 この 資料 から データベース の 心臓 部 と も 言える 主 キー と 外部 キー を 理解 する と 。 で 、 出発 点 が 面白い です よ ね 。 資料 の 中 の 海 産 も 抱い て い た 素朴 な 疑問 。 そもそも なぜ キー 、 つまり 鍵 と 呼ぶ の か 。 はい 。 そこ から な ん で す ね 。 ええ 。 ここ から ス タ ー ト し て 、 ま あ 、 多 く の 人 が 持 っ て い る エ ク セ ル の 表 み た い な イ メ ー ジ か ら 一 歩 進 ん で 、 膨 大 な デ ー タ が ど う 整 理 さ れ て 、 ど う 関 係 づ け ら れ て い る の か 、 そ の 裏 に あ る 設 計 思 操 を 掴 む の が ゴ ー ル で す ね 。 このテキストを、専門用語をIDとか 意図とか、非常に身近で直感的な言葉に置き換えているのが本当に秀逸だなと思います。 確かに。 この比喩を手がかりにデータ整理術の核心に迫っていけるんじゃないかなと。 で、始める前にあなたに一つ質問なんですけど。 はい、何でしょう。 普段何気なく使っているショッピングサイトとかSNSで、なぜあなたの情報が他の誰かの情報と混ざることなく きちんと整理されているんだと思いますか？ うーん 、 考 え た こ と も な か っ た で す ね 。 ですよね。その答えのヒントがまさにこのキーという概念に隠されているんですよ。 なるほど。膨大なデータの中からどうやってピンポイントで私の情報だけを抜き出しているのか。 で は 早速 そ の キ ー の 謎 を 解 き 明 か し て い き ま しょ う 。 まず は 資 料 の 出 発 点 海 産 の 疑 問 か ら で す ね 。 な ん で 鍵 っ て 呼 ぶ の か 。 資料 の 中 で 秋 さ ん は 主 キ ー を こ う 説 明 し て い ま す ね 。 そ の 業 を 世 界 で た っ た 一 つ に 特 定 す る た め の I D 。 ええ 。 こ こ が す べ て の 始 ま り で す 。 具 体 例 と し て 学 校 の 出 席 番 号 と か マ イ ナ ン バ ー 、 商 品 コ ー ド が あ げ ら れ て い ま す ね 。 ク ラ ス に 同 姓 同 名 の 佐 藤 さ ん が 二 人 い て も 出 席 番 号 が 違 え ば 先 生 は 間 違 え な い み た い な こ の 感 覚 は す ご く よ く わ か り ま す 。 まさにその通りなんです。主キーが持つ最も重要で、そして絶対的な性質が 資料にも出てきた一意性、つまりユニークであるということです。 一意性、はい。 データの世界では曖昧さっていうのは、もう致命的なエラーに繋がりますからね。 確かにもしあなたの銀行口座の残高が同性同名の別人 の口座に表示されたら大変なことになりますよね。 そ れ は も う 大 問 題 で す ね 。 だからこそ、この人だ、この商品だ、と絶対に間違えずに一ポン釣りできる識別詞が必要になる。 それが主キーの役割なんです。 なるほど。 で も こ こ で 一 つ 疑 問 が 湧 い て き ま し た 。 お、いいですね。何でしょう? 例えば、会員登録する時ってメールアドレスって基本的に1人1つでユニークですよね。 ええ、そうですね。 わざわざ新しいIDみたいなものを振らなくても、そのメールアドレスをそのまま主キーとして使えばいいんじゃないかなって素人考えですけど思ってしまうんですが。 それは非常に良い質問で、実は多くの人が最初に陥る まあ、罠とも言えるかもしれないんです。 罠ですか? はい。メールアドレスのようにデータ自身が持っている意味のある情報 をキーにすることを自然キーと呼びます。 一見合理的で便利そうに見えますよね。 ええ、見えます。 しかし、ここで一つ考えてみてください。 もしその人がメールアドレスを変更したらどうなりますか? ああ、そっか。 プロバイダーを変えたり会社を辞めたりして メールアドレスって変わることがありますね。 その通りです。もしメールアドレスを主キーにして いたら、その人が過去に行った全ての注文履歴、問い合わせ履歴、投稿とか あらゆる場所に記録された古いメールアドレスを全部新しいものに書き換えるっていう、 もう途方もない作業が発生するんです。 うわあ 。 1つでも修正を漏らせばデータ間の繋がりが切れてしまって、その人の過去の履歴が ごっそり失われるかもしれない。これはデータベースにとってはまさに悪夢なんです。 そ れ は 怖 い で す ね 。 ええ。だからプロの設計では、そうした変わりうる自然キーを主キーにすることはまず避けるのが一般的です。 で は ど う す る ん で す か 。 そこ で 登 場 す る の が 何 の 意 味 も 持 た な い た だ の ラ ン ダ ム な 数 字 や 文 字 列 で す 。 意 味 を 持 た な い 。 え え 。 A 8 1 B - C 7 2 - E 0 F 3 み た い な こ れ を 人工 キ ー と か サ ロ ゲ ー ト キ ー と 呼 び ま す 。 サ ロ ゲ ー ト キ ー 。 このキーの唯一の存在理由は絶対に変わらず絶対に他と重複しないこと、これだけです。 なるほど。その人が名前を変えようが住所やメールアドレスを変えようが、このIDだけは永久に変わらないんです。これこそがそのデータが保管されている金庫を開けるための世界でただ一つの複製不可能な鍵。 だから主キー、プライマリーキーと呼ぶのに最もふさわしいというわけですね。 なるほど。 変わる可能性があるものを頼りにするんじゃなくて、変わらない絶対的な目印を もう自分たちで発明してしまうわけですね。 そういうことです。 これ は す ご い 感 動 的 に す ら あ り ま す ね 。 ま さ に 鍵 と い う 言 葉 の 持 つ そ の 唯 一 無 二 で 普 遍 っ て い う 感 じ が す ご く 腑 に 落 ち ま し た 。 ええ。そしてこの強力な目印は単に一つのリストの中か ら何かを見つけるためだけに、あるのではありません。 と 言 い ま す と 。 ここからが面白いところで、この目印が全く異なるデータのリスト同士を繋ぐための言わば架け橋。 架け橋ですか。 確かに実際のアプりって顧客情報とか、注文履歴とか、商品カタログとか、全然違う種類のデータがたくさありますもんね。 そうですよね。 今の主キーの話はあくまで一つのリストの中での話。これら全く別々のリストをどうやって関係づけていくんですか。そこで、もう一つのキーの登場です。はい。資料で朝子さんが別の表とつなげた目の意図と表現していた外部キーです。ああ、意図、この比喩すごく分かりやすかったです。ですよまさにその役割を現しているんです。資料にある注文テーブルと商品テーブルの例で考えてみましょうか。ええ、それが一番分かりやすいと思います。えっと、商品テーブルには、商品コード、商品名、価格が記録されている。この場合主キーはもち、論商品コードですよね。その通りです。一方で注文テーブルには注文番号、顧客ID、そして商品コードが記録されていると。あれ、ちょっと待ってください。注文テーブルに商品名や価格は書かないんですか?はい、書かないんです。商品コード101とだけ書かれても、それだけじゃ何の商品かわからないですし、なんか不便じゃないですか。一覧でパッと見えた方が分かりやすい気がするんですけど。そこがデータベース設計の最も巧妙な点なんです。一見二度手間に見あるその構造にこそデータの正確性と効率性を保つための専人たちが詰まっているんです。もしあなたの言う通り注文があるたびに注文テーブルにザディープダイブオリジナルマグカップ1500円と商品の情報をいちいち書き込んでいたらどうなると思いますか。まず入力が面倒くさいとか、ですね。あとタイプミスでマブカップとか書いてしまいそうです。それも大きな問題です。同じ情報が何千何万と重複して保存されることになりますから。容量の無駄にもなるんですね。そう、それにマグカップ、マブカップ、マグカップみたいに表記が揺れると後でマグカップは全部でいくつ売れたかを正確に集計できなくなります。確かに。でもさらに深刻なのは価格が変更になった場合です。例えばマグカップが1800円に値上がりしたとしましょう。過去の何万件という注文履歴の中から全てのマグカップの価格を1500円から1800円に一つ一つ手作業で直さないといけない。それは地獄ですね。絶対に修正もりが起きます。そうなんです。データの一貫性が完全に崩壊します。しかし外部キーを使っていれば修正は商品テーブルにある商品コード第101の行の価格を1箇所だけ1800円に変えるだけで済みます。たった1箇所で。注文テーブルは商品コード第101という意図で商品テーブルを参照しているだけなので自動的に新しい価格が反映されます。なるほど。これが資料の核心部分。別の表にある主キーをこっちの表では外部キーとして使うということ。データの重複をなくし修正の手間を最小限に抑え情報の正確性を保つ。非常にエレガントで強力な仕組みだと思いませんか。これはすごい感動的すらありますね。まさにリレーショナルデータベースという言葉の関係そのものですねこれ。そうなんです。実は以前私がまだ若手だった頃に関わったプロジェクトでまさにこの構造化を怠って痛い目にあったことがあるんですよ。へえ、どんなことがあったんですか?最初は小さなシステムだったのでまあいいかとあちこちのテーブルに直接クライアントの会社名が記録されていたんですね。はいはい。である日そのクライアントが社名変更をすることになってしまって、うわあ。もう大変でした。システム内の数十のテーブルから古い社名を一つ残らず探し出して新しい社名に書き換える作業にチームで1週間近くかかりましたね。一週間もですか。あの時の悪夢のような作業以来この情報は一箇所に他からはキーで参照するという原則の重要性をもう骨身に染みて理解しました。生生しいお話ですね。でもそのおかげでこの設計思想のありがたみがよりリアルに感じられました。ではこの考え方をもっと身近なサービスに当てはめてみるとどうなりますか。例えば音楽配信サービスのSpotifyとか。良い例ですね。Spotifyの裏側を想像してみましょう。まず世界中の曲を管理する巨大な曲テーブルがあります。そこにはユニークな曲IDが主キーとしてあって曲名や再生時間などの情報が入っている。ふむふむ。いやもっと正確に言うとアーティスト名も直接は入っていませんね。そうなんですか。アーティストテーブルという別のテーブルがあってそこにはアーティストIDという主キーと正式なアーティスト名が記録されているはずです。ということは曲とアーティストを繋ぐためのテーブルがまた別にある。そう。特に複数のアーティストが参加する曲もありますからね。曲アーティスト連携テーブルみたいなものがあってそこにどの曲IDにどのアーティストIDが関わっているかが記録されているわけです。そしてあなたが作るお気に入りプレイリスト。これもプレイリストテーブルにプレイリストIDとあなたのIDが記録されてさらにプレイリスト曲連携テーブルにあなたのプレイリストIDと、お気に入りの曲IDがずらっとリストされているだけなんです。はあ、そういう仕組みなのか。だからあるアーティストが名前を変えた時、Spotify側はアーティストテーブルの一箇所を修正するだけでいいんですね。その通りです。それ で 何 億 と い う プ レ イ リ ス ト や 曲 情 報 に 即 座 に 新 し い 名 前 が 反 映 さ れ る わ け で す ね 。 も し 全 デ ー タ に ア ー テ ィ ス ト 名 を 直 接 書 き 込 ん で い た ら 絶 対 に 不 可 能 で す も ん ね 。 え え 。 主 キ ー と 外 部 キ ー が 作 る 巨 大 で 効 率 的 な デ ー タ の ネ ッ ト ワ ー ク の お か げ で 私 た ち は 快 適 な サ ー ビ ス を 供 受 で き て い る ん で す 。 いやあ、よく分かりました。 で は こ こ ま で の 話 を ま と め ま しょ う か 。 お 願 い し ま す 。 資料の海さんがたどり着いた結論がまさに本質を捉えていますよね。 鍵という言葉から始まりましたけど、最終的には目印とコネクターというイメージ。 ええ 。 そ の 表 現 が い ち ば ん し っ く り き ま す ね 。 つまり主キーはあるデータの中からこれだと特定するための絶対に重複が許されない永久不変の目印。そして外部キーはその目印を使って別の表の情報を引っ張ってくるための表と表を繋ぐコネクターの役割を果たしている。とその通りです。この2つを巧みに組み合わせることでどんなに複雑なデータでも矛盾なく効率的に管理できる。これが今回の資料が教えてくれる核心ですね。その理解で完璧です。そして重要なのはこの目印とコネクターという考え方は何もプログラマーやシステムエンジニアだけのものではないということなんです。と言いますと、例えばあなたがExcelでイベントの参加者名簿とアンケート結果の2つのシートを作るとしますよね。はい。その時参加者にユニークな参加者IDを割り振っておけばそれが主キーになります。そうすれば名簿とアンケート結果を簡単に紐付けてどの人がどの回答もしたかを正確に分析できる。ああ、なるほど。 VLOOKUP関数とかで使えますね。そうそう。これはまさにリレーショナルデータベースの考え方の応用なんです。小規模なデータ整理から国家規模のシステム開発まで普遍的に通じる強力な思考ツールなんです。データベースのキーという一つの概念からデータがどうやって重複や矛盾なく効率的に管理されているかの全体像がすごくクリアに見えてきました。普段使っているサービスの裏側でこの目印とコネクターがものすごい速さで働いてくれているおかげなんですね。データの構造を理解するというのがこれからの情報化社会におけるまあ必須のリテラシーと言えるかもしれませんね。確かに。さて、今回の話はここまでですが最後にあなたに一つ思考を巡らせるための問いを投げかけたいと思います。ほう、何でしょう。今回はデータが主キーと外部キーによってどのように繋がっているかを見ましたよね。見ました。では逆に考えてみてください。もしシステムの中に意図的に繋げられていないデータがあったとしたらそこにはどんな意味が隠されているでしょう。プライバシー保護のためかもしれませんし、あるいは単に組織の縦割りの弊害でデータが連携できていないだけかもしれない。なるほど。そしてもう一つ今は全く別々のテーブルとして存在している2つのデータ群。例えばある会社の顧客の購買履歴とその会社のウェブサイトの閲覧履歴。これらを新しい外部キー、例えば顧客IDのようなものを使って繋げることでこれまで見えなかったどんな新しい関係性やビジネス上のインサイトが発見できるでしょうか。それは面白そうですね。データの繋がりを設計することの重要性は見てきました。その次のステップとしてデータの繋がっていないことの意味を考え、そして新たな繋がりを想像する。それこそがデータから新たな価値を生み出すための次の1本になるのかもしれませんね。