Discussion :

[Thomas_Dotnet]

Bonjour à tous,

Concernant la partie Modele Conceptuel de Données sur Merise, j'ai un problème à vous soumettre auquel je ne trouve pas de solution viable:

Soit les entités PISTE (chanson d'un d'un album), ARTISTE et SPECIALITE (auteur, compositeur, chanteur, producteur...)

Ci dessous, un diagramme contraignant l'artiste à n'intervenir sur une chanson qu'avec une seule spécialité. (La table associative aura pour clé primaire Id_Piste + Id_Specialite + Id_Artiste).


Comment représenter le fait qu'un artiste puisse intervenir dans une même chanson, avec une spécialité différente?
Par exemple: Lara Fabien est interprète de la chanson Je t'aime.
Lara Fabian est auteur de la Chanson Je t'aime.

Physiquement, il est facile de représenter ce modèle en liant une Table d'association (Specialite + Artiste) à la Table Piste

Voici la modélisation la plus proche que j'ai réussit à produire, cependant la modélisation me semble incorrecte car une entité doit avoir une clé primaire (même si dans ce cas, la clé primaire de ARTISTE_SPECIALITE est portée par les FK de Artiste et Spécialité)


Comment représenter ce cas?

[escartefigue]

Bonjour

Bonne nouvelle : vous n'avez rien à faire pour le mentionner

Si au contraire la règle était : "un artiste ne peut intervenir que pour une spécialité", alors, vous auriez du poser une contrainte d'intégrité fonctionnelle (CIF) matérialisée par une flèche en direction de l'entité type artiste.
Ensuite, dans le MPD, il aurait fallu supprimer l'identifiant SPECIALITE de la table résultante de l'association, de sorte a rendre le couple (PISTE, ARTISTE) unique, quelque soit la spécialité

Mais là, encore une fois, rien à changer

[Thomas_Dotnet]

Bonjour escartefigue et merci pour votre réponse.


Donc selon vous, la proposition que j'ai proposée pour répondre à cette contrainte est viable:

Il me semblait cependant qu'on ne modélisait jamais d'entités "Vides" (ce qui est le cas pour l'entité ARTISTE_SPECIALITE) mais si vous me confirmez que cette forme de modélisation est correcte j'en suis ravi!

[escartefigue]

Non je parlais du premier schéma avec la relation à 3 pattes

EDIT : j'argumente

Avec votre premier schéma, la table issue de la relation aura une PK avec 3 composantes id_artiste + id_specialite + id_piste
Donc rien n'interdit de changer d'id_spécialité sans changer d'artiste, votre PK restera unique

C'est bien la règle (qui n'est pas la votre) selon laquelle un artiste aurait une et une seule spécialité, qui nécessiterait une modification légère au niveau MCD (la flèche) mais cruciale au niveau des index (clef unique sur 2 colonnes seulement)

[JPhi33]

Bonjour,

Bonne nouvelle : vous n'avez rien à faire pour le mentionner

Je confirme ce que dit escartefigue.

En reprenant l'exemple de Lara Fabian, le premier schéma permet bien de créer les occurrences de l'association "Participer" nécessaires à ce cas :

Code :

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

1
2
3
4
Participer (Piste, Spécialité, Artiste)
-------------------------------------------------
Occurrence 1 : Je t'aime, Interprète, Lara Fabian
Occurrence 2 : Je t'aime, Auteur, Lara Fabian