UML 2 pour les bases de données
62
© Éditions Eyrolles
base de données ne pourra stocker que la date de la dernière visite pour chaque chantier, un
véhicule pouvant sortir à différentes dates et visiter différents chantiers.
●
Hypothèse 2 : un chantier peut être visité le même jour par différentes missions. Par ailleurs,
une mission ne pourra pas visiter le même jour plus d’une fois le même chantier.
●
Hypothèse 3 : un chantier peut être visité le même jour par différentes missions. En revanche,
une mission ne pourra pas visiter le même jour un autre chantier. En d’autres termes, la base
de données ne pourra stocker au plus qu’une visite par mission.
Entités faibles de Merise/2
Dans cet exemple, il est révélateur que l’association soit appelée Mission, elle est devenue
mentalement un objet (dont on peut parler, que l’on peut dénombrer... et qui est devenu un
sujet dans les phrases), toutefois identifiée par le couple (codev , datem). Pour Merise/2, il
est naturel que cette association soit représentée en tant qu’entité faible.
L’exemple 1-60 illustre le MCD de l’hypothèse (1). L’entité faible n’a pas d’identifiant mais
« hérite » des identifiants des entités concernées (Vehicule et Date). Les liens sont marqués
de (R) qui signifie le caractère relatif de l’identification.
Une autre modélisation de l’hypothèse (1) est illustrée à la figure 1-61, elle fait abstraction de
l’entité Date qui n’est pas nécessaire tout en conservant la propriété représentant le jour.
À titre de comparaison, l’exemple 1-62 décrit, avec le formalisme Merise/2 de Win’Design, le
cas général illustré à la figure 1-58. PowerAMC utilise une autre forme de notation.
Figure 1-59 Possibilités de cardinalités dans une association d’agrégation
Employe
codemp
nomemp
Jour
0,N
datem
Transporter
0,N
Vehicule
codev
nomv, np
total_km
Mission
0,N
0,N
B
A
km
Chantier
codecha
adrcha
Visiter
62
© Éditions Eyrolles
base de données ne pourra stocker que la date de la dernière visite pour chaque chantier, un
véhicule pouvant sortir à différentes dates et visiter différents chantiers.
●
Hypothèse 2 : un chantier peut être visité le même jour par différentes missions. Par ailleurs,
une mission ne pourra pas visiter le même jour plus d’une fois le même chantier.
●
Hypothèse 3 : un chantier peut être visité le même jour par différentes missions. En revanche,
une mission ne pourra pas visiter le même jour un autre chantier. En d’autres termes, la base
de données ne pourra stocker au plus qu’une visite par mission.
Entités faibles de Merise/2
Dans cet exemple, il est révélateur que l’association soit appelée Mission, elle est devenue
mentalement un objet (dont on peut parler, que l’on peut dénombrer... et qui est devenu un
sujet dans les phrases), toutefois identifiée par le couple (codev , datem). Pour Merise/2, il
est naturel que cette association soit représentée en tant qu’entité faible.
L’exemple 1-60 illustre le MCD de l’hypothèse (1). L’entité faible n’a pas d’identifiant mais
« hérite » des identifiants des entités concernées (Vehicule et Date). Les liens sont marqués
de (R) qui signifie le caractère relatif de l’identification.
Une autre modélisation de l’hypothèse (1) est illustrée à la figure 1-61, elle fait abstraction de
l’entité Date qui n’est pas nécessaire tout en conservant la propriété représentant le jour.
À titre de comparaison, l’exemple 1-62 décrit, avec le formalisme Merise/2 de Win’Design, le
cas général illustré à la figure 1-58. PowerAMC utilise une autre forme de notation.
Figure 1-59 Possibilités de cardinalités dans une association d’agrégation
Employe
codemp
nomemp
Jour
0,N
datem
Transporter
0,N
Vehicule
codev
nomv, np
total_km
Mission
0,N
0,N
B
A
km
Chantier
codecha
adrcha
Visiter