Relation réflexive composant/composé

Bonjour,
J'ai dans ma base de données postgres des dosages qui sont utilisés pour fabriquer d'autre dosages, c'est en gros une relation mère fille mais il peut y en avoir 3 de suite ou plus:

Code:

---

1 2 3 4 5 6 7 8

create table definition_fabrication ( id serial primary KEY, num_dosage character varying(20));   create table definition_acceleration( id_acc integer references definition_fabrication, id_na integer references definition_fabrication, primary key(id_acc, id_na));

---

De là, j'aimerai récupérer pour la clause WHERE de ma requête entière, l'id de tous les numéros de dosage qui sont liés à un autre numéro de dosage (peu importe si c'est du coté mère ou fille ou lui-même) .

Code:

---

1 2 3 4 5 6 7

select distinct df.id from definition_fabrication df left join definition_acceleration da inner join definition_fabrication df2 on df2.id = da.id_na or df2.id = da.id_acc on df.id = da.id_na or df.id = da.id_acc where df.num_dosage ='22/11/346' or df2.num_dosage ='22/11/346'

---

Le problème est que cette sous-requête ne marche que pour la relation direct mère fille et je me dis qu'il doit bien exister un moyen pour récupérer d'une manière plus générique tous les résultats mais je ne trouve pas...

Bonjour,
Si le niveau d'héritage n'est pas défini, il faut utiliser une requête récursive.

Tatayo.

Bonjour,

J'ai modifié le titre pour qu'il corresponde au contenu (une PK en double étant par définition impossible) : au niveau conceptuel il s'agit d'un cas classique de relation reflexive (type d'entité ou classe d'entité en association avec elle même), ce type de relation se traduisant en SQL par une requête récursive, dès que la profondeur dépasse deux ou trois niveaux.

À noter : la syntaxe complète d'une contrainte FK désigne la table et la colonne référencée, et non pas la table seule
Je suppose qu'en l'absence de nom de colonne, c'est la colonne de même type et de même longueur qui est choisie, mais c'est risqué...

constraint nom_contrainte foreign key(ma_colonne) references nom_autre_table(nom_autre_colonne).
Avec facultativement les actions à effectuer en cas de suppression (ON DELETE) et de modification (ON UPDATE).

À noter également : dans le cas d'une relation composant/composé comme ici, on a en général besoin d'un attribut quantité dans la table associative pour savoir combien de composants sont requis pour fabriquer le composé.

Merci,

A vrai dire, j'apprends tout par moi même donc je ne connaissais pas le vocabulaire et par conséquent je ne pouvais pas l'écrire dans le titre. :)
Je ne savais même pas comment l'exprimer pour le trouver sur le net, c'est pour ça que j'ai essayé ici.

Pour ce qui est de la non précision de la colonne, en posgresql, il n'est pas nécessaire de préciser la colonne si c'est la clé primaire de la table citée.
Pour ce qui est du ON DELETE ou ON UPDATE, je gère tout par un script python qui s'occupe de cette base de données. Pour être plus précis, cette base de données et une "concaténation" récupérant et organisant des données provenant de 2 bases postgresql, un base sqllite, une base access 2000 et de 2 "bases" dbf... (vive les logiciels indépendants qui écrivent tous dans leur propre base de données)

Pour ce qui est de la quantité, en fait, un mélange est composé d'une liste d'ingrédients qui font parti d'une formule d'incorporation détaillée temporellement. Dans cette liste il peut y avoir un nom générique d'un dosage et vu que c'est du 1 pour 1, alors je n'ai pas mis de quantité.
Il n'est absolument pas nécessaire de savoir quel nom générique est présent où, surtout que ce nom peut varier pour un même dosage...

En tous cas merci, je vais pouvoir me pencher dessus quand j'aurai plus de temps!

cordialement.

Voici une modélisation conceptuelle simplifiée d'un cas composant/composé (réalisée avec l'excellent Looping :))

Pièce jointe 621122

et le DDL correspondant (ici sans les options ON DELETE / ON UPDATE)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

CREATE TABLE AR_article( AR_ident INT IDENTITY, AR_reference CHAR(8) NOT NULL, AR_description VARCHAR(50) NOT NULL, PRIMARY KEY(AR_ident), UNIQUE(AR_reference) );   CREATE TABLE CO_composer( AR_ident_composant INT, AR_ident_composé INT, CO_qte DECIMAL(11,4) NOT NULL, PRIMARY KEY(AR_ident_composant, AR_ident_composé), FOREIGN KEY(AR_ident_composant) REFERENCES AR_article(AR_ident), FOREIGN KEY(AR_ident_composé) REFERENCES AR_article(AR_ident) );

---

Citation:

---

Envoyé par tatayo

Bonjour,
Si le niveau d'héritage n'est pas défini, il faut utiliser une requête récursive.

Tatayo.

---

Merci beaucoup, c'était le mot de vocabulaire qu'il me manquait! (et que je n'arrivais pas à m'exprimer clairement pour le trouver...)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

with recursive toto (id) as ( select id from definition_fabrication df3 where df3.num_dosage ='22/11/346' union select df.id from definition_fabrication df inner join ( select id_na, id_acc from definition_acceleration da inner join toto df2 on df2.id = da.id_na or df2.id = da.id_acc) reqb on df.id = reqb.id_na or df.id = reqb.id_acc) select id from toto

---

Sinon merci mais pour la création des tables, je n'avais pas de soucis et puis personnellement, je ne mets jamais d'accent dans un nom de colonne.

Citation:

---

Envoyé par Chichen

je ne mets jamais d'accent dans un nom de colonne.

---

En effet, c'est nettement préférable, c'est une erreur d'inattention !