Version imprimable
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 ?
En gros, je n'ai rien compris à ta question... pourrais-tu par exemple expliciter les points suivants :
- Qu'est-ce qu'une partition XT ?
- Quels sont les attributs de tes entités ?
- les "entités filles" sont-elles filles par spécialisation ou par appartenance ?
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.
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.
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.
Ce qui revient à dire que ta participation a un type, "abonné" ou "anonyme".Citation:
Envoyé par kazou
... sauf qu'elle ne permet pas d'implémenter la contrainte dont tu as besoin ;)Citation:
Envoyé par kazou
Plus largement, l'impression que tu donnes est que c'est un modèle objet... qui ne se traduit pas directement en MPD relationnel.
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.).Citation:
Envoyé par kazou
d'où ma suggestion de le mettre à NULL pour les anonymesCitation:
Envoyé par kazou
Normalement, ça ne change rien, à part effectivement une sématique amoindrie.Citation:
Envoyé par kazou
je comprend ta solution qui n'est pas mauvaise, mais qui n'est pas avantageuse dans cet exemples, puisque pour ajouter un control d'intégrité je devrais etre obligé de renoncer a d'autres asses importants.
Donc je vais renoncer de poser cette contrainte pour le moment, puis dans le pire des cas ca se fera en code meme si j'aime pas bosser a la place de mon SGBD.
Merci du coup de main :)
Eventuellement (mais je ne sais pas si ça correspond à ton cas), tu peux adopter ma solution et la masquer en créant des vues PartAbonnee et PartAnonyme, ce qui devrait te permettre de garder ton MLD.
Ca peut etre une solution effectivement, je vais peser le pour et le contre.
Merci d'avoir repondu aussi rapidement et aussi efficacement :)