カノニカルデータモデル(CDM)の基本

エンタープライズアプリケーションやエンタープライズシステムは、そもそも簡単に扱えるものではありません。これらは規模が大きく、統合された複雑な環境になりがちであり、さまざまなデータ形式やデータ構造が混在しています。統合された複数のコンポーネント間で多様なデータモデルを定義して管理するには、多大な労力と時間が必要です。

カノニカルデータモデル(CDM)は、接続するコンポーネント間で標準的かつ一貫性のあるデータモデルの利用を促すことで、作業の負担を大幅に軽減します。このブログ記事では、CDMの導入を始める際に役立つ次のトピックについて説明します。

• CDMの定義
• CDMの仕組み
• 組織にとってのメリット
• 導入方法

CDMの定義

カノニカルデータモデル(CDM)は、データのタイプ、構造、関係性、ルールなど、標準化された共通の定義セットを持つデータモデルであり、特定のアプリケーションに一切依存しません。

アプリケーションは、他のアプリケーションとデータをやり取りするときに、この共通化された形式でメッセージを作成し、使用する必要があります。カノニカルデータモデルは、すべてのデータモデルを融合したモデルではなく、統合された複数のコンポーネント間で利用できる単一のユニバーサルデータモデルです。CDMを利用する目的は次のとおりです。

• 統合に関連する依存関係を減らす
• アプリケーション間やシステム間のスムーズな連携を可能にする

「カノニカル」とは、一般的なルールや広く認められた手順に従うこと、つまり規範の一部であることを示す用語です。したがってこのデータモデルは、これから定義する一般的なルールに従うものになります。

CDMの導入が進んだ要因

CDMが導入された経緯を理解するには、統合にまつわる複雑さを知る必要があります。現在のアプリケーションアーキテクチャは、使用するテクノロジースタックやプログラミング言語が異なるサブシステムやアプリケーションを統合して成り立っています。マイクロサービス、サービス指向アーキテクチャ(SOA)、分散システムなどはその一例です。

アーキテクチャによって形式が異なるため、統合されたアプリケーションやシステム間で、データのやり取り、データガバナンス、相互運用性の確保が複雑になります。しかし、CDMの導入により、統合環境間でやり取りされるデータについて、統合されたすべてのコンポーネントが共通の理解を持てるようになります。これにより、統合されたコンポーネント間の依存関係が最小限に抑えられ、データの一貫性とデータガバナンスが向上します。

データ関連のトピック

CDMの導入をすでに検討している方は、データ管理、データパイプライン、データオブザーバビリティ、データ品質、データの正規化、ETLなどのトピックをご覧になることをお勧めします。

CDMの仕組み 

あるオンライン学習アプリケーションが、学生登録、コース登録、決済システムなど、他のいくつかのサブシステムと連携しているとします。各サブシステムに保存されているクライアント(学生と講師)のデータは、データタイプ、形式、構造がさまざまに異なっている可能性があります。

たとえば、Node.jsの学生登録システムがMongoDBに情報を保存しているのに対し、メインの学習アプリケーションはJavaで構築され、リレーショナルデータベースにデータを保存しているかもしれません。

ここでデータタイプ、形式、構造が標準化されたCDMを作成することで、クライアントデータを上記のシステム間で共有できるようになります。このCDMは、Plain Old XML (POX)、SOAl、JSONなど、合意された形式で定義できます。また、学生の名前、ID、メールアドレス、電話番号などのデータフィールドを含めることもできます。

ただし、各データフィールドの共通名について、システム間で合意しておく必要があります。そうすれば、あるシステムがフィールド名として"Student ID"を使用し、別のシステムがフィールド名として"Student No"を使用していたとしても、この両方をCDMの"Student No"フィールドにマッピングできます。

学生登録システムは、学生データをメインアプリケーションに送信する前に、CDMの標準形式に変換します。学生データを登録システムから受け取ったメインアプリケーションは、そのデータを独自の形式に変換します。

CDMのメリット：CDMが必要な理由

CDMは、さまざまなシステムやサードパーティアプリケーションと統合された現在のエンタープライズアプリケーションに、多くのメリットをもたらします。CDMの主なメリットは次のとおりです。

複数のシステム間でのデータ変換作業を削減

たとえば、相互接続が必要な3つの異なるシステム(X、Y、Z)があるとします。この場合、XからY、YからZ、XからZへのデータ変換と最大で6回のデータ変換が必要になります(逆方向のデータ変換も考慮する必要があります)。CDMを使用している場合も、データ変換の回数は最大で6回です。

しかし、接続システムの数がさらに増えると、CDMを使用していない場合にはデータ変換の実行回数がさらに増えることになります。そのため、CDMを使用することでデータ変換の回数と管理の負担を軽減できます。

システム間のデータの一貫性と通信が改善

CDMは、各システムのデータモデルに関係なく標準となるデータモデルを提供します。この標準化により、次のようなデータ要素の一貫性を確保できるようになります。

• データ形式
• 定義
• 構造

さらに、データの品質が向上するため、ビジネス上の意思決定が改善されます。また、将来的に別のシステムが追加で統合されても、システム間の通信の一貫性が維持されます。

柔軟性とビジネスの俊敏性が向上

CDMは、統合されたアプリケーションやシステムから独立しているため、新しいコンポーネントを簡単に統合できます。そのため組織は、複雑さや統合コストを抑えながら運用を拡大できます。さらに、この柔軟性により、ビジネスニーズの変化にすばやく対応できるようになり、企業の対応能力、ビジネスレジリエンス、および俊敏性が向上します。

変換の管理が容易

CDMがもたらすもう1つの重要なメリットは、変換の管理に必要な労力が軽減されることです。たとえば、ある統合システムのリプレース、削除、または更新が必要になったとします。CDMがなければ、そのシステムに接続しているすべてのシステムでデータの変換を確認しなければならず、コストと時間がかかります。

これに対し、接続システム間でCDMを利用すれば、そのCDMとの間のデータ変換をチェックするだけで済むため、統合の管理が容易になります。

ビジネスロジックの管理が容易

CDMは、データ変換の管理だけでなく、統合システム間のロジックの管理も容易にします。統合環境に変更があると、既存のデータモデルとロジック間の依存関係を確認しなければなりません。その後、必要に応じてロジックの変更が必要になります。しかし、そのロジックがCDMで使用されていれば、システムに変更があっても、統合レイヤーのビジネスロジックを変更する必要はありません。

CDMの例

CDMは、さまざまな業界で、複数の異なるアプリケーションやシステムのデータ通信と標準化に使用されています。現在使用されているCDMの一般的な例は、次のとおりです。

Health Level Seven (HL7)の臨床文書アーキテクチャ(CDA)

病院や医療研究所などの医療機関は、患者登録、患者追跡、病歴、支払いなどに使用するシステムを所有しています。HL7は、異なる医療アプリケーション間で電子カルテをやり取りするための共通のメッセージ形式を定義した標準規格です。最新の標準規格には、HL7 V2、V3、FHIR、CDAなどのプロトコルがあります。

臨床文書アーキテクチャ(CDA)は、XMLベースの主要な標準規格の1つで、臨床文書のエンコーディング、構造、およびセマンティクスを規定しています。これには、病歴、退院情報、患者固有の医療レポートなどの臨床情報を含めることができます。

Microsoft Common Data Model (CDM)

CDMが登場するまで、Microsoftアプリケーション間の通信はアプリケーションごとに行われ、統合の管理が難しく費用もかかるなど、全体的に困難な作業でした。Microsoft CDMは、このような複雑さを軽減し、さまざまなMicrosoftアプリケーション間の連携を可能にするために導入されました。

たとえば、Microsoft Dynamics 365では、データが同じでも、バージョンによってその保存方法や処理方法が異なります。CDMを使用すれば、2つの異なるバージョンのアプリケーションが、それぞれ独自の方法でデータを照合しながらも、アプリケーション間で簡単に情報をやり取りできるようになります。

OpenTravel Alliance (OTA)のデータモデル

OTAが定義している共通のメッセージ形式は、旅行業界、観光業界、接客業のシステム間でデータをやり取りするためのもので、ホテル、航空会社、鉄道会社、クルーズ船会社、流通や物流の会社で使用されています。これらの企業は、OTAを使用することで、自社の電子システム間の相互運用性を強化できます。

たとえば、OTAの業界標準のXMLスキーマにより、航空会社は電子チケットを別の航空会社のシステムに自動で移行できます。このCDMは、チケットの価格や予約などのデータをやり取りできるようにした標準形式のXMLスキーマです。2016年にリリースされたOpenTravel 2.0からは、JSONメッセージと既存のXMLメッセージのやり取りが可能になりました。

Open Geospatial Consortium (OGC)のデータモデル

OGCは、地理情報システム(GIS)アプリケーション間で地理空間データをやり取りするための標準規格を定義しています。このCDMでは、ポイント、ライン、ポリゴンなどの形式で地理情報をやり取りできます。また、エネルギー、公益事業、航空、緊急時対応、災害管理といった他の業界でも、システムの相互運用性を高めるために使用されています。

CDMの導入方法

CDMの構築にあたっては、業界の理解からデータマッピングによるCDMの導入まで、いくつかのステップが必要になります。以下のステップでは、組織がゼロからCDMを構築する方法を一般的な例を使用して説明します。

1. 接続システムについて理解する

まず、接続関係を把握することから始めます(ここでCMDBが役立つ場合があります)。たとえば、小売業界の企業が顧客の注文データをやり取りするためのCDMを構築する場合は、顧客データを保存および処理する接続システムやアプリケーションについて把握する必要があります。

さらに、それらのシステム内のワークフローを確認します。

2. 接続システムのデータソースを特定する

各システムが顧客の注文データをどのように保存しているか、どのようなデータタイプや関係性が存在しているか、どのような構造や形式で情報が保存されているかを知る必要があります。このステップにより、異なるシステム間で保持されている共通のデータを特定できます。

3. CDMを定義する

2つ目のステップを完了したら、次のステップとして、すべての接続システムに対応できる標準のデータタイプ、構造、関係性を考慮してCDMを定義します。

4. データをマッピングする

次に、接続システムのすべてのデータとそれらの関係性を、CDMにマッピングします。

5. CDMとの変換機能を構築する

最後に、各システムのデータモデルをCDMに変換したり、その逆の変換を行ったりするためのCDMとデータ変換機能を構築します。

規範となるデータモデル

カノニカルデータモデルは、データのタイプ、構造、関係性、およびルールの標準化されたセットを持つデータモデルであり、特定のアプリケーションに一切依存しません。これにより、統合されたアプリケーションやシステム間でのデータのやり取りが容易になり、テクノロジーの違いに関係なく、相互運用が可能になります。

統合するコンポーネントは、この共通形式でメッセージを作成し、そのメッセージを変換して、それぞれの必要な形にする必要があります。CDMは現在、データ変換作業の削減、データの一貫性の向上、統合の柔軟性、ビジネスの俊敏性といった面で、企業に多くの利点をもたらしています。つまり、CDMはデータ変換とビジネスロジックの管理コストの削減に大きく貢献しています。

このブログはこちらの英語ブログの翻訳です。