clés étrangères multiples

Bon, j'espère que la question ne sera pas saugrenue, ni déjà posée, je sais pas trop comment chercher sur ce thème.

[pour info, je cherche à modéliser l'équivalent d'un heritage mais la fonctionnalité ne marche pas correctement sur mon SGBD, à savoir PostGreSQL]

Je vais essayer d'être clair.
J'ai une table centrale tout ce qu'il y a de plus classique avec une clé primaire. (normal :wink: )

j'ai N tables annexes avec leurs clefs aussi.
simplement, je voudrais que la clé primaire de ma table centrale soit identifiée comme clé étrangère dans UNE des autres tables. C'est-à-dire que la clé primaire de ma table centrale doit exister dans une autre table.

Pour l'instant, pas d'intégrité référentielle de la table centrale vers les autres, ce que j'aimerais avoir.

Voila...j'espère que quelqu'un aura compris et aura une idée.

merci d'avance

J'avoue ne pas comprendre si tu as un pb avec PostgreSQL ou un pb de conception de shema relation :?

c'est ce que je craignais.
C'est un problème de modélisation, après il se trouve que je bosse sous postgresql mais là je modélise avec Case Studio.

Simplement, ce que je souhaite faire, serait simple avec de l'héritage qui ne fonctionne pas sous postgre.

faut-il que je réexplique le problème?

Pour déclarer une PFK sous CS :

Sélectionne "Identifying Relationship"
Clique (et garde le bouton enfoncé) sur la table annexe
déplace le curseur vers la table centrale et relache.

Ainsi, la clé de la table annexe agit comme une primary foreign key pour la table centrale.


C'est ce que tu voulais ?

eeehhh non...bon en même tps, c pas clair.

Alors, dans l'absolu, j'ai une notion d'héritage avec une table mère (ma table centrale) et des tables filles. Sauf que la fonctionnalité d'héritage ne fonctionne pas correctement sous PostGreSQL (mon SGBD).
Donc je cherche une autre solution.

J'ai gardé mes tables filles et ma table mère. simplement, je n'ai plus de relation entre la mère et les filles. or je ne veux pas que les clés primaires des filles soient en FK chez la mère. En fait je veux que sur la clé primaire de la mère s'applique une mécanisme d'intégrité qui vérifie que la clé de la mère existe soit dans la fille1 soit dans la fille2, etc...

J'espère que c mieux.
Clairement c'est pour avoir un modèle propre mais sinon, je gère l'intégrité en code.

Si c'est une spécialisation (plusieurs entités filles partagent des propriétés d'une entité mère) que tu cherches à modéliser pourquoi ne pas simplement faire ceci :

Citation:

---

ENTITE_MERE : ID_ENTITE_MERE (PK), PROPRIETE1, PROPRIETE2, PROPRIETE3, ...
ENTITE_FILLE1 : ID_ENTITE_FILLE1 (PK), ID_ENTITE_MERE (FK), PROPRIETE1, PROPRIETE2, PROPRIETE3, ...
ENTITE_FILLE2 : ID_ENTITE_FILLE2 (PK), ID_ENTITE_MERE (FK), PROPRIETE1, PROPRIETE2, PROPRIETE3, ...

---

Pour tout ce qui est de tes contraintes d'héritage (X, T, XT) il faut recourrir aux triggers ou l'assurer au niveau de l'appli...[/quote]

Ou encore

Code:

---

1 2 3

ENTITE_MERE : ID_ENTITE_MERE (PK), PROPRIETE1, PROPRIETE2, PROPRIETE3, ... ENTITE_FILLE1 : ID_ENTITE_MERE (PK, FK), PROPRIETE10, PROPRIETE11, PROPRIETE12, ... ENTITE_FILLE2 : ID_ENTITE_MERE (PK, FK), PROPRIETE20, PROPRIETE21, PROPRIETE22, ...

---

alors..notre soucis c que ce sont d'abord les entités filles qui sont renseignées...donc ces solutions sont pas très pratiques

C'est un faux problème. Ce n'est pas parce que tu "renseignes" d'abord les propriétés filles que ton enregistrement père (hérité) n'existe pas.

Il doit forcément exister !

Pour faire un nouvel enregistrement dans ton entité fille, passe par une procédure qui créée d'abord l'enregistrement l'entité mère.

ok, ok..on est d'accord, avec des procédures et des triggers, ça roule sans problème.
Vos solutions sont intéressantes, on va probablement les suivre.

c'est plus une question d'ordre général que je me posais.
Existe-t-il un modèle, une instruction SQL permettant de préciser à une clé étrangère qu'elle doit existe dans au moins une table associée?

contraintes multiples sur une clé étrangère...

La définition des données SQL ne permet pas ceci. Les contraintes simples sont assurées par l'ajout de contraintes via CONSTRAINT. Les contraintes complexes (on cas) sont alors maintenues par des triggers si le SGBD le permet.

C'est toujours ce qui est fait pour implémenter les contraintes d'héritage (exclusivité, totalité, ...)

bon, ben c'est ce qu'on craignait...on a bien fait de passer la solution trigger sans attendre :D

merci

A+