CIMフォーマット

クラウド情報モデル (CIM) は、顧客、注文、製品、アカウント、およびそれらの間の関係といったビジネス概念の、標準ベースでアプリケーションに依存しないモデルとして最初から設計されました。ただし、概念モデルは、それを必要とするシステムが実際にそれを利用できる場合にのみ役立ちます。そのため、CIM は単一の独自の成果物としてではなく、シリアル化 (serializations) のファミリーとして公開されており、それぞれが異なるクラスのツール、ランタイム、および対象ユーザーを対象としています。

このページでは、各 CIM 形式とは何か、その用途、およびその選択方法について説明します。あなたがエンタープライズ データ アーキテクト、統合または ETL エンジニア、アプリケーションまたはプラットフォーム ベンダー、またはオープンソース コントリビュータである場合、最初に選択する形式は、パイプラインのどこに位置するかによって異なります。

重要なポイント

• CIM は 2 つのファミリーで配布されています。セマンティック Web 形式 (JSON-LD, RDF Schema, SHACL, R2RML) と、人間が読める/リレーショナル形式 (AML vocabulary, AML dialect, RAML types, JSON Schema, SQL DDL) です。
• 概念モデル (concepts.*) はエンティティと関係を記述し、正規スキーマ (schema.*) はデータの形状と制約を記述します。これらは、別々の目的を持つ別々の成果物です。
• JSON-LD は正規の機械可読形式であり、AML は同じコンテンツを人間が読める形式で表現したものです。SQL DDL と JSON Schema は、ほとんどのアプリケーション チームと ETL チームが直接利用する形式です。
• R2RML はブリッジの役割を果たします。リレーショナル スキーマを RDF グラフにマッピングし、これにより既存の SQL データベースをセマンティック レイヤーに接続します。
• 形式の選択は、好みではなく 消費者の問題 です。ターゲットとなるツールチェーンがネイティブに取り込める形式を選択し、他の形式はクロスチェックとして使用してください。

CIM が複数の形式で提供される理由

ほとんどのデータ モデルは、通常は ER 図、スプレッドシート、またはベンダー固有のメタデータ ファイルなど、たった 1 つの形式で公開されます。これは、異なるスタックを使用する組織間でモデルを共有する必要がない限りは機能します。例えば、小売プラットフォームでは PostgreSQL と dbt が動作し、パートナーはグラフ データベースとトリプル ストアを運用し、SaaS ベンダーは JSON API を公開して JSON Schema でペイロードを検証しているかもしれません。共有モデルがこれらの方言の 1 つでしか存在しない場合、他の全員がそれを翻訳しなければならず、その結果、翻訳に乖離が生じます。

CIM のマルチフォーマット戦略は、この問題に対する意図的な答えです。モデルは一度作成され、その後 認められた標準にきれいにマッピングされる形式に変換 されるため、各消費者は既に所有しているツールを使用して CIM を採用できます。これは、CIM が再発明するのではなく再利用している RDF、SHACL、R2RML などの仕様を公開している World Wide Web Consortium (W3C) などの標準化団体と同じ哲学です。また、CIM プロジェクトが運営されている Linux Foundation のより広範な相互運用性の使命とも一致しています。

実用的な利点は 2 つあります。さまざまなテクノロジーを使用する企業は、既存システムを完全に置き換えることなく CIM を導入でき、コントリビュータは他のシリアル化が再生成可能であることを前提に、自身の専門知識に合った形式でモデルを拡張できます。

概念モデル vs. 正規スキーマ

ファイル形式を比較する前に、CIM が明確に区別している 2 つのレイヤーを分けて考えることが役立ちます。これらは初心者が混同しがちな点です。

関連: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

• 概念モデルは、「何が存在し、それがどのように関係しているか」に答えます。エンティティ (顧客、注文、製品)、それらの属性、およびそれらの間の関係を定義します。意図的にビジネス用語に近づけ、物理的な詳細はあえて最小限に抑えています。
• 正規スキーマは、「有効なインスタンスがどのようなものであるか」に答えます。システムが検証可能なデータの形状と制約 (カーディナリティ、型、必須フィールド、値の範囲) を追加します。

CIM の配布物では、これらは 2 つのファイル名ステムにマッピングされます。概念レイヤーには concepts.*、正規レイヤーには schema.* です。これらを分離しておくことで、ビジネス アナリストは制約構文に惑わされることなく概念モデルを読み取ることができ、エンジニアは完全な概念的な説明を必要とせずにスキーマに対してペイロードを検証できます。

セマンティック Web フォーマット

これらの形式は、CIM を RDF ベースのグラフとして表現します。消費者にトリプル ストア、ナレッジ グラフ、オントロジー ツール、またはリンクされたデータを推論するシステムが含まれている場合に最適な選択肢となります。

JSON-LD — concepts.json および schema.json

JSON-LD はリンクされたデータ コンテキストを備えた JSON であり、通常の Web API とセマンティック Web の間の実用的なブリッジとなります。CIM は 2 つの JSON-LD 成果物を公開しています。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

• concepts.json — RDF Schema として表現された、エンティティと関係の概念的な説明。
• schema.json — SHACL で表現された正規のデータ形状と追加の制約。

有効な JSON であるため、concepts.json と schema.json は通常の JSON ツールでロードできますが、@context を保持しているため、完全な RDF トリプルにも展開されます。この二重の性質により、最初から特殊な RDF スタックを採用せずにセマンティックな忠実性を求めるチームにとって、JSON-LD はしばしば最適なデフォルトとなります。

RDF Schema — schema.json

RDF Schema (RDFS) は、クラスとプロパティを記述するための語彙、つまり rdfs:Class、rdfs:subClassOf、および rdfs:domain/rdfs:range 構造を提供します。これにより、マシンは「注文はビジネス ドキュメントの一種である」ことや、「その顧客プロパティが顧客エンティティを指している」ことを理解できます。CIM は RDFS を使用して概念モデルに形式的なセマンティクスを与え、サブクラス階層やプロパティ ドメインを単に文書化するだけでなく、機械的に解釈可能にします。

SHACL — schema.json

Shapes Constraint Language (SHACL) は、シェイプと呼ばれる一連の条件に対して RDF グラフを検証するための W3C 標準です。RDFS がクラスとは 何か を示すのに対し、SHACL は有効なインスタンスが 満たさなければならないもの（必須のプロパティ、許可される値の型、カーディナリティの制限）を示します。CIM の正規データ形状（canonical data shapes）は SHACL で表現されます。つまり、どのような SHACL プロセッサでもカスタムコードなしで CIM 準拠のデータを検証できます。

R2RML — schema.rdml

R2RML は、リレーショナルデータベーススキーマを RDF グラフにマッピングするための W3C 標準です。これは、テーブル、列、外部キーを持つ既存の SQL データベースを CIM 準拠のリンクデータとして公開するメカニズムであるため、統合エンジニアや ETL エンジニアにとって最も重要な形式です。運用データベースを手動で再モデル化するのではなく、各テーブルと列が CIM エンティティとプロパティにどのように対応するかを宣言する R2RML マッピングを作成（または生成）します。その結果、既存のリレーショナルデータ上の仮想 RDF グラフが作成されます。

人間が読める形式とリレーショナル形式

すべての消費者が RDF を望んでいるわけではありません。アプリケーション開発者、データモデラー、DBA は、多くの場合、テキストエディタで読んだり、データベースに直接読み込んだりできるものを望んでいます。CIM は、AML、RAML、JSON Schema、および SQL DDL シリアル化を提供することでこれらに対応しています。

AML — concepts.yaml, schema.yaml, schema.raml

ここでモデリング方言として使用されている AnyLogic Modeling Language 系統の AML は、人間が読める CIM の表現です。CIM は 3 つの AML アーティファクトを公開します：

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

• concepts.yaml — AML 語彙（vocabulary）。概念モデルの人間が読めるバージョンです。
• schema.yaml — AML 方言（dialect）。正規データ形状の人間が読めるバージョンです。
• schema.raml — 正規形状を RAML データ型でレンダリングしたもの。

語彙 と 方言 の区別を理解しておくことは重要です。語彙は用語（モデルの名詞と動詞）を定義し、方言はそれらの用語がどのように組み合わされて有効な構造になるかを定義します。初めて CIM をレビューする場合、通常は concepts.yaml が最も親しみやすいエントリポイントになります。

JSON Schema — schema.json

JSON Schema は JSON ドキュメントを検証するための事実上の標準であり、ほぼすべての現代的な言語でネイティブに、あるいはライブラリ経由でサポートされています。CIM の JSON Schema アーティファクトは、正規データ形状を JSON Schema として表現するため、すでに JSON ペイロードを検証している API ゲートウェイ、メッセージブローカー、CI パイプラインで直接利用可能です。統合インターフェースが REST またはイベント駆動型 JSON である場合、多くの場合この形式が最適です。

SQL DDL — schema.sql

SQL DDL は、リレーショナルデータベース内で正規形状を具体化するための CREATE TABLE、CREATE VIEW、および制約ステートメントのセットです。CIM は SQL 2008 構文をターゲットにしており、主要なリレーショナルエンジン間で DDL の移植性を維持しています。これは、DBA や ETL エンジニアが CIM に準拠する物理スキーマ（例えば、正規モデルをミラーリングするステージングまたは統合データベース）を構築したいときに使用する形式です。

ショッピングの場合: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

フォーマットの選択：実践ガイド

単一の「正しい」形式はありません。適切な選択は、次に誰が、あるいは何がモデルを消費するかによって決まります。以下の表を意思決定の補助として使用してください。

消費者が…の場合	まずは…から	理由…
モデルをレビューするビジネスアナリストまたはデータモデラー	AML 語彙 (concepts.yaml)	人間が読める、ビジネス語彙優先
トリプルストア、ナレッジグラフ、またはオントロジーツール	JSON-LD (concepts.json, schema.json)	JSON オンランプを備えたネイティブ RDF
SHACL バリデータまたはセマンティックデータ品質パイプライン	SHACL (schema.json)	RDF 上の標準的な制約検証
リンクデータとして公開したい既存のリレーショナルデータベース	R2RML (schema.rdml)	再モデル化せずにテーブル/列を CIM エンティティにマップ
REST またはイベント駆動型の JSON API	JSON Schema (schema.json)	JSON ペイロードを直接検証
CIM に準拠させたいリレーショナルデータベース	SQL DDL (schema.sql)	移植可能な SQL 2008 DDL
RAML で記述された API	RAML 型 (schema.raml)	RAML ツールチェーンにネイティブ

いくつかの実践的な注意点：

• 各形式を独立したモデルとして扱わないでください。 これらはすべて、同じ基礎となる CIM のシリアル化です。例えば、schema.json (JSON Schema) と schema.json (SHACL) の間に不一致がある場合、それは設計上の選択ではなく、バグまたはバージョンの乖離です。報告してください。
• ファイル名の衝突に注意してください。 いくつかの形式は、異なる拡張子 (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml) を持ちながら schema という共通のステムを持っています。フルディストリビューションをダウンロードする際は、あるシリアル化を別のシリアル化で上書きしないよう、フォーマットごとのディレクトリを分けて管理してください。
• 検証段階に合わせて形式を選択してください。 設計時のレビューには概念的な形式を、実行時の検証には正規の形式を使用してください。概念モデルに対する検証は、制約が欠けているため意味がありません。
• 手動編集よりも生成を優先してください。 CIM を拡張する場合は、各形式を手動で編集するのではなく、ソースを拡張して他のシリアル化を再生成してください。そうしないと、各形式の間で同期がずれてしまいます。

完全な CIM ディストリビューションのダウンロード

CIM は、利用可能な各形式の完全な定義として配布されているため、モデルを断片的に組み立てるのではなく、必要なシリアル化でモデル全体をプルダウンできます。公開されているダウンロードオプションは次のとおりです：

• AML (vocabulary) — 人間が読める概念モデル。
• AML (dialect) — 人間が読める標準形状（canonical shapes）。
• JSON-LD (vocabulary & schema) — 機械可読なセマンティックモデル。
• R2RML — リレーショナルからRDFへのマッピング。
• RAML Types — RAMLデータ型としての標準形状。
• SQL DDL — 移植可能なSQLとしての標準形状。

各ダウンロードには、その形式での完全なCIM定義が含まれています。つまり、CIMを段階的に導入することが可能です。現在のツールチェーンがサポートする形式から始めて、相互運用性のニーズが高まるにつれて他の形式を追加してください。

フォーマットをまたいだ貢献について

CIMはオープンプロジェクトであるため、貢献を歓迎しています。また、マルチフォーマット構造が貢献の仕組みを規定しています。貢献者は通常、次の2つのグループに分かれます：

• モデル貢献者：新しいエンティティ、関係、または制約を提案します。これらの変更は一度作成され、その後他のシリアル化形式に伝播されます。
• フォーマット貢献者：特定のシリアル化の忠実度やツールを改善します。例えば、R2RMLマッピングの洗練やSQL DDLの移植性の向上などです。

貢献する場合の実践的なルールは、自分がどのレイヤー（概念的か標準的か）を変更しているのか、およびその結果としてどの形式を再生成する必要があるのかを理解することです。プロジェクトのGitHubリポジトリとコントリビューター用Webフォームが、参加するためのエントリーポイントとなります。

よくある質問

CIMにおける concepts.json と schema.json の違いは何ですか？

concepts.json は概念モデルであり、CIM内のエンティティと関係をRDF Schemaセマンティクスを持つJSON-LDとして表現したものです。schema.json は標準スキーマであり、データ形状と追加の制約をSHACLセマンティクスを持つJSON-LDとして表現したものです。簡単に言えば、concepts は「何が存在するか」を記述し、schema は「有効なインスタンスがどのような姿であるべきか」を記述します。

なぜCIMは同じモデルをこれほど多くの形式で公開しているのですか？

利用者によって使用するテクノロジーが異なるためです。トリプルストアにはRDFが必要であり、JSON APIにはJSON Schemaが必要で、DBAにはSQL DDLが必要であり、ビジネスアナリストには人間が読める形式が必要です。CIMを複数の標準形式で公開することで、単一のスタックを全員に強制するのではなく、各ユーザーがすでに持っているツールを用いてモデルを採用できるようになります。

CIMにおいてR2RMLは何に使用されますか？

R2RMLは、リレーショナルデータベーススキーマをRDFグラフにマッピングするためのW3C標準です。CIMにおいて、これは既存のSQLデータベースをCIM準拠のリンクドデータとして公開するためのブリッジとなり、運用中のリレーショナルシステムを手動で再モデリングすることなくセマンティックレイヤーに接続することを可能にします。

AMLはJSON-LD形式と同じものですか？

いいえ。AMLはCIMの人間が読める表現であり、語彙 (concepts.yaml) と方言 (schema.yaml, schema.raml) を指します。JSON-LDは機械可読なRDFベースの表現です。これらは同じモデルを記述していますが、対象とする読者とツールチェーンが異なります。

どのCIM形式から始めるべきですか？

利用目的に依存します。モデルをレビューする場合は、AML語彙から始めてください。JSON APIを構築する場合は、JSON Schemaから始めてください。リレーショナルデータベースに接続する場合は、R2RMLまたはSQL DDLから始めてください。ナレッジグラフを扱う場合は、JSON-LDとSHACLから始めてください。

他のCIM形式を更新せずに、1つの形式だけを編集できますか？

可能ですが、推奨されません。これらの形式は1つの基礎となるモデルのシリアル化であるため、単一の形式を手動で編集すると、形式間の同期がずれてしまいます。代わりにソースモデルを拡張し、他のシリアル化形式を再生成してください。

さらに詳しく

• World Wide Web Consortium (W3C) — CIMがベースとしている仕様であるRDF、RDF Schema、SHACL、およびR2RMLを策定している標準化団体。
• Shapes Constraint Language (SHACL) — CIMの標準データ形状に使用されている制約言語に関する背景情報。
• Linux Foundation — CIMプロジェクトが運営されている財団。