La première forme normale définit essentiellement la notion d'information atomique. Elle stipule les choses suivantes : Tous ces principes sont en fait assez triviaux. Le fait qu'il ne peut pas y avoir de ligne dupliquée implique que chaque ligne doit avoir une identité , ce qui suppose que l'on peut toujours définir dessus une clé primaire. En général, cette clé primaire est portée par une colonne particulière, mais ce n'est pas toujours le cas. La notion de clé primaire est définie par la deuxième forme normale. Notons que cette forme indique que chaque cellule ne peut porter qu'une seule information. En toute rigueur, une colonne numéro de téléphone de notre table Marins ne doit donc pas comporter plusieurs numéros séparés par des virgules (cas que l'on ne rencontre bien sûr jamais dans la réalité !).

La deuxième forme normale définit la notion de clé primaire. Une table vérifiant la deuxième forme normale doit d'abord vérifier la première forme normale. Si l'on définit une clé primaire PK sur cette table, éventuellement constituée de plusieurs colonnes, alors toutes les colonnes de la table doivent dépendre uniquement de la totalité de PK, et non pas de l'une de ses parties. Théoriquement, cet énoncé peut paraître un peu compliqué, sur un exemple il devient très simple.
Une approche naturelle serait de prendre le nom de chaque musicien comme clé primaire. Ce n'est pas possible, car ce nom devrait permettre d'accéder à une ligne unique, ce qui n'est pas le cas. Une approche plus complexe pourrait consister à prendre les champs (nom, instrument) comme clé primaire. Cette seconde approche échoue aussi, dans la mesure où l'adresse que nous avons ajoutée ne dépend que du nom du musicien, et pas de l'instrument qu'il joue. On viole ici donc le fait qu'une colonne ne peut pas dépendre d'un composant (c'est-à-dire d'une partie) d'une clé primaire. Cette table viole donc la deuxième forme normale, il faut donc la réorganiser. Il faut éclater nos informations en deux tables.

Dans cette dernière table, la clé primaire est constituée des deux colonnes de la table. En toute rigueur il faudrait même éclater cette deuxième table en deux tables, suivant le modèle que nous avons utilisé pour construire la relation entre nos marins et leurs communes de naissance.

La deuxième forme normale nous impose qu'il n'est pas possible qu'une colonne puisse dépendre d'une partie de la clé primaire définie sur la table. La troisième nous impose le complément : une colonne n'a pas le droit de dépendre d'une colonne qui ne fait pas partie de la clé primaire. Prenons un exemple d’une structure qui respecte la deuxième forme normale, et qui malgré tout pose un problème immédiat. Nous avons une première table de marins :
Ces marins embarquent sur des bateaux, qui ont un tonnage :
La table embarquements suit bien la deuxième forme normale : aucune colonne ne dépend d'une partie de la clé primaire. Toutefois, la colonne bateau, qui ne fait pas partie de la clé primaire, sert en fait de clé à la colonne tonnage, puisque le tonnage dépend bien sûr du bateau. Si l’on change la valeur de bateau, qui est une partie de clé primaire, on doit aussi changer celle de tonnage. En cela, elle viole la troisième forme normale : une colonne ne peut pas dépendre d'autre chose que de la clé primaire d'une table.

Il existe encore de nombreuses façons de normaliser les données. Le principe qui sous-tend toutes ces normalisations est cependant toujours le même : unicité des dépendances, unicité des actions SQL à effectuer pour la mise à jour d’une donnée unique. Il appartient aussi à chaque développeur de réfléchir à son problème, et de voir quelle forme normale est la plus simple pour résoudre son problème.