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

このドキュメントでは、Adobe 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 について.

キーの選択

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

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

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 万。 最大値に達した後、シーケンスは ID をリサイクルするために 0 に戻されます。

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

したがって、顧客が年間 60 億通の E メールを送信し、そのログの保持期間が 180 日の場合、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 は外部テーブルのプライマリキーを使用してリンクを作成します。わかりやすくするために、リンク定義で結合を明示的に定義することをお勧めします。

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

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

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

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

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

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

次に例を示します。

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

  • この トランザクション および トランザクション項目 テーブルが大きい：1,000 万以上。
  • この 製品 および ストア テーブルは小さくなります。1 万未満。
  • 製品ラベルと参照が 製品 表。
  • この トランザクション項目 テーブルには 製品 表（数値）

このページ