Discussion :

[gromf]

Bonjour

je débute en programmation et souhaiterais avoir votre avis sur la validité de mon modèle.
Souhaitant développer un radio réveil partagé(multi user) avec la possibilite d'écouter /programmer l'écoute de radio ou musique ou réveil.

Le principe est simple chaque user à une bibliothéque de sons, de radios et de podcasts (+ possibilité d'ajouter / supprimer / modifier) ainsi que des alarmes et playlist et il peut soit :
- écouter un média (= radio ou musique ou podcast) ou une playlist (enregistrement d'une suite de médias)
- programmer une alarme (définir une heure de début / fin pour un média ou une playliste)

Voila le shémas que j'ai fait
(j'ai aussi rajouté une problématique de role pour avoir des super user qui peuvent tout faire et des user qui ne peuvent que voir par exemple)

Je ne sais si cela a une quelconque importance mais le langage utilisé sera python
D'avance merci pour vos commentaires, remarques, suggestions...

[Richard_35]

Bonjour Gromf,

Pas mal, pour un début !... La structure des tables est OK. Peut-être, prévoir qu'une alarme peut déclencher une playlist ?

Sinon, pour débuter, il vaut mieux commencer par écrire en français les règles de gestion, tel qu'expliqué dans cet excellent billet de CinePhil.

Ensuite, créer un MCD et enfin, générer les tables, compte tenu de cet autre excellent billet de CinePhil.

Dans ton cas, en commençant par la fin, donc :

Les règles de gestion :

• 1 user possède 1 et 1 seul rôle ;
• 1 rôle peut être affecté à plusieurs user ;
• 1 user peut avoir plusieurs alarmes ;
• 1 alarme n'appartient qu'à 1 et 1 seul user ;
• 1 user peut avoir plusieurs playlist ;
• 1 playlist n'appartient qu'à 1 et 1 seul user ;
• 1 alarme ne fait référence qu'à 1 et 1 seul média ;
• 1 média peut concerner plusieurs alarmes ;
• 1 playlist ne fait référence qu'à 1 et 1 seul média ;
• 1 média peut concerner plusieurs playlist.

Le MCD :


Les tables :
Fait par tes soins.


Cette démarche est importante pour tes futurs projets qui, sans doute, seront plus complexes et feront intervenir de multiples entités.

[gromf]

Je passais de temps en temps, espérant une réponse, voila qui est fait... avec classe et liens qui vont bien
Je lis tout ca, corrige la copie et post ma révision

Grand merci Sensei

[gromf]

Quand meme un peu de mal à comprendre
"1 playlist ne fait référence qu'à 1 et 1 seul média"

C'est plutôt :
"1 playlist fait référence à 1 ou plusieurs média" non ?

Et ainsi, mais la j'ai la tête en feu avec ta très pertinente suggestion d'alarme qui déclenche une playlist, je pense à ça :


J'ai bon ?

[Richard_35]

Bonjour Gromf,

Quand meme un peu de mal à comprendre
"1 playlist ne fait référence qu'à 1 et 1 seul média"
C'est plutôt :
"1 playlist fait référence à 1 ou plusieurs média" non ?

==> je me bornais à traduire tes tables en règles de gestion (normalement, il faut faire l'inverse...). Dans ta table Playlist (identifiant IdPlaylist), tu stockes IdMedia donc, 1 playlist ne fait référence qu'à 1 et 1 seul média (dans 1 champ, tu ne peux pas stocker plusieurs valeurs de IdMedia).
Souhaites-tu que 1 playlist fasse référence à 1 ou plusieurs média ?


Pour l'instant, compte tenu des tables que tu présentes :

Tes règles de gestion :

• 1 user possède 1 et 1 seul rôle ;
• 1 rôle peut être affecté à plusieurs user ;
• 1 user peut avoir plusieurs alarmes ;
• 1 alarme n'appartient qu'à 1 et 1 seul user ;
• 1 user peut avoir plusieurs playlist ;
• 1 playlist n'appartient qu'à 1 et 1 seul user ;
• 1 alarme ne fait référence qu'à 0 ou 1 seul média ;
• 1 média peut concerner plusieurs alarmes ;
• 1 playlist ne fait référence qu'à 0 ou 1 seul média ;
• 1 média peut concerner plusieurs playlist ;
  
• 1 alarme ne fait référence qu'à 0 ou 1 seule playlist ;
• 1 playlist peut concerner plusieurs alarmes.

Les tables :
Élaborées par tes soins.

Je te suggère fortement, de nouveau, de passer par une modélisation avant de créer tes tables. Tu trouveras pas mal de logiciels gratuits, JMerise, par exemple.

[gromf]

Bonjour Richard,

Ok Sensei, j'ai tout repris !

Donc voila les règles de gestion :

• 1 user possède 1 et 1 seul rôle ;
• 1 rôle peut être affecté à plusieurs user ;
• 1 user peut avoir 0 ou plusieurs alarmes ;
• 1 alarme n'appartient qu'à 1 et 1 seul user ;
• 1 user peut avoir 0 ou plusieurs playlist ;
• 1 playlist n'appartient qu'à 1 et 1 seul user ;
• 1 alarme ne fait référence qu'à 1 et 1 seul média ;
• 1 média peut concerner 0 ou plusieurs alarmes ;
• 1 playlist fait référence à 1 ou plusieurs média ;
• 1 média peut concerner 0 ou plusieurs playlist;
• 1 alarme peut avoir 0 ou 1 playlist;
• 1 playlist est associée à 0 ou 1 alarmes;

Par contre je ne vois pas bien l'intérêt de faire un MCD puis les tables... j'ai donc fait comme j'avais fait avant = les deux en même temps !
(et effectivement il me manquait des tables associatives, cf un des articles cités).
Donc ca me donne ca :



Tu m'adoubes chevalier du MCD ou je retourne encore une fois récurer les chiottes du forum pour avoir mal lu ?

[Richard_35]

Tu m'adoubes chevalier du MCD ou je retourne encore une fois récurer les chiottes du forum pour avoir mal lu ?

==> je pencherais pour la seconde solution......




En cause :

• 1 playlist fait référence à 1 ou plusieurs média ==> peut-être inversé avec la suivante ;
• 1 playlist n'appartient qu'à 1 et 1 seul user ==> peut-être inversé avec la suivante ;
• 1 alarme ne fait référence qu'à 1 et 1 seul média ==> en es-tu sûr ?... une alarme est, soit un média, soit une playlist, non ?
• 1 playlist est associée à 0 ou 1 alarmes ==> en es-tu sûr ?... une playlist peut concerner 0 ou plusieurs alarmes, non (car 1 user peut avoir plusieurs alarmes) ?

Par contre je ne vois pas bien l'intérêt de faire un MCD puis les tables...

==> plusieurs raisons :

• l'inversement des deux premières règles dans ton schéma ;
• la création des clés étrangères au bon endroit ;
• la plus importante :

  Cette démarche est importante pour tes futurs projets qui, sans doute, seront plus complexes et feront intervenir de multiples entités.

  ==> le projet qui nous occupe est relativement simple (quoique suscitant de nombreux échanges...). Quand tu attaqueras des projets plus complexes avec un nombre d'entités plus important, il faudra d'abord "modéliser" avant de passer au construction des tables car c'est une conceptualisation correcte qui doit générer les tables, en final. Avec 5 entités, pas de problèmes... avec 50, ce n'est plus la même chanson...

[gromf]

Manque de rigueur flagrant (relectures des règles et annotations peu cohérentes) la honte me caresse les fesses et je transmets mes excuses au Sensei donc.
Les chiottes brillent de 1000 feu cette fois ... de toutes façon si ce n'est pas le cas je me colle la tête dedans !



Et je crois que j'ai bien compris l'intérêt de modéliser
Une dernière question j'espère :
- Il n'y a pas plus simple pour modéliser cette histoire d'alarme qui est soit un média soit plusieurs médias (donc une playlist) ?

[Richard_35]

Les chiottes brillent de 1000 feu cette fois ...

==> il semble...

Mais :

la création des clés étrangères au bon endroit ;

==> 2 clés étrangères figurent dans la table associative, elles ne doivent donc pas figurer dans les tables liées à l'association (clés barrées) :



Le MCD (conceptuel, donc) :

Il n'y a pas plus simple pour modéliser cette histoire d'alarme qui est soit un média soit plusieurs médias (donc une playlist) ?

==> c'est modélisé par la contrainte X (indiquée par la flèche). Dans les faits, il faudra la gérer par un trigger (code).

[gromf]

Tudieu, j'en aurai appris des choses
Et très sérieusement, grand merci Richard !

Je "résolu" et post le résultat propre
(porté par l'élan de cet enthousiasme j'ai même rajouté aux user la possibilité de gérer leur médias !)

[Richard_35]

Donnant :

[gromf]

Donnant :

Encore merci, une dernière question, puis je ré utiliser ceci (image + citer ton pseudo) sur mon blog ?
(je compte faire une série d'articles, une sorte de grand tuto pour un projet raspberry pi + python)

[Richard_35]

Bonjour Gromf,

Pas de problème, tu peux utiliser tout ce que tu veux !