Discussion :

[Alain Defrance]

Tout d'abord j'aimerais savoir si les contraintes de partition XT (entre deux entité filles) existe avec innoDB de mySQL.
Et si c'est le cas comment ca se traduit en SQL je ne trouve pas de doc.

J'ai :
Participation, PartAbonnee (fille de Participation), PartAnonyme(fille de Participation), et un XT entre PartAbonnee et PartAnonyme

Comment se traduirait cette contrainte en SQL ?

[Antoun]

En gros, je n'ai rien compris à ta question... pourrais-tu par exemple expliciter les points suivants :

1. Qu'est-ce qu'une partition XT ?
2. Quels sont les attributs de tes entités ?
3. les "entités filles" sont-elles filles par spécialisation ou par appartenance ?

[Alain Defrance]

Excuse moi pour ce manque de précision que je vais corriger.

Voici le MLD

Participation(dateParticipation, ip)
PartAbonnee(#dateParticipation, nbTickets)
PartAnonyme(#dateParticipation)

Et je voudrais que l'existance d'une Participation ne soit jamais présente dans PartAbonne et PartAnonyme en meme temps.

La contrainte "XT" dont je parlais fait reference au modèle merisien.

[Antoun]

Si je comprends bien, dateParticipation est la clé primaire de ta table participation, et une clé étrangère sur les deux tables PartAbonee et PartAnonyme ?

ça veut dire que pour chaque participation, il y a soit plusieurs parts abonné, soit plusieurs parts anonymes, mais jamais les deux ?

J'en déduirais que chaque Participation a un type "abonné" ou "anonyme". Ton modèle deviendrais donc le suivant :

Participation(dateParticipation, ip, type)
Part(#dateParticipation, nbTickets)

avec évidemment un nbTickets NULL pour les parts anonymes.

[Alain Defrance]

Non le modèle est plus complexe et les deux filles ont lieu d'exister, nbTickets concerne seulement les Partabonnees, mais outre une semantique un peu moins précise, faire disparaitre les PartAnonymes rendrait le modèle faux puisque d'autres entités sont liés a cette entité fille.

La conception est fini et bonne (je pense), mon soucis est d'ordre syntaxeique. Comment puis-je definir les contraintes SQL permettant d'avoir l'existance d'une fille, ou de l'autre, mais pas les deux a la fois.
Une participation ne peut pas etre d'abonnees et d'anonyme à la fois si tu préfère.

[Antoun]

Une participation ne peut pas etre d'abonnees et d'anonyme à la fois si tu préfère.

Ce qui revient à dire que ta participation a un type, "abonné" ou "anonyme".

La conception est fini et bonne (je pense),

... sauf qu'elle ne permet pas d'implémenter la contrainte dont tu as besoin

Plus largement, l'impression que tu donnes est que c'est un modèle objet... qui ne se traduit pas directement en MPD relationnel.

mon soucis est d'ordre syntaxique. Comment puis-je definir les contraintes SQL permettant d'avoir l'existance d'une fille, ou de l'autre, mais pas les deux a la fois.

MySQL ne permettant pas les contraintes CHECK, je crains que la seule solution "propre" ne soint celle que je t'ai indiquée. Tu peux par contre utiliser une solution "sale", à savoir un trigger qui fait échouer l'insertion s'il existe déjà des lignes dans la table soeur. Ce qui est sale est que tu n'auras jamais de message d'erreur explicite, mais un message faisant référence à l'astuce que tu auras utilisé pour faire échouer l'insertion (ajout d'un NULL dans une colonne NOT NULL, d'un VARCHAR dans une colonne INT, etc.).

Non le modèle est plus complexe et les deux filles ont lieu d'exister, nbTickets concerne seulement les Partabonnees,

d'où ma suggestion de le mettre à NULL pour les anonymes

mais outre une semantique un peu moins précise, faire disparaitre les PartAnonymes rendrait le modèle faux puisque d'autres entités sont liés a cette entité fille.

Normalement, ça ne change rien, à part effectivement une sématique amoindrie.