51
4.1 Modélisation de la base de données
Formes normales
Normaliser un modèle de données veut dire le rendre conforme à des règles
nommées « formes normales ». Ce qu’on appelle les formes normales sont des lois
importantes de structuration du modèle, qui permettent de s’assurer que celui-ci
évite les pièges les plus élémentaires, en assurant une base de conception favorable à
un stockage utile et optimal des données. Par utile nous entendons favorable à
l’extraction des données désirées, dans la plupart des cas de figures. Pour être
complet, les formes normales principales sont au nombre de six. Toutefois, les trois
premières sont les plus importantes et les plus utiles dans la « vie réelle » de la modélisation de données. Chaque forme normale complète les formes précédentes. Il est
donc nécessaire de les appliquer dans l’ordre.
Première forme normale (1FN)
Tout attribut doit contenir une valeur atomique, c’est-à-dire que toutes ses
propriétés doivent être élémentaires. En clair, cela signifie que vous utiliserez une
colonne par pièce d’information à stocker, et qu’en aucun cas vous ne vous permettrez de colonnes concaténant des éléments différents d’information. Cette règle est
importante pour deux raisons : elle va vous permettre toute la souplesse nécessaire à
la restitution et à la manipulation des données, et elle va vous permettre, bien plus
en aval, de vous assurer de bonnes performances. Créer le modèle d’une base de
données est aussi un exercice de prudence et d’anticipation. Ne prenez pas de décision à la légère. Si vous estimez par exemple qu’une ligne d’adresse peut être
contenue dans une seule colonne ('12, boulevard de Codd', par exemple), êtesvous sûr que vous n’aurez jamais besoin – donc que personne ne vous demandera
jamais – d’un tri des adresses par rue et numéro de rue ? Si vous modélisez la base de
données d’un service de gestion des eaux, ne voudrez-vous pas fournir aux employés
chargés de relever les compteurs une liste des habitants, dans l’ordre du numéro
d’immeuble de la rue ? Comment ferez-vous sans avoir isolé ce numéro dans un
attribut (une colonne) dédié ? Comme beaucoup, vous allez vous échiner à récupérer
ce numéro avec des fonctions telles que SUBSTRING(), en prenant en compte toutes
les particularités de saisie possibles. Vous n’avez alors plus de garantie de résultats
corrects, seulement celle d’une baisse de performances. En résumé, toute valeur dont
vous savez, ou soupçonnez, que vous allez devoir la manipuler, l’afficher, la chercher
individuellement devra faire l’objet d’un attribut, donc être stockée dans sa propre
colonne. Ne créez des colonnes contenant des types complexes que lorsque leur relation est indissociable.
Attributs de réserve
Une autre réflexion : ne créez pas d’attributs inutiles. Créer des colonnes réservées à un
usage ultérieur, par exemple, n’a aucun sens. Vous alourdissez le modèle et la taille de vos
tables pour rien. Les versions modernes des SGBDR comme SQL Server permettent très facilement d’ajouter ou de supprimer des colonnes après création de la table. Même lorsque les
objets font parties d’une réplication, il est devenu aisé, à partir de SQL Server 2005, de répliquer aussi les changements de structure. Il n’y a donc aucune justification rationnelle à créer
des colonnes réservées.
4.1 Modélisation de la base de données
Formes normales
Normaliser un modèle de données veut dire le rendre conforme à des règles
nommées « formes normales ». Ce qu’on appelle les formes normales sont des lois
importantes de structuration du modèle, qui permettent de s’assurer que celui-ci
évite les pièges les plus élémentaires, en assurant une base de conception favorable à
un stockage utile et optimal des données. Par utile nous entendons favorable à
l’extraction des données désirées, dans la plupart des cas de figures. Pour être
complet, les formes normales principales sont au nombre de six. Toutefois, les trois
premières sont les plus importantes et les plus utiles dans la « vie réelle » de la modélisation de données. Chaque forme normale complète les formes précédentes. Il est
donc nécessaire de les appliquer dans l’ordre.
Première forme normale (1FN)
Tout attribut doit contenir une valeur atomique, c’est-à-dire que toutes ses
propriétés doivent être élémentaires. En clair, cela signifie que vous utiliserez une
colonne par pièce d’information à stocker, et qu’en aucun cas vous ne vous permettrez de colonnes concaténant des éléments différents d’information. Cette règle est
importante pour deux raisons : elle va vous permettre toute la souplesse nécessaire à
la restitution et à la manipulation des données, et elle va vous permettre, bien plus
en aval, de vous assurer de bonnes performances. Créer le modèle d’une base de
données est aussi un exercice de prudence et d’anticipation. Ne prenez pas de décision à la légère. Si vous estimez par exemple qu’une ligne d’adresse peut être
contenue dans une seule colonne ('12, boulevard de Codd', par exemple), êtesvous sûr que vous n’aurez jamais besoin – donc que personne ne vous demandera
jamais – d’un tri des adresses par rue et numéro de rue ? Si vous modélisez la base de
données d’un service de gestion des eaux, ne voudrez-vous pas fournir aux employés
chargés de relever les compteurs une liste des habitants, dans l’ordre du numéro
d’immeuble de la rue ? Comment ferez-vous sans avoir isolé ce numéro dans un
attribut (une colonne) dédié ? Comme beaucoup, vous allez vous échiner à récupérer
ce numéro avec des fonctions telles que SUBSTRING(), en prenant en compte toutes
les particularités de saisie possibles. Vous n’avez alors plus de garantie de résultats
corrects, seulement celle d’une baisse de performances. En résumé, toute valeur dont
vous savez, ou soupçonnez, que vous allez devoir la manipuler, l’afficher, la chercher
individuellement devra faire l’objet d’un attribut, donc être stockée dans sa propre
colonne. Ne créez des colonnes contenant des types complexes que lorsque leur relation est indissociable.
Attributs de réserve
Une autre réflexion : ne créez pas d’attributs inutiles. Créer des colonnes réservées à un
usage ultérieur, par exemple, n’a aucun sens. Vous alourdissez le modèle et la taille de vos
tables pour rien. Les versions modernes des SGBDR comme SQL Server permettent très facilement d’ajouter ou de supprimer des colonnes après création de la table. Même lorsque les
objets font parties d’une réplication, il est devenu aisé, à partir de SQL Server 2005, de répliquer aussi les changements de structure. Il n’y a donc aucune justification rationnelle à créer
des colonnes réservées.