52
Chapitre 4. Optimisation des objets et de la structure de la base de données
Deuxième forme normale (2FN)
L’entité doit respecter la 1FN. Tous les attributs doivent être un fait concernant la
clé tout entière, et non pas un sous-ensemble de la clé. Cette forme normale
concerne les entités dont la clé est composite. Dans ce cas, chaque attribut doit
dépendre de tous les attributs formant la clé. Par exemple, dans notre exemple de
magasin, l’entité VenteProduit représente un produit vendu lors d’un acte de vente.
Sa clé est composite : une clé de produit, une clé de vente. Nous voulons connaître
le prix de vente unitaire du produit, ainsi que le prix d’achat au fournisseur, pour
connaître notre marge. Où devons-nous mettre ces attributs ? Sur la figure 4.2, ils
ont été placés dans l’entité VenteProduit.
Figure 4.2 — Deuxième modèle Commerce
Est-ce logique ? Le prix d’achat au fournisseur dépend-il de toute la clé, c’est-àdire du produit et de la vente ? Certainement pas : le prix d’achat ne dépend pas de
la vente effectuée, à moins que nous gérions notre stock en flux tendu, et que nous
commandions le produit chez notre fournisseur à chaque commande du client. À ce
moment, peut-être négocions-nous un prix particulier selon la quantité
commandée ? Alors, cela aurait peut-être du sens de placer le prix d’achat dans cette
entité. Mais dépendrait-il réellement de la vente ? Si nous réalisons plusieurs ventes
le même jour, et que nous effectuons une commande groupée auprès du fournisseur,
il s’agit alors plus d’une notion de commande fournisseur, qui peut être liée à la
vente, comme par exemple sur la figure 4.3.
Chapitre 4. Optimisation des objets et de la structure de la base de données
Deuxième forme normale (2FN)
L’entité doit respecter la 1FN. Tous les attributs doivent être un fait concernant la
clé tout entière, et non pas un sous-ensemble de la clé. Cette forme normale
concerne les entités dont la clé est composite. Dans ce cas, chaque attribut doit
dépendre de tous les attributs formant la clé. Par exemple, dans notre exemple de
magasin, l’entité VenteProduit représente un produit vendu lors d’un acte de vente.
Sa clé est composite : une clé de produit, une clé de vente. Nous voulons connaître
le prix de vente unitaire du produit, ainsi que le prix d’achat au fournisseur, pour
connaître notre marge. Où devons-nous mettre ces attributs ? Sur la figure 4.2, ils
ont été placés dans l’entité VenteProduit.
Figure 4.2 — Deuxième modèle Commerce
Est-ce logique ? Le prix d’achat au fournisseur dépend-il de toute la clé, c’est-àdire du produit et de la vente ? Certainement pas : le prix d’achat ne dépend pas de
la vente effectuée, à moins que nous gérions notre stock en flux tendu, et que nous
commandions le produit chez notre fournisseur à chaque commande du client. À ce
moment, peut-être négocions-nous un prix particulier selon la quantité
commandée ? Alors, cela aurait peut-être du sens de placer le prix d’achat dans cette
entité. Mais dépendrait-il réellement de la vente ? Si nous réalisons plusieurs ventes
le même jour, et que nous effectuons une commande groupée auprès du fournisseur,
il s’agit alors plus d’une notion de commande fournisseur, qui peut être liée à la
vente, comme par exemple sur la figure 4.3.