În proiectarea bazelor de date relationale, tehnica normalizării este folosită pentru a elimina asa-numitele anomalii de actualizare. Această tehnică se sprijină pe o solidă fundamentare teoretică, în care notiunea de dependentă functională joacă un rol cheie.
Dacă vom considera o tabelă care consemnează comenzile clientilor unei companii, aceasta ar putea avea următoarele atribute:
Cod_C - Codul clientului (ex: C03);
Nume_C - Numele clientului (ex: Comimpex SRL);
Loc_C - Localitatea
Info_C - Informatii despre client (ex: adresa, telefon/fax, etc)
Cod_prod - Codul produsului (ex: PL003A);
Den_prod - Denumirea produsului (ex: Placa de retea Ethernet EtherLink III);
Fabr_prod - Fabricantul produsului (ex: 3Com);
Cant - Cantitatea comandată (ex: 20 buc.);
Tabela poate descrie corect comenzile, dar există o serie de inconveniente, majoritatea datorate redundantei. De pildă schimbarea adresei unui client impune actualizarea adresei în toate comenzile pe care acesta le-a lansat (anomalia de modificare). Pe de altă parte nu se pot memora informatii despre un client cîtă vreme nu se derulează comenzi ale acestuia (anomalia de inserare). În fine, dacă stergem singura linie din tabelă cuprinzînd o comandă a unui client, pierdem toate informatiile relative la acesta.
Normalizarea se realizează prin descompunerea tabelelor în mai multe tabele, astfel încît tabela initială să poată fi recompusă fără pierderi de date prin operatii de conectare (join). În principiu, se ajunge în majoritatea cazurilor la o tabelă numită primară, care cuprinde datele esentiale (în exemplul anterior se poate considera o tabelă avînd doar coloanele Cod_C, Cod_P si Cant) si mai multe tabele numite de obicei nomenclatoare, cuprinzînd detalii caracteristice pentru anumite entităti (de exemplu o tabelă cu toti clientii si informatiile despre acestia: Cod_C, Nume_C, Loc_C, Info_C, etc). Se observă să anomaliile de actualizare dispar.
Deoarece depozitul de informatii nu este exploatat tranzactional, anomaliile de actualizare nu au nici o importantă. În plus, pentru un analist, o linie dintr-o tabelă primară nu are nici o semnificatie (două coduri si o cantitate nu înseamnă nimic). Pentru a obtine informatii inteligibile, se impun cel putin două operatii de conectare între tabele (pentru a obtine măcar denumirea produsului si numele clientului), ceea ce poate să încetinească foarte mult accesul la date. Pentru a evita această situatie se obisnuieste ca anumite date provenind din sistemul operational să fie denormalizate la intrarea în depozitul de date, prin operatii de join. Desi se crează redundantă, accesul la informatia semnificativă este mult mai simplu pentru utilizatori.