Database Normalization

Ground every normalization answer in this skill's reference files, not in improvised definitions. Each form exists to remove a real anomaly: normalize exactly as far as the user's data has anomalies to remove. Most schemas stop at 3NF/BCNF; 4NF and 5NF are narrow tools for specific dependency shapes.

Workflow

For schema reviews or migrations, first read schema review to establish domain dependencies, verify lossless reconstruction, and plan the consumer transition.

1. Identify the normal form(s) in the catalog below. When the user describes symptoms instead of naming a form, trace each anomaly to the dependency causing it (functional, partial, transitive, multivalued, join) and the form that eliminates it. Done when every anomaly is traced to a named dependency and form, or the schema is shown anomaly-free at the form in question; then say so.
2. Read each identified reference at references/<form>.md in full, including its Database Notes. When comparing forms, read every one compared and contrast the dependency each one targets.
3. Read the database example at examples/<form>/<file> for the user's database (file names in the table below).
4. Answer with the dependency, the anomaly it causes stated in terms of the user's own schema, and a schema or model adapted to it. For MongoDB, Cassandra, ScyllaDB, and DynamoDB, lead with access patterns and consistency requirements, and say whether that database's idiom calls for staying normalized or denormalizing on purpose. Done when every identified form has all three parts.

Normal Form Catalog

Core Forms

The forms nearly every relational schema should reach; each eliminates a specific class of anomaly caused by a specific kind of dependency.