1. Trois classes peuvent être extraites de la description de l’application : Commande, Produit et Date. Les deux relations entre les classes définies dans l’énoncé sont les suivantes :

•   Une relation binaire intervient entre Produit et Commande. La commande  est composée de plusieurs produits. Mais, les durées de vie des objets ne sont pas liées. De ce fait, cette relation peut être modélisée par une agrégation. La commande est composée de plusieurs produits. En principe, il faut définir une multiplicité *.

• Une relation ternaire met en jeu les trois classes Commande, Date et Produit.

2. Pour définir la multiplicité à mettre à côté d’une classe dans une relation n-aire, calculez le nombre  d’objets de ladite classe consistant avec chaque ensemble de (n-1) objets des autres classes. L’union de ces nombres calculés constitue la cardinalité de la relation. Pour cette application,  calculez le nombre  d’objets de la classe Date consistant  avec chaque couple d’objets des classes Commande et Produit, le nombre  d’objets de la classe Commande consistant avec chaque couple des classes Produit et Date et le nombre d’objets de la classe Produit consistant avec chaque couple d’objets des classes Commande et Date. Par exemple, l’énoncé indique  qu’à chaque  couple d’objets des classes Commande et Produit sont associées exactement deux dates (figure 2.54).

Par ailleurs, même si l’énoncé ne le dit pas explicitement, vous savez qu’une commande n’a de sens que si elle porte sur au moins un produit  et qu’un produit  peut apparaître dans plusieurs commandes. La multiplicité de l’agrégation est, de ce fait, restreinte.

3. La contrainte de cardinalité est violée plusieurs fois par la base de données. Par exemple, il est indiqué qu’à chaque couple d’instances des classes Commande et Produit correspondent  exactement deux instances de la classe Date. Les couples (c2,p1) et (c2,p4) ne vérifient pas cette contrainte.