データモデルのベストプラクティス

このドキュメントでは、Adobe Campaign データモデルを設計する際の主な推奨事項の概要を説明します。

Campaign の組み込みテーブルとそのインタラクションについて詳しくは、 この節 を参照してください。

Campaign スキーマの概要については、 このドキュメント を参照してください。 このドキュメント では、Adobe Campaignデータベースの概念的データモデルを拡張するための拡張スキーマの設定方法について説明します。

概要

Adobe Campaignシステムは非常に柔軟で、初期実装を超えて拡張できます。 可能性は無限です。とはいえ、賢明な判断を下し、データモデルの設計を開始する前に強力な基盤を構築しておくことが不可欠です。

このドキュメントでは、Adobe Campaignツールを適切に設計する方法を学ぶための一般的な使用例とベストプラクティスを示します。

データモデルアーキテクチャ

Adobe Campaign は強力なクロスチャネルキャンペーン管理システムであり、オンラインとオフラインのマーケティング戦略を融合して、パーソナライズされた顧客体験を作成できます。

顧客中心のアプローチ

ほとんどのメールサービスプロバイダーは、リスト中心アプローチを使用して顧客と通信していますが、Adobe Campaign は、リレーショナルデータベースに基づいて、顧客と顧客の属性を幅広く視野に入れて活用しています。

この顧客中心アプローチは、次のグラフに表示されます。 灰色の 受信者 テーブルは、すべてが作成されるメイン顧客テーブルを表します。

各テーブルの記述にアクセスするには、管理／設定／データスキーマ​に移動し、リストからリソースを選択して「ドキュメント」タブをクリックします。

Adobe Campaignのデフォルトデータモデルについては、このドキュメント 🔗 で説明しています。

メモ

Adobe Campaign Classicでは、カスタム顧客テーブルを作成できます。 ただし、ほとんどの場合は、既に追加のテーブルや機能があらかじめ組み込まれている標準の 受信者テーブル を利用することをお勧めします。

Adobe Campaign 用データ

Adobe Campaign に送信すべきデータ マーケティングアクティビティに必要なデータを決定することがきわめて重要です。

メモ

Adobe Campaign はデータウェアハウスでもレポートツールでもありません。 可能性のある顧客とその関連情報をすべて Adobe Campaign にインポートしたり、レポートの作成にしか使用しないデータをインポートしたりしないように心がけます。

Adobe Campaign で必要な属性であるかどうかを判断するには、次のカテゴリのいずれかに該当するかどうかを確認します。

  • セグメント化​に使用する属性
  • データ管理プロセス​に使用する属性（集計計算など）
  • パーソナライゼーション​に使用する属性

これらのいずれにも該当しない場合、その属性は Adobe Campaign でまず必要にならないと思われます。

データタイプの選択

システムのアーキテクチャとパフォーマンスを適切な状態に保つには、次のベストプラクティスに従って Adobe Campaign のデータを設定します。

  • 大きなテーブルには、主として数値フィールドや参照テーブルへのリンクを含みます（値のリストを扱う場合）。
  • expr 属性を使用すると、テーブル内の物理的な設定値ではなく、計算フィールドとしてスキーマ属性を定義できます。 これにより、両方の値を保存する必要なく、異なる形式（年齢や生年月日など）で情報にアクセスできます。 これにより、フィールドの重複を避けることができます。 例えば、ドメインはメールフィールドに既に存在するので、受信者テーブルでドメインの式を使用できます。
  • ただし、式の計算が複雑な場合は、expr 属性を使用しないでください。検索時に計算すると、クエリのパフォーマンスに影響を与える可能性があるからです。
  • XML 型を使用すると、作成するフィールドの数を減らすことができます。ただし、データベース内で CLOB 列を使用するので、ディスク領域も消費します。また、結果的に複雑な SQL クエリになり、パフォーマンスに影響を与える可能性もあります。
  • 文字列​フィールドの長さは、常に列で定義する必要があります。Adobe Campaign ではデフォルトの最大長は 255 ですが、データの最大長があらかじめわかっている場合は、フィールドの長さを短くすることをお勧めします。
  • 参照元のシステム内のフィールドサイズが過大に見積もられていて、データはそれほど長くないことが確実な場合は、Adobe Campaign のフィールドを参照元のシステムのフィールドより短くしても構いません。 これにより、Adobe Campaign では短い文字列や小さい整数として扱うことができます。

フィールドの選択

ターゲティングやパーソナライゼーションに利用するフィールドは、テーブルに格納する必要があります。つまり、パーソナライズされた E メールの送信やクエリの基準として使用されないフィールドは、ディスク領域を消費しますが、無駄です。

ハイブリッドインスタンスおよびオンプレミスインスタンスの場合、FDA（Federated Data Access、外部データにアクセスするためのオプション機能）では、キャンペーンプロセス中にフィールドを「オンザフライ」で追加する必要性をカバーします。 FDA がある場合は、すべてを読み込む必要はありません。 詳しくは、Federated Data Access について を参照してください。

キーの選択

ほとんどのテーブルでデフォルトで定義されている autopk に加えて、論理キーまたはビジネスキー（アカウント番号、クライアント番号など）を追加することを検討してください。 後でデータのインポートや紐付け、データパッケージに使用できます。 詳細については、識別子を参照してください。

パフォーマンスを高めるには、効率的なキーが不可欠です。 テーブルのキーとして常に推奨されるのは、数値データ型です。

SQLServer データベースの場合、パフォーマンスが必要な場合は、「クラスター化インデックス」の使用を検討できます。 Adobeはこれを処理しないので、SQL で作成する必要があります。

専用テーブルスペース

スキーマの tablespace 属性を使用すると、表の専用表領域を指定できます。

インストールウィザードでは、タイプ（データ、一時、インデックス）別にオブジェクトを保存できます。

専用の表領域は、パーティション化、セキュリティ・ルールに適しており、流動的で柔軟な管理、最適化、パフォーマンスの向上を可能にします。

識別子

Adobe Campaign リソースには 3 つの識別情報があり、別の識別情報を追加することもできます。

これらの識別子とその目的を次の表に示します。

識別子 説明 ベストプラクティス
ID
  • ID は、Adobe Campaign テーブルの物理的なプライマリキーです。 標準のテーブルの場合、シーケンスから生成される 32 ビットの番号です
  • この識別子は、通常、特定のAdobe Campaignインスタンスに固有です。
  • 自動生成された ID は、スキーマ定義で表示できます。 autopk="true" 属性を検索します。
  • 自動生成された識別子は、ワークフローやパッケージ定義で参照として使用しないでください。
  • ID が常に増加する数であると仮定しないでください。
  • 標準のテーブルの ID は 32 ビットの数値で、この型は変更しないでください。 この番号は、の節で取り上げた「シーケンス」から同じ名前で取得されます。
名前（または内部名）
  • この情報は、テーブル内のレコードの一意の識別子です。 この値は、通常は生成された名前で手動で更新できます。
  • この識別子は、Adobe Campaign の別のインスタンスにデプロイされたときにその値を保持し、空にはしないでください。
  • オブジェクトをある環境から別の環境にデプロイする場合は、Adobe Campaign で生成されたレコード名を変更します。
  • オブジェクトに名前空間属性（schema​など）がある場合、この共通の名前空間は、作成されたすべてのカスタムオブジェクトで活用されます。 一部の予約済み名前空間は使用しないでください。nms、xtk、nl、ncl、crm、xxl。
  • オブジェクトに名前空間（workflow や delivery など）がない場合、この名前空間は内部名オブジェクトのプレフィックスとして追加されます（namespaceMyObjectName）。
  • スペース「 」、セミコロン「;」、ハイフン「-」などの特殊文字は使用しないでください。 これらの文字はすべて、アンダースコア「_」（許可されている文字）に置き換えられます。 例えば、「abc-def」と「abc:def」は「abc_def」として保存され、相互に上書きされます。
ラベル
  • ラベルは、Adobe Campaign 内のオブジェクトまたはレコードのビジネス識別子です。
  • このオブジェクトでは、スペースと特殊文字も使用できます。
  • レコードの一意性は保証されません。
  • オブジェクトラベルの構造を決定することをお勧めします。
  • これは、Adobe Campaign ユーザーにとって、レコードまたはオブジェクトを識別するための最も使いやすい解決策です。

カスタム内部キー

プライマリキーは、Adobe Campaign で作成されるすべてのテーブルに必要です。

ほとんどの組織は、外部システムからレコードを読み込んでいます。 受信者テーブルの物理キーは「id」属性ですが、さらにカスタムキーを特定することもできます。

このカスタムキーは、Adobe Campaign にフィードする外部システムの実際のレコードのプライマリキーです。

標準のテーブルに autopk と内部キーの両方がある場合、内部キーは物理データベーステーブル内の一意のインデックスとして設定されます。

カスタムテーブルを作成する場合は、次の 2 つのオプションがあります。

  • 自動生成されたキー（id）と内部キー（カスタム）の組み合わせ。 このオプションは、システムキーが複合キーであるか、整数ではない場合に役立ちます。 整数は、大きいテーブルで高いパフォーマンスを提供し、他のテーブルと結合できます。
  • プライマリキーを外部システムのプライマリキーとして使用します。 この解決策は、異なるシステム間で一貫したキーを使用してデータのインポートとエクスポートのアプローチを簡素化するので、通常は推奨されます。 キーの名前が「id」で、（自動生成ではなく）外部値が入力されると想定される場合は、autopk を無効にする必要があります。
重要

autopk は、ワークフロー内の参照として使用しないでください。

シーケンス

Adobe Campaignのプライマリキーは、すべての標準テーブルに対して自動生成される id で、カスタムテーブルに対して同じにできます。 詳しくは、この節を参照してください。

この値は、シーケンス と呼ばれる、番号シーケンスの生成に使用されるデータベースオブジェクトから取得されます。

シーケンスには次の 2 種類があります。

  • 共有:複数のテーブルが同じシーケンスから id を選択します。つまり、あるテーブルで ID「X」が使用されている場合、同じシーケンスを共有する他のテーブルには、その ID「X」のレコードは存在しません。 ​​XtkNewId は、Adobe Campaignで使用できるデフォルトの共有シーケンスです。
  • 専用:1 つのテーブルのみが、シーケンスから id を選択しています。シーケンス名には、通常、テーブル名が含まれます。
重要

シーケンスは整数の 32 ビット値で、使用可能な値の最大数は有限です。21 億 4000 万。 最大値に達した後、シーケンスは 0 に戻り、ID を再利用します。

古いデータがパージされなかった場合、一意のキー違反が発生し、プラットフォームの正常性と使用を妨げます。 Adobe Campaignは（配信ログテーブルに影響を与える場合）通信を送信できず、パフォーマンスに大きな影響を与えます。

したがって、顧客がログの保持期間が 180 日の電子メールを年 60 億件送信すると、4 か月で ID が不足します。 このような課題を回避するには、ボリュームに応じてパージ設定を必ず設定します。 詳しくは、この節を参照してください。

プライマリキーを autoPK としてAdobe Campaignでカスタムテーブルを作成する場合、カスタム専用シーケンスをそのテーブルに体系的に関連付ける必要があります。

デフォルトでは、カスタムシーケンスの値は+1,000 ～ +2.1 BB です。 技術的には、負の ID を有効にすることで、4BB のフルレンジを得ることができます。 これは慎重に使用する必要があり、負の数から正の数への交差時に 1 つの ID が失われます。通常、生成された SQL クエリでは、レコード 0 はAdobe Campaignで無視されます。

関連トピック：

  • シーケンス自動生成 機能について詳しくは、 このドキュメント を参照してください。
  • シーケンスが枯渇した場合の詳細については、 このビデオ をご覧ください。

インデックス

インデックスはパフォーマンスに不可欠です。 スキーマでキーを宣言すると、Adobeは自動的にキーのフィールドにインデックスを作成します。 また、キーを使用しないクエリに対して、さらに多くのインデックスを宣言することもできます。

Adobeでは、パフォーマンスが向上する可能性があるので、追加のインデックスを定義することをお勧めします。

ただし、次の点に注意してください。

  • インデックスの使用は、アクセスパターンに結び付けられています。 インデックス作成の最適化は、多くの場合、データベース設計の重要な部分であり、エキスパートが処理する必要があります。 インデックスの追加は、多くの場合、データベースのメンテナンスに関連付けられた反復的なワークフローです。 時間の経過と共に段階的に実行され、発生時のパフォーマンスの問題に対処します。
  • インデックスを使用すると、（インデックス自体を格納する）テーブル全体のサイズが大きくなります。
  • カラムにインデックスを追加すると、データ読み取りアクセス (SELECT) のパフォーマンスが向上しますが、データ書き込みアクセス (UPDATE) のパフォーマンスが低下する可能性があります。
  • これはデータの挿入中にパフォーマンスに影響を与えるので、インデックスのサイズと数は制限する必要があります。
  • 不要な場合はインデックスを追加しないでください。 必須であることと、クエリ（テストおよび学習）の全体的なパフォーマンスが向上することを確認します。
  • 一般に、クエリがレコードの 10%を超えないことがわかっている場合は、インデックスが効率的です。
  • 定義する必要があるインデックスは慎重に選択してください。
  • 標準テーブルからネイティブインデックスを削除しないでください。

例

インデックスの管理は非常に複雑になる場合があるので、その仕組みを理解することが重要です。 この複雑さを説明するために、姓と名をフィルタリングして受信者を検索するなど、基本的な例を見てみましょう。 手順は次のとおりです。

  1. データベース内のすべての受信者を一覧表示するフォルダーに移動します。 詳しくは、 プロファイルの管理 を参照してください。

  2. 名 フィールドを右クリックします。

  3. 「このフィールドでフィルター」を選択します。

  4. 姓 フィールドに対して、この操作を繰り返します。

対応する 2 つのフィルターが画面の上部に追加されます。

様々なフィルター条件に従って、「名」および「姓」フィールドに対して検索フィルターを実行できるようになりました。

これらのフィルターの検索を高速化するために、インデックスを追加できます。 しかし、どのインデックスを使用する必要がありますか？

メモ

この例は、PostgreSQL データベースを使用するホスト型のお客様に当てはまります。

次の表に、最初の列に表示されるアクセスパターンに従って、以下の 3 つのインデックスが使用される場合と使用されない場合を示します。

検索条件 インデックス 1（名+姓） インデックス 2（名のみ） インデックス 3（姓のみ） コメント
名が「Johnny」に等しい 使用済み 使用済み 未使用 名はインデックス 1 の最初の位置にあるので、いずれにしても使用されます。姓に基準を追加する必要はありません。
名が「Johnny」に等しい、姓が「Smith」に等しい 使用済み 未使用 未使用 両方の属性が同じクエリで検索されるので、両方の属性を組み合わせたインデックスのみが使用されます。
姓が「Smith」と等しい 未使用 未使用 使用済み インデックス内の属性の順序が考慮されます。 この順序が一致しない場合、インデックスは使用されない可能性があります。
名が「Joh」で始まる 使用済み 使用済み 未使用 「左検索」ではインデックスが有効になります。
名が「nny」で終わる 未使用 未使用 未使用 「右検索」を選択すると、インデックスが無効になり、フルスキャンが実行されます。 一部の特定のインデックスタイプでこの使用例を処理できますが、Adobe Campaignではデフォルトで使用できません。
名に「John」が含まれる 未使用 未使用 未使用 「左」検索と「右」検索の組み合わせです。 後者のため、インデックスが無効になり、完全なスキャンが実行されます。
名が「john」に等しい 未使用 未使用 未使用 インデックスでは大文字と小文字が区別されます。 大文字と小文字を区別しないようにするには、「upper(firstname)」のような SQL 関数を含む特定のインデックスを作成する必要があります。 「unaccent(firstname)」など、他のデータ変換も同じ処理を行う必要があります。

大きなテーブルでは、「own」整合性に注意してください。 完全性が「own」のワイド・テーブルを持つレコードを削除すると、インスタンスが停止する場合があります。 テーブルはロックされ、削除は 1 つずつ行われます。 したがって、大型の子テーブルには「neutral」整合性を使用することをお勧めします。

リンクを外部結合として宣言すると、パフォーマンスが悪くなります。ゼロ ID レコードは外部結合機能をエミュレートします。 リンクが autopk を使用する場合、外部結合を宣言する必要はありません。

ワークフロー内の任意のテーブルを結合できますが、リソース間の共通リンクをデータ構造の定義に直接定義することをお勧めします。

リンクは、テーブル内の実際のデータと整合するように定義する必要があります。 誤った定義は、レコードの予期しない複製など、リンクを介して取得したデータに影響を与える可能性があります。

リンクには、テーブル名と一致する名前を付けます。リンク名は遠隔テーブルの内容を理解するのに役立ちます。

「id」をサフィックスとして含む名前をリンクに付けないでください。 例えば、「transactionId」ではなく「transaction」という名前を付けます。

デフォルトでは、Adobe Campaign は外部テーブルのプライマリキーを使用してリンクを作成します。 わかりやすくするために、リンク定義で結合を明示的に定義することをお勧めします。

リンクで使用される属性にインデックスが追加されます。

​10. created-by リンクと last-modified-by リンクは、多くのテーブルに存在します。 この情報がビジネスで使用されていない場合は、リンクの属性 noDbIndex を使用してインデックスを無効にできます。

カーディナリティ

リンクを設計する場合は、1-1 関係が宣言されているときに、ターゲットレコードが一意になることを確認します。 そうでない場合は、結合の結果、1 つであるはずのレコードが複数返される可能性があります。 これにより、「クエリが想定以上の行を返す」場合、配信の準備中にエラーが発生します。 リンク名をターゲットスキーマと同じ名前に設定します。

(1) 側のスキーマにカーディナリティ(1-N) のリンクを定義します。 例えば、受信者 (1) - (N) トランザクションという関係は、トランザクションスキーマ内で定義してください。

デフォルトでは、リンクの逆カーディナリティは (N) なので注意してください。 リンク定義に revCardinality='single' という属性を追加することで、リンク (1-1) を定義できます。

逆リンクをユーザーに表示しない場合は、リンク定義 revLink='NONE' を使用して非表示にできます。 例えば、受信者から最後に完了したトランザクションへのリンクを定義する場合が、これに該当するユースケースです。 受信者から最後のトランザクションへのリンクのみ表示されればよく、トランザクションテーブルからの逆リンクを表示する必要はありません。

外部結合 (1-0…1) を実行するリンクは、システムのパフォーマンスに影響を与えるので、慎重に使用してください。

データ保持 — クリーンアップとパージ

Adobe Campaign はデータウェアハウスでもレポートツールでもありません。 したがって、Adobe Campaign ソリューションの高いパフォーマンスを確保するには、データベースの増大を抑制する必要があります。 これを達成するには、以下のベストプラクティスが役に立ちます。

デフォルトでは、Adobe Campaignの配信ログとトラッキングログの保持期間は 180 日です。 クリーンアッププロセスが実行され、それより古いログが削除されます。

  • ログを長く保つ場合は、データベースのサイズと送信されるメッセージの量に応じて、この決定を慎重におこなう必要があります。 Adobe Campaignのシーケンスは 32 ビットの整数です。
  • これらの表では、一度に 10 億個を超えるレコードを使用しないこと（21 億 4,000,000 ID の約 50%）をお勧めし、使用可能なすべての ID を消費するリスクを制限します。 この場合、一部のお客様は、保持期間を 180 日未満に短縮する必要があります。

データ保持について詳しくは、Campaign のプライバシーとセキュリティのガイドライン を参照してください。

Campaign データベースのクリーンアップワークフロー について詳しくは、この節 を参照してください。

重要

カスタムテーブルは標準のクリーンアップ処理で削除されません。 この処理は初日には必要ないとしても、パフォーマンス上の問題を引き起こす可能性があるので、カスタムテーブルのパージ処理を作成することを忘れないでください。

Adobe Campaign 内のレコードの必要性を最小限に抑えるには、いくつかの解決策があります。

  • Adobe Campaign 外部の Data Warehouse にデータをエクスポートする。
  • 使用するデータ容量が小さいながらもマーケティング活動には十分な集計値を生成する。例えば、最後の購入を追跡することが目的であれば、Adobe Campaign の顧客トランザクション履歴をすべて残す必要はありません。

「deleteStatus」属性はスキーマで宣言できます。 レコードを削除済みとマークしてから、後でクリーンアップタスクで削除する方が効率的です。

パフォーマンス

常にパフォーマンスの向上を図るには、次のベストプラクティスに従います。

一般的な推奨事項

  • クエリで「CONTAINS」などの演算子は使用しません。 フィルタリングしたい対象がはっきりしている場合は、「EQUAL TO」または他の特定のフィルター演算子を使用して同じ条件を適用します。
  • ワークフローでデータを作成する際は、インデックスが付いていないフィールドとの結合を避けます。
  • インポートやエクスポートなどのプロセスは営業時間外に行われるようにします。
  • 日常のすべてのアクティビティがわかるスケジュールがあることを確認して、そのスケジュールに従います。
  • 日常的なプロセスの 1 つまたはいくつかが失敗し、その同じ日に実行する必要がある場合があります。手動でプロセスを開始する際は、システムのパフォーマンスに影響を与える可能性があるので、競合するプロセスが実行されていないことを確認します。
  • インポートプロセスを実行中、または手動プロセスを実行したときに、日常的なキャンペーンが実行されていないことを確認します。
  • すべての行にフィールドを複製するのではなく、参照テーブルを使用します。キーと値のペアを使用する場合は、数値キーを選択することをお勧めします。
  • 短い文字列は引き続き使用できます。 参照テーブルが外部システムに配置されている場合、それを再利用すると、Adobe Campaign とのデータ統合が容易になります。

1 対多の関係

  • データ設計は使い勝手と機能性に影響を与えます。 1 対多の関係を多く持つデータモデルを設計すると、ユーザーがアプリケーション内で意味のあるロジックを作成するのが難しくなります。 マーケターが技術者でない場合は、1 対多のフィルターロジックを正しく理解して構築するのは困難なことがあります。
  • 必須フィールドをすべて 1 つのテーブルにまとめておくと、クエリの作成が容易になります。 結合を回避できれば、テーブル間でいくつかのフィールドを複製することもパフォーマンス的には良い場合があります。
  • オファーの重み付けの式や配信などのように、1 対多の関係を参照できない組み込み機能もあります。

大きいテーブル

Adobe Campaign は、サードパーティのデータベースエンジンを活用しています。 プロバイダーによっては、大きいテーブルに対するパフォーマンスを最適化するために、特定のデザインが必要になる場合があります。

大きいテーブルと複雑な結合を使用したデータモデルを設計する場合は、以下のような一般的なベストプラクティスに従う必要があります。

  • 追加のカスタム受信者テーブルを使用する場合は、配信マッピングごとに専用のログテーブルを使用します。
  • 列の数を減らします。特に、未使用の列を特定して削減します。
  • 複雑な結合を回避して、データモデルのリレーションを最適化します。たとえば、複数の条件や複数の列に対する結合を回避します。
  • 結合キーには、文字列ではなく常に数値データを使用します。
  • ログを保持する深さをできる限り減らします。 深い履歴が必要な場合は、集計の計算やカスタムログテーブルの処理を行うと、大きな履歴を保存できます。

テーブルのサイズ

テーブルサイズは、レコード数とレコードあたりの列数の組み合わせです。 いずれも、クエリのパフォーマンスに影響を与える可能性があります。

  • 小さいサイズ​のテーブルは、配信テーブルに似ています。
  • 中程度のサイズ​のテーブルは、受信者テーブルと同じくらいのサイズです。 顧客 1 人につき 1 件のレコードがあります。
  • 大きいサイズ​のテーブルは、広範ログテーブルに似ています。 1 人の顧客につき多くのレコードがあります。
    例えば、データベースに 1,000 万人の受信者が含まれている場合、広範ログテーブルには 1 億件から 2 億件くらいのメッセージが格納され、配信テーブルには数千件のレコードが格納されます。

PostgreSQL では、行が 8 KB を超えてはなりません。これは、TOAST メカニズムを回避するためです。 したがって、システム（メモリと CPU）の最適なパフォーマンスを維持するために、列数と各行のサイズをできるだけ小さくしてください。

行数もパフォーマンスに影響します。 Adobe Campaign データベースは運用データベースであり、ターゲティングやパーソナライゼーションにあまり使用しない履歴データを格納するようには設計されていません。

行数の増加に伴うパフォーマンス上の問題を防ぐには、必要なレコードのみをデータベースに保存します。 その他のレコードは、サードパーティのデータウェアハウスにエクスポートし、Adobe Campaign 運用データベースから削除する必要があります。

テーブルサイズに関するベストプラクティスのいくつかを次に示します。

  • フィールド数が少なく数値データが多い大きなテーブルを設計します。
  • 多数の列を使用しない ( 例：Int64) を使用して、ブール値などの小さな数値を格納します。
  • 未使用の列をテーブル定義から削除します。
  • 履歴データや非アクティブなデータはエクスポートして消去し、Adobe Campaign データベースには保持しません。

次に例を示します。

この例では、

  • トランザクション および トランザクション項目 テーブルは大きいです。1 千万以上。
  • Product および Store テーブルは小さくなっています。1 万未満
  • 製品のラベルと参照が Product テーブルに配置されています。
  • トランザクション項目 テーブルには、Product テーブル（数値）へのリンクのみが含まれます。

このページ