データモデリングと設計 (Data Modelling & Design)
DAMA-DMBOK 2nd Edition — Chapter 5: Data Modeling and Design
出題割合: 11%（約11問）— 最重要トピック
1. データモデリングとは
定義: データ要件を発見・分析・スコープ設定し、それを明示的な形式（データモデル）として表現するプロセス。
データモデルは組織のデータ資産を正確に表すための「設計図」。
2. データモデルの種類と抽象化レベル
3層モデル（最重要）
| レベル | 名称 | 別名 | 対象者 | 内容 |
|---|---|---|---|---|
| 最上位 | 概念モデル（Conceptual） | CDM | ビジネスステークホルダー | ビジネスエンティティと関係のみ |
| 中間 | 論理モデル（Logical） | LDM | データアーキテクト・アナリスト | 属性・データ型・正規化含む |
| 最下位 | 物理モデル（Physical） | PDM | DBA・開発者 | テーブル・カラム・インデックス等 |
概念モデル → 論理モデル → 物理モデル
（What） （How-abstract） （How-concrete）
概念モデル（Conceptual Data Model）
- エンティティ名と関係のみ
- 技術的な詳細なし
- ビジネスの語彙・概念を反映
- 例: 「顧客」「注文」「製品」の関係
論理モデル（Logical Data Model）
- すべての属性を含む
- データ型と長さを定義
- 正規化（1NF/2NF/3NF/BCNF）を適用
- 特定DBMSに依存しない
物理モデル（Physical Data Model）
- 特定DBMSに最適化
- テーブル・カラム・インデックス・制約
- 非正規化（パフォーマンス最適化）を含む
- パーティション・ストレージ設定
3. データモデリング記法
Entity Relationship Diagram (ERD)
カーディナリティ（多重度）
| 記号 | 意味 |
|---|---|
| ` | |
| ` | O` |
| `} | ` |
}O |
0以上（オプション多数） |
IE記法（Information Engineering）とバーカー記法
- IE記法（Crow's Foot）: 鳥の足マークで多を表現。最も一般的
- バーカー記法（Barker）: Oracle方式
- Chen記法: ERD の原型（ダイヤモンドが関係を表す）
UML（Unified Modeling Language）
- クラス図でデータ構造を表現
- オブジェクト指向設計と整合
4. 正規形（Normalization）
| 正規形 | 条件 |
|---|---|
| 1NF | 繰り返しグループなし・原子値のみ |
| 2NF | 1NF + 部分関数従属の除去（複合キーの場合） |
| 3NF | 2NF + 推移的関数従属の除去 |
| BCNF | 3NF + すべての決定子が候補キー |
| 4NF | BCNF + 多値従属の除去 |
| 5NF | 4NF + 結合従属の除去 |
試験では 1NF〜3NF/BCNF が特に重要
5. データモデリングのスキーマ設計パターン
リレーショナルDWH設計（OLAP向け）
| スキーマ | 特徴 |
|---|---|
| スタースキーマ | ファクトテーブル + 非正規化ディメンション。シンプルで高速 |
| スノーフレークスキーマ | ファクトテーブル + 正規化ディメンション。整合性高いが複雑 |
| Galaxy/Constellation | 複数ファクト + 共有ディメンション |
ディメンショナルモデリング（Kimball方式）
- ファクトテーブル: 数値指標（売上、数量）+ ディメンションキー
- ディメンションテーブル: 分析軸（日時、顧客、製品）の詳細
Slowly Changing Dimension (SCD)
| タイプ | 対処法 |
|---|---|
| SCD Type 1 | 上書き（履歴なし） |
| SCD Type 2 | 新行追加（履歴保持 → 有効日付で管理） |
| SCD Type 3 | 旧値カラム追加（限定的な履歴） |
6. データモデリングの技法
前方設計（Forward Engineering）
要件定義 → 概念モデル → 論理モデル → 物理モデル → DDL生成
逆設計（Reverse Engineering）
既存DB → 物理モデル読み取り → 論理モデル → 文書化
データモデルのレビュー観点
- 完全性（すべてのエンティティ・属性が定義されているか）
- 正確性（ビジネスルールが正しく反映されているか）
- 一貫性（命名規則・データ型の統一性）
- 整合性（関係・制約が正しいか）
7. モデリングツール
| ツール | 特徴 |
|---|---|
| ERwin | エンタープライズ向けモデリングツール |
| PowerDesigner (SAP) | 広機能・企業向け |
| ER/Studio | Embarcadero製 |
| draw.io / Lucidchart | 軽量・クラウド型 |
| DbSchema | 物理DB可視化 |
8. 試験で頻出の概念
サロゲートキー vs ナチュラルキー
| 種類 | 説明 | 利点 |
|---|---|---|
| ナチュラルキー | ビジネス上の意味を持つキー（例: 社員番号） | 意味が明確 |
| サロゲートキー | システムが生成する意味のないキー（例: ID = 1, 2, 3） | 安定・変更に強い |
データドメイン（Data Domain）
属性が取れる値の集合。制約条件として機能。 例: 性別ドメイン = {M, F, Unknown}
データ型のカテゴリ
- 数値型（Integer, Decimal, Float）
- 文字型（CHAR, VARCHAR, TEXT）
- 日時型（DATE, TIMESTAMP）
- 論理型（BOOLEAN）
- バイナリ型（BLOB, VARBINARY）
試験ポイント
- 概念→論理→物理の3層と各層の特徴
- 正規化 1NF〜3NF の定義
- スタースキーマ vs スノーフレークの違い
- SCD Type 1/2/3 の違い
- サロゲートキー vs ナチュラルキー
- ERDの記法（Crow's Foot）
- Reverse Engineering の定義
Specialist試験 深掘り
データモデルの品質評価（Specialist頻出活動）
モデル品質の5次元:
| 次元 | 説明 | 評価方法 |
|---|---|---|
| 完全性（Completeness） | 全ビジネス概念がモデル化されているか | ビジネス要件との対照 |
| 正確性（Accuracy） | ビジネスルールが正確に表現されているか | ビジネスStewardのレビュー |
| 一貫性（Consistency） | 命名規則・データ型・パターンが統一されているか | 自動チェックツール |
| 簡潔性（Conciseness） | 冗長な要素がないか（過剰設計を避ける） | アーキテクトのレビュー |
| 安定性（Stability） | ビジネス変化に対して変更しやすい設計か | 変更履歴の分析 |
Data Vault モデリング（Specialist試験で出題）
Kimball/Inmonに次ぐ第3のDWHモデリング手法。
構成要素:
Hub: ビジネスキーを格納（例: customer_hub → customer_natural_id）
Link: Hubの関係を格納（例: order_customer_link → order_hub + customer_hub）
Satellite: 属性・履歴を格納（例: customer_name_sat → 全変更履歴）
Data Vaultの利点:
- 監査性が高い（すべての変更が追加のみ、削除なし）
- アジャイルなスキーマ変更（Satelliteを追加するだけ）
- 並列ロードが容易（Hub/Link/Satelliteを独立してロード可能）
使いどき:
- 監査要件が厳しい（銀行・保険）
- ソースが頻繁に変わる
- 長期にわたる完全な履歴が必要
高度な正規形（Specialist試験対象）
4NF（第4正規形）:
- 条件: BCNF + 多値従属（Multi-valued Dependency）の除去
- 例: 「社員」が「スキル」と「言語」の両方を持つ場合、スキル×言語の全組み合わせができてしまう
問題（3NF）: employee_skill_language
| emp_id | skill | language |
| E001 | Python | English |
| E001 | Python | Japanese |
| E001 | Java | English |
| E001 | Java | Japanese | ← Pythonに日本語を追加するとJavaも追加が必要
解決（4NF）: 2テーブルに分割
employee_skill: emp_id + skill
employee_language: emp_id + language
5NF（第5正規形）/ PJNF:
- 条件: 4NF + 結合従属（Join Dependency）の除去
- 実務では3NF/BCNFまでで十分な場合がほとんど
Temporal Data Modeling（時制データモデリング）
SCD Type 2 のさらに高度な概念：
Valid Time（有効時間）: ビジネス上の事実が真であった期間 Transaction Time（取引時間）: DBにレコードが存在した期間
-- Bi-temporal テーブル（両方の時制を管理）
CREATE TABLE customer_bitempoural (
customer_id INT,
name VARCHAR(100),
-- Valid Time
valid_from DATE, -- この情報がビジネス上いつから有効か
valid_to DATE, -- この情報がビジネス上いつまで有効か
-- Transaction Time
recorded_at DATETIME, -- DBにいつ書き込まれたか
superseded_at DATETIME -- この行がいつ上書きされたか（NULLは現在）
);
-- 使用例: 「6月1日時点でのDBを、7月1日時点で参照する」
用途: 「過去に間違ったデータが入力されて後日修正された場合でも、修正前の状態に遡れる」必要がある規制業務（銀行・保険・法律）
データモデリングガバナンス
Specialist試験では「モデリングプロセスのガバナンス」も問われる。
モデル変更の管理プロセス:
変更要求（Change Request）
↓
Impact Analysis（影響分析）
→ 下流の物理テーブルへの影響
→ 依存するアプリケーション・ETLへの影響
→ データ品質ルールへの影響
↓
ステークホルダーレビュー
→ Business Steward（ビジネス要件の確認）
→ Technical Architect（設計整合性の確認）
↓
承認・実装・テスト
↓
モデルのバージョン管理（Git等でモデルを管理）
アンチパターン: 開発者がモデルを勝手に変更して後からDBを変更する。これはガバナンス違反。モデルが「設計図」として機能するには変更プロセスが必須。