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
    Profil pro
    Inscrit en
    mars 2010
    Messages
    315
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 315
    Points : 359
    Points
    359
    Par défaut 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

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 293
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 293
    Points : 15 656
    Points
    15 656
    Billets dans le blog
    1
    Par défaut
    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
    Profil pro
    Inscrit en
    mars 2010
    Messages
    315
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 315
    Points : 359
    Points
    359
    Par défaut
    Merci pour le lien. J'ai tout compris

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 394
    Points : 46 066
    Points
    46 066
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 293
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 293
    Points : 15 656
    Points
    15 656
    Billets dans le blog
    1
    Par défaut
    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 924
    Points : 25 942
    Points
    25 942
    Billets dans le blog
    16
    Par défaut
    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
    Profil pro
    Inscrit en
    mars 2010
    Messages
    315
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2010
    Messages : 315
    Points : 359
    Points
    359
    Par défaut
    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
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 394
    Points : 46 066
    Points
    46 066
    Par défaut
    Ceci devrait pouvoir être fait sans déferrer la contrainte !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 924
    Points : 25 942
    Points
    25 942
    Billets dans le blog
    16
    Par défaut
    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 :

    Nom : codd_regle7_resultat.png
Affichages : 83
Taille : 14,4 Ko

    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
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 924
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 924
    Points : 25 942
    Points
    25 942
    Billets dans le blog
    16
    Par défaut
    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)
    ;
    
    =>
    Nom : codd_regle7_pgg(val_is_not_key).png
Affichages : 78
Taille : 16,7 Ko

    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)
    ;
    
    =>

    Nom : champomy62_codd_regle7_mysql(val_is_not_key).png
Affichages : 80
Taille : 15,8 Ko


    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
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 394
    Points : 46 066
    Points
    46 066
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [À lire] Les règles de ce forum
    Par hiko-seijuro dans le forum C++Builder
    Réponses: 4
    Dernier message: 07/09/2009, 17h55
  2. Obligatoire : lisez les règles du forum : MAJ 06/08/2010
    Par Anomaly dans le forum Mode d'emploi & aide aux nouveaux
    Réponses: 0
    Dernier message: 03/07/2008, 14h46
  3. Règles d'utilisation des forums C
    Par Franck.H dans le forum C
    Réponses: 3
    Dernier message: 26/01/2008, 18h35
  4. [IMPORTANT] Rappel des règles
    Par Community Management dans le forum C++
    Réponses: 4
    Dernier message: 12/12/2006, 00h11
  5. [IMPORTANT] Rappel des règles
    Par Geronimo dans le forum Outils pour C & C++
    Réponses: 3
    Dernier message: 21/08/2005, 10h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo