翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 比較コントロール
SQL では、リテラル比較は、データセットの列をクエリに直接入力されたリテラル値と照合します。列比較は、同じテーブル内または結合されたテーブル間で、2 つの異なる列の値を互いに照合します。
## デフォルトの 動作
比較コントロールは許可リストです。を設定すると`allowedLiteralComparisonColumns`、リストする列のみがリテラル値と比較され、リストしないすべての列がブロックされます。column-to-column比較`allowedColumnComparisonColumns`の場合も同様です。一方の許可リストに列を追加しても、もう一方の許可リストには列は追加されません。
を設定しない場合`comparisonControls`、 は比較制限 AWS Clean Rooms を適用しません。クエリは任意の列をリテラル値または別の列と比較できます。
を設定せずに最小集約しきい値を設定`comparisonControls`した場合、比較は制限されません。ただし、 でリストされている列でリテラル比較を許可 AWS Clean Rooms しないでください`identityColumns`。この制限はしきい値自体から取得されるため、比較コントロールを設定するかどうかにかかわらず適用されます。詳細については、「[最小集計しきい値](custom-min-agg-thresholds.md)」を参照してください。
許可されていない出力列`comparisonControls`とともに を設定する場合、2 つのコントロールは独立しており、両方が適用されます。比較コントロールは、クエリが比較できる列を制御します。許可されていない出力列は、クエリ結果に表示される列を制御します。列は比較で許可でき、結果から除外されます。詳細については、「[許可されない出力列](disallowed-output-columns.md)」を参照してください。
## リテラル比較
リテラル比較は、1 つのハードコードされた定数 (文字列、数値、または日付) に対して列を評価します。クエリの実行中に演算子の右側が変更されることはありません。構文の例は次のとおりです。
+ WHERE status = 'Active'
+ WHERE 料金 > 49.99
を使用する場合[最小集計しきい値](custom-min-agg-thresholds.md)、 AWS Clean Rooms は`identityColumns`値に対するリテラル比較を許可しません。これにより、クエリランナーが個々のユーザーまたは特定のユーザーのセットにフィルタリングされたクエリを送信できなくなります。小さなグループや個々のデータサブジェクトを除外できる低基数列でリテラル比較を許可しないでください。
```
{
"comparisonControls": {
"allowedLiteralComparisonColumns": [
"status",
"price"
]
}
}
```
**リテラル比較用の列の選択**
リテラル比較は、個人や小グループを識別しない列でのみ許可します。低カーディナリティ列 (age\_band、粗いリージョンコードなど) で許可することは避けてください。これらの列は設定値ではありませんが`identityColumns`、リテラルと比較すると、結果を小さく識別可能な母集団に絞り込むことができます。`campaign_id` や などのカーディナリティが高く、識別できないディメンション`product_sku`の方が安全です。
### 例: キャンペーン列でのリテラル比較の許可
パブリッシャーは、すべての出力行が少なくとも 100 人の個別のユーザー () を表すように、最小集約しきい値でカスタム分析ルールを設定します`user_id`。広告主はこのテーブルに対してクエリを実行しますが、一度に 1 つのキャンペーンのリーチを測定するなど、分析の範囲を特定の広告キャンペーンに絞り込む必要があります。
`user_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 never be compared to a literal
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 つの行の値を別の列の値と動的に評価します。構文の例は次のとおりです。
+ WHERE retail\_price < wholesale\_price
+ WHERE users.id = orders.user\_id
を使用する場合[最小集計しきい値](custom-min-agg-thresholds.md)、データプロバイダーは、オーディエンスの重複レポートなど、テーブル間で結合する必要があるユースケース`identityColumns`の値の列比較を許可できます。
```
{
"comparisonControls": {
"allowedColumnComparisonColumns": [
"user_id"
]
}
}
```
### 例: 重複レポートの ID 列で列比較を許可する
パブリッシャーとアドバタイザーは、対象者の重複、つまり両方のデータセットに表示されるユーザーの数を、個々のユーザーが誰であるかを知ることなく測定したいと考えています。これには、column-to-column比較である `user_id`の 2 つのテーブルを結合する必要があります。パブリッシャーは、特定のキャンペーン IDs を対象とする対象者の重複分析をアドバタイザーが実行できるようにします。
`user_id` は ID 列であるため、パブリッシャーはすでにリテラル比較をブロックしています (そのため、誰も特定の人物にフィルタリングすることはできません）。テーブル間の結合を有効にするために、パブリッシャーは `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`されます。
## 比較コントロールと式
比較コントロールは、直接WHERE`column = 'literal'`述語だけでなく、間接的なリテラル比較に従います。を通じて集計関数`ANY_EXPRESSION`の内部を許可しても`allowedAggregateExpressionType`、比較コントロールは にない列のリテラル比較をブロックします`allowedLiteralComparisonColumns`。これは、リテラルが式内にネストされている場合にも当てはまります。
次の例は、リテラルが直接述語として記述されるのではなく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 つのコントロールは補完的です。集計内で式を許可すると、クエリが計算できる範囲が広がりますが、比較コントロールはクエリが値でどの列を除外できるかを制限します。詳細については、「[集計関数でネストされた式を許可する](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions)」を参照してください。