Je me suis laissé dire qu'une clé étrangère ne peut pas etre null; c'est vrai ?
Pourquoi ?
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.
Partager