@k2works/claude-code-booster 3.2.1 → 3.3.1

package/lib/assets/docs/article/practical-database-design/part5/chapter36.md

@@ -0,0 +1,1292 @@
+# 第36章：マスタデータ管理（MDM）
+
+本章では、複数の基幹業務システム間で共有されるマスタデータの管理方法について解説します。マスタデータ管理（Master Data Management: MDM）は、企業全体でのデータ品質と一貫性を確保するための重要な取り組みです。
+
+---
+
+## 36.1 マスタデータ統合の課題
+
+### 各システムでのマスタ重複
+
+基幹業務システムが個別に構築された場合、同じマスタデータが複数のシステムに存在することがあります。この「マスタ重複」は様々な問題を引き起こします。
+
+```plantuml
+@startuml
+title マスタデータ重複の現状
+
+package "販売管理システム" as sales {
+    database "顧客マスタ\n----\n顧客コード\n顧客名\n住所\n与信限度額" as sales_customer
+    database "商品マスタ\n----\n商品コード\n商品名\n販売単価\n在庫数" as sales_product
+}
+
+package "生産管理システム" as production {
+    database "取引先マスタ\n----\n取引先コード\n取引先名\n住所\n納入条件" as prod_partner
+    database "品目マスタ\n----\n品目コード\n品目名\n製造リードタイム\nBOM情報" as prod_item
+}
+
+package "財務会計システム" as accounting {
+    database "取引先マスタ\n----\n取引先コード\n取引先名\n債権債務区分\n決済条件" as acc_partner
+}
+
+note bottom of sales
+  【問題点】
+  ・同一顧客が異なるコードで登録
+  ・住所変更が反映されない
+  ・データ不整合
+end note
+
+note bottom of production
+  【問題点】
+  ・商品と品目の紐付けが曖昧
+  ・仕入先情報の重複
+  ・更新タイミングのずれ
+end note
+
+@enduml
+```
+
+#### マスタ重複による具体的な問題
+
+| 問題カテゴリ | 具体例 | ビジネスへの影響 |
+|------------|-------|----------------|
+| データ不整合 | 顧客住所が各システムで異なる | 請求書誤送付、配送ミス |
+| 更新漏れ | 取引先の廃業が反映されない | 無効な発注、債権回収不能 |
+| コード重複 | 同一顧客に複数コード付与 | 売上分析の誤り、与信管理不能 |
+| 属性欠落 | 必要な属性が一部システムにのみ存在 | システム間連携の障害 |
+
+### コード体系の不一致
+
+各システムが独自のコード体系を持つことで、データの突合が困難になります。
+
+```plantuml
+@startuml
+title コード体系の不一致
+
+rectangle "販売管理" as sales {
+    object "顧客コード" as sales_code {
+        形式: "C" + 連番5桁
+        例: C00001, C00002
+    }
+}
+
+rectangle "生産管理" as production {
+    object "取引先コード" as prod_code {
+        形式: 区分2桁 + 連番4桁
+        例: CU0001（顧客）
+        例: SP0001（仕入先）
+    }
+}
+
+rectangle "財務会計" as accounting {
+    object "取引先コード" as acc_code {
+        形式: 連番8桁
+        例: 00000001
+    }
+}
+
+sales_code -[hidden]-> prod_code
+prod_code -[hidden]-> acc_code
+
+note bottom
+  【同一顧客のコード例】
+  ・販売管理：C00001
+  ・生産管理：CU0001
+  ・財務会計：00000001
+
+  → 突合するためにマッピングテーブルが必要
+  → マッピングの維持管理コストが発生
+end note
+
+@enduml
+```
+
+### 更新タイミングの同期
+
+マスタデータの更新がシステム間で同期されないと、一時的または恒久的なデータ不整合が発生します。
+
+```plantuml
+@startuml
+title 更新タイミングの不整合
+
+concise "販売管理" as sales
+concise "生産管理" as production
+concise "財務会計" as accounting
+
+@0
+sales is "住所A"
+production is "住所A"
+accounting is "住所A"
+
+@100
+sales is "住所B" : 住所変更
+production is "住所A"
+accounting is "住所A"
+
+@200
+sales is "住所B"
+production is "住所B" : バッチ同期
+accounting is "住所A"
+
+@300
+sales is "住所B"
+production is "住所B"
+accounting is "住所B" : 手動更新
+
+@400
+sales is "住所B"
+production is "住所B"
+accounting is "住所B"
+
+@enduml
+```
+
+```plantuml
+@startuml
+title マスタ更新の同期問題
+
+|販売管理|
+start
+:顧客住所変更;
+:販売管理DBを更新;
+
+|生産管理|
+:夜間バッチで同期;
+note right
+  タイムラグ：最大24時間
+end note
+
+|財務会計|
+:月次で手動確認;
+note right
+  タイムラグ：最大1ヶ月
+end note
+
+|問題|
+:期間中のデータ不整合;
+note right
+  ・請求書の住所が古い
+  ・配送先と請求先の不一致
+  ・顧客からのクレーム
+end note
+
+stop
+
+@enduml
+```
+
+---
+
+## 36.2 MDM パターン
+
+マスタデータ管理には、組織の状況や要件に応じた複数のアーキテクチャパターンがあります。
+
+### MDM パターンの概要
+
+```plantuml
+@startuml
+title MDM パターンの分類
+
+rectangle "Registry Style\n（参照型）" as registry
+note right of registry
+  ・既存システムを維持
+  ・インデックスのみ集約
+  ・低コスト・低リスク
+end note
+
+rectangle "Consolidation Style\n（統合型）" as consolidation
+note right of consolidation
+  ・マスタを集約
+  ・分析・レポート用途
+  ・既存システムは変更なし
+end note
+
+rectangle "Coexistence Style\n（共存型）" as coexistence
+note right of coexistence
+  ・MDMと既存システムが共存
+  ・双方向同期
+  ・段階的な移行に適する
+end note
+
+rectangle "Transaction Hub Style\n（ハブ型）" as hub
+note right of hub
+  ・MDMが唯一の正
+  ・すべての更新はハブ経由
+  ・最高の一貫性
+end note
+
+registry -[hidden]down-> consolidation
+consolidation -[hidden]down-> coexistence
+coexistence -[hidden]down-> hub
+
+@endumll
+```
+
+### Registry Style（参照型）
+
+既存システムのマスタデータはそのまま維持し、MDMはマスタデータの「インデックス」として機能します。
+
+```plantuml
+@startuml
+title Registry Style MDM
+
+package "MDM（Registry）" as mdm {
+    database "マスタインデックス\n----\nグローバルID\nローカルID（販売）\nローカルID（生産）\nローカルID（会計）" as index
+}
+
+package "販売管理" as sales {
+    database "顧客マスタ" as sales_cust
+}
+
+package "生産管理" as production {
+    database "取引先マスタ" as prod_partner
+}
+
+package "財務会計" as accounting {
+    database "取引先マスタ" as acc_partner
+}
+
+rectangle "クロスリファレンス\nサービス" as xref
+
+index <--> xref
+xref <--> sales_cust : 参照
+xref <--> prod_partner : 参照
+xref <--> acc_partner : 参照
+
+note bottom of mdm
+  【特徴】
+  ・各システムのマスタは変更なし
+  ・グローバルIDによる紐付けのみ
+  ・名寄せ・重複検出に活用
+
+  【適用場面】
+  ・既存システムへの影響を最小化したい
+  ・分析・レポートでの統合ビューが欲しい
+end note
+
+@enduml
+```
+
+<details>
+<summary>Java 実装例</summary>
+
+```java
+// マスタインデックス
+@Entity
+@Table(name = "master_index")
+public class MasterIndex {
+    @Id
+    private String globalId;
+
+    @OneToMany(mappedBy = "masterIndex", cascade = CascadeType.ALL)
+    private List<LocalIdMapping> localMappings;
+
+    private String masterType; // CUSTOMER, SUPPLIER, PRODUCT
+    private String canonicalName;
+    private LocalDateTime lastUpdated;
+}
+
+// ローカルIDマッピング
+@Entity
+@Table(name = "local_id_mapping")
+public class LocalIdMapping {
+    @Id
+    @GeneratedValue
+    private Long id;
+
+    @ManyToOne
+    private MasterIndex masterIndex;
+
+    private String systemCode; // SALES, PRODUCTION, ACCOUNTING
+    private String localId;
+    private String status; // ACTIVE, INACTIVE, PENDING
+}
+
+// クロスリファレンスサービス
+@Service
+public class CrossReferenceService {
+    private final MasterIndexRepository indexRepository;
+
+    // グローバルIDからローカルIDを取得
+    public String getLocalId(String globalId, String systemCode) {
+        return indexRepository.findById(globalId)
+            .flatMap(index -> index.getLocalMappings().stream()
+                .filter(m -> m.getSystemCode().equals(systemCode))
+                .findFirst())
+            .map(LocalIdMapping::getLocalId)
+            .orElseThrow(() -> new MappingNotFoundException(globalId, systemCode));
+    }
+
+    // ローカルIDからグローバルIDを取得
+    public String getGlobalId(String localId, String systemCode) {
+        return indexRepository.findByLocalIdAndSystem(localId, systemCode)
+            .map(MasterIndex::getGlobalId)
+            .orElseThrow(() -> new MappingNotFoundException(localId, systemCode));
+    }
+
+    // 名寄せ処理
+    public List<MasterIndex> findPotentialDuplicates(String name) {
+        return indexRepository.findByCanonicalNameLike(normalize(name));
+    }
+}
+```
+
+</details>
+
+### Consolidation Style（統合型）
+
+各システムのマスタデータを MDM に集約し、分析やレポート用途の「ゴールデンレコード」を作成します。
+
+```plantuml
+@startuml
+title Consolidation Style MDM
+
+package "ソースシステム" as source {
+    database "販売顧客" as sales_cust
+    database "生産取引先" as prod_partner
+    database "会計取引先" as acc_partner
+}
+
+package "MDM（Consolidation）" as mdm {
+    rectangle "ETL/統合処理" as etl
+    database "ゴールデンレコード\n----\n統合取引先マスタ\n品質スコア\nソース情報" as golden
+}
+
+package "分析システム" as analytics {
+    rectangle "BI/レポート" as bi
+    rectangle "データウェアハウス" as dwh
+}
+
+sales_cust --> etl : 抽出
+prod_partner --> etl : 抽出
+acc_partner --> etl : 抽出
+
+etl --> golden : 統合・クレンジング
+
+golden --> bi : 参照
+golden --> dwh : 連携
+
+note bottom of mdm
+  【特徴】
+  ・各システムからデータを収集
+  ・クレンジング・統合処理
+  ・ゴールデンレコード（信頼できる単一ソース）作成
+
+  【適用場面】
+  ・分析・レポートの統合ビューが必要
+  ・運用系への書き戻し不要
+end note
+
+@enduml
+```
+
+#### ゴールデンレコードの構造
+
+```plantuml
+@startuml
+title ゴールデンレコードの構造
+
+class "GoldenRecord" as golden {
+    +globalId: String
+    +entityType: String
+    +canonicalName: String
+    +qualityScore: Double
+    +survivorshipRule: String
+    +lastConsolidated: Timestamp
+}
+
+class "AttributeValue" as attr {
+    +attributeName: String
+    +value: String
+    +sourceSystem: String
+    +confidence: Double
+    +lastUpdated: Timestamp
+}
+
+class "SourceReference" as source {
+    +systemCode: String
+    +localId: String
+    +lastSynced: Timestamp
+    +syncStatus: String
+}
+
+class "MatchHistory" as history {
+    +matchedGlobalId: String
+    +matchScore: Double
+    +matchRule: String
+    +matchDate: Timestamp
+}
+
+golden "1" -- "*" attr : 属性
+golden "1" -- "*" source : ソース参照
+golden "1" -- "*" history : マッチ履歴
+
+note right of golden
+  【Survivorship Rule】
+  複数ソースから同一属性がある場合の
+  採用ルール
+  ・最新優先
+  ・信頼度優先
+  ・特定システム優先
+end note
+
+@enduml
+```
+
+### Coexistence Style（共存型）
+
+MDM と各システムのマスタが共存し、双方向で同期を行います。
+
+```plantuml
+@startuml
+title Coexistence Style MDM
+
+package "MDM Hub" as mdm {
+    database "マスタハブ" as hub
+    rectangle "同期エンジン" as sync
+}
+
+package "販売管理" as sales {
+    database "顧客マスタ" as sales_cust
+}
+
+package "生産管理" as production {
+    database "取引先マスタ" as prod_partner
+}
+
+package "財務会計" as accounting {
+    database "取引先マスタ" as acc_partner
+}
+
+hub <--> sync
+sync <--> sales_cust : 双方向同期
+sync <--> prod_partner : 双方向同期
+sync <--> acc_partner : 双方向同期
+
+note bottom of mdm
+  【特徴】
+  ・MDMと各システムが共存
+  ・双方向でデータ同期
+  ・どちらでも更新可能
+
+  【適用場面】
+  ・段階的なMDM導入
+  ・各システムの独自要件を維持
+end note
+
+@enduml
+```
+
+#### 同期ルールの設計
+
+```plantuml
+@startuml
+title Coexistence同期ルール
+
+|MDM Hub|
+start
+:変更イベント受信;
+
+if (変更元は?) then (MDMHub)
+    :各システムへ配信;
+    :同期ステータス更新;
+else (ローカルシステム)
+    :変更内容を検証;
+
+    if (競合あり?) then (yes)
+        :競合解決ルール適用;
+        note right
+          ・タイムスタンプ優先
+          ・システム優先度
+          ・手動解決キュー
+        end note
+    else (no)
+    endif
+
+    :MDM Hubを更新;
+    :他システムへ配信;
+endif
+
+:同期完了;
+
+stop
+
+@enduml
+```
+
+<details>
+<summary>Java 実装例</summary>
+
+```java
+// 同期設定
+@Entity
+@Table(name = "sync_configuration")
+public class SyncConfiguration {
+    @Id
+    private String configId;
+
+    private String entityType;
+    private String sourceSystem;
+    private String targetSystem;
+    private SyncDirection direction; // INBOUND, OUTBOUND, BIDIRECTIONAL
+    private ConflictResolution conflictResolution;
+
+    public enum ConflictResolution {
+        LATEST_WINS,      // 最新タイムスタンプ優先
+        SOURCE_WINS,      // ソースシステム優先
+        TARGET_WINS,      // ターゲットシステム優先
+        MANUAL_REVIEW     // 手動確認
+    }
+}
+
+// 同期サービス
+@Service
+public class CoexistenceSyncService {
+    private final SyncConfigurationRepository configRepository;
+    private final MasterHubRepository hubRepository;
+    private final ConflictResolver conflictResolver;
+
+    @EventListener
+    public void handleMasterChange(MasterChangeEvent event) {
+        SyncConfiguration config = configRepository
+            .findByEntityTypeAndSystem(event.entityType(), event.sourceSystem());
+
+        if (event.sourceSystem().equals("MDM_HUB")) {
+            // MDM Hubからの変更：各システムへ配信
+            distributeToSystems(event, config);
+        } else {
+            // ローカルシステムからの変更
+            MasterRecord hubRecord = hubRepository.findByGlobalId(event.globalId());
+
+            if (hasConflict(hubRecord, event)) {
+                MasterRecord resolved = conflictResolver.resolve(
+                    hubRecord,
+                    event,
+                    config.getConflictResolution()
+                );
+                hubRepository.save(resolved);
+            } else {
+                hubRepository.updateFromSource(event);
+            }
+
+            // 他システムへ配信
+            distributeToOtherSystems(event, config);
+        }
+    }
+
+    private boolean hasConflict(MasterRecord hubRecord, MasterChangeEvent event) {
+        return hubRecord.getLastUpdated().isAfter(event.previousUpdateTime());
+    }
+}
+```
+
+</details>
+
+### Transaction Hub Style（トランザクションハブ型）
+
+MDM が唯一の正（Single Source of Truth）となり、すべてのマスタ更新は MDM 経由で行われます。
+
+```plantuml
+@startuml
+title Transaction Hub Style MDM
+
+package "MDM Hub（唯一の正）" as mdm {
+    database "マスタデータ" as master
+    rectangle "API Gateway" as api
+    rectangle "バリデーション" as validation
+    rectangle "ワークフロー" as workflow
+}
+
+package "販売管理" as sales {
+    rectangle "顧客参照" as sales_ref
+}
+
+package "生産管理" as production {
+    rectangle "取引先参照" as prod_ref
+}
+
+package "財務会計" as accounting {
+    rectangle "取引先参照" as acc_ref
+}
+
+actor "マスタ管理者" as admin
+
+admin --> api : マスタ更新
+api --> validation : 検証
+validation --> workflow : 承認フロー
+workflow --> master : 更新
+
+master --> sales_ref : 参照のみ
+master --> prod_ref : 参照のみ
+master --> acc_ref : 参照のみ
+
+note bottom of mdm
+  【特徴】
+  ・MDMが唯一の更新ポイント
+  ・各システムは参照のみ
+  ・最高レベルのデータ一貫性
+
+  【適用場面】
+  ・厳格なデータガバナンスが必要
+  ・規制対応（金融、医療等）
+end note
+
+@enduml
+```
+
+#### マスタ更新ワークフロー
+
+```plantuml
+@startuml
+title Transaction Hub マスタ更新フロー
+
+|申請者|
+start
+:マスタ変更申請;
+:変更内容入力;
+
+|MDM Hub|
+:申請受付;
+:自動バリデーション;
+
+if (バリデーションOK?) then (yes)
+else (no)
+    :エラー通知;
+    |申請者|
+    :内容修正;
+    |MDM Hub|
+endif
+
+:承認ワークフロー開始;
+
+|承認者|
+:変更内容確認;
+
+if (承認?) then (yes)
+    :承認;
+else (no)
+    :却下;
+    |申請者|
+    :却下通知受信;
+    stop
+endif
+
+|MDM Hub|
+:マスタデータ更新;
+:変更イベント発行;
+:監査ログ記録;
+
+|各システム|
+:変更イベント受信;
+:ローカルキャッシュ更新;
+
+|申請者|
+:完了通知受信;
+
+stop
+
+@enduml
+```
+
+### MDM パターンの比較と選択
+
+| パターン | データ一貫性 | 導入コスト | 運用負荷 | 適用場面 |
+|---------|------------|----------|---------|---------|
+| Registry | 低 | 低 | 低 | 分析用途、名寄せ |
+| Consolidation | 中 | 中 | 中 | BI、レポート |
+| Coexistence | 中〜高 | 中〜高 | 高 | 段階的移行 |
+| Transaction Hub | 高 | 高 | 中 | 規制対応、厳格なガバナンス |
+
+```plantuml
+@startuml
+title MDMパターン選択フローチャート
+
+start
+
+:MDM導入検討;
+
+if (既存システムへの\n影響を最小化?) then (yes)
+    if (分析用途のみ?) then (yes)
+        :Consolidation Style;
+        stop
+    else (no)
+        :Registry Style;
+        stop
+    endif
+else (no)
+    if (厳格なデータガバナンス\nが必要?) then (yes)
+        :Transaction Hub Style;
+        stop
+    else (no)
+        if (段階的な移行?) then (yes)
+            :Coexistence Style;
+            stop
+        else (no)
+            :Transaction Hub Style;
+            stop
+        endif
+    endif
+endif
+
+@enduml
+```
+
+---
+
+## 36.3 共通マスタの設計
+
+基幹業務システムで共有される主要なマスタデータの統合設計について解説します。
+
+### 取引先マスタの統合
+
+取引先（顧客、仕入先、外注先）は、複数のシステムで参照される代表的なマスタです。
+
+```plantuml
+@startuml
+title 統合取引先マスタの設計
+
+entity "統合取引先マスタ" as partner {
+    *取引先ID <<PK>>
+    --
+    *取引先名
+    取引先名カナ
+    取引先区分
+    法人個人区分
+    代表者名
+    設立年月日
+    資本金
+    従業員数
+    業種コード
+    --
+    作成日時
+    更新日時
+    有効フラグ
+}
+
+entity "取引先住所" as address {
+    *住所ID <<PK>>
+    --
+    *取引先ID <<FK>>
+    住所区分
+    郵便番号
+    都道府県
+    市区町村
+    町域
+    番地
+    建物名
+    --
+    主住所フラグ
+}
+
+entity "取引先連絡先" as contact {
+    *連絡先ID <<PK>>
+    --
+    *取引先ID <<FK>>
+    連絡先区分
+    担当者名
+    部署名
+    電話番号
+    FAX番号
+    メールアドレス
+    --
+    主連絡先フラグ
+}
+
+entity "取引先口座" as account {
+    *口座ID <<PK>>
+    --
+    *取引先ID <<FK>>
+    銀行コード
+    支店コード
+    口座種別
+    口座番号
+    口座名義
+    --
+    主口座フラグ
+}
+
+entity "取引先システム属性" as system_attr {
+    *属性ID <<PK>>
+    --
+    *取引先ID <<FK>>
+    *システムコード
+    属性名
+    属性値
+    --
+    有効開始日
+    有効終了日
+}
+
+partner ||--o{ address
+partner ||--o{ contact
+partner ||--o{ account
+partner ||--o{ system_attr
+
+note right of partner
+  【取引先区分】
+  ・CUSTOMER（顧客）
+  ・SUPPLIER（仕入先）
+  ・SUBCONTRACTOR（外注先）
+  ・BOTH（顧客兼仕入先）
+end note
+
+note right of system_attr
+  【システム固有属性の例】
+  ・販売：与信限度額、締日、回収方法
+  ・生産：納入リードタイム、発注ロット
+  ・会計：勘定科目、補助科目
+end note
+
+@enduml
+```
+
+<details>
+<summary>SQL 定義</summary>
+
+```sql
+-- 統合取引先マスタ
+CREATE TABLE 統合取引先マスタ (
+    取引先ID VARCHAR(20) PRIMARY KEY,
+    取引先名 VARCHAR(200) NOT NULL,
+    取引先名カナ VARCHAR(200),
+    取引先区分 VARCHAR(20) NOT NULL,
+    法人個人区分 VARCHAR(10),
+    代表者名 VARCHAR(100),
+    設立年月日 DATE,
+    資本金 DECIMAL(15,0),
+    従業員数 INTEGER,
+    業種コード VARCHAR(10),
+    作成日時 TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    更新日時 TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    有効フラグ BOOLEAN DEFAULT TRUE
+);
+
+-- 取引先住所
+CREATE TABLE 取引先住所 (
+    住所ID VARCHAR(20) PRIMARY KEY,
+    取引先ID VARCHAR(20) NOT NULL,
+    住所区分 VARCHAR(20) NOT NULL,
+    郵便番号 VARCHAR(10),
+    都道府県 VARCHAR(10),
+    市区町村 VARCHAR(50),
+    町域 VARCHAR(100),
+    番地 VARCHAR(100),
+    建物名 VARCHAR(100),
+    主住所フラグ BOOLEAN DEFAULT FALSE,
+    FOREIGN KEY (取引先ID) REFERENCES 統合取引先マスタ(取引先ID)
+);
+
+-- 取引先システム属性
+CREATE TABLE 取引先システム属性 (
+    属性ID VARCHAR(20) PRIMARY KEY,
+    取引先ID VARCHAR(20) NOT NULL,
+    システムコード VARCHAR(20) NOT NULL,
+    属性名 VARCHAR(50) NOT NULL,
+    属性値 VARCHAR(500),
+    有効開始日 DATE,
+    有効終了日 DATE,
+    FOREIGN KEY (取引先ID) REFERENCES 統合取引先マスタ(取引先ID),
+    UNIQUE (取引先ID, システムコード, 属性名, 有効開始日)
+);
+```
+
+</details>
+
+### 商品/品目マスタの統合
+
+販売管理の「商品」と生産管理の「品目」を統合的に管理します。
+
+```plantuml
+@startuml
+title 統合商品/品目マスタの設計
+
+entity "統合商品マスタ" as product {
+    *商品ID <<PK>>
+    --
+    *商品名
+    商品名カナ
+    商品区分
+    販売単位
+    在庫管理単位
+    製造単位
+    基準換算率
+    --
+    JANコード
+    製造元コード
+    ブランドコード
+    --
+    有効開始日
+    有効終了日
+}
+
+entity "商品分類" as category {
+    *分類ID <<PK>>
+    --
+    *商品ID <<FK>>
+    *分類体系コード
+    分類コード
+    分類階層
+}
+
+entity "商品販売属性" as sales_attr {
+    *属性ID <<PK>>
+    --
+    *商品ID <<FK>>
+    標準販売単価
+    最低販売単価
+    販売開始日
+    販売終了日
+    --
+    課税区分
+    消費税率
+}
+
+entity "商品製造属性" as mfg_attr {
+    *属性ID <<PK>>
+    --
+    *商品ID <<FK>>
+    製造リードタイム
+    安全在庫数
+    最小ロット数
+    発注点
+    --
+    歩留率
+    検査要否
+}
+
+entity "商品原価属性" as cost_attr {
+    *属性ID <<PK>>
+    --
+    *商品ID <<FK>>
+    標準原価
+    原価計算方式
+    有効開始日
+    有効終了日
+}
+
+product ||--o{ category
+product ||--o| sales_attr
+product ||--o| mfg_attr
+product ||--o{ cost_attr
+
+note right of product
+  【商品区分】
+  ・FINISHED（製品）
+  ・SEMI_FINISHED（半製品）
+  ・WIP（仕掛品）
+  ・RAW_MATERIAL（原材料）
+  ・PURCHASED（購入品）
+  ・SERVICE（サービス）
+end note
+
+@enduml
+```
+
+#### 商品コード体系の統一
+
+```plantuml
+@startuml
+title 統一商品コード体系
+
+object "コード構成" as code_structure {
+    形式: PPPP-CCCC-SSSS-VV
+    --
+    PPPP: 商品区分（4桁）
+    CCCC: 分類コード（4桁）
+    SSSS: 連番（4桁）
+    VV: バージョン（2桁）
+}
+
+object "商品区分コード" as product_type {
+    PROD: 製品
+    SEMI: 半製品
+    RAWM: 原材料
+    PART: 部品
+    SUPP: 消耗品
+    SERV: サービス
+}
+
+object "コード例" as examples {
+    PROD-ELEC-0001-01: 電子機器製品001
+    SEMI-MECH-0023-01: 機械半製品023
+    RAWM-METAL-0102-01: 金属原材料102
+}
+
+@enduml
+```
+
+### 部門・組織マスタの統合
+
+組織構造は、権限管理や実績集計に使用される重要なマスタです。
+
+```plantuml
+@startuml
+title 統合組織マスタの設計
+
+entity "組織マスタ" as org {
+    *組織ID <<PK>>
+    --
+    *組織名
+    組織名略称
+    組織区分
+    組織レベル
+    親組織ID <<FK>>
+    組織パス
+    --
+    有効開始日
+    有効終了日
+}
+
+entity "組織階層" as hierarchy {
+    *階層ID <<PK>>
+    --
+    *組織ID <<FK>>
+    *階層種別
+    上位組織ID
+    下位組織ID
+    階層順序
+}
+
+entity "組織属性" as org_attr {
+    *属性ID <<PK>>
+    --
+    *組織ID <<FK>>
+    *システムコード
+    属性名
+    属性値
+    有効開始日
+    有効終了日
+}
+
+entity "組織担当者" as staff {
+    *担当者ID <<PK>>
+    --
+    *組織ID <<FK>>
+    社員ID
+    役職コード
+    主担当フラグ
+    有効開始日
+    有効終了日
+}
+
+org ||--o{ hierarchy
+org ||--o{ org_attr
+org ||--o{ staff
+org ||--o| org : 親組織
+
+note right of org
+  【組織区分】
+  ・COMPANY（会社）
+  ・DIVISION（事業部）
+  ・DEPARTMENT（部）
+  ・SECTION（課）
+  ・TEAM（チーム）
+end note
+
+note right of hierarchy
+  【階層種別】
+  ・REPORTING（レポート階層）
+  ・COST_CENTER（原価センター階層）
+  ・SALES_TERRITORY（営業テリトリー階層）
+end note
+
+@enduml
+```
+
+#### 組織パスによる階層表現
+
+```plantuml
+@startuml
+title 組織パスによる階層表現
+
+object "株式会社ABC" as company {
+    組織ID = "ORG-001"
+    組織パス = "/ORG-001"
+    組織レベル = 1
+}
+
+object "営業本部" as sales_div {
+    組織ID = "ORG-010"
+    組織パス = "/ORG-001/ORG-010"
+    組織レベル = 2
+}
+
+object "東日本営業部" as east_dept {
+    組織ID = "ORG-011"
+    組織パス = "/ORG-001/ORG-010/ORG-011"
+    組織レベル = 3
+}
+
+object "東京営業課" as tokyo_sec {
+    組織ID = "ORG-111"
+    組織パス = "/ORG-001/ORG-010/ORG-011/ORG-111"
+    組織レベル = 4
+}
+
+company --> sales_div
+sales_div --> east_dept
+east_dept --> tokyo_sec
+
+note bottom
+  【組織パスの利点】
+  ・階層検索が高速（LIKE '/ORG-001/%'）
+  ・任意の深さに対応
+  ・親子関係の判定が容易
+end note
+
+@enduml
+```
+
+<details>
+<summary>SQL クエリ例</summary>
+
+```sql
+-- 特定組織の配下をすべて取得
+SELECT * FROM 組織マスタ
+WHERE 組織パス LIKE '/ORG-001/ORG-010/%'
+ORDER BY 組織パス;
+
+-- 特定組織の直接の子組織を取得
+SELECT * FROM 組織マスタ
+WHERE 親組織ID = 'ORG-010'
+AND 有効終了日 IS NULL;
+
+-- 組織の全階層を展開（再帰CTE）
+WITH RECURSIVE 組織階層 AS (
+    -- 基点
+    SELECT 組織ID, 組織名, 親組織ID, 1 as レベル
+    FROM 組織マスタ
+    WHERE 組織ID = 'ORG-001'
+
+    UNION ALL
+
+    -- 再帰部分
+    SELECT o.組織ID, o.組織名, o.親組織ID, h.レベル + 1
+    FROM 組織マスタ o
+    INNER JOIN 組織階層 h ON o.親組織ID = h.組織ID
+    WHERE o.有効終了日 IS NULL
+)
+SELECT * FROM 組織階層
+ORDER BY レベル, 組織ID;
+```
+
+</details>
+
+---
+
+## 36.4 MDM 導入のベストプラクティス
+
+### データガバナンスの確立
+
+```plantuml
+@startuml
+title データガバナンス体制
+
+rectangle "データガバナンス委員会" as committee {
+    rectangle "データスチュワード" as steward
+    rectangle "データオーナー" as owner
+    rectangle "データ品質管理者" as quality
+}
+
+rectangle "ポリシー・ルール" as policy {
+    rectangle "データ標準" as standard
+    rectangle "品質基準" as quality_std
+    rectangle "セキュリティポリシー" as security
+}
+
+rectangle "プロセス" as process {
+    rectangle "登録プロセス" as register
+    rectangle "変更プロセス" as change
+    rectangle "監査プロセス" as audit
+}
+
+rectangle "ツール" as tools {
+    rectangle "MDMプラットフォーム" as platform
+    rectangle "データ品質ツール" as dq_tool
+    rectangle "ワークフローツール" as workflow
+}
+
+committee --> policy : 策定
+committee --> process : 管理
+process --> tools : 実装
+
+@enduml
+```
+
+### 段階的な導入アプローチ
+
+```plantuml
+@startuml
+title MDM段階的導入ロードマップ
+
+|Phase 1|
+:アセスメント;
+note right
+  ・現状分析
+  ・課題特定
+  ・ROI試算
+end note
+
+|Phase 2|
+:パイロット;
+note right
+  ・対象マスタ選定
+  ・小規模で検証
+  ・課題抽出
+end note
+
+|Phase 3|
+:展開;
+note right
+  ・対象マスタ拡大
+  ・システム連携
+  ・運用プロセス確立
+end note
+
+|Phase 4|
+:最適化;
+note right
+  ・データ品質向上
+  ・プロセス改善
+  ・新規マスタ追加
+end note
+
+@enduml
+```
+
+---
+
+## 36.5 まとめ
+
+本章では、マスタデータ管理（MDM）の概念と実践的なパターンについて解説しました。
+
+### 学んだこと
+
+1. **マスタデータ統合の課題**
+
+   - 各システムでのマスタ重複
+   - コード体系の不一致
+   - 更新タイミングの同期問題
+
+2. **MDM パターン**
+
+   - Registry Style：インデックスとしての軽量 MDM
+   - Consolidation Style：分析用ゴールデンレコード
+   - Coexistence Style：双方向同期による共存
+   - Transaction Hub Style：唯一の正としての厳格な MDM
+
+3. **共通マスタの設計**
+
+   - 取引先マスタ：顧客・仕入先・外注先の統合
+   - 商品/品目マスタ：販売と製造の属性統合
+   - 部門・組織マスタ：階層構造の表現
+
+### MDM 成功のポイント
+
+- ビジネス要件に合ったパターンの選択
+- 段階的な導入アプローチ
+- データガバナンス体制の確立
+- 継続的なデータ品質管理
+
+### 次章の予告
+
+第37章では、イベント駆動アーキテクチャについて解説します。ドメインイベント、イベントソーシング、CQRS など、モダンなシステム統合の基盤となる概念を学びます。