postgre 10 -notion de clé étrangere

Bonjour

Concept de cle étranger

voici la vision table tbr_0110 est lié à tbr_0120 par le champ Code_tbr_0110 .
La table tbr_0110 et tbr_0110_a de légere différence sont les clé primaire
Pour ces 2 tables les champs suivant sont fixes.
Type_enr ='0110'
Drapeau = 'C'

Pour les 4 champ suivant la valeur est unique (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) raison de sa définition de cle primaire pour la table tbr_0110_a.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

CREATE TABLE tbr_0110 ( Type_enr varchar(4) , Drapeau varchar(1), Code_tbr_0110 varchar(10) NOT NULL PRIMARY KEY , Date_debut DATE, Date_fin DATE, Libelle varchar(50) );   CREATE TABLE TRB_GE_0120 ( Type_enr varchar(4), Drapeau varchar(1), Code_tbr_0110 varchar(10), Code_tbr_0120 varchar(10), Date_debut DATE, Date_fin DATE, Description varchar(250), Ordre_vente INTEGER, nb_de_valeur INTEGER, CONSTRAINT TRB_GE_0120_PK PRIMARY KEY (Code_tbr_0110 , Code_tbr_0120 , Date_debut ) , FOREIGN KEY(Code_tbr_0110) REFERENCES tbr_0110 (Code_tbr_0110) );

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

CREATE TABLE tbr_0110_a ( Type_enr varchar(4) , Drapeau varchar(1), Code_tbr_0110 varchar(10) , Date_debut DATE, Date_fin DATE, Libelle varchar(50), CONSTRAINT tbr_0110_PK PRIMARY KEY (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) );   CREATE TABLE tbr_0120_a ( Type_enr varchar(4), Drapeau varchar(1), Code_tbr_0110 varchar(10), Code_tbr_0120 varchar(10), Date_debut DATE, Date_fin DATE, Description varchar(250), Ordre_vente INTEGER, nb_de_valeur INTEGER, CONSTRAINT tbr_0120_a_pk PRIMARY KEY (Type_enr , Drapeau ,Code_tbr_0110 , Code_tbr_0120 , Date_debut ) , FOREIGN KEY(Code_tbr_0110) REFERENCES tbr_0110_a (Code_tbr_0110) );

---

mon problème est sur la définition FOREIGN KEY dans tbr_0120_a , la creation de la table tbr_0120_a.

Le système refuse de définir la clé étrangere car il ne s'agit pas d'un clé primaire de la table tbr_0110_a.

alors pourquoi ne pas utiliser les champs de la cle primaire de la table tbr_0110_a (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) et bien parce que le contenu des champs Date_debut et Date_fin sont des valeurs unique à chaque table .

on peu ainsi avoir
table tbr_0110_a

Type_enr	Drapeau	Code_tbr_0110	Date_debut	Date_fin	Libelle
'0110'	'c'	'TAX456'	01/01/2010	null	valeur des codages TAX456
'0110'	'c'	'XME16'	01/01/2015	null	valeur des ecarts

table tbr_0110_a

Type_enr	Drapeau	Code_tbr_0110	Code_tbr_0120	Date_debut	Date_fin	Description	Ordre_vente	nb_de_valeur
'0120'	'c'	'TAX456'	'Oker77'	01/02/2011	31/12/2013	Traitement des informations	1	22
'0120'	'c'	'TAX456'	'OPER456'	01/01/2015	31/12/2017	Traitement des affectation	2	17
'0120'	'c'	'XME16'	'Aw15'	01/01/2010	null	Traitement operation complexe	1	33

Quelle serait selon vous la FOREIGN KEY a creer pour tbr_0120_a ?

Comment creer un lien entre ces 2 tables ?

Votre modèle est complétement foireux. C'est la raison pour laquelle vous n'arrivez à rien. Commencez par un MCD au lieu de foncer sur le MPD et les CREATE TABLE. Expliquez nous clairement et de manière conceptuel ce que vous voulez faire avec des mot et non pas des codes... tbr_010, tbr_020 ne signifie rien. En matière de bases de données, les noms sont importants....

A +

Citation:

---

Envoyé par dedalios

Concept de cle étranger

---

La clef étrangère est, comme son nom l'indique, héritée d'une clef primaire issue d'une autre table
Il convient donc de commencer par définir correctement la clef primaire dans la table en question et c'est loin d'être le cas ici

Pour commencer, pourquoi mettre en table des valeurs constantes ?

Citation:

---

Envoyé par dedalios

Pour ces 2 tables les champs suivant sont fixes.
Type_enr ='0110'
Drapeau = 'C'

---

Si vraiment ces deux attributs ou colonnes (il n'y a pas de champ dans une table) ont une valeur constante et que ce sera le cas sur la durée de vie de la database, inutile de les stocker.

De plus, un identifiant primaire doit être unique, stable et concis, or
- vous avez choisi un identifiant primaire sur plusieurs colonnes : l'identifiant n'est pas concis
- vous avez choisi un identifiant primaire qui utilise des colonnes (var)char : l'identifiant est potentiellement instable et qui plus est, sensible à la collation et encombrant

Citation:

---

Envoyé par dedalios

Pour les 4 champ suivant la valeur est unique (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) raison de sa définition de cle primaire pour la table tbr_0110_a.

---

Ajoutez un identifiant technique de type integer et attribué par le SGBD ("generated by default as identity") qui garantira l'unicité, la concision et la performance de votre PK

Citation:

---

Envoyé par escartefigue

La clef étrangère est, comme son nom l'indique, héritée d'une clef primaire issue d'une autre table

---

C'est souvent un peu oublié, mais une contrainte d'unicité suffit à être la référence d'une clef étrangère.

Citation:

---

Envoyé par Waldar

C'est souvent un peu oublié, mais une contrainte d'unicité suffit à être la référence d'une clef étrangère.

---

Yes ;) mais l'idée ici c'est qu'il faut corriger le problème à sa source :)

Citation:

---

Envoyé par SQLpro

Votre modèle est complétement foireux. C'est la raison pour laquelle vous n'arrivez à rien. Commencez par un MCD au lieu de foncer sur le MPD et les CREATE TABLE. Expliquez nous clairement et de manière conceptuel ce que vous voulez faire avec des mot et non pas des codes... tbr_010, tbr_020 ne signifie rien. En matière de bases de données, les noms sont importants....

A +

---

Les termes utilisés sont malheureusement volontairement des codes pour des questions de non divulgation . Et je ne dispose ni du MPD ni du MCD mais des données brutes hors ce que je vous présente c'est la forme de ces donnée brutes .

Il faut que j'en construise le modele cela afin de le comparer a un second modele pour lequelle je ne dispose aussi que des données.

Code:

---

1 2 3 4

Pour ces 2 tables les champs suivant sont fixes. Type_enr ='0110' Drapeau = 'C'

---

Ceci n'est pas totalement vrai ; ce projet oui sur les donnée fournies seront fixe et contenu das les fichiers a convertir (donc peut être effectivement a supprimer du MPD / MCD
Pour ces 2 tables les champs suivant sont fixes.
si Type_enr ='0110' est fixe , Drapeau = a plusieurs valeurs possible .

Bonsoir,


dedalios, vos structures de tables sont à aménager. La table tbr_0110_a possède une clé candidate qui intrigue :

{Type_enr , Drapeau ,Code_tbr_0110 , Date_debut}

Pour aller dans le sens des sages, escartefigue et Waldar, et travailler dans les règles de l’art, vous devriez ajouter un attribut tbr_110_Id, de type INTEGER (ou SERIAL de préférence, mais peu importe) sans aucune signification et invariant. Cet attribut serait utilisé pour une clé supplémentaire, alternative (alternate key) :

Code:

---

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

CREATE TABLE tbr_0110_a ( tbr_110_Id integer, Type_enr varchar(4) , Drapeau varchar(1), Code_tbr_0110 varchar(10) , Date_debut DATE, Date_fin DATE, Libelle varchar(50), CONSTRAINT tbr_0110_PK PRIMARY KEY (Type_enr , Drapeau , Code_tbr_0110 , Date_debut), CONSTRAINT tbr_0110_AK UNIQUE (tbr_110_Id) ) ;

---

Le mieux serait de permuter les rôles des deux clés tbr_0110_PK et tbr_0110_AK, mais dans un 1er temps on peut rester en l’état.

Définissez le même attribut tbr_110_Id dans l’autre table, et c’est lui qui servira pour la clé étrangère ; vous lui définissez également un attribut, tbr_120_Id, pour une clé supplémentaire {tbr_120_Id}, laquelle a tout intérêt à devenir clé primaire, tandis que l’autre clé (actuellement primaire) devient alternative : sitôt dit, sitôt fait :

Code:

---

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

CREATE TABLE tbr_0120_a ( tbr_110_Id integer, tbr_120_Id integer, Type_enr varchar(4), Drapeau varchar(1), Code_tbr_0110 varchar(10), -- devrait disparaître ! Code_tbr_0120 varchar(10), Date_debut DATE, Date_fin DATE, Description varchar(250), Ordre_vente INTEGER, nb_de_valeur INTEGER, CONSTRAINT tbr_0120_a_PK PRIMARY KEY (tbr_120_Id), CONSTRAINT tbr_0120_a_AK UNIQUE (Type_enr , Drapeau ,Code_tbr_0110 , Code_tbr_0120 , Date_debut ) , FOREIGN KEY(tbr_110_Id) REFERENCES tbr_0110_a (tbr_110_Id) );

---

Eliminez de tbr_0120_a les attributs que l’on sait retrouver par jointure des deux tables (et définissez une vue de jointure au besoin). Le ménage a une incidence sur tbr_0120_a_AK (disparition par exemple de Code_tbr_0110, au bénéfice de tbr_120_Id) mais cette « clé » à 5 attributs vérifie-t-elle bien l’irréductibilité des clés candidates ? Seules les règles de gestion des données permettent de le savoir, car elles sont notamment utilisées pour constituer l’ensemble des dépendances fonctionnelles sources des clés des tables.

Tout comme escartefigue et Waldar, je ne prétends pas résoudre votre problème précis, on n’en sait pas assez quant aux règles de gestion des données (données primitives, données dérivables, pertinence des clés), mais au moins vous donner une idée des structures vers lesquelles devraient rendre vos tables.

Tant qu’à faire, ajoutez « NOT NULL » pour chaque attribut de chaque table. Méditez aussi ce qu’a écrit Yves Tabourier au sujet des identifiants significatifs (voyez ici).

Une 1re pour moi : le VARCHAR(1)...

Effectivement créer des clés primaires automatiques est une solution interressante. Le problème par contre est de conservé la clé primaire pour injecté les donnée dans la table suivante , est accéssoirement faire de même pour 4 tables lié est le reste mais effectivement je ne vois pas d'autre solution.


le VARCHAR(1) est simplement du a une transformation d'un type TEXT(1) TEXT(25)....etc.

Utiliser une vue pour éliminer de tbr_0120_a les attributs présent dans tbr_0110. Effectivement c'est la solution mais je n'irais pas jusque la, le but n'est pas de réellement construire une base propre mais un processus de comparaison.


Plus qu'a modifier les programmes d'alimentation
merci

Create table avec une clé primaire sur une colonne de type serial, ok, mais comment récupérer l'identifiant unique après avoir effectué une insertion en table, car de fait le champ n'est pas saisi à l'insertion...

Citation:

---

Envoyé par dedalios

Create table avec une clé primaire sur une colonne de type serial, ok, mais comment récupérer l'identifiant unique après avoir effectué une insertion en table, car de fait le champ n'est pas saisi à l'insertion...

---

Bonjour

Tu peux demander un insert into table values (..., ...) returning xxx ("xxx" étant le nom de ta colonne serial). La valeur du serial te sera donc retournée.

Moi, personnellement, je ne passe pas par un serial mais par une sequence créée manuellement (create sequence "seq_toto" etc etc etc). Ensuite, j'affecte cette sequence à la colonne que je veux mettre en serial (create table "toto" ("id_toto" integer not null default nextval('"seq_toto"')) puis alter sequence "seq_toto" owned by "toto."."id_toto" (cette dernière n'est pas primordiale mais je trouve ça plus propre)).
A la base ça revient au même (la colonne récupèrera la valeur de la séquence lors de l'insert tandis que la séquence s'incrémentera). Mais ça m'offre des possibilités en plus. Comme par exemple demander un select currval('"seq_toto"') ce qui me donne alors la valeur courante (donc la dernière valeur) de ma séquence.

A partir de là, ce que je fais moi (mais en prog donc à partir d'un langage qui va interfacer Postgres): je demande d'abord un select nextval('"seq_toto"'). Ca me donne un n° utilisable et unique tandis que la sequence s'incrémente pour un autre insert ultérieur. Ensuite, j'intègre ce n° dans mon insert. Ben oui, ce n'est pas parce que le champ n'est pas à saisir qu'on n'a pas le droit de quand-même le saisir. Et donc c'est comme si j'avais eu un serial sauf que comme c'est moi qui l'ai d'abord manuellement demandé, je l'ai toujours en main et je peux ensuite m'en resservir (c'est surtout quand j'insère dans diverses tables liées entre elles)...

Create séquence similaire à Oracle donc.

OK

Bon ce qui veux dire que les insert sont à réaliser un enregistrement par un enregistrement.
Qu’il n'est pas possible de réalisé x insert si l'on a besoin de l'information de ce champ comme foreign key pour la table ou est la susdite foreign key. je vais donc pose mon schéma plus global.


alter sequence "seq_toto" owned by "toto."."id_toto" cette partie est plus nébuleuse.. pourquoi modifier les droits sur la séquence??

Citation:

---

Envoyé par dedalios

Create séquence similaire à Oracle donc.

OK

Bon ce qui veux dire que les insert sont à réaliser un enregistrement par un enregistrement.

---

Rien ne vous empêche de générer plusieurs valeurs de clef en une seule instruction, mais la difficulté est de savoir à quelle ligne sera attribuée la clef n°1 et ainsi de suite.

A +