Discussion :

[sbill]

Bonjour,

J'aimerai juste une confirmation que les choses sont bien faîtes en suivant cette logique (MCD):

Un membre peut posséder 0,N Images et une Images est posséder par un unique membre, soit :
(1)User (0,N) ----- [ posséder ] ----- (1, 1)Images

Un image peut être commenter par 0,N User, sois :
(2)User (0,N) ---- [ commenter ] ---- (0,N) Images

Le passage au MLD entre la table avec les commentaires me pose quelques problème :
(1)La table image prend une clé étrangère id_user qui pointe vers la table User.

(2)La relation créer une troisième table user_comment_img qui est consitutée de d'une clé primaire {id_user, id_images}, dont chaque id est une clé étrangère pointant vers les tables User et Image.
Cependant, ainsi un utilisateur ne pourra commenter qu'une seule fois une image (ce qui n'est pas le but), donc j'ai penser à modifier la clé primaire ainsi : {id_user_comment_img, id_user, id_images } OU {id_user} (pour les performances ?)
Cependant cela ne viole-t-il pas les "règles" du passage du MCD au MLD ?

Merci pour vos avis.

[fsmrel]

Bonsoir sbill,


Si vous voulez qu’un utilisateur puisse commenter plus d’une fois la même image, alors en Merise vous devrez modéliser quelque chose comme ceci :





L’entité-type FOIS donnera lieu à une table FOIS, mais n’offrant aucune espèce d’intérêt, au contraire. Il faudra donc : soit la supprimer manuellement, soit (cas de PowerAMC) demander à l’AGL de ne pas générer cette table :






Mais si vous utilisez DB-MAIN (gratuit), vous pouvez lui signifier que l’identifiant de l’association COMMENTER n’est pas la paire {UTILISATEUR, IMAGE}, mais le triplet {UTILISATEUR, IMAGE, Fois} dans lequel l’attribut Fois est lui aussi partie prenante, auquel cas le MLD produit sera identique au précédent, sans intervention de votre part :






Dans cette affaire, la performance n’est pas concernée, c’est le choix (au niveau physique, dans la soute) de l’index cluster (au sens DB2 ou PostgreSQL du terme, voire MySQL, etc.) qui interviendra.

[sbill]

Bonjour,

Merci pour votre réponse.
Cependant entre temps, j'ai trouver une solution qui règle mon problème, pourriez-vous me donner votre avis en la comparant avec votre dernière proposition svp.

User (0,N) ----- [ posséder ] ----- (1, 1)Images
User (0,N) ----- [ post ] ---- (1,1)Commentaire
Images (0,N) ---- [ a ] ---- (1,1) Commentaire

Au final l'entité Commentaire aura comme clé primaire id_commentaire et deux clé étrangères id_user & id_image.

Dans cette affaire, la performance n’est pas concernée, c’est le choix (au niveau physique, dans la soute) de l’index cluster (au sens DB2 ou PostgreSQL du terme, voire MySQL, etc.) qui interviendra.

Dois-je comprendre qu'il faut conçevoir le MCD sans penser au performance ?

Merci

[sbill]

Mais ou es passé Monsieur fsmrel ?

[fsmrel]

Bonsoir sbill,

Mais ou es passé Monsieur fsmrel ?

Il arrive à M. fsmrel d’avoir des obligations qui l’éloignent pendant une semaine...

Dois-je comprendre qu'il faut concevoir le MCD sans penser au performance ?

Quand on réalise un MCD on n’a pas à penser aux performances, parce qu’on modélise en se préoccupant seulement du quoi et pas du comment, parce qu’on établit une séparation radicale entre le logique et le physique (8e des 12 règles de Codd).

Cela dit, quand on a fini de modéliser, on bâtit un prototype pour mesurer les performances, disons celles des requêtes qu’on aura à mettre en oeuvre et jugées les plus sensibles. En cas de mauvaise performance, encore faut-il être capable d’en diagnostiquer les causes. Ainsi, l’exemple de la banque d'une ville méridionale où il fait bon vivre est significatif : fallait-il modifier la structure des tables et violer la troisième forme normale ? Réponse négative, alors que les responsables de la base de données étaient prêts à le faire...

Supposons que l’on adopte votre modélisation. Si votre prototype des performances met en évidence une performance médiocre de telle ou telle requête, il faudra voir ce que donne un aménagement de la structure, avec une clé primaire {id_user, id_commentaire}, ou {id_image, id_commentaire}, ou {{id_user, id_image, id_commentaire}, etc. Ou bien, si vous utilisiez DB2 vérifier s’il suffit de remplacer l’index cluster (id_image} par exemple par {id_user}, sans toucher à la structure de la clé primaire (c’est quelque chose qu’on peut faire avec DB2 mais par exemple pas avec MySQL, pour lequel index primaire = index cluster, avec vraisemblablement une conception différente de la notion d’index cluster, mais je connais mal MySQL).

Maintenant, il y a des précautions à prendre. Ainsi, il faut éviter de dériver l’entité-type COMPTEUR si elle est présente dans le MCD, car en SQL sa présence sous forme de table peut nuire aux performances (histoire vécue avec l’entité-type DATE devenue table).

[sbill]

Merci pour vos explications

Sujet résolu, bonne soirée