スキーマ構成の基本

エクスペリエンスデータモデル（XDM）スキーマと、Adobe Experience Platformでスキーマを構成するための構成要素、原則およびベストプラクティスについて説明します。 XDM の一般的な情報と内での使用方法については、を参照してください Platformを参照してください。 XDM システムの概要.

スキーマ understanding-schemas

スキーマは、データの構造と形式を表し、検証する一連のルールです。スキーマは、高いレベルで、実世界のオブジェクト（人など）の抽象的な定義を提供し、そのオブジェクトの各インスタンスに含めるデータ（名、姓、誕生日など）の概要を示します。

スキーマは、データの構造を説明するだけでなく、制約や期待をデータに適用し、システム間の移動時に検証できるようにします。これらの標準的な定義により、接触チャネルに関係なくデータを一貫して解釈でき、アプリケーション間での翻訳の必要性を排除できます。

Experience Platformでは、このセマンティック正規化をスキーマを使用して維持管理します。 スキーマは Experience Platform での標準的なデータ記述方法で、スキーマに適合するすべてのデータを組織間で競合なく再利用可能にし、さらに複数の組織間で共有できるようになります。

XDM スキーマは、膨大な量の複雑なデータを自己完結型の形式で保存するのに最適です。 のセクションを参照してください。 埋め込みオブジェクト および ビッグデータ xdm がこれを実現する方法の詳細については、このドキュメントの付録を参照してください。

Experience Platform でのスキーマベースのワークフロー schema-based-workflows

標準化は、Experience Platform の背後にある主要な概念です。アドビが推進する XDM は、顧客エクスペリエンスデータを標準化し、顧客エクスペリエンス管理の標準スキーマを定義する取り組みです。

Experience Platformが構築されるインフラストラクチャ（別名） XDM Systemを使用すると、スキーマベースのワークフローを容易にし、次の機能が含まれます Schema Registry, Schema Editor、スキーマメタデータ、サービス使用パターンです。 詳しくは、「XDM システムの概要」を参照してください。

Experience Platformでスキーマを使用する主なメリットはいくつかあります。 1 つ目は、スキーマを使用すると、データガバナンスの改善とデータの最小化を可能にすることです。これは、プライバシー規制で特に重要になります。 次に、Adobeの標準コンポーネントを使用してスキーマを構築すると、最小限のカスタマイズで、すぐに使用できるインサイトを提供し、AI/ML サービスを使用できます。 最後に、スキーマは、データ共有のインサイトと効率的なオーケストレーションのためのインフラストラクチャを提供します。

スキーマの計画 planning

スキーマを構築する最初の手順は、スキーマ内で捕捉しようとする概念、すなわち現実世界のオブジェクトを決定することです。記述しようとしている概念を特定したら、データのタイプ、潜在的な ID フィールド、将来のスキーマの進化方法などを考えることで、スキーマの計画を開始します。

Experience Platform でのデータ動作 data-behaviors

Experience Platform での使用を意図したデータの動作タイプは、次の 2 つに分類されます。

すべての XDM スキーマは、レコードまたは時系列として分類できるデータを記述します。スキーマのデータ動作は、スキーマのクラスによって定義され、スキーマの作成時に割り当てられます。XDM クラスについては、このドキュメントで後述します。

レコードと時系列の両方のスキーマには、ID のマップ（xdm:identityMap）が含まれます。このフィールドには、次の節で説明する「ID」とマークされたフィールドから作成された、主体の ID 表現が含まれます。

ID identity

スキーマは、データを Experience Platform に取得するために使用されます。このデータは、複数のサービスで使用して、個々のエンティティの単一の統合表示を作成できます。したがって、顧客 ID のスキーマをデザインする際には、データの取得元に関係なく、サブジェクトの識別に使用できるフィールドを考慮することが重要です。

このプロセスに役立つように、スキーマ内のキーフィールドを ID としてマークできます。 データの取り込み時に、これらのフィールドのデータは、に挿入されます。ID グラフ」と表示されます。 その後、次の方法でグラフデータにアクセスできます Real-Time Customer Profile その他のExperience Platformサービス：個々の顧客の関連付けられたビューを提供します。

一般的に「」とマークされているフィールドID「次を含む：メールアドレス、電話番号、 Experience Cloud ID (ECID)、CRM ID、またはその他の一意の ID フィールド。 組織に固有の一意の ID は良い場合があるので、考慮してください」ID」フィールドも選択します。

可能な限り堅牢なプロファイルを構築するためにデータを確実に統合するために、スキーマ計画フェーズで顧客 ID について考えることが重要です。 ID 情報が、顧客にデジタルエクスペリエンスを提供する上でどのように役立つかについては、を参照してください ID サービスの概要. については、データモデリングのベストプラクティスのドキュメントを参照してください スキーマ作成時の ID の使用に関するヒント.

Platform に ID データを送信する方法は 2 つあります。

identityMap identityMap

identityMap は、個人の様々な id 値を、関連する名前空間と共に記述するマップタイプフィールドです。 このフィールドは、スキーマ自体の構造の中で ID 値を定義する代わりに、スキーマの ID 情報を提供するために使用できます。

を使用することの主な欠点 identityMap つまり、ID はデータに埋め込まれ、その結果、見えにくくなります。 生データを取り込む場合は、代わりに実際のスキーマ構造内で個々の ID フィールドを定義する必要があります。

ただし、ID マップは、1 つのスキーマに対して ID の数が可変な場合や、ID を保存するソースからデータを取り込む場合（など）に役立ちます Airship またはAdobe Audience Manager）に保存します。 さらに、を使用している場合は、ID マップが必要です Adobe Experience Platform Mobile SDK.

単純な ID マップの例は、次のようになります。

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": true
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "CRMID": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": false
    }
  ]
}

上の例が示すように、内の各キー identityMap オブジェクトは、id 名前空間を表します。 各キーの値はオブジェクトの配列で、ID 値（id）に設定する必要があります。 を参照してください。 Identity Service のドキュメント 標準 id 名前空間のリスト Adobeアプリケーションで認識される。

スキーマ進化の原則 evolution

デジタルエクスペリエンスの本質が進化し続けるにつれ、デジタルエクスペリエンスを表すスキーマが必要になります。したがって、適切に設計されたスキーマは、必要に応じて適応し、進化し、以前のバージョンのスキーマに破壊的な変更を加えることなく使用できます。

後方互換性の維持はスキーマ進化にとって重要なので、Experience Platformでは純粋に追加的なバージョン管理原則を適用します。 この原則により、スキーマへのすべての変更が、非破壊的な更新および変更のみを生み出すことを保証します。 つまり、後方互換性を壊すような変更 ​はサポートされません。

次の表に、スキーマ、フィールドグループおよびデータタイプを編集する際にサポートされる変更を示します。

*に関する重要な考慮事項については、以下の節を参照してください 新しい必須フィールドの設定.

必須フィールド

個々のスキーマフィールドには、次の種類があります 必須としてマーク済みつまり、取り込んだレコードは、検証に合格するために、これらのフィールドにデータを含んでいる必要があります。 例えば、スキーマのプライマリ ID フィールドを必要に応じて設定すると、取り込まれたすべてのレコードがリアルタイム顧客プロファイルに確実に関与するようにできます。 同様に、タイムスタンプフィールドを必要に応じて設定すると、すべての時系列イベントが時系列で保持されます。

取り込み後に必要に応じてフィールドを設定 post-ingestion-required-fields

データの取り込みに使用されているフィールドが、元々は必須として設定されていなかった場合、そのフィールドには、一部のレコードで null 値が含まれている場合があります。 このフィールドを取り込み後に必須として設定した場合、履歴レコードが null の場合でも、今後のすべてのレコードにこのフィールドの値が含まれる必要があります。

以前のオプションフィールドを必須として設定する場合は、次の点に注意してください。

スキーマとデータの取得

データを Experience Platform で取得するには、まずデータセットを作成する必要があります。データセットは、のデータ変換とトラッキングの構築ブロックです。 Catalog Service、およびは通常、取り込んだデータを含むテーブルまたはファイルを表します。 すべてのデータセットは既存の XDM スキーマに基づいており、取得するデータの内容と構造の制約を提供します。詳しくは、「Adobe Experience Platform でのデータ取得の概要」を参照してください。

スキーマの構成要素 schema-building-blocks

Experience Platform では、標準の構築要素を組み合わせてスキーマを作成する構成アプローチを使用します。このアプローチは、既存のコンポーネントの再利用を促進し、業界全体で標準化を推進して、のベンダースキーマとコンポーネントをサポートします Platform.

スキーマは、次の式を使用して構成されます。

クラス + スキーマフィールドグループ* = XDM スキーマ

スキーマは、クラスと 0 個以上のスキーマフィールドグループで構成されます。 つまり、フィールドグループをまったく使用せずに、データセットスキーマを作成できます。

クラス class

クラスを割り当てることで、スキーマの構成が開始されます。クラスは、スキーマに含まれるデータ（レコードまたは時系列）の行動の側面を定義します。 これに加えて、クラスは、そのクラスに基づくすべてのスキーマに含める必要のある共通のプロパティの最小数を記述し、複数の互換性のあるデータセットを結合する方法を提供します。

スキーマのクラスは、そのスキーマで使用できるフィールドグループを決定します。 これについては、以下で詳しく説明します 次のセクション.

Adobeは、複数の標準（「コア」） XDM クラスを提供します。 この 2 つのクラス、 XDM Individual Profile および XDM ExperienceEventは、ほぼすべてのダウンストリームの Platform プロセスに必要です。 これらのコアクラスに加えて、独自のカスタムクラスを作成して、組織のより具体的な使用例を記述することもできます。 カスタムクラスは、一意のユースケースを記述するために使用できるAdobe定義のコアクラスがない場合に、組織が定義します。

次のスクリーンショットは、Platform UI でクラスがどのように表されるかを示しています。 表示されるサンプルスキーマにはフィールドグループが含まれていないので、表示されるすべてのフィールドはスキーマのクラス（XDM 個人プロファイル）に設定します。

使用可能な標準 XDM クラスの最新リストについては、を参照してください 公式 XDM リポジトリ. または、のガイドを参照してください。 xdm コンポーネントの詳細 ui でリソースを表示する場合は、

フィールドグループ field-group

フィールドグループは、個人の詳細情報、ホテルの環境設定、住所などの特定の機能を実装する 1 つ以上のフィールドを定義する再利用可能なコンポーネントです。 フィールドグループは、互換性のあるクラスを実装するスキーマの一部として含めることを目的としています。

フィールドグループは、表現するデータの動作（レコードまたは時系列）に基づいて、互換性のあるクラスを定義します。 つまり、すべてのフィールドグループをすべてのクラスで使用できるわけではありません。

Experience Platformには、多くの標準のAdobeフィールドグループが含まれています。また、ベンダーはユーザーのフィールドグループを定義でき、個々のユーザーは、独自の具体的なコンセプトのフィールドグループを定義できます。

例えば、詳細を取得するには、「名前（名）「」と「」に対して検査する値住所（自宅）」に設定しますロイヤルティメンバー「スキーマがあれば、これらの一般的な概念を定義する標準のフィールドグループを使用できます。 ただし、標準のフィールドグループではカバーされない可能性のある、組織に固有の概念（カスタムロイヤルティプログラムの詳細や製品属性など）です。 この場合、この情報を取得するには、独自のフィールドグループを定義する必要があります。

スキーマは「0 個以上」のフィールドグループで構成されているので、フィールドグループをまったく使用せずに有効なスキーマを作成できます。

次のスクリーンショットは、Platform UI でフィールドグループがどのように表されるかを示しています。 単一のフィールドグループ（人口統計の詳細）がスキーマに追加されています。この例では、スキーマの構造に対してフィールドのグループ化を提供します。

使用可能な標準 XDM フィールドグループの最新のリストについては、を参照してください 公式 XDM リポジトリ. または、のガイドを参照してください。 xdm コンポーネントの詳細 ui でリソースを表示する場合は、

データタイプ data-type

データタイプは、基本リテラルフィールドと同様に、クラスやスキーマの参照フィールド型として使用されます。主な違いは、データタイプがフィールドグループと同じ方法で複数のサブフィールドを定義できることです。 これらの主な違いは、データタイプをフィールドの「データタイプ」として追加することで、スキーマ内の任意の場所に含めることができるということです。 フィールドグループは特定のクラスにのみ適合しますが、データタイプは任意の親クラスまたはフィールドグループに含めることができます。

Experience Platformは、の一部として多くの一般的なデータタイプを提供しています Schema Registry 共通のデータ構造を記述するための標準パターンの使用を支援する。 これについて詳しくは、 スキーマレジストリのチュートリアル データタイプを定義する手順を実行すると、およびが明確になります。

次のスクリーンショットは、Platform UI でデータタイプがどのように表されるかを示しています。 によって提供されるフィールドの 1 つ 人口統計の詳細 フィールドグループは「」を使用しますオブジェクト「データタイプ」と表示されます（パイプ文字（|）を選択します。 この特定のデータタイプは、個々のユーザーの名前に関連する複数のサブフィールドを提供します。これは、ユーザーの名前を取り込む必要がある他のフィールドで再利用できる構造です。

使用可能な標準 XDM データタイプの最新リストについては、を参照してください 公式 XDM リポジトリ. または、のガイドを参照してください。 xdm コンポーネントの詳細 ui でリソースを表示する場合は、

フィールド field

フィールドは、スキーマの最も基本的な構成要素です。フィールドは、特定のデータタイプを定義することによって、フィールドに含めることができるデータのタイプに関する制約を提供します。 これらの基本的なデータタイプは、1 つのフィールドを定義しますが、 データタイプ 前述のとおり、複数のサブフィールドを定義して、同じ複数フィールド構造を様々なスキーマで再利用できます。 したがって、フィールドの「データタイプ」をレジストリで定義されたデータタイプの 1 つとして定義する以外に、Experience Platform は、次のような基本的なスカラー型をサポートしています。

これらのスカラー型の有効な範囲は、特定のパターン、形式、最小値や最大値、事前定義値にさらに制限できます。これらの制約を使用すると、以下のような、より詳細なフィールドタイプを幅広く表すことができます。

合成の例 composition-example

スキーマは、コンポジションモデルを使用して作成され、取り込むデータの形式と構造を表します Platform. 前述のように、これらのスキーマは、1 つのクラスと、そのクラスと互換性のある 0 個以上のフィールドグループで構成されます。

例えば、小売店での購入を記述するスキーマは、「」と呼ばれますストアトランザクション」と入力します。 スキーマは、 XDM ExperienceEvent 標準と組み合わされたクラス コマース フィールドグループとユーザー定義 製品情報 フィールドグループ。

Web サイトのトラフィックを追跡する別のスキーマは、「Web 訪問数」と入力します。 また、 XDM ExperienceEvent クラス、今回は標準を組み合わせたものです Web フィールドグループ。

次の図に、これらのスキーマと、各フィールドグループによって提供されるフィールドを示します。 また、に基づく 2 つのスキーマも含まれています XDM Individual Profile クラス （「」を含む）ロイヤルティメンバー」というスキーマが含まれています。

和集合 union

Experience Platform では特定の使用事例のスキーマを作成できますが、特定のクラスタイプのスキーマの「和集合」を確認することもできます。前の図は、XDM ExperienceEvent クラスに基づく 2 つのスキーマと、に基づく 2 つのスキーマを示しています XDM Individual Profile クラス。 以下に示すように、結合は、同じクラスを共有するすべてのスキーマのフィールドを集計します（XDM ExperienceEvent および XDM Individual Profile、それぞれ）。

で使用するスキーマを有効にする Real-Time Customer Profile含まれる場合、そのクラスタイプの和集合に含まれます。 Profile は、と統合されたあらゆるシステムで顧客が経験したすべてのイベントについて、顧客属性の堅牢な一元化されたプロファイルとタイムスタンプ付きのアカウントを提供します Platform. Profile では、和集合ビューを使用してこのデータを表し、各顧客の全体像を提供します。

の操作の詳細 Profileを参照してください。 リアルタイム顧客プロファイルの概要.

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

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

外部オーディエンスのスキーマ

外部システムから Platform にオーディエンスを取り込む場合は、次のコンポーネントを使用してスキーマで取り込む必要があります。

次の手順

これでスキーマ構成の基本を理解したので、次に、を使用したスキーマの調査と構築を開始します Schema Registry.

2 つのコア XDM クラスの構造と、それらの一般的に使用される互換性のあるフィールドグループを確認するには、次のリファレンスドキュメントを参照してください。

この Schema Registry にアクセスするために使用されます。 Schema Library Adobe Experience Platform内にあり、使用可能なすべてのライブラリリソースにアクセスできるユーザーインターフェイスと RESTful API を提供します。 この Schema Library Adobeが定義した業界リソース、Experience Platform パートナーが定義したベンダーのリソース、および所属組織のメンバが作成したクラス、フィールド グループ、データ型、およびスキーマが含まれます。

UI を使用してスキーマの構成を開始するには、スキーマエディターのチュートリアルを参照しながら、このドキュメントで取り上げる「ロイヤルティメンバー」スキーマを作成します。

の使用を開始するには Schema Registry API を使用する場合、まず次を読み取ります スキーマレジストリ API デベロッパーガイド. 開発者ガイドを読んだ後、スキーマレジストリ API を使用したスキーマの作成に関するチュートリアルで説明されている手順に従います。

付録

以下の節では、スキーマ構成の原則に関する追加情報を示します。

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

リレーショナルデータベースを使用する場合のベストプラクティスには、データの正規化、またはエンティティを取得してそれを個別のピースに分割し、複数のテーブルに表示することが含まれます。データ全体を読み取ったり、エンティティを更新したりするには、JOIN を使用して、多数の個別のテーブルに対して読み取りおよび書き込み操作を行う必要があります。

埋め込みオブジェクトを使用することで、XDM スキーマは複雑なデータを直接表し、階層構造を持つ自己完結型のドキュメントに保存できます。 この構造の主な利点の 1 つは、複数の非正規化テーブルへの高価な結合によってエンティティを再構築することなく、データをクエリできることです。 スキーマ階層のレベル数に関する厳しい制限はありません。

スキーマとビッグデータ big-data

現代のデジタルシステムは、大量の行動信号（トランザクションデータ、Web ログ、物のインターネット、ディスプレイなど）を生成します。このビッグデータは、エクスペリエンスを最適化する非常に大きな機会を生み出しますが、データの規模と多様性が原因で、使用が困難です。データから価値を得るには、その構造、形式、定義を標準化して、一貫して効率的に処理できるようにする必要があります。

スキーマは、複数のソースからのデータの統合、共通の構造や定義による標準化、複数のソリューション間での共有を可能にすることで、この問題を解決します。これにより、後続のプロセスやサービスは、データに関するあらゆる種類の質問に答えることができます。 従来のデータモデリングのアプローチから移行します。従来のデータモデリングでは、データに関する質問はすべて事前に把握され、その期待に応えるためにデータがモデル化されます。

オブジェクトとフリーフォームフィールド objects-v-freeform

スキーマをデザインする際に自由形式フィールドよりもオブジェクトを選択する場合は、いくつかの重要な要因を考慮する必要があります。

オブジェクト

フリーフォームフィールドでオブジェクトを使用する場合のメリットとデメリットを以下に示します。

長所:

短所:

自由形式フィールド

オブジェクト上でフリーフォームフィールドを使用するメリットとデメリットを以下に示します。

長所:

短所: