Schema Editor

Adobe Experience Platformのユーザーインターフェイスを使用すると、Schema Editorと呼ばれるインタラクティブなビジュアルキャンバスでExperience Data Model (XDM)スキーマを作成および管理できます。 このチュートリアルでは、Schema Editorを使用してスキーマを作成する方法を説明します。

代わりにSchema Registry APIを使用してスキーマを構成する場合は、APIを使用したスキーマの作成に関するチュートリアルを開始する前に、Schema Registry 開発者ガイドを読んで、開始をお勧めします。

はじめに

このチュートリアルでは、スキーマの作成に関わるAdobe Experience Platformのさまざまな側面について、十分に理解する必要があります。 このチュートリアルを始める前に、次の概念に関するドキュメントを確認してください。

• Experience Data Model (XDM):顧客体験データを Platform 編成する際に使用される標準化されたフレームワーク。
  • スキーマ合成の基本：XDM スキーマとその構築ブロック（クラス、mixin、データ型、フィールドなど）の概要です。
• Real-time Customer Profile:複数のソースからの集計データに基づいて、統合されたリアルタイムの消費者プロファイルを提供します。

スキーマワークスペースを開きます

Platform UIのスキーマワークスペースはSchema Libraryのビジュアライゼーションを提供し、組織で使用可能なスキーマを表示が管理できます。 このワークスペースには、このチュートリアル全体でスキーマを構成できるキャンバスであるSchema Editorも含まれています。

Experience Platformにログインした後、左側のナビゲーションで​スキーマ​を選択し、スキーマ​ワークスペースを開きます。 「参照」タブには、スキーマのリスト（Schema Libraryの表現）が表示され、表示やカスタマイズが可能です。 リストには、スキーマの基となる名前、型、クラス、動作（レコードまたは時系列）、およびスキーマが最後に変更された日時が含まれます。

詳しくは、UIの既存のXDMリソースの詳細を参照してください。

スキーマの作成と命名

スキーマの構成を開始するには、スキーマ​ワークスペースの右上隅にある「スキーマ​]を作成」を選択します。[​ドロップダウンメニューが表示され、コアクラスXDM個別プロファイルとXDM ExperienceEventのいずれかを選択できます。 これらのクラスが目的に合わない場合は、「参照」を選択して他の使用可能なクラスから選択するか、新しいクラスを作成することもできます。

このチュートリアルの目的で、「XDM個別プロファイル」を選択します。

Schema Editorが表示されます。 これは、スキーマを作成するキャンバスです。スキーマの基にする標準XDMクラスを選択したので、エディターに到着したときに、名称未設定のスキーマがキャンバスの​Structure​セクションに自動的に作成され、そのクラスに基づくすべてのスキーマに含まれる標準フィールドが作成されます。 スキーマに割り当てられたクラスは、「構成」セクションの「クラス​Class」にも表示されます。

エディターの右側のフィールドを使用して、スキーマの表示名とオプションの説明を入力します。 名前を入力すると、キャンバスが更新され、スキーマの新しい名前が反映されます。

スキーマの名前を決定する際に考慮すべき重要な点がいくつかあります。

• スキーマ名は短く、スキーマを後で簡単に見つけられるように、説明的にします。
• スキーマ名は一意である必要があります。つまり、将来再利用されないように十分に具体的でなければなりません。例えば、組織が異なるブランドに対して別々のロイヤルティプログラムを持つ場合、後で定義する他のロイヤルティ関連スキーマと区別しやすいように、スキーマに「ブランド A ロイヤルティメンバー」という名前を付けると効果的です。
• スキーマの説明を使用して、スキーマに関する追加のコンテキスト情報を提供することもできます。

このチュートリアルでは、忠誠度プログラムのメンバに関連するデータを取り込むスキーマを構成します。したがって、スキーマの名前は「Loyalty Members」になります。

Mixin の追加

これで、mixin を追加して、スキーマにフィールドを追加できます。ミックスインは、特定の概念を説明するためによく一緒に使用される1つ以上のフィールドのグループです。 このチュートリアルでは、mixin を使用してロイヤルティプログラムのメンバーを説明し、名前、誕生日、電話番号、住所などの重要な情報を取得します。

ミックスインを追加するには、ミックスイン​サブセクションで追加​​​を選択します。

新しいダイアログが表示され、使用可能なミックスインのリストが表示されます。 各ミックスインは特定のクラスでのみ使用されるため、ダイアログには選択したクラス（この場合はXDM Individual Profileクラス）と互換性のあるリストミックスインのみが表示されます。 標準のXDMクラスを使用している場合、ミックスインのリストは、使用頻度に基づいてインテリジェントに並べ替えられます。

リストからMixinを選択すると、右側のパネルにMixinが表示されます。 必要に応じて複数のミックスインを選択し、各ミックスインを確認する前に右側のレールのリストに追加します。 また、現在選択されているミックスインの右側にアイコンが表示され、そのフィールドの構造をプレビューできます。

Mixinをプレビューする際、Mixinのスキーマの詳細が右側のパネルに表示されます。 また、提供されたキャンバス内のMixinのフィールド間を移動することもできます。 別のフィールドを選択すると、右側のパネルが更新され、目的のフィールドに関する詳細が表示されます。 プレビューが終了したら、「戻る」を選択して、mixinの選択ダイアログに戻ります。

このチュートリアルでは、人口統計の詳細​ミックスインを選択し、ミックスイン追加​を選択します。

スキーマキャンバスが再び表示されます。ミックスイン​セクションには、「人口統計的詳細」と​構造​セクションには、ミックスインが寄与するフィールドが含まれるようになりました。 「ミックスイン」セクションでミックスインの名前を選択し、キャンバス内で提供される特定のフィールドを強調表示することができます。

このミックスインは、最上位レベルの名前personの下に、「人」というデータ型のフィールドをいくつか使用します。 このフィールドグループは、名前、生年月日、性別など、個人に関する情報を説明します。

nameフィールドのデータ型は「人名」です。つまり、一般的な概念を表し、名、姓、敬称、敬称、接尾辞など、名前に関連するサブフィールドが含まれます。

キャンバス内の別のフィールドを選択すると、スキーマ構造に影響を与える追加のフィールドが表示されます。

別の mixin の追加

次に、同じ手順を繰り返して、別の mixin を追加できます。今回は​mixin追加​ダイアログを表示する際に、「人口統計の詳細」ミックスインは灰色表示になっており、隣のチェックボックスは選択できないことに注意してください。 これは、既に現在のスキーマに含まれている mixin を誤って複製するのを防ぎます。

このチュートリアルでは、ダイアログから「Personal Contact Details」ミックスインを選択し、「ミックスイン追加」を選択してスキーマに追加します。

追加すると、キャンバスが再び表示されます。「個人の連絡先の詳細」が​コンポジション​セクションの​ミックスイン​の下に表示され、自宅住所、携帯電話などのフィールドが​構造​の下に追加されました。

nameフィールドと同様、先ほど追加したフィールドは複数フィールドの概念を表しています。 例えば、homeAddressのデータ型は「[!UICONTROL 住所]」、mobilePhoneのデータ型は「電話番号」です。 これらの各フィールドを選択して展開し、データ型に含まれる追加のフィールドを表示できます。

新しい mixin の定義

「忠誠度メンバー」スキーマは、忠誠度プログラムのメンバーに関連するデータを取り込むためのものなので、いくつかの特定の忠誠度関連フィールドが必要になります。 必要なフィールドを含む標準 mixin がないので、新しい mixin を定義する必要があります。

今回は、Mixin の追加​ダイアログを開いたときに、「新規 mixin の作成」を選択します。その後、ミックスインの表示名と説明を入力するように求められます。

クラス名と同様に、mixin 名は短く単純で、mixin がスキーマに与える影響を説明するべきです。これらも一意なので、名前を再利用できません。名前が十分に具体的であるようにしてください。

このチュートリアルでは、新しい mixin に「Loyalty Details」という名前を付けます。

ミッ追加クスイン​を選択してSchema Editorに戻ります。 キャンバスの左側の​ミックスイン​の下に"忠誠度の詳細"が表示されるはずですが、関連するフィールドはまだないので、構造​の下に新しいフィールドは表示されません。

Mixin へのフィールドの追加

「Loyalty Details」mixin を作成したら、mixin がスキーマに貢献するフィールドを定義します。

最初に、ミックスイン​セクションでミックスイン名を選択します。 これを行うと、mixinのプロパティがエディターの右側に表示され、構造​の下のスキーマ名の横に​プラス(+)​アイコンが表示されます。

「」の横のプラス(+)​アイコンを選択して、構造内に新しいノードを作成します。 Loyalty Membersこのノード（この例では_tenantIdと呼ばれます）は、IMS組織のテナントIDを表し、前にアンダースコアが付きます。 テナント ID の存在は、追加するフィールドが組織の名前空間に限られていることを示しています。

つまり、追加するフィールドは組織に固有のものであり、組織にのみアクセス可能な特定の領域のSchema Registryに保存されます。 定義するフィールドは、他の標準クラス、ミックスイン、データ型、およびフィールドの名前との競合を防ぐために、常にテナント名前空間に追加する必要があります。

その名前の付いたノードの中には、「新しいフィールド」が入っています。 これは、「忠誠度の詳細」ミックスインの開始です。

エディターの右側のコントロールを使用して、忠誠度関連のフィールドの保持に使用するloyaltyオブジェクト]の型を持つ<a0/>フィールドを作成し、開始します。 [終了したら、「適用」を選択します。

変更が適用され、新しく作成されたloyaltyオブジェクトが表示されます。 オブジェクトの横にあるプラス(+)アイコンを選択し、忠誠度関連のフィールドを追加します。「新しいフィールド」が表示され、キャンバスの右側に​フィールドプロパティ​セクションが表示されます。

各フィールドには、次の情報が必要です。

• Field Name：フィールド の名前。キャメルケースで書かれています。例：loyaltyLevel
• 表示名：フィールド の名前。タイトルの場合は大文字で表記されます。例：Loyalty Level
• Type: フィールドのデータ型。これには、基本的なスカラー型とSchema Registryで定義されているすべてのデータ型が含まれます。 例：文字列、整数、ブール値、人、住所、電話番号など。
• 説明:（オプション）フィールド の説明は、文頭の場合と同様に、最大200文字で記述します。

Loyaltyオブジェクトの最初のフィールドは、loyaltyIdという文字列になります。 新しいフィールドのタイプを「文字列」に設定すると、フィールドプロパティ​セクションに、デフォルト値、形式、最大長など、制約を適用するためのオプションが入力されます。

選択したデータ型に応じて、様々な制約オプションを使用できます。loyaltyIdは電子メールアドレスになるので、形式​ドロップダウンメニューから「電子メール」を選択します。 「適用」を選択して変更を適用します。

mixinの追加追加フィールド

loyaltyIdフィールドを追加したら、次のような忠誠度関連の情報を取り込むためのフィールドを追加できます。

• ポイント（整数）
• 会員登録日

各フィールドをスキーマに追加するには、loyaltyオブジェクトの横にある​プラス(+)​アイコンを選択し、必要な情報を入力します。

完了すると、忠誠度オブジェクトには、忠誠度ID、ポイント、およびメンバー登録用のフィールドが含まれます。

mixin追加の列挙フィールド

Schema Editorにフィールドを定義する場合、基本的なフィールドの種類に適用できる追加のオプションがいくつかあり、フィールドに含めることのできるデータに対してさらなる制約を設けます。 これらの制約の使用例を次の表に示します。

制約	説明
必須	フィールドがデータ取り込みに必要であることを示します。 このフィールドを含まないデータセットに基づいてスキーマセットにアップロードされたデータの取得は失敗します。
配列	フィールドに値の配列が含まれ、各値は指定されたデータ型になっていることを示します。 例えば、データ型が「String」のフィールドに対してこの制約を使用すると、フィールドに文字列の配列が含まれるように指定できます。
Enum	このフィールドに、可能な値の列挙リストの値の1つを含める必要があることを示します。
ID	このフィールドがIDフィールドであることを示します。 ID フィールドの詳細については、このチュートリアルの後半で説明します。
Relationship	スキーマの関係は、和集合スキーマとReal-time Customer Profileを使用して推定できますが、これは同じクラスを共有するスキーマにのみ当てはまります。 Relationship制約は、このフィールドが、異なるクラスに基づくスキーマの主なIDを参照することを示し、2つのスキーマ間の関係を示します。 詳細は、関係の定義のチュートリアルを参照してください。

このチュートリアルでは、スキーマの"loyalty"オブジェクトに、顧客の「忠誠度レベル」を示す新しい列挙フィールドが必要です。値は、4つのオプションのうちの1つに限定されます。 このフィールドをスキーマに追加するには、loyaltyオブジェクトの横にある​プラス(+)​アイコンを選択し、フィールド名​と​表示名​の必須フィールドに入力します。 「タイプ」で、「文字列」を選択します。

配列、列挙、ID​のチェックボックスなど、タイプを選択した後に、フィールドに追加のチェックボックスが表示されます。

「列挙」チェックボックスを選択して、下の​列挙値​を開きます。 ここで、許容可能な各ロイヤルティレベルの​値（キャメルケース）と​ラベル（タイトルケースでの読みやすい名前でオプション）を入力できます。

すべてのフィールドプロパティを完了したら、「適用」を選択して、「loyaltyLevel」フィールドをloyaltyオブジェクトに追加します。

複数フィールドオブジェクトのデータ型への変換

loyaltyオブジェクトには複数の忠誠度固有のフィールドが含まれ、他のスキーマで役立つ共通のデータ構造を表すようになりました。 Schema Editorを使用すると、再利用可能な複数フィールドオブジェクトを簡単に適用できます。これらのオブジェクトの構造をデータ型に変換します。

データ型を使用すると、複数フィールド構造を一貫して使用でき、mixin よりも柔軟性が高まります。これは、データ型がスキーマ内のどこでも使用できるからです。これは、フィールドの​Type​値を、Schema Registryで定義されている任意のデータ型の値に設定することで行います。

loyaltyオブジェクトをデータ型に変換するには、[!UICONTROL 構造]​の下のloyaltyフィールドを選択し、フィールドのプロパティ​の下のエディターの右側の<a4/>新しいデータ型​]に変換を選択します。[​オブジェクトが正常に変換されたことを確認する緑のポーバーが表示されます。

構造​の下を見ると、loyaltyフィールドのデータ型が「Loyalty」で、フィールドの横に小さな錠前のアイコンが表示され、個々のフィールドではなく、複数フィールドのデータ型であることがわかります。

今後のスキーマでは、フィールドを「Loyalty」型として割り当て、ID、忠誠度レベル、メンバーシンク、ポイントのフィールドを自動的に含めることができます。

スキーマフィールドの検索とフィルター

スキーマには、基本クラスが提供するフィールドに加えて、複数のミックスインが含まれるようになりました。 大きいスキーマを使用する場合は、左側のレールでmixin名の横にあるチェックボックスをオンにして、表示されるフィールドを、関心のあるミックスインで提供されるフィールドのみにフィルタリングできます。

スキーマ内で特定のフィールドを探している場合は、検索バーを使用して、表示されるフィールドを、どのミックスインがどの下に提供されているかに関係なく、名前でフィルターすることもできます。

ID フィールドとしてのスキーマフィールドの設定

スキーマが提供する標準的なデータ構造を活用して、複数のソースにわたって同じ個人に属するデータを識別でき、分類、レポート、データサイエンスの分析など、様々な下流の使用例に対応できます。 個々のIDに基づいてデータを結合するには、キーフィールドを該当するスキーマ内でIDフィールドとしてマークする必要があります。

Experience Platform を使用すると、の「 ​​Identity」チェックボックスを使用して、IDフィールドを簡単に示すことがで Schema Editorきます。ただし、データの性質に基づいて、IDとして使用するのに最適なフィールドを決定する必要があります。

例えば、同じ「忠誠度レベル」に属する何千もの忠誠度プログラムメンバーが存在する場合がありますが、忠誠度プログラムの各メンバーは一意のloyaltyIdを持ちます（この場合は、個々のメンバーの電子メールアドレスです）。 loyaltyIdが各メンバの一意の識別子であることは、loyaltyLevelがIDフィールドに対する適切な候補となるのに対し、<a0/>は異なります。

エディターの​構造​セクションで、loyaltyIdフィールドを選択し、フィールドのプロパティ​の下に「ID」チェックボックスが表示されます。 チェックボックスをオンにし、プライマリID​として設定するオプションが表示されます。 このボックスも選択します。

次に、ドロップダウン内の事前定義済みの名前空間のリストから​ID名前空間​を指定する必要があります。 loyaltyIdはお客様の電子メールアドレスなので、ドロップダウンから「電子メール」を選択します。 「​を適用」を選択して、loyaltyIdフィールドの更新を確認します。

変更を適用した後、loyaltyIdのアイコンに指紋の記号が表示され、現在はIDフィールドであることが示されます。

loyaltyIdフィールドに取り込まれたすべてのデータは、その個人を特定し、その顧客の1つの表示をつなぎ合わせるのに役立ちます。 Experience PlatformでIDを使用する方法の詳細については、Identity Serviceのドキュメントを参照してください。

スキーマをReal-time Customer Profileで使用できるようにする

Real-time Customer Profile アイデンティティデータ Experience Platform を活用して、個々の顧客の全体的な表示を提供します。このサービスは、Experience Platformと統合されたあらゆるシステムにわたって顧客属性の360°の堅牢なプロファイルと、顧客が持つすべてのインタラクション顧客のタイムスタンプのあるアカウントを構築します。

スキーマをReal-time Customer Profileで使用できるようにするには、プライマリIDが定義されている必要があります。 最初にプライマリIDを定義せずにスキーマを有効にしようとすると、エラーメッセージが表示されます。

Profileで「Loyalty Members」スキーマを使用できるようにするには、まずエディターの​Structure​セクションで「Loyalty Members」を選択します。

エディターの右側には、スキーマに関する情報（表示名、説明、タイプなど）が表示されます。 この情報に加えて、プロファイル​の切り替えボタンがあります。

「プロファイル」を選択すると、Profileのスキーマを有効にするかどうかを確認するプローバーが表示されます。

「有効」を選択して、選択を確定します。 プロファイル​の切り替えを再度選択して、必要に応じてスキーマを無効にできますが、Profileが有効な間にスキーマを保存すると、無効にできなくなります。

次の手順とその他のリソース

スキーマの構成が完了すると、カンバスに完全なスキーマが表示されます。 「保存」を選択すると、スキーマがSchema Libraryに保存され、Schema Registryからアクセスできるようになります。

新しいスキーマを使ってPlatformにデータを取り込めるようになりました。 データの取得にスキーマを使用した後は、追加的な変更のみがおこなわれる場合があります。スキーマバージョン管理について詳しくは、「スキーマ合成の基本」を参照してください。

これで、UIでスキーマの関係を定義するチュートリアルに従って、「Loyality Members」スキーマに新しい関係フィールドを追加できます。

「ロイヤルティメンバー」スキーマは、Schema Registry APIを使用して表示および管理することもできます。 APIの使用を開始するには、Schema Registry API 開始ガイドを読んでください。

ビデオリソース

次のビデオでは、Platform UIで単純なスキーマを作成する方法を示します。

次のビデオは、ミックスインとクラスを使用する際の理解を深めるためのものです。

付録

以下の節では、Schema Editorの使用に関する追加情報を示します。

新しいクラスの作成

Experience Platform は、組織に固有のクラスに基づいてスキーマを定義する柔軟性を提供します。新しいクラスの作成方法については、UI](…/ui/resources/classes.md#create)の[クラスの作成と編集に関するガイドを参照してください。

スキーマクラスの変更

スキーマのクラスは、スキーマが保存される前の最初の構成プロセスの任意の時点で変更できます。

スキーマのクラスを変更する方法については、UIでのスキーマの管理に関するガイドを参照してください。