Como consultar dados protegidos por privacidade diferencial¶

Operadores de junção¶

Cada junção deve ser uma junção equi que usa um único operador. Por exemplo, t1.c1 == t2.c1 é suportado, mas col1 > col2 e col1 + 10 = col2 não são. Junções não condicionadas não são suportadas.

As junções devem usar o operador JOIN. A sintaxe WHERE para junções não é suportada. Para obter mais informações sobre a sintaxe de junção, consulte Implementação de junções.

Junções suportadas¶

As junções em uma consulta privada diferencial devem ser uma das seguintes:

• INNER

• { LEFT | RIGHT | FULL } OUTER

• NATURAL

Ambos os lados da junção devem ter o mesmo padrão de consulta. Por exemplo, as seguintes junções são suportadas:

Ambos os lados são identificadores

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

Copy

Ambos os lados são subconsultas

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

Atualmente, não há suporte para unir um identificador a uma subconsulta

Para obter informações sobre a sintaxe de consulta suportada relacionada a junções, consulte Sintaxe de consulta.

Uso de chaves de entidade em junções¶

Ao trabalhar com tabelas protegidas com privacidade em nível de entidade, você pode minimizar a quantidade de ruído incluindo a coluna de chave de entidade como parte da chave de junção, especialmente se isso não alterar semanticamente a consulta.

Por exemplo, considere as seguintes tabelas onde a entidade é clientes:

Tabela	Descrição
customers	Diretório de clientes, onde cada linha é um cliente e tem um customer_id.
transactions	Transações de clientes, onde cada cliente pode ter múltiplas transações.
transaction_lines	Itens exclusivos que foram comprados em uma transação. Pode haver várias linhas em uma única transação.

Se estiverem seguindo as práticas recomendadas, o provedor de dados estruturou os dados para que cada uma dessas tabelas tenha a chave de entidade customer_id. Para esse esquema de dados, cada linha de transação só pode pertencer a uma transação e cada transação só pode pertencer a um cliente. Essa relação não é evidente nos próprios dados, portanto, sem informações adicionais, a quantidade de ruído adicionada para a privacidade diferencial será maior do que o necessário.

Você pode minimizar a quantidade de ruído incluindo a chave de entidade customer_id como parte da chave de junção, mesmo que ela seja redundante. Por exemplo, unir a tabela transactions a transaction_lines normalmente requer apenas a chave de junção transaction_id. No entanto, unir ambas transaction_id e customer_id resultará em uma quantidade menor de ruído.

Tipos de dados e domínios de privacidade¶

Ao unir duas tabelas, os tipos de dados das colunas de chave de junção de ambos os lados devem ser os mesmos. Para privacidade diferencial, o tipo de dados de uma coluna inclui se ela tem ou não um domínio de privacidade.

Por exemplo, se você tivesse uma tabela transactions com privacidade protegida e uma tabela desprotegida product_lookup e quisesse uni-las em product_id, a coluna product_id em ambas as tabelas deveria ser do mesmo tipo de dados (por exemplo, uma cadeia de caracteres) e cada uma deveria ter um domínio de privacidade.

Para atender a esse requisito, o administrador do analista pode precisar definir um domínio de privacidade assim como o provedor de dados o define. Para obter informações sobre como definir um domínio de privacidade para uma tabela, consulte Definição de um domínio de privacidade.

Requisito de exclusividade¶

As junções podem potencialmente duplicar linhas de dados, o que pode fazer com que a quantidade de ruído adicionada a um resultado de consulta se torne ilimitada. Para garantir que os dados protegidos por privacidade não sejam duplicados em uma junção, a chave de junção (ou seja, as colunas nas quais as tabelas são unidas) para tabelas protegidas por privacidade deve corresponder a apenas um registro na outra tabela. Isso significa que, ao unir-se a uma tabela protegida por privacidade, a chave de junção no lado oposto deve ser desduplicada.

Para satisfazer o requisito de exclusividade para junções, a consulta pode usar um GROUP BY em um subconjunto das colunas de junção para agrupar linhas duplicadas em um resultado.

Por exemplo, suponha que a tabela patients esteja protegida por privacidade diferencial e a tabela geo_lookup não. O analista quer unir essas duas tabelas em zip_code para poder filtrar a tabela patients em State. Para garantir que os registros na tabela patients protegida por privacidade não sejam duplicados, a consulta deve desduplicar a tabela zip_code na chave de junção. Isso deve ser feito explicitamente, mesmo que a tabela geo_lookup já seja única em zip_code. Isso garante que o Snowflake possa contabilizar corretamente a privacidade.

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

Execução de consultas em nível de transação¶

O requisito de desduplicação para privacidade diferencial em nível de entidade não impede que você execute consultas em nível de transação. No entanto, primeiro você deve agrupar os dados no nível da entidade e depois agregar nesses grupos.

Por exemplo, suponha que você tenha uma tabela doctor_visits e que o provedor de dados tenha definido uma chave de entidade patient_id para implementar privacidade em nível de entidade. Uma consulta em nível de transação pode ser: “Quantas consultas médicas não foram para um check-up regular?” A seguir está um exemplo de como escrever esta consulta:

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;

A subconsulta faz um agrupamento por patient_id para desduplicar os dados. A coluna agregada num_visits captura o número de visitas por paciente que não foram para um check-up regular. A consulta então agrega novamente essa coluna por paciente para obter o número total de visitas. Observe que a cláusula WHERE na consulta externa é necessária para especificar um domínio de privacidade nos dados.