Discussion :

[balooooooo]

Hello,

Je suis en train de réaliser un site de VOD et j'ai le MCD suivant (désolé sur papier avant de le construire sous logiciel).

- Un utilisateur fait partie d'un groupe
- Il peut ensuite "commenter", "noter" et "mettre en favoris" des vidéos
- Une vidéo a "un genre" et des "acteurs"

Pouvez m'aider en m'indiquant s'il y a des erreurs ou incohérences?

Merci d'avance

[seabs]

Bonjour,

Tu auras des avis plus avertis que le mien, mais déjà, il est d'usage de mettre le nom des entités au singulier VILLE, GROUPE, etc. Exemple, un utilisateur compose un groupe et un groupe est composé de 0 ou n utilisateur.

L'association entre UTILISATEUR et NOTE limite le nombre maximum de notes par utilisateur à 1. C'est-à-dire qu'il ne peut faire qu'une note pour toutes les vidéos. Cette cardinalité est plutôt 0:n que 0:1.

Même remarque pour l'association UTILISATEUR et FAVORI

Les cardinalités pour ces deux entités

UTILISATEUR --0:n -- affecter --1:1 -- NOTE
UTILISATEUR --0:n -- mettre --1:1 -- FAVORI

Il serait certainement plus efficace d’utiliser l'identifiant relatif pour l'entité NOTE.

NOTE --(1:1)-- attribuer -- 0:n -- VIDEO

J'ai cru comprendre qu'une vidéo ne peut avoir qu'un seul genre. Si c'est exact, nous devons avoir

VIDEO --1:1-- est de --1:n -- GENRE

Pour l'entité ACTEUR, il serait préférable de faire
ACTEUR --0:n --jouer --0:n VIDEO

Ainsi, il est possible d'enregistrer un acteur qui n'a pas encore joué dans une vidéo. De plus, avec ta cardinalité, l'acteur qui n'aura plus de vidéo devra être supprimé de l'entité ACTEUR

Voilà mes quelques remarques.

A+

[balooooooo]

Bonjour,

Merci beaucoup de ta réponse!

J'ai refait mon MCD sous PowerAMC histoire que ce soit plus propre.

J'ai bien pris en compte tes remarques, cependant je ne comprends pas trop ce passage:

Il serait certainement plus efficace d’utiliser l'identifiant relatif pour l'entité NOTE.

NOTE --(1:1)-- attribuer -- 0:n -- VIDEO

J'ai également un doute pour la table VILLE comme je met aussi un attibut "ville" dans UTILISATEUR ?!

Dernière question:

Est ce que je peux utiliser plusieurs fois l'attribut "nom" ou je suis obligé de mettre de l'unicité du genre "nom_groupe", "nom_user", "nom_video"

Merci d'avance.

[seabs]

Bonjour,

J'ai bien pris en compte tes remarques, cependant je ne comprends pas trop ce passage:

Citation:
Il serait certainement plus efficace d’utiliser l'identifiant relatif pour l'entité NOTE.

NOTE --(1:1)-- attribuer -- 0:n -- VIDEO

Je considère que l'entité NOTE est une entité faible car elle dépend de l'entité VIDEO. Une vidéo ne possède qu'une seule note par utilisateur. Il est peut être préférable que la clé primaire de l'entité NOTE soit composée de l'identifiant de l'utilisateur et de l'identifiant de la vidéo. Maintenant, il ne s'agit que d'une suggestion, mais pas d'une obligation.

Pour plus de détail, va lire ce sujet http://fsmrel.developpez.com/basesre...n/?page=1#L1.7 sur l'identification relative.

J'ai également un doute pour la table VILLE comme je met aussi un attibut "ville" dans UTILISATEUR ?!

Maintenir l'entité VILLE est préférable, mais supprimes l'attribut Ville dans l'entité UTILISATEUR. Le fait de créer une entité VILLE évite de voir des orthographes différentes pour une même ville. Exemple St Etienne, Saint-Etienne, Saint Etienne, plus les minuscules et majuscules différentes en début de nom.

Est ce que je peux utiliser plusieurs fois l'attribut "nom" ou je suis obligé de mettre de l'unicité du genre "nom_groupe", "nom_user", "nom_video"

J'opterais pour le nom unique de chaque attribut, mais sans être affirmatif dans ma réponse. Cependant, PowerAMC permet les deux options. Personnellement, je préfixe mes attributs de chaque entité par le nom complet ou partiel de l'entité. Exemple pour UTILISATEUR, je fais Utilis_Pseudo, Utilis_Nom et idem pour les autres entités. Bien ou mal, j'utilise cette approche.

Il existe peut être des améliorations complémentaires possibles, mais cela est au-delà de mes compétences

Bon courage et A+

Edit : Une vidéo peut comporter 0 à plusieurs favoris pour un même utilisateur. Nous ne sommes pas dans le même schéma que pour l'entité NOTE ?

[balooooooo]

Encore une fois merci de ta réponse

Je vais aller regarder le lien merci

Pour ce qui ai des favoris:

- Un utilisateur peut mettre 0 à n vidéos dans ses favoris
- Un utilisateur peut noter 1 fois 0 à n vidéos

[seabs]

Bonjour,

Pour ce qui ai des favoris:

- Un utilisateur peut mettre 0 à n vidéos dans ses favoris
- Un utilisateur peut noter 1 fois 0 à n vidéos

Compte tenu de tes explications, je pense qu'il faut mettre

VIDEO -- 0:n -- est mis --1:1 -- FAVORI
UTILISATEUR -- 0:n -- mettre -- 1:1 FAVORI

Ainsi, l'utilisateur pourra avoir un nombre illimité de favoris, mais seulement un lien pour chaque vidéo. Je ne vois aucune raison pour qu'un utilisateur fasse la création de plusieurs favoris pour atteindre une vidéo.

En éditant ton MLD ou MPD, tu verras si ton approche est la bonne ou s'il vaut mieux retenir ma solution

A+

[balooooooo]

Merci encore des tes précieux conseils!

J'ai généré le MLD et MPD et je n'ai pas eu d'erreurs.

J'ai re-posté le MCD modifié, cependant j'ai des doutes sur les relations:
- est attribué
- compose
- est mit

J'ai pu lire sur le forum qu'on pouvez utiliser une ternaire, mais je ne sais pas trop comment ça fonctionne.

Si jamais tu as des idées, je te remercie encore d'avance

[seabs]

Bonjour,

Après un dernier coup d’œil, il me semble que la cardinalité COMMENTAIRE et UTILISATEUR doit être
COMMENTAIRE --1:1-- Rediger -- 0:n-- UTILISATEUR.

Après cette rectification, ton MCD me paraît satisfaisant. Mais, il est possible que d'autres intervenants trouvent des modifications à apporter.

Il ne nécessite aucune ternaire. En général, il convient d'utiliser une relation ternaire uniquement quand il est impossible de traiter avec une relation binaire.

Tu trouveras des explications dans le document situé à cette adresse http://fdigallo.online.fr/cours/merise.pdf

A+

[JPhi33]

Bonjour à vous deux,

J'interviens pour donner mon avis sur un point particulier.

Il est peut être préférable que la clé primaire de l'entité NOTE soit composée de l'identifiant de l'utilisateur et de l'identifiant de la vidéo.

Ceci est la définition d'une association. La modélisation serait donc :

[ UTILISATEUR ]--0,n---( NOTE )----0,n--[ VIDEO ]

A condition que l'utilisateur ne puisse attribuer qu'une seule note par vidéo (ce qui suppose qu'il s'agit d'un système de notation du type scolaire sur 20, ou de 1 à 5 étoiles, par exemple). Et cela semble être le cas puisque :

- Un utilisateur peut noter 1 fois 0 à n vidéos

Le même principe est à retenir pour FAVORI :

[ UTILISATEUR ]--0,n---( FAVORI )----0,n--[ VIDEO ]

En conclusion, si l'on retient ces modélisations :
- NOTE et FAVORI ne sont pas des entités mais des associations
- on élimine 2 propriétés parasites que sont id_note et id_favori ce qui permet de réduire le "bruit" du MCD (objet de modélisation inutiles qui encombrent un MCD pour rien et n'ont pas de plus-value)

[dba01]

[ UTILISATEUR ]--0,n---( NOTE )----0,n--[ VIDEO ]
A condition que l'utilisateur ne puisse attribuer qu'une seule note par vidéo


C'est compatible, ça ?

[JPhi33]

C'est compatible, ça ?

Expliquez-vous ! Compatible avec quoi ?

[dba01]

Je voulais dire : voir "0,n" sur une ligne et "qu'une seule note" sur l'autre, j'ai du mal à me représenter la mécanique du truc. C'est seulement une impression.

[JPhi33]

voir "0,n" sur une ligne et "qu'une seule note" sur l'autre

L'expression complète est "qu'une seule note par vidéo". Cette restriction est la conséquence de la définition même d'une association !

NOTE est une association entre UTILISATEUR et VIDEO :
- un utilisateur peut noter plusieurs vidéos (0,n côté UTILISATEUR)
- une vidéo peut être notée par plusieurs utilisateurs (0,n côté VIDEO)
mais un même utilisateur ne peut pas noter plusieurs fois une même vidéo.

En effet, NOTE étant une association, chacune de ses occurrences est identifiée par un couple unique (utilisateur, vidéo). Pour qu'un utilisateur puisse noter plusieurs fois une même vidéo, il faudrait que NOTE contienne plusieurs fois le même couple (utilisateur, vidéo) or ceci est contraire à la nature d'une association.


Si, dans la réalité, un utilisateur pouvait noter plusieurs fois une vidéo, la modélisation correspondante ne pourrait pas être une association entre UTILISATEUR et VIDEO. Ici ce n'est pas le cas puisque :

- Un utilisateur peut noter 1 fois 0 à n vidéos

[dba01]

OK, je vois le truc.
Merci.

.db.