論理データモデル設計

目的: 業務要件を正規化されたエンティティと属性に落とし込み、データの一貫性と整合性を保証する論理的なデータ構造を定義する。物理設計やパフォーマンスチューニングの前に、業務ルールに忠実なデータモデルを確立する
スコープ: エンティティの識別、属性定義、主キー・外部キーの設定、正規化（第1～第3正規形）、エンティティ間のリレーションシップ（1:1、1:N、N:M）、参照整合性ルール、業務制約の定義を含む。物理的なテーブル設計、インデックス設計、パーティショニングは対象外
推奨する実施タイミング: 要件定義完了後、基本設計の早い段階で実施する。画面設計やAPI設計と並行して進めることで、データ要件の整合性を早期に確保できる
関連するステークホルダー: データアーキテクト、システムアーキテクト、業務担当者、開発リーダー、DBA

📥 重要な前提知識・インプット

前提知識: データモデリング技法（ER図、UML）、正規化理論（第1～第3正規形、BCNF）、リレーショナルデータベースの基礎、主キー・外部キー・参照整合性の概念、業務ドメインの理解
インプット: 要件定義書、業務フロー図、ユースケース記述、概念データモデル（存在する場合）、画面設計書（画面項目からデータ項目を抽出）、既存システムのデータ構造（移行対象の場合）、非機能要件（データ保持期間、参照整合性ルール、データ量見積もりなど）

📄 成果物の定義

ドキュメントテンプレート: 📄[テンプレ]論理データモデル仕様書
必須要素: エンティティ一覧、論理ER図、エンティティ定義書（主キー、一意性、レコード粒度）、属性定義書（属性名、論理名、データ型、桁数、必須、業務ルール）、リレーションシップ定義、参照整合性ルール、業務制約・整合性ルール

✅ 品質基準・レビュー観点

✅ 品質チェックリスト:

チェック項目	チェック内容
正規化の妥当性	第3正規形まで正規化され、更新異常が発生しない設計になっているか
主キーの適切性	各エンティティに適切な主キーが設定され、一意性が保証されているか
リレーションシップの完全性	エンティティ間の関係が正しく定義され、外部キーが適切に設定されているか
属性の完全性	全ての属性に論理名、データ型、桁数、必須、業務ルールが定義されているか
業務ルールの反映	業務制約や整合性ルールがデータモデルに反映されているか
ネーミング規約	エンティティ名、属性名が命名規則に従い、一貫性があるか

👁️‍🗨️ レビュー観点:

要件網羅性: 要件定義書の全てのデータ要件がエンティティと属性に落とし込まれているか
正規化レベル: 適切なレベルで正規化され、冗長性が排除されているか（過度な正規化は避ける）
参照整合性: 外部キー制約や業務制約が適切に定義され、データの一貫性が保証されているか
拡張性: 将来の機能追加や仕様変更に対応できる柔軟な構造になっているか
物理設計への移行可能性: 論理モデルから物理テーブル設計へスムーズに移行できる構造か

🧪成果物のサンプル

# 論理データモデル

## テーブル一覧

| No | エンティティ名 | 論理名 | ドメイン | 概要 |
|----|--------------|--------|---------|------|
| 1 | Member | 会員 | 会員管理 | システム利用者の会員情報 |
| 2 | MemberStatus | 会員ステータス | 会員管理 | 会員ランク（BRONZE/SILVER/GOLD/PLATINUM） |
| 3 | Order | 注文 | 注文管理 | 会員が行った注文の基本情報 |
| 4 | OrderItem | 注文明細 | 注文管理 | 注文に含まれる商品と数量 |
| 5 | Product | 商品 | 商品管理 | 販売商品のマスタ情報 |
| 6 | Category | カテゴリ | 商品管理 | 商品分類カテゴリ |
| 7 | Inventory | 在庫 | 商品管理 | 商品の在庫数と状態 |
| 8 | Payment | 決済 | 注文管理 | 注文に対する決済情報 |

---

## テーブル定義

### Member（会員）

| 項目 | 内容 |
|------|------|
| **エンティティ名** | Member |
| **論理名** | 会員 |
| **主キー** | member_id |
| **一意性の意味** | システム内で会員を一意に識別する。会員登録時に自動採番される。 |
| **レコード粒度** | 最新のみ。過去のステータス変更は別テーブル（MemberStatusHistory）で管理。 |

### Order（注文）

| 項目 | 内容 |
|------|------|
| **エンティティ名** | Order |
| **論理名** | 注文 |
| **主キー** | order_id |
| **一意性の意味** | 会員が行った各注文を一意に識別する。注文作成時に自動採番される。 |
| **レコード粒度** | 最新のみ。注文ステータスの変更履歴は別途管理可能。 |

---

### 属性定義（論理設計レベル）

#### Member（会員）属性定義

| 属性名 | 論理名 | データ型（論理） | 桁数・制限 | 必須 | 業務ルール |
|--------|--------|----------------|-----------|------|----------|
| member_id | 会員ID | 文字列 | 20文字 | ○ | システム採番、変更不可 |
| email | メールアドレス | 文字列 | 255文字 | ○ | 一意制約、RFC5322準拠 |
| name | 氏名 | 文字列 | 100文字 | ○ | - |
| member_status | 会員ステータス | 列挙型 | BRONZE/SILVER/GOLD/PLATINUM | ○ | 累計購入金額で自動更新 |
| registered_at | 登録日時 | 日時 | - | ○ | 登録時の現在日時を設定 |
| status_updated_at | ステータス更新日時 | 日時 | - | - | ステータス変更時に更新 |

#### Order（注文）属性定義

| 属性名 | 論理名 | データ型（論理） | 桁数・制限 | 必須 | 業務ルール |
|--------|--------|----------------|-----------|------|----------|
| order_id | 注文ID | 文字列 | 20文字 | ○ | システム採番、変更不可 |
| member_id | 会員ID | 文字列 | 20文字 | ○ | 外部キー（Member） |
| order_date | 注文日時 | 日時 | - | ○ | 注文確定時の現在日時 |
| total_amount | 合計金額 | 数値 | 整数部8桁、小数部2桁 | ○ | 0以上、OrderItemの合計と一致 |
| order_status | 注文ステータス | 列挙型 | PENDING/CONFIRMED/SHIPPED/DELIVERED/CANCELLED | ○ | ステータス遷移ルールあり |

---

### 論理ER図

```mermaid
erDiagram
    Member ||--o{ Order : "1:N"
    Member ||--o{ MemberStatusHistory : "1:N"
    Order ||--|{ OrderItem : "1:N"
    Order ||--|| Payment : "1:1"
    OrderItem }o--|| Product : "N:1"
    Product }o--|| Category : "N:1"
    Product ||--|| Inventory : "1:1"
    
    Member {
        string member_id PK
        string email UK
        string name
        enum member_status
        datetime registered_at
        datetime status_updated_at
    }
    
    Order {
        string order_id PK
        string member_id FK
        datetime order_date
        decimal total_amount
        enum order_status
    }
    
    OrderItem {
        string order_item_id PK
        string order_id FK
        string product_id FK
        int quantity
        decimal unit_price
    }
    
    Product {
        string product_id PK
        string category_id FK
        string product_name
        decimal price
    }
```

---

### 整合性ルール

- 外部キーは参照先エンティティに必ず存在すること
- 注文の合計金額は注文明細の小計合計と一致すること
- 注文確定時、在庫数量は注文数量以上であること
- 決済金額は注文の合計金額と一致すること

---

🔄 設計の進め方・プロセス

🏗️ プロセス1: エンティティの識別

設計対象:

業務要件から管理すべきデータの「もの」や「こと」を抽出し、エンティティとして識別する。

具体例:

要件定義書や業務フロー図から、管理すべき対象（会員、商品、注文、在庫など）を洗い出す
画面設計書から入力項目・表示項目を分析し、エンティティ候補を抽出する
既存システムがある場合、既存のテーブル構造を参考にする（ただし盲目的に従わない）
マスタデータ（変更頻度が低い）とトランザクションデータ（日々発生する）を区別する

設計原則:

業務視点での識別: 技術的な都合ではなく、業務的に意味のある単位でエンティティを切り出す
名詞の抽出: 要件記述やユースケースから名詞を抽出し、エンティティ候補とする
独立性の確認: そのエンティティが他のエンティティとは独立して存在意義を持つか確認する
適切な粒度: 粗すぎず細かすぎず、業務的に管理しやすい粒度で定義する

文書化の推奨表現:

エンティティ一覧表の作成: エンティティ名、論理名、ドメイン（業務領域）、概要を一覧にまとめる
エンティティの定義: 各エンティティが何を表すのか、業務的な意味を明確に記述する
エンティティ候補の整理: 最初は多めに洗い出し、重複や不要なものを統廃合していく過程を記録する

🏗️ プロセス2: 属性の定義

設計対象:

各エンティティが持つべき属性（項目）を定義し、属性の詳細仕様を決定する。

具体例:

エンティティ「会員」に対して、会員ID、氏名、メールアドレス、登録日時などの属性を定義する
各属性に対して、論理名、データ型（文字列、数値、日時、列挙型など）、桁数、必須、業務ルールを定義する
画面設計書やAPI仕様書から入出力項目を分析し、属性候補を抽出する
業務ルール（例: メールアドレスは一意、累計購入金額で会員ステータス自動更新）を明確にする

設計原則:

原子性の確保: 属性はそれ以上分割できない最小単位とする（例: 住所を都道府県、市区町村、番地に分割）
業務ルールの明確化: 各属性の入力制約、計算ルール、更新タイミングを明記する
命名規則の統一: 属性名は一貫した命名規則に従い、分かりやすい名称とする
NULL許容の慎重な判断: 必須属性とオプション属性を明確に区別し、NULL許容は業務的な意味を持たせる

文書化の推奨表現:

属性定義表の作成: 属性名、論理名、データ型（論理レベル）、桁数・制限、必須、業務ルールを表形式でまとめる
データ型の論理表現: 物理的なDBMS依存の型ではなく、論理的なデータ型（文字列、数値、日時、列挙型など）で記述する
業務ルールの詳細化: 属性に関連する計算式、変換ルール、バリデーションルールを明記する

🏗️ プロセス3: 主キーと一意性の定義

設計対象:

各エンティティを一意に識別する主キーを決定し、一意性の意味とレコード粒度を明確にする。

具体例:

エンティティ「会員」の主キーを「会員ID」とする（システム採番、変更不可）
エンティティ「注文」の主キーを「注文ID」とする（注文作成時に自動採番）
自然キー（業務上の識別子）とサロゲートキー（システム採番の人工キー）のどちらを使うか検討する
複合主キーが必要なケース（例: 注文明細の「注文ID + 明細番号」）を識別する

設計原則:

一意性の保証: 主キーは全てのレコードを一意に識別できる属性または属性の組み合わせとする
不変性の確保: 主キーは原則として変更不可とし、安定した識別子とする
業務的意味の明確化: 主キーの一意性が業務的にどのような意味を持つか文書化する
サロゲートキーの優先: 自然キーが複雑または変更リスクがある場合、サロゲートキー（システム採番ID）を検討する

文書化の推奨表現:

エンティティ定義表の作成: エンティティごとに、主キー、一意性の意味、レコード粒度（最新のみ/履歴管理）を明記する
主キー選定理由の記録: なぜその属性を主キーとしたのか、代替候補との比較結果を残す

🏗️ プロセス4: リレーションシップと外部キーの定義

設計対象:

エンティティ間の関係性（リレーションシップ）を特定し、外部キーを設定する。

具体例:

「会員」と「注文」の関係は1:N（1人の会員が複数の注文を行う）
「注文」と「注文明細」の関係は1:N（1つの注文が複数の明細を持つ）
「注文明細」と「商品」の関係はN:1（複数の明細が同じ商品を参照する）
「注文」と「決済」の関係は1:1（1つの注文に1つの決済が対応）

設計原則:

カーディナリティの明確化: 1:1、1:N、N:Mのいずれかを明確に定義する
N:M関係の解消: 多対多関係は中間エンティティ（交差テーブル）を設けて1:Nと N:1に分解する
参照整合性の確保: 外部キーは参照先エンティティの主キーを参照し、存在しない値を許容しない
業務的な関係性の反映: 単なる技術的な結びつきではなく、業務上の関係性を正確に表現する

文書化の推奨表現:

論理ER図の作成: エンティティ間のリレーションシップとカーディナリティを視覚的に表現する（Mermaid、PlantUML、draw.ioなど）
リレーションシップ定義表の作成: 関係元エンティティ、関係先エンティティ、カーディナリティ、外部キー属性を一覧化する
参照整合性ルールの明記: 親レコード削除時の挙動（CASCADE、RESTRICT、SET NULLなど）を定義する

🏗️ プロセス5: 正規化

設計対象:

冗長性を排除し、更新異常を防ぐために、データモデルを第3正規形まで正規化する。

具体例:

第1正規形: 繰り返し項目を排除し、全ての属性が原子的な値を持つようにする
第2正規形: 部分関数従属を排除し、非キー属性が主キー全体に従属するようにする
第3正規形: 推移的関数従属を排除し、非キー属性が主キーにのみ従属するようにする
過度な正規化は避け、業務上の使いやすさとのバランスを考慮する

設計原則:

更新異常の防止: 挿入異常、削除異常、更新異常が発生しない構造にする
第3正規形を基本とする: 原則として第3正規形まで正規化し、データの一貫性を確保する
意図的な非正規化は慎重に: パフォーマンス上の理由で非正規化する場合は、その理由と影響を文書化する
業務的な自然さの維持: 正規化により業務的に不自然な構造にならないよう注意する

文書化の推奨表現:

正規化プロセスの記録: どのような冗長性を発見し、どのように解消したかを記録する
正規化前後の比較: 正規化前のモデルと正規化後のモデルを比較し、改善点を明確にする
非正規化の判断理由: 意図的に非正規化する場合は、その理由（パフォーマンス要件など）を明記する

🏗️ プロセス6: 業務制約・整合性ルールの定義

設計対象:

データの整合性を保つための業務ルールや制約条件を定義する。

具体例:

注文の合計金額は注文明細の小計合計と一致すること
注文確定時、在庫数量は注文数量以上であること
決済金額は注文の合計金額と一致すること
会員のメールアドレスは一意であること（ユニーク制約）
注文日時は商品の販売開始日以降であること

設計原則:

業務ルールの明文化: 暗黙的なルールを明示的に文書化し、実装時の漏れを防ぐ
データベース制約での実現: 可能な限り、CHECK制約、UNIQUE制約、外部キー制約などDB機能で実現する
アプリケーション層での補完: DB制約で表現できない複雑なルールはアプリケーション層で実装する
整合性チェックの網羅: データ登録・更新・削除時にどのようなチェックが必要か洗い出す

文書化の推奨表現:

整合性ルール一覧の作成: 業務制約、参照整合性ルール、ユニーク制約などを一覧化する
ルールの実現方法: DB制約で実現するか、アプリケーション層で実現するかを明記する
エラー時の挙動: 整合性違反が発生した場合のエラーメッセージや処理方針を定義する

🚨 よくある失敗と予防策　

🚧 実例収集後、追記予定

📚 参考資料・関連リンク

参考文献: 『データベース設計論』、『SQL実践入門』、『達人に学ぶDB設計徹底指南書』
関連する他のガイド: 📄システムアーキテクチャ設計、物理データベース設計ガイド、API設計ガイド
ツール・テンプレート: draw.io、PlantUML、Mermaid（ER図）、ER図テンプレート

テンプレートサイト: 📄テンプレート集