Database normalisation is a structured process for organising a relational database's tables specifically to eliminate redundant, duplicated data, following a defined sequence of increasingly strict normal forms, from first normal form through more advanced forms like Boyce-Codd normal form. The central goal throughout this process is making sure any given single fact is stored in exactly one place within the database, which directly prevents a specific, genuinely damaging problem called an update anomaly, where the same real-world fact ends up changed in one stored copy but left unchanged, and now silently incorrect, in another.
Duplicated data creates a real risk that copies quietly drift apart
If the same piece of information, a customer's address, say, is stored redundantly in multiple different places across a database, updating that information correctly requires finding and updating every single one of those stored copies consistently. In practice, this kind of redundant, duplicated storage creates a genuine, ongoing risk: an update might successfully change one stored copy of the fact while missing another, leaving the database holding two contradictory versions of what's actually supposed to be the exact same underlying fact, with no way for the database itself to know which stored copy is now correct.
Normalisation restructures tables so each fact has exactly one home
Each successive normal form in the normalisation process addresses a specific, formally defined category of redundancy, restructuring tables so that related information is grouped together appropriately and any given fact ends up stored in exactly one place, in one specific table, rather than being duplicated across several. Achieving successive normal forms means working through this process step by step, checking a database design against each form's specific formal criteria and restructuring tables as needed until the redundancy that would otherwise enable an update anomaly has been genuinely eliminated, not merely reduced or hidden.
What we're still unsure about
The formal normal forms and the specific redundancy problems each one addresses are precisely defined, well established database theory, confirmed across decades of consistent relational database design practice. What's more genuinely an ongoing area of practical engineering judgement is exactly how far to actually push normalisation in a given real system, since fully normalised databases can sometimes require more complex queries joining several tables together to retrieve commonly needed information, which can meaningfully affect performance — database engineers continue to make deliberate, sometimes contested trade-off decisions between fully eliminating redundancy and accepting some controlled, deliberate redundancy for better query performance, rather than there being one universally correct level of normalisation for every system.
This sits inside Normalisation (1NF through BCNF), one of seven topics in Databases, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.