PrivateSQL

Abstract

Differential privacy is considered a de facto standard for private data analysis. However, the definition and much of the supporting literature applies to flat tables. While there exist variants of the definition and specialized algorithms for specific types of relational data (e.g. graphs), there isn't a general privacy definition for multi-relational schemas with constraints, and no system that permits accurate differentially private answering of SQL queries while imposing a fixed privacy budget across all queries posed by the analyst. This work presents PrivateSQL, a first-of-its-kind end-to-end differentially private relational database system. PrivateSQL allows an analyst to query data stored in a standard database management system using a rich class of SQL counting queries. PrivateSQL adopts a novel generalization of differential privacy to multi-relational data that takes into account constraints in the schema like foreign keys, and allows the data owner to flexibly specify entities in the schema that need privacy. PrivateSQL ensures a fixed privacy loss across all the queries posed by the analyst by answering queries on private synopses generated from several views over the base relation that are tuned to have low error on a representative query workload. We experimentally evaluate PrivateSQL on a real-world dataset and a workload of more than 3, 600 queries. We show that for 50% of the queries PrivateSQL offers at least 1, 000x better error rates than solutions adapted from prior work.

R2T: Instance-optimal Truncation for Differentially Private Query Evaluation with Foreign Keys

“…The issue above was first identified by Kotsogiannis et al [24], who also formalized the DP policy for relational databases with FK constraints. The essence of their model (a rigorous definition is given in Section 3) is that the individuals and their private data are stored in separate relations that are linked by FKs.…”

Differentially Private Data Release over Multiple Tables

“…Two DP settings have been studied in the relational model, depending on whether foreign key constraints are considered or not. The one considering foreign key constraints assumes the existence of a primary private table, and deleting a tuple in the primary private relation will delete all other tuples referencing it; see [14,32,42]. In this work, we adopt the other notion, which does not consider foreign key constrains, but defines instances to be neighboring if one can be converted into the other by adding/removing a single tuple; this is the same as the notion studied in some previous works [30,31,38,41].…”

“…Data analysis over multiple private tables connected via join operators has been the subject of significant interest within the area of modern database systems. In particular, the challenging question of releasing the join size over a set of private tables has been studied in several recent works including the sensitivity-based framework [15,16,30], the truncation-based mechanism [14,32,42], as well as in works on one-to-one joins [37,41], and on graph databases [6,10]. In practice, multiple queries (as opposed to a single one) are typically issued for data analysis, for example, a large class of linear queries on top of join results with different weights on input tuples, as a generalization of the counting join size query.…”

Differential Privacy for Black-Box Statistical Analyses

“…An example of such a system is PINQ, which presents programmers with a SQL-like interface with privacy guarantees [21]. Other differentially private SQL systems have been subsequently developed [15,19,32]. In a similar fashion, Kifer et al propose an architecture in which access to data is mediated by a privacy layer that implements differentially private mechanisms [17].…”