Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôles de comparaison

En SQL, la comparaison littérale fait correspondre une colonne de votre ensemble de données à une valeur littérale saisie directement dans la requête. La comparaison de colonnes met en correspondance les valeurs de deux colonnes différentes, soit dans la même table, soit dans des tables jointes.

Comportement par défaut

Les contrôles de comparaison constituent une liste d'autorisations. Une fois que vous avez définiallowedLiteralComparisonColumns, seules les colonnes que vous répertoriez peuvent être comparées à une valeur littérale, et chaque colonne que vous ne répertoriez pas est bloquée. Il en va de même allowedColumnComparisonColumns pour les comparaisons colonne à colonne. L'ajout d'une colonne à une liste autorisée ne l'ajoute pas à l'autre.

Si vous ne configurez pascomparisonControls, n' AWS Clean Rooms applique aucune restriction de comparaison : une requête peut comparer n'importe quelle colonne à une valeur littérale ou à une autre colonne.

Si vous ne configurez pas comparisonControls mais que vous définissez un seuil d'agrégation minimum, les comparaisons restent par ailleurs illimitées. Cependant, AWS Clean Rooms n'autorise jamais une comparaison littérale sur une colonne répertoriée dansidentityColumns. Cette restriction provient du seuil lui-même. Elle s'applique donc que vous configuriez ou non les contrôles de comparaison. Pour de plus amples informations, veuillez consulter Seuils d'agrégation minimaux.

Si vous configurez comparisonControls avec des colonnes de sortie interdites, les deux contrôles sont indépendants et s'appliquent tous les deux. Les contrôles de comparaison déterminent les colonnes qu'une requête peut comparer ; les colonnes de sortie interdites déterminent quelles colonnes peuvent apparaître dans le résultat de la requête. Une colonne peut être autorisée dans une comparaison tout en étant exclue du résultat. Pour de plus amples informations, veuillez consulter Colonnes de sortie interdites.

Comparaison littérale

Une comparaison littérale évalue une colonne par rapport à une seule constante codée en dur (une chaîne, un nombre ou une date). Le côté droit de l'opérateur ne change jamais pendant l'exécution de la requête. Les exemples de syntaxe incluent :

Lorsque vous utilisezSeuils d'agrégation minimaux, AWS Clean Rooms ne permet pas la comparaison littérale de la identityColumns valeur. Cela empêche le lanceur de requêtes de soumettre une requête filtrée à un individu ou à un ensemble spécifique d'utilisateurs. Évitez d'autoriser la comparaison littérale sur des colonnes à faible cardinalité qui peuvent distinguer de petits groupes ou des sujets de données individuels.

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

Exemple : autoriser la comparaison littérale dans une colonne de campagne

Un éditeur configure une règle d'analyse personnalisée avec un seuil d'agrégation minimum afin que chaque ligne de sortie représente au moins 100 utilisateurs distincts (user_id). Un annonceur effectue des requêtes dans ce tableau, mais doit étendre son analyse à une campagne publicitaire spécifique, par exemple pour mesurer la portée d'une campagne à la fois.

Comme il user_id s'agit de la colonne d'identité, elle ne peut pas être comparée à un littéral, ce qui empêche l'annonceur de filtrer les résultats en fonction d'un seul utilisateur. Mais ce event_date sont des dimensions à cardinalité élevée campaign_id et non identifiables, auxquelles l'éditeur les ajouteallowedLiteralComparisonColumns, ce qui permet à l'annonceur de filtrer par campagne et d'étendre l'analyse à une plage de dates :

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

Compte tenu de la configuration précédente, cette requête est autorisée :

-- 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;

Dans la même configuration, cette requête est bloquée :

-- 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;

La première requête ne renvoie toujours que des lignes soutenues par au moins 100 utilisateurs distincts, tandis que les comparaisons littérales portent sur les lignes prises en compte campaign_id et event_date filtrent celles qui sont prises en compte. La deuxième requête est rejetée car elle tente d'identifier une personne concernée en particulier.

Comparaison de colonnes

Une comparaison de colonnes évalue dynamiquement la valeur d'une colonne par rapport à la valeur d'une autre colonne pour chaque ligne. Les exemples de syntaxe incluent :

Lors de l'utilisationSeuils d'agrégation minimaux, un fournisseur de données peut autoriser la comparaison de colonnes sur la identityColumns valeur pour les cas d'utilisation nécessitant la jonction de plusieurs tableaux, tels qu'un rapport sur le chevauchement des audiences.

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

Exemple : Autoriser la comparaison de colonnes dans la colonne d'identité pour un rapport de chevauchement

Un éditeur et un annonceur souhaitent mesurer la superposition de leur audience, c'est-à-dire le nombre d'utilisateurs apparaissant dans leurs deux ensembles de données, sans qu'aucune des parties ne sache qui est un utilisateur individuel. Cela nécessite de joindre les deux tableauxuser_id, ce qui constitue une comparaison colonne par colonne. L'éditeur autorise l'annonceur à effectuer une analyse de chevauchement d'audience portant sur des identifiants de campagne spécifiques.

Comme il user_id s'agit de la colonne d'identité, l'éditeur a déjà bloqué les comparaisons littérales (personne ne peut donc filtrer en fonction d'une personne en particulier). Pour activer la jointure entre les tables, l'éditeur ajoute user_id àallowedColumnComparisonColumns. Pour activer le filtrage des campagnes, l'éditeur ajoute campaign_id àallowedLiteralComparisonColumns.

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

Compte tenu de la configuration précédente, cette requête est autorisée :

-- 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;

Dans la même configuration, cette requête est bloquée :

-- 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;

La jointure est réussie car une comparaison colonne à colonne évalue dynamiquement chaque ligne et ne permet pas au lanceur de requêtes de cibler une valeur connue. Le résultat applique le seuil d'agrégation minimum, garantissant que le nombre de chevauchements n'est renvoyé que s'il représente au moins 100 utilisateurs distincts. La deuxième requête est bloquée car elle email ne figure pas dans la allowedColumnComparisonColumns liste d'autorisation et ne peut pas être utilisée dans une comparaison. Seule user_id peut le faire.

Contrôles et expressions de comparaison

Les contrôles de comparaison suivent des comparaisons littérales indirectes, et pas seulement un WHERE column = 'literal' prédicat direct. Si vous autorisez les fonctions d'agrégation ANY_EXPRESSION internesallowedAggregateExpressionType, les contrôles de comparaison bloquent toujours une comparaison littérale sur une colonne qui n'y figure allowedLiteralComparisonColumns pas. Cela s'applique même lorsque le littéral est imbriqué dans une expression.

L'exemple suivant montre une requête qui reste bloquée parce qu'elle ne zip_code figure pas dans la liste d'autorisation, même si le littéral se trouve dans une CASE expression plutôt que d'être écrit en tant que prédicat direct :

-- 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;

C'est pourquoi les deux contrôles sont complémentaires : autoriser les expressions à l'intérieur d'agrégats élargit ce qu'une requête peut calculer, tandis que les contrôles de comparaison limitent toujours les colonnes qu'une requête peut sélectionner par valeur. Pour de plus amples informations, veuillez consulter Autoriser les expressions imbriquées dans les fonctions d'agrégation.