Discussion :

[Jéjé34]

Bonjour à tous,

Je dois et surtout souhaite, réaliser un site de sondages qui permet aux utilisateurs de classer les propositions d'un sondage, par ordre de préférence.

Voici le cahier des charges que je dois respecter:
- un utilisateur doit pouvoir fonder un groupe, créer un sondage et répondre a un sondage.
- il doit pouvoir voir l'ensemble des sondages auxquels il peut répondre, l'ensemble des sondages auxquels il a déja répondu et l'ensemble des groupes dans lesquels il est inscrit, ainsi que l'ensemble des groupes dans lesquels il peut s'inscrire.
- un groupe peut être public (tout les membres du site peuvent y entrer), ou privé (seul l'administrateur peut ajouter des membres). Les groupes privés peuvent être visible (tout le monde peut les voir et demander a y entrer) ou cachés (les groupes ne sont listés nul part).
- un sondage peut être public (tout le monde peut y répondre même sans être inscrit sur le site), réserve aux inscrits (seul les personnes ayant un compte sur le site peuvent y répondre), peut appartenir a un groupe (seul les utilisateurs du groupe peuvent y répondre), et peut être privé (seul les utilisateurs inscrit sur ce sondage peuvent y répondre).
- Lorsqu'un utilisateur crée un sondage, il en devient administrateur. Si le vote est prive, il peut ajouter des votants.
- Lorsqu'un utilisateur cree un groupe, il en devient administrateur. Si le groupe est prive, il peut ajouter des membres.
- Un utilisateur peut poster des commentaires sur un sondage

Suite à cela, j'ai donc réaliser mon tout premier MCD que voici :



J'aimerai avoir votre avis et vos conseils afin de partir sur de bonnes bases.
J'ai notamment un doute sur la gestion des accès publics/privés/etc. des sondages et des groupes, est-ce qu'un attribut suffit pour chacune des entités va suffire?

Merci beaucoup à ceux qui m'ont lu et pourront me conseiller.

[fsmrel]

Bonjour Jéjé34


En première approche, pour un premier MCD, c’est pas mal.


Il y a quelques remarques à faire, mais déjà, pour répondre à votre question « est-ce qu'un attribut suffit pour chacune des entités va suffire? »

Pour les accès aux sondages, on peut raisonner ainsi au niveau opérationnel (je bascule donc au niveau SQL et parle de tables plutôt que d’entités-types ) : supposons que l’on définisse une table virtuelle (vue) dérivée de la table SONDAGE, pour mettre en évidence les sondages privés :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE VIEW SONDAGE_PRIVE (idSondage, titre, descriptifSondage, datefin, dateCreationSondage)  
    AS SELECT idSondage, titre, descriptifSondage, datefin, dateCreationSondage
       FROM   SONDAGE
       WHERE  accesSondage = 'prive' ;

Son binôme pour les sondages publics :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE VIEW SONDAGE_PUBLIC (idSondage, titre, descriptifSondage, datefin, dateCreationSondage)  
    AS SELECT idSondage, titre, descriptifSondage, datefin, dateCreationSondage
       FROM   SONDAGE ;

C'est-à-dire qu’au niveau applicatif, vous utilisez ces vues quand il s’agit de montrer des données à l’utilisateur qui consulte.

Pour savoir si l’utilisateur de Pseudo 'Raoul' a le droit de consulter le sondage privé identifié par idSondage = 123456 :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT COUNT(*)
FROM   SONDAGE_PRIVE AS x JOIN EST_INSCRIT AS y ON x.IdSondage = y.IdSondage
                          JOIN UTILISATEUR AS z ON y.IdUtilisateur = z.IdUtilisateur
WHERE   pseudo = 'Raoul' AND x.IdSondage = 123456 ;

Vous me direz qu’on pourrait se dispenser des vues, mais au plan organisation ça pourrait vite devenir le foutoir.


Question : Qu’est-ce qu’une option ?

[Jéjé34]

Merci pour cette réponse !

Je ne connaissais pas la notion de tables virtuelles.
Donc si j'ai bien compris, l'idée d'un attribut qui gère les accès n'est pas si bête au final?
Si c'est pas géré de manière anarchique.

Une option est une proposition d'un sondage.
Par exemple pour le sondage "Dans quelle ville de la région voulez vous que la bibliothèque soit implémenté?" ?
Il va y avoir plusieurs options que l'utilisateur va classer par ordre de préférence: ville A, villeB, villeC etc.
Mais j'ai peur d'avoir un problème de redondance avec l'attribut dateClassement dans l'association "classe", mais je vois pas d'autres endroits pour le mettre.

[fsmrel]

Effectivement, la date de classement est redondante.

Avant de traiter de ce point, travaillons avec des exemples pour que j’y voie plus clair. Par exemple, le sondage S1 a été créé par l’utilisateur U1 :


SONDAGE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IdSondage, IdCreateur, ...
S1         U1          ...

Je suppose que c’est U1 qui définit les options pour le sondage S1. C’est bien cela ? Quoi qu’il en soit, pourriez-vous remplacer les "?" ci-dessous par les descriptifs qui vont bien ?


OPTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
idSondage, IdOption, descriptifOption
S1         O1        ?
S1         O2        ?
S1         O3        ?

[Jéjé34]

Tout à fait, c'est le créateur du sondage (U1 dans notre cas) qui définit les options du sondage.

Admettons S1 le sondage et O1, O2 et O3 ses 3 options :

"Dans quelle ville de la région voulez vous que la bibliothèque soit implémenté?" ?
Il va y avoir plusieurs options que l'utilisateur va classer par ordre de préférence: ville A, villeB, villeC etc.

On aurait ceci dans la table Option

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
idSondage, IdOption, descriptifOption
S1         O1        villeA
S1         O2        villeB
S1         O3        villeC

Avec le tuple suivant dans la table Sondage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IdSondage, IdCreateur, titre,                                 descriptifSondage           ...
S1         U1        Bibliothèque      Dans quelle ville de la région voulez vous que la bibliothèque soit implémenté?         ...

Suite à cela, un utilisateur U2 pourrait classer les options du sondage et on se retrouverait avec la table Classe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Idutilisateur, Idoption, ordre           ...
       U2        O1        3         ...
       U2        O2        1         ... 
       U2        O3        2         ...

[fsmrel]

Merci, j'y vois plus clair. La date de classement va changer d'hébergement.


Auparavant, une question complémentaire : un utilisateur qui effectue un classement doit-il d'abord être inscrit ?

[Jéjé34]

Merci, j'y vois plus clair. La date de classement va changer d'hébergement.

Merci à toi, surtout.
C'est bien ce que je pensais, mais par contre je vois pas où pour le moment.

Auparavant, une question complémentaire : un utilisateur qui effectue un classement doit-il d'abord être inscrit ?

Ça dépend, on a 4 cas :

* si le sondage est public alors tout le monde peut y répondre même sans être inscrit sur le site
* si le sondage est réservé aux inscrits alors seul les personnes ayant un compte sur le site peuvent y répondre
* si le sondage appartient a un groupe alors seul les utilisateurs du groupe peuvent y répondre
* si le sondage est privé alors seul les utilisateurs inscrit sur ce sondage peuvent y répondre.

Et je te cache pas, que j'ai un peu de mal a voir comment je vais gérer ça.

D’où ma question, est-ce qu'un attribut accesGroupe + une clé étrangère idGroupe dans Sondage vont me permettre de gérer tout ça?

[fsmrel]

Bonsoir Jégé34,


Je me suis remis à Open ModelSphere...

1) Au sujet des attributs accsSondage et accGroupe : il serait préférable de les dégager de SONDAGE et GROUPE, et de mettre en œuvre deux entités-types dédiées, nommées par exemple TYPE_ACCES_SONDAGE et TYPE_ACCES_GROUPE (bien entendu, vous remplacez les valeurs que j’ai fournies par les vôtres, je n’ai pas forcément tout capté). Exemple :


TYPE_ACCES_SONDAGE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
typeAccesSondageId     typeAccesSondageLibelle
                 1     Public
                 2     Réservé aux utilisateurs (personnes ayant un compte sur le site)
                 3     Privé (utilisateurs inscrits au sondage)
                 4     Réservé aux utilisateurs du groupe auquel le sondage fait référence

TYPE_ACCES_GROUPE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
typeAccesGroupeId     typeAccesGroupeLibelle
                1     Public
                2     Privé
                3     Caché

2) Ne pas oublier de recenser et mettre en évidence les identifiants « alternatifs » (ceux qui comme {pseudo} doivent respecter une contrainte d’unicité).


3) Dans votre MCD, la patte connectant l’entité-type SONDAGE et l’association « est inscrit » est porteuse d’une cardinalité 1,N : il serait préférable de la remplacer par 0,N. En effet, le créateur du sondage est inscrit de facto, et pour des raisons de redondance (la redondance est un ennemi redoutable...), il n’aura pas à figurer « en dur » dans la table SQL dérivée de l’association « est inscrit ». Pour constituer la liste des inscrits au sondage (y-compris le créateur du sondage « Votre opinion sur Open ModelSphere » , on utilisera une requête dont on parlera un peu plus tard (au fait, c’est pour un sondage ! quel est votre niveau de connaissance de SQL ?)


4) Au sujet de la date de classement :

Y a pas à tortiller, il faudrait établir une association, appelons-la REPONSE, entre l’entité-type OPTION et l’association CLASSE, afin qu'on puisse faire migrer la date de CLASSE vers REPONSE. Manque de chance, Merise ne permet pas qu’une association soit branchée sur une autre association : qu’à cela ne tienne, on va déguiser REPONSE en entité-type. Notons que cette entité-type, n’a pas à avoir d’identifiant en propre, on l’identifie relativement à UTILISATEUR et SONDAGE. Lors du passage au MLD, la table REPONSE aura la structure suivante (clé soulignée) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 REPONSE {idUtilisateur, idSondage, dateClassement} ;

Avec Open ModelSphere, pour signifier l’identification relative, on effectue un glisser-déposer du mickey sur les cardinalité 1,1 concernées. OMS les souligne, comme cela est montré dans le MCD ci-dessous :




On reparlera bien sûr du contrôle de l’accès aux sondages et aux groupes.

[Jéjé34]

Merci pour le temps passé sur cette réponse!

1) Ok pour des entités plutôt que des attributs.
Par contre, je ne pense pas que ça va permettre de gérer ce cas là.

Si le sondage appartient a un groupe alors seul les utilisateurs du groupe peuvent y répondre.

En fait, les groupes vont pouvoir contenir des sondages (exactement comme des groupes contiennent des utilisateurs).
Et si un sondage appartient a un groupe alors seuls les utilisateurs inscrits dans ce groupe pourront y répondre.
Dans ce cas, le type d'accès n'a plus d'importance.
C'est pour cela que j'avais une association "appartient" entre Sondage et Groupe.

2) J'en ai repéré seulement 2 autres : email et nomGroupe

3) D'accord, je comprends!
Pour répondre a ta question, je pense maitriser les bases en SQL, suffisante pour faire le site: jointures, sous-requêtes, regroupement, insertion/modification de données etc.

4) Je connaissais pas ce concept d'identification relative et je n'y aurai donc jamais pensé.
Mais je pense l'avoir compris alors si c'est la meilleure solution, allons y!

[fsmrel]

Bonsoir Jégé34,


J’ai rafraîchi le MCD que j’avais proposé, car il y avait des cardinalités à la Dagobert et l’association APPARTIENT entre SONDAGE et GROUPE était passée à la trappe. Quoi qu’il en soit, il y a une redondance, car si un sondage est associé à un groupe, l’attribut typeAccesSondageId doit prendre la valeur 4. Même chose si on se cantonne à n’avoir que l’attribut accesSondage (cf. votre table SONDAGE initiale). Comme la redondance n’est pas l’amie des bases de données, on va essayer autre chose : la spécialisation des sondages, d’où le MCD qui suit :



Un sondage est soit public (entité-type SONDAGE_PUBLIC), soit accessible seulement aux utilisateurs du site (SONDAGE_UTILISATEUR), soit accessible seulement aux utilisateurs inscrits (SONDAGE_INSCRIT), soit accessible seulement aux utilisateurs faisant partie du groupe (SONDAGE_GROUPE, qui remplace ‘association APPARTIENT).

Affaire à suivre...

[Jéjé34]

Parfait, je pense que ça va me permettre de respecter mon cahier des charges.

Quel est la prochaine étape?
Je dois passer au schéma relationnel, c'est ça?

[fsmrel]

Bonjour,


Allons-y pour passer du MCD au MLD (Modèle logique des données). Avec OMS ça n’est pas complètement automatisé, allez savoir pourquoi...

Bon courage, donc !

[Jéjé34]

Ok merci, je vais m'y mettre.

Juste, comment se passe la transformation au niveau de la spécialisation, stp?

Edit: je n'arrive pas non plus a crée de clé étrangère avec OMSphere (je suis bien passé en MLD pourtant)

[fsmrel]

Bonsoir Jégé34,


Remarques préalables :

— Dans mon MCD précédent, j’ai omis d’identifier OPTION relativement à SONDAGE (on verra que cela servira à résoudre un problème de contrainte de chemin) ;

— En outre, la cardinalité portée par la patte connectant REPONSE et CLASSEMENT doit être 1,N. J'ai rafraîchi l'image.

Pour en venir au MLD :

Avez-vous procédé à la vérification de votre MCD ?

Outils > Modèle de données > Vérifier l’intégrité

Si la vérification a été satisfaite, vous devez arriver à produire un MLD tel que celui-ci (encore incomplet quant aux clés, OMS complétera de lui-même lors de la génération des clés étrangères) :




Suite à génération des clés étrangères, le MLD prend l'allure suivante :




OMS s’est planté, il a oublié dans le diagramme la clé étrangère qui est portée par la table SONDAGE et faisant référence à la table UTILISATEUR (contrairement à ce qu’annonce l’explorateur, qui arrive pour sa part à déclarer une clé étrangère caractéristique d’une association réflexive branchée sur la table SONDAGE, c’est du grand n’importe quoi...) Par ailleurs, il crée un attribut idSondage en trop pour les tables INSCRIT_S et INSCRIT_G..., j’en passe et des meilleures.


Note sur les contraintes de chemin :

On peut « naviguer » de SONDAGE à CLASSEMENT via deux chemins :

a) En passant par REPONSE,

b) En passant par OPTION.

En conséquence, OMS génère — à juste titre cette fois-ci ! — deux attributs idSondage pour la table CLASSEMENT. Mais dans notre cas, il n’ y a qu’un seul sondage impliqué, on supprimera donc un des deux attributs, ce qui résoudra le problème de la contrainte de chemin.


Il serait préférable de renommer les attributs inutilement préfixés par le nom de la table source.

Attention, « OPTION » est un mot réservé en SQL, il faut renommer la table OPTION (pour ma part, j’ai utilisé « CHOIX » comme nom, voyez le diagramme MWB).

Par ailleurs, il faudra demander à OMS de produire les triggers de mise à jour pour les insertions, modifications et suppressions.

Ceci fait, il faudra lui demander de vérifier l’intégrité du MLD :

Outils > Modèle de données > Vérifier l’intégrité

Quand il n’y aura plus d’erreurs, on pourra demander la génération de la structure SQL de la base de données :

Outils > Base de données > Génération

Puis il faudra demander la vérification de cette structure et ça n’est pas gagné....

Et pour finir, les bugs du MLD en engendrent d’autres lors de la production du code SQL qui devient inexploitable...

C’est le parcours du combattant...


Moralité : je passe à MySQL Workbench pour créer ex nihilo un MLD et le code SQL correspondant, sinon on y est encore pour quelques jours...(A cette occasion e vous renvoie à l’article dont je me suis fendu qui est un mode d’emploi...)

L’organisation des objets dans le plan diffère, mais MWB refuse qu’on l’aide à « tirer » les liens entre tables, il faut donc ruser...





A votre tour...

[Jéjé34]

Bonjour,

Avant toute chose,
- j'ai rajouté 2 attributs: dateEntree (d'un utilisateur dans un groupe) et dateInscriptionSondage (d'un utilisateur pour un sondage)
- pour Option, j'avais remarqué également que c'était réservé et je l'ai de mon coté renommé Proposition

Voici donc mon Modelè Conceptuel de Données :



Je ne suis pas parvenu a souligner les cardinalités pour exprimer l'identification relative, comment as tu fais?

Et mon Modèle Logique des Données sous MWB (je ne savais pas que les cardinalités s'inversaient lors de la transformation)
Et merci pour l'article, très bien écrit.




J'ai généré le code SQL associé : creation.sql

Est-ce que je peux affirmer que la modélisation est terminé et commencer à coder, ou bien il reste une étape?

[fsmrel]

Bonsoir Jégé34,

Je ne suis pas parvenu à souligner les cardinalités pour exprimer l'identification relative, comment as tu fais?

La réponse est ici :

Avec Open ModelSphere, pour signifier l’identification relative, on effectue un glisser-déposer du mickey sur les cardinalité 1,1 concernées.

Question : quelle est la finalité de l’association entre GROUPE et INSCRIT_S ?


Ordre des attributs dans les clés : au stade du MLD, l’en-tête d’une table est un ensemble (au sens de la théorie des ensembles), autrement dit, que l’en-tête de la table PROPOSITION soit le celui-ci :

{idProposition, idSondage}

Ou celui-là :

{idSondage, idProposition}

Peu importe, on peut suivre Monsieur Jourdain : « D’amour mourir me font, belle Marquise, vos beaux yeux »...

Mais au stade SQL, changement de chanson, la performance des requêtes varie selon l’ordre des clés dans les index impliqués par les clés des tables (primaires, alternatives, étrangères). Si vous effectuez une jointure des tables SONDAGE et PROPOSITION, vous pénaliserez la performance si pour la table PROPOSITION vous retenez la clé {idProposition, idSondage}.

En ce qui concerne la table CLASSEMENT, un dilemme se pose : l’attribut idUtilisateur doit-il figurer en tête ou non de la clé de la table ? Bien sûr, vous aurez un index de clé {idUtilisateur} ou {idUtilisateur, idSondage} ou {idUtilisateur, idSondage, idProposition} ainsi qu’un index de clé {idSondage, idProposition} ou {idSondage, idProposition, idUtilisateur}, mais on est alors confronté à la recherche des requêtes les plus sensibles, les plus fréquentes, ce qui influe sur le choix de l’ordre des attributs dans les clés, et on est alors aux prises avec le délicat mais décisif travail de prototypage des performances, du ressort du DBA.

Table COMMENTAIRE : j’avais oublié son existence. Question : l’utilisateur U1 peut-il participer plus d’une fois au sondage S1 ? La suppression d’un utilisateur entraîne-t-elle la suppression de ses commentaires ? (Ou au contraire, est-il interdit de supprimer un utilisateur tant qu’il a des commentaires ?) Même question concernant la relation entre les sondages et les commentaires.


Pour suivre avec le code SQL :


A propos du métabolisme de la base de données (qui n’est pas qu’anatomie...)

CASCADE vs NO CASCADE (NO ACTION, RESTRICT) : quand on modélise proprement, il s’ensuit qu’on n’a pas à modifier une clé primaire, en conséquence de quoi on code « ON UPDATE NO ACTION ». Pour les suppressions de lignes, on doit se poser la question : la suppression d’une ligne d’une table référencée entraîne-t-elle la suppression des lignes correspondantes dans les tables référençantes ? Il est évident que si on cherche à supprimer un client, cela ne doit pas être possible tant qu’il a des factures qui courent. Il est évident que si on cherche à supprimer une ligne de la table ACCES_GROUPE, cela n’est pas possible tant qu’au moins un groupe y fait référence. En revanche, un sondage est un sondage et si on cherche à supprimer un sondage de la table SONDAGE, la spécialisation concernée ne peut pas s’y opposer (table SONDAGE_PUBLIC, ou SONDAGE_UTILISATEUR, ou SONDAGE_INSCRIT, ou SONDAGE_GROUPE), d’où l’on retient CASCADE. Même chose pour une proposition qui n’est jamais qu’un élément appartenant à un sondage. Bien sûr, si la suppression d’une ligne « maman » entraîne celle des lignes « filles », l’opération échouera si une ligne « petite-fille » et au-delà (transitivité) reçoit le stimulus mais s’y oppose. Pour le reste, comme dirait Laspalès à Chevallier : « C’est vous qui voyez »... (Par exemple, qu’advient-il des groupes créés par un utilisateur qu’on souhaite supprimer ?)


Une erreur dans le code SQL (table CLASSEMENT) : la clé étrangère ci-dessous n’est pas complète, elle doit faire référence à la clé primaire complète de la table REPONSE :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CONSTRAINT fk_CLASSE_REPONSE1
  FOREIGN KEY (idUtilisateur)
  REFERENCES REPONSE (idUtilisateur)

La table GROUPE contient une erreur analogue.


Remarque concernant l’inversion des cardinalités :

En Merise, on considère qu’un utilisateur peut participer N fois à l’association CREE_SONDAGE, tandis qu’un sondage donné n’y participe qu’une fois. L’ovale symbolisant l’association empêche de voir ce qui se passe de l’autre côté. Dans le contexte de la notation UML, on joue les passe-muraille puisqu’il n’y a pas d’ovale pour arrêter la lecture. En partant de l’entité-type UTILISATEUR, le N se balade le long du lien et s’écrase contre le mur SONDAGE que, cette fois-ci, il ne peut pas traverser.

[Jéjé34]

Bonjour,

Avec Open ModelSphere, pour signifier l’identification relative, on effectue un glisser-déposer du mickey sur les cardinalité 1,1 concernées.

Oups, j'avais pas vu. Merci, j'ai mis à jour mon MCD dans mon précédent message, j'espère n'avoir rien oublié.

Question : quelle est la finalité de l’association entre GROUPE et INSCRIT_S ?

Aucune. Je me suis embrouillé, merci de l'avoir remarqué! Mis à jour dans le message précedentnt, également


Pour ce qui est de l'ordre des clès, je suis pas sur d'avoir tout compris, ni d'avoir les notions nécessaires pour comprendre.
Mais je pense pas que ce soit dramatique à mon échelle, je me trompe?
Au moins, j'ai compris qu'il faut que je prenne {idSondage, idProposition} pour l'entité type Proposition.

Table COMMENTAIRE : j’avais oublié son existence. Question : l’utilisateur U1 peut-il participer plus d’une fois au sondage S1 ?

Quand tu dis "participer", tu veux dire voter au Sondage ou commenter le Sondage?
Dans le doute, je vais répondre au deux :
- un utilisateur peut voter qu'une fois sur un Sondage
- un utilisateur peut commenter plusieurs fois un Sondage

La suppression d’un utilisateur entraîne-t-elle la suppression de ses commentaires ? (Ou au contraire, est-il interdit de supprimer un utilisateur tant qu’il a des commentaires ?) Même question concernant la relation entre les sondages et les commentaires.

Oui, la suppression d'un utilisateur entraine la suppression de ses commentaires.
Et la suppression d'un sondage entraine également la suppression des commentaires liés.


Je viens de remarquer également que l'attribut ordre de ma relation Classement dont on avait parlé plus haut avait sauté dans notre modélisation

Pour résumé,
Soit U1 et U2 des utilisateurs et S1 un sondage et P1, P2, P3 ses 3 propositions.

Je suis censé avoir une table Classement comme ceci, non?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Idutilisateur, IdProposition, IdSondage, ordre 
       U1        P1         S1          1
       U1        P2         S1          2
       U1        P3         S1          3
       U2        P1         S1          1
       U2        P2         S1          3
       U2        P3         S1          2

Et je souhaite également déterminer la proposition qui a le plus de voix avec le systeme suivant (méthode Borda)
Si la proposition est classé en premiere position par un utilisateur alors elle gagne n points
Si la proposition est classé en deuxieme position par un utilisateur alors elle gagne n-1
Si la proposition est classé en dernière position par un utilisateur alors elle gagne 1 point
Puis on fait le total.

Dans notre exemple :
Nombre de points de P1 : 3 + 3 = 6 points
P2: 2 + 1 points
P3: 1 + 2 points

Est ce que je dois modéliser et stocker tout ça?
Ou bien faire le calcul lors de l'affichage est suffisant?

[fsmrel]

Bonsoir Jégé34,

Pour ce qui est de l'ordre des clés, je ne suis pas sûr d'avoir tout compris, ni d'avoir les notions nécessaires pour comprendre.
Mais je ne pense pas que ce soit dramatique à mon échelle, je me trompe?

A votre échelle, tout dépend de la volumétrie qui sera celle des tables. Si vous avez 10 minutes, vous pouvez lire ce que j’ai écrit ici à propos de ce que l’on appelle le clustering.

Voyez encore la discussion où l’on s’intéresse à la vachette Zaza, avec des dessins un peu plus loin...
Zaza fait son retour ici et là...

Si ça reste confus, dites-le, j’essaierai alors de trouver un moment pour vous donner les bases qui vont bien sur le sujet, lequel n’est pas à négliger quand la performance est en jeu.

Dans le doute, je vais répondre au deux :
- un utilisateur peut voter qu'une fois sur un Sondage
- un utilisateur peut commenter plusieurs fois un Sondage

De fait, le verbe « participer » était ambigu, je pensais à « commenter ». Pour les raisons de performance (et même pour des raisons sémantiques, puisqu’un commentaire n’est pas autonome, son existence dépend de celle d’une paire {utilisateur, sondage}), je propose la modélisation suivante (correspondant en Merise à l’identification de COMMENTAIRE relativement à UTILISATEUR et SONDAGE) :

la suppression d'un utilisateur entraîne la suppression de ses commentaires.
Et la suppression d'un sondage entraîne également la suppression des commentaires liés.

D’accord. L’option à retenir sera donc CASCADE des deux côtés pour les suppressions :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE COMMENTAIRE (
   ...
  CONSTRAINT fk_COMMENTAIRE_UTILISATEUR FOREIGN KEY (idAuteur)
    REFERENCES UTILISATEUR
    ON DELETE NO CASCADE
    ON UPDATE NO ACTION,
  CONSTRAINT fk_COMMENTAIRE_SONDAGE1
    FOREIGN KEY (idSondage)
    REFERENCES SONDAGE (idSondage)
    ON DELETE NO CASCADE
    ON UPDATE NO ACTION)
   ...

A propos des classements

je suis censé avoir une table Classement comme ceci, non?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Idutilisateur, IdProposition, IdSondage, ordre 
       U1             P1         S1          1
       U1             P2         S1          2
       U1             P3         S1          3
       U2             P1         S1          1
       U2             P2         S1          3
       U2             P3         S1          2

Cette table a une très bonne tête, c'est bien ce qu'on attend.

Est-ce que je dois modéliser et stocker tout ça?
Ou bien faire le calcul lors de l'affichage est suffisant?

Comme en stockant on aurait de la redondance (l’ennemie des bases de données, comme vous le savez), le calcul lors de l’affichage suffira.


N.B. Certes, ce ne sont pas les municipales^^, mais on ne vote plus ?

[Jéjé34]

Au niveau de la modélisation,
J'ai mis à jour mon MCD et mon MLD ci dessus en rajoutant
- l'attribut ordre dans classement
- l'identification relative entre Utilisateur-Commentaire et Commentaire-Sondage
Normalement, si j'ai rien oublié, ça devrait être les schémas définitifs.



Pour ce que est du code SQL,
Je me suis penché sur ce que tu m'as dit et il s'avère que j'ai beaucoup de CASCADE finalement, puisque je souhaite que:

[SONDAGE] Quand on supprime un utilisateur, on supprime les sondages qu'il a crée

[COMMENTAIRE]
Quand on supprime un utilisateur, on supprime ses commentaires.
Quand on supprime un sondage, on supprime les commentaires également

[PROPOSITION]
Quand on supprime un sondage, on supprime les propositions (c'est presque trivial)

[REPONSE]
Quand on supprime un utilisateur, on supprime ses réponses a un sondage
Quand on supprime un sondage, on supprime les réponses qui ont eu lieu dessus

[CLASSEMENT]
Quand on supprime une proposition, on supprime les "classements" qui ont eu lieu dessus
Quand on supprime une réponse, on supprime les "classements"

[GROUPE]
Quand on supprime un utilisateur, on supprime les groupes qu'il a crée

[INSCRIT_S]
Quand on supprime un utilisateur, il n'est plus inscrit a aucun sondage

[INSCRIT_G]
Quand on supprime un utilisateur, il n'est plus inscrit a aucun groupe

En revanche,

[SONDAGE_GROUPE]
Quand on supprime un groupe, on ne veut pas que les sondages qui étaient dedans soit supprimés donc NO ACTION

Est ce que j'ai bien compris?



J'ai joint le fichier SQL, j'ai corrigé ça:

Une erreur dans le code SQL (table CLASSEMENT) : la clé étrangère ci-dessous n’est pas complète, elle doit faire référence à la clé primaire complète de la table REPONSE.

Par contre, je ne vois pas celle ceci:

La table GROUPE contient une erreur analogue.

idAccesGroupe fait référence a son homonyme de ACCES_GROUPE
idFondateur fait référense a idUtilisateur de UTILISATEUR
Quel est le problème?



Le site n'a pas pour vocation d'être diffusé, je le fais surtout pour mettre en pratique les bases que j'ai en BD et PHP donc pour le moment, je vais pas m'attarder sur la performance (même si j'ai conscience que ça puisse fait grincer des dents un professionnel comme toi ^^). Merci pour les liens, je garde tout ça à l'esprit et je m'y concentrerai dessus un jour ou l'autre.


Edit : MySQL me crie dessus il arrive a la ligne suivante (dans la table COMMENTAIRE)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PRIMARY KEY (`idAuteur`, `idSondage`, `idCommentaire`)

Avec le message d'erreur suivant :

#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

Pourquoi tant de haine?

[fsmrel]

Bonsoir Jégé34,


On est dans la ligne droite...

Pourquoi tant de haine ?

MySQL a raison ^^, pour le calmer il faut virer « AUTO_INCREMENT » des tables COMMENTAIRE et PROPOSITION (c’est une scorie des définitions d’origine des clés de ces tables). Pour mettre en œuvre l’identification relative, je vous renvoie au billet de CinePhil qui traite de cela.


Table CLASSEMENT : permuter l’ordre des attributs de la clé étrangère fk_CLASSE_PROPOSITION1 (ainsi que dans la clause REFERENCES), en effet cette clé étrangère fait référence à la table PROPOSITION dont la clé primaire est {idSondage, idProposition}.

Table GROUPE : renommer la colonne ACCES_GROUPE_idAccesGroupe en idAccesGroupe ; renommer la colonne UTILISATEUR_idUtilisateur en idFondateur. En faire autant pour les index.

Table SONDAGE_GROUPE : remplacer ON DELETE ACTION par ON DELETE CASCADE.


A propos de la mise à jour des modèles : normalement, dans le MLD faire passer IdSondage devant idProposition (tables PROPOSITION et CLASSEMENT ; je rappelle qu’une proposition est une propriété multivaluée d’un sondage). Dans le code SQL, c'est déjà fait pour la table PROPOSITION.

[SONDAGE_GROUPE]
Quand on supprime un groupe, on ne veut pas que les sondages qui étaient dedans soient supprimés donc NO ACTION

Est ce que j'ai bien compris?

Oui, en notant bien que si la table SONDAGE_GROUPE reçoit un stimulus de suppression concernant le groupe G1 et si G1 y est représenté, alors la tentative suppression dans SONDAGE_GROUPE du groupe G1 échoue. Observez encore que, si on cherche à supprimer l’utilisateur U1 qui a créé le groupe G1, alors la suppression de G1 devant échouer, une tentative de suppression de U1 échouera elle aussi, même chose pour ce qui lui est accroché : les sondages qu’il aura créés, etc. Si vous voulez que ses sondages, etc. disparaissent, il faudra agir table par table et au besoin supprimer « logiquement » (mise en place d’un attribut ad-hoc) U1 : c’est de la cuisine, mais bon...

je vais pas m'attarder sur la performance (même si j'ai conscience que ça puisse fait grincer des dents un professionnel comme toi ^^)

Ce sont plutôt les marchands de CPU, de mémoire et de disques qui grinceraient des dents...