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

このドキュメントでは、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で作成する必要があります。

専用テーブルスペース

スキーマのテーブルスペース属性を使用すると、テーブル専用のテーブルスペースを指定できます。

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

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

識別子

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万。 最大値に達した後、IDを再利用するためにシーケンスが0に戻ります。

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

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

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

デフォルトでは、カスタムシーケンスの値は+1,000 ～ +2.1BBです。 技術的には、負の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. 作成者および最終変更者のリンクは、多くのテーブルに存在します。 この情報がビジネスで使用されていない場合は、リンクで属性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億4000万IDの約50%）をお勧めし、使用可能なすべてのIDを消費するリスクを抑えます。 この場合、一部のお客様は、保持期間を180日未満に抑える必要があります。

キャンペーンのプライバシーとセキュリティのガイドラインでのデータ保持について詳しく説明します。

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では、TOASTメカニズムを回避するために、行が8 KBを超えないようにする必要があります。 したがって、システム（メモリとCPU）の最適なパフォーマンスを維持するために、列数と各行のサイズをできるだけ小さくしてください。

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

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

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

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

次に例を示します。

この例では、次のようになります。

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

このページ