Interrogation de données protégées par la confidentialité différentielle¶

Opérateurs de jointure¶

Chaque jointure doit être une jointure équivalente qui utilise un seul opérateur. Par exemple, t1.c1 == t2.c1 est pris en charge, mais col1 > col2 et col1 + 10 = col2 ne le sont pas. Les jointures inconditionnelles ne sont pas prises en charge.

Les jointures doivent utiliser l’opérateur JOIN. La syntaxe WHERE pour les jointures n’est pas prise en charge. Pour plus d’informations sur la syntaxe de jointure, voir Mise en œuvre des jointures.

Jointures prises en charge¶

Les jointures d’une requête différentiellement privée doivent être l’une des suivantes :

• INNER

• { LEFT | RIGHT | FULL } OUTER

• NATURAL

Les deux côtés de la jointure doivent avoir le même modèle de requête. Par exemple, les jointures suivantes sont prises en charge :

Les deux côtés sont des identificateurs

SELECT COUNT(*)
FROM t1 INNER JOIN t2 ON t1.a=t2.a;

Copy

Les deux côtés sont des sous-requêtes

SELECT COUNT(*)
FROM (SELECT a, SUM(b) FROM t1 GROUP BY a) AS g1
    INNER JOIN (SELECT * FROM t2) AS g2
    ON g1.a=g2.a;

Copy

La jonction d’un identificateur avec une sous-requête n’est actuellement pas prise en charge.

Pour plus d’informations sur la syntaxe de requête prise en charge liée aux jointures, voir Syntaxe de requête.

Utilisation des clés d’entité dans les jointures¶

Lorsque vous travaillez avec des tables protégées par une confidentialité au niveau de l’entité, vous pouvez minimiser la quantité de bruit en incluant la colonne de clé d’entité dans le cadre de la clé de jointure, en particulier si elle ne modifie pas sémantiquement la requête.

Par exemple, considérons les tables suivantes où l’entité correspond aux clients :

Table	Description
customers	Répertoire des clients, où chaque ligne correspond à un client et comporte un customer_id.
transactions	Transactions clients, où chaque client peut avoir plusieurs transactions.
transaction_lines	Articles uniques qui ont été achetés lors d’une transaction. Il peut y avoir plusieurs lignes dans une seule transaction.

Si les meilleures pratiques sont suivies, le fournisseur de données a structuré les données de sorte que chacune de ces tables possède la clé d’entité customer_id. Pour ce schéma de données, chaque ligne de transaction ne peut appartenir qu’à une seule transaction et chaque transaction ne peut appartenir qu’à un seul client. Cette relation n’est pas évidente à partir des données elles-mêmes ; de ce fait, sans informations supplémentaires, la quantité de bruit ajoutée pour la confidentialité différentielle sera plus élevée que nécessaire.

Vous pouvez minimiser la quantité de bruit en incluant la clé d’entité customer_id dans le cadre de la clé de jointure, même si elle est redondante. Par exemple, joindre la table transactions avec transaction_lines nécessite, en général, uniquement la clé de jointure transaction_id. Cependant, joindre des tables sur transaction_id et customer_id entraînera une diminution du bruit.

Types de données et domaines de confidentialité¶

Lors de la jonction de deux tables, les types de données des colonnes clés de jointure de chaque côté doivent être identiques. Pour la confidentialité différentielle, le type de données d’une colonne indique si elle possède ou non un domaine de confidentialité.

Par exemple, si vous aviez une table protégée par la confidentialité transactions et une table non protégée product_lookup, et que vous vouliez les joindre sur product_id, la colonne product_id des deux tables doit être du même type de données (par exemple, une chaîne) et doit chacune avoir un domaine de confidentialité.

Pour répondre à cette exigence, l’administrateur de l’analyste devra peut-être définir un domaine de confidentialité tout comme le fournisseur de données le définit. Pour plus d’informations sur la façon de définir un domaine de confidentialité pour une table, voir Définition d’un domaine de confidentialité.

Condition d’unicité¶

Les jointures peuvent potentiellement dupliquer des lignes de données, ce qui peut entraîner une quantité illimitée de bruit ajouté au résultat d’une requête. Pour garantir que les données protégées par la confidentialité ne sont pas dupliquées dans une jointure, la clé de jointure (c’est-à-dire les colonnes sur lesquelles les tables sont jointes) des tables protégées par la confidentialité doit correspondre à un seul enregistrement de l’autre table. Cela signifie que lors de la jointure avec une table protégée par la confidentialité, la clé de jointure du côté opposé doit être dédupliquée.

Pour satisfaire à l’exigence d’unicité des jointures, la requête peut utiliser GROUP BY sur un sous-ensemble des colonnes de jointure pour regrouper les lignes en double en un seul résultat.

Par exemple, supposons que la table patients est protégée par la confidentialité différentielle, contrairement à la table geo_lookup. L’analyste souhaite joindre ces deux tables sur zip_code afin qu’ils puissent filtrer la table patients sur State. Afin de garantir que les enregistrements dans la table patients protégée par la confidentialité ne sont pas dupliqués, la requête doit dédupliquer la table zip_code sur la clé de jointure. Cela doit être fait explicitement même si la table geo_lookup est déjà unique sur zip_code. Cela garantit que Snowflake peut correctement prendre en compte la confidentialité.

SELECT COUNT(*)
  FROM patients
  LEFT JOIN (SELECT zip_code, ANY_VALUE(state) AS residence_state
            FROM geo_lookup
            GROUP BY zip_code)
  USING zip_code
  WHERE birth_state = residence_state;

df_patients = session.table("patients")
df_geo = session.table("geo_lookup")
df_geo_deduped = df_geo.group_by("zip_code").agg(f.any_value("state").as_("state"))
df_patients.join(df_geo_deduped, on="zip_code", join_type="left")\
          .where(f.col("birth_state") == f.col("residence_state")).select(f.count("*"))

Exécution de requêtes au niveau des transactions¶

L’exigence de déduplication pour la confidentialité différentielle au niveau de l’entité ne vous empêche pas d’exécuter des requêtes au niveau des transactions. Cependant, vous devez d’abord regrouper les données au niveau de l’entité, puis les agréger sur ces groupes.

Par exemple, supposons que vous ayez une table doctor_visits et que le fournisseur de données a défini une clé d’entité patient_id pour mettre en œuvre la confidentialité au niveau de l’entité. Une requête au niveau de la transaction pourrait être : « Combien de visites chez le médecin n’étaient pas pour un suivi régulier ? » Voici un exemple de la manière d’écrire cette requête :

SELECT SUM(num_visits)
  FROM (SELECT SUM((visit_reason<>'Regular checkup')::INT) AS num_visits
        WHERE visit_reason IS NOT NULL
        GROUP BY patient_id)
  WHERE num_visits > 0 AND num_visits < 20;

Les sous-requêtes se regroupent par patient_id pour dédupliquer les données. La colonne agrégée num_visits capture le nombre de visites par patient qui n’étaient pas pour un contrôle régulier. La requête s’agrège ensuite à nouveau sur cette colonne par patient pour obtenir le nombre total de visites. Notez que la clause WHERE sur la requête externe est requise pour spécifier un domaine de confidentialité sur les données.