Most production OLTP schemas are normalized to Third Normal Form or Boyce-Codd Normal Form and no further. Why do Fourth and Fifth Normal Form rarely appear as an explicit design step, and when is it still worth checking for them?

## The modelling style does the work The reason 4NF rarely bites is structural. When you model entities as tables and give each many-to-many relationship its own junction table with a compound key, every table ends up holding one relationship. A two-column junction table cannot contain two independent multi-valued attributes, so it satisfies 4NF automatically. Violations arise only when someone merges two relationships into one wide table, which competent modelling does not do. Contrast this with 2NF and 3NF, which you actually have to think about: partial and transitive dependencies appear naturally the moment you copy a descriptive attribute next to a foreign key. Those are everyday mistakes; 4NF violations are not. ## Diminishing returns Functional dependencies drive nearly all real redundancy. BCNF removes the redundancy that functional dependencies cause, and the residue that 4NF and 5NF address is small in transactional systems. Spending review time on the residue while the schema still has denormalised descriptive columns is misallocated effort. There is also a cost side. Each further decomposition adds a table and therefore joins on the read path. If the higher form is not fixing an anomaly you can point to, you have bought joins with no return. ## Semantics, not data This is the deepest reason. Functional dependencies are often discoverable and enforceable: a UNIQUE constraint states one, and the engine maintains it. Multivalued and join dependencies are neither. No standard declarative constraint says these two columns are independent, so the DBMS cannot help you find a violation, cannot stop one being introduced, and cannot keep a decomposition honest afterwards. That asymmetry has a sharp edge. Deciding a 4NF or 5NF violation exists requires a domain expert to confirm that independence, or the cyclic rule, is a permanent truth rather than a property of today's rows. Get it wrong and the decomposition is lossy in practice: rejoining the pieces invents combinations nobody ever asserted, and nothing raises an error. The failure mode of over-normalising past BCNF is silent wrong data, whereas the failure mode of stopping at BCNF is a bit of redundancy you can see. ## 5NF specifically 5NF requires a cyclic constraint of the form pairwise facts imply the three-way fact. Genuine ternary relationships in business systems usually are not like that: which supplier supplies which part to which project is normally an independent fact. So the precondition for a 5NF violation is usually absent, and when present the decomposition needs application-level enforcement to stay correct. ## When to actually check Concrete triggers worth a look: - A table with three or more columns in its primary key that is not obviously one relationship. Ask whether it is really two independent relationships glued together. - Row counts that multiply. If adding one tag to an entity inserts several rows, or if a COUNT jumps by a factor rather than by one, you are storing a cross product. - Data imported from spreadsheets, CSV exports or an entity-attribute-value store, where whoever flattened the data had no schema discipline. - Aggregates that are wrong by a constant factor, the classic symptom of joining across a cross product. - SELECT DISTINCT appearing on nearly every query against a table. ## The answer to give Say that you check 4NF opportunistically by asking whether each table represents exactly one relationship, that the modelling style makes explicit 4NF work redundant most of the time, and that 5NF is a completeness result you recognise but rarely act on because it depends on an invariant the database cannot enforce. That combination reads as someone who knows the theory and has judgement about applying it.