データアーキテクチャ

データアーキテクチャ（DA）は、ビジネス要件（戦略の実現、各種報告の信頼性確保、各種法規の遵守）に対するデータ戦略を実現するデータの仕組をモデル（青写真）として表したものです。

ここでは、エンタープライズアーキテクチャ（EA）の一要素であるデータアーキテクチャをどう設計するのか、次の観点で具体的な方法を提示します。

• データアーキテクチャの構成
• 準備タスク
• データアーキテクチャ設計基準の定義
• マスターデータのデータアーキテクチャ設計
• トランザクションデータのデータアーキテクチャ設計
• 分析データのデータアーキテクチャ設計
• ビジネスメタデータの定義

データアーキテクチャの構成

記事「データアーキテクチャの設計」

でも言及しましたが、データマネジメント知識体系（DMBOK）では、データアーキテクチャとして、以下の２つのモデルを作成すべきとしています。

• エンタープライズデータモデル（EDM：Enterprise Data Model)
  EDMは、全体的でエンタープライズレベルの実装に依存しない概念または論理データモデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供します。
  EDMには、企業の重要なデータ、それらの間の関係、重要な手引きとなるビジネスルール（ビジネスメタデータとして記録する）、いくつかの重要な属性が含まれます。
  これらは、すべてのデータが関連するシステム開発プロジェクトの基礎を定めているので、どのプロジェクトのレベルのデータモデルもEDMに基づいている必要があります。
• データフロー
  データがビジネスプロセスやシステムをどのように移動するかを示すものです。
  これは、データリネージュ（データの系統）のドキュメントであり、データの発信元、格納場所、使用場所、さまざまなプロセスとシステムの内部や間を移動する際に、データがどのように変換されるかを示します。
  重要なのは、戦略的に重要なデータがどの業務活動やシステムで生成・収集、変換・蓄積、利活用、破棄されるのか、業務活動やシステムとデータライフサイクルの関係を抑えるとです。
  これによって、データ品質を維持・向上させるために、業務活動やシステムをどう設計すればよいか検討したり、改善すべき業務活動やシステムを特定することができます。
  それから、データフローに近い概念に、データパイプラインがありますが、データパイプラインは、データの収集から処理、保存、配信までの一連のプロセスを自動化するシステムです。
  データフローが設計図とすると、データパイプラインは、その設計に基づいて構築された実行可能なシステムになります。

エンタープライズデータモデルは、

• 全社単位の全体概念データモデル
• 活動領域単位の概念データモデルおよび論理データモデル
• アプリケーション単位の論理データモデルおよび物理データモデル

から構成されます。

図：エンタープライズデータモデル 出典：データマネジメント知識体系 第二版
次の図は、スコープ（縦軸）とレベル（横軸）でエンタープライズデータモデルを分けたマトリクスです。

一方、データフローですが、EDM同様、スコープ（縦軸）とレベル（横軸）で分解すると次の図のようになります。

なお、なお、ビジネスプロセスの業務概念データモデルや業務論理データモデルをつくるときは、企業全体の活動領域（DMBOKのサブジェクトエリアと同義）を明確にします。

そして、そして、各活動領域に対応するビジネスプロセスを定義したうえで、ビジネスプロセス単位に業務概念データモデルや業務論理データモデルを作成します。

それから、エンタープライズアーキテクチャ（EA）におけるデータアーキテクチャ（DA）の位置づけは次のようになります。

概念データモデルは、データモデルのスキームや技術、製品に依存しない本質的なデータモデルなので、データモデルのスキームに依存しないUMLのクラス図で記述します。

一方、論理データモデルは、データモデルのスキームによって表現が異なります。
リレーショナルスキームの場合、論理データモデルはER図で記述します。
なので、リレーショナルスキームの場合、論理データモデルは、概念データモデルをER図に変換したものになります。

また、概念データフローは、技術や製品に依存したい本質的なアプリケーションタイプ間のデータの流れを表した図になります。
また、概念データフローには、データ統合の方針に合わせてバッチによる統合、イベント駆動による統合、リアルタイムの統合の違いが示されています。

論理データフローは、アプリケーションやデータ管理基盤の製品が反映されたものになります。

エンタープライズアーキテクチャ（EA）でいうと、概念レベルのEDMとデータフローは、EAの設計レベル、論理レベルのEDMとデータフローは、EAの戦略レベル、物理レベルのEDMとデータフローは、EAの実例レベルのデータアーキテクチャとして設計します。

図：エンタープライズアーキテクチャの構成
また、データマネジメント導入プロセスでいうと、概念レベルのEDMとデータフローは、データマネジメントモデルの設計、論理レベルのEDMとデータフローは、データマネジメント戦略の策定、物理レベルのEDMとデータフローは、データマネジメントシステムの構築のときに設計します。

準備タスク

データアーキテクチャを設計するためには、次のような準備が必要です。

• ビジネス概要の確認
• ジョブの設計
• アプリケーションポートフォリオの設計
• ビジネスプロセスの整理
• バリューチェーンの設計
• 業務フローの分析

データフロー

を設計するときは、データを保管する機能としてアプリケーションタイプが必要です。
アプリケーションタイプはジョブを支援する役割でジョブの単位に定義します。
アプリケーションポートフォリオは、全社レベルでアプリケーションタイプを構成したものになります。
トランザクションデータは、業務活動によって発生する事実を記録したデータです。
トランザクションデータを分析するためには、全社レベルで業務活動を整理する必要があります。
ここでは、事業ドメインや活動領域などビジネスの概要を整理した上で、ビジネスプロセス、バリューチェーン、業務フローという観点で業務活動を整理します。

データアーキテクチャ設計基準の定義

実際にデータアーキテクチャを設計する前に、どのようにデータアーキテクチャを設計するのか基準を次の観点で定義します。

• データアーキテクチャ（概念レベル）
  • データモデルを設計する観点の定義
  • ビジネス上のデータ要件を定義する観点の整理
  • データ品質の評価項目の定義
  • データセキュリティを測る基準の定義
  • ビジネスメタデータとして定義する内容の定義
  • データドメインの定義
• データアーキテクチャ（論理レベル）
  • テクニカルメタデータとして定義する内容の定義
  • データアーキテクチャ（論理レベル）を設計する基準の定義

データモデルを設計する観点の定義

どのように、データモデルを設計するかについて定義します。
ビジネスの仕組化では、ビジネスストラクチャマトリクスについて説明しましたが、このビジネスストラクチャマトリクスの資産、場所、機能、活動を使ってデータモデルを設計することができます。

次の図は、５W1Hの観点でデータモデルを設計するための雛形（テンプレート）です。

ビジネスストラクチャマトリクスの資産、場所、機能の部分がマスターデータ、活動がトランザクションデータになっていることがわかります。
メンバーは社員、パートナーは代理店や仕入先などの取引先になります。

ビジネス上のデータ要件を定義する観点の整理

ビジネス上の要件を満たすために定義すべきデータ要件があれば次の観点で記述します。

• データのトレーサビリティの確保
  財務報告の信頼性を確保する場合など、データが発⽣した原因となるデータがトレースできなければならない場合、それをデータ要件として定義します。
  「出荷の予約」アクションの業務概念データモデルの例の場合
  • 出荷の元となる受注データがトレースできなければならない。
    これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要である。
  • 出荷明細の元となる受注明細データがトレースできなければならない。
    これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要である。
• データ関連の制約
  分納や⼀括納⼊などのビジネスルール上、データ間の関連に制約がある場合、それをデータ要件として定義します。
  「出荷の予約」アクションの業務概念データモデルの例の場合
  • 複数の受注の製品をまとめて出荷（一括納品）できなければならない。
  • 一つの受注の製品を分割して出荷（分納）できなければならない。
  • 複数の受注明細の製品をまとめて出荷（一括納品）できなければならない。
  • 一つの受注明細の製品を分割して出荷（分納）できなければならない。
• データ記録者の記録
  財務報告の信頼性を確保する場合など、誰がデータを記録したか証跡を残す必要がある場合、それをデータ要件として定義します。
  「出荷の予約」アクションの業務概念データモデルの例の場合
  • 内部統制のため販売管理者、出荷管理者、請求管理者の職務を分掌する場合、出荷管理者のどの社員が受注したかを記録し履歴を残しておく必要がある。
• データの状態管理と、それに伴う制約
  ビジネスルール上、データの状態を管理し、それに伴う制約を担保する必要がある場合、それをデータ要件として定義します。
  • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷の出荷日が設定され、出荷ステータスが完了にならなければならない。
    出荷ステータスが完了になると、出荷内容の変更や出荷明細の追加ができないようにならなければならない。
  • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細のステータスが「出荷済」にならなければならない。
  • 「納品報告の確認」アクションのタイミング（製品が納品されたタイミング）で、出荷明細のステータスが「納品済」にならなければならない。
• データの記録に関する制約
  ビジネスルール上、記録されなければならないデータ項⽬などがあれば、それをデータ要件として定義します。
  • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細の出荷数量が設定されなければならない。
  • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細の出荷数量が、出荷明細が関連する受注明細の出荷数量に設定されなければならない。
• データの参照に関する制約
  ビジネスルール上、データと関連するデータを参照できなければならない場合、それをデータ要件として定義します。
  • 受注に基づいた出荷がある場合、それが参照できなければならない。
  • 受注明細に基づいた出荷明細がある場合、それが参照できなければならない。
  • 出荷明細には、販売品目ではなく、それに対応する製造品目が関連しなければならない。

「出荷の予約」アクションの業務概念データモデルの例

データ品質の評価項目の定義

データ品質の評価項目（データの一意性など）を定義します。
例
データ品質の評価項目を次のように定義します。

• 正確性
  データが現実の実体を正しく表している程度を表す。
• 完全性
  必要なデータが全て存在しているかどうか、その程度を表す。
• 一意性
  同じ実体を表すデータが同じデータセット内に複数存在していないか、その程度を表す。
• 一貫性
  データが、正しいルールに貫かれて表現されているか、その程度を表す。
• 適時性
  データが適切な時点のものであるか、その程度を表す。

データセキュリティを測る基準の定義

データセキュリティを測る基準（機密レベルと規制対象カテゴリ）を定義します。
例

機密性レベル
次のように機密性レベルを分けます。
• 公開用
  公衆を含む誰でも利用できる情報。
• 社内向け
  情報は社内のメンバーに限定されるが、共有した場合のリスクは最小限である情報。
  組織外部に向けて表示したり、説明することはできるがコピーすることはできない。
• 社外秘
  適切に結ばれた機密保持契約や、それに類するものがない場合は、組織外で共有することができない情報。
• 制限付機密
  「知る必要がある」一定のロールを持つ個人に限定された情報。
  制限付機密データにアクセスするには、個人が権限付与手続を踏む必要がある。
• 登録者限定機密
  非常に機密レベルが高い情報で、データにアクセスするためには、情報にアクセスするすべての人が法的な合意に署名し、秘密のための責任を負わなければならない。
規制対象カテゴリ
規制対象のカテゴリは次のようになります。
• 個人識別情報（PII：Personal Identification Information）
  個人の私的情報で、氏名、住所、電話番号、スケジュール、政府のID番号、年齢、人種、宗教、民族性、誕生日、家族の氏名や仲間の名前、雇用情報（人事データ）、報酬など、個人一人一人を識別できる情報が含まれるもの。
• 財務上のセンシティブデータ
  インサイダーデータと呼ばれるもので、まだ公表されていない現在の財務情報を含む、すべての財務情報を指す。
• 医療上のデータ/個人健康情報（PHI:Personal Health Information）
  個人の健康や医療に関するすべての情報。
• 教育記録
  個人の教育に関するすべての情報。

ビジネスメタデータとして定義する内容の定義

ビジネスメタデータとして定義する内容を定義します。
例



データドメインの定義

データドメインとは、属性の定義域のことで、属性が取りうる値一式を定義したものです。
データドメインを使うと、属性の特性を標準化することができます。
例えば、有効な日付をすべて含む日付というドメインを定義すると、それを論理データモデル内の任意の日付属性や物理データモデル内の日付カラム（フィールド）に割り当てることができます。
DMBOKではデータドメインの種類を次のように紹介しています。



テクニカルメタデータとして定義する内容の定義

テクニカルメタデータとして定義する内容を定義します。
DMBOKでは、テクニカルメタデータとして次のような例を示しています。

• 物理データベーステーブルとカラムの名称
• カラムのプロパティ
• データベースオブジェクトのプロパティ
• アクセス権
• データCRUDルール
• データテーブル名、キー、インデックスなどを含む物理データモデル
• データモデルと物理的資産の関係を示すドキュメント
• ETLジョブの詳細
• ファイルフォーマットのスキーマ定義
• ソースからターゲットへのマッピングを示すドキュメント
• 上流および下流への変換影響情報を含むデータリネージュを記述するドキュメント
• プログラムとアプリケーションの名称と説明
• コンテンツ更新サイクルのジョブスケジュールと依存関係
• リカバリーとバックアップのルール
• グループ別、役割別データのアクセス権

データアーキテクチャ（論理レベル）を設計する基準の定義

データモデリングのスキームをどうするかなどデータアーキテクチャ（論理レベル）を設計する基準を定義します。
リレーショナルスキームをER図で記述する場合、次のようにER図の表記方法も定義します。
例
ここでは、IE表記法（Information Engineering）とIDEF1X表記法（Integration Definition for Information Modeling）を、次のように組み合わせて使います。

• エンティティは独立エンティティと従属エンティティを分けて記述する(IDEF1X表記法)
• エンティティ名を長方形の上(外側)に書く(IDEF1X表記法)
• 主キーを長方形の1段目に、その他の属性を長方形の2段目に書く(IDEF1X表記法)
• 外部キーは属性名の後ろに(FK)を書く(IDEF1X表記法)
• リレーションシップは依存型リレーションシップと非依存型リレーションシップを分けて記述する(IDEF1X表記法)
• リレーションシップの多重度はIE記法で書く(IE表記法)

また、次のように論理データフローを記述する場合の基準も定義します。
例
論理データフローには、概念データフローに対して次の観点を反映させます。

• アプリケーションマネジメント戦略で選定されたアプリケーション製品
• データマネジメント戦略で選定されたデータ管理基盤の製品

マスターデータのデータアーキテクチャ設計

マスターデータのデータアーキテクチャは次のように分類されます。

• 概念レベルのデータアーキテクチャ
  • データモデル
    全体概念マスターデータモデル
  • データフロー
    全体概念データフロー
• 論理レベルのデータアーキテクチャ
  • データモデル
    全体論理マスターデータモデル
  • データフロー
    全体論理データフロー

DMBOKではマスターデータの種類として次の例をあげています。

• パーティマスターデータ
• 財務マスターデータ
• 法令マスターデータ
• 製品マスターデータ
• ロケーションマスターデータ
• 業種マスターデータ

ここでは、パーティマスタデータの代表として顧客マスターデータと製品マスターデータの全体概念マスターデータモデルと全体概念データフローの例を示します。

• 顧客マスターデータの全体概念マスターデータモデル
• 顧客マスターデータの全体概念データフロー
• 製品マスターデータの全体概念マスターデータモデル
• 製品マスターデータの全体概念データフロー

顧客マスターデータの全体概念マスターデータモデル


これは、法人顧客の全体概念マスターデータモデルの例です。
本概念データモデルの特徴は次のようになります。

• 顧客は特定の法人に関連づけられる。
• 法人は複数の関連会社に関連することがある。
• 各顧客には、固有の顧客担当者が複数いる場合がある。
• 各顧客には、固有の販売条件がある。
• 各顧客には、特定の銀行口座を登録することができる。
• 各顧客は、既に取引を開始しているか、まだ取引していないか識別することができる。
• 各顧客は、業種や規模、エリアなど様々な分類基準で分類することができる。
• 各顧客は、契約先、出荷先、請求先など役割に分けることができる。

顧客マスターデータの全体概念データフロー


このデータアーキテクチャは、顧客データの主管システムである顧客管理システムが顧客マスターデータのトランザクションハブになり、顧客データが更新される都度、顧客データを必要とするシステムにTopicを介して配布（ブロードキャスト）するというイベント駆動統合の仕組を表しています。
Topicとは発行者となるシステムが購読者となるシステムに一斉にメッセージを送るPublish/Subscribeモデルのチャネルのことです。
顧客データを必要とするシステムが、必要な都度、APIを介して顧客管理システムから最新の顧客データをリアルタイムに取得することもできますが、リアルタイム統合の場合、顧客管理システムに障害が発生すると各システムが、その影響受けてしまいます。
非同期通信をベースとしたイベント駆動統合の場合、データを発信するシステムが、データを受信するシステムに依存しないためシステム間を疎結合にし、それだけ個々のシステムの独立性と、ネットワーク全体の障害耐性を高めることができます。


製品マスターデータの全体概念マスターデータモデル

マーケティングマネジメント―持続的成長の開発と戦略展開で、フィリップ・コトラーは、製品の階層構造を次のように説明しています。

• ニーズ・ファミリー
  製品ファミリーのもととなる中核ニーズ。
  生命保険の例
  安全。
• 製品ファミリー
  中核ニーズを満足させる全ての製品クラス。
  生命保険の例
  貯蓄と所得。
• 製品クラス
  製品ファミリーの中で機能的一貫性を持っているとみなされる製品グループ。
  生命保険の例
  金融手段。
• 製品ライン
  製品クラスの中で、機能、顧客、販路、価格水準などを同じくすることで密接に関連づけられている製品グループ。
  生命保険の例
  生命保険。
• 製品タイプ
  製品ラインの中で、形態や様式が同じもの。
  生命保険の例
  長期契約の生命保険。
• ブランド
  製品ラインの中の一つあるいは複数のアイテムにつけられた名前であり、アイテムの特性や出所を明らかにするもの。
  生命保険の例
  プルーデンシャル。
• 品目（アイテム）
  製品ラインやブランドの中で、サイズ、価格、外見、その他の特性で区別される単位。
  生命保険の例
  プルーデンシャル更新可能長期保険。

この製品分類の最下層である品目（アイテム）は、衣類であれば仕様×サイズ×色によって一意に決まる最小在庫管理単位（SKU）を表します。
ここでは、製品マスターデータとして品目（アイテム）のマスターデータ、品目マスターデータの例を示します。

本概念データモデルの特徴は次のようになります。

• 品目は、「PN（Parts Number）」という品目情報と、「PS（Part Structure）」というPNの親子関係を管理するBOM（Bills of materials：部品表）の構造を持つ。
• 品目の種類には、設計品目、製造品目、販売品目、購買品目、サービス品目がある。
• 各品目は、種類ごとに、仕様、サイズ、色など様々な分類基準で分類することができる。
• 各品目は、種類ごとに、複数の単価を持つことができる。

次に、設計品目、製造品目、販売品目、購買品目、サービス品目間の関係は次のようになります。



製品マスターデータの全体概念データフロー

製品開発の業務フローは次のような流れになります。


• 製品管理者が製品を設計すると、
• 生産管理者がそれを受けて量産化の準備をする。
• 量産化の準備ができると、販売管理者、購買管理者、保守サービス管理者が、それぞれ、販売、購買、サービスの企画を策定する。
• 販売、購買、サービスの企画が策定されると、顧客管理者が市場に向けて製品のプロモーションを行う。


製品開発の流れを受けて、各システム間のデータフローは次のようになります。


• 製品管理者の製品設計を受けて製品管理システムが、設計品目データをQueueを介して生産管理システムに送る。
• 生産管理者の生産準備の過程で、設計品目データから製造品目データが生成され、それがTopicを介して販売管理システム、購買管理システム、サービス管理システムに送られ、各システムで販売品目、購買品目、サービス品目が生成される。
• また、生産準備を受けて、製造品目データがQueueを介して在庫管理システムに送られることで、製造品目に対応した在庫が生成される。
• 販売、購買、サービスの企画が策定されると、販売管理システムの販売品目がQueueを介して顧客管理システムに送られ、製品のプロモーションに活用される。
• なお、顧客の問い合わせやクレームによって蓄積された製品の改善要求データは、製品管理システムに送られ、製品の改良に活用される。

トランザクションデータのデータアーキテクチャ設計

トランザクションデータのデータアーキテクチャは次のように分類されます。

• 概念レベルのデータアーキテクチャ
  • データモデル
    全体概念トランザクションデータモデル
    業務概念データモデル
  • データフロー
    業務概念データフロー
• 論理レベルのデータアーキテクチャ
  • データモデル
    業務論理データモデル
  • データフロー
    業務論理データフロー

ここでは、次の業務概念マスターデータモデルと業務概念データフローの例を示します。

• 全体概念トランザクションデータモデル
• 「製品の受注」アクティビティの業務概念データフロー
• 「受注の登録」アクションの業務概念データモデル（販売管理システム）
• 「受注の登録」アクションの業務概念データモデル（在庫管理システム）
• 「出荷の予約」アクションの業務概念データモデル（出荷管理システム）

関連する業務フローについては以下を参照ください。
「製品の販売」プロセスの業務フロー


全体概念トランザクションデータモデル

例えば、産業機械製造業のバリューチェーンが次のような内容だとします。

このうち、価値を届ける活動のバリューチェーンに対する全体概念トランザクションデータモデルの例は次のようになります。

また、情報通信サービス業のバリューチェーンが次のような内容だとします。

このうち、価値を届ける活動のバリューチェーンに対する全体概念トランザクションデータモデルの例は次のようになります。



「製品の受注」アクティビティの業務概念データフロー

「製品の販売」プロセスのアクティビティフローのうち、「製品の受注」アクティビティのアクションフローは次のようになります。

このアクションフローの「受注の登録」アクションと「出荷の予約」アクションに対するデータの流れは次のようになります。

販売管理者が販売管理システムで「受注の登録」をしたタイミングで、販売管理システムからリアルタイムに在庫管理システムに受注明細データが渡されることで、該当する製造品目の在庫が引き当てられます。


「受注の登録」アクションの業務概念データモデル（販売管理システム）

上記業務概念データフローにおける販売管理システムの業務概念データモデルは次のようになります。

販売見積がある場合は、それが受注の原因として参照できるようにします。


「受注の登録」アクションの業務概念データモデル（在庫管理システム）

上記業務概念データフローにおける在庫管理システムの業務概念データモデルは次のようになります。

引当の原因となる受注明細がトレースできるようにします。
また、引当対象は販売品目ではなく製造品目なので、販売管理システムでは、販売品目データを製造品目データに変換して在庫管理システムに渡す必要があります。


「出荷の予約」アクションの業務概念データモデル（出荷管理システム）

上記業務概念データフローにおける出荷管理システムの業務概念データモデルは次のようになります。

出荷の原因となる受注データがトレースできるようにします。
出荷対象は、販売品目ではなく、それに対応する製造品目になるようにします。


分析データのデータアーキテクチャ設計

分析システムのアプリケーションタイプは、分析の目的ごと設定するので、BSCのKPIに定義します。
なので、分析データもBSCのKPIに対応したものになります。

ここでは、LTV分析システムにおけるLTVのデータアーキテクチャの例について説明します。
まず、LTV分析システムではLTV（顧客生涯価値）を次のように管理すると考えます。

• 既存顧客のLTV=取引期間における顧客の粗利益ー取引期間における顧客維持コストと考える。
• 製品カテゴリの定義
  販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類する。
• 顧客セグメントの作成
  例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類する。
• 期間（年、四半期など）ごとの顧客維持コストを記録する。
• 売上計上の都度、売上データをLTV分析システムに蓄積する。
• LTV分析システムでは、売上明細から継続的に期間（年、四半期など）ごとのLTVを測定する。

まず、販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類します。

図：製品マスターデータの全体概念マスターデータモデル
次に、例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類します。

図：顧客マスターデータの全体概念マスターデータモデル
このモデルでは、期間（年、四半期など）ごとの顧客維持コストを顧客ごとに記録できるようにしています。
さて、次のように売上データから製品一個あたり粗利益を計算することができます。

なので、コマンド・クエリ分離パターン（CQRS）を適用して、「製品の出荷登録」アクションのタイミングで売上管理システムから売上データをLTV分析システムに渡します。
LTV分析システムのDWHには、その都度、売上データが蓄積されます。

売上管理システムからLTV分析システムに渡される売上データのカノニカルモデルは次のようになります。

LTV分析システムでは、定期的にバッチで売上データからLTVデータを統合します。
その際、バッチ処理のの一環として、顧客管理システムから最新の顧客セグメント別顧客データを取得するとともに、販売管理システムから最新の製品カテゴリ別販売品目データを取得します。

LTV分析システムでは、次のよなLTVデータが生成されます。

図：LTVの全体分析概念データモデル


ビジネスメタデータの定義

概念レベルのデータアーキテクチャを設計するときは、その結果を、ビジネスメタデータとして定義する必要があります。
ビジネスメタデータは、データカタログとして活用することができます。
ここでは、次のビジネスメタデータの定義例を示します。

• 受注データのビジネス上のデータ要件の例
• 受注データの品質要件の例
• 受注データのセキュリティ要件の例
• 受注明細データのビジネス上のデータ要件の例
• 受注明細データの品質要件の例
• 受注明細データのセキュリティ要件の例
• 出荷明細データのビジネス上のデータ要件の例
• 出荷明細データの品質要件の例
• 出荷明細データのセキュリティ要件の例
• 売掛金データのビジネス上のデータ要件の例
• 売掛金データの品質要件の例
• 売掛金データのセキュリティ要件の例

ビジネスメタデータの例（Excel）のダウンロード


受注データのビジネス上のデータ要件の例




受注データの品質要件の例




受注データのセキュリティ要件の例




受注明細データのビジネス上のデータ要件の例




受注明細データの品質要件の例




受注明細データのセキュリティ要件の例




出荷明細データのビジネス上のデータ要件の例




出荷明細データの品質要件の例




出荷明細データのセキュリティ要件の例




売掛金データのビジネス上のデータ要件の例




売掛金データの品質要件の例




売掛金データのセキュリティ要件の例