Database Reference
In-Depth Information
●
num_dossier
→
jour_depart
;
●
num_dossier
→
num_classe
;
●
num_dossier
→
num_voiture
;
●
num_dossier
→
num_siege
;
●
num_train
→
ville_depart
(si on considère qu'un numéro de train désigne le même
trajet régulier) ;
●
num_train
→
heure_depart
.
La première dépendance n'est pas optimale, car le nom d'un passager dépend davantage d'un
code client que des voyages qu'il a réalisés. Ainsi, il conviendrait d'introduire un identiiant
pour le passager et les dépendances induites seraient :
●
num_dossier
→
num_client
(si on considère que tous les passagers sont « ichés ») ;
●
num_client
→
nom_passager
.
Pour connaître la composition de chaque train (voiture 12 en tête, voiture 14 en position 2,
etc.), il convient de déterminer de quoi dépend la position d'une voiture : du trajet à un jour
donné. Ces deux attributs interviennent donc dans l'identiiant qui nécessite un troisième
composant (le numéro de la voiture ou la position) ain de pouvoir déterminer le quatrième
(la position ou le numéro de la voiture). Les deux dépendances suivantes sont donc équiva-
lentes :
●
num_train,
jour_depart
,
num_voiture
→
position
;
●
num_train
,
jour_depart
,
position
→
num_voiture
.
Vériication
Non-redondance
Un.attribut.ne.figure.qu'à.un.seul.endroit.du.diagramme :.soit.dans.une.classe,.soit.dans.une.
classe-association.
Si vous découvrez sur un diagramme des attributs qui se répètent dans différentes classes,
deux cas se présentent.
●
L'attribut identiie une classe à un endroit et il est répété en tant que clé étrangère.
●
L'attribut ne joue pas le rôle d'identiiant et il est redondant partout où il est dupliqué.
Le diagramme UML suivant trouvé sur le Web présente des redondances au niveau des iden-
tiiants. En réalité, ce diagramme décrit un modèle relationnel et non un modèle conceptuel.
D'un point de vue conceptuel, ce diagramme n'est pas correct, mais d'un point de vue rela-
tionnel, il ne pose pas de problème au premier abord.
