42
Chapitre 4 • Concepts des bases de données
COMPTE (propriété 3). Étant donné que l’identifiant (NCLI, NFOURN) de COMPTE
est constitué de deux clés étrangères, on a aussi les propriétés suivantes :
• toute valeur de NCLI de COMPTE est une valeur de NCLI de CLIENT (propriété
1),
• toute valeur de NFOURN de COMPTE est une valeur de NFOURN de FOURNISSEUR (propriété 2).
Des propriétés 1, 2 et 3, on déduit alors que (figure 3.10) :
• toute valeur de NCLI de ACHAT est une valeur de NCLI de CLIENT (propriété
4),
• toute valeur de NFOURN de ACHAT est une valeur de NFOURN de FOURNISSEUR (propriété 5).
Cependant, les propriétés 4 et 5 ne peuvent jamais se substituer à la propriété 3,
comme le suggère le schéma de la figure 3.10.
Figure 3.10 - Une version incorrecte du schéma 3.9
Par exemple, un achat représenté par (C123,F445,14/04/2006,...) est valide,
non pas par l’existence d’un client n° C123 et d’un fournisseur n° F445, mais parce
qu’il existe un compte identifié par (C123,F445), auquel il est attaché 11 . Il s’agit
d’une erreur qui apparaît fréquemment chez les modélisateurs débutants.
11. Plus précisément, cette discussion se base sur deux propriétés importantes concernant les
règles d’inclusion, et donc les clés étrangères. La première (dite de décomposition) veut que si
U.(A,B) ⊆ T.(A,B), alors on a aussi que U.A ⊆ T.A et U.B ⊆ T.B; l’inverse n’est cependant pas
vraie. La seconde (dite de transitivité) stipule que si U.A ⊆ T.A et T.A ⊆ R.A, alors on a aussi
U.A ⊆ R.A. Etant donné les propriétés (T.A ⊆ R.A) et (T.B ⊆ S.B), la propriété (U.(A,B) ⊆
T.(A,B)) permet d’inférer (U.A ⊆ R.A) et (U.B ⊆ S.B). Mais, une fois encore, l’inverse n’est pas
vraie. Dans cette formulation, R(A,..), S(B,..), T(A,B,..) et U(A,B,..) sont des schémas de tables,
R.A désigne l‘ensemble des valeurs de A dans R, et U.(A,B) désigne l’ensemble des couples de
valeurs de (A,B) dans U.
1
2
4
5
Chapitre 4 • Concepts des bases de données
COMPTE (propriété 3). Étant donné que l’identifiant (NCLI, NFOURN) de COMPTE
est constitué de deux clés étrangères, on a aussi les propriétés suivantes :
• toute valeur de NCLI de COMPTE est une valeur de NCLI de CLIENT (propriété
1),
• toute valeur de NFOURN de COMPTE est une valeur de NFOURN de FOURNISSEUR (propriété 2).
Des propriétés 1, 2 et 3, on déduit alors que (figure 3.10) :
• toute valeur de NCLI de ACHAT est une valeur de NCLI de CLIENT (propriété
4),
• toute valeur de NFOURN de ACHAT est une valeur de NFOURN de FOURNISSEUR (propriété 5).
Cependant, les propriétés 4 et 5 ne peuvent jamais se substituer à la propriété 3,
comme le suggère le schéma de la figure 3.10.
Figure 3.10 - Une version incorrecte du schéma 3.9
Par exemple, un achat représenté par (C123,F445,14/04/2006,...) est valide,
non pas par l’existence d’un client n° C123 et d’un fournisseur n° F445, mais parce
qu’il existe un compte identifié par (C123,F445), auquel il est attaché 11 . Il s’agit
d’une erreur qui apparaît fréquemment chez les modélisateurs débutants.
11. Plus précisément, cette discussion se base sur deux propriétés importantes concernant les
règles d’inclusion, et donc les clés étrangères. La première (dite de décomposition) veut que si
U.(A,B) ⊆ T.(A,B), alors on a aussi que U.A ⊆ T.A et U.B ⊆ T.B; l’inverse n’est cependant pas
vraie. La seconde (dite de transitivité) stipule que si U.A ⊆ T.A et T.A ⊆ R.A, alors on a aussi
U.A ⊆ R.A. Etant donné les propriétés (T.A ⊆ R.A) et (T.B ⊆ S.B), la propriété (U.(A,B) ⊆
T.(A,B)) permet d’inférer (U.A ⊆ R.A) et (U.B ⊆ S.B). Mais, une fois encore, l’inverse n’est pas
vraie. Dans cette formulation, R(A,..), S(B,..), T(A,B,..) et U(A,B,..) sont des schémas de tables,
R.A désigne l‘ensemble des valeurs de A dans R, et U.(A,B) désigne l’ensemble des couples de
valeurs de (A,B) dans U.
1
2
4
5