Discussion :

[cotede2]

Bonjour , voici mon idée.

J'ai un répertoire d'entreprises (genre les pages jaunes), et sur mon site j'aimerais pouvoir ajouter des fonctionnalités en plus (système de profils...).
Donc une entrée dans mon répertoire est associée à 0 ou 1 profil.
Et un profil est associée à 0 ou 1 entrée de mon répertoire d'entreprises (car le profil peut être un simple utilisateur ou un profil d'un autre répertoire).

Comment représenter la chose?



user --- 0,1 ---- Business ---- 0,1--- repertoire_business
user --- 0,1 ---- Artist ---- 0,1--- repertoire_artist



Quand le SQL est généré il me met business_id et artist_id en cléf etrangère de users. Est ce une erreur?
J'aurais pensé faire une table artists et une table businesses .
Qui prendraient chacune 2 colonnes (user-id et artist_id respectivemenet business_id) !

[Soutou]

Il faudrait, pour être plus précis dans la modélisation, ajouter une contrainte d'exclusivité entre les 2 associations reliés à users. La limitation est que l'outil ne gère pas les contraintes.
Pour les clés étrangères, il peut y avoir plusieurs solutions. Celle là est OK, il faudra rajouter un CHECK qui s'assure que quand une valeur est nulle l'autre ne l'est pas et inversement.

[TheLeadingEdge]

Bonjour,

Si tu veux 1 entité par profil, tu pourrais utiliser 1 héritage.
Ca t'éviterait de plus d'avoir à gérer l'intégrité des relations ds ton application.



Selon l'option de passage au MPD que tu vas choisir, tu obtiendras des résultats sensiblement différents. Pour résumer :
1 Tu peux choisir de recopier les propriétés du parent ds les enfants sans créer le parent. A priori ce n'est pas ce que tu veux.
2 Tu peux choisir de créer le Parent, et de recopier les propriétés du parent ds les enfants. Tu auras également 3 tables avec des contenus différents.
3 Tu peux choisir de créer le Parent, et de ne pas recopier les propriétés du parent ds les enfants. Tu auras 3 tables avec des contenus différents.
Avec la 2nde solution tu as tt ce que tu veux en 1 seul select. Avec la 3eme, selon ce que tu veux comme données, tu devras peut-être faire 1 jointure entre Membre et 1 de ses enfant.
Il y a déjà eu plusieurs posts à ce sujet. 1 recherche ds le forum te donneras plus de détails.

Qques petites remarques :
Je ne connais pas ton contexte, et je peux me tromper, mais je ne pense pas que ''Groupe'' et '''User'' soient liés.
Egalement, si ''genre'' et ''instrument'' sont ce que je pense, (ie les id des entités ''Instruments'' et ''Genres'') tu ne dois pas les faire apparaitre sur ton MCD. Ce sont des contraintes, pas des propriétés de l'entité.

[cotede2]

merci beaucoup.
Je pense me diriger vers la solution 3.
Je vais regarder sur le forum pour cette solution.

Concernant les genres et instruments , nous avons décidé que tout artiste a un genre principal et un instrument principal.
Et un user peut etre un groupe (Destiny 's Child par exemple).

Concernant ma relation 0,1 - 0,1 , je pense tout simplement créér une table.

Businesses
user_id business_id

et une table

Artists
user_id artist_id

C'est vrai qu'il manque quelque chose pour assurer l'intégrité et que la solution cléf étrangère dans l'entité user parait plius logique.

Comment faire ce check?

Comment se manifeste une relation d'héritage en SQL?

Je travaille avec des américains , ils connaissent pas MERISE

[Soutou]

Dans users tu mets les 2 clés étrangères

USERS (user_id, ... business_id#, artist_id#)

il faut ensuite ajouter avec ALTER TABLE la contrainte

CHECK ((business_id IS NULL AND artist_id IS NOT NULL)
OR
(business_id IS NOT NULL AND artist_id IS NULL))

ainsi chaque users est soit business soit artiste
Si tu laisse la possibilité qu'un user ne soit ni l'un ni l'autre il faudra
ajouter : OR (business_id IS NULL AND artist_id IS NULL)

[cotede2]

merci!

Dans le livre : ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf

Page 38 , nous retrouvons un exemple similaire.


Les factures d'une entreprise font l'objet d'un réglement soit par chèque soit par carte bleue.
Cette entreprise souhaite connaître pour chaque réglement la date , le montant et:
-le numéro et le nom de la banque des chèques
-ou le numéro et la date d'expiration des paiements par carte

Regardez à la page 38 , ils décident de ne pas faire de clés étrangères dans l'entité règlements mais plutôt de faire une clé étrangère sur l'identifiant de réglement dans les entités chèques et paiements par carte.

Pourquoi? C'est bien une association 0,1 - 0,1 comme mon association (user artist ou user business) .

[TheLeadingEdge]

bonjour,

Dans ce cas la norme Merise recommande de migrer la clef du coté 0,1 vers le coté 1,1.
Ca évite les clefs étrangères ''nullable''.

Pour autant, si tu veux gérer la contrainte d'exclusion, il faudra que tu le fasses par 1 trigger.
Faire l'inverse, avoir les 2 FK dans la même table, permet d'utiliser une contrainte CHECK comme te le propose C. Soutou.

AMC ne se mouille pas. Il génère les 2. A toi de choisir ton camp.