Je me suis laissé dire qu'une clé étrangère ne peut pas etre null; c'est vrai ?
Pourquoi ?
Version imprimable
Je me suis laissé dire qu'une clé étrangère ne peut pas etre null; c'est vrai ?
Pourquoi ?
Bien sûr que c'est vrai !!!
Car par essence, elle doit référencer une valeur de la clé primaire de la table dont elle dépend.
Mais si j'ai une entité
A qui "peut contenir" une entité B (agrégation)
Comme j'ai la proposition (peut contenir) on a 0 ou 1 B. Donc dans le cas de 0 je fais comment ? A référence B, mais B peut exister sans A (aggrégation)
Je suis un pro modélisation object mais pas base de données donc ca me pose des problèmes de compréhension.
SI j'ai bien compris ton exemple, c'est A qui peut exister sans B, et non l'inverse.
Tu dis "A peut contenir B", mais je rajoute que "A peut aussi ne pas contenir B" (au sens Merise).
Par contre, si B existe, il est forcément contenu par A.
La clé primaire est dans A, la clé étrangère dans B...
Mais en faite si je comprends bien en modélisation de table on choisi pas la navigation qu'on veut.
J'ai une voiture (A) qui peut avoir un moteur (B). (Je suis dans une casse par exemple). Donc la classe A contient un attribut moteur. Si je retire le moteur, l'attribut=null;
A et B peuvent donc exister indépendamment.
Si je te comprend pour respecter le problème de null comme clé étrangère, il faut que ce soit le moteur qui référence la voiture donc de (B vers A). en faite meme pas il faut d'office une table d'association représentant le lien entre les deux.
Enfin en somme il ne faut pas penser comme en UML. Pour les référencements entre tables. Si je veux reconstruire une instance voiture et son moteur, avec mon DAO. Je parse la table voiture avec son immatriculation, et ensuite la table moteur avec la clé étrangère pointant sur l'ID du moteur.
Autre question: est ce que une clé étrangère peut etre redondante ?
Une clé étrangère peut être nulle et représenter la cardinalité 0-x en modélisation.
Elle peut aussi être redondante si tu ne définis pas un index unique dessus.
Pour ton exemple, tu peux tout imaginer :
- soit tu dis qu'une voiture et un moteur peuvent exister indépendamment (cardinalité 0 - n), dans ce cas là pourquoi parler de clé étrangère ?
- soit tu dis qu'une voiture est obligatoirement équipée d'un moteur, et inversement qu'un moteur appartient à une voiture et une seule, dans ce cas la moteur est un simple attribut de l'entité voiture.
- soit tu dis qu'une voiture peut ne pas avoir de moteur, mais que par contre un moteur appartient forcément à une voiture et une seule (cardinalité 1 - 1), donc dans ce cas l'entité Moteur contient un champ id_voiture qui est clé étrangère reférençant la clé primaire id_voiture de l'entité Voiture, et donc ce champ est obligatoirement renseigné.
En clair, le problème n'est pas de savoir si une clé étrangère peut être nulle (ce n'est pas possible au niveau des SGBD), c'est plutôt de se poser la question d'en mettre une ou pas selon justement si on a une relation 0 - n (voire 1 - n) ou 1 - 1.
Quand vmolines dit "Une clé étrangère peut être nulle et représenter la cardinalité 0-x en modélisation.", il précise bien en modélisation. Quand tu vas passer au modéle physique dans le SGBD, ce ne sera plus possible d'avoir du null si tu as créé la clé étrangère.
Cela dit, en disant cela, vmolines s'écarte déjà des règles de l'art, car j'irai même plus loin : en remontant aux sources de Merise (que j'ai appris avec des vieux gourous il y a 15 ans), la notion de clé étrangère n'existe pas dans le modèle logique, c'est une conséquence automatique des cardinalités 1 - 1 lorsqu'on passe vers le modèle physique : on appelle ça une intégrité référentielle (c'est d'ailleurs comme ça, en respectant scrupuleusement cette règle, que des outils de modélisation comme AMC Designor peuvent générer automatiquement les clés primaires lors de la création des scripts)
Voici un autre exemple, qui est un cas d'école : toute facture dans un magasin référence un client. Si tu ne veux pas mettre la clé sous la porte, tu ne peux pas envisager une seule seconde avoir une autre cardinalité que 1 - 1 de facture vers client, donc tu vas créer la clé étrangère.
Dans ton exemple, le débat est plus ouvert, c'est pour ça que je dis que tu dois adapter ton modèle physique en fonction des règles de gestion arrêtées finalement.
C'est tout à fait possible aussi sur le modèle physique. J'ai parlé de modélisation mais je n'ai pas réduit la possibilité à la simple modélisation.Citation:
Envoyé par dgi77
Une clé étrangère peut très bien être définie avec le champ nullable.
Exemple tout bête pour une arborescence en auto-référence :
T_ElementArbre = {idElement, Libelle, #idElementParent}
Une FK peut être définie entre idElementParent et idElement. idElement doit et peut être défini comme nullable pour un éléments racine.
L'intégrité référentielle fonctionnera et empèchera d'avoir une ligne avec un idElementParent qui ne référence aucun idElement existant. Par contre on pourra avoir idElementParent à Null sans violer l'intégrité définie par la FK.
Ton exemple n'est pas tout bête : il s'agit d'une auto-référence. C'est un cas très particulier qui s'apparente aux chaînages, et effectivement le premier père n'a pas de père lui-même.
Par contre, je n'ai jamais testé si ce que tu dis est vrai, mais je suis curieux de savoir sur quel SGBD tu l'as fait ?
Ok merci pour toutes ces précisions.
J'ai pris cet exemple pour ne pas avoir à déclarer 2 tables (moindre effort) mais il est tout aussi applicable à n'importe quelle FK même sans auto référence.Citation:
Envoyé par dgi77
Je n'ai pas une énumération précise des SGBD sur lesquels j'ai utilisé des FK nullables mais je n'ai pas souvenir d'avoir été gêné pour ça. Le dernier en date est actuellement SQL Server.
Une clef étrangère peut heureusement parfaitement être null. En effet une voiture peut avoir un conducteur, mais heureusement que lorsque l'on la gare on n'est pas obligé de rester au volant !!!!!
A +
moi je le fais sous postgresql par exemple...Citation:
Envoyé par dgi77
la contrainte FK permet surtout de vérifier les contraintes d'intégrité référentielle
...le nullable est en plus en fonction des cas, mais n'est pas une condition préalable de la contrainte