Bonjour,
Envoyé par
LB
Je trouve tout de même bizarre qu'en créant un champ sous forme d'entier, celui-ci ressorte Null et non vide.
Le fait que vous trouviez bizarre qu'en créant un champ sous forme d'entier, celui-ci ressorte Null et non vide, est la conséquence que vous vous en tenez à la logique binaire traditionnelle (en passant, « vide » n’est pas un entier).
En fait, Null impose la mise en oeuvre d’une logique ternaire.
L’équipe de Don Chamberlin (IBM Research Laboratory, San Jose, CA) a défini le langage SQL, d’abord baptisé SEQUEL en 1974, puis SEQUEL 2 en 1976. A cette occasion, le marqueur Null (que j’ai surnommé bonhomme Null) a fait l’objet d’un soin particulier dans l’article de 1976 (SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control), car y figurent les tables de vérité dont on a besoin pour connaître le comportement des opérations auxquelles participe le bonhomme Null : ces tables de vérité sont celles d’une logique ternaire.
Rappelons-nous d’abord des tables de vérité de la bonne vieille logique binaire, exprimant le comportement des opérateurs logiques ET, OU, NON :
1 2 3 4 5
|
ET | vrai | faux
—————|——————|——————
vrai | vrai | faux
faux | faux | faux |
1 2 3 4 5
|
OU | vrai | faux
—————|——————|——————
vrai | vrai | vrai
faux | vrai | faux |
1 2 3 4 5
|
NON | vrai
—————|——————
vrai | faux
faux | vrai |
La présence du bonhomme Null exige désormais la mise en œuvre d’une logique ternaire (et les soucis commencent...)
Selon cette logique, les valeurs de vérité ne sont plus seulement vrai et faux, il faut leur adjoindre une troisième, symbolisée ci-dessous par « ?? ». Les tables de vérité évoluent donc, et je reprends celles de l’article de 1976 (et toujours en vigueur quel que soit le SGBD SQL, du moins peut-on l’espérer !) :
1 2 3 4 5 6
|
ET | vrai | faux | ??
—————|——————|——————|——————
vrai | vrai | faux | ??
faux | faux | faux | faux
?? | ?? | faux | ?? |
1 2 3 4 5 6
|
OU | vrai | faux | ??
—————|——————|——————|——————
vrai | vrai | vrai | vrai
faux | vrai | faux | ??
?? | vrai | ?? | ?? |
1 2 3 4 5 6
|
NON | vrai
—————|——————
vrai | faux
faux | vrai
?? | ?? |
Avec cette logique trivaluée, il y a des tautologies qui n’en sont plus, telle celle-ci : SI p ALORS p au cas où p est inconnu. Par exemple : « Si je chante alors je chante » n’est plus une évidence. Même chose pour une contradiction telle que p ET NON p : « Je chante et je ne chante pas » n’est plus une contradiction. De la même façon, dans le cas du biconditionnel, p SI ET SEULEMENT SI p, on retrouve les mêmes problèmes : « Je chante si et seulement si je chante » n’est plus une tautologie.
La référence en en ce qui concerne les logiques multivaluées, Nicholas Rescher in Many-Valued Logic rappelle que l’équivalence doit être réflexive, c'est-à-dire que p SI ET SEULEMENT SI p est nécessairement vrai, pour toutes les valeurs de p, contrainte qui est violée si la valeur de vérité de p est i (inconnue). On peut toujours s’essayer a utiliser d’autres tables de vérité : on débouche sur de nouveaux problèmes de tautologies.
=> L’optimiseur de votre SGBD peut fournir des résultats faux, à tout le moins vous faire commettre des erreurs.
Pour approfondir le sujet, je vous renvoie à l’ouvrage de Chris Date : Date on Database: Writings 2000-2006, au chapitre 18 « Why three - And four-valued logic don’t work ».
A leur tour, les résultats des opérations arithmétiques sont influencés par la présence du bonhomme Null. Si z symbolise un nombre et @ symbolise un opérateur tel que +, -, X, /, la situation est inévitablement la suivante :
1 2 3
|
z @ Null = Null ; Null @ z = Null ; Null @ Null = Null; |
Ainsi, si l’on ne connaît pas la TVA à appliquer à un montant hors taxe, on ne sait pas calculer le montant TTC correspondant et le résultat du calcul doit être marqué Null, sous peine de mentir. Moralité, dans nos bases de données on doit tout faire pour ne pas se trouver dans cette situation, la TVA à appliquer doit toujours être connue, c’est un problème de modélisation. Plus généralement, lors de la codification d’une instruction CREATE TABLE, si pour tout attribut d’une table vous ne codez pas « NOT NULL », c’est à vos risques et périls (ou plutôt ceux de la base de données...)
De la même façon, les opérateurs d’agrégation, SUM, AVG, MAX, etc. donnent lieu à des résultats pouvant surprendre, mais dans lesquels le bonhomme Null à son rôle à jouer...
Etc.
Partager