Reflexion autour d'un MCD

Bonjour,

Dans le cadre d'un exo, je vizns vous soumettre un MCD qui m'est demandé pour développer ultérieurement un petit exemple de client lourd en java.

Grosso modo, il s'agit pour un particulier de pouvoir utiliser une appli qui permet de ranger et de trouver des oeuvres dans sa bibliothèque qui comporte plusieurs type d'oeuvre. Une oeuvre est définie par
- un titre
- une catégorie (film, jeu vidéo, album de musique...)
- une note de 0 à 5 étoiles
- Un support (cd, bluray, livre papier)
- une origine d'achat (librairie, magasin spécialisé, download)

Certaines catégories demandent des infos en plus. Par exemple un film va avoir besoin d'un réalisateur, d'un genre...Un jeu va avoir besoin d'un nbre de joueurs, i faut savoir si il est terminé...

Je précise que viens pas chercher une réponse tte faite, déjà je voudrais seulement savoir si je ne pars pas à côté de la plaque...
Voici un premier MCD

Merci !
Pièce jointe 526228

Bonsoir Olivier,


Manifestement vous utilisez une représentation à la Chen, donc avec inversion des cardinalités portées par les pattes d’association (voyez par exemple le diagramme produit par Chen lui-même). Sans cette précision, les concepteurs pourraient vous dire que vous vous êtes planté dans les cardinalités :P

Comme je vous l’ai déjà conseillé, vous devriez utiliser Looping qui est quand même un cran au-dessus (par exemple la modélisation des contraintes, de la généralisation/spécialisation, passage instantané au diagramme de classes UML, au MLD (pas encore graphique pour le moment) et au code SQL).


Quant à votre MCD :

Comment prenez-vous en compte le fait qu’on puisse avoir une oeuvre en plusieurs exemplaires (par exemple « Les trois mousquetaires », sur des supports différents ou non ? (Ainsi dans ma propre bibliothèque, j’ai des exemplaires (livres) en double, en triple, avec en plus la version électronique...)

Les supports font l’objet d’une entité-type SUPPORT, d’accord. Les origines quant à elles n’ont pas droit à ce régime ? Attention si Escartefigue passe par là ! :D

L’entité-type CARACTERISTIQUE est un fourre-tout façon big-mac, il n’est pas normal que pour la catégorie LIVRE, on ait à renseigner (même par du vide !) l’attribut NB-PLAYERS, etc. (on y trouve même deux fois l’attribut GENRE...). La spécialisation de l’entité-type CATEGORIE est à envisager (sous-types : LIVRE, FILM, ALBUM_MUSIQUE, JEU...)

A suivre.

 

Merci pour votre réponse,

C'est vrai que je n'ai pas utilisé looping, je vais regarder. En fait, l prof qui nous donne les cours de BDD/Merise/Sql nous interdit d'utiliser un logiciel qui fasse la conversion MCD vers le MLD.
Dernièrement j'ai eu le malheur d'utiliser DB-main (version d'évluation gratuite) et je me suis fait avoir car la conversion (MCD->MLD) est totalement fantaisiste. Mais du coup, je regarderai looping.

Pour le diagramme de Chen, je ne connais pas, et en regardant je ne comprends pas trop les cardinalités avec une seule notation, et que signifie "M" ? :oops:

Sinon en effet, je ne prends pas en compte le fait qu'une oeuvre soit dupliquée (si j'ai bien compris, avoir "les misérables" en 3 exemplaires, il faudra que je questionne mon prof à ce sujet). Mais j'ai essayé de tenir compte qu'une même oeuvre pouvait se retrouver en plusieurs formats.


Enfin vous avez raison, l'entité caractéristique est fourre-tout. Il faudrait d'autres entités en fonction des catégories je suppose. Merci pour votre aide
Olivier

Citation:

---

Envoyé par olivier252

le prof qui nous donne les cours de BDD/Merise/Sql nous interdit d'utiliser un logiciel qui fasse la conversion MCD vers le MLD

---

Il a raison, dans le sens où, tel le feignant moyen, vous ne chercheriez pas à dériver vous-même le MLD. Cela dit, vous pouvez utiliser un tel logiciel sans regarder le MLD produit, sinon après coup, histoire de vérifier que vous avez bien compris la méthode en comparant votre MLD à celui de l’AGL, et en expliquant les éventuelles différences...

Citation:

---

Envoyé par olivier252

Dernièrement j'ai eu le malheur d'utiliser DB-main (version d'évluation gratuite) et je me suis fait avoir car la conversion (MCD->MLD) est totalement fantaisiste. Mais du coup, je regarderai looping.

---

C’est sûr que si vous utilisez les cardinalités à la Chen :

[COMMANDE]----1,1----(R)----1,N----[LIGNE_COMMANDE]

Alors DB-MAIN vous suivra à la lettre, le résultat ne pourra être que fantaisiste, même chose pour Looping ! Le malheur sera sur vous...

Avec Merise, et ces AGL, les cardinalités sont dans le sens inverse de celui de Chen :

[COMMANDE]----1,N----(R)----1,1----[LIGNE_COMMANDE]

Et cette fois-ci, en respectant cette convention, ni DB-MAIN ni Looping ne vous paraîtront fantaisistes quant au MLD et au code SQL produits !

Citation:

---

Envoyé par olivier252

Pour le diagramme de Chen, je ne connais pas, et en regardant je ne comprends pas trop les cardinalités avec une seule notation, et que signifie "M" ?

---

"M" représente la cardinalité maximale : Chen n’a pas la notion de cardinalité minimale. Ainsi, "M" signifie "1,N" ou "0,N", à votre convenance...

Pour reprendre l’exemple des factures, avec Chen on écrit :

[COMMANDE]----1----(R)----M----[LIGNE_COMMANDE]

Ce qui ne manquera pas de faire sursauter les merisiens...:D

 

Citation:

---

Envoyé par fsmrel

Pour reprendre l’exemple des factures, avec Chen on écrit :

[COMMANDE]----1----(R)----M----[LIGNE_COMMANDE]

Ce qui ne manquera pas de faire sursauter les merisiens...:D 

---

Effectivement, en regardant les diagrammes de Chen (tout comme les diagrammes de classes UML), tel un cabri, je sursaute ! :mouarf:

Merci encore pour votre aide,

Du coup j'ai essayé de suivre le conseil que vous préconisez :

Citation:

---

La spécialisation de l’entité-type CATEGORIE est à envisager (sous-types : LIVRE, FILM, ALBUM_MUSIQUE, JEU...)

---

Ca m'a obligé a créer d'autres entités spécialisées chacunes dans chaque item de "categorie"; En fait je réalise que la difficulté pur moi est de concevoir la manière d'organiser les données de chaque catégorie.
Du coup, je me jette à nouveau dans la bataille avec ce nouveau MCD. Je finaliserai sur looping que j'ai commencé à utiliser (merci à Paprick pour ce partage gratuit).

Sinon, j'ai une dernière question, quand vous dites que j'écris les cardinalités à la façon d'un diagramme de Chen, est-ce négatif ? Y a-t-il une nomenclature particulière à respecter ?

Pièce jointe 526376

Bonsoir,

Sans dénigrer les diagrammes de Chen, deux formalismes dominent actuellement la modélisation de données : les schémas entité-association et les diagrammes de classes UML... ce qui ne les empêche pas de s'opposer concernant le sens des cardinalités ! :?
Personnellement, je considère que les schémas entité-association sont les plus adéquats pour réaliser des modèles conceptuels de données.

Concernant votre modèle, je n'ai pas vérifié dans le détail sa validité, mais voici quelques observations :
- Je pense tout d'abord qu'il y a une inversion de cardinalités entre "Œuvre" et "Origin"...
- Par ailleurs, la spécialisation peut être mise en œuvre avec une syntaxe spécifique, ce qui évite la classe "Catégorie" qui posait de toute façon problème...
- Enfin, le fait qu'il y ait plusieurs acteurs pour un film doit entrainer la définition d'une classe d'entités "Acteur".

Voici ce que cela pourrait donner avec Looping :
Pièce jointe 526419

Bonjour Paprick, bonjour à tous,

Il me semble que toutes les œuvres au sens large (livres, CD, films...) peuvent avoir plusieurs intervenants de même nature (par exemple plusieurs réalisateurs, plusieurs auteurs, plusieurs scénaristes...).

Du coup, plutôt que mettre en oeuvre une association "jouer" propre aux films, il me semble qu'une association plus générale comme "intervenir" ou "contribuer" mise en oeuvre avec l'entité-type "oeuvre" serait plus appropriée. Dans cette association qui devient ternaire, on ajoute un rôle pour préciser le ou les rôles exercés par la personne dans l'oeuvre (ex : auteur et compositeur).
Il faudra probablement ajouter un trigger pour contrôler la cohérence du rôle avec le type d'oeuvre.

Pièce jointe 526467

Les réponses sur ce fil ont dépassé mes espérances c'est pourquoi je remercie chaleureusement les contributeurs et à nouveau Paprick : il y a largement matière à avancer sur le sujet que je considère comme largement résolu !

Bien à tous et bonnes fêtes de fin d'année