Model your data right without being a developer

Data normalization is taught in SQL, with vocabulary that puts people off. Our claim: it works perfectly well in a no-code database, and three habits cover the bulk of everyday cases — one table per entity, links instead of copies, atomic fields. If you can create a field in Airtable, you can normalize.

The idea is not new. In 1970, in the very first sentence of his paper, E. F. Codd founded the relational model on a promise: future users must be

"protected from having to know how the data is organized in the machine" — E. F. Codd, CACM, 1970

Separating the meaning of data from its machinery: that is exactly what a no-code database does 55 years later. The theory has not changed; the tool has become accessible.

Why the schema is the real deliverable, we covered in model before you tool up; this article is its hands-on companion — only the how. "Spreadsheets used as databases" is one of the seven real starting points of our projects (Ownward internal data, 2026): here is what we fix first.

Microsoft's database design documentation — the mainstream reference, written without a line of SQL — rests on two principles: divide information into subject-based tables, and record each fact just once. Duplicated data, Microsoft writes, wastes space and increases the likelihood of errors and inconsistencies.

The habit: one table per entity — customers, orders, products. The test: if you type the same customer name into two tables, you are missing a table.

Each fact lives with its owner; everything else is derived through links and computed fields, never through re-entry.

In 1983, William Kent condensed the second and third normal forms into one canonical sentence: a field must state a fact about "the key, the whole key, and nothing but the key." In business terms: every column describes the entity of its own table. The sales rep's email does not belong in the Orders table — it describes the rep.

In Airtable, this principle has a name: the linked record field. It creates a bidirectional relationship, automatically mirrored in the linked table. It is the SQL foreign key without the word or the syntax: you link, you don't retype.

The link then unlocks two computed fields that eliminate re-entry:

• the lookup displays a value from the linked record without copying it — the value stays with its owner;
• the rollup aggregates linked records — sum, average, count, among 19 functions, on every plan. An order total calculates itself from its lines.

Airtable's documentation states the benefit plainly: linking records minimizes redundant data entry while ensuring the latest information is available everywhere. Kent, for his part, reminded us that normalization rules exist to prevent update anomalies and data inconsistencies — not an academic exercise, an insurance policy.

What doing nothing costs — Every copied value is an inconsistency waiting to happen: the reference research on spreadsheet risk (EuSpRIG, 2000 — historical) found errors in at least 86% of spreadsheets audited from 1997 onward. Duplication also costs quota: 1,000 records per base on Free, 50,000 on Team ($20/seat/month), 125,000 on Business ($45/seat/month), verified August 12, 2026. Copying means spending your ceiling twice.

First normal form, academic version: at every row/column intersection, a single value, never a list. Microsoft's version, jargon-free: break each piece of information into its smallest useful parts — anything you want to sort, filter or calculate on deserves its own field.

The Airtable habit is typing: around thirty field types — single select, email, phone, currency, date, duration. A free-text status will produce "in progress", "In Progress" and "inprogress"; a single select allows one option from a controlled list. An address in one block cannot be filtered by city; four fields can.

The pocket rule: one field = one piece of information, of the right type. A comma separating two things in one cell means two fields — or two linked records.

There remains the case that stalls most self-built bases: the many-to-many relationship. A book has several authors, an author writes several books — Airtable's documentation describes all three relationship types, with examples.

The trap: when the relationship itself carries information. An order contains several products, each with its quantity — where does the quantity go? Not in the order, not in the product: it describes the pair. Airtable then recommends a junction table: an "Order lines" table where each record links one order and one product, and carries the quantity.

Normalization, translated into Airtable habits, fits in three rows:

The principle scales: our synchronization engine connects 6 CRM/ERP systems to a single source of truth, driven by a mapping stored in Airtable — zero re-entry, a new source = a new mapping, no code (Ownward internal data, 2026). It is the heart of how we build: structure first, tool second.

Run your base through the sieve: every sign has its corrective move, and none requires code.

One sign checked: the fix is quick and local. Five or more: go back to the model before adding a single field.

Three habits cover most cases, not all. A no-code database does not enforce referential integrity the way a classic database engine does: no uniqueness constraint on the primary field, no safety net when deleting a linked record. Rigor remains a team discipline — a matter of governance more than tooling. Beyond plan volumes, or as soon as strong isolation between customers is required, the pattern to remember is migrating to a managed relational database — a path we have taken on 8 of our production applications (Ownward internal data, 2026). And modeling is never finished: a new entity in the business means a new table in the base.