Show Menu
トピック×

スキーマ組成の基本

このドキュメントでは、Experience Data Model(XDM)スキーマと、Adobe Experience Platformで使用するスキーマを構成するための構成要素、原則およびベストプラクティスを紹介します。 XDMの一般的な情報とプラットフォームでのXDMの使用方法については、 XDMシステムの概要を参照してください

スキーマについて

スキーマは、データの構造と形式を表し、検証する一連のルールです。 高いレベルで、スキーマは現実世界のオブジェクト(人など)の抽象的な定義を提供し、そのオブジェクトの各インスタンスに含めるデータ(名、姓、誕生日など)の概要を示します。
スキーマは、データの構造に加えて、制約や期待をデータに適用し、システム間を移動する際に検証できるようにします。 これらの標準の定義により、接触チャネルに関係なく一貫した形でデータを解釈でき、複数のアプリケーション間での翻訳を必要としなくなります。
Experience Platformは、スキーマを使用して、このセマンティックの正規化を維持します。 スキーマは、Experience Platformのデータを記述する標準的な方法で、スキーマに準拠するすべてのデータを組織全体で競合なく再利用可能にし、複数の組織間で共有可能にすることができます。

リレーショナルテーブルと埋め込みオブジェクト

リレーショナルデータベースを扱う場合、ベストプラクティスでは、データの標準化、またはエンティティの取得と分割を個別の部分に分割し、複数のテーブルに表示します。 データ全体を読み取る、またはエンティティを更新するために、読み取り/書き込み操作は、JOINを使用して、多くの個々のテーブルに対して行う必要があります。
XDMスキーマは、埋め込みオブジェクトを使用することで、複雑なデータを直接表現し、階層構造を持つ独立したドキュメントに格納できます。 この構造の主な利点の1つは、複数の非正規化テーブルへの高価な結合によってエンティティを再構築することなく、データをクエリできる点です。

スキーマとビッグデータ

最新のデジタルシステムは、大量の行動信号(トランザクションデータ、ウェブログ、物のインターネット、表示など)を生成します。 この大規模なデータオファーは、エクスペリエンスを最適化する非常に大きな機会ですが、データの規模と種類が大きいので使用が困難です。 データから値を取得するには、一貫性と効率性を持って処理できるように、データの構造、形式および定義を標準化する必要があります。
スキーマは、複数のソースからデータを統合し、共通の構造と定義を通じて標準化し、ソリューション間で共有することで、この問題を解決します。 これにより、後続のプロセスやサービスは、データに関する質問に対して、従来のデータモデリングアプローチとは異なり、データに関する質問を事前に把握し、データを期待に沿ってモデル化します。

Experience Platformのスキーマベースのワークフロー

標準化は、エクスペリエンスプラットフォームの背後にある主要な概念です。 XDMは、アドビが推進する機能で、カスタマーエクスペリエンスデータを標準化し、カスタマーエクスペリエンス管理の標準的なスキーマを定義する取り組みです。
Experience Platformが構築されるインフラストラクチャは、XDM Systemと呼ばれ、スキーマベースのワークフローを容易にし、スキーマレジストリ、スキーマエディター、スキーマメタデータ、サービス消費パターンを含みます。 See the XDM System overview for more information.

スキーマの計画

スキーマを構築する最初の手順は、スキーマ内で捕捉しようとする概念、つまり現実世界のオブジェクトを決定することです。 説明しようとしている概念を特定したら、データの種類、潜在的なIDフィールド、将来のスキーマの発展について考えることで、スキーマの計画を始めることができます。

エクスペリエンスプラットフォームでのデータ動作

エクスペリエンスプラットフォームでの使用を意図したデータは、次の2つの動作タイプに分類されます。
  • Record data : 件名の属性に関する情報を提供します。 件名は、組織または個人にすることができます。
  • 時系列データ : レコードの件名によって直接または間接的にアクションが実行された時点のシステムのスナップショットを提供します。
すべてのXDMスキーマは、レコードまたは時系列として分類できるデータを記述します。 スキーマのデータ動作は、スキーマの クラス (最初に作成されたときにスキーマに割り当てられる)によって定義されます。 XDMクラスについては、このドキュメントで後述します。
レコードと時系列の両方のスキーマには、IDのマップ( xdm:identityMap )が含まれます。 このフィールドには、次のセクションで説明するように、「ID」とマークされたフィールドから描画される、件名のID表現が含まれます。

ID

スキーマは、データをエクスペリエンスプラットフォームに取り込むために使用されます。 このデータは、複数のサービスで使用して、個々のエンティティの単一の統合表示を作成できます。 したがって、「ID」について考える際は、スキーマを考える際に重要です。データの送信元に関係なく、どのフィールドを使用して件名を特定できるかを考慮する必要があります。
この処理に役立つように、主要フィールドを「ID」としてマークすることができます。 データ取り込み時に、これらのフィールドのデータが個々の「アイデンティティグラフ」に挿入されます。 グラフデータは、 リアルタイム顧客プロファイル 、およびその他のエクスペリエンスプラットフォームサービスによってアクセスされ、個々の顧客の関連付けが完了した表示を提供できます。
「ID」として一般的にマークされるフィールドには、次のものがあります。 電子メールアドレス、電話番号、 Experience Cloud ID(ECID) 、CRM IDまたはその他の一意のIDフィールド。 また、「ID」フィールドとしても適切な場合があるので、組織に固有の一意の識別子も考慮する必要があります。
スキーマ計画段階で顧客のIDを考えて、最も堅牢なプロファイルを構築するためにデータを統合できるようにすることが重要です。 ユーザーにデジタルエクスペリエンスを提供する際にID情報がどのように役立つかについて詳しくは、 IDサービスの概要 (英語)を参照してください。

スキーマ進化の原則

デジタルエクスペリエンスの本質が進化し続けるにつれて、スキーマがデジタルエクスペリエンスを表現する必要があります。 したがって、適切に設計されたスキーマは、スキーマの以前のバージョンに破壊的な変更を加えることなく、必要に応じて適応し、進化することができます。
下位互換性の維持はスキーマの発展にとって重要なので、Experience Platformでは、完全に加算的なバージョン管理原則を適用して、スキーマに対するすべてのリビジョンが非破壊的な更新と変更の結果にのみなるようにします。 つまり、変更の 破棄はサポートされていません。
サポートされる変更
変更の破棄(未サポート)
  • 既存のスキーマへの新しいフィールドの追加
  • 必須フィールドのオプション化
  • 以前に定義したフィールドの削除
  • 新しい必須フィールドの紹介
  • 既存のフィールドの名前の変更または再定義
  • 以前サポートされていたフィールド値の削除または制限
  • ツリー内の別の場所への属性の移動
スキーマがまだデータをExperience Platformに取り込むのに使用していない場合は、そのスキーマに画期的な変更が加わる可能性があります。 ただし、スキーマをプラットフォームで使用した後は、追加のバージョン管理ポリシーに従う必要があります。

スキーマとデータの取り込み

データをExperience Platformに取り込むには、まずデータセットを作成する必要があります。 データセットは、 Catalog Service (カタログサービス)のデータ変換と追跡の基礎となる要素であり、一般に、取り込んだデータを含むテーブルやファイルを表します。 すべてのデータセットは既存のXDMスキーマに基づいており、取り込むデータの内容と構造化方法に制約があります。 詳しくは、 Adobe Experience Platform Data Ingestの概要を参照してください

スキーマの構成要素

Experience Platformでは、標準の構築ブロックを組み合わせてスキーマを作成する組版アプローチを使用します。 このアプローチは、既存のコンポーネントの再利用を促進し、プラットフォームのベンダーのスキーマとコンポーネントをサポートするために、業界全体の標準化を推進します。
スキーマは次の式を使用して構成されます。
Class + Mixin* = XDMスキーマ
*スキーマは、クラスと 0個以上の mixinで構成されます。 つまり、ミックスインをまったく使用せずにデータセットスキーマを作成できます。

クラス

スキーマの構成は、クラスの割り当てから始まります。 スキーマに格納されるデータ(レコードまたは時系列)の行動面を定義するクラスです。 このクラスに加えて、そのクラスに基づくすべてのスキーマが必要とする最小の共通プロパティを記述するクラスもあります。これにより、互換性のある複数のデータセットをマージする手段が提供されます。
また、クラスは、スキーマでどのミックスインを使用できるかを決定します。 この点については、後述の mixin 節で詳しく説明します。
「業界」クラスと呼ばれる、エクスペリエンスプラットフォームのすべての統合で提供される標準クラスがあります。 業界クラスは、一般的に認められる業界標準で、広範な使用例に適用されます。 Industryクラスの例としては、アドビが提供するXDM IndividualプロファイルとXDM ExperienceEventクラスがあります。
Experience Platformでは、「ベンダー」クラスも使用できます。「ベンダー」クラスは、エクスペリエンスプラットフォームパートナーによって定義され、プラットフォーム内でそのベンダーサービスまたはアプリケーションを使用するすべての顧客が利用できます。
また、プラットフォーム内の個々の組織に対して、より具体的な使用例を説明するために使用される「顧客」クラスもあります。 顧客クラスは、一意の使用例を説明するためのIndustryクラスまたはVendorクラスがない場合に、組織によって定義されます。
例えば、忠誠度プログラムのメンバーを表すスキーマは、個人に関するレコードデータを記述するので、XDM Indivustryクラス(Adobeが定義する標準的なIndustryクラス)に基づくことができます。

Mixin

ミックスインは、個人の詳細、ホテルの環境設定、住所などの特定の機能を実装する1つ以上のフィールドを定義する再利用可能なコンポーネントです。 ミックスインは、互換性のあるクラスを実装するスキーマの一部として含めることを意図しています。
ミックスインは、表すデータ(レコードまたは時系列)の動作に基づいて、互換性のあるクラスを定義します。 つまり、すべてのクラスで使用できるミックスインがあるわけではありません。
ミックスインは、クラスと同じスコープと定義を持ちます。 プラットフォームを使用する個々の組織で定義される業界ミックスイン、ベンダーミックスイン、および顧客ミックスインがあります。 エクスペリエンスプラットフォームには多くの標準的な業界ミックスインが含まれていますが、ベンダーはユーザーのミックスインを定義でき、個々のユーザーは独自の概念のミックスインを定義できます。
例えば、「忠誠度メンバー」スキーマの「名」や「ホームアドレス」などの詳細を取り込むには、これらの共通概念を定義する標準的なミックスインを使用できます。 ただし、あまり一般的でない使用例に特有の概念(「忠誠度プログラムレベル」など)には、多くの場合、事前定義済みのミックスインがありません。 この場合、この情報を取り込むには、独自のミックスインを定義する必要があります。
スキーマは「0個以上」のミックスインで構成されているので、これは、ミックスインを一切使用せずに有効なスキーマを構成できることを意味します。

Data type

データ型は、基本的なリテラルフィールドと同様に、クラスまたはスキーマで参照フィールド型として使用されます。 主な違いは、データ型は複数のサブフィールドを定義できる点です。 mixinと同様、データ型は複数フィールド構造の一貫した使用を可能にしますが、データ型はフィールドの「データ型」として追加することでスキーマ内のどこにでも含めることができるので、mixinよりも柔軟性が高くなります。
Experience Platformは、スキーマレジストリの一部として多数の共通データ型を提供し、一般的なデータ構造を記述するための標準パターンの使用をサポートしています。 これについては、スキーマレジストリのチュートリアルで詳しく説明しています。データ型を定義する手順を実行すると、より明確になります。

フィールド

フィールドは、スキーマの最も基本的な構成要素です。 フィールドには、特定のデータ型を定義することで、フィールドに含めることができるデータの種類に関する制約があります。 これらの基本的なデータ型は1つのフィールドを定義しますが、 前述の データ型では、複数のサブフィールドを定義し、同じ複数フィールド構造を様々なスキーマで再利用できます。 したがって、フィールドの「データ型」をレジストリで定義されたデータ型の1つとして定義するだけでなく、Experience Platformは次のような基本的なスカラー型をサポートしています。
  • 文字列
  • 整数
  • 数値
  • Boolean
  • 配列
  • オブジェクト
これらのスカラー型の有効範囲は、特定のパターン、形式、最小/最大値、または事前定義済みの値にさらに制限できます。 これらの制約を使用すると、以下のような様々な特定のフィールドタイプを表すことができます。
  • 列挙
  • ロング
  • Short
  • バイト
  • 日付
  • 日時
  • マップ
「map」フィールドタイプを使用すると、1つのキーに対する複数の値を含むキーと値のペアのデータを取得できます。 マップはシステムレベルでのみ定義できます。つまり、業界またはベンダー定義のスキーマでマップが見つかる場合がありますが、定義したフィールドでは使用できません。 フィールドの種類の定義について詳しくは、『 スキーマレジストリAPI開発者ガイド 』を参照してください。
ダウンストリームサービスやアプリケーションで使用される一部のデータ操作では、特定のフィールドタイプに制約が適用されます。 影響を受けるサービスには、次のものがあります。
ダウンストリームサービスで使用するスキーマを作成する前に、スキーマが対象とするデータ操作のフィールド要件と制約をより深く理解するために、該当するサービスの適切なドキュメントを確認してください。

XDMフィールド

XDMは、基本的なフィールドと独自のデータ型を定義する機能に加え、Experience Platform Servicesで暗黙的に認識される標準のフィールドとデータ型のセットを提供し、プラットフォームコンポーネント間で使用した場合に一貫性を高めます。
「名」や「電子メールアドレス」などのこれらのフィールドには、基本的なスカラーフィールド型以外の記述が追加され、同じXDMデータ型を共有するすべてのフィールドが同じように動作することをプラットフォームに伝えます。 この動作は、データの送信元や使用されているプラットフォームサービスに関係なく、信頼できるため、一貫性を保つことができます。
使用可能なXDMフィールドの完全なリストについては、 XDMフィールドディクショナリ (XDM field dictionary)を参照してください。 エクスペリエンスプラットフォーム全体での一貫性と標準化をサポートするために、可能な限りXDMフィールドとデータ型を使用することをお勧めします。

組版の例

スキーマは、プラットフォームに取り込まれ、組版モデルを使用して構築されるデータの形式と構造を表します。 前述したように、これらのスキーマは、クラスと、そのクラスと互換性のある0個以上のミックスインで構成されます。
例えば、小売店で行われた購入を説明するスキーマを「店舗トランザクション」と呼ぶことができます。 このスキーマは、標準のコマースミックスインとユーザ定義の製品情報ミックスインを組み合わせたXDM ExperienceEventクラスを実装します。
Webサイトトラフィックを追跡する別のスキーマは、「Web訪問回数」と呼ばれる場合があります。 また、XDM ExperienceEventクラスも実装しますが、今回は標準のWebミックスインを組み合わせます。
次の図に、これらのスキーマと各ミックスインが貢献するフィールドを示します。 また、XDM個々のプロファイルクラスに基づく2つのスキーマも含まれます。これには、このガイドで前述した「Loyalty Members」スキーマが含まれます。

和集合

Experience Platformでは特定の用途向けにスキーマを作成できますが、特定のクラスタイプ向けにスキーマの「和集合」を確認することもできます。 上の図は、XDM ExperienceEventクラスに基づく2つのスキーマと、XDM Indivualプロファイルクラスに基づく2つのスキーマを示しています。 以下に示す和集合は、同じクラス(XDM ExperienceEventとXDM Individualプロファイル)を共有するすべてのスキーマのフィールドを集計します。
スキーマをリアルタイム顧客プロファイルで使用できるようにすると、そのクラスタイプの和集合に含められます。 プロファイルは、堅牢で一元化されたプロファイルの顧客属性に加え、Platformと統合されたあらゆるシステムにおけるお客様のイベントのタイムスタンプのあるアカウントを提供します。 プロファイルは、和集合表示を使用してこのデータを表し、個々の顧客の全体的な表示を提供します。
プロファイルの操作について詳しくは、 リアルタイム顧客プロファイルの概要を参照してください

データ・ファイルのXDMスキーマへのマッピング

Experience Platformに取り込まれるすべてのデータファイルは、XDMスキーマの構造に従う必要があります。 XDM階層(サンプルファイルを含む)に準拠するためにデータファイルをフォーマットする方法の詳細については、ETL変換の サンプルに関するドキュメントを参照してください 。 データファイルのExperience Platformへの取り込みに関する一般的な情報については、 バッチ取り込みの概要を参照してください

次の手順

スキーマ構成の基本を理解したら、スキーマレジストリを使用してスキーマの作成を開始する準備が整いました。
スキーマレジストリは、Adobe Experience Platform内のスキーマライブラリにアクセスするために使用され、使用可能なすべてのライブラリリソースにアクセスできるユーザーインターフェイスとRESTful APIを提供します。 スキーマライブラリには、アドビが定義する業界リソース、Experience Platformパートナーが定義するベンダーリソース、および組織のメンバーが構成するクラス、ミックスイン、データ型、スキーマが含まれています。
UIを使用してスキーマの構成を開始するには、 スキーマエディタのチュートリアルに従って 、このドキュメントで説明する「Loyalty Members」スキーマを作成します。
スキーマレジストリAPIの使用を開始するには、開始版レジストリAPI開発ガイドを読んでください スキーマレジストリAPI開発者ガイド 。 開発者ガイドを読んだ後、スキーマレジストリAPIを使用したスキーマの 作成に関するチュートリアルで概要を説明している手順に従います