SQL - Etienne ZINZINDOHOUE » SGBD

SQL Three-Valued Logic (3VL)

zinzineti — Wed, 08 Aug 2012 21:52:40 +0000

Soit les tables T1 et T2 suivantes :

create table T1 (col1 int)
create table T2 (col2 int)
insert into T1 select 1 union select 2 union select 3 union select null
insert into T2 select 4 union select 2 union select 5 union select null

Pourquoi la requête SELECT * FROM T1 WHERE col1 NOT IN (SELECT col2 FROM T2) ne renvoie aucune valeur alors que
SELECT * FROM T1 WHERE col1 IN (SELECT col2 FROM T2) renvoie la valeur 2 ?
Rappelons qu’une colonne affiche NULL lorsqu’elle ne contient pas de valeur. En SQL une opération de comparaison peut être avoir l’une des trois valeurs logiques suivantes : TRUE (vrai) ou FALSE (faux) ou UNKNOWN (inconnu). C’est ce qu’on a appelle « Three-Valued Logic » (3VL). Signalons qu’en mathématiques, l’algèbre de Boole est 2VL et ne connait donc que deux valeurs (VRAI ou FAUX). En SQL la valeur logique UNKNOWN est due à la présence de NULL dans une opération de comparaison.
Exemple :

——————————————————

p condition état logique

——————————————————

2 p IS NULL FALSE

——————————————————

2 p IS NOT NULL TRUE

——————————————————

NULL p IS NULL TRUE

——————————————————

NULL p IS NOT NULL FALSE

——————————————————

2 p = NULL UNKNOWN

——————————————————

2 p <> NULL UNKNOWN

——————————————————

NULL p = NULL UNKNOWN (pour SQL standard)

——————————————————

NULL p <> NULL UNKNOWN

——————————————————

NULL p = 2 UNKNOWN

——————————————————

NULL p <> 2 UNKNOWN

——————————————————

avec le tableau ci-dessus on peut constater que si l’un des opérandes est NULL alors l’opération de comparaison prend la valeur logique UNKNOWN. Pour déterminer si une expression est NULL (ou pas) il faut utiliser IS NULL (ou IS NOT NULL)

=> Algèbre Three-Valued Logic (3VL) et les opérateurs NOT, AND et OR
–> avec l’opérateur NOT
NOT TRUE = FALSE
NOT FALSE = TRUE
NOT UNKNOWN = UNKNOWN

–> avec l’opérateur AND
TRUE AND TRUE = TRUE
TRUE AND FALSE = FALSE
TRUE AND UNKNOWN = UNKNOWN

FALSE AND TRUE = FALSE
FALSE AND FALSE = FALSE
FALSE AND UNKNOWN = FALSE

UNKNOWN AND TRUE = UNKNOWN
UNKNOWN AND FALSE = FALSE
UNKNOWN AND UNKNOWN = UNKNOWN

–> avec l’opérateur OR
TRUE OR TRUE = TRUE
TRUE OR FALSE = TRUE
TRUE OR UNKNOWN = TRUE

FALSE OR TRUE = TRUE
FALSE OR FALSE = FALSE
FALSE OR UNKNOWN = UNKNOWN

UNKNOWN OR TRUE = TRUE
UNKNOWN OR FALSE = UNKNOWN
UNKNOWN OR UNKNOWN = UNKNOWN

=> UNKNOWN avec les clauses WHERE et CHECK
Dans une clause WHERE une expression évaluée comme UNKNOWN se comporte comme FALSE et dans ce cas aucune ligne n’est renvoyée.
Exemple :
select * from T1 where col1 not in (select col2 from T2)
Par contre dans une clause CHECK une expression évaluée comme UNKNOWN se comporte comme TRUE et l’expression est considérée comme valide
Exemple

create table T2 (col2 int , CONSTRAINT CHK CHECK (col2 < 10))
insert into T2 select 4 union select 2 union select null

— insertion réalisée

=> opération arithmétique avec NULL renvoie NULL et peut donc provoquer un état logique UNKNOWN lors d’une comparaison

SELECT 3 + null
SELECT 3 - null
SELECT 3 * null
SELECT 3 /null

=> La plupart des fonctions d’agregation ignorent NULL

select AVG(col2) from T2 -- donne (4+2)/2 = 3 ici null est ignoré
select COUNT(*) from T2 -- donne 4 : ici null n'est pas ignoré
select COUNT(col2) from T2 -- donne 3 : ici null est ignoré

=> Les opérateurs ensemblistes UNION,INTERSECT,EXCEPT n’ignorent pas NULL

select * from T1 UNION select * from T2
select * from T1 EXCEPT select * from T2
select * from T1 INTERSECT select * from T2

=> CASE expression : attention lorsque la clause ELSE n’est pas explicite ELSE NULL est rajouté !
Exemple

SELECT case col1
when 1 then 1
when 2 then 2
when 3 then 3
END
FROM T1

Les fonctions CASE, COALESCE, … permettent de traiter les NULLs afin d’obtenir les résultats escomptés.

——————–
Etienne ZINZINDOHOUE
——————–

SGBD CACHé

zinzineti — Tue, 12 Jul 2011 21:35:56 +0000

Cette semaine, lors de la présentation d’un produit (nouveau né du rachat de Nortel par AVAYA), j’ai posé la question suivante à la personne qui anime la séance :

Quel est le SGBD sur lequel repose le produit ?

elle me répond : c’est caché.

Je réplique en disant…. mais c’est caché et vous ne pouvez même pas nous donner le nom ?

Et elle dit : c’est ce que je viens de vous dire … c’est caché !

C’est à partir de ce moment que j’ai compris qu’il existe un SGBD qui a pour nom CACHé !

Un tour rapide sur internet m’a permis d’en savoir plus.

Voici une démo sur CACHé

———————————–
Etienne ZINZINDOHOUE
———————————–

Schema mal présenté dans SSMS

zinzineti — Thu, 14 Jul 2011 20:13:32 +0000

Depuis SQL SERVER 2005 la notion de schema de base de données a changé. Un schema est devenu donc un « namespace », un conteneur des objets de la base de données : Tables, Vues, Procédures, Fonctions, Triggers, Users,… Malgré cette définition claire de Microsoft on n’en voit pas la traduction dans la représentation affichée par SQL SERVER Management Studio (SSMS 2005, SSMS 2008, SSMS 2008R2). Une image est souvent plus parlant que de belles définitions…

Mettons en perspective les représentations de la notion de schema par SSMS et par RazorSQL

=> Pour une base système master vu par SSMS et RazorSQL

=> Pour une base « utilisateur » Adventureworks vu par SSMS et par RazorSQL

Avec cette représentation de schema par SSMS on comprend donc la confusion et le désordre dans l’écriture des requêtes, des procédures stockées, … désordre aussi dans l’écriture des DDLs.

Et le schema dbo (schema poubelle) est là pour qui aime le désordre et la confusion …

Je n’ai pas encore installé SQL11 (Denali), j’espère que la présentation de la notion de schema par SSMS Denali va être différente ?

=> Pour une base « utilisateur » Adventureworks vu par EMS SQL Manager

Cette présentation de la notion de schema par EMS SQL Manager (ou par SQLRazor) est plus réaliste que celle de SSMS de Microsoft.

————————————-
Etienne ZINZINDOHOUE
————————————-