Bonsoir,
 
Je me lance depuis peu dans l'univers du développement afin de concevoir une application mobile pour mon travail.
J'ai suivi quelque formation en ligne et lu quelques ouvrages, mais j'éprouve des difficultés à réaliser le MCD qui correspond à mes besoins.
 
Fonctionnalité de l'application :
Le but est de permettre à un enseignant de pouvoir créer plusieurs type d'épreuve/événement dans lequel il pourra inscrire une ou plusieurs classe.
Chaque classe pourra participer aux différents événements plusieurs fois au cours de l'année. Un événement reste cependant unique avec une durée limité (l'enseignant ouvrira et fermera l'événement une fois terminé).
 
Epreuve 1 : Biathlon
Les élève de la classe (ou des classes) sont répartis en groupe de travail.
Lors d'une séance, chaque élève réalisera sa séance durant laquelle il réalisera certaines performance qui seront relevées au sein de l'application.
La séance donnera lieu à un bilan ou seront calculés les points marqué par l'élève et son % de réussite sur cette séance.
Chaque bilan de séance de chaque élève du groupe détermineront le bilan de séance du groupe auquel vient s'ajouter des défi à réaliser en groupe qui apportent des points supplémentaires au groupe entier.
Afin de voir une progression, séance, après séance, nous afficherons au sein d'un bilan de progression les résultats des élève du groupe, séance après séance (sur certains point clés) pour établir l'axe de travail.
 
Epreuve 2 : Tournois raquette
Les élèves sont soit placé dans un tournois individuel, soit en binôme. Durant l'événement, les binômes (ou élève) lanceront des défis à n'import quel autre binôme (ou élève). Au lancement du défi, en fonction du nombre de point d'écart entre les deux binômes (au classement général), le groupe le moins bien placé pourra (si ils sont activés dans les réglages de l'événement) mettre en place 0, 1 ou 2 handicaps. A la fin du match, le résultat est inscrit dans l'application et cela met à jour le classement, toujours en fonction de l'écart au point existant au début du défi.
 
Epreuve 3 : Gestion d'équipe
Au début de chaque séance, il est nécessaire d'indiquer les élèves absent ou ne pouvant pratiquer.
Les élèves aptes sont répartis, soit manuellement, soit automatiquement en fonction du classement (ou de l'ordre alphabétique au lancement de l'événement) et des impératif de chaque cours (temps de pratique, nombre de terrain disponible, organisation choisie par l'enseignant, ...). Une fois les équipes constituées, elles sont inscrites dans leur tournois du jour, dans lequel elles réaliseront autant de match que demandé au début de la séance par l'enseignant. Lors de chaque match, les résultats seront récoltés afin d'attribuer des points en fonction de (victoire - nul - défaite) à chaque équipe. Ces points remportés par une équipe seront attribués individuellement à chaque élève qui appartient à l'équipe. C'est point viendront alors modifier le classement général individuel de l'épreuve.
 
Concernant le MCD, j'ai déjà réalisé ceci :  

 
Comme j'ai pu le voir durant mes différents cours et lectures, je n'ai pas fait apparaître au sein des partie que j'ai mis en place les entités ou de "calculs" seront nécessaire comme mes bilans de séance en biathlon par exemple.
 
Sur ce qui est réalisé, avez-vous des remarques à formuler pour tenter de l'améliorer ?
 
Sur la partie Gestion d'équipe, j'ai tenté une réflexion, mais je ne suis absolument pas sur de moi.
 
Concernant la dernière épreuve, je ne vois absolument pas comment organiser la réflexion afin de pouvoir récupérer la liste des participant afin de pouvoir signaler les présents, pour ensuite créer les équipes.
 
Merci de votre lecture et de vos futurs retour.
 
Bonne soirée

Bonjour Wark07,

l'analyse c'est compliqué.
Félicitation en tout cas  

J'ai bien compris "le domaine" .

Revois le concept 'entité'.
Car ton MCD , tu peux l'améliorer encore.

Il y a beaucoup trop de "table" et de "cardinalité".

Le MCD c'est avant la création de la base de données.
C'est une représentation, c'est le 'plan relationnel' de ta structure de données. ( un dessin ).

Ce MCD que tu a montré, me fait pensé + à une GUI. Une Interface Homme Machine, donc ton logiciel avec les cases à remplir et à cocher...

Le problème que ça posera, c'est que avec ton 'design' tu va péter un cable ( c'est  pas un gros mot    )   quand tu écrira tes requetes SQL.
Dit autrement, tu va te retrouver avec des requetes SQL en pagailles et en surnombres , avec des 'JOIN' et des 'WHERE' aboslument infectes, et inabordables.
10h travaillées contre 1h utile... ( gaffe , gaffe , gaffe !!! ).

Mais de lire ton MCD , j'ai bien compris le besoin.
Et ça c'est  déjà signe que tu a compris ce que demandais ton projet. Et moi aussi lors de la lecture.

Je sais pas ce que tu sais pour faire l'analyse,
mais tu a 'migré' bien trop souvent des données,
et tu a 'inventé' des relations qui étaient facultatives. ( l'un provoquant l'autre ).

Pour l'image , tu a écrit ton MCD en 'effet boule de neige / masse critique'.

tu dois reprendre ton dictionnaire des données.
c'est "la liste des données de ta BDD".
Et
- reconsidérer tes entités : remettre en bonne place, réorganiser + simplement tes données.

Une chose à faire lors d'un raffinage :
- monter en abstraction la sémantique, si un gain est évident.

comme par exemple :
boulanger / ingénieur / technicien :: peut devenir 'METIER'
ou bien ,
client / eleve / prof :: devient l'entité 'PERSONNE' ( avec une colonne : statut.. )

Et félicitations pour cette analyse claire  et synthètique !
beau travail ! ( car tout a été compris dès lecture ... preuve d'application au travail   )

================================
Pour la notion 'ne pas mettre dans la base de données les données calculées',
c'est une embûche,
autant 'conserver le détail' est important ( si c'est le travail demandé ),
et il ne faut pas négliger que si le besoin exiges une table 'bilan' ... les données calculées seront dans ta base de données, par besoin du cahier des charges.

Un exemple :
les pays du monde et la démographie :
Les habitants de chaque pays ne sont pas comptés un par un ( pour la structure de données ).. et pour chaque année, ou chaque comptage.

=================================

pour revenir à ton projet :
BIathlon / séance / tir ...
en considérant le peu de données nécessaires,
tu pouvais tout mettre dans la même table par exemple : 'EPREUVE' ,

exemple "rapide"
car une table de 12 colonnes,   ou 3 tables de 4 colonnes ... de données.
c'est des clé étrangéres et primaires en moins ...
Une clé qui est réécrites dans plusieurs tables, c'est finalement des 'doublons de données'.
Alors que les données étaient -distinctes, facilement -isolées, chacunes à leurs places. sans confusion.

On finit par avoir 1 table avec 9 colonnes ( sans redondances inutiles ).  

======================================
Quand tu écrit ton MCD :
reperes les élements IMPORTANT :
( c'est souvent PERSONNE / ELEVE / CLIENT .. dès qu'il y a des noms et des prénoms ... )

compte le nombre de tes entitès ...
et comme sur une pendule, minuit / 3 heures / 6 heures / 9 heures ...
tu disposes de nombreux choix pour placer tes entités sur ton MCD.

Tu peux partir par le centre de ta 'feuille'
ou par un coté ... 'haut bas gauche droit'

Regarde ton MCD ,  t'aurai pas commencé par PE_Personne ?
t'a écrasé les sous-types immédiatement .... ( c'est ça  ? ) dans le MCD.

Là c'est un tuto : organiser un schéma , composer un diagramme ... etc ... comme 'science' ... ( en vidéo Youtu ?? )  

Et si tu le fait avec PE_Personne à gauche de ta feuille ?
et que tu écrit ton MCD , et 'branches' et 'niveaux / sous-branches' ? de la gauche vers la droite ?
c'est mieux ou pas ?

Dans le choix des VERBEs d'actions pour le MCD.

Restes au plus proche des notions ensemblistes.
COMPOSER / APPARTENIR / ... fait partie de ...

Bien que des verbes qui décrivent une action, un geste soient pertinents à un moment de la conception.

Cela amènes une 'surcharge' dans l'analyse, et ça crées des erreurs.
Pourquoi ? car c'est 'trés riche' ( en occurences , en nombres , en sémantique ), bien que ça amènes du sens.

Une réduction du vocabulaire pour un MCD , est nécessaire.
C'est chercher le strabisme , la synthèse.
Pour les élèments communs ( des entités, et des types de données aussi ).

cf : appartenir / participer / grouper / asso 8b / concourir

c'est vers des 'meta' , des 'génériques' que tu va simplifier le MCD.
des 5 mots cités, il y en a surement 2 à retenir, 3 à supprimer.
Pourquoi en garder au moins 2 : pour que ça restes lisible , compréhensible au niveau MCD ... sinon une suite de zéro , ou 1 suffirait.

Bien que ces relations, comme elles ne sont pas 'porteuses de données',
ne seront pas 'écrites' , ni existantes , au niveau applicatif. ( Bdd et Code ).

Bonjour Djinto,
 
Merci pour votre réponse très détaillée.
 
Je vais avoir besoin d'un peu de temps pour assimiler et intégrer tout cela. Car a vrai dire, le fait de synthétiser, va à l'encontre de ce j'ai pu éventuellement lire sur différent forum. Je sais bien que tout le monde ne travail pas de la même façon (et fort heureusement d'ailleurs).
 
Je comprend en effet, le fait de synthétiser l'ensemble au sein d'une table unique, car cela diminue les recherches et donc la "durée" de la requête ultérieurement si je ne me trompe pas ?
 
Si je comprend bien je peux regrouper Biathlon / Seance / tir sous la forme de :  
== Epreuve biathlon ==
seance
date_seance
tours
tir 1
tir 2
tir 3
tir 4
penalite
-----
avec une association ELEVE -0,n- réaliser -1,1(r)- Epreuve Biathlon
 
???
 
Je vais essayer de me pencher de nouveau sur mon dictionnaire de donnée en essayant de synthétiser et de regrouper un maximum ce qui peu l'être. J'ai honnêtement du mal à voir ce que cela peut donner. Je vais essayer de faire au mieux.
 
Encore merci pour ce retour instructif et encourageant !

Oui, des deux tables séances et tirs : tu peux en faire une seule.

Mais encore + loin ,
une table "epreuve" permettrait de gérer à la fois les "biathlon" et les "raquettes"

Visuellement :
tu mets les tables concernées en colonne l'une à coté de l'autre.

Il y a toujours des élèments communs,
une table aura + de colonnes que l'autres.

Mais en tant que 'espace disque occupé' une cellulle vide, c'est 0 octets. ( c'est pas un gachis de disque dur , c'est vraiment une zéro quantité ).

BIATHLON   ||  RAQUETTES
ChampB 1     || Champ_R 1
ChampB 2     || Champ_R 2
ChampB 3     || Champ_R 3

tu peux concilier les 2 activités sportives :
SPORT
Champ_B_R 1  
Champ_B_R 2
Champ_B_R 3
Champ_B 4
Champ_R 4
Champ_B 5

Il y a des données propices à beaucoup de convergence :
date / libellé=nom=prénom=text_court /

C'est par des contraintes 'mathèmatiques'
- si et seulement si
- inclus
- exclus

Car un champ vide, ou à double emplois ... ce n'est pas une erreur.
C'est de l'optimisation.

exemple pour ton MCD :
Le sport badminton , et l'activité tennis , ainsi que l'activité biathlon et aussi tennis de table, et pelote basque , ont un libellé enregistré dans la base de données.
Le libellé de l'activité est indispensable à chaque sport enregistré.

J'ajoute dans ma table 'SPORT' une colonne "libellé" ( le nom du sport ),
SPORT
- IDentifiant
libellé ( caractère commun )
date événement ( caractère commun )
organisateur ( c commun )
lieux ( c commun )
résultat ( c commun tant que adapté... )

c'est 4 colonnes communes à tout les sports.
Pourquoi spécialiser ces 4 données, dans des tables, des entités dédièes ?
alors que leurs bonnes places, afin d'éviter toutes redondances, et des réécritures inutiles d'une informations
seraient dans d'autres tables.

Une entité est constituée du minimum nécessaire.

Un MCD est un ensemble d'entités en relation.

Si une entité 'MERE' est distincte , elle intégres toutes les données communes aux autres, et ces données ne sont pas nécessaires dans une entité 'FILLE'.
C'est "établir une hierarchie" dans la répartition des données.

l'entité 'supérieure' portes les données communes aux autres entités 'filles' dépendantes de l'entité 'supérieure'.
Les entêtés 'filles' ne sont pas porteuses de ces données.

===================================
ICI :
Ton MCD , il s'est dévellopé en 2 axes au moment ou tu a laissé 'personne' , pour donner des relations aux types spécialisés 'eleves / enseignant'
c'est là que le design s'est emmelé les pinceaux.
===========================
Reprends les cardinalités, et les relations depuis 'PERSONNE'. ======== FIN ICI =======================
Une entité peut établir un trés grand nombre de relations vers les autres entités.

car depuis eleves, et enseignant ... il y a que le lien de dépendance vers personne qui existe.

Tu verra qu'au niveau logique , c'est un identifiant de 'personne' qui va être distribué.
Une bonne raison de le faire ?
tu pourrai te retrouver avec un identifiant 'eleve' qui serait égal à un identifiant 'enseignant' dans une table de tournoi...
ce sera délicat pour savoir si l'eleve 137 , ou l'enseignant 137  a joué à l'activité "raquette" ou "biathlon".

J'en fais pas le pari.

Dans un cas, tu démarrera tes requetes depuis la table 'eleve' ou 'enseignant',
dans l'autre cas, tu pourra faire SANS ce paramètre 'personne'.
Alors que c'est l'entité 'personne' qui posséde l'identifiant.
l'identifiant de 'personne' sera existant dans les groupes 'participants' , etc ....

( wahhhhh !!! cette sieste là        )

Je vois, je vais essayer de représenter cela.
Difficile pour moi pour l'instant car j'ai "appris" à faire en étant le plus explicite possible et à tout détailler.
J'ai donc du mal à percevoir réellement ce que je peux regrouper et ce que je dois distinguer pour l'application. Car pour l'instant (pour rester sur l'exemple de la séance de biathlon), j'ai toujours l'impression de devoir la distinguer car elle est relative à l'élève qui la réalise.
Et en regroupant tout ensemble, je ne vois pas comment récupérer les information "séance" pour les placer relativement aux élèves qui les réalise.

un corrigé en couleur
https://nsm09.casimages.com/img/202 [...] 442781.png

Les spécialisations XT , c'est vraiment selon le système utilisé.
Pour profiter de cette spécialisation XT , c'est par exemple SQL server , Oracle , Access un peu aussi , qui utilisent ces 'types d'entités'.
MySql n'a pas besoin d'autant de détail.

C'est vraiment en 'exploitation' que cette contrainte s'applique, c'est des verrous ... une erreur si une requete 'insert ...' ne va pas vers la bonne table. ( access, Oracle , Sql Server ).

{ j'espere ne pas t'emmener trop haut dans l'espace ... l'analyse c'est quelques semaines à plein temps pour intégrer toutes ces pratiques .... mais que des bonnes choses }.

Je finis avec 5 Entités + 1 relation porteuse de données,  ( c'est pas du JSON ... c'est les entités à l'horizontale : style MCT )

Les ENTITés :
* PERSONNE { ID_PERS ; ....ce que tu veux..... ; ID_CLASS ; ID_TYPE }
* GROUPE { ID_GROU ; NOM_GROU ; ....ce que tu veux..... }
* TYPES { ID_TYPE ; TYP_LIBELLE ; TYP_CATEGORIE }
les libellés : ( en dur dans la table , les valeurs ne changeront jamais )
Prof 0 ;Eleves 1 ;Tirs 2 ;Session 4 ;Classe 3; Groupe 5 ; sport_a 6 ; sport_b 7
les categories : personne = 0  ;; sport = 3 ; collectif = 2 ; biathlon = 1 ; raquette = 4

cela donnes :
Prof 0/0 ;Eleves 1/0 ;Tirs 2/1 ;Session 4/1 ;Classe 3/2; Groupe 5/2 ; sport_a 6/3 ; sport_b 7/3

* DATE { ID_DATE ; UNIX_DATE }
* RESULTAT { ID_RESULTAT ; ID_TYPE ; RES_LIBELLE }

et pour rassembler les diverses actions, inscriptions , etc .... [ c'est le noeud central, toutes les autres entités s'y relient ]

* ACTION { ID_DATE ; ID_TYPE ; ID_PERSONNE ; ID_GROUPE ; ID_EPREUVE ; ID_RESULTAT }
sachant qu'une colonne ou plusieurs dans cette table peut être vide selon la ligne créée... un champ vide n'étant pas une erreur.

A l'usage :

un prof dans la table personne :
PERSONNE( id ; ........... ; 3 ( sa classe scolaire ) ; 0 ( valeur de prof dans entité TYPE )   ).
un eleve :
PERSONNE( id ; .......... ; 3 ( idem... ) ; 1 ).

un prof appartient à un groupe
ACTION(ID_DATE ; 4 ( numéro du type ) ; ID_DATE ) ... les autres colonnes de ACTION sont laissés vides.

un prof appartient à une classe :
ACTION(ID_DATE ; 3 ( numéro du type ) ; ID_DATE ) .... les autres colonnes laissées vides aussi.

un élève est inscrit pour l'épreuve badminton :
ACTION(ID_DATE ; 6 )  ..... les autres sont laissés vides.

un élève est gagnant au badminton , score 3 manches contre 1.
ACTION( 1245 (clé étrangère ID_DATE ) ;  6 ( clé étrangère : 'badminton' de TYPE ) ; 8 ( clé étrangère :  'vainqueur' dans TYPE )  ; 158741 ( clé étrangère de RESULTAT , RES_LIBELLE = '3-1' ) )

ACTION a pour nombre de colonnes 5 , c'est une dimension, sa largeur maxi.
selon l'usage dédié , plusieurs champs peuvent contenir des ID de la même entité. 4 maxi + date ...
car la requete SQL ne se trompera pas dans la liaison des données.

c'est vraiment la relation 'ACTION' porteuse de données , qui peut regrouper toutes les autres ENTITés.
Afin de stocker tout événements, avec des types différents , des groupes , des personnes ... les ENTITés du MCD.

Bien sur , ça fonctionnes avec une nomenclature.
dans TYPE : la nomenclature est fournie. écrite en dur.
dans RESULTAT : selon les cas ( score / issue d'un tournoi ... ) , c'est un libellé qui peut être nouveau à chaque utilisation de 'RESULTAT::LIBELLE

si tu a tous les termes avant d'utiliser , tu peux les ajouter en tant que TYP_LIBELLE et dans une CATEGORIE dans TYP_CATEGORIE

pas mal ... ( tout en binaire dans la table ?? selon taille maxi de la chaine binaire , et c'est vu )

Alors : l'entité TYPE est 'source' de sémantique statique ( c'est une nomenclature , ça ne doit pas évoluer , c'est inévitablement rigide ).
l'entité RESULAT est aussi 'source' de sémantique , dynamique , c'est un fourre-tout ; tout ce qui n'était pas prédéfini par TYPE_libelle.
On peut ajouter des termes , des scores écrits comme on veut pour l'usage de cette bdd.

la relation ACTION qui est porteuse de données , c'est la marmite, le silot ... tout s'y mélanges , s'y retrouve. ( 1 champ date + 5 champs disponibles ; 5 x le même entité si besoin ; ou une fois chaque ).

C'est les requetes SQL qui organisent la restitution des données pour un affichage, une lecture adapté à ce qui doit être retourné par la requete.
C'est un système de 'va et vient' qui peut être fait entre ACTION et une entité unique...
ou 2 ... ou 3 ...... ++  ou 5 entités.
et ça par SQL.

{ quelques erreurs peuvent s'étre glissées, c'est même sur )
1 marmite + les ingrédients 'sémantique dynamique / sémantique statique' + 'user/people/human TABLE' + date
largeur de la marmite = 1 id +  1 ( date ) + nbre d'entités autres + ??checksum pour sécu ____??

Bonsoir,
 
J'ai vraiment du mal à comprendre et à intégrer l'ensemble de la proposition. Le fait que tout soit regrouper au même endroit me perturbe dans ma réflexion.
 
De plus, je pense ne pas avoir encore toutes les billes en langage SQL pour pouvoir imaginer ce que cela donnerais en script / trigger / procédure stockée. Je vais donc me pencher sur l'assimilation du langage SQL (si  tu as des sources fiable pour cette approfondissement, je suis preneur).
 
Je reviendrais ici, une fois ce langage assimilé convenablement.

et bien le MCD que je t'ai fait ( en courant ).
 
C'est typique 'META' ...
en fait, au lieu de faire des entités 'nommées/orientés besoin',
c'est orienté 'type de données' , et 'utilisation en tuple'.
 
Cherches des MCD de méta sur le web , des sites comme developpez.net / ou siteduzero .. en ont dans un cours, ou dans un coin ...
 
et pour l'usage du SQL dans ces MCD là,
le SQL fait la même chose que d'habitude,
il requete la base de données, pour lier les données.
 
C'est juste un peu moins transparent ...
les résultats des requetes sera le même que avec un MCD 'orienté besoin'.
Au niveau optimisation , les MCD Meta ils sont top, c'est des structures épurés.
 
tu a pu voir que l'entité ACTION , elle est composé que de clé étrangére..
au niveau réduction du poids , et utilisation à l'extreme des 'types de données' , c'est des modèles trés trés interessants.
Une réduction énorme ... presque des 'universels'.
Des modèles à tout faire avec.
 
Et, il y a sur ma proposition encore quelques optimisations possibles...
avec l'usage des réflexives.
une reflexive , c'est une relation d'une table vers elle même ( avec quelques données supplèmentaires quand la réflexive portes des données ).