Database Normalization Analyzer

Normalization is mechanical once you write the functional dependencies down, but doing it by hand is slow and easy to get wrong — especially finding every candidate key. Paste your attributes and dependencies and this analyzer computes attribute closures, enumerates the candidate keys, marks prime and non-prime attributes, reports which dependency breaks 2NF, 3NF or BCNF and why, then produces a minimal cover, a dependency-preserving 3NF synthesis, a lossless BCNF decomposition and a DDL sketch to start from. Everything is computed in your browser.

Attributes (comma separated, optional — inferred from the dependencies if left blank)

Functional dependencies — one per line, e.g. order_id, product_id -> quantity

Multi-valued / repeating attributes for the 1NF check (optional, comma separated)

Analysis

Attributes (8)
--------------------
order_id, product_id, quantity, product_name, unit_price, customer_id, customer_email, customer_city

Functional dependencies (4)
----------------------------
  order_id, product_id -> quantity
  product_id -> product_name, unit_price
  order_id -> customer_id
  customer_id -> customer_email, customer_city

Candidate keys (1)
--------------------
  { order_id, product_id }

Prime attributes: order_id, product_id
Non-prime attributes: quantity, product_name, unit_price, customer_id, customer_email, customer_city

Highest normal form satisfied
-----------------------------
  1NF

Violations
----------
  [2NF] product_id -> product_name
         product_name is a non-prime attribute that depends on part of the candidate key (product_id).
  [2NF] product_id -> unit_price
         unit_price is a non-prime attribute that depends on part of the candidate key (product_id).
  [2NF] order_id -> customer_id
         customer_id is a non-prime attribute that depends on part of the candidate key (order_id).
  [3NF] customer_id -> customer_email
         customer_email is non-prime and customer_id is neither a superkey nor part of a key — a transitive dependency.
  [3NF] customer_id -> customer_city
         customer_city is non-prime and customer_id is neither a superkey nor part of a key — a transitive dependency.
  [BCNF] product_id -> product_name
         product_id is not a superkey.
  [BCNF] product_id -> unit_price
         product_id is not a superkey.
  [BCNF] order_id -> customer_id
         order_id is not a superkey.
  [BCNF] customer_id -> customer_email
         customer_id is not a superkey.
  [BCNF] customer_id -> customer_city
         customer_id is not a superkey.

Minimal cover (4)
--------------------
  order_id, product_id -> quantity
  product_id -> product_name, unit_price
  order_id -> customer_id
  customer_id -> customer_email, customer_city

3NF decomposition (synthesis — lossless and dependency preserving)
----------------------------------------------------------------
  r1 ( order_id, product_id, quantity )
  r2 ( product_id, product_name, unit_price )
  r3 ( order_id, customer_id )
  r4 ( customer_id, customer_email, customer_city )

BCNF decomposition (lossless; may not preserve every dependency)
--------------------------------------------------------------
  r1 ( order_id, product_id, quantity )
  r2 ( customer_id, order_id )
  r3 ( customer_id, customer_email, customer_city )
  r4 ( product_id, product_name, unit_price )

DDL sketch for the 3NF decomposition
------------------------------------
CREATE TABLE r1 (
  order_id <type> NOT NULL,
  product_id <type> NOT NULL,
  quantity <type>,
  PRIMARY KEY (order_id, product_id)
);

CREATE TABLE r2 (
  product_id <type> NOT NULL,
  product_name <type>,
  unit_price <type>,
  PRIMARY KEY (product_id)
);

CREATE TABLE r3 (
  order_id <type> NOT NULL,
  customer_id <type>,
  PRIMARY KEY (order_id)
);

CREATE TABLE r4 (
  customer_id <type> NOT NULL,
  customer_email <type>,
  customer_city <type>,
  PRIMARY KEY (customer_id)
);

Do more than database normalization analyzer — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

List the attributes of the relation, separated by commas — or leave the field empty and let the analyzer read them from your dependencies.
Write one functional dependency per line as "a, b -> c, d"; add any attribute that stores multiple values per row to the 1NF field.
Read the candidate keys and violations, then copy the 3NF or BCNF decomposition and the DDL sketch as the starting point for your schema.

Frequently asked questions

What is the difference between 2NF, 3NF and BCNF?

All three are about which attributes a dependency is allowed to have on its left-hand side. A relation is in 2NF when no non-prime attribute depends on only part of a candidate key — that rules out partial dependencies, which only exist when a key is composite. It is in 3NF when, in addition, no non-prime attribute depends on another non-key attribute; that rules out transitive dependencies such as order_id determining customer_id which in turn determines customer_email. It is in BCNF when every non-trivial dependency has a superkey on the left, which is strictly stronger: a relation can be in 3NF and still violate BCNF when a prime attribute depends on a non-superkey. BCNF removes more redundancy, but a BCNF decomposition sometimes cannot preserve every dependency, while a 3NF synthesis always can.

How are the candidate keys computed?

By attribute closure. Any attribute that never appears on the right-hand side of a dependency must belong to every candidate key, so those are fixed first. The analyzer then adds the remaining attributes in increasing combination size, computes the closure of each candidate set, and keeps the ones whose closure covers all attributes — skipping any set that already contains a smaller key, which is what makes a key minimal rather than merely a superkey. The search is capped at 24 attributes and at five optional attributes per key to keep the page responsive; if a cap is hit, the report says so explicitly rather than presenting a partial answer as complete.

Should I always normalize all the way to BCNF?

No. Normalize to 3NF by default: it removes the redundancy that causes update anomalies while keeping every dependency checkable on a single table. Go to BCNF when a remaining anomaly is actually hurting you and you can enforce the lost dependency another way. Go the other direction — deliberate denormalization — only for read paths you have measured, and keep the normalized tables as the source of truth. To explore an existing schema, inspect its keys and constraints and test a decomposition against real data, Chat2DB is an AI SQL client for PostgreSQL, MySQL, Oracle and 20+ other engines; download it at https://chat2db.ai/download or use https://app.chat2db.ai in a browser.