Relational Data Synthesis

The primary challenge is ensuring foreign key relationships are perfectly maintained in the synthetic data. A generated 'Order' record must reference a valid, existing synthetic 'Customer' ID. Failure creates orphaned records or broken joins, rendering the dataset useless for testing or analytics. Solutions involve:

• Joint modeling of parent and child tables.
• Sequential generation where parent tables are synthesized first.
• Constraint-aware sampling from the generator's output.

Synthesizers must capture and replicate the joint probability distribution across all related tables. This includes:

• Column-wise distributions (marginals) within each table.
• Inter-table correlations (e.g., the distribution of 'OrderAmount' linked to 'CustomerIncomeTier').
• Cardinality ratios (e.g., average number of 'Orders' per 'Customer'). Models like Hierarchical Bayesian Networks or Graphical Generative Models are often employed to model these complex, high-dimensional dependencies.

Real databases enforce business rules beyond simple foreign keys. Synthesizers must generate data that respects:

• Temporal constraints (e.g., a 'ShipDate' must be after the 'OrderDate').
• Conditional uniqueness (e.g., an 'ActiveSubscription' per customer).
• Derived attributes (e.g., 'TotalPrice' = Sum('LineItem.Price')). Ignoring these rules produces semantically invalid data. Techniques involve post-generation rule enforcement, constrained optimization during sampling, or integrating logic as hard constraints in the model's loss function.

Enterprise databases can have dozens or hundreds of related tables. Modeling the full dependency graph becomes computationally intractable. Key scaling challenges include:

• Exponential growth in relationship permutations.
• Training instability for deep models on highly sparse relational data.
• Memory overhead for storing the state of the entire graph during generation. Common strategies are schema partitioning (synthesizing related table clusters independently), summary statistics for distant relationships, and progressive generation from core entities outward.

Differential privacy guarantees are harder to achieve in relational data. Adding noise to preserve privacy can:

• Severely distort relationship cardinalities (e.g., a customer appears to have 500 orders instead of 5).
• Break referential integrity through noisy key generation.
• Destroy subtle multi-table correlations critical for model training. Methods like PrivBayes extend differential privacy to relational settings by building a private Bayesian network of the schema, but utility loss remains a significant challenge compared to single-table synthesis.

Assessing the quality of synthetic relational data requires multi-faceted metrics beyond single-table tests. Key evaluation dimensions include:

• Statistical Similarity: Using metrics like Wasserstein Distance on marginal and conditional distributions across tables.
• Relational Faithfulness: Measuring the preservation of foreign key joinability and cardinality distributions.
• Downstream Utility: The Train on Synthetic, Test on Real (TSTR) paradigm for multi-table tasks (e.g., training a JOIN-heavy analytical query model on synthetic data).
• Privacy Audits: Testing for membership inference attacks that could exploit relational leaks.

The measurable effectiveness of a generated dataset for downstream tasks. Utility is not a single metric but a multi-faceted evaluation:

• Statistical Fidelity: Preservation of marginal distributions, pairwise correlations, and higher-order joint distributions (e.g., using Wasserstein Distance or Kolmogorov-Smirnov tests).
• Machine Learning Efficacy: Measured via the Train on Synthetic, Test on Real (TSTR) protocol, where a model trained on synthetic data is evaluated on held-out real data.
• Task-Specific Performance: The synthetic data's ability to maintain utility for specific applications like fairness auditing, model debugging, or predictive analytics.

A rigorous mathematical framework that provides a strong, quantifiable privacy guarantee for synthetic data generation algorithms. It ensures that the output (synthetic dataset) does not reveal whether any specific individual's record was in the training data.

• Formal Definition: An algorithm is (ε, δ)-differentially private if for any two neighboring datasets (differing by one record), the probability of any output is within a multiplicative factor of e^ε (plus a small δ).
• Implementation in Synthesis: Methods like PrivBayes inject calibrated noise (e.g., Laplace or Gaussian) into the parameters of a learned Bayesian network before generating synthetic samples.
• Privacy-Utility Trade-off: A core challenge is balancing the strength of the privacy guarantee (ε) with the statistical utility of the resulting synthetic data.

The definitive evaluation protocol for assessing the practical utility of synthetic tabular data. It directly measures how well a model trained on artificial data generalizes to real-world scenarios.

• Procedure:
  1. Split the real dataset into training and test sets.
  2. Generate a synthetic dataset from the real training set.
  3. Train a downstream ML model (e.g., a classifier or regressor) only on the synthetic data.
  4. Evaluate the model's performance on the held-out real test set.
• Comparison Baseline: Often contrasted with TRTR (Train on Real, Test on Real) to quantify the performance gap introduced by using synthetic data.
• Primary Metric: The closer the TSTR performance is to TRTR, the higher the utility of the synthetic data for that specific modeling task.