Bonjour, je débute dans la modélisation de données alors d'avance, désolé pour les questions bateau...

J'explique brièvement le concepte du site, qui est globalement : une plateforme pour apprendre (consulter des cours), faire des exercices, suivre ses progrès au fil du temps grâce aux stats.

https://ibb.co/HzLZRx8

D'après la représentation au dessus,exercice et cours devrait être l'héritage de matière ou c'est bon comme ça ?

-
Edité par Fab291 16 juillet 2020 à 11:33:18

Bonjour,

Fabou291 a écrit:

exercice et cours devrait être l'héritage de matière ou c'est bon comme ça ?

Non, c'est bon comme ça, la notion d'héritage n'a rien à voir avec cet exemple ... je pense que tu peux rechercher un peu pour approfondir cette notion ... https://sqlpro.developpez.com/cours/modelisation/heritage/

En revanche, un exercice n'est-il pas lié à un cours (ou plusieurs) plutôt que simplement à une matière ?

Merci beaucoup pour le lien, c'est effectivement beaucoup plus simple de comprendre avec le rôle de personnes au sein d'une entreprise. D'ailleurs dans le cadre d'un collège ou lycée je pourrais appliquer ça pour le rôle d'étudiant et d'enseignant, ou encore définir un rôle plus précis pour les étudiants, pour savoir s'ils sont interne ou externe.

Je t'avais déjà vu répondre à quelques questions sur le forum et j'ai vu que tu proposai des lien pour la "Conception BDD". C'est pas mal grâce à toi que j'essai d'apprendre le modèle conceptuel de donnée :). J'avais vu cette notion d'héritage mais dès qu'il sagit de savoir quand l'appliquer c'est une autre histoire 

Benzouye a écrit:

En revanche, un exercice n'est-il pas lié à un cours (ou plusieurs) plutôt que simplement à une matière ? 

Effectivement, ça semble être plus logique, mais j'ai quand même du mal à savoir si je m'oriente correctement (les changements : https://ibb.co/zXpKZtt)

Un cours peut correspondre à un ensemble d’exercice, en fonction d’un type d’exercice. Ces exercices ont plusieurs niveaux de difficulté qui est déterminé par plusieurs paramètres (qui diffèrent en fonction du cours)

Par exemple :

Les cours portent sur les intervalles (les intervalles, en musique), c’est ce que j’appelle pour le moment une matière (qui n’en est pas vraiment une, c’est plus une section qu’autre chose).

Pour ce « Cours », Il y a plusieurs type d’exercices :

        - Comparaison d’intervalle

        - Identification d’intervalle

        - Chant d’intervalle

Pour chaque type d’exercice il y a un ensemble d’exercice

        1/ Unisson-2^nd mineur

        2/ 2^nd mineur-2^nd majeur

        3/ 2^nd majeur – 3ece mineur

        4/ Unisson - 2^nd mineur - 2^nd majeur – 3ece mineur

        Etc.

Pour chaque exercice, plusieurs niveaux de difficulté qui sont défini par des paramètres

        - De 1 à   3             = Note commune (Ascendant, Descendant, Harmonique)

        - De 4 à   6             = Note avoisinante (Ascendant, Descendant, Harmonique)

        - De 7 à   9             = Pas de note commune (Ascendant, Descendant, Harmonique)

        - 10                        = Mélange de tout

Et c’est là que je m’embrouille… Comment inscrire dans une base de donnée, l’ensemble des paramètres qui déterminent un niveau de difficulté pour un exercice donné (Sachant que les paramètres de difficulté d’un d’exercice, diffèrent avec les paramètres de difficulté d’un autre quand ils ne font pas partie du même cours) ?

Est-ce d’ailleurs une bonne idée de stocker ces "paramètres de difficulté" dans une base de donnée... ?

Comment savoir si des données sont à intégrer dans une base ou non d'ailleurs?

Existe-il une méthode, un ensemble de question auquel répondre avant et pendant la méthode MERISE pour la création d'un projet/site?

Je suis un peu perdu... x)

-
Edité par Fab291 16 juillet 2020 à 14:24:57

Fabou291 a écrit:

J'avais vu cette notion d'héritage mais dès qu'il sagit de savoir quand l'appliquer c'est une autre histoire

Je comprends ... C'est un apprentissage pas à pas ... La création d'un modèle entité/relation devrait "couler de source", mais ce n'est pas si évident. C'est un peu la même logique que la programmation orientée objet. Tu détermines quels sont tes objets (entités) et leurs attributs propres, puis tu définis les relations entre eux en précisant les cardinalités.

Avec un peu de pratique, lorsque tu énonces ton contexte "en français" tu peux en déduire entités, relations et cardinalités.

Je ne connais pas ton contexte (ni la musique ...) mais énoncé ainsi, à ce que je comprends, tu as des sections (ou matières), des cours, des types d'exercices, des exercices et des paramètres. Cela fait 5 entités.

Après il faut formaliser les relations et cardinalités.

Exemple pour la relation entre cours et section : un cours est lié à une section, une section contient plusieurs cours. les cardinalités peuvent s'écrire ainsi : cours 1,1 --- 1,n section. C'est une relation 1,n (de la plus grande cardinalité de chaque côté de la relation).

Il te faut faire cet exercice pour chaque relation pour clarifier "par écrit" comment les entités sont reliées entre elles.

Pour information, il existe des relations ternaires, qui relient 3 entités entre elles, ce qui pourrait être utile dans ton cas pour déterminer la relation entre paramètre exercice et cours ...

-
Edité par Benzouye 16 juillet 2020 à 15:18:51

Yep, merci beaucoup pour tous ces bon conseils Ben !

J'ai fait une nouvelle version, enfin presque... je suis limité à un nombre d'entité et de relation avec Jmerise sans activation. Mais je commence à y voir un peu plus clair même si je suis sur de rien (je verrai au fil du temps). Tu utilises quoi comme logiciel pour tes diagramme ?

-
Edité par Fab291 16 juillet 2020 à 23:19:32

Fabou291 a écrit:

Tu utilises quoi comme logiciel pour tes diagramme ?

Un sujet récent : https://openclassrooms.com/forum/sujet/logiciel-pour-modeliser-une-bdd#message-93820545

Merci pour le lien! Finalement j'ai opté pour JMerise pendant 6 mois, le rapport qualité/prix est intéressant j'ai l'impression.

Je bloque là, comment je peu modéliser ce concept :

Un utilisateur crée un exercice en paramétrant des données liées aux thèmes et au type de de l'éxo ?

PS_1 : J'ai essayé la relation ternaire, mais j'arrive pas du tout à faire une phrase correcte.

- Un thème à des paramètres de type d'exo

- un type d'exo à des paramètre de thème

- Un paramètre dépend de type d'éxo et de themes

???...

PS_2 : Finalement j'ai remis la relation entre exo et thème/sujet de travail (qui s’appelait matière avant). Ça me semble plus logique dans mon contexte, mais je sent que je vais pas tarder à revenir sur cette relation...   Je t'avoue que dès qu'il y a des relations du type "Contenir, Avoir, Appartenir", je suis un peu perdue

j'avais écrit:

Exemple pour la relation entre cours et section : un cours est lié à une section, une section contient plusieurs cours

Il faut faire le travail de cardinalités comme présenté plus haut :

Tu as des exercices, des types d'exercice, des paramètre et des thèmes.

• Un thème est lié à ... type d'exercice, un type d'exercice est lié à ... thème.
• Un thème est lié à ... exercice, un exercice est lié à ... thème.
• Un paramètre est lié à ... type d'exercice, un type d'exercice est lié à ... paramètres.
• etc.

Force-toi à écrire ces phrases en remplissant les trous.

-
Edité par Benzouye 17 juillet 2020 à 12:27:37

Ok, j'ai zappé d'ajouter le diagramme à mon message :/

https://ibb.co/Dbbt307

Pour les cardinalité, en générale je les dit, mais j'ai jamais essayé de mettre ça à plat par écrit. Ok, je vais faire ça ! Merci !

-
Edité par Fab291 17 juillet 2020 à 12:45:56

Qu'est-ce qu'un "paramètre" en fait ?

Peux-tu donner quelques exemples de ce qui doit être stocker ?

Vu comme ça, je verrai bien une ternaire thème / paramètre / type, avec une attribut valeur ...

T'as mis le doigt sur une entité qui m'embrouille énormément x)

En fait, j'ai besoin de plusieurs paramètres pour déterminer de quoi se compose un exercice.

Par exemple :

Si je veux Créer un exercice pour Comparer (données rattaché au type d'exercice)

deux intervalles (donnée rattaché au thème de l'exercice) 

-> Il me faut à la fois définir les intervalles (par exemple je choisi de comparer la 2nd mineur et la 2nd Majeur à partir d'une liste d'une 20aine d'intervalles disponible)

-> Définir des paramètre relatif à l'exercice de comparaison d'intervalle (si les notes seront commune- voisine- ou non, si elles seront joué en arpège (ascendant et/ou descendant) - en harmonique. Se qui augmente la difficulté en fonction de se qui est choisi...).

PS : J'essaie de faire un site qui permettra de travailler l'oreille relative, donc pour l'histoire de comparaison d'intervalle, il y aura une page dédié qui jouera 2 note à la suite (premier intervalle), deux autre note (qui correspondent au 2ème), et en fonction on doit répondre quel est le plus grand. (il y a un autre exercice qui ressemble ou il faut cette fois identifier l'intervalle entre plusieurs proposition faites). Si tu veux, pour que se soit plus claire, je peux te montrer une petite vidéo du visuel que j'ai pensé en mp.

PS2 : 

Voilà le genre de parametre/donnée qu'il faut que je traite pour la création d'un exercice du type : comparaison d'intervalle :

Les intervalles :

   - Unisson (bool),

   - Seconde mineur (bool),

   - Seconde Majeur (bool),

   - Tierce mineure (bool),

   - Tierce Majeur (bool)

   - Quarte juste (bool),

etc.

L'Exécution : 

   - Jouer harmoniquement (bool)

   - Jouer en arpège (bool)

      - ascendant (bool)

      - descendant (bool)

      - harmonique (bool)

Options : 

   - Notes communes

   - Notes voisines

   - Montrer les nom des intervalles (bool)

-
Edité par Fab291 17 juillet 2020 à 15:38:25

C'est dommage que je n'y connaisse rien en musique, car j'ai vraiment du mal à comprendre le fonctionnement souhaité ...

Peux-tu essayer de représenter le contenu de quelques exercices différents pour que j'essaye de comprendre ?

Yep, je vais essayer, merci en tout cas de me porter autant d’intérêt !

Je crois que le plus simple c’est de t’expliquer en fonction de la « veille fonctionnelle » que je suis en train de faire sur un logiciel qui reprend les mêmes principes que les miens :

https://i.ibb.co/54t4gWJ/Untitled-3.jpg

Je t’ai envoyé un mp, avec un lien vers une vidéo qui représente le visuel du site, avec plus précisément le visuel de l’exo « comparaison ». Même s'il n'est pas question de création d'exercice, tu verra au moins comment j'ai prévu de ranger tout ça

Ouai je comprend que t'ai du mal à comprendre comment je veux procéder, je suis pas sur de le savoir moi même pour le moment... J'essai surtout de retranscrire se que je vois avec cette "veille fonctionnel"...  Mais comme tu le vois je patauge un peu x)

-
Edité par Fab291 17 juillet 2020 à 18:50:12

Pour moi, les paramètres que tu indiques seraient des données d'un exercice, donc la relation est entre Exercice et Paramètres (1 exercice à 1 jeu de paramètres, 1 jeu de paramètre peut appartenir à plusieurs Exercices (même si je pense que dans les faits, il vaudrait mieux 1 jeu de paramètre appartient à 1 Exercice).
De même, pour moi, le type et le thème d'exo dépendent des paramètres de l'exercice; et donc toujours pour moi, c'est Exercice qui est "central" et donc qu'il faudrait fusionner la table Exercice et Paramètres et "transformer" les paramètres en colonnes de la table Exercice.

umfred a écrit:

il faudrait fusionner la table Exercice et Paramètres et "transformer" les paramètres en colonnes de la table Exercice

Je ne suis pas d'accord avec cela, car d'un exercice à l'autre les paramètres ne seront pas les mêmes.

Selon moi, il faut bien créer une table paramètres reprenant l'ensemble des paramètres possibles, tous types d'exercice confondus.

Tu définis tous les types possibles, tous les thèmes possibles. Ensuite tu associes à un type les paramètres qu'il faut renseigner (relation n,n que l'on pourrait nommer type_parametre par exemple). Enfin les exercices sont créé en leur donnant un type, et tu vas donc avoir une relation n,n entre paramètre et exercice pour affecter la valeur du paramètre.

Ce qui me fait un peu peur c'est la diversité des paramètres, dont certains ont des valeurs prédéfinies, ce qui implique de créer des listes de valeurs par paramètres avec une nouvelle entité "valeur" pour les stocker.

Rapidement je verrais un MCD ainsi :

Attention, je n'ai pas représenté la contrainte de cohérence entre exercice/paramètre et type/paramètre pour empêcher de lier à un exercice un paramètre qui n'est pas lié à ce type d'exercice.

-
Edité par Benzouye 20 juillet 2020 à 18:06:23

Merci pour vos réponses, effectivement, fusionner la table exercice et paramètre n'est pas envisageable pour les raisons évoqué par Benzouye.

Ton mcd à l'air de tenir la route. Il y a une cardinalité qui n'a pas l'air de correspondre cependant, ce qui complique un peu le raisonnement malheureusement puisque :

1.a.

"Un type peux appartenir à plusieurs thèmes" :

le type Identification peux aussi bien servir pour le thème intervalles, accords et gammes. 

le type Reproduction peux aussi bien servir pour les thème rythmique et mélodie.

C'est pour ça d’ailleurs que je n'avais pas fait de relation directe entre type et thème dans ma dernière représentation. J'avais simplement fait une relation entre type et exercice.

Si on suit mon raisonnement (qui n'est pas forcément le bon, j'envisage seulement...) :

Ça donne les cardinalité 0,n et 1,n pour la relation entre theme et type, se qui voudrait dire que la relation concerne deviendrait une table dans ma base de donnée avec les clefs étrangères des tables theme et type.

Si on suit mon raisonnement qu'advient-il de la relation type_parametre?

1.b

Sinon pour que les cardinalité soit correcte il faudrait que je crée non pas un type identification qui conviendrai à plusieurs thème mais un type identification d'intervalle, identification d'accords, identification de gammes. Ça peut être une solution plus simple au finale pour gérer les paramètres :

2/

Jusqu’à aujourd'hui  je préférai lié les paramètres/données non pas au type d'exercice mais au thème car pour les thèmes suivants je jongle avec les paramètre/données suivant(e)s :

   - intervalles : 2nd mineur, 2nd majeur, 3ece mineur, 3ece majeur, etc. (représente la grandeur de l'écart entre les notes)

   - accords : Majeur, Mineur, Majeur 7, mineur 7, diminué, augmenté, etc (nom des accords), + La possibilité d'en créer/ajouter un sois même

   - gammes : Lonien, Dorien Phrygien, etc (Le nom des gammes) + La possibilité d'en créer/ajouter un sois même

   - rythmique : C'est un peu particulier lui, puisqu'il faut à la fois définir le chiffrage de la mesure (2/2,2/4,4/4), les figures de notes que (croche, double croche, etc) et le nombre de mesure. + La possibilité d'importer une rythmique perso

   - mélodie : La ça se complique parce que ça peu aussi bien reprendre les paramètres du type rythmique et gammes etavoir ses propre paramètres comme le nombre de mesures, l'intervalle maximum, et d'autre paramètre spécifique à mélodie. + La possibilité d'importer une mélodie perso.

Le type d'exercice sert surtout à savoir comment s'organise un exercice  :

Par exemple pour la comparaison il faut forcement utilisé 2 donnée pour pouvoir les comparer (en donnant la possibilité de répondre soit A soit B), alors que pour l'identification, 1 seul suffit (avec réponse multiple).

3/

En y réfléchissant, et en observant finalement qu'il y aura la possibilité d'ajouter sois même des données (ajouter un accord ou une gammes, etc) je me demande s'il faudrait pas tout simplement faire une table spécifique pour chaque en listant toute les données :

Une table :

   - Accord (listant tous les nom),

   - Gamme,

   - Chiffrage,

   - Figures de note

   - rythmique perso et mélodie perso que je peux regrouper en une seul table "fichier importé", puisqu'il pourrais être aussi bien utilisé pour travailler la mélodie ou sa rythmique seulement.

Mais si je fais ça, comment suis-je censé représenter mon MCD pour la création d'un exercice ? La création de ces tables me semble de plus en plus évident, mais le MCD de moins en moins...

4/

Une chose aussi pour laquelle je cherche une réponse/avis :

Pour la création d'un exercice Comparaison d'intervalle par exemple :

Je peux définir les intervalles que je souhaite comparer dans une liste d'une 20 intervalles (on va dire...) à l'aide de checkbox.

Le plus simple pour stocker les intervalles choisi, serais tous simplement de stocker l'id de l'intervalle checké au lieux de renseigner dans une table une valeur bool pour chaque intervalles possible (se à quoi j'ai pensé en premier lieu...)

Ça me parait mieux, mais je suis pas sûr...

-
Edité par Fab291 21 juillet 2020 à 10:38:26

Fabou291 a écrit:

Un type peux appartenir à plusieurs thèmes"

Du coup je retournerai la situation en affectant le thème à l'exercice, un exercice ayant un type, et un thème regroupant plusieurs exercices. Après il ne faudrait pas qu'un même exercice puisse se retrouver dans plusieurs thèmes mais je n'ai pas l'impression que ce soit le cas.

Ainsi, tu peux afficher les thèmes, et pour chacun les types d'exercice issus des exercices auquel il est rattaché "indirectement".

Par ailleurs, Je maintiendrai le paramétrage au niveau de l'exercice, pour avoir une gestion fine de chaque exercice, même si la relation type_parametre permet d'avoir un "modèle" de paramétrage.

Le MCD serait :

Ça m'a l'air d'être une bonne piste, merci. Par contre on est obligé de relier exercice et valeur? Ça apporte quoi? Pourquoi n'est-il pas relié à type_parametre également? Ça oblige du coup à un paramètre d'un exercice à avoir une valeur ? 

Autre chose: Comment je fais pour indiquer les résultats d'un exo par réponse possible, par exemple :

Imaginons que pour l'identification d'un intervalle j'ai 3 choix de rep possible : unisson, 2nd mineur, 2nd Majeur (défini grace a type_parametre, type_theme sur mon diagramme). Ou est-ce que je stock mes résultats :

   -> 50% de réussite pour identifier A

   -> 80 % de réussite pour identifier B

   -> 30 % de réussite pour identifier C

Résultat total : 53%

Fabou291 a écrit:

Par contre on est obligé de relier exercice et valeur ?

Non, cela permettrait par exemple de stocker la réponse attendue à un exercice pour un paramètre donné ... Un paramètre a plusieurs valeurs possibles (unisson, 2nde mineure et 2nde majeure par exemple).

Fabou291 a écrit:

Comment je fais pour indiquer les résultats d'un exo par réponse possible

Là encore, ne comprenant pas de quoi l'on parle, j'ai peur de te faire partir dans une mauvaise direction. C'est pour cela que j'aurais aimé que tu décrives précisément, dans le détail, au moins deux exercices différents pour comprendre ce qui défini un exercice, où se trouve la liste des réponses possibles et ce qui défini une bonne ou mauvaise réponse ...

Par ailleurs, concernant ton modèle actuel, un exercice étant lié à un thème, je ne vois pas l'intérêt de la relation theme_parametre, j'ai l'impression qu'elle doublonne "dangereusement" avec la relation exercice_parametre ...

Ok, je vais reprendre du début en essayant d’être concis :

    -Le site en question permettra d’apprendre à reconnaitre les notes à l’oreille.

     En d’autres termes permettra de « travailler son oreille relative » = en fonction d’une première note jouée, apprendre à déterminer la hauteur de(s) (la) note(s) suivante(s).

    -Il y aura plusieurs activités (type d’exo) définis au sein d’un thème de travail (intervalles, accords, gammes, rythmique et mélodie)

    -Il y aura plusieurs exercices dans une activité

    -Chaque exercice à un niveau de difficulté défini par des règles d’exécution de l’exo

Un exercice correspond donc à un ensemble d’éléments avec lesquels il va jongler pour poser une question à l’utilisateur. Un exercice a une procédure d’exécution paramétré par l’utilisateur (s’il a créé l’exercice) grâce à diverses règles d’exécutions.

Un exercice peut être prédéfini ou crée par l’utilisateur lui-même.

Exemple 1 :

    Thème : Accords

          ->Activité : Identification d’accords

                    ->Exercice 1 : Identification des Accord Majeur et Accord mineur

                                 ->Difficulté 1 : Arpège ascendant

Pour élaborer cette exercice :

   - 2 Eléments ont été inclus : Accord Majeur et Accord mineur (dans une liste d’une 20 aine d’autre éléments)

   - 5 règles d’exécutions :

      - Jouer l’accord en arpège Ascendant

      - Position fondamental de l’accord

      - Tessiture correspondant à celle d’une guitare (la note la plus haute et la note la plus basse ne pourront être dépassé)

      - Transposition aléatoire (aucune restriction quant à la fondamental de l’accord)

      - Ne pas jouer la tonique de la tonalité avant de jouer l’accord

L’appli web, grâce à ça, va réaliser, à partir d’une note random (la fondamentale de l’accord), un accord Majeur ou mineur. Il va ensuite le faire écouter à l’utilisateur, et poser la question:

L’accord que vous venez d’entendre est-il Majeur ou mineur ?

Laissant ainsi à l’utilisateur le choix de répondre entre les deux propositions (boutons) : Majeur ou mineur.

En fonction de l’élément (l’accord Majeur ou mineur) qui viens d’être mis sur table, un pourcentage de réussite est appliqué suite à la réponse donnée par l’utilisateur. Il y a donc 2 pourcentages de réussite dans cette exercice puisqu’il y a 2 éléments incorporé (un pour Majeur, un pour mineur) + 1 autre qui fait la moyenne des deux.

Et ainsi de suite : Une fois l’exercice terminé, les données relatives au pourcentage de réussite pour cette exercice sont stockées dans la bdd.

Il se peut que pour d’autre exo, il y ai plus de deux éléments, ce qui implique qu’il y aura plus de 2 résultat + 1.

Exemple 2 :

    -> Thème : Rythmique

          ->Activité : Reproduction de rythmique

                    ->Exercice 1 : Mesure en 4/4, ronde, blanche, noir et croche

                             ->Difficulté 1 : 1 mesure en 4/4 – Noires uniquement – Avec silence

Pour élaborer cette exercice :

   - 2 élément de figure ont été incorporé = la noir, et le silence correspondant (parmi 30 figures différentes)

   - 1 élément de chiffrage de la mesure a été incorporé = 4/4 (parmi 10 chiffrages différents)

   - 5 règle d’exécutions :

          - Nombre de mesure : 1

          - Aucune modification de durée (parmis 3 possibilité cumulable)

          - Tempo : 90

          - Sévérité de l’évaluation : normal

En fonction tout ça, l’appli va générer sur 1 mesure en 4/4 un rythmique composé de noir et de silence. Elle va dans un premier jouer la rythmique à l’utilisateur.

Dans un seconde temps, l’utilisateur devra reproduire cette rythmique en tapant des mains au micro.

En fonction du moment de chaque clap de l’utilisateur, et en fonction de la sévérité de l’évaluation, la réponse sera valide ou non.

Un pourcentage de réussite est mis à jour à chaque réponse donnée.

En fin d’exercice, les résultats sont sauvegardés en base de donnée pour cette exercice

PS : Tu l’as surement remarqué, finalement je reviens en arrière et je préfère considère qu’un exercice appartient à 1,1 activité qui elle-même appartient 1,1 à un thème.

J’espère que je te n’embrouille pas trop à changer de nom toutes les deux secondes… J’essaie moi-même de comprendre comment tout peut s’imbriquer…

Merci encore de passer autant de temps sur un truc aussi obscur soit-il :/

-
Edité par Fab291 22 juillet 2020 à 16:45:56

Bon, j'imagine que je ne suis toujours pas clair...:(

J'ai fait un nouveau MCD axé sur les éléments à inclure dans un exo.

Je doute sur la table résultats_par_elements_de_réponses.

Apres pour les paramètres d’exécution d'un exercice, je sais toujours pas comment conceptualiser ça...

Le MCD suivant à l'air correct?

-
Edité par Fab291 24 juillet 2020 à 14:43:36

Je ne suis pas très optimiste sur la maniabilité de ce MCD ...

Les deux exemples d'exercice dans ton message précédent sont pas mal pour comprendre où tu veux aller. J'aimerais recoller avec ma proposition de modèle ( paramètre / valeur ).

Si je m'appuie sur le premier exercice, les paramètres semblent être (attention je dis sûrement n'importe quoi là) :

• Sens
• Note
• Tessiture
• Transposition
• Tonique préalable

Les valeurs pour ses paramètres semblent être respectivement :

• Ascendant ou descendant
• La liste des notes
• La liste des tessitures
• la liste des transposition
• Oui / Non

Ensuite tu crées un bout de programme spécifique, qui sera en charge de sélectionner une note dans la liste des valeurs disponibles pour le paramètre "note", une tessiture dans la liste des valeurs disponibles pour le paramètre "tessiture", une transposition dans la liste des valeurs disponibles pour le paramètre "transposition", et proposer le questionnaire à l'utilisateur.

L'utilisateur créant l'exercice pourrait également enregistrer des choix de paramètre que tu traiterais côté code.

Tu pourras stocker en base le résultat de l'utilisateur avec au moins le lien de l'exercice réalisé et pourquoi pas la liste des valeurs des paramètres utilisés (au format JSON par exemple pour simplifier).

Il faut bien distinguer ce qui est de l'ordre du stockage de données, et ce qui de l'ordre de "l'intelligence applicative". Ton programme doit pouvoir trouver les données dont il a besoin pour représenter les fonctionnalités attendues, et ta base de données doit pouvoir fournir ces données avec cohérence et intégrité ...

Oui, c'est à peu près l'idée pour les paramètres.

Benzouye a écrit:

Il faut bien distinguer ce qui est de l'ordre du stockage de données, et ce qui de l'ordre de "l'intelligence applicative".

Justement, je m'enmmele les pinceaux, j'ai du mal à savoir ce que je dois stocker en base et ce qui doit être stocké en dehors (en json comme tu l'as indiqué en exemple). Existe-t-il des tutos, livres ou autre, qui peuvent me permettre de comprendre se qui est préférable de stocker ou pas en bdd?

Donc selon toi il serais préférable de stocker tous les paramètres qui régis un exercice avec sa valeur associé en dehors de la base, dans un fichier représentant chacun un exercice, et ne stocker que le résultat à chaque entrainement dans la bdd, avec un lien vers le fichier exercice créé par l'utilisateur. Du coup les tables "valeurs" et "paramètres" des précédents MCD n'ont plus lieu d'être ?

-
Edité par Fab291 27 juillet 2020 à 11:32:08

On s'est mal compris.

Le travail effectué pour construire l'exercice ne peut pas être stockée en base (c'est du code applicatif, de l'intelligence fonctionnelle) tout au mieux le résultat de ce travail peut l'être. Toute autre donnée sera stockée en base ...

Si je reprends :

• une table type d'exercice qui recense tous les types d'exercice
• une table paramètre qui recense tous les paramètres possibles pour tous les types d'exercice
• une table valeur qui recense pour chaque paramètre les valeurs possibles
• une table parametre_type_exercice pour définir les paramètres à renseigner par type d'exercice

Lorsqu'un utilisateur crée un exercice, il choisit le type et ton programme lui propose donc les paramètres associés chacun avec ses valeurs possibles (ou aucune ou aléa ?).

Tu peux stocker le nouvel exercice créé dans la table exercice, et son paramétrage dans une table parametre_exercice.

Lorsqu'un utilisateur s'entraîne sur un exercice, ton programme doit identifier le type d'exercice et exécuter un algorithme spécifique. Pour cela il va récupérer le paramétrage de l'exercice et le "construire" en fonction pour l'utilisateur.

Pour stocker les réponses utilisateurs (je n'en avais pas trop parlé), tu peux avoir une entité utilisateur et une entité participation. Cette dernière en relation 1,n avec utilisateur et exercice. Pour stocker la réponse je pense que là on peut dénormaliser pour simplifier le modèle, en mettant une colonne réponse de type JSON pour éviter de différencier les réponses par type d'exercice ...

Benzouye a écrit:

Pour stocker la réponse je pense que là on peut dénormaliser pour simplifier le modèle, en mettant une colonne réponse de type JSON pour éviter de différencier les réponses par type d'exercice ...

Ok, et à partir de la, pour chaque participation je pourrais en déduire le pourcentage de réussite par réponse possible.

Exemple : Participation a l'exo Identification d'accord Majeur et mineur :

   Résultats déduit par l'application apres lecture du JSON :

      80% de réussite pour identifier un accord Majeur

      30 % de réussite pour identifier un accord mineur

   Moyenne : 55% 

La relation s’entraîner entre exercice et utilisateur ne fait-elle pas doublon avec l'entité participation?

-
Edité par Fab291 27 juillet 2020 à 14:29:03

Fabou291 a écrit:

La relation s’entraîner entre exercice et utilisateur ne fait-elle pas doublon avec l'entité participation?

Si, c'est en effet la même chose.

Bon, je suis un peu perdu.. Existe-t-il des services qui permettent de créer un MCD / une base de donnée viable pour un projet ?

Et avec un pue de recul je comprend même plus pourquoi associer un thème d'exercice à un exercice plutôt qu'a un type...

La logique est plutôt la suivante : 

Un thème/sujet (d'étude ou d'exercice) contient -> une collection de type d'exo qui contiennent -> une collection d'exo

-
Edité par Fab291 29 septembre 2020 à 17:19:43

Tu peux peut-être simplifier ton projet en utilisant un objet JSON, complètement unique et personnalisé par exercice sans te soucier d'avoir une structure relationnelle forte ...

C'est une idée, ca me parle déjà un peu plus en tout cas.

Ce MCD te parait-il viable?

EDIT :

- Oups, ne fait pas attention à la table "valeur" tout à droite, elle n'apparaissait pas a l'écran lors de mon export, sinon je l'aurai enlever

- Dans la relation "Créer", le champ "date" n'a rien à faire ici, elle fait parti de l'entité Exercice)

-
Edité par Fab291 30 septembre 2020 à 8:31:12

Oui, c'est bien plus simple pour toi en effet

Surtout si tu es plus à l'aise avec le JSON.

Par contre cela impose une plus grande part de gestion côté application.