Problème CONSTRAINT FOREIGN KEY avec NO ACTION [Résolu]

[kaouane]

Bonsoir tout le monde;
Je veux ajouter une contrainte de clé étrangère à ma table, mais sans lui accorder d'action de suppression ou de mise à jour;
J'écris pour cela :

Code :

ALTER TABLE LIVRAISONS_PRD ADD CONSTRAINT FK_LIVRAISONS_PRD1 FOREIGN KEY (PRODUIT) REFERENCES PRODUIT(COD_PROD) ON DELETE NO ACTION ON UPDATE NO ACTION;

mais j'obtiens le message d'erreur :

violation of FOREIGN KEY constraint "FK_LIVRAISONS_PRD1" on table "LIVRAISONS_PRD"
Foreign key reference target does not exist

[TryExceptEnd]

Envoyé par kaouane

J'écris pour cela :

Code :

ALTER TABLE LIVRAISONS_PRD ADD CONSTRAINT FK_LIVRAISONS_PRD1 FOREIGN KEY (PRODUIT) REFERENCES PRODUIT(COD_PROD) ON DELETE NO ACTION ON UPDATE NO ACTION;

C'est la bonne syntaxe, pas de problème.

Envoyé par kaouane

mais j'obtiens le message d'erreur :

Code :

C'est pars que la table LIVRAISONS_PRD n'est pas vide et qu'elle possèdent des valeurs dans le champs PRODUIT qui ne sont référencés dans la table PRODUIT(COD_PROD)

[kaouane]

Effectivement; mais quelle est la différence entre

Code :

ON DELETE cascade ON UPDATE cascade

et

Code :

ON DELETE no action ON UPDATE no action

Je pense que la dernière permet le fait :
- supprimer l'information de la table produit même si elle est référencée dans la table livraisons_prd ?

[seabs]

Bonjour,

Je vais essayer de te donner une explication.

Si tu as une table "FACTURE" et une table "LIGNE". Pour une facture, tu auras une plusieurs lignes de facture.

Dans ta table "LIGNE", l'index de la clé primaire de la table "FACTURE" va constituer une clé étrangère. Ainsi, quand tu appelles ta facture, tu connais toutes les lignes qui la compose.

Maintenant, tu décides de supprimer ta facture. Si dans ta table "LIGNE", tu as mis

Code :

ON DELETE no action ON UPDATE no action

lors de la mise en place de ta clé étrangère, tu ne pourras supprimer ta facture seulement et seulement s'il n'existe plus aucune ligne pour la facture que tu veux effacer. En résumé, il faut d'abord supprimer toutes les lignes puis la facture.

Par contre, si tu mets

Code :

ON DELETE cascade ON UPDATE cascade

En cas de suppression de la facture, la base de données effacera automatiquement les lignes de la facture et la facture.

Dans le premier cas tu fais toi-même, dans le second cas c'est la base qui assure le travail.

Bon après, il faut savoir pourquoi choisir l'une ou l'autre méthode. Mais il s'agit d'une autre histoire.

J'espère que mes explications seront suffisamment claires pour répondre à ta question.

A+

[kaouane]

Merci beaucoup seabs;
C'est très bien expliquer et je viens de le confirmer de l'article "le SQL de A à Z".
Cela veut dire que pour mon cas, je ne doit pas créer une contrainte de clé étrangère.
Mais comment implémenter un lien entre deux tables sans contrainte d'intégrité?

[Cl@udius]

Salut

Envoyé par kaouane

Mais comment implémenter un lien entre deux tables sans contrainte d'intégrité?

Comme ceci:

Code :

ALTER TABLE LIVRAISONS_PRD ADD CONSTRAINT FK_LIVRAISONS_PRD1 FOREIGN KEY (PRODUIT) REFERENCES PRODUIT(COD_PROD);

Tout simplement.

@+

[kaouane]

Merci Cl@udius;
Ca marche mais pour quelques tables ça ne marche pas et j'ai le message d'erreur :

violation of FOREIGN KEY constraint "FK_ROTATIONS1" on table "ROTATIONS"
Foreign key reference target does not exist

Peux tu m'orienter sur la cause probable?

[Cl@udius]

Re,

Foreign key reference target does not exist

Cela veut simplement dire que la relation n'a pu être définie parce que une ou plusieurs des clés n'ont pu être trouvées dans la table maître.

Exemple bateau: un code client saisi dans une table Facture avec un code inexistant dans la table Client.

Pour résoudre il suffit d'effectuer une requête de non-concordance pour isoler la/les clés incriminées.

Voiloù.

@+ Claudius.

[kaouane]

Cela veut dire que mon problème n'a pas de solution;
c-a-d que je ne peut pas représenter une relation entre deux tables sans contrainte d'intégrité.

Par exemple je veux créer une table journal_vente qui référence à une table clients; mais sans empêcher l'utilisateur de supprimer les clients.
Le journal peut contenir des informations relatives à un client qui a été supprimer.

[seabs]

Bonjour,

Je comprends pas bien le sens de ta question, en général un journal ventes fait référence à des factures, lesquelles sont en relation avec la table des clients.

Pour revenir à ton exemple, je ne vois pas pourquoi tu veux supprimer des clients sans supprimer les écritures dans le journal-ventes. Cette approche te conduit à posséder les lignes orphelines dans ta table Journal-Ventes. Quelle utilité, car tu ne peux plus les rapprocher des clients ?

Exposes ce que tu veux réellement faire, il y a peut être une autre solution.

J'espère que j'ai compris ta demande.

A+

[kaouane]

Bonjour seabs;
Tu as très bien compris mas question et je te remercie pour les remarques.
Peu importe ce que je veux faire de ma question, la conclusion c'est qu'il ne peut pas y avoir de relation entre deux tables sans qu'il y ai une contrainte.
Je pense que je ne me trompe pas

[seabs]

Bonjour,

Il est toujours possible de supprimer une contrainte liée à une clé étrangère. Pour cela il faut écrire :

Code :

ALTER TABLE LIVRAISONS_PRD ADD CONSTRAINT FK_LIVRAISONS_PRD1 FOREIGN KEY (PRODUIT) REFERENCES PRODUIT(COD_PROD) ON SET NULL ON UPDATE SET NULL;

Dans cette situation, tu peux supprimer ta ligne LIVRAISONS_PRD sans supprimer ton produit. Mais cette approche ne représente pas une situation réelle car nous sommes, à mon avis, en présence d'une conception de base de données mal conçue et qui n'est pas normalisé. Dans mon exemple de facture, tu pourrais supprimer la facture sans supprimer les lignes.

Pour t'éclairer sur le sujet, tu peux lire l'article de SQLPro à cette adresse http://sqlpro.developpez.com/contrai...aintes_SQL.pdf

Pour informations, voici un extrait :

1.4 But des contraintes

Mais enfin, quel est l'intérêt des contraintes ? Assurer l'intégrité et la cohérence des
données. Sans contrainte une base de données est rapidement incohérence et faiblement
intègre. La redondance y est commune et la qualité des données piètre. Toute chose qui
condamne la base de données à une évolution incertaine, une mort lente et surtout à un
coût exorbitant du traitement des données.

J'espère avoir répondu, approximativement, à ta question.

A+

[kaouane]

Merci beaucoup seabs pour ta réponse complète et surtout pour le lien que tu as poster.
Effectivement, je pense que nous somme devant le cas suivant :

Envoyé par seabs

car nous sommes, à mon avis, en présence d'une conception de base de données mal conçue et qui n'est pas normalisé.

Je dois revoir la conception pour répondre aux besoins.