bonsoir à tous ,
mon problème dans la pièce jointe
quelqu‘un pourrait m‘aider ,merci par avance Pièce jointe 344326
cordialement.
bonsoir à tous ,
mon problème dans la pièce jointe
quelqu‘un pourrait m‘aider ,merci par avance Pièce jointe 344326
cordialement.
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
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:
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
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 ;
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
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.
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
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 ?
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
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).
Super, merci pour ces éclaircissements
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager