Discussion :

[vmolines]

Bonjour à tous,

aujourd'hui j'ai une question qui m'a semblé simple et sur laquelle je cale lamentablement.

J'ai 2 entités Film (Titre, date de sortie) et Acteur (Nom, prénom, date naissance). Les films et les acteurs ont des Commentaires (Date, pseudo auteur, commentaire).

Commentaire est une entité faible dans la mesure où le commentaire d'un film n'existe pas sans son film et même chose pour les commentaires sur les acteurs. Corolaire, un commentaire ne peut pas être rattaché à la fois à un Film et un Acteur.

Pour passer au modèle logique, j'hésite entre :

1)
FILM = {Film_Id, Film_Titre, Film_DateSortie}
ACTEUR = {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
COMMENTAIRE = {Comm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
FILM_COMMENTAIRE = {#Film_Id, #Comm_Id}
ACTEUR_COMMENTAIRE = {#Acteur_Id, #Comm_Id}

(avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)

ou
2)
FILM = {Film_Id, Film_Titre, Film_DateSortie}
ACTEUR = {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
FILM_COMMENTAIRE = {#Film_Id, FilmComm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
ACTEUR_COMMENTAIRE = {#Acteur_Id, ActeurComm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}

La première solution me gêne dans la mesure où le modèle ne signifie par l'exclusivité d'un commentaire à un film ou un acteur par lui même.

La deuxième solution me gêne dans la mesure où on répète la structure d'un commentaire dans chaque entité faible.

[Richard_35]

Bonjour Vmolines,

La première solution est la meilleure !... si, à l'avenir, tu dois ajouter des attributs à l'entité "Commentaire", ils seront ajoutés pour toutes les entités qui pointent sur elle.

le modèle ne signifie par l'exclusivité d'un commentaire à un film ou un acteur par lui même.

==> il s'agit de la contrainte XT dans Merise. Concrètement, il faudra un trigger qui contrôlera qu'un commentaire appartient, obligatoirement, à un film ou à un acteur, mais pas aux deux. Astuce : une vue ou une requête liant FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE via Comm_Id doit être toujours vide...

[vmolines]

Mon premier réflexe aurait été celui là. La répétition étant souvent synonyme de problème de normalisation.

Cependant, bien qu'ayant les mêmes attributs, un commentaire de film et d'acteur doivent ils être dans la même table ?

Ce qui me ferait pencher pour des tables distinctes :
- Un commentaire n'a pas de sens en tant que tel mais uniquement rattaché à l'une ou l'autre des entités. Bizarre de ne pas l'identifier relativement.
- D'un point de vue optimisation, les commentaires rattachés à une entité seront toujours chargés par rapport à celle ci et rangés physiquement comme ça avec cette solution. Je pourrais avoir une recherche directe d'index sur la table commentaire dédiée. Avec la solution 1, j'aurai une recherche d'index sur la table d'association + une boucle de key lookup sur la table commentaire.

Au final si la structure de mon commentaire évolue la solution 1 m'économise juste de mettre à jour les 2 tables. En contre partie, ça me semble pas plus juste, moins performant et rafistolé à coup de trigger pour maintenir la cohérence.

[Richard_35]

Cependant, bien qu'ayant les mêmes attributs, un commentaire de film et d'acteur doivent ils être dans la même table ?

==> ça se discute... mais, je pense que oui.

Conceptuellement, un commentaire est un texte rattaché à... ce que l'on veut. Les entités concernées peuvent évoluer et les attributs des commentaires aussi.

Admettons que, à l'avenir, tu veuilles stocker des commentaires liés aux réalisateurs, aux scénaristes, aux directeurs de la photographie, etc... Conceptuellement, il n'y a pas autant d'entité "Commentaire" que d'objets en possédant. Et, dans la pratique (MLD), il faudra que tu aies autant de tables que de liaisons... ce qui me parait gênant.

Le conceptuel doit primer et, du conceptuel, doit découler les objets de travail (les tables).

[JPhi33]

Bonjour vmolines et Richard,

Désolé de ne pas être d'accord avec vous mais il me semble que la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films :

[ FILM ]--0,n----( FILM_COMMENTAIRE )----0,n--[ COMMENTAIRE ]

Il en va de même pour les acteurs.

La solution 2 est meilleure de ce point de vue mais induit une entité commentaire par entité de gestion comme vous l'avez souligné l'un et l'autre.

Il me semble qu'une 3e solution serait plus adéquate :

Code :

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

1
2
3
4
5
6
  [ FILM ]--0,n----( )----0,1-+
                    |         |
                    x  [ COMMENTAIRE ]
                    |         |
[ ACTEUR ]--0,n----( )----0,1-+

Le "x" est une contrainte d'exclusivité signifiant qu'un commentaire ne s'applique qu'à un film ou à un acteur.

Les cardinalités 0,1 infèrent des tables de liaison au niveau relationnel identifiées par le commentaire et comportant une clé étrangère vers l'entité de gestion :

Commentaire_Film(Comm_Id, Film_Id)
Commentaire_Acteur(Comm_Id, Acteur_Id)

Qu'en pensez-vous ?

[CinePhil]

La meilleure solution est effectivement celle de JPhi33.

[Richard_35]

Bonjour JPhi33, CinePhil et Vmolines,

De l'inconvénient de traiter la structure des tables avant le modèle conceptuel...

Désolé de ne pas être d'accord avec vous mais il me semble que ni la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films

==> cette remarque est traitée par :

(avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)

==> qui signifie, si j'ai ben compris, la création d'un index unique sur #Comm_Id.

FILM= {Film_Id, Film_Titre, Film_DateSortie}
ACTEUR= {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
COMMENTAIRE= {Comm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id
ACTEUR_COMMENTAIRE= {#Acteur_Id, #Comm_Id} ==> index unique sur #Comm_Id

Je reste persuadé que la solution 1 est la meilleure car, conceptuellement, un commentaire est, simplement, un objet texte rattaché à... ce que l'on veut. C'est une entité à part entière. Les entités liées aux commentaires peuvent évoluer et les attributs des commentaires aussi. Dans la solution 2, si les attributs des commentaires évoluent, alors il faudra les intégrer à toutes les tables de liaisons !...

Admettons que, à l'avenir, il failles stocker des commentaires liés aux réalisateurs, aux scénaristes, aux directeurs de la photographie, etc... Conceptuellement, il n'y a pas autant d'entité "Commentaire" que d'objets en possédant. Et, dans la pratique (MLD), il faudra créer autant de tables que de liaisons... ce qui me parait gênant.

Mais bon, comme habituellement, la balle est dans le camp de Vmolines.

[JPhi33]

Bonjour à tous,

De l'inconvénient de traiter la structure des tables avant le modèle conceptuel...

Je suis bien d'accord avec Richard.

Désolé de ne pas être d'accord avec vous mais il me semble que ni la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films

==> cette remarque est traitée par :

(avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)

==> qui signifie, si j'ai ben compris, la création d'un index unique sur #Comm_Id.

C'est l'interprétation de Richard pour cette contrainte. Je la comprends différemment : pour moi, elle signifie "un commentaire donné ne peut pas être à la fois un commentaire de film et un commentaire d'acteur". A vmolines de nous éclairer sur ce point.

Mais, soit. Partons de l'hypothèse retenue par Richard : un index unique sur #Comm_Id. On se restreint aux films, le raisonnement pouvant être appliqué aux acteurs par similitude.

FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id

Dans cette hypothèse, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table COMMENTAIRE (normal). Mais, puisqu'il y a un index UNIQUE sur #Comm_Id dans la table FILM_COMMENTAIRE, une ligne de la table COMMENTAIRE ne peut référencer qu'une ligne de la table FILM_COMMENTAIRE. Par rétro-ingénierie, en supposant pour l'instant que ces deux tables soient issues d'entités, on obtient le MCD :

[ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]

Concernant #Film_Id, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table FILM. En revanche, une ligne de la table FILM peut référencer plusieurs lignes de la table FILM_COMMENTAIRE (pas d'index UNIQUE cette fois). Par rétro-ingénierie, on obtient le MCD :

[ FILM ]--0,n----( )----1,1--[ FILM_COMMENTAIRE ]

Le MCD global est donc :

[ FILM ]--0,n----( )----1,1--[ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]

La table FILM_COMMENTAIRE n'a pas de clé propre, seulement des clés étrangères. Par conséquent cette table doit être issue d'une association. On aurait donc le MCD suivant :

[ FILM ]--0,n----( FILM_COMMENTAIRE )----1,1--[ COMMENTAIRE ]

qui se traduit au niveau relationnel par une clé étrangère dans la table COMMENTAIRE... et l'inexistence d'une table FILM_COMMENTAIRE. C'est bien d'ailleurs la signification conceptuelle de l'index UNIQUE sur #Comm_Id dans FILM_COMMENTAIRE : un commentaire ne peut se rapporter qu'à un seul film.


En ajoutant la partie acteurs par similitude, on obtient au final ce MCD :

[ FILM ]--0,n----( FILM_COMMENTAIRE )----1,1--[ COMMENTAIRE ]--1,1----( ACTEUR_COMMENTAIRE )----0,n--[ ACTEUR ]

(l'association ACTEUR_COMMENTAIRE ne se dérive pas en table mais en clé étrangère dans la table COMMENTAIRE)


C'est là que vmolines doit nous éclairer sur le sens de l'exclusivité : un commentaire donné doit-il s'appliquer à la fois à un film et à un acteur ? Si c'est oui, on en reste là. Si c'est non, alors le MCD qui en découle est celui de mon précédent post.

Code :

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

1
2
3
4
5
6
  [ FILM ]--0,n----( )----0,1-+
                    |         |
                    x  [ COMMENTAIRE ]
                    |         |
[ ACTEUR ]--0,n----( )----0,1-+

Avec des cardinalités 0,1 il n'y a plus, cette fois, de clés étrangères dans la table COMMENTAIRE mais des tables de lien (les tables disparues réapparaissent) :

FILM_COMMENTAIRE(#Film_Id, #Comm_Id)
ACTEUR_COMMENTAIRE(#Acteur_Id, #Comm_Id)

A noter que la clé de ces tables est #Comm_Id. #Film_Id et #Acteur_Id sont des clés étrangères non identifiantes... ce qui suffit à garantir l'unicité de #Comm_Id. Quelle coïncidence !
A noter aussi que ce modèle permet de lier COMMENTAIRE à d'autres entités (réalisateur, scénariste, etc.)

[Richard_35]

Bonjour à tous,

FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id

Dans cette hypothèse, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table COMMENTAIRE (normal).

==> vrai.

Mais, puisqu'il y a un index UNIQUE sur #Comm_Id dans la table FILM_COMMENTAIRE, une ligne de la table COMMENTAIRE ne peut référencer qu'une ligne de la table FILM_COMMENTAIRE.

==> vrai. Peut, car il y a aussi la table ACTEUR_COMMENTAIRE.

Par rétro-ingénierie, en supposant pour l'instant que ces deux tables soient issues d'entités, on obtient le MCD :
[ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]

==> non. Peut=0,1, donc : [ FILM_COMMENTAIRE ]--1,1----( )----0,1--[ COMMENTAIRE ]


En final, je pense que nous sommes tous les trois d'accord (JPhi33, CinePhil et moi-même). D'ailleurs, en reprenant l'ordre logique des choses :

Règles de gestion :

• 1 film peut posséder 0 ou n commentaires ;
• 1 commentaire peut concerner 0 ou 1 seul film ;
• 1 acteur peut posséder 0 ou n commentaires ;
• 1 commentaire peut concerner 0 ou 1 seul acteur ;
• 1 même commentaire ne peut pas concerner 1 film et 1 acteur à la fois.

MCD (c'est celui que tu proposais, JPhi33...) :



Tables :

Film(IdFilm, …)
Acteur(IdActeur, …)
Commentaire(IdCommentaire, Pseudo, …)
Film_Commentaire(#IdFilm, #IdCommentaire, …) ==> index unique sur #IdCommentaire
Acteur_Commentaire(#IdActeur, #IdCommentaire, …) ==> index unique sur #IdCommentaire
Contrainte XT (trigger) ==> une vue liant Film_Commentaire à Acteur_Commentaire via #IdCommentaire ne doit renvoyer aucun élément.

Plus ou moins vite fait...
Qu'en pensez-vous ?

[JPhi33]

Bonjour,

Film_Commentaire(#IdFilm, #IdCommentaire, …) ==> index unique sur #IdCommentaire
Acteur_Commentaire(#IdActeur, #IdCommentaire, …) ==> index unique sur #IdCommentaire

Pas d'accord en ce qui concerne la clé de ces tables et la contrainte d'unicité sur #IdCommentaire.
Je maintiens (voir mon précédent post) qu'une association 0,1 - 0,n (ou 1,n) se dérive en une table dont la clé est celle de la table côté 0,1 (ici #IdCommentaire) et comporte une clé étrangère qui référence la table côté 0,n.

Donc :

Film_Commentaire(#IdCommentaire, #IdFilm, …) ==> L'index unique sur #IdCommentaire est inutile : #IdCommentaire étant la clé primaire de cette table, l'unicité est garantie.
Acteur_Commentaire(#IdCommentaire, #IdActeur, …) ==> Idem

[Richard_35]

Bonjour,

Tu as raison, JPhi33, ta solution économise un index.

[SQLpro]

Une solution plus simple serait de faire un héritage exclusif, en considérant une entité générique "mère" que l'on pourrait appelé objet_médiatique qui aurait un id et un commentaire nullable. Dès lors film et acteur serait des spécialisations de l'objet médiatique.... avec tous les avantages de la clef unique propagée (rangement des tuples si table IOT/clustered).

A +