Discussion :

[aymanamkassou]

Bonjour ! J'ai été assez bloqué sur cette question d'examen, toute aide est appréciée. voici l'enoncé:
"On désire informatiser la gestion des courses de voitures. Chaque course est caractérisée par une ville de départ, une ville d'arrivée et une distance. Une même course peut avoir lieu dans plusieurs dates différentes constituant chacune un départ particulier. Plusieurs employées(médecins, mécaniciens, arbitres, ..) sont affectes a chaque départ. Un pilote automobile connu pas son nom, son adresse et son âge peut participer a un départ et peut n'appartenir a aucun club. Le club est caractérisé par son nom et sa date de création.
Chaque voiture possède un numéro, une marque et utilise une certaine quantité d'essence pour accomplir le trajet. Le prix d'une voiture dépend de son modèle et la quantité d'essence dépend de la manière avec laquelle un pilote d'automobile conduit sa voiture."
Mon ambiguïté réside dans le fait que l'exercice mentionne que la quantité de carburant brûlé dépend uniquement de la méthode de conduite, et de la voiture, à l'exclusion de la distance. Cela implique-t-il automatiquement qu'il y aurait une association 1 à 1 entre le pilote et la course ?
Voici le modèle conceptuel que j'ai réalisé. Dites-moi si cela a un sens, s'il vous plaît.

Voila le modele logique:
Course(numcourse, villedep, villearr, distance, #numemploy, #numpil)
Pilote(numpil, nompil, adressepil, datenaissance, maniere_conduite)
Employe(numemploye, fonction)
Club(numclub, nomclub, datecreation)
Voiture(numvoiture, marque, modele, prix)
Conduit(#numvoi, #numpil, qttessence)

[fsmrel]

Bonjour aymanamkassou,

Il y a pas mal de choses à dire, mais déjà :

Une course a un seul employé et un seul pilote, c’est maigre...

Un pilote participe à au plus une course, ce qui est encore bien peu...

Un pilote peut appartenir en même temps à plusieurs clubs. Normal ?

En passant, utilisez l’excellent Looping, très beau cadeau de Paprick (forum Looping, https://www.developpez.net/forums/f2...utils/looping/)

Bon courage !

[aymanamkassou]

D'abord Merci beaucoup pour votre temps.

Une course a un seul employé et un seul pilote, c’est maigre...

Je fixe la cardinalité à 1 entre la course et le pilote pour éviter une association ternaire entre les trois (course,pilote,voiture). Puisque la quantité de carburant brûlé dépend de la méthode de conduite, de la voiture et de la distance. Mais en y réfléchissant, ça n'a pas vraiment de sens d'avoir une course avec une seule voiture haha.

Un pilote participe à au plus une course, ce qui est encore bien peu...

J'ai un problème avec la cardinalité et les dimensions temporelles. Par exemple, un pilote peut participer à plusieurs courses mais pas en même temps ; comment cela se traduit-il en termes de cardinalité ? Lorsque je fixe la cardinalité à n pour les pilotes et les clubs, vous mentionnez qu'ils ne peuvent pas être dans plusieurs clubs en même temps. Excusez ma confusion.

J'ai recréé le modèle en looping, faites-moi savoir si c'est mieux.


une dernière chose, l'association de particpation est-elle nécessaire ici après avoir ajouté l'association ternaire ?

[fsmrel]

Aymanamkassou, vous allez découvrir le monde des CIF (contraintes d’intégrité fonctionnes) 😉
Prenons le cas de la contrainte voulant qu’à une date un pilote ne puisse participer qu’à une seule course.

Dans le cadre de la théorie relationnelle on écrit :

{PILOTE, DATE} -> {COURSE}

Au stade MCD, pour cela on crée une entité-type DATE que l’on déclare fictive (ce qui pour marquer l’œil fait que son nom est mis entre parenthèses par Looping). Il est surtout important de noter que cette entité-type ne fera en aucune façon l’objet d’une table (MLD et SQL).

Dans un deuxième temps, on choisit l’objet CIF et l’on crée un lien entre la CIF et l’association PARTICIPER. Ceci fait, on crée un lien entre la CIF et l’entité-type COURSE, puis un lien avec l’entité-type PILOTE. COURSE est alors la cible de la CIF.

Au résultat : A une date, un pilote ne peut participer qu’à une course.

On marche sur des oeufs, avançons doucement. En attendant, merci Paprick !

[fsmrel]

Maintenant il s’agit de modéliser les contraintes :

(C1) A la date T, le pilote P conduit seulement la voiture V ;
(C2) A la date T, le pilote P participe seulement à la course C ;
(C3) A la date T, la voiture V est conduite seulement par le pilote P ;
(C4) A la date T, la voiture V participe seulement à la course C ;

Dans le contexte de la théorie relationnelle, ces contraintes s’expriment ainsi :

{P, T} -> {V, C}
{V, T} -> {P, C}

Avec le MCD merisien, l’affaire se corse. Là encore, on utilise des CIF, mais ça devient de la gymnastique.

Il va falloir :

Une 1re CIF pour exprimer la contrainte (C1) : {P, T} -> {V}
Une 2e CIF pour exprimer la contrainte (C2) : {P, T} -> {C}
Une 3e CIF pour exprimer la contrainte (C3) : {V, T} -> {P}
Pas besoin de 4e CIF pour exprimer la contrainte (C4) : {V, T} -> {C}
car Looping manifestement l’infère.

Peut-être peut-on simplifier le MCD dans la mesure où Looping propose des CIF multi-cibles, mais je n’ai pas réussi à mettre en oeuvre cette possibilité. Le MCD ci-dessous peut donner l’envie de partir en courant, mais en tout cas le code SQL produit est correct.

Code SQL (notez la contrainte UNIQUE(v, t) de la table R) traduisant une clé alternative :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
CREATE TABLE P
(
   p INT,
   n VARCHAR(50) NOT NULL,
   PRIMARY KEY(p)
);
 
CREATE TABLE V
(
   v INT,
   n VARCHAR(50) NOT NULL,
   PRIMARY KEY(v)
);
 
CREATE TABLE C
(
   c INT,
   n VARCHAR(50) NOT NULL,
   PRIMARY KEY(c)
);
 
CREATE TABLE R
(
   p INT,
   t INT,
   v INT NOT NULL,
   c INT NOT NULL,
   PRIMARY KEY(p, t),
   UNIQUE(v, t),
   FOREIGN KEY(p) REFERENCES P(p),
   FOREIGN KEY(v) REFERENCES V(v),
   FOREIGN KEY(c) REFERENCES C(c)
);

Affaire à suivre...

[aymanamkassou]

Merci beaucoup ! Cela a beaucoup de sens, mais malheureusement, cela ne fait pas partie de mon programme d'études et j'ai peur de ne pas pouvoir l'utiliser le jour de l'examen, mais de toute façon, c'est très logique et cela a beaucoup plus de sens. Je vous remercie encore une fois.

[fsmrel]

Bon, le MCD se lit plus facilement si on le débarrasse de ses CIF. Il suffit de se souvenir qu’avant la générations du code SQL il faudra de les remettre en œuvre, maintenant qu’on sait comment elles fonctionnent.




Simplement j’ai oublié de traiter de l’essence.

Si la règle est la suivante :

A la date t, lors de la course c, la voiture v a consommé la quantité q d’essence ;
il suffit donc de faire porter cette quantité par l’association R :



La mise en oeuvre de la règle reste valable si au lieu de quantité consommée on parle de quantité allouée.

Code SQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE R(
   p INT,
   t INT,
   q INT NOT NULL,
   v INT NOT NULL,
   c INT NOT NULL,
   PRIMARY KEY(p, t),
   UNIQUE(v, t),
   FOREIGN KEY(p) REFERENCES P(p),
   FOREIGN KEY(v) REFERENCES V(v),
   FOREIGN KEY(c) REFERENCES C(c)
);

Et bonne route !

[fsmrel]

En cherchant ce que j’avais pondu en ce qui concerne les courses de chevaux, je suis tombé par hasard sur un problème équivalent au vôtre, où l’on s’appuie non pas sur un MCD mais d’un diagramme UML.
Ça se passait en 2014.

Voyez ici : https://www.developpez.net/forums/d1...navigationnel/