data-modeling

データモデリング

このスキルを使用する場面

次の場合にこのスキルを使用します。

• データモデリングのタスク - エンティティ・リレーションシップ図（ERD）、データディクショナリ、概念／論理／物理モデルを用いたデータモデリングに取り組む場合。データ構造、関係、属性を文書化します
• 計画または設計 - データモデリングの手法についてガイダンスが必要な場合
• ベストプラクティス - 確立されたパターンや標準に従いたい場合

概要

エンティティ・リレーションシップ図（ERD）、データディクショナリ、構造化データモデルを使用して、データ構造を作成し、文書化します。データベース設計とデータアーキテクチャにおける概念、論理、物理の各モデリングレベルに対応します。

データモデリングとは

データモデリングでは、データ要素とその関係を視覚的かつ構造的に表現します。以下を文書化します。

• エンティティ：データを保存する対象
• 属性：エンティティの特性
• 関係：エンティティ同士のつながり
• 制約：データを規定するルール

モデリングレベル

レベル	目的	対象者	詳細
概念	ビジネス概念	ビジネスユーザー	エンティティ、概要レベルの関係
論理	データ構造	アナリスト、設計者	エンティティ、属性、すべての関係
物理	実装	開発者、DBA	テーブル、列、型、インデックス

概念モデル

ビジネス概念の概要：

• 主要なエンティティのみ
• 主要な関係
• 属性なし（または最小限）
• 技術的な詳細なし

論理モデル

テクノロジーに依存しないデータ構造：

• すべてのエンティティと属性
• 主キーと外部キー
• カーディナリティを含むすべての関係
• 正規化を適用
• 物理的な実装の詳細なし

物理モデル

データベース固有の実装：

• テーブル名（物理的な命名）
• 列名とデータ型
• インデックスと制約
• ビューとストアドプロシージャ
• データベース固有の機能

ERD表記法

エンティティ（長方形）

エンティティは、データを保存する対象を表します。

┌─────────────────┐
│    CUSTOMER     │
├─────────────────┤
│ customer_id PK  │
│ name            │
│ email           │
│ created_at      │
└─────────────────┘

エンティティの種類：

種類	説明	例
強エンティティ	独立して存在する	顧客、製品
弱エンティティ	別のエンティティに依存する	注文明細（注文に依存）
連関エンティティ	多対多の関係を解消する	登録（学生・コース）

属性

種類	記号	説明
主キー（PK）	下線／PK	一意な識別子
外部キー（FK）	FK	別のエンティティへの参照
必須	* または NOT NULL	値が必要
任意	○ または NULL	空でもよい
導出	/	他の属性から計算
複合	{attrs}	サブ属性で構成
多値	[attr]	複数の値を持つことができる

関係（線）

表記法の種類：

種類	使用分野
Chen	学術、概念
Crow's Foot	業界標準
UML	ソフトウェア設計
IDEF1X	政府、構造化モデリング

Crow's Foot表記法：

記号	意味
──	1つ（必須）
──○	0または1（任意）
──<	複数
──○<	0または複数

カーディナリティ

表記	意味	例
1:1	1対1	従業員 → ワークステーション
1:M	1対多	顧客 → 注文
M:N	多対多	学生 ↔ コース

カーディナリティの読み方：

「1つの[エンティティA]は[min]..[max]個の[エンティティB]を持つ」

例：「1人の顧客は0..複数の注文を持つ」

ワークフロー

フェーズ1：エンティティを特定する

ステップ1：要件から名詞を抽出する

ビジネス要件から、次を特定します。

• ビジネスが追跡する対象
• ビジネスルールの対象
• データのソースとターゲット

ステップ 2：候補を絞り込む

残す	除外する
独立した概念	属性（エンティティのプロパティ）
複数のインスタンスを持つもの	同義語（同じ概念の異なる名前）
データの保存が必要なもの	アクション（名詞ではなく動詞）

ステップ 3：エンティティを文書化する

## Entities

| Entity | Description | Example |
|--------|-------------|---------|
| Customer | Person or organization that purchases | John Smith, Acme Corp |
| Order | Purchase transaction | Order #12345 |
| Product | Item available for sale | Widget, Gadget |

フェーズ 2：属性を定義する

ステップ 1：各エンティティの属性を列挙する

各エンティティについて、次の点を特定します。

• このエンティティについて、何を知る必要がありますか？
• これを一意に識別するものは何ですか？
• ビジネスではどのようなデータを参照しますか？

ステップ 2：属性を分類する

属性	型	必須	備考
customer_id	PK	はい	代理キー
email	Unique	はい	ビジネスキー
name	String	はい
phone	String	いいえ	任意

ステップ 3：キーを特定する

• 主キー（PK）：一意な識別子
• 自然キー：ビジネス上の意味を持つ識別子
• 代理キー：システムが生成する識別子
• 複合キー：複数の属性を組み合わせたもの

フェーズ 3：リレーションシップを定義する

ステップ 1：関連を特定する

エンティティの各ペアについて、次の点を確認します。

• ビジネス上の関連はありますか？
• リレーションシップの性質はどのようなものですか？
• 多重度はどのようになっていますか？

ステップ 2：リレーションシップを文書化する

## Relationships

| Relationship | From | To | Cardinality | Description |
|--------------|------|-----|-------------|-------------|
| places | Customer | Order | 1:M | Customer places orders |
| contains | Order | Product | M:N | Order contains products |

ステップ 3：多対多を解決する

M:N リレーションシップには、関連エンティティが必要です。

Student ──M:N── Course

Becomes:

Student ──1:M── Enrollment ──M:1── Course

フェーズ 4：正規化する（論理モデル）

正規形：

形式	ルール	違反の例
1NF	値が原子的であり、繰り返しグループがない	Phone1、Phone2、Phone3
2NF	部分関数従属がない	非キー属性が複合キーの一部に依存している
3NF	推移的関数従属がない	非キー属性が別の非キー属性に依存している
BCNF	すべての決定項が候補キーである	候補キーが重複している

非正規化する場合：

• 読み取り性能が重要な場合
• レポート作成や分析のユースケース
• データウェアハウスの設計
• 明確なトレードオフ分析に基づいて正当化できる場合

フェーズ 5：物理モデルを作成する

ステップ 1：物理型にマッピングする

論理型	物理型（PostgreSQL）	物理型（SQL Server）
String(50)	VARCHAR(50)	NVARCHAR(50)
Integer	INTEGER	INT
Decimal(10,2)	NUMERIC(10,2)	DECIMAL(10,2)
Date	DATE	DATE
Timestamp	TIMESTAMP	DATETIME2
Boolean	BOOLEAN	BIT

ステップ 2：制約を定義する

• 主キー制約
• 外部キー制約
• 一意制約
• チェック制約
• デフォルト値

ステップ 3：インデックスを計画する

• 主キー（自動）
• 外部キー（結合用）
• 頻繁にクエリされる列
• パフォーマンス向上のためのカバリングインデックス

出力形式

Mermaid ERD

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : includes

    CUSTOMER {
        int customer_id PK
        string name
        string email UK
        date created_at
    }

    ORDER {
        int order_id PK
        int customer_id FK
        date order_date
        decimal total
        string status
    }

    ORDER_LINE {
        int order_id PK,FK
        int product_id PK,FK
        int quantity
        decimal unit_price
    }

    PRODUCT {
        int product_id PK
        string name
        string sku UK
        decimal price
        int stock_qty
    }

データディクショナリ

## Data Dictionary

### CUSTOMER

| Column | Type | Null | Key | Default | Description |
|--------|------|------|-----|---------|-------------|
| customer_id | INT | No | PK | AUTO | Unique identifier |
| name | VARCHAR(100) | No | | | Customer full name |
| email | VARCHAR(255) | No | UK | | Contact email |
| phone | VARCHAR(20) | Yes | | NULL | Contact phone |
| created_at | TIMESTAMP | No | | NOW() | Record creation |

**Indexes:**
- `pk_customer` (customer_id) - Primary
- `uk_customer_email` (email) - Unique
- `ix_customer_name` (name) - Search

**Constraints:**
- Email format validation (CHECK)
- Name length minimum 2 characters

構造化データ（YAML）

data_model:
  name: "E-Commerce"
  version: "1.0"
  date: "2025-01-15"
  level: "logical"  # conceptual, logical, physical
  analyst: "data-modeler"

  entities:
    - name: "Customer"
      type: "strong"
      description: "Person or organization that makes purchases"
      attributes:
        - name: "customer_id"
          type: "integer"
          key: "primary"
          required: true
          generated: true

        - name: "email"
          type: "string"
          length: 255
          key: "unique"
          required: true

        - name: "name"
          type: "string"
          length: 100
          required: true

    - name: "Order"
      type: "strong"
      description: "Purchase transaction"
      attributes:
        - name: "order_id"
          type: "integer"
          key: "primary"
          required: true

        - name: "customer_id"
          type: "integer"
          key: "foreign"
          references: "Customer.customer_id"
          required: true

  relationships:
    - name: "places"
      from: "Customer"
      to: "Order"
      cardinality: "1:M"
      from_participation: "optional"  # 0..1
      to_participation: "mandatory"   # 1..M
      description: "Customer places orders"

  constraints:
    - entity: "Customer"
      type: "check"
      expression: "LENGTH(name) >= 2"
      description: "Name minimum length"

  indexes:
    - entity: "Order"
      name: "ix_order_date"
      columns: ["order_date"]
      purpose: "Date range queries"

概要

## Data Model: E-Commerce

**Version:** 1.0
**Date:** [ISO Date]
**Level:** Logical

### Entity Summary

| Entity | Description | Key Relationships |
|--------|-------------|-------------------|
| Customer | Purchasers | Places Orders |
| Order | Transactions | Belongs to Customer, Contains Products |
| Product | Items for sale | Included in Orders |
| Order Line | Order details | Links Order to Product |

### Key Relationships

1. **Customer → Order (1:M)**
   - One customer can place many orders
   - Each order belongs to exactly one customer

2. **Order ↔ Product (M:N via Order Line)**
   - An order can contain many products
   - A product can appear in many orders

### Data Integrity Rules

1. Orders cannot exist without a customer
2. Order lines must reference valid order and product
3. Stock quantity cannot be negative
4. Email must be unique per customer

### Notes

- Consider partitioning Orders by date for large volumes
- Product price stored in Order Line for historical accuracy

よくあるパターン

継承（サブタイプ／スーパータイプ）

erDiagram
    PERSON ||--o| EMPLOYEE : "is a"
    PERSON ||--o| CUSTOMER : "is a"

    PERSON {
        int person_id PK
        string name
        string email
    }

    EMPLOYEE {
        int person_id PK,FK
        date hire_date
        decimal salary
    }

    CUSTOMER {
        int person_id PK,FK
        string company
        decimal credit_limit
    }

自己参照

erDiagram
    EMPLOYEE ||--o{ EMPLOYEE : "manages"

    EMPLOYEE {
        int employee_id PK
        string name
        int manager_id FK
    }

監査証跡

erDiagram
    ENTITY ||--o{ ENTITY_HISTORY : "has history"

    ENTITY {
        int id PK
        string data
        timestamp updated_at
    }

    ENTITY_HISTORY {
        int history_id PK
        int entity_id FK
        string data
        timestamp valid_from
        timestamp valid_to
        string changed_by
    }

統合

上流

• Requirements - データ要件の情報源
• domain-storytelling - ドメインの概念
• process-modeling - プロセス内のデータ

下流

• Database design - 物理的な実装
• API design - データ契約
• Integration - データ交換

関連スキル

• process-modeling - データのプロセスコンテキスト
• journey-mapping - 顧客データのタッチポイント
• decision-analysis - データに基づく意思決定
• capability-mapping - ケイパビリティを支えるデータ

バージョン履歴

• v1.0.0（2025-12-26）：初回リリース