How to Generate Fake Relational Tables: A Step-by-Step Tutorial

This tutorial walks through building three related fake database tables from scratch using the Relational Data Generator — with screenshots of every single step. By the end you'll have a complete, importable dataset with a customers table, an address_book table, and an invoices table, all wired together with real foreign keys.

Connect on LinkedIn →

We'll also cover the theory behind relational tables so you understand why the setup works the way it does — not just how to click through it.

What Are Relational Tables and Why Do They Matter?

A relational database stores data across multiple tables, and those tables are connected to each other. Rather than cramming every piece of information about a customer into one giant row, a relational database splits the data into logical groups and links them together.

The connection mechanism is the foreign key. A foreign key is a column in one table that stores the ID value of a row in another table. It creates a reference — a pointer — that says "this row belongs to that row over there."

Here's a simple mental model. Imagine three filing cabinets:

• The Customers cabinet has one card per customer, each with a unique ID number
• The Address Book cabinet has address cards — but instead of writing the customer's name on each card, you write their ID number from the Customers cabinet
• The Invoices cabinet has invoice slips — and again, each slip has the customer's ID number written on it, not their full details

When you want to know everything about customer #4821, you look up ID 4821 in the Customers cabinet, then search the other cabinets for anything with that same ID. Every cabinet stays lean — no duplicated names, addresses repeated across dozens of invoices — and the whole system stays consistent by design.

What is referential integrity?

Referential integrity is the rule that says: every foreign key value must exist in the table it references. You cannot have an invoice for customer #9999 if there is no row with ID 9999 in the customers table. This sounds obvious but it's the most common thing that breaks when you generate fake data naively — you end up with invoices referencing customer IDs that don't exist anywhere.

The Relational Data Generator handles this automatically. It generates the customers table first, captures all the real customer IDs it created, and then uses only those real IDs when building the address_book and invoices tables. The result is a dataset that will import cleanly into any database with FK constraints enabled.

The Schema We're Building

Our three tables and what each one stores:

Notice that both address_book and invoices reference customers — customers is the parent table and the other two are child tables. A customer can have multiple addresses and multiple invoices, but every address and every invoice must belong to a real customer.

The record ratio we'll use: 100 customers → 200 addresses → 400 invoices. This means roughly 2 addresses per customer and 4 invoices per customer on average — a realistic ratio for a small business billing system.

Understanding the Generated SQL

Let's look at what the downloaded script actually contains and why each part is structured the way it is.

The file header

The script opens with a comment block summarising everything:

-- Script generated by DataConversionCenter.com
-- Dialect: PostgreSQL  |  Tables: 3  |  Total records: 700
-- Generated: 2026-02-24
-- Insert order respects foreign key dependencies
-- ── Table order: customers → address_book → invoices

The "insert order" note is important. The script always inserts parent tables before child tables. If you try to run the address_book inserts before the customers inserts, the FK constraint check fails because the customer IDs don't exist yet. The generator handles this automatically.

The CREATE TABLE block for customers

-- ── 1 of 3: customers (100 records) ──────────────────────
CREATE TABLE IF NOT EXISTS "customers" (
  "customer_id"  UUID          NOT NULL,
  "first_name"   VARCHAR(100)  NOT NULL,
  "last_name"    VARCHAR(100)  NOT NULL,
  "email"        VARCHAR(255)  NOT NULL,
  "phone"        VARCHAR(25)   NOT NULL,
  "created_at"   TIMESTAMPTZ   NOT NULL,
  PRIMARY KEY ("customer_id")
);

Notice the PostgreSQL-specific types: UUID (a native type in PostgreSQL), TIMESTAMPTZ (timestamp with timezone). If you'd chosen MySQL, these would be VARCHAR(36) and DATETIME respectively. The generator maps each field type to the correct SQL type for your chosen dialect.

The CREATE TABLE block for address_book — with the FK constraint

-- ── 2 of 3: address_book (200 records) ───────────────────
CREATE TABLE IF NOT EXISTS "address_book" (
  "address_id"    UUID          NOT NULL,
  "customer_id"   UUID          NOT NULL,
  "address_line_1" VARCHAR(200) NOT NULL,
  "address_line_2" VARCHAR(100),
  "city"          VARCHAR(100)  NOT NULL,
  "state"         CHAR(2)       NOT NULL,
  "zip_code"      CHAR(5)       NOT NULL,
  "is_primary"    BOOLEAN       NOT NULL,
  PRIMARY KEY ("address_id"),
  FOREIGN KEY ("customer_id") REFERENCES "customers" ("customer_id")
);

The final line is the FK constraint. It tells PostgreSQL: the customer_id column in this table must always reference a value that exists in customers.customer_id. Any attempt to insert an address with a customer_id that doesn't exist in the customers table will be rejected by the database engine itself.

The bulk INSERT blocks — transaction-wrapped

BEGIN;

INSERT INTO "customers" ("customer_id", "first_name", "last_name", "email", "phone", "created_at") VALUES
  ('f47ac10b-58cc-4372-a567-0e02b2c3d479', 'Sarah', 'Mendoza', '[email protected]', '(847) 293-5571', '2023-03-14T09:42:17Z'),
  ('b3c4d5e6-89ab-cdef-0123-456789abcdef', 'James', 'Wilson', '[email protected]', '(312) 847-2910', '2022-11-07T14:22:44Z'),
  -- ... 98 more rows
;

COMMIT;

All 100 customers are inserted in a single batch, wrapped in BEGIN / COMMIT. If any row fails, the entire batch rolls back — you won't end up with a partially-inserted customers table.

The address_book inserts — with real customer IDs

BEGIN;

INSERT INTO "address_book" ("address_id", "customer_id", "address_line_1", ...) VALUES
  ('c8d9e0f1-...', 'f47ac10b-58cc-4372-a567-0e02b2c3d479', '4821 Ridgewood Ave', ...),
  ('d1e2f3a4-...', 'b3c4d5e6-89ab-cdef-0123-456789abcdef', '192 Maple St',       ...),
  -- ...
;

COMMIT;

Look at the customer_id values in the address_book insert: f47ac10b-58cc-4372-a567-0e02b2c3d479. That's the exact same UUID that was used as the primary key for Sarah Mendoza in the customers insert above. The generator captured all 100 customer UUIDs during generation and used them when building the address_book rows. That's referential integrity guaranteed.

The output data

Here's what the actual generated rows look like across all three tables. Notice that the customer_id values in address_book and invoices always match real IDs from customers:

Sarah Mendoza (f47ac10b-...) appears in both the address_book (she has two addresses) and in invoices (she has two invoices). Maria Thompson (a1b2c3d4-...) also appears in invoices. Every value in the customer_id column of both child tables is a real UUID from the customers table — that's what makes this dataset importable.

Exporting as CSV and JSON Instead

SQL isn't always the right format. If you need to import the data using a GUI tool, test it in a JavaScript application, or load it into a document database, switch the output format before clicking Generate.

CSV format

Select CSV in the format row. Each table downloads as a separate file: customers.csv, address_book.csv, invoices.csv. The FK relationships are preserved by value — the customer_id values in address_book.csv match real IDs in customers.csv.

CSV is the right choice for importing with a GUI tool like TablePlus, DBeaver, or pgAdmin's import wizard, or for loading data into Google Sheets or Excel for review.

JSON nested format

Select JSON (nested) to get a single file where addresses and invoices are embedded inside each customer object:

[
  {
    "customer_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "first_name": "Sarah",
    "last_name": "Mendoza",
    "email": "[email protected]",
    "addresses": [
      { "address_id": "c8d9e0f1-...", "address_line_1": "4821 Ridgewood Ave", "city": "Austin", ... },
      { "address_id": "d1e2f3a4-...", "address_line_1": "113 Oak Blvd Apt 4B", ... }
    ],
    "invoices": [
      { "invoice_id": "11a2b3c4-...", "invoice_number": "INV-2024-0892", "amount_due": "4291.47", ... },
      { "invoice_id": "33c4d5e6-...", "invoice_number": "INV-2025-0012", "amount_due": "341.00", ... }
    ]
  }
]

This nested format is ideal for MongoDB or Firestore where documents can contain nested arrays, for GraphQL mock servers, or for React and Vue application development where components receive nested customer data from an API.