Discussion :

[Oberown]

J'ai trois tables.
- Commentaire
- Photo
- Article

Un commentaire peut porter soit sur une photo soit sur un article.
Une photo peut avoir plusieurs commentaires, tout comme les articles.
Un commentaire ne peut pas porter sur une photo et un article

Commentaire <---0,1 ------>0,n Photo
Commentaire <---0,1 ------>0,n Article

Ma table commentaire
IdCommentaire (clé primaire)
IdPhoto (Clé étrangere)
IdArticle (Clé étrangere)

Est-ce que ma modélisation est juste ?

Comment faire pour dire qu'une seule de mes clés étrangere doit être non null ? Je n'ai pas l'impression que c'est possible, et que c'est à l'application de le traiter.

[Le Pharaon]

Comment faire pour dire qu'une seule de mes clés étrangere doit être non null ?

En Mérise il existe un symbole pour dire que deux associations sont exclusives. Niveau SGBD il n'y a pas de méthode spécique à ma connaissance pour traiter un cas pareil. Tu peux toutefois utiliser des triggers (déclencheurs) ou faire des tests sur le niveau applicatif.

[TheLeadingEdge]

Bonjour,

Est-ce que ma modélisation est juste ?

Oui

Comment faire pour dire qu'une seule de mes clés étrangere doit être non null ? Je n'ai pas l'impression que c'est possible, et que c'est à l'application de le traiter.

Sur ton MCD tu relies tes 2 relations avec 1 une contrainte ''totalité/exclusive'' notée XT.
Attention, ce n'est qu'1 notation. A ma connaissance il n'y a pas d'AGL qui la traduise dans 1 schema de base.
Tu peux éventuellement ajouter des contraintes ''check'' sur les 2 FK de ta table ''commentaire'', mais je ne suis pas sur que ça couvre tous les cas. Je pense comme toi que le mieux est de faire gérer ça par l'appli.

A +

[fsmrel]

Les cardinalités 1,1 / 0,n sont à privilégier à tout prix par rapport aux cardinalités 0,1 / 0,n (effets secondaires au niveau de la manipulation des données par le SGBD : valeurs nulles et logique ternaire).

A priori, vous avez soit des commentaires de photos, soit des commentaires d'articles. Vous voulez les mélanger ? Dommage, mais soit.

Entre autres solutions, vous pouvez par exemple utiliser la représentation

Photo 0,n <----I-1,1 Commentaire_Photo (I-1,1 signifiant que le commentaire de photo est une entité "faible", identifiée relativement à la photo, entité "forte")

Article 0,n <----I-1,1 Commentaire_Article

d'où les schémas de tables :

Photo (Id_Photo, ....)
Primary key : Id_Photo

Commentaire_Photo (Id_Photo, No_relatif_commentaire, ...) // No_relatif démarre à 1 pour chaque photo et est incrémenté pour chaque commentaire pour une photo donnée.
Primary key : Id_Photo, No_relatif_commentaire
Foreign key : Id_Photo references Photo


Article (Id_Article, ....)
Primary key : Id_Article

Commentaire_Article (Id_Article, No_relatif_commentaire, ...)
Primary key : Id_Article, No_relatif_commentaire
Foreign key : Id_Article references Article

Partant de là, si vous souhaitez lire uniquement les commentaires de photos, pas de problème.

Si vous souhaitez disposer d'une table permettant d'offrir une vision unique, photos et articles confondus, créez une vue d'union, avec un attribut discriminant ("F" pour Photo, "A" pour Article)

Create VIEW Commentaire AS
Select Id_Photo, No_relatif_commentaire, "F", ...
FROM Commentaire_Photo
UNION ALL
Select Id_Article, No_relatif_commentaire, "A", ...
FROM Commentaire_Article

En respectant bien sûr la compatibilité de type astreignant les unions et en utilisant "UNION ALL" plutôt que UNION car, l'intersection des résultats des Select étant vide, ça va beaucoup plus vite (pas de tri nécessaire).

Bonne chance

[TheLeadingEdge]

Re,

Si la définition des 2 entités ''photo'' et ''article'' est la même, ça pourrait aussi se modéliser comme ça.
On évite les artifices de contraintes sur le modèle et dans la base.
Si ''photo'' et ''article'' sont différentes tu peux essayer avec 1 spécialisation de ''objet'' à la place de l'entité ''type''.



A +