Bonsoir sushis,
Vous vous êtes lancé dans les dépendances fonctionnelles, c’est très bien. Mettons en évidence la table CLIENT servant de référence :
je raisonne comme ceci:
{ ClientNo } -> { ClientNo } // je sais qu'il faut le mettre mais je ne comprend le sens de cette relation ClientNo dépend de ClientNo ? )
Il s’agit d’une DF triviale, elle est toujours vraie. On s’en sert essentiellement pour les définitions, démontrer les théorèmes ou au besoin qu’un ensemble d’attributs est clé candidate.
{ ClientNo } -> { Cname } // cname dépend de ClientNo
Donc vous traduisez de manière formelle la contrainte suivante :
Pour une valeur de l’attribut ClientNo, il y a une seule valeur de l’attribut Cname.
On a ici l’amorce de l’ensemble (très précieux) F des DF non triviales de la table CLIENT :
F = {{ClientNo} -> {Cname}}
J'ai lu le concept de clé candidate, moi j'ai toujours une approche SQL sinon j'ai plus de mal à comprendre.
ClientNo identifie de manière unique un client, c'est donc pour la clé primaire (et donc la clé candidate).
Si vous codez en SQL :
1
2
3
4
5
6
7
8
| CREATE TABLE CLIENT
(
ClientNo CHAR(4) NOT NULL
, Cname VARCHAR(64) NOT NULL
, PropertyNo VARCHAR(64) NOT NULL
, Padress VARCHAR(64) NOT NULL
, CONSTRAINT CLIENT_PK PRIMARY KEY (ClientNo)
) ; |
Et si vous effectuez un 1er INSERT (correspondant à la 1re ligne de votre exemple) :
INSERT INTO CLIENT (ClientNo, Cname, PropertyNo, Padress) VALUES ('CR76', 'John Kay', 'PG4', '6, rue de toto') ;
Alors tout se passe bien, mais si vous effectuez un INSERT pour la 2e ligne de votre exemple :
INSERT INTO CLIENT (ClientNo, Cname, PropertyNo, Padress) VALUES ('CR76', 'John Kay', 'PG16', '7, rue de titi') ;
Alors votre SGBD rejette l’INSERT. Exemple de message de rejet :
Violation de la contrainte PRIMARY KEY 'CLIENT_PK'. Impossible d'insérer une clé en double dans l'objet 'CLIENT'.
Donc {ClientNo} ne peut pas être clé primaire, ce n’en est possiblement qu’un sous-ensemble.
Si Cname était unique, ça en aurait fait la clé alternative c'est ça?
Oui, mais Cname n’est pas unique puisque la valeur 'John Kay' apparaît dans deux lignes...
{ PropertyNo } -> { PAdress }
PropertyNo identifie de manière unique une adresse
En énonçant cette DF, vous fournissez un élément important, permettant d’enrichir l’ensemble F des DF de la table CLIENT, qui devient :
F = {{ClientNo} -> {Cname}, {PropertyNo} -> {Padress}}
PropertyNo identifie de manière unique une adresse, c'est donc une clé primaire.
Ce n'est certainement pas la clé primaire de la table CLIENT, il y a seulement une DF {PropertyNo} -> {Padress}.
Quoi qu’il en soit, on est en mesure de trouver les clés candidates de la table CLIENT. Une observation importante les concerne ici :
Si un attribut n’est présent dans aucun dépendant (partie droite) d’une DF de l’ensemble F, alors il participe à une clé candidate.
Ainsi dans votre exemple, les attributs ClientNo et PropertyNo doivent participer à au moins une clé candidate de CLIENT.
Partant de là, la paire {ClientNo, PropertyNo} est-elle clé candidate ?
Si la définition donnée de la clé candidate vous gêne, on va faire référence à la remarque accompagnant sa définition, où K représente une clé candidate :
la DF : K -> {A} est vérifiée pour chaque attribut A de R.
Donc pour être clé candidate, la paire {ClientNo, PropertyNo} doit vérifier {ClientNo, PropertyNo} -> {A} pour chaque attribut A de CLIENT. Qu'en est-il ?
On montre que :
{ClientNo, PropertyNo} -> {ClientNo} : c'est en vertu du 1er axiome d’Armstrong (cf. le paragraphe traitant des
axiomes d’Armstrong).
{ClientNo, PropertyNo} -> {PropertyNo} : grâce là encore au 1er axiome d’Armstrong.
{ClientNo, PropertyNo} -> {Cname} : en effet, il suffit d’appliquer les axiomes d’Armstrong d’augmentation et de décomposition à la DF {ClientNo} -> {Cname} appartenant à F.
{ClientNo, PropertyNo} -> {Padress} : en effet, il suffit d’appliquer les axiomes d’Armstrong d’augmentation et de décomposition à la DF {PropertyNo} -> {Padress} appartenant à F.
La DF {ClientNo, PropertyNo} -> {A} est vérifiée pour chaque attribut A de CLIENT : la paire {ClientNo, PropertyNo} est donc clé candidate, (et clé primaire pour vous faire plaisir).
La table CLIENT est-elle en 2NF ?
Admettons que la paire {ClientNo, PropertyNo} soit la seule clé candidate. Pour que la table CLIENT soit en 2NF, il ne doit pas y avoir d’attribut n’appartenant pas à la clé {ClientNo, PropertyNo} qui soit dépendant d’un sous-ensemble strict de cette clé. Or l’attribut Cname n’appartient pas à la clé mais est dépendant du sous-ensemble strict {ClientNo} du fait de la DF {ClientNo} -> {Cname} : il s'ensuit que la table CLIENT n’est pas en 2NF.
Par application du théorème de Heath à la DF {ClientNo} -> {Cname}, vous pouvez décomposer la table CLIENT {ClientNo, Cname, PropertyNo, Padress} en deux tables :
CLI1 {ClientNo, Cname} et CLI2 {ClientNo, PropertyNo, Padress}.
Je vous laisse le soin de prouver que CLI1 est en 3NF (elle est même en 6NF !) et que CLI2 a pour clé {ClientNo, PropertyNo} et viole la 2NF.
A suivre...
Différence entre 2NF et 3NF
Répondre avec citation
Envoyé par sushis
Partager