Bonsoir,
Tant qu’on en reste à l’aspect structurel des choses, faire intervenir NULL ça ne mange pas de pain, mais quand on prend en compte les aspects manipulation et intégrité, ça se gâte.
Envoyé par
MacFly58
En fait, ce qui me pose problème, c'est le cas d'une relation binaire de type 0,1 - 0,n. Je comprends l'intérêt de créer une table associative pour éviter les clés étrangères NULL, mais cela me semble aller à l'encontre de ce qui préconisé dans la scolarité de nos futurs informaticiens. La règle habituellement enseignée me semble être :
"L'identifiant de l'entité "père" devient un attribut de la table "fils". Cet attribut est une clé étrangère."
Tout d'abord, NULL est interdit de séjour dans la théorie relationnelle (familièrement Relationland). Maintenant, si les enseignants enseignent ce qu'ils veulent, de leur côté les ingénieurs s’engagent vis-à-vis de la maîtrise d’ouvrage dans les entreprises quant à la validité du contenu de la base de données. Que l’on enseigne les mêmes approximations et erreurs depuis plus de vingt ans est une chose, s’engager comme je le fais en tant que spécialiste des bases de données en est une autre et j'adhère évidemment à la théorie (et je vous laisse deviner ce que j’enseigne quand cela m’arrive).
Par ailleurs il ne semble pas que tous les professeurs aient la même position, voyez par exemple la discussion ouverte par Nico128. Au cours de cette discussion, j’ai écrit :
Envoyé par
fsmrel
La théorie relationnelle serait mise en échec si l’on y acceptait le Bonhomme NULL, lequel est accessoirement un inhibiteur pour l’optimiseur d’un SGBDR, car les lois de transformation utilisées pour rendre les requêtes plus performantes sont mises en échec (une équivalence telle que r JOIN r ≡ r qui est au cœur de ces lois ne vaut plus ; A = B et B= C n’implique plus que A = C, etc.) Vous comprendrez que je respecte scrupuleusement la théorie relationnelle...
Prenons le cas du théorème de Heath, omniprésent dans la normalisation des bases de données :
Si la relation R (A, B, C) satisfait à la dépendance fonctionnelle A → B, alors R peut être décomposée selon ses projections R1 (A, B) et R2 (A, C), avec préservation du contenu de la base de données, c'est-à-dire que l’on retrouve très exactement R par la jointure naturelle de R1 et de R2.
Ce théorème ne tient plus si A peut prendre des valeurs nulles. Par exemple, si R est ainsi représentée ainsi :
1
2
3
4
|
R ( A, B, C )
a1 b1 c1
NULL b2 c2 |
Les projections R1 et R2 sont les suivantes :
1
2
3
4
|
R1 ( A, B ) R2 ( A, C )
a1 b1 a1 c1
NULL b2 NULL c2 |
Et la jointure naturelle de R1 et R2 n’est pas égale à R :
1
2
3
|
R’ ( A, B, C )
a1 b1 c1 |
Un exemple de lecture intéressante, avec l' intervention de deux grands spécialistes des bases de données relationnelles, Hugh Darwen et Fabian Pascal :
A propos de la norme SQL :
The data type boolean comprises the distinct truth values
True and
False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value
Unknown as the null value. This specification does not make a distinction between the null value of the boolean data type and the truth value
Unknown that is the result of an SQL <predicate>, <search condition>, or <boolean value expression>; they may be used interchangeably to mean exactly the same thing.
Questions :
Peut-on dire que NULL = NULL ?
A quoi ressemble le résultat de NULL * NULL, de NULL / 0 ?
Etc., etc., etc.
problème de référence circulaire
Répondre avec citation
MCD.jpg)
Partager