Discussion :

[nponzo]

Bonjour,

j'ai dans mon modèle physique de données, quatres tables (A1,A2,A3,A4) qui héritent d'une table (A)

cette "table-mère" reçoit les identifiant autoincrémentés et d'autres données des "tables filles".

ces clés primaires, autoincrémentés, des "tables-filles" viennent alimenter la clé primaire de la "table-mère".

cette "table-mère" est en relation avec une autre table (table "B") par le biais d'une table issue d'association (table "A_B").

j'ai un problème lors de l'insertion des données dans cette table issue d'association.

il me dit que la clé étrangère dans "A_B" fait référence à des données inexistantes dans "A". or mes données sont bien présentes dans "A".

j'ai essayé de supprimer les "tables filles" de "A". et là l'insertion dans la table "A_B" ne me renvoi pas d'erreur.

est-ce un problème connu des relations d'héritage ?

plus étonnant, c'est que dans mon modèle, j'ai d'autres relations d'héritage et des liens avec des tables issues d'associations (la même architecture avec moins de "tables filles") et ça fonctionne sans problème.

???

[Chtulus]

Bonjour,

Tu aurais un jeu d'essais s'il te plait.

Sous quel SGBD travail tu ?

[nponzo]

Bonjour,

et merci de vous intéresser à ce problème.

je travailles dans postgres 8.3 sous windows.

voilà un exemple, et les requêtes de création de tables :

TABLE PARCELLE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE TABLE parcelle
(
  id_parcelle serial NOT NULL,
  insee character varying(5) NOT NULL,
  section character varying(5) NOT NULL,
  parcelle character varying(4) NOT NULL,
  CONSTRAINT cle_par PRIMARY KEY (id_parcelle),
  CONSTRAINT fkey_section FOREIGN KEY (insee, section)
      REFERENCES section (insee, section) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE parcelle OWNER TO postgres;
 
-- Index: fkidx_sect
 
-- DROP INDEX fkidx_sect;
 
CREATE INDEX fkidx_sect
  ON parcelle
  USING btree
  (insee, section);

j'ai volontairement enlevé la géométrie de la table parcelle car, ça ne sert à rien pour les tests.

TABLE OPEFON

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
CREATE TABLE opefon
(
  id_opef serial NOT NULL,
  date date NOT NULL,
  proprio character varying(30) NOT NULL,
  CONSTRAINT cle_opef PRIMARY KEY (id_opef)
)
WITH (OIDS=FALSE);
ALTER TABLE opefon OWNER TO postgres;

TABLE AXI

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE axi
(
-- Hérité(e):   id_opef integer NOT NULL DEFAULT nextval('opefon_id_opef_seq'::regclass),
-- Hérité(e):   date date NOT NULL,
-- Hérité(e):   proprio character varying(30) NOT NULL,
  disponibilite boolean NOT NULL DEFAULT true,
  anex character varying(50) NOT NULL,
  CONSTRAINT cle_axi PRIMARY KEY (id_opef)
)
INHERITS (opefon)
WITH (OIDS=FALSE);
ALTER TABLE axi OWNER TO postgres;

TABLE CD

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE cd
(
-- Hérité(e):   id_opef integer NOT NULL DEFAULT nextval('opefon_id_opef_seq'::regclass),
-- Hérité(e):   date date NOT NULL,
-- Hérité(e):   proprio character varying(30) NOT NULL,
  CONSTRAINT cle_cd PRIMARY KEY (id_opef)
)
INHERITS (opefon)
WITH (OIDS=FALSE);
ALTER TABLE cd OWNER TO postgres;

TABLE PAROF

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
CREATE TABLE parof
(
  id_parcelle serial NOT NULL,
  id_opef serial NOT NULL,
  CONSTRAINT cleparof PRIMARY KEY (id_parcelle, id_opef),
  CONSTRAINT fk_opef FOREIGN KEY (id_opef)
      REFERENCES opefon (id_opef) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk_par FOREIGN KEY (id_parcelle)
      REFERENCES parcelle (id_parcelle) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE parof OWNER TO postgres;

et voici ce que ça donne sous PGAdmin III:



de haut en bas : axi, cd, opefon (cachée par parof), parcelle et à droite parof (la table issue de l'association de parcelle et opefo) avec le message d'erreur lorsque j'essaye d'insérer à la main.

j'espère que ça suffira, s'il vous faut autre chose, je suis à votre disposition.

cordialement.

[CinePhil]

Je trouve étrange cette partie là :

ces clés primaires, autoincrémentés, des "tables-filles" viennent alimenter la clé primaire de la "table-mère".

Si je comprends bien, tu crées une ligne dans la table fille avant la ligne correspondante dans la table mère et la clé primaire de la table fille est auto-incrémentée ?
Ne peut-il arriver un cas où le même identifiant existe dans deux tables filles ?
N'y aurait-il pas alors conflit dans la table mère ?

Perso je ferais plutôt le contraire :
- Création de la ligne dans la table mère
- Récupération de l'id créé et insertion dans la table fille.

Dans un héritage, on a par exemple les associations :
Employe -1,1----Etre---- Personne
Contact -1,1----Etre---- Personne
Personne est ici l'entité mère et Employe et Contact sont les entités filles.

Si je passe du MCD au MPD, ça donne :
T_Personnes_Per(Per_Id, Per_Nom, Per_Prenom, ...)
T_Employes_Emp(Emp_IdPersonne, Emp_Salaire, ...)
T_Contacts_Ct(Ct_IdPersonne, Ct_IdOrganisme, ...)

C'est donc bien la table mère qui doit donner sa clé primaire aux tables filles et non l'inverse.

J'ajoute que, évidemment, les tables associatives contenant une clé étrangère faisant référence à la clé primaire de la table mère ou d'une table fille sont alimentées après l'insertion de la ligne dans les tables de l'héritage. Dans l'exemple ci-dessus, ce serait le cas si on externalise les adresses des personnes :
Personne -0,n----Habiter----0,n- Adresse
T_Adresses-Adr(Adr_Id, Adr_Rue, Adr_Ville, Adr_CP, ...)
T_Personnes_Per((Per_Id, Per_IdAdresse, Per_Nom, Per_Prenom, ...)

EDIT : Tu as posté le détail pendant que j'écrivais mon message.
Je ne savais pas que Postgres implantait directement le concept d'héritage. Intéressant !

[nponzo]

bonjour,


Cinephil

je me serais trompé de sens ? bin mince alors, je vais essayer comme vous dites.

Pour répondre aux questions posées, j'alimente d'abord les tables filles et postgres remplis les tables mères comme vous avez dit

c'est lui qui gère les clés primaires. je n'ai donc pas remplis les champs "id" des tables axi et cd (voir image post précédent) et il à mis automatiquement 5 et 6 dans cd. il à autoincrémenté à la suite, tout seul. mais je ne sais pas s'il peut se tromper à la longue ou autre (mais je ne vois pas de raison).

_______________________________________________________________

pour l'autre exemple d'héritage dans ma base entre "personne" et "exploitation", j'ai bien remplis les tables filles avant (car personne_physique à un champs en plus [date de naissance], que personne_morale, dont n'hérite pas "personne" mais je n'ai pas mis d'identifiant auto incrémenté. j'ai utilisé des entiers et j'ai chargé les données à partir d'une table d'export qui contenait un identifiant autoincrémenté.

plus étonnant, c'est que dans mon modèle, j'ai d'autres relations d'héritage et des liens avec des tables issues d'associations (la même architecture avec moins de "tables filles") et ça fonctionne sans problème.

même architecture mais pas même types !!!! bourricot de moi

je suis donc sure de ne pas m'être trompé lors de l'insertion dans les tables filles car les identifiant de personne_morale et personne_physique se suivent.

en tout cas merci à tous pour vos réponses, j'essaye de voir ce que je peux faire avec ça et j'espère cliquer sur "résolu" le plus vite.

à bientôt,

cordialement

nicolas.

[CinePhil]

Je n'ai jamais utilisé Postgres donc je ne me prononcerai pas là dessus mais il faut s'assurer dans la doc que Postgres gère correctement la clé primaire de la table mère si on alimente une table fille.

INHERITS signifie bien normalement que c'est la fille qui hérite de la mère (de son identifiant et de ses autres attributs) et pas le contraire.

Il semble que oui puisqu'en fait la table fille ne contient pas d'identifiant en propre mais a pour clé primaire-étrangère la clé primaire de la table mère.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CONSTRAINT cle_axi PRIMARY KEY (id_opef)

Si ça fonctionne correctement, c'est bien pratique : je crée une fille et la mère est alimentée automatiquement !

[nponzo]

Bonjour,

en effet, je créé une table fille et les données entrée se trouvent dans la table mère.

je continu à faire quelques tests, mais je voulais vous dire qu'il y a une erreur dans mon code, ma table issue d'association (parof) contient deux champs autoincrémentés. ça devrait être des entiers qui récupèrent la valeur autoincrémenté des autres tables.

mais je ne suis pas sure que ça ne vienne que de là.

en tout cas merci, car au moins ça avance.

à bientôt,

cordialement,

nicolas.

[CinePhil]

ma table issue d'association (parof) contient deux champs autoincrémentés.

Effectivement, une table associative n'a en principe pas de colonne auto-incrémentée, en tout cas pas en tant que clé primaire.
Elle doit avoir pour clé primaire les clés étrangères faisant référence aux clés primaires des tables qui entrent en jeu dans l'association.

Il faut changer le type des colonnes id_parcelle et id_opef dans la table parof

[nponzo]

rebonjour.

cinephil : oui, j'ai changé, mais le pb ne viens pas de là

l'héritage sous postgres fonctionne correctement quand on insère des données dans les tables filles, qui remplissent automatiquement la table mère.

on peut même mettre des types "serial" dans les filles et dans les mères ils ne se mélange pas les pinceaux, il remplis correctement les champs.

mais si on travail dans ce sens là (les filles avant la mère) la table issue d'association ne veut rien savoir. et ne peut pas récupérer les données de la table mère, que ce soit des entier ou non. on dirait que les champs sont fictifs dans la mère quand on fait ça.

si on rempli la mère d'abord, la table d'association accepte les données mais ne remplit pas automatiquement les données dans les tables filles.

un déclencheur pourrait peut-être régler le problème car mes tables filles ont des codes uniques.

je pourrais peut-être lui dire : "si dans telle colonne, code like 'XX%' remplis telle table fille avec telles données, si code like 'YY%' alors remplis telle autre fille.

que pensez vous d'une telle solution pour ne pas avoir à remplir les filles après avoir remplis les mères ??

[CinePhil]

Tu as changé pour quel type ?
Le type 'serial' pour moi veut dire 'entier auto-incrémenté'. Si tu laisse ce type 'serial' dans la table associative, ça ne peut pas fonctionner.

Il faut savoir quel est le type équivalent à serial et le mettre dans la table parof sur les deux clés étrangères :
- Entier simple ?
- Entier long ?

Encore une fois, je ne connais pas Postgres donc il faut que tu cherches un peu.

[nponzo]

cinephil,

tout d'abord merci d'avoir déplacé la discussion, ce n'est pas la première fois, je vise à coté.

j'ai changer les "serial" de la table d'association pour "integer".

dans postgres, on à le choix entre smallint (entier court) bigint (entier long) et integer (entier simple je suppose).

dans mon modèle, les autres tables d'associations ont des champs et clés étrangère de type "integer" quand les champs des tables auxquelles elles se réfèrent sont de type "serial". en général sa fonctionne.

merci de votre aide, je cherche quand même de mon coté.

en tout cas, votre solution initiale (remplir les tables mère d'abord) fonctionne.
il suffit juste de remplir les filles ensuite.
je vais essayer de changer les type pour smallint et bigint et voir ce que ça fait.

[nponzo]

Bonjour,

je pense que je vais utiliser une procédure stockée et un trigger pour insérer automatiquement dans les tables filles.

[nponzo]

fonctionnalités et limites héritage postgres

http://geekblog.over-blog.com/article-17775481.html

[GrandFather]

Bonjour,

Il y a des limitations sévères concernant l'héritage, notamment le fait que les contraintes de clé étrangère ne sont pas héritées, pas plus que les droits, les index et donc les contraintes d'unicité (voir https://postgresql.developpez.com/do...tion/francais/).

Concrètement, les quelques avantages apportés par l'héritage ont bien du mal à compenser les inconvénients imposés par ses limitations, quand le schéma de base est un tant soit peu complexe. Je l'ai mis en oeuvre une fois pour une application assez complexe (un workflow), je m'en suis mordu les doigts et n'ai jamais réitéré. Personnellement, je déconseillerais son utilisation pour autre chose que de l'expérimentation.

[nponzo]

hello grandfather

thank U for the advice, it is kind.

je vais donc suivre votre conseil même si ça me fait multiplier mes tables.

j'ai un petit modèle cependant, mais dans le mcd, il y a 6 tables qui héritent de tables différentes.

cela casse un peu mon modèle mais je crois que je m'en remettrait.
le seul truc, c'est que ça complexifie car du coup j'ai 4 X 3 + 2 X 2 tables d'associations qui sont crées.

je pense que si je créé un interface en php ou autre et que j'automatise les requêtes, je peux rendre ça transparent pour les utilisateurs.

merci pour la doc,

je crois que je peux cliquer sur résolu, non ?

à bientôt

cordialement,
nicolas

[CinePhil]

Cas intéressant et similaire au tien.
Ce comportement est selon moi un bug issu d'une mauvaise implémentation de la notion d'héritage dans Postgres.

Comme je l'ai déjà expliqué plus haut, c'est bien la table fille qui doit hériter de la table mère et non l'inverse donc l'identifiant devrait être dans la table mère et en tant que clé étrangère dans la table fille.

L'idée d'héritage automatisé dans Postgres me séduisait mais là je suis très déçu.

[nponzo]

moi aussi cinéphil, je suis très déçu.

bien qu'il y ai visiblement des solutions avec partitionnement et déclencheurs, cela semble lourd.

je vais faire du classique, il parait que ça fonctionne toujours.

merci à tous,

[GrandFather]

je pense que si je créé un interface en php ou autre et que j'automatise les requêtes, je peux rendre ça transparent pour les utilisateurs.

Dans la mesure du possible il faudra effectivement essayer de "masquer" la complexité ajoutée par les tables d'association en utilisant vues, procédures stockées, règles et triggers, et ça PostgreSQL le fait à la perfection.

[nponzo]

Bonjour GrandFather,

justement, maintenant c'est ça qui va être un peu coton pour moi car je débute à peine en langage de programmation (notions php, java et sql) mais très sommaires.

j'ai vu des programmes javascript qui piochaient dans la base, qui permettaient d'insérer des données... sans que l'utilisateur ne rentre dans la base afin qu'il ne la casse pas.

on m'a aussi parlé d'access qui permettait de developper des choses facilement.

mais on s'éloigne du sujet. je vais aller faire un tour sur les autres forums et voir ce que je trouve...

...si vous avez de la doc, des pistes ou des conseils, je vous serez très reconnaissant.

merci,

cordialement,

nicolas

[CinePhil]

Si tu te décides à abandonner l'héritage de Postgres, reprend la structure proposée par mon message #4.

Ensuite, ton interface en PHP devra, lors de la saisie d'un nouvel enregistrement :
1) Créer la ligne dans la table mère
2) Récupérer l'id inséré (il doit y avoir une fonction pour ça adaptée à Postgres)
3) Créer la ligne dans la table fille
4) Créer la ligne dans la table associative

Tout se passe sur le serveur et l'utilisateur n'y voit que du feu, il croit avoir inséré une seule ligne de données. C'est à ça que ça sert les interfaces homme-machine