オントロジーと ER の違い：業務の「意味」を扱う

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

この章で学ぶこと

ER 図で 顧客–注文–商品 の線は引けました。 それでもさくら商事の会議は止まります。理由はシンプルで、同じテーブル名でも“意味”が合意されていない からです。

「キャンセル」「返品」「売上確定」——日本語では分かるつもりでも、SQL の WHERE 句 1 行で解釈が割れます。 オントロジー（Ontology） は、この 業務上の意味と関係 を整理する枠組みです。

本章は OWL ファイルの書き方ではありません。 データマネジメントとして、いつ ER だけでは足りず、意味の層が必要か を判断できることを目標にします。

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

• ER 図とオントロジーの 目的の違い を説明できる
• 「キャンセル」「返品」「売上確定」を 業務ルール として言語化できる
• ER だけでは判断材料が足りない場面を具体例で示せる
• オントロジーが SSOT・品質・ガバナンスとどう接続するか説明できる

1. 返品を売上に含めるか：再び

Stage 1 の会議を思い出してください。 経理・マーケ・基盤で「6 月売上」が合いませんでした。 その一因が 返品の扱い です。

3 人とも ER 上の orders テーブルを見ています。 テーブル構造は同じなのに、数字が割れる。

経営・木村

「orders があるんだから、正しい SQL を 1 本書けばいいんじゃないの？」

基盤・鈴木

「SQL の前に、返品が起きた注文を“売上”と呼ぶか を決めないと、WHERE が永遠に増えます。」

2. ER が答えられること・答えられないこと

さくら商事の ER（簡略）:

Customer ──< Order ──< OrderLine >── Product
                          │
                          └──< Refund
          

Refund 表があるから返品は追える——と見えて、Refund が発生した時点で Order は売上から除外するのか、月をまたいで調整するのか は ER には書きません。

3. ER とオントロジーの違い

3.1 関係タイプの例

オントロジーでは、関係に 意味の種類 を付けます（ツール非依存の考え方）。

ER は「どのテーブルがどう繋がるか」、オントロジーは「業務上の意味と関係」を扱います。

さくら商事では、ER だけでは キャンセル注文を売上に含めるか の判断材料が足りません。

4. 三つの用語を業務ルールで固定する

4.1 キャンセル（Cancel）

4.2 返品（Return / Refund）

4.3 売上確定（Revenue Recognition）

これらは オントロジー／ビジネスルール の領域です。 決まれば、AE はマート SQL を 1 本に寄せられます。

-- 例：合意後の「公式売上」マート（概念）
          SELECT
            DATE(shipped_at) AS sales_date,
            SUM(total_amount) AS recognized_revenue
          FROM orders
          WHERE shipped_at IS NOT NULL
            AND status NOT IN ('cancelled')
            -- 返品は refunds 表で別調整（ポリシーに従う）
          GROUP BY 1;
          

現場メモ

オントロジーを整えると、SQL は 短く なります。 逆に、定義が曖昧なまま SQL を足すと、オントロジーが SQL に埋もれる —— これが属人化の正体です。

5. いつオントロジーが必要か：判断表

すべての列に OWL は不要です。次の どれか 2 つ以上 当てはまったら、意味の整理（オントロジー的作業）を優先します。

6. ツールは後：まず「合意可能な言葉」

Palantir Foundry、Knowledge Graph、RDF——製品名は様々です。 入門トラックで重要なのは ツール選定 ではなく、次の 3 点です。

1. 概念（Customer, Order, Revenue）に一意の定義を付ける
2. 関係（is-a, part-of, precedes）を明示する
3. ルール（いつ売上か、何を除外するか）を変更管理する

さくら商事では、スチュワードの佐藤さん（経理）と田中さん（マーケ）が、1 枚の用語集 から始めました。

これは簡易オントロジーです。後からセマンティックレイヤーやカタログに載せられます。

7. DAMA・SSOT との接続

ER が 骨格、オントロジーが 神経、SSOT が 公式の参照先 —— そう考えると、Stage 2 の流れが一本につながります。

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

コラム：よくある誤解 —「オントロジー＝難しいグラフ DB を入れること」

オントロジーと聞くと、RDF や Knowledge Graph、専用製品の導入を連想する人が多いです。さくら商事でも「Foundry 入れれば？」という雑談が一度出ましたが、鈴木さんは ツール以前に合意可能な言葉 がないとグラフも空箱だと指摘しました。

実際に効いたのは、佐藤さんと田中さんが作った 1 枚の用語集 です。「公式売上」「アクティブ顧客」「返品反映」の 3 語に、定義・オーナー・最終更新日を付けただけで、会議の定義確認は半分以下になりました。OWL ファイルはまだありません。

オントロジー的作業のシグナルは、CASE WHEN が 20 行を超える、同じ名詞で部門が割れる、監査で説明責任が問われる——といった 現場の痛み です。グラフ DB は、その痛みを整理した 後 の選択肢の一つに過ぎません。

まとめ

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

テーブルがきれいでも、意味が合意されていなければ 正しい SQL は存在しません。 オントロジーは難しい哲学ではなく、会議で揉める言葉を固定する作業 です。

次に読む

• 前章: ER・SSOT・マスターデータ
• 次章: メタデータとリネージ
• 関連: 指標定義（analytics）

確認問題

問題 1

さくら商事で orders テーブルは全員同じ ER を見ているが、返品の扱いで売上が割れる。 最も本質的な原因 はどれですか。

A. JOIN の書き方が悪い
B. 返品・売上確定の 業務定義 が合意されていない
C. BigQuery のリージョンが違う
D. ER 図の線の色が統一されていない

正解: B

解説: 構造は共有できても 意味 が未合意だと WHERE が割れます。A は症状への対症療法、C/D は無関係です。

問題 2

「キャンセル済み注文は売上確定と両立しない」というルールを、オントロジー的に表すと 最も近い のはどれですか。

A. part-of
B. excludes（相互に成立しない関係）
C. is-a
D. 外部キー制約

正解: B

解説: 業務上の 排他 は excludes 的ルールです。part-of は構成、is-a は種別、D は ER/DDL の話です。

問題 3

山田さんが「オントロジー導入 = OWL ファイルを全部書く」と理解している。 データマネジメント入門の観点で 最も適切な修正 はどれですか。

A. OWL だけがオントロジーなので、全テーブルを RDF 化する
B. まず用語集・ビジネスルール・オーナーで 合意可能な意味 を固定し、必要に応じてツール化する
C. オントロジーは不要。ER さえあれば売上は自動的に一致する
D. 返品問題は SQL の WINDOW 関数で解決する

正解: B

解説: 入門レベルでは 合意と文書化 が本体です。A は過剰、C は Stage 1–2 で否定済み、D は定義問題を技術で覆い隠します。

用語メモ（この章）