リレーショナルデータモデル

昔々、恐竜がでっかかった頃…いや、正確には1970年、エドガー・コッドって人が「データのカオスやべぇ、もうクリエイティブな散らかりじゃなくて、時間とリソースを吸い込むブラックホールじゃん」と思ったんだ。エドガーはめっちゃ考えて、全部整理する方法を思いついた。ついでに、データがきれいに本棚に並んだ本みたいにテーブルに収まる世界の基礎も作っちゃった。行、列、秩序！「まあいいや」とか「なんとなく分かるでしょ」みたいなのはナシ。

リレーショナルモデルは、データをテーブル（表）で表現する考え方がベース。各テーブルは行と列でできてる。直感的に分かるよね：行はレコード（データの一件）、列はその属性やプロパティ。こういうやり方だと、データの操作や管理がめっちゃ楽になる。

例えば、ネットショップで注文する場面を想像してみて。注文がちゃんと処理されて届くには、システムはいろんな情報を管理しなきゃいけない：誰が注文したか（お客さん）、どの配送サービスを選んだか、どこに届けるか、荷物のステータスはどうか、などなど。

もし全部の情報が一つの巨大なテーブルに入ってたら、カオスになるよ：データが重複しまくるし、更新も大変、必要な情報をサクッと探すのも超むずい。リレーショナルなやり方なら、情報をテーブルごとに分けて、必要な時にやりとりできるからスッキリ！

この図は、配送追跡プロセスのデータ構成例だよ：

• お客さん - ここには各クライアントの情報が入ってる。ユニークなお客さん番号付き。
• 配送サービス - このテーブルは配送できるサービスのリスト。ユニークなサービス番号付き。
• 注文配送 - これが中心のテーブル。各行は一つの配送。配送番号があって、お客さんや配送サービス、注文、日付、ステータスなどにリンクしてる。

矢印は、注文配送テーブルのレコードがお客さんや配送サービステーブルのレコードとどう繋がってるかを示してるよ。

注文配送テーブルのサンプル：

こういうやり方のメリット：

• お客さんや配送サービスの情報は一回だけ保存すればOK。配送ごとに何度も書かなくていいから、重複がなくなる。
• ユニーク番号（キーとも呼ばれる）で繋ぐことで、例えば存在しないお客さんやサービスの配送が作られるのを防げる。
• いろんなテーブルのデータを組み合わせて、複雑なレポートやピンポイントな抽出も簡単！
• データの変更は一箇所だけでOK。例えば配送サービスの電話番号を変えたら、全部の配送に即反映される。

リレーショナルデータベースの構造

リレーショナルデータベースのコアはテーブルだよ。各テーブルには：

• 名前（Table Name）がある。例えばcustomersみたいに、どのテーブルか分かるように。
• カラム（Columns/Attributes）のセットがあって、オブジェクトの属性を定義する。
  • ユニーク番号（主キー）用のカラム名は、よく名前_idみたいなパターンを使う。サフィックスの_idは「identifier」って意味。例：お客さん番号はcustomer_idになる。
  • 例えばcustomersテーブルなら、customer_id、first_name、emailなどがある。
• 行（Rows/Records）のデータ - customersテーブルの1行は、特定のお客さん（101, Alex Song など）の全情報が入ってる。

例としてcustomersテーブルを見てみよう：

テーブルのキー

各行をユニークに特定するために、主キー（Primary Key, PK）を使う。これは1つ（または複数）のカラムで、各行で値がユニーク＆空じゃない。パスポートの番号みたいなもので、例えばcustomersテーブルのcustomer_idは各お客さんを一意に識別できる。

主キーはパスポート、いや、パスポート番号みたいなもの。各オブジェクトでユニークだから、同じ名前の行があっても混乱しない。

テーブル同士の関係を作るには、外部キー（Foreign Key, FK）を使う。これは他のテーブルの主キーを参照するカラム。外部キーはテーブル間の「橋」みたいなもの。カラム名は参照先の主キー名と同じことが多い。例えばdeliveriesテーブルのcustomer_idは、customersテーブルのcustomer_idを参照して、配送とお客さんを繋げてる。

さっきの図が、よりリアルな形で再登場！

• customersテーブルはお客さん情報を持ってて、主キーはcustomer_id。
• delivery_servicesテーブルは配送サービス情報で、主キーはservice_id。
• ordersテーブル（図の完全性のために表示。order_idで配送テーブルから参照される）は注文情報用で、主キーはorder_id。
• deliveriesテーブルは配送操作の中心。
  • 自分の主キー：delivery_id。
  • 3つの外部キーで関係を作る：
    • customer_id（FK）：customersテーブルの特定のお客さんと配送を繋ぐ。
    • service_id（FK）：delivery_servicesテーブルのサービスと配送を繋ぐ。
    • order_id（FK）：ordersテーブルの注文と配送を繋ぐ。
  • created_dateフィールドは配送レコードの作成日時を示す。

こうやって主キーと外部キーを使うことで、データの整合性が保たれる。例えば、指定したcustomer_idやorder_idが存在しないと配送レコードは作れないし、関連情報の抽出も柔軟にできる。

リレーショナルモデルのメリット

リレーショナルモデルには他の方式にない強みがいろいろある：

1. シンプルな構造。カラムと行のテーブルは分かりやすくて直感的。
2. データ操作の柔軟性。新しいデータの追加や変更も、整合性を壊さず簡単にできる。
3. 複雑なクエリもOK。SQLを使えば、複数テーブルからデータを引っ張ってきたり、組み合わせたり、フィルタしたり、やりたいことはほぼ何でもできる。例えば「特定のコースを受講してる学生を探す」とかも余裕！
4. キーによるデータ整合性。主キーと外部キーを使えば、データの一貫性が保証される。例えば、存在しないコースに学生を登録することはできない。

リレーショナルデータモデルは、現代のデータベースの基礎だよ。シンプルでパワフル、構造化データの保存にピッタリ。エドガー・コッドも「整理しないと死ぬぞ！」（まあ、実際はもうちょい違う言い方だったけど、意味はそんな感じ）って言ってた。次のレクチャーでは、リレーショナルモデルと他のデータベース（例えばNoSQL）との違いや、どこで使い分けるといいかを見ていくよ。