Mímisbrunnr知恵の泉

← データエンジニアリング 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：リレーショナルモデルと正規化　|　関連：スタースキーマと次元モデリング

要点（BLUF）

概念 ── エンティティと関係

エンティティは「顧客」「注文」「商品」のような独立して存在するモノ／コト。属性はその性質（顧客の名前・住所）。関係は「顧客が注文する」「注文が商品を含む」といったエンティティ同士の繋がりです。

要するにER図は、業務の言葉（顧客・注文・商品）を、そのままテーブルとキーに翻訳する前の中間表現です。ここで構造を固めてから物理設計に落とします。

仕組み ── カーディナリティと多対多の分解

erDiagram
    CUSTOMER ||--o{ ORDER : "発注する"
    ORDER ||--|{ ORDER_ITEM : "含む"
    PRODUCT ||--o{ ORDER_ITEM : "に現れる"
    CUSTOMER {
      int  cust_id PK
      text name
    }
    ORDER {
      int order_id PK
      int cust_id FK
      text ordered_at
    }
    PRODUCT {
      int product_id PK
      text name
      int  price
    }
    ORDER_ITEM {
      int order_id FK
      int product_id FK
      int quantity
    }

ポイントは 注文と商品が「多対多」であること（1注文に複数商品、1商品は複数注文に現れる）。リレーショナルDBは多対多を直接持てないので、ORDER_ITEM（連関テーブル）を挟んで「1対多 × 多対1」に分解します。ORDER_ITEM は両側の外部キーを持ち、数量などの関係そのものの属性を載せます。

flowchart LR
    A["多対多（注文 ↔ 商品）"] --> B["連関テーブル ORDER_ITEM で分解"]
    B --> C["注文 1対多 ORDER_ITEM 多対1 商品"]

設計の勘所 ── 3段階で詰める

段階決めること例
概念モデルエンティティと関係（多重度）顧客・注文・商品とその繋がり
論理モデルテーブル・主キー・外部キーcustomers, orders, order_item
物理モデル列の型・インデックス・制約cust_id INTEGER PK, INDEX(cust_id)

概念→論理→物理の順で、抽象から具体へ降りていきます。物理（インデックス等）は インデックスと実行計画 で扱います。

なぜそうするか ── 多重度を最初に固める

なぜER図を先に描くのか。関係の多重度を間違えると、テーブル構造ごと作り直しになるからです。「1顧客に住所は1つ」と思って住所を顧客テーブルに入れた後、「複数住所が必要」と判明すれば、列の分離・データ移行が発生します。図で多重度を関係者と合意してから物理に落とすと、この手戻りを防げます。連関テーブルへの分解も、図の段階で見抜けば自然に設計に入ります。

⚠️ よくある落とし穴

対応ラボ

なし（設計回）。連関テーブルを使ったJOINの実演は SQLの基礎（結合・集約・サブクエリ） のラボで扱う。

関連

← 第2章 データモデリング 目次