Data Architecture

Database Normalisation Checker

Reads your DDL and raises the shapes that usually accompany a first, second or third normal form problem.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste your CREATE TABLE statements. Several tables at once is fine and gives better results, since foreign keys inform the analysis.
  2. Select Check normalisation.
  3. Read each finding as a question. The severity column says how likely it is to be a real dependency problem rather than a naming coincidence.
  4. Confirm anything you intend to act on against the data and the business rules before you change the model.

What normalisation checker does

Normal forms are defined by functional dependencies, and functional dependencies live in the data and in the business rules — not in the schema text. No tool that reads only DDL can tell you a model is in third normal form, and anything that claims to is guessing while sounding certain.

What a schema can show you is the shapes that almost always accompany a dependency problem: three columns called phone1, phone2 and phone3; a column called tag_list; a customer_name sitting in a table keyed on customer and product together; an attribute of a referenced entity carried alongside its foreign key. Each of those is raised here as a question with the reasoning attached, ranked by how likely it is to actually be one. A clean result is much weaker evidence than a dirty one, and the tool says so rather than congratulating you.

Frequently asked questions

No, and neither can anything else that reads only DDL. Normal forms are defined by functional dependencies, which live in the data and the business rules. What a schema shows is the shapes that usually accompany a dependency problem. Everything reported here is a question to take to someone who knows the data, which is why a clean result is much weaker evidence than a dirty one.

They are a one-to-many relationship flattened into a row. The count is capped at three whatever the business later needs, every query that searches for a phone number has to check all three columns, and adding a fourth means a schema change plus edits to every one of those queries. A child table keyed on the parent holds any number and searches with one predicate.

It is an attribute that depends on part of a composite key rather than all of it. In a table keyed on customer and product together, customer_name depends only on the customer — so it is stored once for every product that customer has ever ordered, and changing the name means updating every one of those rows or living with the ones you miss. Move it to the customer table and it exists once.

Not at all. Dimensional models denormalise deliberately, and copying an attribute alongside its key is standard practice in a warehouse where reading fast matters more than writing once. The distinction the tool cares about is whether it was a decision. A denormalised column that someone chose, documented and knows how to refresh is fine; the same column arrived at by accident is a consistency bug waiting to be found by a report.