差分プライバシーで保護されたデータのクエリ¶

結合演算子¶

各結合は、単一の演算子を使用する等価結合である必要があります。たとえば、 t1.c1 == t2.c1 はサポートされていますが、 col1 > col2 と col1 + 10 = col2 はサポートされていません。無条件結合はサポートされていません。

結合には JOIN 演算子を使用する必要があります。WHERE 構文による結合はサポートされていません。結合構文の詳細については、 結合の実装 をご参照ください。

サポートされている結合¶

差分プライベートクエリの結合は、以下のいずれかでなければなりません。

• INNER

• { LEFT | RIGHT | FULL } OUTER

• NATURAL

結合の両側は同じクエリパターンになる必要があります。たとえば、以下の結合がサポートされています。

両側とも識別子である

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

Copy

両側ともサブクエリである

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

識別子とサブクエリの結合は現在サポートされていません。

サポートされている結合に関連するクエリ構文については、 クエリ構文 をご参照ください。

結合でのエンティティキーの使用¶

エンティティレベルのプライバシー で保護されたテーブルを扱う場合、特にクエリを意味的に変更しないのであれば、エンティティキー列を結合キーの一部として含めることで、ノイズの量を最小限に抑えることができます。

たとえば、エンティティが顧客である以下のテーブルを考えてみましょう。

テーブル	説明
customers	各行が顧客であり、 customer_id を持つ顧客ディレクトリ。
transactions	各顧客が複数のトランザクションを持つことができる顧客トランザクション。
transaction_lines	トランザクションで購入された固有のアイテム。1つのトランザクションに複数の行が存在することもあります。

ベストプラクティスに従っているのであれば、データプロバイダーは、これらのテーブルがそれぞれエンティティキー customer_id を持つようにデータを構造化しています。このデータスキーマでは、各トランザクション行は1つのトランザクションにのみ属することができ、各トランザクションは1人の顧客にのみ属することができます。この関係はデータ自体からは明らかではないので、追加情報がなければ、差分プライバシーによって追加されるノイズの量は必要以上に多くなります。

たとえ冗長であっても、結合キーの一部としてエンティティキー customer_id を含めることで、ノイズの量を最小限に抑えることができます。たとえば、テーブル transactions を transaction_lines と結合する場合、通常は結合キー transaction_id だけが必要です。しかし、 transaction_id と customer_id の両方で結合すると、ノイズの量は少なくなります。

データ型とプライバシードメイン¶

2つのテーブルを結合する場合、両側の結合キー列のデータ型は同一になる必要があります。差分プライバシーの場合、列のデータ型には、 プライバシードメイン を持つかどうかが含まれます。

たとえば、プライバシー保護されたテーブル transactions と保護されていないテーブル product_lookup があり、それらを product_id で結合したい場合、両方のテーブルの product_id 列は同じデータ型（たとえば、文字列）でなければならず、それぞれプライバシードメインを持っていなければなりません。

この要件を満たすために、アナリストの管理者が、データプロバイダーがプライバシードメインを定義するのと同じように、プライバシードメインを定義する必要が生じる場合があります。テーブルにプライバシードメインを設定する方法については、 プライバシードメインの設定 をご参照ください。

一意性要件¶

結合はデータ行を重複させる可能性があるため、クエリ結果に付加されるノイズの量が際限なく増える可能性があります。プライバシー保護されたデータが結合で重複しないようにするため、プライバシー保護されたテーブルの結合キー（つまり、テーブルが結合される列）は、もう一方のテーブルの1つの記録にのみ一致する必要があります。つまり、プライバシー保護されたテーブルと結合する場合、反対側の結合キーは重複排除する必要があります。

結合の一意性要件を満たすために、クエリは結合列のサブセットで GROUP BY を使用して重複する行を1つの結果にまとめることができます。

たとえば、 patients テーブルが差分プライバシーで保護され、 geo_lookup テーブルは保護されていないとしましょう。アナリストはこの2つのテーブルを zip_code で結合し、 patients テーブルを State でフィルタリングしたいと考えています。プライバシー保護された patients テーブルの記録が重複しないように、クエリは結合キーの zip_code テーブルを重複排除する必要があります。これは、 geo_lookup テーブルが zip_code ですでに一意である場合でも、明示的に行う必要があります。これにより、Snowflakeでプライバシーに正しく対応できるようになります。

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

トランザクションレベルのクエリの実行¶

エンティティレベルの差分プライバシーに対する重複排除要件は、トランザクションレベルのクエリの実行を妨げるものではありません。ただし、まずデータをエンティティレベルにグループ化し、そのグループに対して集計を行う必要があります。

たとえば、 doctor_visits テーブルがあり、データプロバイダーがエンティティレベルのプライバシーを実装するためにエンティティキー patient_id を定義したとします。トランザクションレベルのクエリは「定期検診でない来院は何件あったか？」のようになります。以下に、このクエリの書き方の例を示します。

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;

データを重複排除するため、サブクエリを patient_id でグループ化します。集計列 num_visits は、定期検診以外の患者一人当たりの来院回数を示しています。その後、クエリは患者ごとの列を再度集計し、総来院回数を取得します。外側のクエリの WHERE 句は、 データにプライバシードメインを指定 するために必要であることに注意してください。