（下書き）データガバナンスのためのデータ定義（odooカスタムモジュール開発）

プラットフォーム別物理モデルの設計

データモデリング × データ定義 → 物理モデル（プラットフォーム固有）

データモデリング（ビジネス層）

• エンティティ
• 属性（アトリビュート）
• リレーション

エンティティ・データ定義

ISO 11179をベースにビジネス主導のビジネスルール管理に拡張する。

ISO 11179

• オブジェクトクラス（Object Class）
  データ要素が属する「実体」。
  例：人、製品、タスク、顧客、注文、車両。
  Odoo での対応：
  → Odoo のモデル（テーブル）
  例：product.product, project.task, res.partner

• データ要素概念（Data Element Concept）
  データ要素の「意味的な概念」。
  例：身長、住所、難易度、担当者、製品仕様。
  Odoo での対応：
  → x_attribute_type（属性タイプ：階層）
  → x_attribute_composite（複合属性）

• データ要素（Data Element）
  オブジェクトクラスが持つ具体的な属性。
  名前・コード・型・値ドメイン・意味を持つ。
  Odoo での対応：
  → x_attribute（属性モデル）

• 値ドメイン（Value Domain）
  データ要素が取りうる値の集合・制約。
  例：整数 0〜300、選択肢（易・普・難）、Many2one の絞り込み条件。
  Odoo での対応：
  → x_attribute_domain（属性ドメイン：フラット）

• 概念ドメイン（Conceptual Domain）
  抽象的な値の意味集合。
  例：「難易度」という概念に対して「易・普・難」という意味集合。
  Odoo での対応：
  → x_attribute_type の上位カテゴリ（階層の親ノード）

• 分類体系（Classification Scheme）
  データ要素や概念を分類する体系。
  Odoo での対応：
  → x_attribute_type（階層構造）

• レジストリ（Metadata Registry）
  これらすべてを管理する仕組み。
  Odoo での対応：
  → ここで設計した 3 モデル＋複合属性モデルの全体

図. IPA isoiec-11179-4.pdf, p.33

ビジネス主導

ISO 11179をベースにビジネス主導のビジネスルール管理に拡張する。

「属性ドメイン」とは

属性ドメインとは、
「その属性が取り得る値の集合（許容される値の範囲）」
のこと。

データモデルの“遺伝子（DNA）”の中核であり、データ品質・整合性・意味論の源泉になります。

👉 列挙型＝“企業の公式な遺伝子”
👉 非列挙型＝“現場の生活習慣としての遺伝子”

分類	遺伝子としての性質	ガバナンスの焦点
列挙型	意思決定の痕跡（歴史）そのもの	変更管理・バージョン管理・意味論の継承
非列挙型	運用のクセ・現場文化が蓄積	入力ルール・品質管理・暗黙知の形式知化

列挙型の属性ドメイン（Enumerated Domain）

定義
取り得る値が 有限のリストとして明示的に定義されているドメイン。

例

• 性別：{Male, Female, Other}
• ステータス：{Draft, Active, Suspended, Closed}
• 都道府県コード：{01, 02, …, 47}
• 商品カテゴリ：{食品, 衣料, 家電}

特徴

• 値が固定
• 意味論が明確
• データ品質が高い
• マスタ管理が必要
• 変更すると歴史（遺伝子）に影響する

ガバナンス上のポイント

• 変更の影響が大きい（系譜に刻まれる）
• マスタのバージョン管理が必須
• 組織の意思決定の痕跡が残る（DNA）

非列挙型の属性ドメイン（Non‑Enumerated Domain）

定義
取り得る値が 無限または範囲・型で定義されるドメイン。

例

• 数値：整数（int）、実数（float）
• 文字列：varchar(255)
• 日付：date
• 金額：decimal(10,2)
• 温度：−50〜200℃
• 緯度経度：−180〜180

特徴

• 値の種類が無限
• 型・範囲で制約
• 柔軟性が高い
• 意味論は文脈依存
• マスタ管理は不要

ガバナンス上のポイント

• 意味論が曖昧になりやすい（暗黙知が入り込む）
• 入力ルール・バリデーションが重要
• データ品質のばらつきが発生しやすい

物理モデル

「システム」として設計する。

プラットフォーム: odoo ORM

• フィールドタイプ

プラットフォーム: 表計算アプリ

• セルの表示形式（データ型）

メタデータレジストリの設計と実装

最小構成での設計と実装

メタデータレジストリを実装するため、物理データ層に、odooプラットフォームを追加しました。
まずは、odooプラットフォームで、メタデータレジストリを実装します。

odoo ソースコード

models.py

from odoo import models, fields

# ----------------------------
# データモデル
# ----------------------------
class DataModel(models.Model):
    _name = "biz001.data_model"
    _description = "biz001 データモデル"

    name = fields.Char(string="名称", required=True)

    item_ids = fields.One2many(
        "biz001.data_item",
        "model_id",
        string="データ項目",
    )


# ----------------------------
# データ項目
# ----------------------------
class DataItem(models.Model):
    _name = "biz001.data_item"
    _description = "biz001 データ項目"

    name = fields.Char(string="名称", required=True)

    data_type = fields.Selection(
        [
            ("char", "文字列"),
            ("integer", "整数"),
            ("float", "実数"),
            ("boolean", "真偽値"),
            ("date", "日付"),
            ("datetime", "日時"),
            ("selection", "選択肢（列挙型）"),
            ("relation", "関連（Many2one/One2many）"),
        ],
        string="データ型",
        required=True,
    )

    model_id = fields.Many2one(
        "biz001.data_model",
        string="データモデル",
        required=True,
    )

    domain_id = fields.Many2one(
        "biz001.data_domain",
        string="データドメイン",
    )


# ----------------------------
# データドメイン
# ----------------------------
class DataDomain(models.Model):
    _name = "biz001.data_domain"
    _description = "biz001 データドメイン"

    name = fields.Char(string="名称", required=True)
    description = fields.Text(string="説明")

    item_ids = fields.One2many(
        "biz001.data_item",
        "domain_id",
        string="関連データ項目",
    )

設計の見直し

さらに詳細化

odooを対象とした論理モデルのメタモデル

＊＊＊　体系の見直し　＊＊＊

ISO/IEC 11179（メタデータレジストリ：MDR）の規格構成・目次体系に依拠し、これまでに議論・策定したメタデータ基盤およびビジネスモデルカタログの全体設計を詳細に体系化します。

UML図
1 管理・ガバナンス領域 (Administration Region)
2 データ記述領域 (Data Description Region)

に次の２つを追加しました。

3 ビジネスルール領域 (Business Rule Region)
4 物理・実装構造領域 (Implementation Region)

---

ISO/IEC 11179 準拠 メタデータレジストリ＆ビジネスモデルフレームワーク仕様書

第1部：フレームワークの概念と全体系（Part 1: Framework）

1.1 目的と基本思想

本フレームワークは、単なる「データベースの項目定義書」にとどまらず、企業および業界全体のビジネスモデルを統一的に管理・記述するためのカタログ基盤である。データ要素（Data Element）のみならず、パッケージ、エンティティ、ビジネスルール、適用文脈（Context）のすべてをISO/IEC 11179に準拠した統合管理対象（Administered Item）として一元化する。

1.2 レイヤード・アーキテクチャ（3層モデル構造）

本フレームワークは、「概念（業界標準）」と「適用（自社実装）」の分離を実現する3層の構造でメタデータを統制する。

【第1層：業界レファレンス・レイヤー】 (Context: INDUSTRY_STD)
  ├── 業界標準パッケージ (サプライチェーン、顧客管理等)
  ├── 概念エンティティ ([概念] 顧客, [概念] 契約等)
  ├── データ要素概念 (DEC: 顧客識別子, 決済金額等)
  └── 業界共通ビジネスルール (法定計算式, 消費税ルール等)
            │
            │ (Fit & Gap / Mapping)
            ▼
【第2層：自社論理・物理レイヤー】 (Context: MY_COMPANY_ERP)
  ├── 自社パッケージ (基幹物流, 会員マイページ等)
  ├── 自社エンティティ (m_users, t_orders 等) ※業界概念をインポート・拡張
  └── 自社データ要素 (DE: user_id, order_tax_rate 等)
            │
            ▼
【第3层：物理実装レイヤー】
  └── データベース (RDB/NoSQL), API規格, 自動生成UML (PlantUML)

---

第2部：分類とコンテキスト（Part 2: Classification & Context）

2.1 コンテキスト（Context）の役割

同一の概念やルールを「どの立場・どの適用範囲」で記述するかを区切る境界（バウンダリ）である。

• 参照コンテキスト（Reference Context）: 業界全体や標準化団体で定義される不変のモデルカタログ。
• 実装コンテキスト（Implementation Context）: 特定の自社システムやプロジェクトに合わせてカスタマイズ・具現化されたモデル。

2.2 パッケージ（Package）構造

メタデータをサブシステムやビジネスドメイン（例: 購買管理、顧客管理）単位でグループ化し、階層構造（親パッケージ ➔ 子パッケージ）を保持する。

---

第3部：メタモデルと基本属性（Part 3: Metamodel & Basic Attributes）

すべての構成要素は administered_items を頂点とする継承構造を採り、ライフサイクルや変更履歴の一元管理を実現する。

                    【共通管理基盤】
                  administered_items
  (item_id, item_type, registration_status, version, context_id...)
                            │
      ┌─────────────────────┼─────────────────────┬─────────────────────┐
      ▼                     ▼                     ▼                     ▼
  packages              entities          data_element_concepts   value_domains
(item_type='PKG')     (item_type='ENT')      (item_type='DEC')     (item_type='VD')
                                                  │                     │
                                                  ▼                     ▼
                                           business_rules        data_elements
                                          (item_type='BR')      (item_type='DE')

3.1 統合 DDL スキーマ定義

-- 1. 適用文脈 (Context)
CREATE TABLE contexts (
    context_id VARCHAR(64) PRIMARY KEY,
    context_name VARCHAR(255) NOT NULL,
    context_type VARCHAR(32) NOT NULL, -- 'REFERENCE', 'IMPLEMENTATION'
    description TEXT
);

-- 2. 統合管理オブジェクト (Administered Item)
CREATE TABLE administered_items (
    item_id VARCHAR(64) PRIMARY KEY,
    context_id VARCHAR(64) REFERENCES contexts(context_id),
    item_type VARCHAR(32) NOT NULL, -- 'PACKAGE', 'ENTITY', 'DEC', 'VD', 'DE', 'BR'
    registration_status VARCHAR(32) NOT NULL DEFAULT 'DRAFT', -- DRAFT, APPROVED, RETIRED
    version VARCHAR(16) DEFAULT '1.0.0',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    created_by VARCHAR(64),
    description TEXT
);

-- 3. パッケージ (Package)
CREATE TABLE packages (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    package_name VARCHAR(255) NOT NULL,
    parent_package_id VARCHAR(64) REFERENCES packages(item_id)
);

-- 4. エンティティ (Entity)
CREATE TABLE entities (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    package_id VARCHAR(64) NOT NULL REFERENCES packages(item_id),
    entity_name VARCHAR(255) NOT NULL,
    physical_name VARCHAR(255),          -- 物理テーブル名（業界標準概念の場合は NULL 可）
    is_conceptual BOOLEAN DEFAULT FALSE  -- TRUE: 業界標準概念, FALSE: 自社物理テーブル
);

-- 5. データ要素概念 (Data Element Concept: DEC)
CREATE TABLE data_element_concepts (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    concept_name VARCHAR(255) NOT NULL, -- 例: '年齢', '注文合計金額'
    object_class VARCHAR(255),          -- 例: '顧客', '注文'
    property VARCHAR(255)               -- 例: '年齢', '金額'
);

-- 6. 値領域 (Value Domain: VD)
CREATE TABLE value_domains (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    data_type VARCHAR(64) NOT NULL,
    format_pattern VARCHAR(64)
);

-- 7. データ要素 (Data Element: DE)
CREATE TABLE data_elements (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    entity_id VARCHAR(64) NOT NULL REFERENCES entities(item_id),
    dec_item_id VARCHAR(64) NOT NULL REFERENCES data_element_concepts(item_id),
    vd_item_id VARCHAR(64) NOT NULL REFERENCES value_domains(item_id),
    logical_name VARCHAR(255) NOT NULL,
    physical_name VARCHAR(255) NOT NULL,
    is_primary_key BOOLEAN DEFAULT FALSE
);

-- 8. ビジネスルール (Business Rule: BR)
CREATE TABLE business_rules (
    item_id VARCHAR(64) PRIMARY KEY REFERENCES administered_items(item_id) ON DELETE CASCADE,
    dec_item_id VARCHAR(64) NOT NULL REFERENCES data_element_concepts(item_id) ON DELETE CASCADE,
    rule_code VARCHAR(64) NOT NULL,
    rule_type VARCHAR(32) NOT NULL, -- 'CALCULATION', 'VALIDATION', 'DERIVATION'
    logic_expression TEXT NOT NULL,
    error_message TEXT
);

---

第4部：データ定義とビジネスルール（Part 4: Formulation of Data Definitions & Business Rules）

4.1 DRY原則に基づくルールの多層分離構造

二重管理を防ぎ、変更の影響範囲を最小化するため、ルールの性質に応じて定義階層を厳格に分離する。

階層	管理責任	具体例	理由
DEC（データ要素概念）	業務ロジック・不変ポリシー	年齢 >= 0 AND 年齢 <= 150

合計金額 = 税抜 * (1 + 税率) + 送料 | システムやDBの型が変わっても、ビジネスの本質として変わらないため。 |
| VD（値領域） | 物理型・桁数・表記制約 | VARCHAR(255), REGEX: ^[0-9]+$ | データフォーマット依存の制約であるため。 |
| DE（データ要素） | 文脈固有のデータベース制約 | NOT NULL, PRIMARY KEY, UNIQUE | 同じ概念（例: メールアドレス）でも、マスターテーブルでは必須、ログでは任意となるため。 |

---

第5部：命名・識別およびマッピング原則（Part 5: Naming, Identification & Mapping）

5.1 業界標準カタログと自社実装の Fit & Gap マッピング

業界標準モデルと自社実装モデルの差分を定量化するため、対照表（entity_mappings）を用意する。

CREATE TABLE entity_mappings (
    std_entity_id VARCHAR(64) NOT NULL REFERENCES entities(item_id), -- 業界標準（Reference）
    my_entity_id VARCHAR(64) NOT NULL REFERENCES entities(item_id),  -- 自社実装（Implementation）
    mapping_type VARCHAR(32) NOT NULL, -- 'EXACT', 'EXTENDED', 'PARTIAL'
    gap_description TEXT,               -- 自社独自の拡張仕様や未採用理由
    PRIMARY KEY (std_entity_id, my_entity_id)
);

これにより、カタログから自社システムへモデルを引き込む（サンプリングする）際、標準に対するカスタマイズ範囲が即座に可視化される。

---

第6部：登録手続・ライフサイクルと動的出力（Part 6: Registration & Visualization）

6.1 ステータス管理と波及統制

すべてのアイテムは DRAFT ➔ APPROVED ➔ RETIRED のライフサイクルを持つ。
親オブジェクト（例: DEC や Entity）が RETIRED に変更された場合、それに紐づく物理カラム（DE）の利用を制限するカスケードチェックロジックが機能する。

6.2 承認済みメタデータからの UML (PlantUML) 自動生成

registration_status = 'APPROVED' の要素のみを動的に抽出し、自社システムと業界標準の比較図（UML）を自動出力する。

---

まとめ（本フレームワークの価値）

1. 拡張性とガバナンスの両立: ISO/IEC 11179 準拠の構造にパッケージ・エンティティ・ビジネスルールを包含することで、統制を効かせながら柔軟なビジネスモデリングが可能となる。
2. ビジネスモデルの資産化: 業界標準カタログを保持することで、新規事業立ち上げ時における仕様設計の高速化と、標準との差分（Fit & Gap）の透明化を実現する。
3. 完全なトレーサビリティ: 概念（DEC）から物理カラム（DE）、そしてビジネスルール（BR）までのリネージが双方向に追跡可能となる。

実装用に再設計(体系の見直し)

参考資料

▼オーストラリア保健福祉研究所（AIHW）の『データ開発ガイド』