Discussion :

[walid kh]

Salut à tous,
Voilà j'ai 2 exercices à faire avec diagramme de classe ; je ne sais pas est ce que les réponses sont exactes ou non
Merci de m'aider
Diag CLASSE.pdf

[escartefigue]

Bonjour Walid

Quelques remarques concernant le 1^er exercice :

Vous avez créé des sous-types CLIENT et PASSAGER, pourquoi pas, mais rien dans l'énoncé ne le justifie :

• pour reconnaitre les clients, il suffit de vérifier l'existence d'une occurrence d'association (effectuer) pour la personne.
• pour reconnaitre les passagers, il suffit de vérifier l'existence d'une occurrence d'association (interesser) pour la personne.

Par contre, vous n'avez pas modélisé les notions de confirmations et d'annulations de réservations.
Je les ai donc ajoutées dans ma proposition de modèle ci-dessous, en ajoutant aussi des contraintes d'inclusion pour vérifier que seule la personne qui a effectué une réservation peut l'annuler ou la confirmer.

Par ailleurs, départ, arrivée et escale ont les mêmes attributs, on peut donc considérer qu'il s'agit du même objet sous réserve d'accepter le marqueur "nul" pour pour la date/heure d'arrivée du départ et la date/heure de départ de l'arrivée.
L'escale peut être considérée comme une entité-type faible du vol (pas de vol, pas d'escale, si le vol disparait, ses escales aussi), c'est pourquoi j'ai identifié l'escale relativement au vol.

Ce qui donne, selon le formalisme Merise :



Et selon le formalisme UML :




EDIT : comme il s'agit de vols potentiellement internationaux, il faudra veiller à choisir des types de dates avec timezone

[walid kh]

Merci beaucoup et pour le 2ème exercice la méthode caculermoyenne est-elle de type void ou float ?

[escartefigue]

Bonjour,

Pour le 2^e exercice.

Dans votre schéma, la salle est sans lien avec le collège, ça ne va pas.

Par ailleurs, quand la règle de gestion dit

Une matière peut être enseignée par plusieurs enseignants mais a toujours lieu dans la même salle de cours

Il faut comprendre

Une matière peut être enseignée par plusieurs enseignants mais a toujours lieu dans la même salle de cours pour un établissement

Sans quoi, une même matière ne serait enseignée que dans un seul établissement

Ensuite, le département comme la salle sont des une entité-type faibles du collège, sans collège, plus de salle ni de département
D'où l'utilisation de l'identification relative dans les deux cas.

Et aussi, il faut vérifier par une contrainte que l'enseignant qui est responsable d'un département est bien rattaché à ce département.

Enfin, bien que l'énoncé ne le mentionne pas, j'ai ajouté une entité-type fictive (qui ne deviendra donc pas une table) CA_calendrier, dont le but est de permettre de changer l'affectation d'une personne (étudiant et enseignant) à un établissement (au travers d'un département si c'est un enseignant)
Comme une personne ne peut être affectée à un instant "t" qu'à un seul collège (étudiant) ou un seul département (enseignant), une flêche vers l'entité-type concernée matérialise cette contrainte.

Je profite de cet exercice pour créer une entité-type [DOMAINE] qui sera associée à l'adresse courriel de la personne.
Ça permet de n'avoir à créer qu'une seule fois un domaine (par exemple google.com) pour tous les utilisateurs qui s'y rattachent.

Ce qui donne le MCD suivant selon le formalisme Merise :



Et selon le formalisme UML :



Et voici un exemple de script DDL ici décliné selon la syntaxe SQL server :

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
CREATE TABLE CLG_college(
   COL_ident INT IDENTITY,
   COL_nom VARCHAR(50) NOT NULL,
   COL_site VARCHAR(2000),
   PRIMARY KEY(COL_ident)
);
 
CREATE TABLE DOM_domaine(
   DOM_ident INT IDENTITY,
   DOM_nom VARCHAR(63) NOT NULL,
   DOM_extensioin VARCHAR(190) NOT NULL,
   PRIMARY KEY(DOM_ident)
);
 
CREATE TABLE MAT_matiere(
   MAT_ident INT IDENTITY,
   MAT_code CHAR(4) NOT NULL,
   MAT_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(MAT_ident),
   UNIQUE(MAT_code)
);
 
CREATE TABLE SAL_salle(
   COL_ident INT,
   SAL_seq SMALLINT,
   PRIMARY KEY(COL_ident, SAL_seq),
   FOREIGN KEY(COL_ident) REFERENCES CLG_college(COL_ident)
);
 
CREATE TABLE PER_personne(
   PER_ident INT IDENTITY,
   PER_nom VARCHAR(50) NOT NULL,
   PER_prenom VARCHAR(50) NOT NULL,
   PER_courriel VARCHAR(64) NOT NULL,
   DOM_ident INT NOT NULL,
   PRIMARY KEY(PER_ident),
   FOREIGN KEY(DOM_ident) REFERENCES DOM_domaine(DOM_ident)
);
 
CREATE TABLE ENS_enseignant(
   PER_ident INT,
   ENS_indice TINYINT NOT NULL,
   MAT_ident INT NOT NULL,
   PRIMARY KEY(PER_ident),
   FOREIGN KEY(PER_ident) REFERENCES PER_personne(PER_ident),
   FOREIGN KEY(MAT_ident) REFERENCES MAT_matiere(MAT_ident)
);
 
CREATE TABLE ETU_etudiant(
   PER_ident INT,
   PRIMARY KEY(PER_ident),
   FOREIGN KEY(PER_ident) REFERENCES PER_personne(PER_ident)
);
 
CREATE TABLE DPT_departement(
   COL_ident INT,
   DPT_seq SMALLINT,
   DPT_code CHAR(6) NOT NULL,
   DPT_lib VARCHAR(50) NOT NULL,
   PER_ident INT NOT NULL,
   PRIMARY KEY(COL_ident, DPT_seq),
   FOREIGN KEY(COL_ident) REFERENCES CLG_college(COL_ident),
   FOREIGN KEY(PER_ident) REFERENCES ENS_enseignant(PER_ident)
);
 
CREATE TABLE RAT_rattacher(
   PER_ident INT,
   CA_date DATE,
   COL_ident INT NOT NULL,
   DPT_seq SMALLINT NOT NULL,
   PRIMARY KEY(PER_ident, CA_date),
   FOREIGN KEY(PER_ident) REFERENCES ENS_enseignant(PER_ident),
   FOREIGN KEY(COL_ident, DPT_seq) REFERENCES DPT_departement(COL_ident, DPT_seq)
);
 
CREATE TABLE SIT_situer(
   COL_ident INT,
   MAT_ident INT,
   COL_ident_1 INT NOT NULL,
   SAL_seq SMALLINT NOT NULL,
   PRIMARY KEY(COL_ident, MAT_ident),
   FOREIGN KEY(COL_ident) REFERENCES CLG_college(COL_ident),
   FOREIGN KEY(MAT_ident) REFERENCES MAT_matiere(MAT_ident),
   FOREIGN KEY(COL_ident_1, SAL_seq) REFERENCES SAL_salle(COL_ident, SAL_seq)
);
 
CREATE TABLE INS_inscrire(
   PER_ident INT,
   CA_date DATE,
   INS_dtfin DATE NOT NULL,
   COL_ident INT NOT NULL,
   PRIMARY KEY(PER_ident, CA_date),
   FOREIGN KEY(PER_ident) REFERENCES ETU_etudiant(PER_ident),
   FOREIGN KEY(COL_ident) REFERENCES CLG_college(COL_ident)
);

EDIT je me rends compte d'une petite coquille : j'ai préfixé l'entité type [COLLEGE] avec le trigramme CLG, mais c'est le trigramme COL que j'ai utilisé pour ses attributs, pas très cohérent , à harmoniser bien entendu si vous retenez cette méthode de nommage

[walid kh]

Merci infiniment
Pour les méthodes c'est bon rien à modifier ?

[escartefigue]

Le type FLOAT sert aux grands nombres, il n'a aucun intérêt ici, d'autant moins qu'il peut générer à la marge des erreurs d'arrondi.
Pour des notes scolaires, on utilisera un type DECIMAL (n,n) ou NUMERIC dans certains SGBD.

[escartefigue]

En relisant ce sujet, je trouve deux coquilles concernant les vols et réservations : les annulations et confirmations de réservations étant facultatives, il faut corriger la cardinalité minimale de 1 en 0 de RES_reservation vers les associations (annuler) et (confirmer)

Comme quoi, on voit rarement tout en première lecture !