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

Merise Discussion :

Abus d'identification relative?


Sujet :

Merise

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut Abus d'identification relative?
    Bonjour,
    Actuellement sur un projet d'application de gestion commerciale multi-entreprise je suis en phase de modélisation des données et je suis amené à me poser une question suite à la lecture et analyse de la discussion suivante : http://www.developpez.net/forums/d90...e-facturation/

    L'identification relative permettant de s'assurer de la continuité des différentes entités entre elles :
    Pour éviter de tricoter les lignes d’une commande d’un client donné avec celles d’un autre client, vous pouvez identifier les lignes relativement au client (et tant qu’à faire utiliser l’héritage pour définir une ligne comme la généralisation des 3 types de lignes).
    N'y aurait-il pas de limites à l'utilisation de ce type d'identification? Par exemple dans le cadre de mon projet l'entité entreprise vient se rajouter amenant l'identification d'un contrat (suivant chaque type : devis,proposition ou facture) relativement à l'agrégat d'un client affilié à une de ces dernières avec de plus l'identification des lignes constituant chacun de ces types de contrats relativement à ce même agrégat et de ce fait, je me suis rendu compte des multiples utilisations de ce type d'identification afin d'assurer que chaque entreprise possède bien ces clients,ces contrats ... sans que ceux d'une autre entreprise viennent s'y mêler.

    Merci d'avance pour toutes réponses où début de piste

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


    Citation Envoyé par JBdev Voir le message
    l'entité entreprise vient se rajouter amenant l'identification d'un contrat (suivant chaque type : devis, proposition ou facture) relativement à l'agrégat d'un client affilié à une de ces dernières avec de plus l'identification des lignes constituant chacun de ces types de contrats relativement à ce même agrégat.
    Qu’entendez-vous par agrégat ? Par ailleurs, votre phrase est difficile à décrypter...

    Merci de fournir votre MCD et votre MLD.

    En tout cas, si vous avez relevé dans ce forum (ou dans le forum Schéma) quelques exemples où l’identification relative est inutile, abusive, ne vous privez pas de les exposer, on les étudiera de près, pour confirmer ou infirmer...
    (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
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Bonjour fsmrel,

    Tout d'abord merci pour les nombreux posts très complets et instructifs que vous pouvez laisser au fil des topics, ils sont une source de d'informations conséquentes.

    si vous avez relevé dans ce forum (ou dans le forum Schéma) quelques exemples où l’identification relative est inutile, abusive
    Bien au contraire, le topic que je citais dans mon premier message m'a servi d'appui pour affiner (je l'espère^^) ce concept d'identification relative .

    Tout ceci dit revenons à nos moutons, en effet ma phrase sans exemple où approfondissements est d'un flou artistique quasi-total je vous l'accorde bien volontiers...

    La situation que je souhaitais illustrer est la suivante (désolé, je n'ai que Windesign sous la main :/),ce n'est pas la totalité de mon mcd juste la partie à présomption de défauts ^^

    Contexte :
    - Chaque entreprise affilie un nombre n de client, chaque client est propre à l'entreprise ( agrégat selon Windesign sur le MCD ci-dessous )
    - A ces clients affiliés, les entreprises émettent des propositions de travaux,
    - Ces propositions de travaux comportent des lignes de type "proposition",
    - Le client affilié peut accepter la proposition (en totalité ou non), qui amènera à créer un devis avec les travaux retenus par le client (lignes type devis)
    - Les travaux du devis dont les produits (physiques et non les opérations de main d'œuvre),qui constituent les lignes, sont à commander amèneront à la création d'un bon de commande
    - Au premier réglèment du client, le devis amène à la création d'une facture composé des lignes qui ont constitué le devis dont elle est issue.

    Nom : mcdtest.PNG
Affichages : 1556
Taille : 25,7 Ko

    La future application qui m'a amené à mettre en place le mcd (base de données MySql,framework Symfony2) , devra gérer un certain nombre d'entreprises qui auront chacune leurs données exclusives pour leur gestion commerciale. Suivant le poste que je citais dans mon premier, l'identification relative permet de s'assurer qu'un contrat peut importe le type sera toujours relatif à un client,aux lignes qui la composent suivant son type.

    D'où ma première question , l'identification relative est-elle ici utilisée à bon escient pour l'intégrité des données, mais également dans le but de commencer à "cloisonner" les données par entreprises.

    De plus l'utilisation de ce type d'identification entraînant ( niveau du MLD ) la migration des composants de l'identifiant de l'entité forte vers celle de l'entité faible conduit ( niveau sql ) à ne pas pouvoir (dans le cadre de mysql en tout cas) mettre en auto-incrément la clé primaire de la table (MPD) (auparavant l'entité faible niveau MCD) dû à son caractère composite (transaction exclusive à mettre en place pour gérer cela).Exemple ici du MCD ci-dessus la table proposition aura (niveau MPD) comme clé primaire {IdProp,IdCli,IdEnt}, IdProp nécessiterait l'extra AUTO_INCREMENT mais Mysql le refuse du fait de sa participation dans la composition de la clé primaire de la table.

    M'amenant pour le coup à la question de mon topic l'identification relative apporte-elle autant que cela? Ou est ce que ce sont les SGBD qui ne sont pas à la hauteur de cette notion?

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


    Citation Envoyé par JBdev Voir le message
    la table proposition aura (niveau MPD) comme clé primaire {IdProp, IdCli,IdEnt}, IdProp nécessiterait l'extra AUTO_INCREMENT mais Mysql le refuse du fait de sa participation dans la composition de la clé primaire de la table.
    Les différents SGBD permettent l’utilisation d’un auto-incrément, mais on n’est pas obligé de s’en servir : il y a quand même d’autres façons de générer des valeurs uniques pour les clés. Quoi qu’il en soit, avant le milieu des années quatre-vingt-dix, chacun devait se débrouiller tout seul, comme un grand...

    Prenons l’exemple MySQL suivant, dans lequel il s’agit d’identifier les entreprises, tout en se passant de l’auto-incrémentation offerte par ce SGBD. Le principe est de dire que la nouvelle clé primaire {EntrepriseId} est incrémentée d’une unité par rapport à la dernière clé créée, ce qui passe par l’utilisation de la fonction d’agrégation MAX (où n représente le pas de l’incrément) :

    MAX(EntrepriseId) + n

    Quand il s’agit de créer la 1re clé, pour empêcher au bonhomme Null de se manifester, on utilise la fonction COALESCE (où m représente la valeur initiale de la clé :

    COALESCE(MAX(EntrepriseId) + n, m)

    Un script :

     
    CREATE TABLE ENTREPRISE 
    (
            EntrepriseId        INT                  NOT NULL
          , EntrepriseSiren     CHAR(9)              NOT NULL  
          , EntrepriseNom       VARCHAR(64)          NOT NULL
        , CONSTRAINT ENTREPRISE_PK PRIMARY KEY (EntrepriseId)
        , CONSTRAINT ENTREPRISE_AK UNIQUE (EntrepriseSiren)
    ) ;
    
    INSERT INTO ENTREPRISE (EntrepriseId, EntrepriseSiren, EntrepriseNom) 
        SELECT COALESCE(MAX(EntrepriseId) + 1, 1), '123456789', 'Dugoineau' 
        FROM   ENTREPRISE ;
    
    INSERT INTO ENTREPRISE (EntrepriseId, EntrepriseSiren, EntrepriseNom)  
        SELECT COALESCE(MAX(EntrepriseId) + 1, 1), '234567890', 'Naudin et Cie' 
        FROM   ENTREPRISE ;
        
    
    Au résultat :

     
    EntrepriseId    EntrepriseSiren    EntrepriseNom
               1    123456789          Dugoineau 
               2    234567890          Naudin et Cie
    
    
    Plutôt qu’alourdir les INSERT avec les fonctions MAX et COALESCE, on peut préférer mettre en œuvre un trigger interceptant les INSERT et chargé de l’incrémentation (pour varier les plaisirs, allons-y pour une incrémentation de 5 en 5, débutant à 100) :

     
    DELIMITER GO
    
    CREATE TRIGGER IncrementonsEntreprise BEFORE INSERT ON ENTREPRISE 
    FOR EACH ROW
        BEGIN 
            SET NEW.EntrepriseId = (SELECT COALESCE(MAX(EntrepriseId) + 5, 100)  
                                    FROM   ENTREPRISE) ;
        END 
    GO
    DELIMITER ;
    
    INSERT INTO ENTREPRISE (EntrepriseId, EntrepriseSiren, EntrepriseNom) 
        VALUES (0, '123456789', 'Dugoineau') ;
        
    INSERT INTO ENTREPRISE (EntrepriseId, EntrepriseSiren, EntrepriseNom)  
        VALUES (0, '234567890', 'Naudin et Cie') ;
    
    
    Au résultat :

     
    EntrepriseId    EntrepriseSiren    EntrepriseNom
             100    123456789          Dugoineau 
             105    234567890          Naudin et Cie
    
    
    Variation sur le thème

    Supposons qu’aux entreprises sont accrochés des établissements et qu’on utilise l’identification relative :

    [ ENTREPRISE ]----1,N--------(Composer)--------1,1 (R)----[ ETABLISSEMENT ]

    Table des établissements :

    
    CREATE TABLE ETABLISSEMENT 
    (
            EntrepriseId        INT                  NOT NULL
          , EtablissementId     INT                  NOT NULL
          , EtablissementSiret  CHAR(14)             NOT NULL
          , EtablisssementNom   VARCHAR(64)          NOT NULL
        , CONSTRAINT ETABLISSEMENT_PK PRIMARY KEY (EntrepriseId, EtablissementId)
        , CONSTRAINT ETABLISSEMENT_AK UNIQUE (EtablissementSiret)
        , CONSTRAINT ETABLISSEMENT_ENTREPRISE_FK FOREIGN KEY (EntrepriseId) 
              REFERENCES ENTREPRISE  (EntrepriseId)
    ) ;
    
    
    Un trigger pour gérer l’« auto-incrémentation relative » (et pallier ainsi la carence du SGBD ^^) :

    
    CREATE TRIGGER IncrementonsEtablissement BEFORE INSERT ON ETABLISSEMENT 
    FOR EACH ROW
        BEGIN 
            SET NEW.EtablissementId = (SELECT COALESCE(MAX(EtablissementId) + 1, 1)  
                                       FROM ETABLISSEMENT 
                                       WHERE EntrepriseId = NEW.EntrepriseId) ;
        END
    GO
    
    
    Quelques insertions d'établissements :

    
    INSERT INTO ETABLISSEMENT (EntrepriseId, EtablissementId, EtablissementSiret, EtablisssementNom) 
        SELECT EntrepriseId
             , 0 
             , '12345678912345', 'Clinique Dugoineau'    
        FROM   ENTREPRISE
        WHERE  EntrepriseSiren = '123456789' ;
    
    INSERT INTO ETABLISSEMENT (EntrepriseId, EtablissementId, EtablissementSiret, EtablisssementNom) 
         SELECT EntrepriseId
              , 0 
              , '23456789012345', 'La péniche'    
         FROM   ENTREPRISE
         WHERE  EntrepriseSiren = '234567890' ;
    
    
    INSERT INTO ETABLISSEMENT (EntrepriseId, EtablissementId, EtablissementSiret, EtablisssementNom) 
         SELECT EntrepriseId
              , 0 
              , '23456789012346', 'Le clapier'    
         FROM   ENTREPRISE
         WHERE  EntrepriseSiren = '234567890' ;  
    
     INSERT INTO ETABLISSEMENT (EntrepriseId, EtablissementId, EtablissementSiret, EtablisssementNom) 
         SELECT EntrepriseId
              , 0 
              , '23456789012347', 'Chez Mme Mado'    
         FROM   ENTREPRISE
         WHERE  EntrepriseSiren = '234567890' ;  
    
    
    Au résultat :
     
    
    EntrepriseId    EtablissementId    EtablissementSiret    EtablisssementNom
             100                  1    12345678912345        Clinique Dugoineau 
             105                  1    23456789012345        La péniche 
             105                  2    23456789012346        Le clapier 
             105                  3    23456789012347        Chez Mme Mado
    
    


    Citation Envoyé par JBdev Voir le message
    M'amenant pour le coup à la question de mon topic l'identification relative apporte-elle autant que cela? Ou est ce que ce sont les SGBD qui ne sont pas à la hauteur de cette notion?
    L’identification relative sert notamment à résoudre de façon simple les contraintes de chemin, c'est-à-dire en évitant les triggers (fouillez dans les forums, j’en parle assez souvent). Dans la soute, la propagation de l’identifiant EntrepriseId chez les descendants des entreprises permet de faire de la « clusterisation » (veuillez me pardonner ce barbarisme, mais il est vraiment tentant...) et offre ainsi des possibilités de gains en performances fort intéressants.

    Peu importe que le SGBD ne soit pas à la hauteur, on vient de voir que ça n’est pas un problème.



    Citation Envoyé par JBdev Voir le message
    Chaque entreprise affilie un nombre n de client, chaque client est propre à l'entreprise ( agrégat selon WinDesign sur le MCD ci-dessous )
    D’accord, je vois ce que vous entendez par agrégat, ça correspond au concept proposé en 1977 par John et Diane Smith dans Database abstractions: Aggregation and Generalization. L’agrégation a été évoquée dans quelques discussions, par exemple ici.

    Votre modélisation de l’agrégation correspond à celle qui est proposée dans la FAQ Merise. Mais l’exemple proposé (en 2004) n’est pas fameux et je ne reconnais pas la patte de Dominique Nanci (élégance du style, pertinence en ont pris un coup), quelqu’un a dû passer derrière lui pour bricoler le MCD, injecter des contre-vérités (un agrégat n’est pas nécessairement vide). Je dis surtout que l’exemple n’est pas fameux (et devrait être remplacé !) parce que la cardinalité portée par la patte connectant l’entité-type Elève et l’association EstInscrit est 1,1 : en conséquence, l’entité-type Classe_Elève n’est qu’une restriction-projection de l’entité-type Elève, ce que l’on perçoit mieux en passant au stade logique :

     
    Classe {ClasseId, ClasseNom}
        PRIMARY KEY {ClasseId} ;
    
    Elève {EleveId, ClasseId, EleveNom, ElevePrenom}
        PRIMARY KEY {EleveId}
        FOREIGN KEY {ClasseId} REFERENCES Classe ;
    
    ClasseEleve {EleveId, ClasseId}
        PRIMARY KEY {EleveId}
        FOREIGN KEY {EleveId} REFERENCES Elève ;
        FOREIGN KEY {ClasseId} REFERENCES Classe ;
    
    
    Si l’on transpose cette représentation dans votre système, je ne saisis pas l’intérêt de ce pseudo agrégat : autant brancher sur CLIENT les associations qui le sont actuellement sur CLIENT_ENTREPRISE...

    Avez vous des règles de gestion des données non dites ici, justifiant un agrégat ? (Un vrai...)


    A suivre...
    (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
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Bonjour fsmrel,

    Tout d'abord merci de l'intérêt que vous pouvez porter à mon sujet.

    Concernant ,la première partie de votre réponse l'idée de mettre en place afin de gérer l'auto-incrémentation d'une partie de clé composite est effectivement la première solution qui m'est venue à l'esprit.Cependant, la mise en place d'un simple trigger afin d'assurer l'unicité de chaque tuple contenu dans la table ne risque-t-il pas de causer des soucis quand aux accès concurrents sur l'insertion dans la table ? Cas certes rare mais pas impossible ^^. C'est pour cela que je pensais plutôt me tourner vers des transactions exclusives pour gérer l'auto incrémentation.

    Pour le barbarisme "clusterisation" je ne peux bien entendu pas vous en vouloir, je l'ai pour ma part juste traduit dans mon précédent post ^^.Donc l'identification relative est bel et bien un outil dont je ne saurai me passer pour ce projet.Les données devant être traité par L'ORM doctrine au sein de symfony2 je souhaitais justement éviter de devoir mettre trop de triggers en place tout en profitant de cette effet de "clusterisation" ( voilà ça fait 1 partout ^^).

    Du côté de l'agrégat sous Windesign, cet exemple de l'élève inscrit dans une classe est en effet un exemple redondant que j'ai rencontré à plusieurs reprises que ce soit dans la FAQ merise sur ce site où même dans différents livres sur la modélisation.Dans mon système, je souhaitais faire apparaître le fait qu'un contrat peu importe son type (proposition,devis ou facture) ne peut être concerner q'un client qui est lié à une entreprise ce qui, comme vous le soulignez, peut-être fait avec une identification relative :

    [ENTREPRISE]---- 1,n ---- AFFILIER ---- (1,1) ---- [CLIENT] puis chaque type de contrat identifier relativement à ce dernier.

    Cette notion d'agrégat, me semble encore flou il va falloir que je continue de chercher afin d'analyser cette notion et toutes ces variations... Mais en effet, je n'ai pas de règle de gestion qui justifie impérativement, ici , son utilisation.Cela était plutôt dû à une mauvaise interprétation de ma part à propos de cette notion.

    Concernant mon mcd, je suppose (j'espère surtout^^) ne pas avoir choquer le DBA que vous êtes, je vais donc maintenant pouvoir me tourner vers Symfony2 et son ORM afin de gérer tout cela.

    Je vous remercie pour votre disposition, l'avis d'un professionnel est toujours rassurant et surtout instructif.

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


    Citation Envoyé par JBdev Voir le message
    la mise en place d'un simple trigger afin d'assurer l'unicité de chaque tuple contenu dans la table ne risque-t-il pas de causer des soucis quand aux accès concurrents sur l'insertion dans la table ?
    Qu’entendez-vous par « causer des soucis quant aux accès concurrents » ? Intégrité des données pouvant ne pas être respectée ? Verrouillages intempestifs, bloquant les accès aux données ? Autres problèmes ?



    Citation Envoyé par JBdev Voir le message
    Les données devant être traité par L'ORM doctrine au sein de symfony2 je souhaitais justement éviter de devoir mettre trop de triggers en place
    Je ne connais ni Doctrine ni Symphony2, mais en quoi sont-ils concernés ou affectés par des triggers qui sont « sous le capot » ?



    Citation Envoyé par JBdev Voir le message
    Du côté de l'agrégat sous WinDesign, cet exemple de l'élève inscrit dans une classe est en effet un exemple redondant que j'ai rencontré à plusieurs reprises que ce soit dans la FAQ merise sur ce site où même dans différents livres sur la modélisation.
    Je répète que la présence de la cardinalité 1,1 fait que le prétendu agrégat n’en est pas vraiment un. Je rappelle que le point de départ de l’agrégation est l’interdiction qui est faite en Merise (ou E/A) classique d’associer une entité-type ou une association à une association.

    Exemple. La connexion entre les associations A1 et A2 ci-dessous est interdite :

    
    [ E1 ]----0,N--------( A1 )--------0,N----[ E2 ]
                           |
                           |
                          0,N
                           |
                           |
                         ( A2 )
                           |
                           |
                          1,1
                           |
                           |
                         [ E3 ]
    
    
    Pour arriver à ses fins, il est naturel de déguiser A1 en entité-type, puis, si on se sent l’âme d’un théoricien, de théoriser sur le thème de l’agrégation.


    Mais revenons à votre cas, en partant de la FAQ Merise :

    La FAQ propose présente le diagramme suivant :




    Ce qui, transposé aux entreprises, donne par exemple :



    Disons que cette représentation est intéressante, car elle peut éclairer l’utilisateur, sans surcharger le MCD.

    Toutefois, la suggestion faite dans la FAQ obscurcit tout... :




    Et transposé dans votre MCD, ça devient dangereux :




    En effet, la dérivation en relationnel donne exactement ceci (aux noms des attributs près) :

     
    ENTREPRISE {EntrepriseId, EntrepriseNom}
        PRIMARY KEY {EntrepriseId} ;
    
    CLIENT {ClientId, EntrepriseId, ClientNom}
        PRIMARY KEY {ClientId}
        FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
    
    CLIENT_ENTREPRISE {ClientId, EntrepriseId}
        PRIMARY KEY {ClientId, EntrepriseId}
        FOREIGN KEY {ClientId} REFERENCES CLIENT 
        FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
    
    
    1ere anomalie

    Puisque la clé primaire de la table CLIENT_ENTREPRISE est la paire {ClientId, EntrepriseId}, alors un client peut sans problème être en relation avec plusieurs entreprises, avec propagation de cette clé non pertinente dans les tables FACTURE, DEVIS, etc. En l’absence d’une règle de gestion qui justifie cela, la clé primaire de la table CLIENT_ENTREPRISE doit donc être corrigée et réduite au singleton {ClientId} :

    
    CLIENT_ENTREPRISE {ClientId, EntrepriseId}
        PRIMARY KEY {ClientId}
        FOREIGN KEY {ClientId} REFERENCES CLIENT 
        FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
    
    
    2e anomalie

    Si la réduction de la clé primaire de la table CLIENT_ENTREPRISE au singleton {ClientId} est justifiée, cette table comporte néanmoins une référence à la table ENTREPRISE, et il est possible que pour un client on fasse référence à une entreprise qui n’est pas celle à laquelle ce client est affilié. En l’absence d’une règle de gestion qui justifie cela, cette référence doit disparaître :

    
    CLIENT_ENTREPRISE {ClientId}
        PRIMARY KEY {ClientId}
        FOREIGN KEY {ClientId} REFERENCES CLIENT ;
    
    
    Autrement dit, la table CLIENT_ENTREPRISE est absorbée par la table CLIENT et disparaît du MCD... :




    En complément : si vous avez des exemples, je veux bien expertiser les ouvrages qui traitent de l’agrégation



    Citation Envoyé par JBdev Voir le message
    Dans mon système, je souhaitais faire apparaître le fait qu'un contrat peu importe son type (proposition, devis ou facture) ne peut être concerner qu'un client qui est lié à une entreprise ce qui, comme vous le soulignez, peut-être fait avec une identification relative :

    [ENTREPRISE]---- 1,n ---- AFFILIER ---- (1,1) ---- [CLIENT]
    Comme je l’ai écrit la fois précédente, l’identification relative permet :

    Au niveau logique, de résoudre la très grande majorité des problèmes de contraintes de chemin, comme ici ;

    Au niveau physique de faciliter le travail de « clusterisation » à tous les étages, voir aussi ici.

    Identifier CLIENT relativement à ENTREPRISE peut être intéressant dans le cadre la clusterisation si un des besoins suivants se fait sentir :

    Isoler l’ensemble des données d’une entreprise par rapport aux données des autres entreprises.

    Réduire le nombre de tables (et/ou index) à parcourir pour récupérer des donnée « lointaines », comparez les requêtes du 4e exemple du paragraphe traitant de l’optimisation ici.



    Citation Envoyé par JBdev Voir le message
    Concernant mon mcd, je suppose (j'espère surtout^^) ne pas avoir choquer le DBA que vous êtes.
    Ne soyez pas inquiet, votre souci de bien modéliser et votre curiosité vous ont emmené du côté de l’agrégation (au sens merisien du terme, ne pas confondre avec l’agrégation au sens « uémélien »). Pas de chance, vous êtes tombé sur la FAQ Merise où le sujet n’est pas traité correctement.

    Et puis, c’est en forgeant qu’on devient forgeron, on a tous le droit à l’erreur, même les DBA ^^ se plantent un jour ou l’autre, et je n’échappe pas à la règle. Le tout est de ne pas persister dans les bêtises (errare humanum est, etc.)
    (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
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Bonsoir fsmrel,

    Tout d'abord désolé pour le temps de réponse, symfony2 et son orm doctrine ont de quoi sérieusement m'occuper.

    Concernant votre réponse, je vous remercie de tous les éclaircissements que vous avez pu m'apporter sur l'identification relative et l'agrégat ( que je manie avec précaution dorénavant.

    Doctrine ne gérant pas les clés primaires composites amenées à faire partie d'autres clés primaires, je crains que je ne puisse utiliser cette modélisation mais j'en sors fort de nouvelles connaissances.

    Encore merci pour votre intervention.
    Bonne continuation.

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


    Citation Envoyé par JBdev Voir le message
    Doctrine ne gérant pas les clés primaires composites
    Holà ! Est-ce à dire que c’est Doctrine qui produit les CREATE TABLE ? Et il ne connaît pas les bases du modèle relationnel ?
    (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
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Bonjour !

    Alors en résumant le résumé,c'est cela en utilisant l'aspect ORM Object Relational Mapping de Doctrine je créé des class.php avec des attributs ,ces objets sont par la suite, mis en relation les uns avec les autres par le biais d'annotations du type ManyToMany ,OneToOne, ManyToOne (gérer soit en unidirectionnel ou en bidirectionnel avec un concept de class propriétaire et inverse) simulant les relation merisiennes.

    Vous l'aurez compris ce sont ces objets avec leurs attributs et leurs mises en relation qui seront en fait les futures tables de la BDD qui vont amener aux instructions SQL de create table avec les contraintes de primary,foreign key.Donc les bases du modèle relationnel sont connu de doctrine mais dès qu'un concept fort du modèle relationnel comme celui de l'identification relative est implémenté Doctrine ne la gère que dans certain cas :
    -Il ne faut pas que la clé primaire composite d'une table soit amenée à faire partie d'une autre clé primaire d'une autre table,
    -Dans les cas de relation ManyToMany (doctrine ne créé pas d'objet concernant la table associative) les deux clé primaires composites des deux entités mise en relations pourront composées la clé primaire de cette table associative ..,n ---- ..,n.

    Cependant, afin de combler ce manque certains développeurs utilisent une alternative qui consiste à "rétrograder" la clé étrangère composite en unique afin qu'elle ne lève pas le conflit concernant sa participation à la composition de la clé primaire de la table dans laquelle elle est amenée à se propager.Ceci me conduit à vous demander de votre point de vue en tant que DBA que pensez vous de cette pratique certes allant sûrement à l'encontre de vos principes?

  10. #10
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : Mai 2013
    Messages : 7
    Points : 5
    Points
    5
    Par défaut
    Re, je viens compléter mon message car, comme souvent je n'ai pas illustrer mes propos rendant sûrement leurs interprétations moins simples.

    suivant mon mcd précédent, l'identification relative d'un client par rapport à une entreprise et d'un devis identifié relativement par ce même client me permettra d'obtenir les tables suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    CLIENT {ClientId, EntrepriseId, DateSaisie}
                         PRIMARY KEY {ClientId,EntrepriseId}
                         FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
    
    DEVIS   {DevisId,ClientId,EnterpriseId,DateDevis}
                       PRIMARY KEY {DevisId,ClientId,EntrepriseId}
                       FOREIGN KEY {ClientId,EnterpriseId} REFERENCES CLIENT;
    Cependant cette situation n'est pas utilisable par doctrine ORM la clé étrangère composite {ClientId,EntrepriseId} ne peut faire partie de la clé primaire composite de devis {DevisId,ClientId,EntrepriseId}.C'est pour cela que les développeurs auxquels je faisais allusion dans le post précédent "gèrent" ceci de la façon suivante:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    DEVIS   {DevisId,ClientId,EnterpriseId,DateDevis}
                       PRIMARY KEY {DevisId}
                       UNIQUE KEY  Client_entreprise {ClientId,EnterpriseId}
                       FOREIGN KEY {ClientId,EnterpriseId} REFERENCES CLIENT;
    Voilà le schéma auquel je suis confronté, l'utilisation du framework symfony2 m'a été imposé, de plus souffrant d'une contrainte de temps relativement courte (comme tout projet informatique ) l'utilisation de l'ORM, aussi frustrant que ça le soit,devrait être un atout.

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


    Revenons au cas général sain, hors du mariage de la carpe et du lapin (alias modélisation objet/relationnel (sic !))

    Quand vous utilisez l'identification relative, il est préférable que l'ordre des attributs dans les clés respecte la généalogie.

    Vous avez codé (Cas C1) :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    CLIENT {ClientId, EntrepriseId, DateSaisie}
                         PRIMARY KEY {ClientId, EntrepriseId}
                         FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
     
    DEVIS   {DevisId, ClientId, EntrepriseId, DateDevis}
                       PRIMARY KEY {DevisId, ClientId, EntrepriseId}
                       FOREIGN KEY {ClientId, EnterpriseId} REFERENCES CLIENT;

    Ainsi, faisons figurer dans cet ordre : l’aïeul (EntrepriseId), le parent (ClientId) l’enfant (DevisId), etc., autrement dit faisons jouer l’effet Dagobert et remettons à l’endroit ce qui est à l’envers, pour aboutir à ceci :


    Cas C2
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    CLIENT {ClientId, EntrepriseId, DateSaisie}
                         PRIMARY KEY {EntrepriseId, ClientId}
                         FOREIGN KEY {EntrepriseId} REFERENCES ENTREPRISE ;
     
    DEVIS   {DevisId, ClientId, EntrepriseId, DateDevis}
                       PRIMARY KEY {EntrepriseId, ClientId, DevisId,}
                       FOREIGN KEY{EntrepriseId, ClientId} REFERENCES CLIENT;

    A noter que l’ordre des attributs vaut non seulement pour les clés primaires, mais aussi, par voie de conséquence, pour les clés étrangères qui les référencent.

    Il est vrai que du strict point de vue relationnel, une clé étant un ensemble, l’ordre des attributs n’y joue aucun rôle, ça n’a aucune incidence sur la validité des résultats lors de la manipulation des relations (tables). Alors pourquoi est-on amené à se soucier de l’ordre ? C’est à cause de se qui se passe dans la soute, au niveau physique, sous le contrôle du SGBD (MySQL dans votre cas) : le temps nécessaire à la production des résultats dépend de cet ordre, et on n’a pas l’éternité devant soi pour y parvenir. En jeu : les index.

    Dans le cas C1, la table CLIENT sera à doter de deux index, le 1er (appelons-le X1) pour la clé primaire {ClientId, EntrepriseId}, le 2e (X2) pour la clé étrangère {EntrepriseId}, même principe pour la table DEVIS.

    Dans le cas C2, pour la table CLIENT un seul index suffira (X1 en l’occurrence). En effet, l’attribut EntrepriseId figurant systématiquement en tête de la liste des attributs de la clé de cet index, celui-ci convient pour la clé primaire et pour la clé étrangère. Même principe pour la table DEVIS.

    Ainsi, dans le cas C1 on consomme 4 index, au lieu de 2 dans le cas C2. Or, lors des opérations de mise à jour, c’est le branle-bas dans les index, c’est coûteux en temps (sans parler de l'espace), aussi faut-il viser à la parcimonie quand on en crée. Je vous renvoie à ce propos à l’exemple de la banque d'une ville méridionale où il fait bon vivre...


    D’autre part, dans le cas C2, le clustering peut jouer plein pot (en tout cas, avec mon SGBD, à savoir DB2 c’est une certitude), alors que dans le cas C1, c’est fichu, et c’est la performance des traitements par lots (Bill Batch) et des requêtes lourdes (Jane Query) qui peut devenir catastrophique (combien de fois ai-je eu à ce sujet à auditer des bases de données dans les grandes entreprises...), quand bien même les requêtes légères (Joe Transaction) ne sont pas particulièrement touchées (du moins en ce qui concerne la partie émergée de l’iceberg).



    Pour en venir à votre produit objet/relationnel, adieu la parcimonie quant aux index, donc prévoyez une dégradation des performances dans les opérations de mise à jour. Adieu le clustering synchrone entre les tables. Adieu la prise en compte des contraintes de chemin, qui devront être garanties par des triggers en pagaille. Maintenant, le DBA pourra peut-être mystifier Doctrine sous le capot, en remettant en œuvre l’identification relative à coups d’ALTER TABLE et de triggers (comme ici), avec propagation donc de la généalogie. Bien sûr, les INSERT seront à surveiller (à nouveau comme ici), car les attribut ancêtres devront être réinjectés dans l’en-tête des tables parties prenantes. A voir, car cela demande une certaine expérience et je ne voudrais pas vous emmener au bain...


    Indépendamment de tout ce qui précède, il y a quelque chose qui ne pas dans votre code ci-dessous : à votre avis combien peut-on avoir de devis au maximum pour un client ?

    Citation Envoyé par JBdev Voir le message
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    DEVIS   {DevisId, ClientId, EntrepriseId, DateDevis}
                       PRIMARY KEY {DevisId}
                       UNIQUE KEY  Client_entreprise {ClientId, EntrepriseId}
                       FOREIGN KEY {ClientId, EntrepriseId} REFERENCES CLIENT;

    Bon courage


    P.-S. N'oubliez pas de voter pour les messages qui ont pu vous être utiles...
    (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.

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

Discussions similaires

  1. [WD10] Analyse : identification relative
    Par Medivh dans le forum WinDev
    Réponses: 4
    Dernier message: 16/11/2012, 13h37
  2. [MCD] MCD avec identification relative
    Par AiDuK dans le forum Schéma
    Réponses: 12
    Dernier message: 20/02/2010, 19h35
  3. [MCD] identification relative et entité faible
    Par erox44 dans le forum Schéma
    Réponses: 5
    Dernier message: 07/03/2008, 09h21
  4. [MCD] représentation d'une identification relative
    Par ZDAZZ dans le forum Schéma
    Réponses: 2
    Dernier message: 05/04/2007, 13h49
  5. [conception] problème identification relative
    Par mel02 dans le forum Modélisation
    Réponses: 4
    Dernier message: 19/01/2006, 17h00

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