Database Normalization
Database normalization splits related facts into well-shaped tables. This reduces repeated data and mistakes when one fact changes.
Another example
A clinic stops copying a patient's phone, a doctor's name, and three medicine columns into every visit row. Patients, clinicians, visits, and `visit_medications` become related tables. A phone change updates one fact; only a checked reporting view combines data for faster reading.
Main parts
- 01Facts and dependencies
- 02Keys and relations
- 03Anomaly-free updates
Use it when
Use facts, their dependencies, and keys to build one reliable source of truth. Denormalize later only when performance evidence supports it.
Do not use it when
Do not chase higher normal forms without matching the real data relationships. Do not denormalize early without clear ownership and sync rules.
Name used in code
functional dependencies + candidate keys + 1NF/2NF/3NF/BCNF as appropriate Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Database Normalization for this system while keeping data correct, secure, and easy to operate. User context: A clinic stops copying a patient's phone, a doctor's name, and three medicine columns into every visit row. Patients, clinicians, visits, and `visit_medications` become related tables. A phone change updates one fact; only a checked reporting view combines data for faster reading. Technical concept or control: Database Normalization. Why it fits: Use facts, their dependencies, and keys to build one reliable source of truth. Denormalize later only when performance evidence supports it. Do not use it when: Do not chase higher normal forms without matching the real data relationships. Do not denormalize early without clear ownership and sync rules. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Database Normalization. Definition: Database normalization splits related facts into well-shaped tables. This reduces repeated data and mistakes when one fact changes. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.