IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Schéma Discussion :

relation ternaire et dates [MCD]


Sujet :

Schéma

  1. #1
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut relation ternaire et dates
    Bonjour,
    je dois établir une modélisation pour un stage.

    voici l'analyse sémantique :
    1 enseigne appartient à 1 groupe d’enseigne.
    1 groupe d’enseigne comprend 1 ou plusieurs enseignes.

    1 enseigne possède 0 ou plusieurs sous-groupes d’enseigne.
    1 sous-groupe d’enseigne appartient à 1 groupe d’enseigne

    Une promo est définie par un ensemble de critères qui sont réuni :

    Une promo a 1 seul nom d’opération
    Une promo concerne 1 ou plusieurs produits
    Une produit peut etre 0 fois, 1 fois ou plusieurs fois en promo
    Une promo détient 1 et 1 seul statut qui évolue dans le temps
    Une promo commence à 1 date et termine à 1 date
    Une promo s’applique sur 1 seule enseigne (national ) OU sur 1 sous-groupe d’enseigne ou périmètre ( régional, ou restreint )
    Une promo contient 1 type de promo ( type d’opération : prospectus, carte, fidélité )

    A la fin de la promotion, nous emettons 1 facture qui peut être réglé en plusieurs fois.
    Il faut acquitter chaque règlement jusqu’à clôturer la facture

    par rapport à ces définitions, j'etablis ce MCD :
    Nom : mcd 2.png
Affichages : 1503
Taille : 92,1 Ko


    je voulais savoir comment gérer la relation entre la promo et l'enseigne ou le sous-groupe d'enseigne auxquelles la promo peut s'appliquer d'après la regle :
    Une promo s’applique sur 1 seule enseigne (national ) OU sur 1 sous-groupe d’enseigne ou périmètre ( régional, ou restreint )

    et enfin, est-ce que les dates sont des attributs propre à une classe d'entité? ou l'on doit les gérer autrement ( via une autre table ? )

    Merci de votre aide.

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonjour jackherrer57,



    Votre ternaire « S’APPLIQUE » signifie ceci :

    La promo « p1 » s’applique à la fois à l’enseigne « e1 » et au sous-groupe « sg1 », autrement dit il faut casser cette ternaire en deux binaires et mettre en œuvre une contrainte d’exclusion (X) et totalité (T) :






    A ce propos, voici ce que dit la « norme » (journée Afcet du 15 novembre 1990) :




    Le problème est qu’avec Power AMC, vous ne pouvez pas définir cette contrainte , alors que c’est possible avec WinDesign . Au stade SQL, cette contrainte devra faire l’objet d’une assertion, en fait d’un trigger dans l’état des SGBDR à ce jour...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  3. #3
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    bonjour fsmrel

    merci pour cette réponse clair et précise.

    par contre je ne comprend pas pourquoi vous rajoutez "totalité"?
    dans ce cas j'aurais plutôt pensé à une contrainte de partition ( l'un ou l'autre mais pas les deux )

    je corrige une erreur : entre 'promo' et 'regler': la cardinalité est de 1,1.


    cordialement

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonsoir jackherrer57,


    Citation Envoyé par jackherrer57
    par contre je ne comprend pas pourquoi vous rajoutez "totalité"?
    dans ce cas j'aurais plutôt pensé à une contrainte de partition ( l'un ou l'autre mais pas les deux )
    « XT » symbolise le OU exclusif donc le partitionnement. C’est le symbolisme utilisé par WinDesign et je l’ai repris ici, en observant par ailleurs que PowerAMC ne propose rien.

    Quant à la prise en compte de la totalité, elle est la conséquence de la règle :

    « Une promo s’applique au moins et au plus une fois à une entité »

    Où « entité » est une enseigne ou un sous-groupe.

    Je propose ce MCD pour la partie qui nous intéresse (j’ai identifié l’entité-type SOUS_GROUPE relativement à ENSEIGNE dans la mesure où je formule l’hypothèse qu’un sous-groupe ne peut pas changer d’enseigne, mais si j’ai faux, je rectifierai) :





    Et le MLD dérivé :





    Dans le cadre de la théorie relationnelle, l’exclusion fait l’objet de la contrainte suivante :

    
    CONSTRAINT CONS_X1 IS_EMPTY
        { PROMO_ENSEIGNE {PromoId} INTERSECT PROMO_SOUS_GROUPE {PromoId} }
    
    

    De la même façon, la totalité fait l’objet de la contrainte :

    
    CONSTRAINT CONS_T1 IS_NOT_EMPTY
        { PROMO_ENSEIGNE {PromoId} UNION PROMO_SOUS_GROUPE {PromoId} }
    
    
    Dans le contexte de la norme SQL, l’exclusion et totalité font l’objet de l’instruction CREATE ASSERTION, laquelle peut laisser passer des erreurs en ce qui concerne la totalité, dans la mesure où les contrôles doivent être différés : entre le moment où l’on met à jour les tables concernées et le moment du contrôle, il peut se passer pas mal d’événements...


    Quant aux SGBD SQL (lequel est le vôtre ), on est obligé d’en passer par des triggers, ce qui permet de garantir l’exclusion, mais pas la totalité...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  5. #5
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    woouff , je m'incline.

    C'est bien un OU exclusif avec 'au moins et au plus un'.
    Et pour répondre aux autres question, en effet, un sous groupe ne changera pas d'entité et la base sera en mysql.

    merci fsmrel pour votre aide et ces précisions chirurgicales.

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut A propos de l'exclusion
    Bonjour jackherrer57,


    Ci-joint un script SQL pour la partie étudiée :

    
    CREATE TABLE ENSEIGNE
    (
            EnseigneId              INT              NOT NULL
          , EnseigneNom             VARCHAR(32)      NOT NULL
        , CONSTRAINT ENSEIGNE_PK PRIMARY KEY (EnseigneId)       
    ) ;
    
    CREATE TABLE SOUS_GROUPE
    (
            EnseigneId              INT              NOT NULL
          , SousGroupeId            INT              NOT NULL        
          , SousGroupeNom           VARCHAR(32)      NOT NULL
        , CONSTRAINT SOUS_GROUPE_PK PRIMARY KEY (EnseigneId, SousGroupeId) 
        , CONSTRAINT SOUS_GROUPE_ENSEIGNE_FK FOREIGN KEY (EnseigneId) REFERENCES ENSEIGNE (EnseigneId)
    ) ;
    
    CREATE TABLE PROMO
    (
            PromoId                 INT              NOT NULL        
          , PromoNom                VARCHAR(48)      NOT NULL
          , PromoDebut              DATE             NOT NULL  DEFAULT '2015-10-01'            
          , PromoFin                DATE             NOT NULL  DEFAULT '2015-10-15' 
          , CONSTRAINT PROMO PRIMARY KEY (PromoId) 
    ) ;
    
    CREATE TABLE PROMO_ENSEIGNE
    (
            PromoId                 INT              NOT NULL        
          , EnseigneId              INT              NOT NULL
        , CONSTRAINT PROMO_ENSEIGNE_PK PRIMARY KEY (PromoId) 
        , CONSTRAINT PROMO_ENSEIGNE_PROMO_FK FOREIGN KEY (PromoId) REFERENCES PROMO (PromoId)
        , CONSTRAINT PROMO_ENSEIGNE_FK FOREIGN KEY (EnseigneId) REFERENCES ENSEIGNE (EnseigneId)
    ) ;
    
    CREATE TABLE PROMO_SOUS_GROUPE
    (
            PromoId                 INT              NOT NULL        
          , EnseigneId              INT              NOT NULL
          , SousGroupeId            INT              NOT NULL
        , CONSTRAINT PROMO_SOUS_GROUPE_PK PRIMARY KEY (PromoId)
        , CONSTRAINT PROMO_SOUS_GROUPE_PROMO_FK FOREIGN KEY (PromoId) REFERENCES PROMO (PromoId)     
        , CONSTRAINT PROMO_SOUS_GROUPE_FK FOREIGN KEY (EnseigneId, SousGroupeId) REFERENCES SOUS_GROUPE (EnseigneId, SousGroupeId)
    ) ;
    
    

    Un bout de jeu d’essai :

    
    INSERT INTO ENSEIGNE (EnseigneId, EnseigneNom) VALUES
        (1, 'enseigne 1'), (2, 'enseigne 2'),(3, 'enseigne 3'),(4, 'enseigne 4')
    ;
    SELECT *  FROM ENSEIGNE ;   
    
    INSERT INTO SOUS_GROUPE (EnseigneId, SousGroupeId, SousGroupeNom) VALUES
        (1, 1, 'enseigne 1, sous-groupe 1'), (1, 2, 'enseigne 1, sous-groupe 2'), (1, 3, 'enseigne 1, sous-groupe 3')
      , (2, 1, 'enseigne 2, sous-groupe 1'), (2, 2, 'enseigne 2, sous-groupe 2'), (2, 3, 'enseigne 2, sous-groupe 3')
      , (3, 1, 'enseigne 3, sous-groupe 1'), (3, 2, 'enseigne 3, sous-groupe 2'), (3, 3, 'enseigne 3, sous-groupe 3')
      , (4, 1, 'enseigne 4, sous-groupe 1'), (4, 2, 'enseigne 4, sous-groupe 2'), (4, 3, 'enseigne 4, sous-groupe 3')   
    ;
    
    SELECT *  FROM SOUS_GROUPE ; 
    
    INSERT INTO PROMO (PromoId, PromoNom) VALUES
        (1, 'promo 1, pour enseigne 1'), (2, 'promo 2, pour sous-groupe 1 de enseigne 3')
      , (3, 'promo 3, pour sous-groupe 1 de enseigne 4'), (4, 'promo 4, pour enseigne 1')
      , (5, 'promo 5, pour enseigne 1'), (6, 'promo 6, pour sous-groupe 3 de enseigne 1')
      , (7, 'promo 7, pour sous-groupe 3 de enseigne 1'), (8, 'promo 8, pour enseigne 3')    
      , (9, 'promo 9, pour enseigne 2'), (10, 'promo 10, pour sous-groupe 3 de enseigne 3')
      , (11, 'promo 11, pour sous-groupe 2 de enseigne 3'), (12, 'promo 12, pour enseigne 2')    
      , (13, 'promo 13, pour personne !')
    ;
    
    SELECT *  FROM PROMO ;   
    
    INSERT INTO PROMO_ENSEIGNE (PromoId, EnseigneId) VALUES
        (1, 1), (4, 1), (5, 1), (8, 1), (9, 2), (12, 2)
    ;
    SELECT * FROM PROMO_ENSEIGNE ;
    
    INSERT INTO PROMO_SOUS_GROUPE (PromoId, EnseigneId, SousGroupeId) VALUES
        (2, 3, 1), (3, 4, 1), (6, 1, 3), (7, 1, 3), (10, 3, 3), (11, 3, 2)
    ;
    
    INSERT INTO PROMO_SOUS_GROUPE (PromoId, EnseigneId, SousGroupeId) VALUES
        (1, 1, 1)  -- délinquant !
    ;
    INSERT INTO PROMO_ENSEIGNE (PromoId, EnseigneId) VALUES
        (2, 1)  -- délinquant !
    ;
    
    

    Les triggers ci-dessous permettent de contrôler l’exclusion en INSERT (il faudrait coder les triggers correspondant aux UPDATE...)

    
    CREATE TRIGGER PromoEnseigeExclusionBeforeInsert BEFORE INSERT ON PROMO_ENSEIGNE 
    FOR EACH ROW
        BEGIN
             SET @K = (SELECT COUNT(*) 
                       FROM PROMO_SOUS_GROUPE 
                       WHERE PromoId = new.PromoId);
            IF @K > 0 THEN
    
                SET @ens = (SELECT EnseigneNom 
                            FROM   ENSEIGNE
                            WHERE  EnseigneId = new.EnseigneId) ;
    
                SET @sg = (SELECT y.SousGroupeNom 
                           FROM   PROMO_SOUS_GROUPE AS x JOIN SOUS_GROUPE AS y ON x.EnseigneId = y.EnseigneId AND x.SousGroupeId = y.SousGroupeId
                           WHERE  x.PromoId = new.PromoId) ;
    
                        SET @Erreur = CONCAT ('La promo d''identifiant  ''', new.PromoId, '''  pour l''enseigne <', @ens, '> est déjà affectée au sous-groupe <', @sg, '>.') ;
                        SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
            END IF ;
    
        END 
    GO 
    
    CREATE TRIGGER PromoSousGroupeExclusionBeforeInsert BEFORE INSERT ON PROMO_SOUS_GROUPE 
    FOR EACH ROW
        BEGIN
             SET @K = (SELECT COUNT(*) 
                       FROM PROMO_ENSEIGNE 
                       WHERE PromoId = new.PromoId);
            IF @K > 0 THEN
    
                SET @sg = (SELECT SousGroupeNom 
                           FROM   SOUS_GROUPE
                           WHERE  EnseigneId = new.EnseigneId AND SousGroupeId = new.SousGroupeId) ;
                             
                SET @ens = (SELECT y.EnseigneNom 
                            FROM   PROMO_ENSEIGNE AS x JOIN ENSEIGNE AS y ON x.EnseigneId = y.EnseigneId
                           WHERE  x.PromoId = new.PromoId) ;
    
                       SET @Erreur = CONCAT ('La promo d''identifiant  ''', new.PromoId, '''  pour le sous-groupe   <', @sg, '> est déjà affectée à l''enseigne <', @ens, '>.') ;
                       SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
            END IF ;
    
        END 
    GO 
    
    
    En passant, si telle ou telle réponse vous a été utile, n’hésitez pas à voter... Voire cliquer sur fsmrel, puis « Voir le profil Pro », puis « Confirmer les compétences » si vous jugez que quelque compétence il y a. La reconnaissance ça fait toujours plaisir...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  7. #7
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    merci merci, je n'en demandais pas tant, j'ai plus grand chose a faire du coup

    compétences confirmés, plus fort et plus complet que mon ancien prof de merise.
    Merci beaucoup encore

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonsoir jackherrer57,



    Citation Envoyé par jackherrer57
    j'ai plus grand chose a faire du coup
    Faut pas pleurer Jack, il y a encore du grain à moudre... Ne pensez-vous pas qu'il faudrait automatiser certains contrôles supplémentaires ? Que penser de cette instruction, laquelle passe allègremement au travers des mailles du filet ?

    
    INSERT INTO PROMO (PromoId, PromoNom, PromoDebut, PromoFin) VALUES
        (14, 'promo 14', '2015-11-01', '2015-10-25') ;
    
    

    En tout cas, merci pour les votes (Et peut-être aurez-vous encore la force de lever le pouce vert ?)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  9. #9
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    bonjour fsmrel,

    j'ai vu votre piege : date_fin < date_debut
    je dirais une contrainte de verification avec CHECK :

    CREATE TABLE PROMO
    (
    PromoId INT NOT NULL
    , PromoNom VARCHAR(48) NOT NULL
    , PromoDebut DATE NOT NULL
    , PromoFin DATE NOT NULL
    , CONSTRAINT PROMO PRIMARY KEY (PromoId)
    , CONSTRAINTE check_dates CHECK PromoDebut < PromoFin )

    ) ;

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Bonjour jackherrer57,


    Citation Envoyé par jackherrer57
    je dirais une contrainte de vérification avec CHECK
    Bon réflexe. Avec les SGBD habituels, c’est ce qu’il faut faire. Mais, à ce jour, avec MySQL, il y a un comme un problème, car il est écrit :

    « The CHECK clause is parsed but ignored by all storage engines »

    Le filet est donc troué à cet endroit précis...

    => Deux petits triggers (un pour INSERT, l'autre pour UPDATE) ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  11. #11
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    bonjour fsmerel

    Citation Envoyé par fsmrel Voir le message
    Bonjour jackherrer57,

    => Deux petits triggers (un pour INSERT, l'autre pour UPDATE) ?
    là je ne vous suis pas.

    Et j'ai une autre question, si je puis abuser encore de votre temps :

    on m'ajoute un élément important, là je suis perdu :

    chaque promo est donc stocké et validé, on ne retouche plus.
    Par contre, à des fins prévisionnel ou de simulations, il faudrait pouvoir sélectionner n promo, pouvoir modifier certain champs mais ne pas les intégrer dans la base.

    Je me suis dit qu'il suffirait de dupliquer ces promo, de rajouter un attribut pour les distinguer des autres enregistrements.

    Mais cela va à l'encontre de ce que j'ai appris en BDD : on ne duplique pas de donnée dans une base ? est-ce une règle immuable, ou un tel cas peut faire exception? ou cela doit se faire d'une autre façon ?

  12. #12
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut On ne duplique pas, on spécialise...
    Bonjour jackherrer57,


    Citation Envoyé par jackherrer57
    là je ne vous suis pas.
    Puisque MySQL ne permet pas de garantir la contrainte PromoDebut < PromoFin au moyen de la clause CHECK (PromoDebut < PromoFin), soit on passe par des triggers, soit— comme dans du temps des SGBD de 2e génération — on contrôle applicativement.


    Il est évident qu’on va plutôt se rabattre sur des triggers, car on sait que le SGBD ne laissera jamais passer une violation de la contrainte.

    Pourquoi deux triggers ? Parce que contrairement à d’autres SGBD tels que SQL Server, MySQL ne permet pas de se contenter d’un seul trigger à la fois pour les inserts et les updates.

    Il faut donc deux triggers, un pour les inserts et un pour les updates, même si leur contenu est le même :

    
    CREATE TRIGGER PromoCoherenceDatesInsert BEFORE INSERT ON PROMO 
    FOR EACH ROW
        BEGIN
            IF new.PromoFin <= new.PromoDebut THEN
                SET @Erreur = CONCAT ('Promo d''identifiant  ''', new.PromoId, ''' : tentative d''insert avec date de fin ''', new.PromoFin, '''  <= date de début de promo ''', new.PromoDebut, '''.') ;
                SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
            END IF ;
        END 
    GO
    
    CREATE TRIGGER PromoCoherenceDatesUpdate BEFORE UPDATE ON PROMO 
    FOR EACH ROW
        BEGIN
            IF new.PromoFin <= new.PromoDebut THEN
                SET @Erreur = CONCAT ('Promo d''identifiant  ''', new.PromoId, ''' : tentative d''update avec date de fin ''', new.PromoFin, '''  <= date de début de promo ''', new.PromoDebut, '''.') ;
                SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
            END IF ;
        END 
    GO
    
    


    Citation Envoyé par jackherrer57
    chaque promo est donc stocké et validé, on ne retouche plus.
    Par contre, à des fins prévisionnel ou de simulations, il faudrait pouvoir sélectionner n promo, pouvoir modifier certain champs mais ne pas les intégrer dans la base.
    Je me suis dit qu'il suffirait de dupliquer ces promo, de rajouter un attribut pour les distinguer des autres enregistrements.
    Ce je comprends pour le moment : ajouter dans l’en-tête de l’entité-type PROMO un attribut pour un attribut pouvant faire l’objet d’une simulation. A mon sens, il est préférable d’externaliser cet attribut supplémentaire, le but étant de ne pas polluer la table PROMO avec des données de simulation.

    Techniquement, on peut passer par la spécialisation : si l’utilisateur a besoin de faire une simulation portant sur une période de promo, on définit un entité-type PROMO_SIMUL_PERIODE, sous-type de l’entité-type PROMO. Si l’utilisateur a besoin de faire une simulation impliquant l’attribut PromoTruc, on définit un entité-type PROMO_SIMUL_TRUC, sous-type elle aussi de l’entité-type PROMO. Même principe pour les autres attributs de PROMO pour lesquels l’utilisateur a besoin de faire une simulation.

    MCD






    MLD


    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  13. #13
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    créer une entité-type pour chaque attribut en gros?
    ce que j'ai omis c'est que la table promo contient environ 20 champs, peut etre meme plus.
    mais je pense que ca ne pose pas de probleme.

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par jackherrer57
    créer une entité-type pour chaque attribut en gros?
    Ce que j'ai omis c'est que la table promo contient environ 20 champs, peut-être même plus.
    Les attributs ne sont peut-être pas tous concernés ? Par exemple, je vois mal le nom de la promo faire l’objet d’une simulation. De toute façon, plutôt que de définir a priori un sous-type par attribut de la table PROMO, vous pouvez le faire au fur et à mesure des besoins de l’utilisateur.

    Par ailleurs, si l’utilisateur a besoin de simuler des données pour lesquelles il n’y a pas d’attribut dans la table PROMO, il pourra le faire. Exemple d’un hypothétique attribut PromoBidule :







    Citation Envoyé par jackherrer57
    Mais je pense que ca ne pose pas de problème.
    Moi non plus . J’ai modélisé des bases de données de l’ordre de 2000 tables, avec très grand soin certes, mais sans problèmes liés à cette volumétrie dans le contexte de la production.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  15. #15
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut
    bonjour fsmrel

    je vois.
    par contre si je veux faire une liaison 0,n entre promo et ses "enfants" promo_simu je devrais rajouter un champ d'index pour faire une clef primaire en couple avec l'id_promo sur chaque "enfant".

    merci pour la piste. Je pense que c'est ce qu'il y a de plus judicieux pour respecter les règles.

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    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 : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut Identification relative
    Bonjour jackherrer57,


    Citation Envoyé par jackherrer57
    si je veux faire une liaison 0,n entre promo et ses "enfants" je devrais rajouter une clef primaire sur chaque "enfant".
    Il est un fait que la spécialisation de l’entité-type PROMO fait que les cardinalités portées par l’associations entre PROMO, considérée comme surtype, et chaque sous-type PROMO_SIMUL_XXX, ne sont pas 0,N mais bien 0,1. Du fait du passage à 0,N, d’un point de vue sémantique, PROMO_SIMUL_XXX devient plutôt une propriété multivaluée de PROMO, c’est une entité-type faible (weak entity-type) qui ne vit que par sa « mère » : si une promo disparaît, ses « enfants » disparaissent de facto. Par analogie, PROMO_SIMUL_XXX est à PROMO ce que LIGNE_FACTURE (ligne de facture) est à FACTURE. Dans ces conditions, vous pouvez utiliser l’identification relative : L’attribut PromoId fait partie de l’identifiant de PROMO_SIMUL_XXX, mais accompagné d’un séquenceur « relatif », dont les valeurs repartent à 1 pour chaque simulation. Exemple avec PROMO_SIMUL_BIDULE :

    
    PromoId    PromoBiduleId    PromoBidule
    -------    -------------    -----------
          1                1    bidule 11
          1                2    bidule 12
          1                3    bidule 13
          1                4    bidule 14
    
          2                1    bidule 21
          2                2    bidule 22
          2                3    bidule 23
          2                4    bidule 24
    
    

    D’où le code SQL (notez le ON DELETE CASCADE présent dans la 2e instruction CREATE TABLE) :

    
    CREATE TABLE PROMO
    (
            PromoId                 INT              NOT NULL
          , PromoNom                VARCHAR(48)      NOT NULL
          , PromoDebut              DATE             NOT NULL  DEFAULT '2015-10-01'
          , PromoFin                DATE             NOT NULL  DEFAULT '2015-10-15' 
          , CONSTRAINT PROMO_PK PRIMARY KEY (PromoId)
    ) ;
    
    CREATE TABLE PROMO_SIMUL_BIDULE
    (
           PromoId                  INT              NOT NULL
         , PromoBiduleId            INT              NOT NULL
         , PromoBidule              VARCHAR(64)      NOT NULL
        , CONSTRAINT PROMO_SIMUL_BIDULE_PK PRIMARY KEY (PromoId, PromoBiduleId)
        , CONSTRAINT PROMO_SIMUL_BIDULE_PROMO_FK FOREIGN KEY (PromoId)
              REFERENCES PROMO (PromoId) ON DELETE CASCADE
    ) ;
    
    

    Même principe pour toutes les tables PROMO_SIMUL_XXX.

    En remontant au MLD :






    Puis au MCD :




    La mise entre parenthèses des cardinalités 1,1 est le moyen utilisé par PowerAMC pour symboliser l’identification relative.


    Accessoirement :

    Citation Envoyé par fsmrel
    « XT » symbolise le OU exclusif donc le partitionnement.
    Ce qui se traduit ainsi selon le formalisme cher à Pierre Dac in Essais, Maximes, Conférences :

    Citation Envoyé par Pierre Dac
    Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde.

    Sic locutus est Petrus.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  17. #17
    Membre à l'essai
    Inscrit en
    Décembre 2008
    Messages
    29
    Détails du profil
    Informations forums :
    Inscription : Décembre 2008
    Messages : 29
    Points : 19
    Points
    19
    Par défaut très belle citation !
    ..je la note. c'est tellement vrai


    Tres bien fsmrel, je peux mettre le sujet en "résolu"

    en vous remercient pour votre implication.

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

Discussions similaires

  1. [MySQL] Boutique et gestion des promotions
    Par okoweb dans le forum PHP & Base de données
    Réponses: 1
    Dernier message: 21/08/2010, 20h22
  2. [reseaux] Gestion des threads en perl
    Par totox17 dans le forum Programmation et administration système
    Réponses: 2
    Dernier message: 28/11/2002, 10h40
  3. Gestion des variables - mémoire ?
    Par RIVOLLET dans le forum Langage
    Réponses: 4
    Dernier message: 26/10/2002, 13h44
  4. Réponses: 4
    Dernier message: 04/07/2002, 13h31
  5. c: gestion des exceptions
    Par vince_lille dans le forum C
    Réponses: 7
    Dernier message: 05/06/2002, 15h11

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