PostGreSQL est il un vrai SGBD Relationnel ? Au regard des règles de Codd et des réflexions de Chris Date, il semblerait que non.
Voici quelques éléments qui vous permettrons d’apprécier les limites de PostGreSQl et de trouver certains moyens de contournement.

En octobre 1985, Franck Edgard Codd, père fondateur des bases de données relationnelles édictait, à travers deux articles
de vulgarisation du magazine Computerworld (Is your DBMS really relational ? et Does your DBMS run by the rules ?), douze règles
formalisent la notion de SGBD relationnel.
Ces règles de (numérotés de 0 à 12, donc en fait treize…) formalisent la notion de SGBD relationnel et gravent ainsi dans le
marbre les 13 commandements de la Loi pour tout SGBD se prétendant relationnel.
A lire : les règles de Codd pour les SGBD Relationnels

D’où la question : PostGreSQL est-il un vrai SGBD Relationnel ?

NOTA : test effectués avec la version : « PostgreSQL 9.1.3, compiled by Visual C++ build 1500, 32-bit »

1 Рpremier probl̬me

viol de la règle de CODD n°7 – Insertion, suppression et modification ensemblistes :
 »
Le SGBDR retourne un ensemble d’éléments en réponse aux requêtes qui lui sont
soumises. Il doit pouvoir mettre à jour un ensemble d’éléments en exécutant une seule
requête.
« 

CREATE TABLE T_UNIK (C INT CONSTRAINT PK PRIMARY KEY); 

 

INSERT INTO T_UNIK VALUES (1), (2), (3); 

 

SELECT * FROM T_UNIK; 

 

UPDATE T_UNIK 

SET C = C + 1; 

 

********** Erreur ********** 

 

ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « t_unik_pkey » 

État SQL :23505 

Détail :La clé « (c)=(2) » existe déjà.

Cette requête passe sur Oracle, MS SQL Server, IBM DB2, etc…

En fait PostGreSQL ne sait pas faire des mises à jour ensembliste et agit itérativement.
Cependant, PostGreSQL fournit une rustine pour ce faire, en permettant de vérifier la contrainte en fin de transaction…
Mais il faut reconstruire la table (pas de ALTER TABLE … ALTER CONSTRAINT … DEFERRABLE INITIALLY DEFERRED);
Voici la solution de contournement :

DROP TABLE T_UNIK; 

 

CREATE TABLE T_UNIK (C INT CONSTRAINT PK PRIMARY KEY DEFERRABLE INITIALLY DEFERRED); 

 

INSERT INTO T_UNIK VALUES (1), (2), (3); 

 

UPDATE T_UNIK 

SET C = C + 1; 

 

SELECT * FROM T_UNIK 

 

C 

----------- 

2 

3 

4

Le problème principal est que PostGreSQL n’est pas capable de faire des requêtes portant directement sur des ensembles de données et fonctionne de manière itérative, c’est à dire, ligne à ligne et vérifie les contraintes à chaque UPDATE monoligne, contrairement à ses grand ancêtres, qui eux fonctionnent proprement !
Cette limitation est inhérente à la conception technique de PostGreSQL qui n’est pas capable de faire des requêtes mutilthreadées, c’est à dire de lancer plusieurs processus pour traiter une seule et même requête, en d’autre termes, exécuter chacune des tâches du plan de requête de manière parallèle (ce que font Oracle ou SQL Server de manière naturelle).
Mais cette solution de contournement est en contradiction apparente avec une autre règle de Codd :

RÈGLE 12 – Non subversion :
 »
Il ne doit pas être possible de transgresser les règles d’intégrité et les contraintes définies par le langage relationnel du SGBDR en utilisant un langage de plus bas niveau (gérant une seule ligne à la fois)
« 

Bref, peut-on parler de vrai SGBD relationnel au sens de Codd ?
À l’évidence NON !

Mais poussons un peu les tests…

2 – Test de « compréhension » du moteur relationnel.

Dans un papier de 2004 intitulé « A Cure for Madness » , Chris Date attire l’attention sur le fait que toute requête doit être évaluée logiquement par l’optimiseur, avant d’être traitée syntaxiquement et d’être exécutée.

Voici un exemple tiré de l’exemple posté par Codd :

CREATE TABLE T_CHRIS_DATE (TYP CHAR(4), VAL VARCHAR(16)); 

 

INSERT INTO T_CHRIS_DATE VALUES 

('NUM', '1234'), 

('ALFA', 'ecfs'), 

('NUM', '4567'), 

('NUM', '11'), 

('ALFA', 'rtg'), 

('ALFA', 'yfc'), 

('NUM', '9'), 

('ALFA', 'pkn');

Recherchons les nombres supérieurs à 1000

code>SELECT *
FROM   T_CHRIS_DATE
WHERE  VAL > 1000;

********** Erreur **********

ERREUR: l'opérateur n'existe pas : character varying > integer
État SQL :42883
Astuce : Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
Caractère : 41

Sur ce point tous les SGBDR se ressemblent et génèrent une erreur !
Mais l’erreur n’est pas du tout la même sur les autres SGBDR qui font une erreur de conversion bien normale…
Tout cela n’est pas bien grave, car le principe est que l’on ne mélange pas les choux et les carottes, or SQL est un langage typé, il faut soit considérer des chaines de caractères soit des entiers, pas les deux.

Mais nous avons la chance dans cette table que des chaînes de caractères, bien que typées comme telles représentent en fait des nombres et de surcroit un critère dans la colonne TYP permet de les distinguer.
Il suffit donc de faire :

SELECT * 

FROM   T_CHRIS_DATE 

WHERE  TYP = 'NUM' 

  AND  VAL > 1000;

Malheureusement, alors que cette requête est correctement exécutée sur Oracle, IBM DB2 ou SQL Server, PostGreSQL s’avère incapable de produire le même résultat !

Il persiste dans sa fausse erreur, qui la confine à la bêtise !

Qu’à cela ne tienne, obéissons lui et castons (Lagaffe !)

SELECT * 

FROM   T_CHRIS_DATE 

WHERE  TYP = 'NUM' 

  AND  CAST(VAL AS INT) > 1000;

Finalement PostGreSQL s’en sort bien :

TYP      VAL 

-------- ---------- 

NUM      1234 

NUM      4567

Mais récrivons cette requête autrement :

SELECT * 

FROM   T_CHRIS_DATE 

WHERE  CAST(VAL AS INT) > 1000 

  AND  TYP = 'NUM';

Bravo, il ne tient justement pas compte de l’ordre des prédicats dans la clause WHERE, tout comme ses grands ainés !

Essayons encore une autre version :

SELECT * 

FROM   (SELECT * 

        FROM   T_CHRIS_DATE 

        WHERE  TYP = 'NUM') AS T 

WHERE  CAST(VAL AS INT) > 1000;

Pas beaucoup de mérite, mais bien quand même… Essayons encore une autre approche :

SELECT * 

FROM   (SELECT * 

        FROM   T_CHRIS_DATE 

        WHERE  CAST(VAL AS INT) > 1000) AS T 

WHERE  TYP = 'NUM';

Formidable, tout comme ses grand frères, PostGreSQL a récrit la requête interne, normalement infaisable, par algébrisation afin de la rendre opérationnelle.
C’est un remarquable progrès, car il y a encore quelques années PostGreSQL n’était pas capable d’une telle prouesse.

CONCLUSION

Si l’on ne peut pas encore parler de véritable SGBDR, par le fait que la règle 7 de Codd est mal implémentée, on peut dire quze fonctionnellement on s’en rapproche à grand pas et au moins une solution de contournement est produite pour ceux qui veukent passer du monde commercial au monde libre.
Il reste cepandant encore quelques points que je qualifierait de « durs » avec MySQL, notamment en ce qui concerne la règle 11 concernant le partitionnement des tables.
En effet, la solution de partitionnement des tables à la sauce PostGreSQL est tout sauf exploitable et les performances en sont globalement plus que piètre et souvent moins bonne qu’une solution de table non partitionnée (voir les discussions interne sur ce délicat sujet « Table partitioning« ), ainsi que les nombreuses complaintes sur l’exploitation du partitionnement mode PG dans les forums de discussions)

En fait il y a même tromperie sur la marchandise, car ce qui est présenté comme un partitionnement n’est autre que de la fédération de tables, ce que la plupart des SGBDR faisaient il y a bien longtemps (pour une explication de la différence de ces deux concepts, voir la 4e édition de mon ouvrage sur SQL, collection Synthex, Pearson Eduction, paris Juin 2012).

RÈGLE 11 – Indépendance de distribution :
 »
Le langage relationnel doit permettre aux programmes d’application et aux requêtes de demeurer identiques sur le plan logique lorsque des données, quelles qu’elles soient, sont physiquement réparties ou centralisées.
« 

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *