Discussion :

[sones]

Bonjour !

Je suis actuellement étudiant en informatique et nous avons récemment commencé à étudier les bases de données. Pour mettre en pratique mes connaissances, j'ai essayé de concevoir la base de données du club étudiant auquel j'appartiens.

Voici les règles de gestion identifiées :

(RG01) — Chaque personne peut être membre du club pendant une ou plusieurs saisons universitaires.
(RG02) — Un membre du club peut occuper le poste de président ou de vice-président pendant une ou plusieurs saisons.
(RG03) — Il ne peut y avoir qu'un seul président par saison.
(RG04) — Un membre du club peut rejoindre aucune, une seule ou plusieurs structures.
(RG05) — De même, un membre peut participer à aucun, un seul ou plusieurs projets.
(RG06) — Une structure peut avoir plusieurs responsables, tandis qu'un projet peut avoir plusieurs coordinateurs.
(RG07) — Un membre peut coordonner plusieurs projets, mais ne peut être responsable que d'une seule structure.
(RG08) — Pour être responsable d'une structure ou coordinateur d'un projet, il faut être membre de cette structure ou de ce projet.
(RG09) — Le président ou le vice-président ne peuvent pas être responsables d'une structure.

Et voici le schéma :



En réalité, la modélisation du club comporte d'autres aspects, mais j'ai choisi de m'arrêter ici pour bien comprendre avant de poursuivre. Je rencontre particulièrement des difficultés dans la modélisation de l'aspect des saisons universitaires, d'autant plus que j'utilise Looping et qu'aucune agrégation n'est possible.

Que pensez vous de cette modélisation ? Quelles sont les améliorations que vous proposeriez ? Auriez vous fait autrement ?

Merci infiniment et passez une excellente journée !

[fsmrel]

Bonsoir sones,


Les règles de gestion sont présentes, bravo !

Celle qui est embarrassante, bien qu’on ne peut plus légitime et naturelle, c’est la règle RG03 :

Il ne peut y avoir qu'un seul président par saison.

Pour s’en sortir, je pense qu’il n’y a pas 36 solutions, et bien que ce soit contre-intuitif, on va dire que c’est la saison qui fait référence au président...
 

 
Suite à cela, on va dire que les choses se passent plus ou moins naturellement :
 

 
Je n’ai pas regardé les problèmes que pourraient poser les vice-présidents.
Notez la contrainte d’exclusion entre les associations AP et RMS pour prendre en compte la règle de gestion RG09 en ce qui concerne la présidence.

En tout cas, bon courage !

[escartefigue]

Bonjour Sones et bienvenue dans ce forum

Je suppose qu'il existe d'autres rôles qui peuvent vous intéresser : trésorier, trésorier adjoint, entraîneur, secrétaire...
Si c'est le cas, vous pouvez modéliser une type d'entité [ROLE] et créer une association à date entre membre, rôle et date tout en conservant la modélisation particulière proposée par Fsmrel concernant le président, règle RG03 oblige .

À ce propos, vous avez non seulement communiqué les règles, mais en plus, vous leur avez donné un identifiant, bravo

[sones]

Merci pour vos réponses !

J'ai finalement réussi à comprendre le schéma. Je suppose que votre expérience vous guide dans votre conception, mais est-ce que vous suivez une méthode particulière ? Même si je connais les règles du modèle, je bloque souvent dans certaines situations. Auriez vous des conseils sur où trouver des méthodes ou des exemples de modélisation ?

[escartefigue]

Il existe de nombreux ouvrages de vulgarisation, parmi lesquels

- "Parlez-vous Merise" de Michel Diviné
- "Merise, 60 affaires classées" du même auteur

Ces deux ouvrages sont disponibles ici :
https://michel-divine.developpez.com/

Et également l'ouvrage proposé par Paprick, contributeur éminent du Forum modélisation et concepteur du remarquable "Looping".
Il me semble qu'on peut le commander directement sur la page d'accueil du téléchargement de Looping, mais je ne peux pas le vérifier sur ce poste.

Par ailleurs, vous pouvez consulter les fils de discussion de ce forum, ceux qui ont eu beaucoup de réponses vous guideront sur la démarche .

[fsmrel]

Bonsoir,

Il existe de nombreux ouvrages de vulgarisation, parmi lesquels

- "Parlez-vous Merise" de Michel Diviné
- "Merise, 60 affaires classées" du même auteur

Ces deux ouvrages sont disponibles ici :
https://michel-divine.developpez.com/

Et également l'ouvrage proposé par Paprick, contributeur éminent du Forum modélisation et concepteur du remarquable "Looping".
Il me semble qu'on peut le commander directement sur la page d'accueil du téléchargement de Looping, mais je ne peux pas le vérifier sur ce poste.

 
A ces ouvrages, on peut ajouter l’ouvrage très complet de Dominique Nanci (RIP) : Ingénierie des systèmes d'information - Merise deuxième génération.
 
Quelques remarques concernant cet ouvrage
 
Tant que l’auteur en reste au MCD, tout va bien, mais dès qu’il passe au MLD et à SQL, on doit prudemment rester sur ses gardes, notamment quant aux contraintes d’intégrité. Il a découvert les triggers Oracle et il en use...
 
Au paragraphe III-C-3-aa. Inclusion de participations d'une entité à plusieurs relations (INCLUSION) :
 
    - Fig. 13.38, de SOUSCRIRE faire une table référençant ABONNEMENT et PERSONNE. SOUSCRIRE est à référencer par PRET et qui donc ne fera plus référence à PERSONNE. En conséquence, le trigger est à mettre à la poubelle.
 
    - Fig. 13.39, même punition, plutôt que référencer PROFESSEUR et CLASSE, ENSEIGNER doit référencer QUALIFIE. Là encore, le trigger est à mettre à la poubelle.
 
Paragraphe III-D. Chapitre 14 Optimisation des Modèles de Données :
 
    L’auteur n’est pas DBA. Pour l'avoir été moi-même pendant 20 ans à partir de 1986 (DB2 OS/390) j’ai à la fois pouffé de rire et hurlé en lisant ce chapitre 14.