Discussion :

[champomy62]

Salut,


J'ai consulté:
https://sgbd.developpez.com/actu/87330/Les-12-regles-de-Codd-le-pere-du-modele-relationnel-de-donnees/

mais comme je suis pas sur d'avoir tout compris, j'en viens a demander une explication un peu plus claire sur cette fameuse règle numéro 7:

Règle 7
Insertion, mise à jour, et effacement de haut niveau :
Le système doit supporter les opérations par lot d'insertion, de mise à jour et de suppression. Ceci signifie que des données peuvent être extraites d'une base de données relationnelle dans des ensembles constitués par des données issues de plusieurs tuples et/ou de multiples table. Cette règle explique que l'insertion, la mise à jour, et les opérations d'effacement devraient être supportées aussi bien pour des lots de tuples issues de plusieurs tables que juste pour un tuple unique issu d'une table unique.

Parle-t-on de la regle énoncé par C.J Date: "the relational closure property" (We can write nested relational expressions ...) ?

Merci.

[escartefigue]

consultez l'article de SQLPro sur ce sujet, un exemple y est donné pour chacune des règles et notamment la R7
https://sqlpro.developpez.com/SGBDR/ReglesCodd/

[champomy62]

Merci pour le lien. J'ai tout compris

[SQLpro]

En particulier vous constaterez que ni MySQL ni PostgreSQL ne supportent cette règle. Ce ne sont donc pas des SGBD Relationnel au sens de Codd.

A +

[escartefigue]

MySQL c'est sans surprise, mais PG même en V12 déroge à la règle 7, fou ça !

[fsmrel]

En particulier vous constaterez que ni MySQL ni PostgreSQL ne supportent cette règle. Ce ne sont donc pas des SGBD Relationnel au sens de Codd.

Quelle démonstration, quelles preuves avancer pour affirmer que tel ou tel SGBD SQL est bien conforme à la règle 7 ?


 

[champomy62]

Effectivement dans le document que SQLPRO a écrit, l'exemple donné échoue sur PG12 puisqu'il est adapté a SQL SERVER.

En modifiant un peu l'exemple il est possible de mettre à jour l'ensemble des données avec l'instruction SQL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
 
CREATE TABLE T_SET (VAL INT);
ALTER TABLE T_SET ADD CONSTRAINT t_set_val_key UNIQUE(val) DEFERRABLE;
 
BEGIN;
 
INSERT INTO T_SET VALUES (-8)
INSERT INTO T_SET VALUES (-7)
INSERT INTO T_SET VALUES (-6)
INSERT INTO T_SET VALUES (-5)
INSERT INTO T_SET VALUES (-4)
INSERT INTO T_SET VALUES (-3)
INSERT INTO T_SET VALUES (-2)
INSERT INTO T_SET VALUES (-1)
INSERT INTO T_SET VALUES (0)
INSERT INTO T_SET VALUES (1)
INSERT INTO T_SET VALUES (2)
INSERT INTO T_SET VALUES (3)
INSERT INTO T_SET VALUES (4)
INSERT INTO T_SET VALUES (5)
INSERT INTO T_SET VALUES (6)
INSERT INTO T_SET VALUES (7)
INSERT INTO T_SET VALUES (8)
 
UPDATE T_SET
SET VAL = POWER(VAL, 3)
 
COMMIT;

La seule chose ici qui change est la manière de créer l'index.

[SQLpro]

Ceci devrait pouvoir être fait sans déferrer la contrainte !

A +

[fsmrel]

Si je code ainsi (PostgreSQL V10) :

CREATE TABLE T_SET 
(
        VAL         INT      NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (VAL) 
);

INSERT INTO T_SET VALUES 
      (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
    , (1), (2), (3), (4), (5), (6), (7), (8)
;  

UPDATE T_SET
    SET VAL = POWER(VAL, 3)
;
 SELECT '' as après, * FROM T_SET ;

Il est un fait que l’UPDATE part en sucette :

« ERROR: ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « t_set_pk »
DETAIL: La clé « (val)=(8) » existe déjà. »

Mais si je code ainsi l’INSERT :

 
INSERT INTO T_SET VALUES 
      (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
    , (8), (7), (6), (5), (4), (3), (2), (1)
;  

Alors on obtient un résultat correct :



Ce qui montre que PostgreSQL a tendance à effectuer les calculs bien séquentiellement, dans l’ordre où il a inséré les lignes et ça saipabien, moteur à améliorer oserai-je dire...




 

[fsmrel]

Toujours avec PostgreSQL V10, si VAL est l’objet d’une clé alternative, alors le résultat n’est pas plus brillant :

CREATE TABLE T_SET 
(
        ID          SERIAL          
     ,  VAL         INT             NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (ID) 
    , CONSTRAINT T_SET_AK UNIQUE (VAL) 
);

INSERT INTO T_SET (VAL) VALUES  
      (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
    , (1), (2), (3), (4), (5), (6), (7), (8)
;  

UPDATE T_SET
    SET VAL = POWER(VAL, 3)
;

=>

« ERROR: ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « t_set_ak »
DETAIL: La clé « (val)=(8) » existe déjà. »

Si VAL n’est l’objet d’aucune clé, alors le résultat est correct :

CREATE TABLE T_SET 
(
        ID          SERIAL          
     ,  VAL         INT             NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (ID) 
);

INSERT INTO T_SET (VAL) VALUES  
      (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
    , (1), (2), (3), (4), (5), (6), (7), (8)
;  

UPDATE T_SET
    SET VAL = POWER(VAL, 3)
;

=>


Au tour de MySQL (v 5.7) : si VAL est clé primaire, MySQL se comporte comme PostgreSQL :

CREATE TABLE T_SET 
(
        VAL         INT             NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (VAL) 
);

INSERT INTO T_SET (VAL) VALUES 
       (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
     , (1), (2), (3), (4), (5), (6), (7), (8)
;  

UPDATE T_SET
    SET VAL = POWER(VAL, 3)
;

=>

« Error Code: 1062. Duplicate entry '8' for key 'PRIMARY' »

Si avec MySQL, VAL fait l’objet d’une clé alternative, une fois encore ça n’est pas brillant :

CREATE TABLE T_SET 
(
        ID          INT             NOT NULL AUTO_INCREMENT 
      , VAL         INT             NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (ID) 
    , CONSTRAINT T_SET_AK UNIQUE (VAL) 
);

INSERT INTO T_SET (VAL) VALUES 
       (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
     , (1), (2), (3), (4), (5), (6), (7), (8)
;
 
UPDATE T_SET
    SET VAL = POWER(VAL, 3)
; 

=>

« Error Code: 1062. Duplicate entry '8' for key 'T_SET_AK' »

Mais comme PostgreSQL, MySQL a au moins la décence de bien se comporter quand VAL ne fait l’objet d’aucune clé :

CREATE TABLE T_SET 
(
        ID          INT             NOT NULL     AUTO_INCREMENT 
      , VAL         INT             NOT NULL
    , CONSTRAINT T_SET_PK PRIMARY KEY (ID) 
);

INSERT INTO T_SET (VAL) VALUES 
       (-8), (-7), (-6), (-5), (-4), (-3), (-2), (-1), (0)
     , (1), (2), (3), (4), (5), (6), (7), (8)
;  

UPDATE T_SET
    SET VAL = POWER(VAL, 3)
;

=>




Un des deux SGBD se serait-il inspiré de l’autre ?

 

[SQLpro]

Il fonctionnement tous les deux selon un principe itératif et valident les transactions en mode ligne à ligne par rapport aux contraintes posées sur la base. Ce que ne font ni DB2, ni Oracle ni SQL Server qui sont transactionnellement conformes !

En fait il faut toujours valider les contraintes après la mise à jour et avant le COMMIT.

Je confirme ce que je disais au sujet de ces deux SGBD, ils ne sont pas relationnels.
Le pire c'est que MySQL n'a même pas de catalogue système ce qui fait que les transactions de tous les utilisateurs sont auto validées en cas de requête DDL !

A +