기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 비교 제어
SQL에서 리터럴 비교는 데이터 세트의 열을 쿼리에 직접 입력된 리터럴 값과 일치시킵니다. 열 비교는 동일한 테이블 내에서 또는 조인된 테이블 간에 서로 다른 두 열의 값을 일치시킵니다.
## 기본 동작
비교 컨트롤은 허용 목록입니다. 를 설정한 후에는 나열한 열`allowedLiteralComparisonColumns`만 리터럴 값과 비교할 수 있으며 나열하지 않은 모든 열은 차단됩니다. column-to-column 비교의 `allowedColumnComparisonColumns` 경우에도에 적용됩니다. 한 허용 목록에 열을 추가해도 다른 허용 목록에는 추가되지 않습니다.
를 구성하지 않으면 비교 제한이 `comparisonControls` AWS Clean Rooms 적용되지 않습니다. 쿼리는 모든 열을 리터럴 값 또는 다른 열과 비교할 수 있습니다.
를 구성하지 `comparisonControls` 않지만 최소 집계 임계값을 설정하면 비교가 제한되지 않습니다. 그러나에 나열된 열에 대한 리터럴 비교를 허용하지 AWS Clean Rooms 않습니다`identityColumns`. 이러한 제한은 임계값 자체에서 비롯되므로 비교 제어를 구성하는지 여부에 관계없이 적용됩니다. 자세한 내용은 [최소 집계 임계값](custom-min-agg-thresholds.md) 단원을 참조하십시오.
허용되지 않는 출력 열과 `comparisonControls` 함께를 구성하는 경우 두 컨트롤은 독립적이며 둘 다 적용됩니다. 비교 제어는 쿼리가 비교할 수 있는 열을 제어하고, 허용되지 않는 출력 열은 쿼리 결과에 나타날 수 있는 열을 제어합니다. 비교에서 열을 허용해도 결과에서 계속 금지할 수 있습니다. 자세한 내용은 [허용되지 않는 출력 열](disallowed-output-columns.md) 단원을 참조하십시오.
## 리터럴 비교
리터럴 비교는 하드코딩된 단일 상수(문자열, 숫자 또는 날짜)를 기준으로 열을 평가합니다. 쿼리 실행 중에는 연산자의 오른쪽이 변경되지 않습니다. 구문 예제는 다음과 같습니다.
+ WHERE 상태 = '활성'
+ WHERE 가격 > 49.99
[최소 집계 임계값](custom-min-agg-thresholds.md)를 사용하는 경우 `identityColumns` 값에 대한 리터럴 비교를 허용하지 AWS Clean Rooms 않습니다. 이렇게 하면 쿼리 실행기가 개별 또는 특정 사용자 집합으로 필터링된 쿼리를 제출할 수 없습니다. 소그룹 또는 개별 데이터 주체를 제거할 수 있는 낮은 카디널리티 열에서 리터럴 비교를 허용하지 마세요.
```
{
"comparisonControls": {
"allowedLiteralComparisonColumns": [
"status",
"price"
]
}
}
```
**리터럴 비교를 위한 열 선택**
개인 또는 소규모 그룹을 식별하지 않는 열에 대해서만 리터럴 비교를 허용합니다. 카디널리티가 낮은 열(예: age\_band, 대략적인 리전 코드)에는 허용하지 마세요. 이러한 열은 구성된 `identityColumns` 값이 아니지만 리터럴과 비교하면 결과를 식별 가능한 작은 모집단으로 좁힐 수 있습니다. `campaign_id` 또는와 같이 카디널리티가 높고 식별되지 않는 차원`product_sku`은 더 안전한 선택입니다.
### 예: 캠페인 열에서 리터럴 비교 허용
게시자는 모든 출력 행이 최소 100명의 개별 사용자()를 나타내도록 최소 집계 임계값으로 사용자 지정 분석 규칙을 구성합니다`user_id`. 광고주는이 테이블에 대해 쿼리를 실행하지만 분석 범위를 특정 광고 캠페인으로 지정해야 합니다. 예를 들어 한 번에 하나의 캠페인에 대한 도달 범위를 측정해야 합니다.
`user_id`는 자격 증명 열이므로 리터럴과 비교할 수 없으므로 광고주는 결과를 단일 사용자로 필터링할 수 없습니다. 그러나 `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` 필터링합니다. 두 번째 쿼리는 개별 데이터 주체를 제거하려고 시도하기 때문에 거부됩니다.
## 열 비교
열 비교는 모든 단일 행에 대해 한 열의 값을 다른 열의 값과 동적으로 평가합니다. 구문 예제는 다음과 같습니다.
+ WHERE retail\_price < wholesale\_price
+ WHERE users.id = order.user\_id
[최소 집계 임계값](custom-min-agg-thresholds.md)를 사용할 때 데이터 공급자는 대상 중복 보고서와 같이 테이블 간에 조인해야 하는 사용 사례의 `identityColumns` 값에 대한 열 비교를 허용할 수 있습니다.
```
{
"comparisonControls": {
"allowedColumnComparisonColumns": [
"user_id"
]
}
}
```
### 예: 중복 보고서의 자격 증명 열에 대한 열 비교 허용
게시자와 광고주는 개별 사용자가 누구인지 어느 당사자도 학습하지 않고 두 데이터 세트에 표시되는 사용자 수와 같은 대상 중복을 측정하려고 합니다. 이를 위해서는 column-to-column 비교`user_id`인에서 두 테이블을 조인해야 합니다. 게시자를 통해 광고주는 특정 캠페인 IDs.
`user_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명의 개별 사용자를 나타내는 경우에만 반환되도록 합니다. 가 `allowedColumnComparisonColumns` 허용 목록에 없고 비교에 사용할 수 없으므로 두 번째 쿼리`email`는 차단됩니다. 만 사용할 `user_id` 수 있습니다.
## 비교 제어 및 표현식
비교 제어는 직접 WHERE `column = 'literal'` 조건자뿐만 아니라 간접 리터럴 비교를 따릅니다. 를 통해 집계 함수 `ANY_EXPRESSION` 내부를 허용하는 경우 `allowedAggregateExpressionType`비교 제어는에 없는 열에 대한 리터럴 비교를 여전히 차단합니다`allowedLiteralComparisonColumns`. 이는 리터럴이 표현식 내에 중첩된 경우에도 적용됩니다.
다음 예제에서는 리터럴이 직접 조건자로 작성`zip_code`되지 않고 CASE 표현식 내에 있더라도가 허용 목록에 없기 때문에 차단된 상태로 유지되는 쿼리를 보여줍니다.
```
-- 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;
```
이것이 두 컨트롤이 보완적인 이유입니다. 집계 내에서 표현식을 허용하면 쿼리가 계산할 수 있는 범위가 넓어지는 반면 비교 컨트롤은 쿼리가 값별로 구분할 수 있는 열을 여전히 제한합니다. 자세한 내용은 [집계 함수에서 중첩 표현식 허용](custom-min-agg-thresholds.md#custom-min-agg-nested-expressions) 단원을 참조하십시오.