A normalizálás értelmét egy példán keresztül mutatjuk be. Képzeljük el, hogy egy könyvkereskedés megrendeléseit szeretnénk adatbázisban tárolni. Első nekifutásra próbálkozhatunk a következő táblával:

Cím	Szerző	Ár	Db	Megrendelő	Rendelési cím	Rendelés dátuma
Az ellenállás melankóliája	Krasznahorkai L.	3500	1	Kis Pista	1234 Város u. 3.	2012.01.30.
Java programozás	J. Gosling	8200	2	Nagy Éva	1111 Park u. 1.	2011.11.20.
Az ellenállás melankóliája	Krasznahorkai L.	3500	1	Tél Tamás	4321 Patak út 2.	2012.01.11.
A Sinistra-körzet	Bodor Ádám	4100	1	Kis Pista	1234 Város u. 3.	2012.01.31.
...

Ezzel a tábla-tervvel több problémánk is adódhat.

Redundancia

Az adatbázis feleslegesen többször tárolja a megrendelők adatait. Ez helypazarló, hálózati elérés esetén lassítja is az adatbázis hozzáférést ( hiszen több adatot kell mozgatni ).

Módosítási anomália

Ha "Kis Pista" megrendelő módosítani szeretné a rendelési címet, akkor ezt több helyen is meg kell tennünk. Ha nem minden rekordot frissítünk, akkor az adatbázisban belső ellentmondás jelenhet meg.

Törlési anomália

Ha töröljük "Nagy Éva" megrendelését, akkor elveszítjük a "Java programozás" című könyvre vonatkozó adatokat, pedig lehet, hogy később valaki pont ezt a könyvet szeretné megrendelni.

A megoldás

A felsorolt anomáliákat az adatbázis normalizálásával szokás kiküszöbölni. A formális definíció helyett a fenti példát folytatva megmutatjuk, hogyan történhet ez. A belső függőségeket tartalmazó táblákat több részre vágjuk.
Például: tegyük fel, hogy egy  megrendelő  mindig azonos címre rendeli a könyveket. Ekkor célszerű a megrendelőket külön táblában tárolni.

id	megrendelő	rendelési cím
1	Kis Pista	1234 Város u. 3.
2	Nagy Éva	1111 Park u. 1.
3	Tél Tamás	4321 Patak út. 2.

A könyvek adatait is külön fogjuk tárolni, hiszen a kínálat és a pillanatnyilag élő megrendelések általában nem fedik egymást.