54
Chapitre 4. Optimisation des objets et de la structure de la base de données
Prévision
Dans la phase de modélisation conceptuelle, on ne réfléchit pas à l’utilité des clés par rapport
aux requêtes d’extraction. Dans la modélisation physique, il devient utile, voir nécessaire de le
faire, pour intégrer les performances des requêtes déjà au niveau de la modélisation – c’est
l’objet de cet ouvrage. Nous pensons qu’il est très utile d’avoir en tête les facilités apportées à
nos requêtes, et à notre recherche d’information, pour intégrer ces besoins et ces contraintes
dans notre modélisation physique.
Malheureusement, ce modèle est loin d’être parfait. Nous avons, notamment,
deux quantités : une quantité de produits commandés, et une quantité de produits
vendus. Ne peut-on pas déduire le nombre de produits commandés en additionnant
le nombre de produits vendus ? Si oui, il est important de supprimer l’attribut Quantite de l’entité CommandeFournisseur. Pourquoi ? Car si nous la conservons, la question sera : où aller chercher l’information ? Si plus tard, à l’aide d’une requête, nous
trouvons une différence entre la quantité de produits commandés et la somme des
produits vendus, quelle est la quantité qui nous donne ce qui s’est vraiment passé
dans la réalité ?
Par contre, si nous n’avons que l’attribut Quantite de l’entité VenteProduit, que
se passe-t-il si une vente est annulée par le client après sa passation de commande,
ou si le client modifie sa quantité ? Comment savoir quelle est la quantité de produits réellement commandée ? Ici, le modèle doit être complété : si le client modifie
la quantité de produits voulus, il nous faut un moyen d’en conserver l’historique,
peut-être en amendant la vente, ou en créant une deuxième vente liée à la première,
par une clé récursive. Et si la vente est annulée, il nous faut certainement également
un moyen d’exprimer dans notre schéma ce qu’il advient des produits commandés,
afin de ne pas en perdre la trace, et de pouvoir les attribuer à des ventes ultérieures,
pour gérer efficacement notre stock.
Troisième forme normale (3FN)
L’entité doit respecter la 2FN. Tous les attributs doivent être des faits concernant
directement la clé, rien que la clé. Ils ne doivent en aucun cas dépendre d’un attribut
non-clé. Dans notre exemple précédent, si l’entité Vente contient un attribut
magasin, peut-on dire qu’il viole la 3FN ? Douteux parce que la vente a bien lieu
dans un magasin ? Certes, les deux informations sont liées, mais le magasin dépendil de la vente (la clé), et seulement de la vente ? Non, parce que dans le monde que
nous modélisons, le magasin dépend aussi d’un attribut non-clé : l’employé, car nous
savons que cet employé est attribué à un magasin. Il viole donc la 3FN. En ajoutant
des attributs qui dépendent d’un attribut non-clé, nous sommes certains d’introduire
de la redondance dans le modèle. Ici, l’identifiant de magasin n’a besoin d’être écrit
qu’une seule fois, dans l’entité Employé, et non pas à chaque vente.
Un signe courant et évident de violation de la 3NF, est la présence dans une
entité d’attributs numérotés. Des attributs tels que Adresse1, Adresse2, Adresse3
peuvent à la rigueur être douloureusement acceptés, mais AdressePrivee1,
AdressePrivee2,
AdressePrivee3,
AdresseProfessionnelle1,
AdresseProfessionnelle2, AdresseProfessionnelle3, est clairement un problème. Il
Chapitre 4. Optimisation des objets et de la structure de la base de données
Prévision
Dans la phase de modélisation conceptuelle, on ne réfléchit pas à l’utilité des clés par rapport
aux requêtes d’extraction. Dans la modélisation physique, il devient utile, voir nécessaire de le
faire, pour intégrer les performances des requêtes déjà au niveau de la modélisation – c’est
l’objet de cet ouvrage. Nous pensons qu’il est très utile d’avoir en tête les facilités apportées à
nos requêtes, et à notre recherche d’information, pour intégrer ces besoins et ces contraintes
dans notre modélisation physique.
Malheureusement, ce modèle est loin d’être parfait. Nous avons, notamment,
deux quantités : une quantité de produits commandés, et une quantité de produits
vendus. Ne peut-on pas déduire le nombre de produits commandés en additionnant
le nombre de produits vendus ? Si oui, il est important de supprimer l’attribut Quantite de l’entité CommandeFournisseur. Pourquoi ? Car si nous la conservons, la question sera : où aller chercher l’information ? Si plus tard, à l’aide d’une requête, nous
trouvons une différence entre la quantité de produits commandés et la somme des
produits vendus, quelle est la quantité qui nous donne ce qui s’est vraiment passé
dans la réalité ?
Par contre, si nous n’avons que l’attribut Quantite de l’entité VenteProduit, que
se passe-t-il si une vente est annulée par le client après sa passation de commande,
ou si le client modifie sa quantité ? Comment savoir quelle est la quantité de produits réellement commandée ? Ici, le modèle doit être complété : si le client modifie
la quantité de produits voulus, il nous faut un moyen d’en conserver l’historique,
peut-être en amendant la vente, ou en créant une deuxième vente liée à la première,
par une clé récursive. Et si la vente est annulée, il nous faut certainement également
un moyen d’exprimer dans notre schéma ce qu’il advient des produits commandés,
afin de ne pas en perdre la trace, et de pouvoir les attribuer à des ventes ultérieures,
pour gérer efficacement notre stock.
Troisième forme normale (3FN)
L’entité doit respecter la 2FN. Tous les attributs doivent être des faits concernant
directement la clé, rien que la clé. Ils ne doivent en aucun cas dépendre d’un attribut
non-clé. Dans notre exemple précédent, si l’entité Vente contient un attribut
magasin, peut-on dire qu’il viole la 3FN ? Douteux parce que la vente a bien lieu
dans un magasin ? Certes, les deux informations sont liées, mais le magasin dépendil de la vente (la clé), et seulement de la vente ? Non, parce que dans le monde que
nous modélisons, le magasin dépend aussi d’un attribut non-clé : l’employé, car nous
savons que cet employé est attribué à un magasin. Il viole donc la 3FN. En ajoutant
des attributs qui dépendent d’un attribut non-clé, nous sommes certains d’introduire
de la redondance dans le modèle. Ici, l’identifiant de magasin n’a besoin d’être écrit
qu’une seule fois, dans l’entité Employé, et non pas à chaque vente.
Un signe courant et évident de violation de la 3NF, est la présence dans une
entité d’attributs numérotés. Des attributs tels que Adresse1, Adresse2, Adresse3
peuvent à la rigueur être douloureusement acceptés, mais AdressePrivee1,
AdressePrivee2,
AdressePrivee3,
AdresseProfessionnelle1,
AdresseProfessionnelle2, AdresseProfessionnelle3, est clairement un problème. Il