chronologie et logique relationnelle [Résolu]

[AIRONE]

Bonjour
Voici mes relations, tout est logique , mais chronologiquement parlant c'est pas vraiment le cas...
je m'explique:
lorsque je créer un bon à mon client j'ai obligatoirement un chantier (1-n pas de pb), mais je ne veux pas le facturer tout de suite alors:
dois je supprimer la relation 1-n de (facture-bon) dans le cas contraire j ai le message d erreur "enregistrement requis"
est il possible de la céer qu'au moment de la transaction pour la facturation
Pour info dans un premier temps j'avais créer une table supplémentaire appelée bonfacture et lorsque je facturais je transférait les bons concernés par la facture dans cette table, çà marche bien mais j'essaye de trouver un solution qui éviterai une redondance dans mes données et limiterai sérieusement les risques d'incohérence entre ces deux tables
J'espère avoir été le + clair possible
Merci pour votre aide (éventuel j'en suis conscient),

[AIRONE]

Pour dire les choses autrement, la relation (1-n) entre la table facture et la table bon ne doit être active que lorsque la coche "facturé" de ma table "bon" est cochée
Dois je absolument utilisé une autre table et faire des transferts
ou est il possible de créer une relation entre une table et une requête

Je sais que la conception de la base est la clef de la réussite du projet je ne veux pas me planter à cette étape, merci pour votre coup de pouce...

[micniv]

lorsque je créer un bon à mon client j'ai obligatoirement un chantier (1-n pas de pb), mais je ne veux pas le facturer tout de suite alors:
dois je supprimer la relation 1-n de (facture-bon) dans le cas contraire j ai le message d erreur "enregistrement requis"

Dans ce cas tu peux faire une relation 0 - n : tous les enreg de la table des bons et seulement les factures qui correspondent .

Isn't it ?

[AIRONE]

bonjour, merci pour ton aide
j ai testé ce type de jointure mais j'obtiens toujours le même message d erreur "enrg requis ds la tbl facture" par contre ma relation affiche toujours 1-n comment faire pour avoir 0-n???

[AIRONE]

En fait il l'intégrité référentielle n'a pas l'air compatible avec ce genre de relation, je l'ai décoché j'ai une relation 1 n qui est acceptée.
Je vais voir ce cela donne plutard en attendant je met le tag [resolu] car ta réponse répond parfaitement à mon interrogation
encore merci pour ton aide , je peux enfin continuer et me creuser très certainement la tête sur une nouvel problematique

[Maxence HUBICHE]

Ceci n'est pas une bonne solution.

J'ai jeté un oeil sur ton modèle, et il me semble d'un compliqué !!!!
Normalement, tu devrais avoir l'intégrité référentielle SYSTEMATIQUEMENT dans ton modèle. Donc, si tu l'enlèves, tu crées une faille dans la validité de tes données.

J'essaie d'approfondir ton modèle, et je reviens vers toi !

[Maxence HUBICHE]

Bon, alors, je pense que déjà, si on met 2 petits points à niveau, tu auras moins de soucis avec l'intégrité référentielle.


Définitions :

1. L'intégrité référentielle est un mécanisme de vérification qui s'assure que pour chaque valeur présente dans la clé étrangère, il y a toujours une valeur qui lui corresponde dans la clé primaire qui lui est jointe.
2. NULL n'est pas une VALEUR, mais un TAG, un drapeau indiquant que la valeur n'est pas connue. Le sens de ce tag est : "Je ne sais pas"

Ces définitions indiquent que ce mécanisme va vérifier l'existence de VALEURS PRÉSENTES dans la clé étrangère.

Donc, si le NULL n'est pas interdit dans ta table, sur la clé étrangère (Propriété du champ / Null Interdit :Oui/Non) , tu peux avoir un NULL. Mais, par contre, si tu ajoutes l'intégrité référentielle sur ta relation, tu ne pourras pas inscrire dans la clé étrangère une valeur qui n'existe pas dans la clé primaire.

Illustrons avec tes bons et factures.
Imaginons que Bons!numfacture soit défini avec un Null Interdit à Non
Dans ce cas, tu peux créer un bon sans pour autant connaître la facture associée. Rien ne t'empèchera d'inscrire le n° de la facture ultérieurement.
Si la propriété avait été définie à Oui, alors là, par contre, dès que tu crées le bon, tu DOIS connaître le numéro de facture associé.
Si tu mets, en plus, l'intégrité référentielle en marche sur ta relation entre Bons et Factures, alors forcément, lorsque tu inscris un numfacture, tu DOIS inscrire un numfacture qui existe au préalable dans la table Factures.

Ceci expliqué, il n'y a pas de cas, dans ton modèle (me semble-t-il) qui nécessitent la suppression de l'intégrité référentielle.

Par contre, il y a un paquet de trucs que je ne comprends pas dans ton modèle !
Par exemple, le BON, c'est quoi ? Y a-t-il un rapport avec la LIVRAISON ? Si oui, pourquoi n'est-il pas en relation avec la LIVRAISON ? D'ailleurs, en parlant de LIVRAISON, pourquoi chaque commande est liée à plusieurs LIVRAISON ? Ca n'a pas beaucoup de sens... à moins que tu aies voulu dire que tu pouvais livrer une COMMANDE en plusieurs LIVRAISON. Mais dans ce cas, il y a bien une erreur : tu ne livres pas LA COMMANDE, mais plutôt les ARTICLES de la COMMANDE. Donc, LVRAISON devrait être attaché à ARTICLES, et non à COMMANDE.
J'en ai plein d'autres encore...
Ce que je peux affirmer sans aucun doute, c'est qu'en l'état, ton modèle ne me plaît pas du tout et me semble abherrant. Mais je me trompe peut-être (enfin, je l'espère pour toi )

A Plus !