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 tables de mappage d'identifiants

Dans AWS Clean Rooms, une règle d'analyse de table de mappage d'identifiants n'est pas une règle d'analyse autonome. Ce type de règle d'analyse est géré AWS Clean Rooms et utilisé pour joindre des données d'identité disparates afin de faciliter les requêtes. Il est automatiquement ajouté aux tables de mappage des identifiants et ne peut pas être modifié. Elle hérite des comportements des autres règles d'analyse de la collaboration, à condition que ces règles d'analyse soient homogènes.

La règle d'analyse des tables de mappage d'identifiants renforce la sécurité d'une table de mappage d'identifiants. Cela empêche un membre de la collaboration de sélectionner ou d'inspecter directement la population ne se chevauchant pas entre les ensembles de données des deux membres à l'aide de la table de mappage des identifiants. La règle d'analyse de la table de mappage d'identifiants est utilisée pour protéger les données sensibles de la table de mappage d'identifiants lorsqu'elles sont utilisées implicitement dans des requêtes avec d'autres règles d'analyse.

Avec la règle d'analyse de la table de mappage d'identifiants, AWS Clean Rooms applique un chevauchement des deux côtés de la table de mappage d'identifiants développéeSQL. Cela vous permet d'effectuer les tâches suivantes :

La structure et la syntaxe de requête prises en charge sont définies dans. Structure et syntaxe des requêtes de la table de mappage d'identifiants

Les paramètres de la règle d'analyse, définis dansContrôles des requêtes des règles d'analyse des tables de mappage d'identifiants, incluent les contrôles des requêtes et les contrôles des résultats des requêtes. Ses contrôles de requête incluent la possibilité d'exiger le chevauchement de la table de mappage des identifiants dans JOIN les instructions (c'est-à-dire,requireOverlap).

Structure et syntaxe des requêtes de la table de mappage d'identifiants

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

--select_list_expression
SELECT 
provider.data_col, consumer.data_col 

--table_expression
FROM provider

JOIN idMappingTable idmt ON provider.id = idmt.sourceId

JOIN consumer ON consumer.id = idmt.targetId

                        

Tables de collaboration

Les tableaux suivants représentent les tables configurées qui existent dans une AWS Clean Rooms collaboration. La colonne id des tables cr_drivers_license et cr_insurance représente une colonne correspondant à la table de mappage des identifiants.

cr_drivers_license

cr_insurance

Table de mappage des identifiants

Le tableau suivant représente une table de mappage d'identifiants existante qui correspond aux tables cr_drivers_license et cr_insurance. Toutes les entrées ne seront pas disponibles IDs pour les deux tables de collaboration.

La règle d'analyse de la table de mappage d'identifiants autorise uniquement l'exécution de requêtes sur l'ensemble de données qui se chevauchent, qui se présente comme suit :

Exemples de requêtes

Les exemples suivants montrent des emplacements valides pour les jointures de tables de mappage d'identifiants :

-- Single ID mapping table
SELECT
    [ select_items ]
FROM
    cr_drivers_license cr_dl
    [ INNER | LEFT | RIGHT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
    [ INNER | LEFT | RIGHT ] JOIN cr_insurance cr_in             ON idmt.cr_insurance_id       = cr_in.id
;

-- Single ID mapping table (Subquery)
SELECT
    [ select_items ]
FROM (
    SELECT
        [ select_items ]
    FROM
        cr_drivers_license cr_dl
        [ INNER | LEFT | RIGHT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
        [ INNER | LEFT | RIGHT ] JOIN cr_insurance cr_in             ON idmt.cr_insurance_id       = cr_in.id
)
;

-- Single ID mapping table (CTE)
WITH
    matched_ids AS (
        SELECT
            [ select_items ]
        FROM
            cr_drivers_license cr_dl
            [ INNER | LEFT | RIGHT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
            [ INNER | LEFT | RIGHT ] JOIN cr_insurance cr_in             ON idmt.cr_insurance_id       = cr_in.id
    )
SELECT
    [ select_items ]
FROM
    matched_ids
;

Considérations

En ce qui concerne la structure et la syntaxe des requêtes de la table de mappage d'identifiants, tenez compte des points suivants :

Contrôles des requêtes des règles d'analyse des tables de mappage d'identifiants

Avec les commandes de requête de table de mappage d'ID, vous AWS Clean Rooms contrôlez la manière dont les colonnes de votre table sont utilisées pour interroger la table. Par exemple, il contrôle quelles colonnes sont utilisées pour la jointure et quelles colonnes doivent être superposées. La règle d'analyse des tables de mappage d'identifiants inclut également des fonctionnalités qui vous permettent d'autoriser la projection du sourceIDtargetID, ou des deux, sans avoir besoin deJOIN.

Le tableau suivant explique chaque contrôle.

Structure prédéfinie des règles d'analyse des tables de mappage d'identifiants

La structure prédéfinie d'une règle d'analyse de table de mappage d'identifiants est assortie de protections par défaut appliquées au et. sourceID targetID Cela signifie que la colonne avec les protections appliquées doit être utilisée dans les requêtes.

Vous pouvez configurer la règle d'analyse de la table de mappage d'identifiants de la manière suivante :

L'exemple suivant montre une structure prédéfinie pour une règle d'analyse de table de mappage d'identifiants avec les protections par défaut appliquées au et. sourceID targetID Dans cet exemple, la règle d'analyse de la table de mappage d'identifiants autorise uniquement une INNER JOIN opération à la fois sur la sourceID colonne et sur la targetID colonne.

{
  "joinColumns": [
    "source_id",
    "target_id"
  ],
  "queryConstraints": [
    {
      "requireOverlap": {
        "columns": [
          "source_id",
          "target_id"
        ]
      }
    }
  ],
  "dimensionColumns": [] // columns that can be used in SELECT and JOIN
}

L'exemple suivant montre une structure prédéfinie pour une règle d'analyse de table de mappage d'identifiants avec des protections appliquées au. targetID Dans cet exemple, la règle d'analyse de la table de mappage d'identifiants autorise uniquement une INNER JOIN opération sur la sourceID colonne.

{
  "joinColumns": [
    "source_id",
    "target_id"
  ],
  "queryConstraints": [
    {
      "requireOverlap": {
        "columns": [
          "target_id"
        ]
      }
    }
  ],
  "dimensionColumns": [
    "source_id"
  ]
}

L'exemple suivant montre une structure prédéfinie pour une règle d'analyse de table de mappage d'identifiants avec des protections appliquées au. sourceID Dans cet exemple, la règle d'analyse de la table de mappage d'identifiants autorise uniquement une INNER JOIN opération sur la targetID colonne.

{
  "joinColumns": [
    "source_id",
    "target_id"
  ],
  "queryConstraints": [
    {
      "requireOverlap": {
        "columns": [
          "source_id"
        ]
      }
    }
  ],
  "dimensionColumns": [
    "target_id"
  ]
}

L'exemple suivant montre une structure prédéfinie pour une règle d'analyse de table de mappage d'identifiants sans protection appliquée au ou. sourceID targetID Dans cet exemple, la règle d'analyse de la table de mappage d'identifiants autorise une INNER JOIN opération à la fois sur la sourceID colonne et sur la targetID colonne.

{
  "joinColumns": [
    "source_id",
    "target_id"
  ],
  "queryConstraints": [
    {
      "requireOverlap": {
        "columns": []
      }
    }
  ],
  "dimensionColumns": [
    "source_id",
    "target_id"
  ]
}

Règle d'analyse des tables de mappage d'identifiants — exemple

Plutôt que de rédiger une longue déclaration en cascade faisant référence à des informations personnellement identifiables (PII), les entreprises peuvent par exemple utiliser la règle d'analyse des tables de mappage d'identifiants pour utiliser le LiveRamp transcodage multipartite. L'exemple suivant montre comment vous pouvez collaborer en AWS Clean Rooms utilisant la règle d'analyse des tables de mappage d'identifiants.

L'entreprise A est un annonceur qui dispose de données sur les clients et les ventes, qui seront utilisées comme source. La société A effectue également le transcodage pour le compte des parties à la collaboration et apporte les LiveRamp informations d'identification.

L'entreprise B est un éditeur qui possède des données sur les événements, qui seront utilisées comme cible.

Pour créer une collaboration permettant d'analyser la table de mappage des identifiants en collaboration, les entreprises procèdent comme suit :