Data Modeling

データモデリングスキル

目的

システムの設計と開発に向けて、データ構造、関係性、ビジネスルールを記録する、明確なデータモデルを作成します。

使用する場面

• 新しいデータベース構造を設計するとき
• 分析に向けて既存のデータを文書化するとき
• FRS でデータ要件を定義するとき
• システム間の統合を設計するとき
• データ移行を計画するとき

データモデリングの概念

エンティティ・リレーションシップ図（ERD）

エンティティ：データを保存する対象（例：Customer、Order、Product） 属性：エンティティのプロパティ（例：customer_name、order_date） リレーションシップ：エンティティ同士の関係

リレーションシップの種類

一対一（1:1） 例：User ↔ UserProfile

• 1 人のユーザーは、ちょうど 1 つのプロフィールを持ちます
• 1 つのプロフィールは、ちょうど 1 人のユーザーに属します

一対多（1:N） 例：Customer → Orders

• 1 人の顧客は、複数の注文を持つことができます
• 1 つの注文は、1 人の顧客に属します

多対多（M:N） 例：Products ↔ Categories

• 1 つの商品は、複数のカテゴリに属することができます
• 1 つのカテゴリには、複数の商品を含めることができます
• 中間テーブルが必要です

カーディナリティ表記（クロウズフット）

||──────|| : One and only one (1:1)
||──────<  : One-to-Many (1:N)
>──────<   : Many-to-Many (M:N)
o|──────<  : Zero or one to Many
||──────o< : One to Zero or Many

ERD の例

E コマース ERD（Mermaid）

erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        uuid customer_id PK
        string email UK
        string first_name
        string last_name
        string phone
        datetime created_at
    }
    ORDER ||--|{ ORDER_ITEM : contains
    ORDER {
        uuid order_id PK
        uuid customer_id FK
        string order_number UK
        decimal subtotal
        decimal tax
        decimal shipping
        decimal total
        string status
        datetime order_date
    }
    ORDER_ITEM {
        uuid item_id PK
        uuid order_id FK
        uuid product_id FK
        int quantity
        decimal unit_price
        decimal total_price
    }
    PRODUCT ||--o{ ORDER_ITEM : "included in"
    PRODUCT {
        uuid product_id PK
        string sku UK
        string name
        text description
        decimal price
        int stock_quantity
        string status
    }
    PRODUCT }|--|| CATEGORY : "belongs to"
    CATEGORY {
        uuid category_id PK
        string name
        uuid parent_id FK
    }

CRM ERD

erDiagram
    ACCOUNT ||--o{ CONTACT : has
    ACCOUNT ||--o{ OPPORTUNITY : has
    ACCOUNT {
        uuid account_id PK
        string name
        string industry
        string website
        int employee_count
        decimal annual_revenue
        uuid owner_id FK
    }
    CONTACT {
        uuid contact_id PK
        uuid account_id FK
        string first_name
        string last_name
        string email UK
        string phone
        string title
    }
    OPPORTUNITY }o--|| CONTACT : "primary contact"
    OPPORTUNITY {
        uuid opportunity_id PK
        uuid account_id FK
        uuid contact_id FK
        string name
        string stage
        decimal amount
        date close_date
        int probability
        uuid owner_id FK
    }
    LEAD {
        uuid lead_id PK
        string first_name
        string last_name
        string email
        string company
        string source
        int score
        string status
    }

データディクショナリ

テンプレート

属性	データ型	サイズ	必須	デフォルト	説明	検証
customer_id	UUID	-	はい	自動生成	一意の識別子	UUID 形式
email	VARCHAR	255	はい	-	顧客のメールアドレス	有効なメールアドレス
status	ENUM	-	はい	'active'	アカウントのステータス	active、inactive、suspended

例：Order エンティティ

属性	型	サイズ	必須	デフォルト	説明	ルール
order_id	UUID	-	はい	自動	主キー	一意
order_number	VARCHAR	20	はい	生成	表示用番号	形式：ORD-YYYYMMDD-XXXX
customer_id	UUID	-	はい	-	Customer への外部キー	存在する必要があります
order_date	DATETIME	-	はい	NOW()	注文日時	未来の日付は不可
status	ENUM	-	はい	'pending'	注文ステータス	pending、processing、shipped、delivered、cancelled
subtotal	DECIMAL	10,2	はい	0.00	商品の合計金額	>= 0
tax	DECIMAL	10,2	はい	0.00	計算された税額	>= 0
shipping_cost	DECIMAL	10,2	はい	0.00	送料	>= 0
total	DECIMAL	10,2	はい	-	合計金額	= subtotal + tax + shipping
shipping_address	JSON	-	はい	-	配送先住所	有効な住所
billing_address	JSON	-	はい	-	請求先住所	有効な住所
notes	TEXT	-	いいえ	NULL	注文に関するメモ	最大 2000 文字
created_at	DATETIME	-	はい	NOW()	レコードの作成日時	変更不可
updated_at	DATETIME	-	はい	NOW()	最終更新日時	自動更新

正規化

第一正規形（1NF）

• 繰り返し項目を排除します
• 各セルには単一の値を格納します
• 各レコードは一意です

❌ 悪い例：customer_phones = "123-456, 789-012" ✅ 良い例：customer_id の外部キーを持つ電話番号テーブルを分けます

第二正規形（2NF）

• 1NF を満たします
• 部分関数従属がありません（すべての非キー属性が主キー全体に依存します）

第三正規形（3NF）

• 2NF を満たします
• 推移的関数従属がありません（非キー属性が他の非キー属性に依存しません）

❌ 悪い例：Order に customer_email がある（order ではなく customer_id に依存します） ✅ 良い例：Customer テーブルとの結合を通じて customer_email を取得します

ドメイン固有のデータパターン

E コマース

• バリエーションを持つ商品（バリエーションごとの SKU）
• 階層型カテゴリ
• ショッピングカートから注文への移行
• 住所の正規化
• 価格履歴の追跡

ERP

• 勘定科目一覧の構造
• 複数企業間のデータ分離
• マスターデータ（顧客、ベンダー、商品）
• 仕訳を含むトランザクションテーブル
• 監査証跡

CRM

• Lead → Contact → Account への変換
• 活動ログ（通話、メール、会議）
• Opportunity → Quote → Order のパイプライン
• Campaign → Member → Response の追跡

CDP

• 顧客 ID の解決
• イベント／行動データ（時系列）
• プロファイル属性（統合済み）
• セグメントへの所属
• 同意の追跡

ベストプラクティス

✅ 実施すること：

• 一貫した命名規則（snake_case）を使用します
• 監査用フィールド（created_at、updated_at、created_by）を含めます
• 主キーを明示的に定義します
• 外部キーの関係を文書化します
• データ型と制約を含めます
• 論理削除と物理削除のどちらを使用するか検討します
• データの増加を見越して計画します

❌ 避けること：

• 計算値を保存します（パフォーマンス上の理由がある場合を除く）
• 曖昧な名前を使用します
• ドキュメントを省略します
• データ検証ルールを無視します
• NULL の扱いを忘れます

ツール

• Figma：ERD のビジュアル設計
• Mermaid：ドキュメント内のコードベースの図
• dbdiagram.io：ERD の迅速な作成
• Lucidchart：プロフェッショナルな図の作成

次のステップ

データモデリングの後：

1. 技術チームとレビューします
2. FRS ドキュメントに含めます
3. マイグレーションスクリプトを作成します
4. データ検証ルールを計画します
5. データモデルに基づいて API コントラクトを設計します

参考資料

• データベースの正規化（1NF、2NF、3NF）
• エンティティ関係モデリング
• データディクショナリの標準