Règle d'analyse des listes - AWS Clean Rooms

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.

Règle d'analyse des listes

DansAWS Clean Rooms, une règle d'analyse de liste produit des listes au niveau des lignes indiquant le chevauchement entre la table configurée à laquelle elle est ajoutée et les tables configurées du membre qui peut effectuer la requête. Le membre habilité à effectuer des requêtes exécute des requêtes qui incluent une règle d'analyse de liste.

Le type de règle d'analyse de liste prend en charge les cas d'utilisation tels que l'enrichissement et la création d'audience.

Pour plus d'informations sur la structure de requête et la syntaxe prédéfinies pour cette règle d'analyse, consultezStructure prédéfinie des règles d'analyse des listes.

Les paramètres de la règle d'analyse de liste, définis dansRègle d'analyse des listes : contrôles des requêtes, comportent des contrôles de requête. Ses commandes de requête incluent la possibilité de sélectionner les colonnes qui peuvent être répertoriées dans la sortie. La requête doit comporter au moins une jointure avec une table configurée provenant du membre qui peut effectuer la requête, directement ou de manière transitive.

Il n'existe aucun contrôle des résultats de requête comme c'est le cas pour la règle d'analyse d'agrégation.

Les requêtes de liste ne peuvent utiliser que des opérateurs mathématiques. Ils ne peuvent pas utiliser d'autres fonctions (telles que l'agrégation ou le scalaire).

Structure et syntaxe des requêtes de liste

Les requêtes sur les tables dotées d'une règle d'analyse de liste doivent respecter la syntaxe suivante.

--select_list_expression SELECT [TOP number ] DISTINCT column_name [[AS] column_alias ] [, ...] --table_expression FROM table_name [[AS] table_alias ] [[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...] --where_expression [WHERE where_condition] --limit_expression [LIMIT number]

Le tableau suivant explique chaque expression répertoriée dans la syntaxe précédente.

Expression Définition Exemples
select_list_expression

Liste séparée par des virgules contenant au moins un nom de colonne de table.

Un DISTINCT paramètre est obligatoire.

Note

Ils select_list_expression peuvent aliaser les colonnes avec ou sans le AS paramètre.

Il prend également en charge le TOP paramètre. Pour plus d'informations, consultez la référence AWS Clean Rooms SQL.

SELECT DISTINCT segment

table_expression

Une table, ou une jointure de tables, join_condition à laquelle la connecterjoin_condition.

join_conditionrenvoie une valeur booléenne.

Les table_expression supports :

  • Un type de JOIN spécifique (INNERJOIN)

  • Les conditions de comparaison de l'égalité au sein d'un join_condition (=)

  • Opérateurs logiques (AND,OR).

FROM consumer_table INNER JOIN provider_table ON consumer_table.identifier1 = provider_table.identifier1 AND consumer_table.identifier2 = provider_table.identifier2
where_expression Expression conditionnelle qui renvoie une valeur booléenne. Il peut être composé des éléments suivants :
  • Nom des colonnes de la table

  • Operateurs mathématiques

  • Littéraux de chaîne

  • Littéraux numériques

Les conditions de comparaison prises en charge sont (=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL).

Les opérateurs logiques pris en charge sont (AND, OR).

where_expressionC'est facultatif.

WHERE state + '_' + city = 'NY_NYC'

WHERE timestampColumn = timestampColumn2 - 14

limit_expression

Cette expression doit prendre un entier positif. Il peut également être échangé avec un paramètre TOP.

limit_expressionC'est facultatif.

LIMIT 100

En ce qui concerne la structure et la syntaxe des requêtes de liste, tenez compte des points suivants :

  • Les commandes SQL autres que SELECT ne sont pas prises en charge.

  • Les sous-requêtes et les expressions de table communes (par exemple,WITH) ne sont pas prises en charge

  • Les BY clauses GROUP BY HAVING, et ORDER ne sont pas prises en charge

  • Le paramètre OFFSET n'est pas pris en charge

Règle d'analyse des listes : contrôles des requêtes

Avec les commandes de requête de liste, vous pouvez contrôler la manière dont les colonnes de votre table sont utilisées pour interroger la table. Par exemple, vous pouvez contrôler quelle colonne est utilisée pour la jointure ou quelle colonne peut être utilisée dans l'instruction et la WHERE clause SELECT.

Les sections suivantes expliquent chaque contrôle.

Commandes de jointure

Avec les commandes Join, vous pouvez contrôler la manière dont votre table peut être jointe aux autres tables de la table_expression. AWS Clean Roomsne prend en charge que INNER JOIN. Dans la règle d'analyse de liste, au moins un INNER JOIN est requis et le membre qui peut effectuer une requête doit inclure une table qu'il possède dans le INNER JOIN. Cela signifie qu'ils doivent joindre votre table à la leur, directement ou de manière transitionnelle.

Voici un exemple de transitivité.

ON my_table.identifer = third_party_table.identifier .... ON third_party_table.identifier = member_who_can_query_table.id

INNERLes instructions JOIN ne peuvent utiliser que des colonnes explicitement classées comme telles joinColumn dans votre règle d'analyse.

Le INNER JOIN doit fonctionner sur une table joinColumn à partir de votre table configurée et joinColumn à partir d'une autre table configurée dans la collaboration. Vous décidez quelles colonnes de votre tableau peuvent être utiliséesjoinColumn.

Chaque condition de correspondance contenue dans la ON clause est requise pour utiliser la condition de comparaison d'égalité (=) entre deux colonnes.

Plusieurs conditions de correspondance au sein d'une ON clause peuvent être les suivantes :

  • Combiné à l'aide de l'opérateur AND logique

  • Séparé à l'aide de l'opérateur OR logique

Note

Toutes les JOIN conditions de match doivent correspondre à une ligne de chaque côté duJOIN. Toutes les conditions connectées par un opérateur OR ou un opérateur AND logique doivent également respecter cette exigence.

Voici un exemple de requête avec un opérateur AND logique.

SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id AND table1.name = table2.name

Voici un exemple de requête avec un opérateur OR logique.

SELECT some_col, other_col FROM table1 JOIN table2 ON table1.id = table2.id OR table1.name = table2.name
Contrôle Définition Utilisation
joinColumns Les colonnes que vous souhaitez autoriser le membre autorisé à effectuer une requête à utiliser dans l'instruction INNER JOIN.

La même colonne ne peut pas être classée à la fois comme a joinColumn et listColumn (voirContrôles de liste).

joinColumnne peut être utilisé dans aucune autre partie de la requête que INNER JOIN.

Contrôles de liste

Les contrôles de liste contrôlent les colonnes qui peuvent être répertoriées dans le résultat de la requête (c'est-à-dire utilisées dans l'instruction SELECT) ou utilisées pour filtrer les résultats (c'est-à-dire utilisées dans l'WHEREinstruction).

Contrôle Définition Utilisation
listColumns Les colonnes que vous autorisez le membre qui peut effectuer une requête à utiliser dans le SELECT et WHERE A listColumn peut être utilisé dans SELECT etWHERE.

La même colonne ne peut pas être utilisée à la fois comme listColumn etjoinColumn.

Structure prédéfinie des règles d'analyse des listes

L'exemple suivant inclut une structure prédéfinie qui montre comment exécuter une règle d'analyse de liste.

Dans l'exemple suivant, MyTablefait référence à votre table de données. Vous pouvez remplacer chaque espace réservé saisi par l'utilisateur par vos propres informations.

{ "joinColumns": [MyTable column name(s)], "listColumns": [MyTable column name(s)], }

Règle d'analyse des listes - exemple

L'exemple suivant montre comment deux entreprises peuvent collaborer en AWS Clean Rooms utilisant l'analyse de listes.

L'entreprise A dispose de données de gestion de la relation client (CRM). L'entreprise A souhaite obtenir des données sectorielles supplémentaires sur ses clients pour en savoir plus sur leurs clients et éventuellement utiliser des attributs comme données d'entrée dans d'autres analyses. L'entreprise B possède des données de segment composées d'attributs de segment uniques qu'elle a créés sur la base de ses données de première partie. L'entreprise B souhaite fournir les attributs de segment uniques à l'entreprise A uniquement pour les clients dont les données se chevauchent avec celles de l'entreprise A.

Les entreprises décident de collaborer afin que l'entreprise A puisse enrichir les données qui se chevauchent. L'entreprise A est le membre qui peut interroger, et l'entreprise B est le contributeur.

Pour créer une collaboration et exécuter une analyse de liste en collaboration, les entreprises procèdent comme suit :

  1. L'entreprise A crée une collaboration et crée une adhésion. La collaboration a la société B comme autre membre de la collaboration. L'entreprise A active la journalisation des requêtes dans la collaboration, et elle active la journalisation des requêtes dans son compte.

  2. L'entreprise B crée une adhésion à la collaboration. Il permet la journalisation des requêtes dans son compte.

  3. L'entreprise A crée une table configurée pour le CRM

  4. L'entreprise A ajoute la règle d'analyse à la table configurée par le client, comme indiqué dans l'exemple suivant.

    { "joinColumns": [ "identifier1", "identifier2" ], "listColumns": [ "internalid", "segment1", "segment2", "customercategory" ] }

    joinColumns— L'entreprise A souhaite utiliser hashedemail et/ou thirdpartyid (obtenue auprès d'un fournisseur d'identité) associer des clients à partir de données CRM à des clients à partir de données de segment. Cela permettra de garantir que l'entreprise A associe des données enrichies aux bons clients. Ils disposent de deux JoinColumns pour potentiellement améliorer le taux de correspondance de l'analyse.

    listColumns— L'entreprise A utilise listColumns pour obtenir des colonnes enrichies à côté d'une colonne internalid qu'elle utilise dans ses propres systèmes. Ils ajoutent segment1 et limitent potentiellement l'enrichissement customercategory à des segments spécifiques en les utilisant dans des filtres. segment2

  5. La société B crée une table configurée par segments.

  6. L'entreprise B ajoute la règle d'analyse à la table des segments configurés.

    { "joinColumns": [ "identifier2" ], "listColumns": [ "segment3", "segment4" ] }

    joinColumns— L'entreprise B permet à l'entreprise A de se joindre à elle pour identifier2 faire correspondre les clients, qu'il s'agisse de données segmentées ou de données CRM. Les sociétés A et B ont travaillé avec le fournisseur d'identité pour identifier2 déterminer laquelle correspondrait à cette collaboration. Ils n'en ont pas ajouté d'autres joinColumns parce qu'ils pensaient identifier2 que c'était le taux de correspondance le plus élevé et le plus précis possible et qu'aucun autre identifiant n'était requis pour les requêtes.

    listColumns— L'entreprise B permet à l'entreprise A d'enrichir ses données segment3 et ses segment4 attributs, qui sont des attributs uniques qu'elle a créés, collectés et sur lesquels elle s'est alignée (avec le client A) afin de participer à l'enrichissement des données. Ils souhaitent que l'entreprise A obtienne ces segments pour le chevauchement au niveau des lignes, car il s'agit d'une collaboration d'enrichissement des données.

  7. L'entreprise A crée une association de tables CRM pour la collaboration.

  8. L'entreprise B crée une association de tables de segments pour la collaboration.

  9. L'entreprise A exécute des requêtes, telles que la suivante, pour enrichir les données clients qui se recoupent.

    SELECT companyA.internalid, companyB.segment3, companyB.segment4 INNER JOIN returns companyB ON companyA.identifier2 = companyB.identifier2 WHERE companyA.customercategory > 'xxx'
  10. Les entreprises A et B examinent les journaux de requêtes. L'entreprise B vérifie que la requête est conforme à ce qui a été convenu dans l'accord de collaboration.