翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

比較コントロール

SQL では、リテラル比較はデータセットの列をクエリに直接入力されたリテラル値と照合します。列比較は、同じテーブル内または結合されたテーブル間で、2 つの異なる列の値を互いに照合します。

デフォルトの 動作

比較コントロールは許可リストです。を設定するとallowedLiteralComparisonColumns、リストする列のみがリテラル値と比較され、リストしないすべての列がブロックされます。ただし、常に許可されている値との比較は除きます。詳細については、「常に許可されるリテラル値」を参照してください。column-to-column比較allowedColumnComparisonColumnsの場合も、同じ許可リスト動作が に適用されます。一方の許可リストに列を追加しても、もう一方の許可リストには列は追加されません。

を設定しない場合comparisonControls、 は比較制限 AWS Clean Rooms を適用しません。クエリは任意の列をリテラル値または別の列と比較できます。

を設定せずに最小集約しきい値を設定comparisonControlsした場合、比較は制限されません。ただし、 にリストされている列ではリテラル比較は許可 AWS Clean Rooms されませんidentityColumns。唯一の例外は、常に許可されている値との比較です。この制限はしきい値自体から取得されるため、比較コントロールを設定するかどうかにかかわらず適用されます。詳細については、「最小集計しきい値」および「常に許可されるリテラル値」を参照してください。

許可されていない出力列comparisonControlsとともに を設定する場合、2 つのコントロールは独立しており、両方が適用されます。比較コントロールは、クエリが比較できる列を制御します。許可されていない出力列は、クエリ結果に表示される列を制御します。列は比較で許可でき、結果から除外されます。詳細については、「許可されない出力列」を参照してください。

リテラル比較

リテラル比較は、1 つのハードコードされた定数 (文字列、数値、日付、ブール値、 など) に対して列を評価しますNULL。クエリの実行中に演算子の右側が変更されることはありません。構文の例は次のとおりです。

を使用する場合最小集計しきい値、 AWS Clean Rooms は、常に許可されるidentityColumns値を除いて、値に対するリテラル比較を許可しません (「」を参照常に許可されるリテラル値)。これにより、クエリランナーが個々のユーザーまたは特定のユーザーのセットにフィルタリングされたクエリを送信できなくなります。小さなグループや個々のデータセットを除外できる低基数列でリテラル比較を許可しないでください。

{
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ]
  }
}

常に許可されるリテラル値

AWS Clean Rooms では、列が にリストされていないallowedLiteralComparisonColumnsか、 にリストされている場合でも、常に許可される値と呼ばれる次のリテラル値と列を比較できますidentityColumns。

これらの値は固定されているため、クエリランナーはデータ内の特定の値をターゲットにするように変更することはできません。

これは、列を直接比較する場合、または CASE、、IF、 COALESCEなどの式内で比較する場合に適用されますUPPER。列が別の関数または算術 ( ABS(revenue) = 0や などrevenue - 50 = 0) でラップされている場合、比較は比較コントロールに従います。

などの他の数値を含む他のリテラル値との比較は1、比較コントロールに従い、ID 列の場合は最小集約しきい値制限に従います。最小集計しきい値を設定しても、クエリ結果のすべての行に適用されます。

たとえば、列が にリストされていない場合でも、次の各条件が許可されますallowedLiteralComparisonColumns。

-- Allowed: comparisons against always-allowed values
WHERE user_id IS NOT NULL
WHERE revenue > 0
WHERE is_active = true

列が にリストされていない場合、以下の各条件はブロックされますallowedLiteralComparisonColumns。

-- Blocked: other literal values, or a column wrapped in a function
WHERE revenue > 1
WHERE status_code = '0'
WHERE ABS(revenue) = 0

例: キャンペーン列でのリテラル比較の許可

パブリッシャーは、すべての出力行が少なくとも 100 人の個別のユーザー () を表すように、最小集約しきい値でカスタム分析ルールを設定しますuser_id。広告主はこのテーブルに対してクエリを実行しますが、一度に 1 つのキャンペーンのリーチを測定するなど、分析の範囲を特定の広告キャンペーンに絞り込む必要があります。

user_id は ID 列であるため、特定のユーザー ID などのリテラルと比較することはできません。これにより、広告主が結果を 1 人のユーザーにフィルタリングするのを防ぐことができます。ただし、 campaign_idと event_dateはカーディナリティが高く、識別できないディメンションであるため、パブリッシャーはそれらを に追加します。これによりallowedLiteralComparisonColumns、広告主はキャンペーンでフィルタリングし、分析を日付範囲に絞り込むことができます。

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id", "event_date"]
  }
}

上記の設定の場合、このクエリは許可されます。

-- Allowed: campaign_id and event_date are both in allowedLiteralComparisonColumns
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE campaign_id = 'CMP-1024'
  AND event_date >= '2026-01-01'
GROUP BY campaign_id;

同じ設定の場合、このクエリはブロックされます。

-- Blocked: user_id is the identity column and can't be compared to a specific user ID
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE user_id = 'U-88231'
GROUP BY campaign_id;

最初のクエリは、少なくとも 100 人の個別のユーザーによってバックアップされた行のみを返しますが、リテラル比較campaign_idでは、考慮される行がevent_dateフィルタリングされます。2 番目のクエリは、個々のデータセットを分離しようとするため拒否されます。

列の比較

列比較では、1 つの列の値を、1 行ごとに別の列の値を動的に評価します。構文の例は次のとおりです。

を使用する場合最小集計しきい値、データプロバイダーは、オーディエンスの重複レポートなど、テーブル間で結合する必要があるユースケースidentityColumnsの値の列比較を許可できます。

{
  "comparisonControls": {
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  }
}

例: 重複レポートの ID 列で列比較を許可する

パブリッシャーとアドバタイザーは、対象者の重複、つまり両方のデータセットに表示されるユーザーの数を、個々のユーザーが誰であるかを知ることなく測定したいと考えています。これには、column-to-column比較である user_idで 2 つのテーブルを結合する必要があります。パブリッシャーは、特定のキャンペーン IDs を対象とする対象者の重複分析をアドバタイザーが実行できるようにします。

user_id は ID 列であるため、 AWS Clean Rooms はそれをユーザー ID などの特定の値と比較することを既にブロックしています。これにより、1 人のユーザーに直接フィルタリングされるのを防ぐことができます。テーブル間の結合を有効にするために、パブリッシャーは user_idを に追加しますallowedColumnComparisonColumns。キャンペーンフィルタリングを有効にするために、パブリッシャーは campaign_idを に追加しますallowedLiteralComparisonColumns。

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id"],
    "allowedColumnComparisonColumns": ["user_id"]
  }
}

上記の設定の場合、このクエリは許可されます。

-- Allowed: user_id is compared against another column (column-to-column join)
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
ON p.user_id = a.user_id;

同じ設定の場合、このクエリはブロックされます。

-- Blocked: email is not in allowedColumnComparisonColumns
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
  ON p.email = a.email;

column-to-column比較は行ごとに動的に評価され、クエリランナーが既知の値をターゲットにしないため、結合は成功します。その結果、最小集計しきい値が適用され、少なくとも 100 人の個別のユーザーを表す場合にのみ重複カウントが返されます。2 番目のクエリは、 email がallowedColumnComparisonColumns許可リストに含まれておらず、比較に使用できないため、ブロックuser_idされます。

比較コントロールと式

比較コントロールは、直接WHEREcolumn = 'literal'述語だけでなく、間接的なリテラル比較に従います。を通じて集計関数ANY_EXPRESSIONの内部を許可してもallowedAggregateExpressionType、比較コントロールは にない列のリテラル比較をブロックしますallowedLiteralComparisonColumns。これは、リテラルが式内にネストされている場合でも適用されます。 AWS Clean Rooms では、CASE、、IF、 COALESCEなどの式内で常に許可されている値と比較できますUPPER。たとえば、 SUM(CASE WHEN bonus = 0 THEN salary ELSE 0 END) は許可されます。詳細については、「常に許可されるリテラル値」を参照してください。

次の例は、リテラルが直接述語として記述されるのではなくCASE式内にある場合でも、 zip_codeが許可リストに含まれていないため、ブロックされたままのクエリを示しています。

-- Blocked: zip_code is not in allowedLiteralComparisonColumns,
-- even though the literal comparison is nested inside a CASE expression
SELECT SUM(CASE WHEN zip_code = '00001' THEN salary ELSE 0 END) AS total
FROM employees;

このため、2 つのコントロールは補完的です。集計内で式を許可すると、クエリが計算できる範囲が広がりますが、比較コントロールはクエリが値でどの列を除外できるかを制限します。詳細については、「集計関数でネストされた式を許可する」を参照してください。