ER・SSOT・マスターデータ：正本はどこにあるか

Stage 2 — 第2章 | データマネジメント入門 推定学習時間：40〜50分 | 難易度：★★★☆☆

この章で学ぶこと

DAMA 地図で 参照・マスターデータ と モデリング の箱を押さえました。 現場で最も火が付きやすいのが、「同じ顧客・同じ商品なのに、ID も名前も数字も違う」問題です。

この章では、ER 図（Entity-Relationship Diagram、エンティティ間の関係図）で 構造 を捉え、SSOT とマスターデータ（Master Data）で 正本 を決める考え方を学びます。

この章を終えると、こんなことができるようになります：

• ER 図を「テーブル設計の地図」として読める
• マスターデータとトランザクションデータ（Transaction Data）の違いを説明できる
• SSOT がないときに起きる 名寄せ・二重管理 の症状を具体例で説明できる
• さくら商事の顧客 ID・商品マスタ問題を、設計判断として整理できる

1. 同じ顧客が 3 人いる

さくら商事の CRM 担当が、次のレポートを持ってきました。

3 つとも「田中花子さん」のはずです。 JOIN すれば解決——と山田さんが SQL を書き始めたところ、鈴木さんが止めました。

「JOIN 以前に、正本の顧客マスタ がない。君の SQL は“その場しのぎの名寄せ”になる。」

2. ER 図：構造を見る言語

ER 図は、どのエンティティ（実体）が、どんな関係で結ばれているか を表します。 さくら商事の EC 分析で最低限必要な構造は、次のイメージです。

[Customer] 1 --- * [Order] * --- * [OrderLine] * --- 1 [Product]
          

ER 図は 物理テーブル名 そのものではありません。 orders と order_items に分割されているか、fct_orders という 1 表にまとまっているかは実装の話です。

現場メモ

ER は 正しさの保証書 ではありません。 線で結ばれていても、キーの意味がソースごとに違えば、きれいな JOIN でも 間違った統合 になります。

3. マスターデータとトランザクションデータ

さくら商事の火事は、トランザクション（注文）を集計する前に、マスタ（顧客・商品）の正本が割れている ことから始まっています。

3.1 商品マスタ二重管理

マーケは EC 側で「売れ筋 TOP10」を出し、経理は ERP 側で「粗利」を出します。 同じ“商品”の話をしているのに、母集団が一致しません。

4. SSOT がないと何が起きるか

SSOT（Single Source of Truth、信頼できる唯一の参照元）は、組織が公式に信頼する参照元が 1 箇所に決まっている状態 です。

4.1 部署別コピー乱立

SSOT 前のさくら商事（簡略）:

SSOT 後の目標像:

4.2 名寄せ（Identity Resolution）の限界

顧客の名寄せは、メールアドレス・電話番号・住所の類似度で 同一人物候補 を出せます。

-- 名寄せの一例（ルールが文書化されていないと危険）
          SELECT
            a.customer_id AS ec_id,
            b.customer_id AS erp_id,
            a.email,
            b.phone
          FROM ec_customers a
          JOIN erp_customers b
            ON LOWER(TRIM(a.email)) = LOWER(TRIM(b.email));
          

名寄せ SQL は 加工段階の技術 です。 SSOT では、公式の顧客 ID をどこで発行し、他システムにどう配るか を先に決めます。

5. 設計判断：正本を決める 5 つの問い

新しいマスタや指標を議論するとき、次の 5 問を使うと会議が短くなります。

Slack 抜粋

マーケ・田中:「Sheets の方が早いから、うちは Sheets 正本で。」

経理・佐藤:「税区分は ERP しか信頼できません。Sheets 正本は監査で通りません。」

基盤・鈴木:「正本は ERP、分析は DWH で分けましょう。Sheets は個人作業用に。」

6. ER・マスタ・SSOT の関係

3 つは別物ですが、セットで効きます。

ER（構造） → マスタ（正本の中身） → SSOT（組織的な合意）
          

さくら商事の次の一手は、ER を完璧に描くことではありません。 顧客・商品の正本を 1 つ決め、DWH へ配る ことです。

7. analytics トラックとの棲み分け

データアナリティクス入門 では、CTE でマートを作り、指標定義を SQL と一緒に書きます。 本トラックでは、その 前 に「正本とオーナー」を決める話をします。

両方必要です。マスタが割れたまま SQL を磨いても、会議の数字は揃いません。

体系コラム：カリキュラム上の位置づけ

コラム：さくら商事メモ — 商品マスタ正本争い

商品カテゴリが EC 管理画面・分析 CSV・経理 ERP で微妙に違い、田中さんが毎月手作業で置換していました。Slack では「Sheets の方が早いから正本にしよう」という声も上がりました。

佐藤さん（経理）は監査の観点から ERP を正本に据え、鈴木さんは「ERP → 日次 ETL → DWH dim_product」の配布経路を提案。木村さんが決めたのは、正本は ERP、分析は DWH、Sheets は個人作業用 という三層です。

この決定で消えたのはカテゴリ名の不一致だけではありません。誰が SKU 追加を承認し、下流へいつ反映するか という変更管理の入口もできました。ER 図を完璧に描くより、正本 1 つを決める方が先です。

まとめ

この章のキーメッセージ：

「同じ顧客が 3 人いる」問題は、JOIN スキル以前に 正本とオーナー の問題です。 ER で構造を共有し、マスタで中身を揃え、SSOT で どこを公式とするか を決めてください。

次に読む

• 前章: DAMA-DMBOK 簡易地図
• 次章: オントロジーと ER の違い
• 関連: 指標定義（analytics）

確認問題

問題 1

さくら商事で EC・ERP・Sheets の商品コードが一致しない。 最も先に 決めるべきことはどれですか。

A. Looker の色テーマ
B. 商品マスタの正本とオーナー
C. ウィンドウ関数の PARTITION 句
D. 機械学習モデルのハイパーパラメータ

正解: B

解説: コード不一致は マスタ正本 の問題です。A/C/D は分析 UI や SQL 技法・モデル調整で、母集団の不一致は解消しません。

問題 2

メールアドレス一致で顧客を JOIN する SQL を恒久運用している。 データマネジメント上 最も懸念すべき 点はどれですか。

A. SQL が長い
B. 名寄せルールが文書化・承認されず、正本 ID 設計を回避している
C. メールアドレスは個人情報ではない
D. ERP は不要になる

正解: B

解説: 名寄せは有用な 加工 ですが、公式顧客 ID の発行・配布が決まっていないと、ルール変更時に過去数字の説明ができません。C は誤り（PII に該当しうる）。

問題 3

「SSOT は DWH の dim_product テーブル 1 個」と宣言した。 この宣言だけでは不十分 な理由として最も適切なのはどれですか。

A. テーブル名に dim_ が付いているから
B. 業務上の正本・変更承認・下流配布・旧コピー廃止がセットで決まっていないから
C. SSOT は Excel しか認めないから
D. ER 図を描いていないから

正解: B

解説: SSOT は 物理表の名前 ではなく、組織的合意です。オーナー、変更管理、配布、旧資産の廃止がなければ、また Sheets 乱立に戻ります。

用語メモ（この章）