Bonsoir,
Citation:
Envoyé par
dodidam
j'aurais voulu savoir quelles conséquences avez-vous pu observer de l'utilisation du marqueur NULL au sein des bases de données ?
Dans les applications archi testées je n’ai pas observé de bugs flagrants produits par les SGBD que j’ai secoués. Cela dit, je modélise de telle sorte que chaque colonne de chaque table de chaque base de données soit accompagnée de la clause NOT NULL. Mais je n’ai pas accès aux « relations » intermédiaires créées sous le capot à partir d’une requête puisque le SGBD ne montre pas la structure de leur en-tête et je croise les doigts avant de valider la relation finale fournie en résultat. Ces « relations » intermédiaires doivent être de même nature que celles dont elles sont issues, leurs parents — sinon elles relèveraient de la tératologie —, on appelle cela le principe de fermeture, mais je ne suis pas bien sûr que les fabricants de SGBD aient clairement cela en tête.
Si vous vous reportez ici (après la photo de Naf-Naf) aux paragraphes traitant des tables de vérité en logique trivaluée (celle de SQL) relatives au conditionnel SI p ALORS q, (qui se ramène à (NON p) OU q) et au biconditionnel p SI ET SEULEMENT SI q, on voit que l’optimiseur du SGBD peut fournir des résultats faux. Pour approfondir, je vous renvoie aux ouvrages de Date et Darwen, par exemple Date on Database: Writings 2000-2006, au chapitre 18 « Why three - And four-valued logic don’t work ».
Je rappelle en passant que le théorème de Heath ne vaut plus quand NULL est présent, alors que ce théorème est au cœur de la décomposition des schémas de relation : la décomposition d’une relation n’est plus sans perte.
Je rappelle aussi que les colonnes appartenant au schéma d’une table permettent de construire le prédicat de cette table. Ainsi, à partir de l’instruction :
Code:
1
2
3
4
5
6
7
8
|
CREATE TABLE PERSONNE
(
PsnId INT NOT NULL
, PsnNom VARCHAR(48) NOT NULL
, PsnTel VARCHAR(24) NOT NULL
, CONSTRAINT PSN_PK PRIMARY KEY (PsnId)
) ; |
On déduit le prédicat à trois places (paramètres) :
La personne PsnId a pour nom PsnNom et pour téléphone PsnTel.
Mais qu’advient-il si la colonne PsnTel de la table PERSONNE peut être marquée NULL ? On a affaire à un autre prédicat, à seulement deux places cette fois-ci :
La personne PsnId a pour nom PsnNom, elle a peut-être le téléphone, mais nous ne savons rien à ce sujet.
Or le prédicat d’une variable relationnelle (relvar, informellement table) ne peut être à la fois à deux et à trois places (sauf à l’asile de fous ou dans un monde quantique). En vertu de quoi, la table PERSONNE est à décomposer :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
CREATE TABLE PERSONNE
(
PsnId INT NOT NULL
, PsnNom VARCHAR(48) NOT NULL
, CONSTRAINT PSN_PK PRIMARY KEY (PsnId)
) ;
CREATE TABLE TELEPHONE
(
PsnId INT NOT NULL
, PsnTel VARCHAR(24) NOT NULL
, CONSTRAINT PSN_PK PRIMARY KEY (PsnId)
) ; |
D’où le prédicat relatif à la table PERSONNE :
(P1) La personne PsnId a pour nom PsnNom.
Et le prédicat relatif à la table TELEPHONE :
(P2) La personne PsnId a pour téléphone PsnTel.
Sinon, je retiens que NULL est collant, tel un bout de scotch au bout du doigt et dont on n’arrive pas à se débarrasser : on est obligé d’utiliser des fonctions ad-hoc pour bricoler et éviter les pièges : COALESCE, NULLIF, IS NULL, ...
Revoyez la discussion à propos de « Sum(X+Y) = Sum(X) + Sum(Y) ? ».
Un sympathique point d’orgue offert ici par J1 est édifiant et significatif, car on y voit que NULL ça peut être de la dynamite à ne pas confier à des mains inexpérimentées.
Ceux qui font la norme SQL (voyez ici) arrivent à se vautrer lamentablement en établissant une équivalence entre la valeur de vérité UNKNOWN et NULL qui n’est pas une valeur ! Au royaume des NULL...
Bref, à la manière de Fernand Naudin (in Les tontons flingueurs), je dirais que le bonhomme NULL me les brise menu...
