Common Data Model を紐解く

はじめに

Common Data Model は、すべてのビジネス プロセス間でデータを統合し、アプリ間の相互運用性を実現するための標準化されたデータモデルです。CDM と表記されることがあります。今回は、何かを構成するのではなく、Common Data Model がどのようなものであるかを整理してみたいと思います。

Common Data Model は特別な意味を持っていますが、基本的にはデータモデルですので、どのような実装でもよいのでデータモデリングの経験を持っていると理解しやすくなります。

「イヤイヤ、それではちょっと」とか「もっとこうすればいいよ」などのお気づきの点があればコメントで教えてください。

全体像

Common Data Model は標準化された拡張可能なデータ スキーマのセットです。いわゆる RDBMS に実装されるようなデータの設計情報ととらえることもできますし、アプリケーションにおけるクラス等のオブジェクト モデルとも似ています。このスキーマのセットには以下のような要素が含まれています。

エンティティ (Entity) と属性 (Attribute)

エンティティは Common Data Model の主要なオブジェクトです。エンティティは物理的なモノ、場所、相互作用、個人などを表します。データ1件1件の構造と意味が記述されています。RDBMS であればテーブル=エンティティとも言えます。
属性はエンティティ内の個々のデータ項目を表します。RDBMS であればデータ列とも言えます。

セマンティック メタデータ (Semmantic metadata)

直訳すると意味的な概念データとなりますが、ざっくりとデータモデルを説明するデータと理解するとよいかと思います。正確ではないのですが、RDBMS のテーブルや列に対して付与された説明 (description) と理解しておくのがこの時点ではよいかと思います。

リレーションシップ (Relationship)

リレーションシップは、エンティティとエンティティの関係性を定義します。あるエンティティのこの属性は、別のエンティティの属性を参照している、のように属性を利用して定義されています。RDBMS では外部参照のようにリレーションシップが実装されています。

なんとなく RDBMS っぽいけど、本当にそうなの？

ここまで、RDBMS であれば、という感じで RDBMS を前提に整理をしてきましたが、実際に Common Data Model を見てみると、RDBMS ではちょっと説明しづらい要素が出てきます。もしかしたら、オブジェクト指向におけるクラス設計として見た方がしっくりくるかもしれません。例えば、以下の要素は RDBMS のテーブルでは表現することが難しくなります。

エンティティ拡張

Common Data Model においては、あるエンティティを再利用して、新たなエンティティを定義することができます。例えば、人というエンティティを拡張してエンジニアというエンティティを定義することを想定します。

この後のエンティティの表記は実際の表記とは異なっていますので、そのまま Common Data Model の一部として利用することはできません。

エンティティ名:人
{要素名:氏名, データの形式:文字列}
{要素名:マイナンバー, データの形式:文字列}

エンティティ名:エンジニア (エンティティ:人の拡張)
{要素名:経験年数, データの形式:数値}

エンジニア エンティティは人エンティティを拡張することによって、人エンティティが持つ「氏名」と「マイナンバー」の属性に加えて、「経験年数」という属性を持たせることができます。

データの形式としてのエンティティ

エンジニア エンティティに、上司を表す属性を追加することを考えます。上司は人であり、場合によってはエンジニアかもしれません。ここでは単純化するために人であることを想定して、上司属性を追加してみます。

エンティティ名:エンジニア (エンティティ:人の拡張)
{要素名:経験年数, データの形式:数値}
{要素名:上司, データの形式:人エンティティ}

Common Data Model では、このようにエンティティの属性が持つデータの形式としてエンティティを指定することができます。

読んでみる

ここまでで Common Data Model を少しだけ整理してみました。では、ここまでの知識を利用して、Common Data Model そのものを読んでみたいと思います。

Common Data Model のリポジトリ

Common Data Model はオンライン上のドキュメントとして整理され、Github 上で管理および公開されています。Github リポジトリ上には、単なるドキュメントだけではなく、データモデルを閲覧するツールなども併せて公開されています。

エンティティの参照

それでは、エンティティを実際に参照してみましょう。Github リポジトリにアクセスしたら Entity Reference Index を開きます。

Github リポジトリのトップページからご自身で Entity Reference Index へのリンクを探していただくこともできますし、下記のリンクを踏んでいただいてもよいと思います。
https://github.com/microsoft/CDM/blob/master/schemaDocuments#directory-of-cdm-entities

エクスプローラー風の画面が出てくるのですが、「どこから触ればよいのやら」という気持ちになるかもしれません。

最初に開かれている schemaDocuments フォルダー内の多くのファイルは、前述のセマンティック メタデータです。このファイル群の意味、読み解き方は次の機会に持ち越したいと思いますので、ここでは気にせず置いておくことにします。

[schemaDocuments]→[core]→[applicationCommon] の順に、左ペインのエクスプローラーを展開してみましょう。

Account.*.cdm.json というファイル群が出てきます。これらのファイルは Account エンティティの定義情報です。ここでは、最新バージョンである Account.cdm.json を開いてみます。

最新バージョンも含め、エンティティ名.バージョン番号.cdm.json というファイル群が存在していますが、最新バージョンは、エンティティ名.cmd.json ファイルからも参照できます。

右ペインに JSON で定義された Account エンティティの情報が表示されます。1 エンティティではありますが、JSON 構造で 5000 行を越えているのでなかなかの分量です。

主要な要素

ここでは主要な JSON 要素に触れてみたいと思います。

エンティティ名

割と頭の方に entityName として定義されています。Account エンティティのファイルを開いたので、Account と記述されています。

属性のリスト

エンティティ自体のメタデータを通り過ぎた後に、属性が定義されています。
hasAttributes 要素の中が属性となります。

この例では、これまでに説明していない属性グループが出てきているため、やや複雑になっています。

属性

今回の例では、属性グループのメンバーとして各属性が定義されています。
例えば、一つ目の属性は accountId です。レコードを識別するのに使用され、データ形式が ID であることが明示され、必須項目になっています、等々の定義が記述されています。

細かい要素については何も解説していませんので、この時点では雰囲気で読み解いていく感じです。適切にモデルを理解していくには、もう少しどのような JSON 要素があるかを見ておいた方がよさそうですね。

まとめ

今回は Common Data Model を紐解く最初の一歩として、概要レベルでの理解を深めることを目的として、Common Data Model とは何かを解説し、実際の定義を読み解いてみました。

技術的な複雑さというよりも、読み解くうえで理解しておいた方がよさそうなルールが沢山あるところが Common Data Model の難しいポイントかなと思います。一方で、一つずつ理解してしまえば、あとは世の中の何かをデータモデル化してあるものとして捉えていくことができるかなと思います。

今時点の予定では、あと2-3記事位に分けて、CDM を紐解いていきたいなと思っています。