Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

Règle numero 7 de codd


Sujet :

Décisions SGBD

  1. #1
    Membre averti
    Règle numero 7 de codd
    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.

  2. #2
    Expert éminent sénior
    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/

  3. #3
    Membre averti
    Merci pour le lien. J'ai tout compris

  4. #4
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  5. #5
    Expert éminent sénior
    MySQL c'est sans surprise, mais PG même en V12 déroge à la règle 7, fou ça !

  6. #6
    Expert éminent sénior
    Citation Envoyé par SQLpro Voir le message
    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 ?


     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Membre averti
    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.

  8. #8
    Rédacteur

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

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  9. #9
    Expert éminent sénior
    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...




     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  10. #10
    Expert éminent sénior
    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 ?

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #11
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

###raw>template_hook.ano_emploi###