Abfragen von Daten, die durch differentielle Privatsphäre geschützt sind¶

Join-Operatoren¶

Jeder Join muss ein Equi Join sein, der einen einzelnen Operator verwendet. Zum Beispiel wird t1.c1 == t2.c1 unterstützt, col1 > col2 und col1 + 10 = col2 jedoch nicht. Unbedingte Verknüpfungen werden nicht unterstützt.

Verknüpfungen müssen den Operator JOIN verwenden. Die WHERE-Syntax für Verknüpfungen wird nicht unterstützt. Weitere Informationen zur Verknüpfungssyntax finden Sie unter Implementierung von Verknüpfungen.

Unterstützte Verknüpfungen¶

Joins in einer Abfrage, die Differential Privacy (differentieller Privatsphäre) unterliegt, müssen eine der folgenden sein:

• INNER

• { LEFT | RIGHT | FULL } OUTER

• NATURAL

Beide Seiten der Verknüpfung müssen dasselbe Muster für die Abfrage haben. Zum Beispiel werden die folgenden Verknüpfungen unterstützt:

Beide Seiten sind Bezeichner

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

Copy

Beide Seiten sind Unterabfragen

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

Die Verknüpfung eines Bezeichners mit einer Unterabfrage wird derzeit nicht unterstützt.

Informationen über die unterstützte Abfragesyntax in Bezug auf Joins finden Sie unter Abfragesyntax.

Entitätsschlüssel in Verknüpfungen verwenden¶

Wenn Sie mit Tabellen arbeiten, die mit Datenschutz auf Entitätsebene geschützt sind, können Sie die Menge an Rauschen minimieren, indem Sie die Spalte mit dem Entitätsschlüssel als Teil des Verknüpfungsschlüssels einbeziehen, insbesondere wenn dies die Abfrage semantisch nicht verändert.

Betrachten Sie zum Beispiel die folgenden Tabellen, bei denen die Entität Kunden ist:

Tabelle	Beschreibung
customers	Kundenverzeichnis, wobei jede Zeile ein Kunde ist und eine customer_id hat.
transactions	Kundentransaktionen, wobei jeder Kunde mehrere Transaktionen haben kann.
transaction_lines	Eindeutige Element, die in einer Transaktion gekauft wurden. Es kann mehrere Zeilen in einer Transaktion geben.

Wenn der Datenanbieter die bewährten befolgt, hat er die Daten so strukturiert, dass jede dieser Tabellen den Entitätsschlüssel customer_id enthält. Bei diesem Schema kann jede Zeile einer Transaktion nur zu einer Transaktion und jede Transaktion nur zu einem Kunden gehören. Diese Beziehung ist aus den Daten selbst nicht ersichtlich, sodass ohne zusätzliche Informationen die Menge an Rauschen, die für die differentielle Privatsphäre hinzugefügt wird, höher ist als nötig.

Sie können die Menge an Rauschens minimieren, indem Sie den Entitätsschlüssel customer_id als Teil des Verknüpfungsschlüssels einbeziehen, auch wenn dies redundant ist. Wenn Sie beispielsweise die Tabelle transactions mit transaction_lines verknüpfen, benötigen Sie in der Regel nur den Verknüpfungsschlüssel transaction_id. Das Verknüpfen sowohl über die transaction_id als auch die customer_id reduziert jedoch die Menge an Rauschen.

Datentypen und Datenschutzbereiche¶

Wenn Sie zwei Tabellen verknüpfen, müssen die Datentypen der Spalten des Verknüpfungsschlüssels auf beiden Seiten gleich sein. Für die Differential Privacy (differentielle Privatsphäre) beinhaltet der Datentyp einer Spalte, ob sie einen Datenschutzbereich hat oder nicht.

Wenn Sie z. B. eine datenschutzgeschützte Tabelle transactions und eine ungeschützte Tabelle product_lookup haben und diese über product_id verknüpfen möchten, muss die Spalte product_id in beiden Tabellen vom gleichen Datentyp sein (z. B. eine Zeichenfolge) und beide müssen einen Datenschutzbereich haben.

Um diese Anforderung zu erfüllen, muss der Administrator für den Analysten möglicherweise einen Datenschutzbereich definieren, genau wie der Datenanbieter sie definiert. Wie Sie einen Datenschutzbereiche für eine Tabelle festlegen, erfahren Sie unter Festlegen eines Datenschutzbereichs.

Eindeutigkeitsanforderungen¶

Verknüpfungen können potenziell Datenzeilen duplizieren, was dazu führen kann, dass einem Abfrageergebnis unendlich viel Rauschen hinzugefügt wird. Um sicherzustellen, dass datenschutzgeschützte Daten bei einer Verknüpfung nicht doppelt vorhanden sind, darf der Verknüpfungsschlüssel (d. h. die Spalten, über die die Tabellen verknüpft werden) für datenschutzgeschützte Tabellen nur einem Datensatz in der anderen Tabelle entsprechen. Das bedeutet, dass bei der Verknüpfung mit einer datenschutzgeschützten Tabelle der Verknüpfungsschlüssel auf der gegenüberliegenden Seite dedupliziert werden muss.

Um die Anforderung der Eindeutigkeit für Verknüpfungen zu erfüllen, kann die Abfrage ein GROUP BY auf einer Teilmenge der Verknüpfungsspalten verwenden, um doppelte Zeilen in einem Ergebnis zu gruppieren.

Nehmen wir zum Beispiel an, dass die Tabelle patients durch Differential Privacy (differentielle Privatsphäre) geschützt ist und die Tabelle geo_lookup nicht. Der Analyst möchte diese beiden Tabellen über zip_code verknüpfen, damit er die Tabelle patients nach State filtern kann. Um sicherzustellen, dass die Datensätze in der datenschutzgeschützten Tabelle patients nicht dupliziert werden, muss die Abfrage die Tabelle zip_code anhand des Verknüpfungsschlüssels deduplizieren. Dies muss explizit gemacht werden, auch wenn die Tabelle geo_lookup bereits eindeutig für zip_code ist. Dadurch wird sichergestellt, dass Snowflake den Datenschutz korrekt berücksichtigen kann.

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("*"))

Ausführen von Abfragen auf Transaktionsebene¶

Die Anforderung der Deduplizierung für die differentielle Privatsphäre auf Entitätsebene hindert Sie nicht daran, Abfragen auf Transaktionsebene auszuführen. Sie müssen die Daten jedoch zunächst auf Entitätseben gruppieren und dann über diese Gruppen aggregieren.

Nehmen wir zum Beispiel an, Sie haben eine Tabelle doctor_visits und der Datenanbieter hat einen Entitätsschlüssel patient_id definiert, um den Datenschutz auf Entitätsebene zu implementieren. Eine Abfrage auf Transaktionsebene könnte lauten: „Wie viele Arztbesuche waren keine regulären Kontrolluntersuchungen?“ Im Folgenden finden Sie ein Beispiel für eine solche Abfrage:

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;

Die Unterabfrage wird nach patient_id gruppiert, um die Daten zu deduplizieren. Die Aggregatspalte num_visits erfasst die Anzahl der Besuche pro Patient, die nicht im Rahmen einer regulären Untersuchung erfolgten. Die Abfrage aggregiert dann wieder auf dieser Spalte pro Patient, um die Gesamtzahl der Besuche zu erhalten. Beachten Sie, dass die WHERE-Klausel in der äußeren Abfrage erforderlich ist, um einen Datenschutzbereich für die Daten anzugeben.