Discussion :

[simonwei]

bonsoir à tous ,

mon problème dans la pièce jointe

quelqu‘un pourrait m‘aider ,merci par avance Pièce jointe 344326

cordialement.

[escartefigue]

Bonjour,

Vous avez déjà tenté de faire faire vos devoirs par les autres ici :
https://www.developpez.net/forums/d1...n/#post9937623

Vous obtiendrez la même réponse partout !

Commencez par travailler votre sujet, proposez une amorce de réponse, énoncez les difficultés rencontrées et là sans doute vous obtiendrez de l'aide

[Darkzinus]

bonjour à tous

mon problème dans la pièce jointe

quelqu‘un pourrait m‘aider ,merci par avance

Comme le mentionne escartefigue personne ne t'aidera si tu n'exposes pas ton point de blocage. Nous sommes ici sur un forum d'entraide et non un forum de résolution d'exercice. A toi de murir le sujet et de nous donner ton modèle de données si tu veux que nous t'aidions.

[simonwei]

bonjour à tous ,

j‘ai fait un schéma e-r en fonction de mon sujet (la pièce jointe),

quelqu‘un pourrait m‘aider à corriger ma réponse？ je sais pas qu‘il est correct ou pas .

si image est grande vous pouvez la ouvrir dans le nouveau onglet

merci à vous.

le sujet:

[escartefigue]

Bonjour,

L'énoncé est sous forme littéraire, il laisse du coup la part belle aux interprétations diverses.
Vous devriez commencer par le traduire en règles de gestion numérotées, ça facilite les échanges et vous permettra de mettre en exergue les points équivoques de l'énoncé.
Voici un exemple
La première phrase peut donner
R001 : un adhérent s'inscrit à au moins une activité
Par contre rien n'indique si une activité peut être partagée par plusieurs adhérents, ou ne concerner aucun adhérent, c'est une faille dans l'énoncé
Selon le cas cela donne
R002 : une activité peut concerner zéro à plusieurs adhérents (cas le plus probable : pensez aux nouvelles activités qui n'ont pas encore trouvé preneur )
R002 : une activité peut concerner un ou plusieurs adhérents (ce que vous avez modélisé, mais en ce cas vous ne pouvez créer une activité que lorsqu'elle a au moins un adhérent...)
R002 : une activité concerne un et un seul adhérent (très peu probable )
Ici, on se doute assez facilement de la règle à appliquer, mais dans d'autres cas c'est autrement plus difficile de deviner la règle.
Dans tous les cas, une règle non formulée est une source d'erreurs engendrant des coûts inutiles.

Vous avez su éviter certains pièges, c'est une bonne chose.
Par exemple, l'énoncé indique "les animateurs sont identifiés par leur prénom et leur nom", mais vous avez eu la sagesse d'utiliser un identifiant technique, c'est bien : les identifiants fonctionnels doivent systématiquement être évités comme identifiants primaires, puisqu'ils sont par nature instable et peu propices aux performances

Par contre vous êtes tombés dans un autre piège, celui de la redondance : les personnes, les responsables, les adhérents et les animateurs ont l'essentiel de leurs attributs en commun.
Il convient donc d'utiliser l'héritage pour éviter les redondances.
Vous pouvez consulter cet article à ce sujet : https://merise.developpez.com/faq/?page=MCD

Votre relation "définir" à 4 pattes est censée modéliser quelle partie de l'énoncé ? 4 pattes dans une relation c'est le plus souvent au moins une de trop.
Quand vous aurez transformé l'énoncé en règles de gestion comme mentionné plus haut, je pense que ce genre d'écueil disparaitra tout seul

[simonwei]

bonjour,

la dernière paragraphe , responsable définit des activités , des animateurs etc .

ça veut dire quoi？

comment modéliser ？

merci

de plus ,j‘ai fait 3ème question en fonction mon schéma e-r pour modéliser le schéma relationnel .

pouvez vous m’aider à corriger？

merci à tous ;

[escartefigue]

bonjour,

la dernière paragraphe , responsable définit des activités , des animateurs etc .

ça veut dire quoi？

comment modéliser ？

merci

Le responsable est donc celui qui peut créer, modifier ou supprimer une activité et également choisir la ou les personnes qui animent ces activités

C'est un sous-type de l'entité-type personne
Là encore, il faut utiliser l'héritage
Ce qui n'est pas précisé dans l'énoncé, c'est si un responsable de l'association peut être également animateur et/ou adhérent
Et si un responsable peut être animateur, peut il se nommer lui même comme animateur ou faut il qu'un autre responsable le nomme ?

Encore des règles de gestion à documenter

[fsmrel]

J’interviens tardivement, mais je profite de quelques instants de libres pour parler de la modélisation.

Escartefigue vous a donné de bons conseils, notamment en ce qui concerne les règles de gestion des données.

Puisqu’il faut modéliser avec un minimum de rigueur, de mon côté, je vous recommande l’utilisation d’un AGL (atelier de génie logiciel) fait pour cela. Pour construire un MCD, vous pouvez utiliser un gratuit, par exemple DB-MAIN ou JMerise (toutefois je ne recommande pas ce dernier, car la production du MLD à partir du MCD est souvent déficiente, et il faut alors construire le MLD en partant de zéro, comme ici...)

Observations concernant le triplet d’entités-types ACTIVITE, CRENEAU, ADHERENT :

Vous avez défini une association DISPENSER entre ACTIVITE et CRENEAU, selon laquelle une activité peut être dispensée selon plus d’un créneau, et un créneau peut caractériser plus d’une activité : d’accord.

Vous avez défini une association CHOISIR entre ADHERENT et CRENEAU, selon laquelle un adhérent choisit au moins une créneau. C’est correct, mais on peut faire bien mieux, car selon votre MCD, un adhérent peut choisir n’importe quel créneau, donc un créneau n’ayant rien à voir avec une activité à laquelle l’adhérent est inscrit, d’où bug potentiel. Pour empêcher cela, il est préférable de transformer l’association DISPENSER en entité-type, appelons-la INSCRIPTION, et d’associer d’une part ADHERENT et INSCRIPTION, et DISPENSER et INSCRIPTION d’autre part.

Exemple de modélisation du triplet d’entités-types ACTIVITE, CRENEAU, ADHERENT.

(1) Avec PowerAMC, lequel n’est malheureusement pas gratuit :




Où l’on notera que les parenthèses encadrant les cardinalités 1,1 jouent un rôle précis : exprimer l’identification relative d’une entité-type par rapport à une autre. Ainsi, DISPENSER est identifiée relativement à ACTIVITE, et elle l’est aussi par rapport à CRENEAU, elle n’a pas besoin d’identifiant particulier.

D’où le MLD (schéma relationnel) produit par l’AGL, où l’on voit que les identifiants des entités-types ACTIVITE et CRENEAU ont donné lieu à la clé primaire {ActiviteId, CreneauId} de la variable relationnelle DISPENSER :



A cette occasion, je signale que le mode de représentation que vous utilisez pour votre schéma relationnel est incomplet, car les liens (clés étrangères) entre les variables relationnelles (tables au sens SQL pour faire court) sont absents : en conséquence, on n’a pas une construction, mais un tas de briques en vrac. On me dira qu’on peut jouer sur les noms des attributs, mais cette façon de procéder n’est pas déterministe, elle est inexploitable, les liens doivent être spécifiés. C’es ce qu’on voit au stade SQL, avec les clés étrangères (foreign keys). Génération proposée par PowerAMC (cible : 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
CREATE TABLE ACTIVITE 
(
   ActiviteId           NUMERIC(4) IDENTITY,
   ActiviteNom          VARCHAR(64) NOT NULL,
   CONSTRAINT ACTIVITE_PK PRIMARY KEY (ActiviteId)
) ;
 
CREATE TABLE CRENEAU 
(
   CreneauId            NUMERIC(4) IDENTITY,
   JourSemaine          INT NOT NULL,
   PlageHoraire         VARCHAR(5) NOT NULL,
   CONSTRAINT CRENEAU_PK PRIMARY KEY (CreneauId)
) ;
 
CREATE TABLE ADHERENT 
(
   AdherentId           NUMERIC(5) IDENTITY,
   AdherentNom          VARCHAR(64) NOT NULL,
   CONSTRAINT ADHERENT_PK PRIMARY KEY (AdherentId)
) ;
 
CREATE TABLE DISPENSER 
(
   ActiviteId           NUMERIC(4) NOT NULL,
   CreneauId            NUMERIC(4) NOT NULL,
   CONSTRAINT DISPENSER_PK PRIMARY KEY (ActiviteId, CreneauId),
   CONSTRAINT DISPENSER_ACTIVITE_FK FOREIGN KEY (ActiviteId)
      REFERENCES ACTIVITE ON DELETE CASCADE,
   CONSTRAINT DISPENSER_CRENEAU_FK FOREIGN KEY (CreneauId)
      REFERENCES CRENEAU ON DELETE CASCADE
) ;
 
CREATE TABLE INSCRIPTION 
(
   AdherentId           NUMERIC(5) NOT NULL,
   ActiviteId           NUMERIC(4) NOT NULL,
   CreneauId            NUMERIC(4) NOT NULL,
   CONSTRAINT INSCRIPTION_PK PRIMARY KEY (AdherentId, ActiviteId, CreneauId),
   CONSTRAINT INSCRIPTION_ADHERENT_FK FOREIGN KEY (AdherentId)
      REFERENCES ADHERENT  ON DELETE CASCADE,
   CONSTRAINT INSCRIPTION_DISPENSER_FK FOREIGN KEY (ActiviteId, CreneauId)
      REFERENCES DISPENSER  ON DELETE NO ACTION
) ;

(2) MCD Avec JMerise :




Mais, là où tout se passe bien avec PowerAMC, avec JMerise ça se gâte quand on tente la génération du MLD :




Echec donc de la génération, mais c’est JMerise qui est délinquant ! En effet, DISPENSER hérite des identifiants d’ACTIVITE et de CRENEAU, et si JMerise permet lui aussi l’identification relative (cardinalité 1,1 mise entre parenthèses, pour imiter PowerAMC), il procède comme si elle n’existait pas : erreur bloquante, copie à revoir !

En passant, JMerise utilise le concept de clé primaire au stade du MCD, alors qu’en Merise on utilise celui d’identifiant ; les clés primaires n’interviennent qu’au niveau relationnel (et SQL). En outre, JMerise utilise le terme entité alors le terme correct est entité-type (ou type d’entité). Une entité n’est qu’une instance d’entité-type, nuance...


(3) avec DB-MAIN :




Où l’on voit que l’identification relative utilise la technique définie dans les extensions de Merise : DISPENSER a pour identifiant le couple {DIS_ACT.ACTIVITE, DIS_CRE.CRENEAU}, où DIS_ACT nomme l’association DIS_ACT établie entre les entités-types ACTIVITE et DISPENSER, et DIS_CRE nomme l’association DIS_CRE établie entre les entités-types CRENEAU et DISPENSER.

MLD produit par DB-MAIN




Le code SQL est comparable à celui produit avec PowerAMC.

[escartefigue]

Bonjour François,

C'est avec plaisir que je vous retrouve sur ce fil, et comme à l'accoutumée, à l'occasion de bons conseils

Je suis surpris par votre schéma produit avec DB-Main, j'utilise également ce (bon) produit gratuit à la maison, mais la représentation est très différente, peut être utilisez vous une version plus récente ?
La mienne est la 9.3.0 et la représentation graphique de cette version me plait moins

[fsmrel]

Bonsoir capitaine,

Ici, j’ai J’utilisé la 10.0.3, mais dans mes billets j’utilisais la 9.2.b, et les représentations graphiques sont les mêmes. As-tu des exemples de graphiques moins plaisants ?

[escartefigue]

La réponse n° 10 du sujet qui suit en est un exemple :
https://www.developpez.net/forums/d1...s/#post9957404

Peut être certaines options permettent de modifier la forme et la couleur des symboles, j'avoue n'avoir pas trop fouillé dans la documentation

[fsmrel]

Salve capitaine,

DB-MAIN nous permet de définir la police par défaut qui nous convient, avant de commencer la création des schémas : nom et taille de la police, mais à ce stade, tout le reste est ignoré (mise en gras, en italique, couleur, etc.) DB-MAIN conserve cela dans ses tablettes, en sorte qu’on puisse utiliser cette police par défaut pour les nouveaux schémas et les nouveaux projets.

A cet effet, on passe par File > Configuration > View settings > Default font in graphical views

On peut aussi agir au niveau du schéma actuellement ouvert et lui affecter une police différente de la police par défaut.

Pour cela, on passe par

Edit > Change font

Cette fois-ci, à part colorier, on peut mettre italiques, etc. Toutefois les changements sont appliqués à tous les objets présents dans la fenêtre active (entités-types, etc.) On ne peut donc pas avoir des polices différentes pour les objets d’un même schéma. C’est du moins mon constat.

En ce qui concerne la couleur, on peut agir au niveau d’un élément :

— Nom d’une entité-type (ce qui entraîne du reste le coloriage des côtés du rectangle, même principe pour les associations, etc.)

— Nom d’un attribut (ou d’un ensemble de noms sélectionnés)

— Liste des noms des attributs d’un identifiant, d’une contrainte référentielle, etc.

Pour cela, une fois les éléments sélectionnés, on passe par

Edit > Change color

Dessin des associations

Comme je l’ai écrit ici (cf. (5) Choix de la représentation graphique des associations), en passant par

View > Graphical settings

alors on peut utiliser des ovales pour les associations. Incidemment, on voit qu’on peut notamment réduire/agrandir les objets (Zoom).

[escartefigue]

Super, merci pour ces éclaircissements

[rabDev]

Bonjour,

Tous les problèmes soulignés dans cette discussion concernant la version 0.4.0.1 de JMerise sont vrais mais ils sont tous corrigés dans la prochaine version (0.5).
je remercie fsmrel pour toutes ces critiques et remarques .

voici le MCD


les notations ont été revues et modifiées :



après vérification du MCD : (elle n'est plus bloquante et pas d'erreur)


le MLD est le suivant :




le script MySQL :

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
 
#------------------------------------------------------------
#        Script MySQL.
#------------------------------------------------------------
 
 
#------------------------------------------------------------
# Table: Adherent
#------------------------------------------------------------
 
CREATE TABLE Adherent(
        adherentId  Int  Auto_increment  NOT NULL ,
        adherentNom Varchar (50) NOT NULL ,
        PRIMARY KEY (adherentId )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: Inscription
#------------------------------------------------------------
 
CREATE TABLE Inscription(
        creneauId  Int NOT NULL ,
        activiteId Int NOT NULL ,
        adherentId Int NOT NULL ,
        PRIMARY KEY (creneauId ,activiteId ,adherentId )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: Activité
#------------------------------------------------------------
 
CREATE TABLE Activite(
        activiteId  Int  Auto_increment  NOT NULL ,
        activiteNom Varchar (50) NOT NULL ,
        PRIMARY KEY (activiteId )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: Dispenser
#------------------------------------------------------------
 
CREATE TABLE Dispenser(
        creneauId  Int NOT NULL ,
        activiteId Int NOT NULL ,
        PRIMARY KEY (creneauId ,activiteId )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: Creneau
#------------------------------------------------------------
 
CREATE TABLE Creneau(
        creneauId    Int  Auto_increment  NOT NULL ,
        jourSemaine  Int NOT NULL ,
        plageHoraire Char (5) NOT NULL ,
        PRIMARY KEY (creneauId )
)ENGINE=InnoDB;
 
 
ALTER TABLE Inscription
	 ADD CONSTRAINT FK_Inscription_adherentId
	 FOREIGN KEY (adherentId)
	 REFERENCES Adherent(adherentId);
 
ALTER TABLE Dispenser
	 ADD CONSTRAINT FK_Dispenser_creneauId
	 FOREIGN KEY (creneauId)
	 REFERENCES Creneau(creneauId);
 
ALTER TABLE Inscription
	 ADD CONSTRAINT FK_Inscription_creneauId
	 FOREIGN KEY (creneauId)
	 REFERENCES Dispenser(creneauId);
 
ALTER TABLE Dispenser
	 ADD CONSTRAINT FK_Dispenser_activiteId
	 FOREIGN KEY (activiteId)
	 REFERENCES Activite(activiteId);
 
ALTER TABLE Inscription
	 ADD CONSTRAINT FK_Inscription_activiteId
	 FOREIGN KEY (activiteId)
	 REFERENCES Dispenser(activiteId);

désolé pour ma réponse un peu tardive (beaucoup trop tardive )

Bonne journée à toutes et à tous