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 :

relations N1 majoritaires : votre avis ? [MCD]


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut relations N1 majoritaires : votre avis ?
    bonjour,
    je travaille actuellement sur la conception d'une application qui doit permettre d'évaluer les compétences de collaborateurs d'un service de supervision informatique : j'ai utilisé Analyse SI pour la modélisation et j'arrive au résultat suivant pour le MCD :

    débutant en modélisation, ma question est : est-ce normal d'avoir autant de relations 1N ? (et en boucle qui plus est) j'imaginais plutôt ma BDD avec 3 tables :
    1 table Collab
    1 table Clients
    1 table Compétences
    et je me retrouve avec 10 tables selon AnalyseSI (toutes les relations ayant été tranformées en table)
    Merci d'avance pour votre avis !

  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 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour ptitdev,


    Les cardinalités 1,N peuvent être à l’occasion transformées en 0,N car par exemple, tel client utilise tel outil qu’aucun collaborateur ne maîtrise. De même, une majorité de collaborateurs peuvent maîtriser tel outil qu’aucun client n’utilise (dommage !) :
    [CLIENT]----1,N----(Posséder)----0,N----[OUTIL]----0,N----(Maîtriser)----1,N----[COLLABORATEUR]
    De même, si certains collaborateurs ne sont pas tous opérationnels, la cardinalité minimale 1 peut être remplacée par 0 sur la patte connectant COLLABORATEUR et Maîtriser.

    Selon votre MCD, des collaborateurs pourraient travailler pour tel client sans maîtriser aucun des outils dont se sert ce client. Est-ce possible ?

    Visuellement vous avez un cycle, mais en réalité celui-ci n’existe pas (on pourra creuser ce point).

    Les associations sont transformées en tables parce que les listes de valeurs sont interdites dans le contexte relationnel.

    Par exemple : Outils du client Tartempion {Analyse SI, PowerAMC, SQL Server, ...} ça ne passe pas, il faut utiliser des paires de valeurs :

    <Tartempion, Analyse SI>
    <Tartempion, PowerAMC>
    <Tartempion, SQL Server>
    (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 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour fsmrel,merci pour t'être penché sur le problème et désolé pour ma réponse un peu tardive,

    tel client utilise tel outil qu’aucun collaborateur ne maîtrise
    en théorie c'est possible mais dans ce cas ces outils n'ont rien à faire dans la base de données, non ?(puisque le collaborateur ne sera évalué que sur des outils ou compétences qu’il utilise)
    Pour info, j’ai modifié le terme outil pour le remplacer par « domaine de compétences » , afin d’y inclure des compétences plus générales (Linux, Windows, réseau…), les compétences elle-même seront donc un « sous-domaine » du domaine de compétences
    De même, une majorité de collaborateurs peuvent maîtriser tel outil qu’aucun client n’utilise
    même remarque que ci-dessus, le but étant de sortir des stats sur les compétences d’un collab par rapport à tel ou tel client (en tout cas, c’est ce qui était demandé au moment de la création du MCD)
    Selon votre MCD, des collaborateurs pourraient travailler pour tel client sans maîtriser aucun des outils dont se sert ce client. Est-ce possible ?
    non, si tel collab travaille pour tel client, il doit avoir au moins une compétence concernant ce client (formation interne ou chez le client) : c’est d’ailleurs le sens de la cardinalité 1,N entre l’entité « collab » et la relation « detient », non ?

    Merci encore pour ta réponse ! bonne journée

  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 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir ptitdev,


    Citation Envoyé par ptitdev Voir le message
    en théorie c'est possible mais dans ce cas ces outils n'ont rien à faire dans la base de données, non ?(puisque le collaborateur ne sera évalué que sur des outils ou compétences qu’il utilise)
    Ces outils pourraient être là à titre préventif (actuellement personne ne s’en sert, mais ça pourrait bien se produire et alors il faudra réagir vite en production pour mettre à jour la table OUTIL). Autant une cardinalité 1,N est justifiée dans le cas par exemple de la relation entre une facture et ses lignes, autant la nécessité de cette cardinalité 1,N est moins évidente dans le cas des outils. Si vous tenez à la conserver, alors pour des raisons de cohérence entre le niveau conceptuel et le niveau opérationnel (disons SQL pour fixer les idées), si vous supprimez un collaborateur de la base de données et si du coup tel outil n’est plus utilisé, alors vous devrez le supprimer à son tour.


    Citation Envoyé par ptitdev Voir le message
    le but étant de sortir des stats sur les compétences d’un collab par rapport à tel ou tel client (en tout cas, c’est ce qui était demandé au moment de la création du MCD).
    Soit, mais cela suppose que les collaborateurs concernés représentent un sous-ensemble des collaborateurs de l’entreprise. Cela dit, les remarques précédentes valent ici.


    Citation Envoyé par ptitdev Voir le message
    non, si tel collab travaille pour tel client, il doit avoir au moins une compétence concernant ce client (formation interne ou chez le client) : c’est d’ailleurs le sens de la cardinalité 1,N entre l’entité « collab » et la relation « detient », non ?
    C’est un vœu pieux. La relation « Detient » dit seulement qu’un collaborateur détient au moins une compétence. Au niveau tabulaire, on peut très bien avoir ceci :
    COLLAB                               COMPETENCE                             CLIENT
    ID_collab    Nom_collab              Id_competence    Nom_competence        Id_client    Nom_client
    ---------    ---------               -------------    --------------        ---------    ----------
            1    Raoul                               1    Analyse SI                    1    Ets Naudin
            2    Paul                                2    PowerAMC                      2    Madame Mado
            3    Jean                                3    SQL Server                    
    
    DETIENT                              REQUISE_PAR                      TRAVAILLE_POUR
    ID_collab    Id_competence           Id_competence    Id_client       ID_collab    Id_client
    ---------    -------------           -------------    ---------       ---------    ---------
            1                2                       1            1               1            1
            2                2                       1            2               2            1
            2                3                                                    3            2 
            3                1  

    Les établissement Naudin utilisent Analyse SI.
    Raoul et Paul travaillent pour les établissements Naudin.
    Ni Raoul ni Paul ne connaissent Analyse SI.

    Moralité : modifier la modélisation ou ajouter les contraintes qui vont bien au niveau opérationnel.
    (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 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour fsmrel,

    D'après ce que tu exposes dans ton message précédent, je retiens qu'il faut "élargir" sa vision du MCD en incluant des possibilités qui ne sont pas forcément d'actualité lors de sa création (sous peine de devoir modifier la structure de la BDD future en rajoutant des contraintes par ex.)
    Je modifie le MCD et le met en ligne dés que je peux
    ceci dit, j'ai encore du mal à "visualiser" l'utilité de certaines tables (détient, requis_par, travaille_pour) sur le plan fonctionnel...est ce que trois tables (client, collab et competences comme je le disais au début) , avec les clés étrangères qui vont bien, ne permettraient pas d'arriver à un résultat équivalent ?

    Merci encore à toi,

  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 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir ptitdev,


    C’est le MCD qui a pour objet de représenter graphiquement le besoin fonctionnel. Le MLD permet de traduire le MCD sous forme de tables, en tenant compte de la règle fondamentale suivante, voulue en 1970 par Ted Codd, inventeur du Modèle Relationnel de Données :
    Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du type applicable, et rien d’autre.
    Si l’on n’a que les 3 tables CLIENT, COLLAB, COMPETENCE, leur représentation en extension pourrait ressembler à quelque chose comme ceci :

    Table COMPETENCE

    Id_competence    Nom_competence      
    -------------    --------------------
                1    Analyse SI
                2    PowerAMC
                3    SQL Server 
    Table CLIENT

    Id_client    Nom_client       Competences_Requises
    ---------    ------------     --------------------------
            1    Ets Naudin       1
            2    Madame Mado      1
            3    Tomate & Cie     1, 2, 3, 4
    Table COLLAB

    ID_collab    Nom_collab     Competences_Detenues    Clients    
    ---------    ----------     --------------------    --------------
            1    Raoul           2                        1
            2    Paul            2, 3, 7                  1, 3
            3    Jean            3, 1                     2, 3
    Examinons le contenu de la table CLIENT. L’attribut Competences_Requises est multivalué (d’où, en passant, l’utilisation du pluriel pour le nommer) : la règle fondamentale est violée. En outre, pour le client Tomate & Cie les collaborateurs devraient avoir les compétences 1, 2, 3, 4, or cette dernière n’existe pas, la table contient donc une erreur. Vous semblez penser qu’on s’en sortira « avec les clés étrangères qui vont bien », mais une valeur de clé étrangère doit avoir son homologue en tant que valeur de clé primaire (ou alternative) d’une table de la base de données : ces valeurs doivent être du même type, ce qui n’est pas le cas ici : l’attribut Competences_Requises est du type ARRAY (ou LIST ou apparenté), tandis que l’attribut Id_competence qui sert pour la clé primaire de la table COMPETENCE est du type INTEGER (ou équivalent) : comme dirait l’autre, y a du conflit de type dans cette affaire, ou comme disait Pascal (pas celui des Pensées, l’autre) : « M’sieur Fernand, vous la voyez, ce coup-là, l’embrouille ? »

    Bref, sauf à passer à un SGBD NF² (Non Première Forme Normale) du genre O², il faudra vous résoudre à normaliser la table CLIENT, c'est-à-dire faire comme dit Codd dans son article fondateur, rendre vertical ce qui est horizontal :

    Id_client    Nom_client       Competence_Requise
    ---------    ------------     ------------------
            1    Ets Naudin                        1
            2    Madame Mado                       1
            3    Tomate & Cie                      1
            3    Tomate & Cie                      2
            3    Tomate & Cie                      3
            3    Tomate & Cie                      4
    Cette fois-ci, vous pourrez établir une contrainte référentielle et faire interdire la présence de la ligne <3, Tomate & Cie, 4>. Néanmoins, la clé primaire n’est plus le singleton {Id_client} mais la paire {Id_client, Competence_Requise}, or il existe la dépendance fonctionnelle {Id_client} {Nom_client} faisant que la 2NF (deuxième forme normale) est violée, ce qui conduit à appliquer le théorème de Heath pour décomposer la table en deux tables ayant respectivement pour contenu :


    Id_client    Nom_client
    ---------    ------------ 
            1    Ets Naudin
            2    Madame Mado
            3    Tomate & Cie

    Id_client    Competence_Requise
    ---------    ------------------
            1                     1
            2                     1
            3                     1
            3                     2
            3                     3
            3                     4
    Curieusement, la structure de la 1re table ressemble comme deux gouttes d’eau à celle de la table CLIENT de mon message précédent et la structure de la 2e table ressemble étonnamment à celle de la table REQUISE_PAR : la boucle est bouclée...

    Il est bien difficile, sinon illusoire de se limiter à 3 tables...

    A titre d'exercice je vous laisse le soin de normaliser la table COLLAB.
    (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 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour fsmrel,

    Voici le MCD revu en tenant compte de tes remarques (en tout cas ce que j'en ai compris !)


    et le MLDR généré par analyseSI

    COLLAB (ID_collab, nom_collab, Date_controle, niveau_competence)
    CLIENT (ID_client, nom_client, #ID_perimetre)
    COMPETENCES (ID_competence, nom_competence)
    PERIMETRE (ID_perimetre, nom_perimetre)
    DOMAINE_COMP (ID_domaine, nom_domaine)
    travaille_pour (ID_collab, ID_client)
    detient (ID_collab, ID_competence)
    oeuvre_sur (ID_client, ID_domaine)
    requises_par (ID_client, ID_competence)
    fait_partie_de (ID_competence, ID_domaine)

    je vais donc tenter de construire la base de données à partir de ce MLDR, en renommant sans doute les tables du type "travaille_pour" d'une manière plus explicite...

    Merci en tout cas pour tes explications et ta patience

  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 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir ptitdev,


    Structurellement ça paraît bon, mais il manque toutefois des éléments capitaux comme les clés primaires et les clés étrangères. Merci de compléter, par exemple ainsi :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Travaille_Pour {ID_collab, ID_client}
        PRIMARY KEY {ID_collab, ID_client}
        FOREIGN KEY {ID_collab} REFERENCES COLLAB
        FOREIGN KEY {ID_client} REFERENCES CLIENT

    Travaille_Pour peut être renommé en COLLAB_CLIENT (ou CLIENT_COLLAB, au nom de la symétrie), ça ne mange pas de pain et on ne passe pas des heures à chercher un nom élégant, pertinent et tout ça. Le plus important est que la structure de la table soit la bonne et son contenu valide.

    Mêmes principes pour les autres tables.
    (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 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour Fsmrel,

    Effectivement, cette façon de renommer les tables me semble pratique, je vais donc les renommer ainsi
    Concernant les clés primaires et étrangères, je comptais bien les rajouter et je te remercie pour ton code : je modifie tout ça et fais un retour dès que possible

    Merci !

  10. #10
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour Fsmrel

    Voici le code utilisé pour la construction de la base, j'intègre des données dès aujourd'hui, à fin de tests... merci encore pour l'aide apportée

    CREATE TABLE IF NOT EXISTS `client` (
    `ID_client` int(11) NOT NULL AUTO_INCREMENT,
    `nom_client` varchar(80) DEFAULT NULL,
    `ID_perimetre` int(11) NOT NULL,
    PRIMARY KEY (`ID_client`),
    KEY `ID_perimetre` (`ID_perimetre`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
    --
    -- Structure de la table `client_competences`
    --

    CREATE TABLE IF NOT EXISTS `client_competences` (
    `ID_client` int(11) NOT NULL AUTO_INCREMENT,
    `ID_competence` int(11) NOT NULL,
    PRIMARY KEY (`ID_client`,`ID_competence`),
    KEY `ID_competence` (`ID_competence`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;


    -- Structure de la table `client_domaine_comp`
    --

    CREATE TABLE IF NOT EXISTS `client_domaine_comp` (
    `ID_client` int(11) NOT NULL AUTO_INCREMENT,
    `ID_domaine` int(11) NOT NULL,
    PRIMARY KEY (`ID_client`,`ID_domaine`),
    KEY `ID_domaine` (`ID_domaine`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    -- Structure de la table `collab`
    --

    CREATE TABLE IF NOT EXISTS `collab` (
    `ID_collab` int(11) NOT NULL AUTO_INCREMENT,
    `nom_collab` varchar(80) DEFAULT NULL,
    `Date_controle` date DEFAULT NULL,
    `niveau_competence` int(11) DEFAULT NULL,
    PRIMARY KEY (`ID_collab`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    Structure de la table `collab_client`
    --

    CREATE TABLE IF NOT EXISTS `collab_client` (
    `ID_collab` int(11) NOT NULL AUTO_INCREMENT,
    `ID_client` int(11) NOT NULL,
    PRIMARY KEY (`ID_collab`,`ID_client`),
    KEY `ID_client` (`ID_client`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------

    -- Structure de la table `collab_competences`

    CREATE TABLE IF NOT EXISTS `collab_competences` (
    `ID_collab` int(11) NOT NULL AUTO_INCREMENT,
    `ID_competence` int(11) NOT NULL,
    PRIMARY KEY (`ID_collab`,`ID_competence`),
    KEY `ID_competence` (`ID_competence`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    -- Structure de la table `competences`
    --

    CREATE TABLE IF NOT EXISTS `competences` (
    `ID_competence` int(11) NOT NULL AUTO_INCREMENT,
    `nom_competence` varchar(120) DEFAULT NULL,
    PRIMARY KEY (`ID_competence`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    -- Structure de la table `competences_domaine_comp`
    --

    CREATE TABLE IF NOT EXISTS `competences_domaine_comp` (
    `ID_competence` int(11) NOT NULL AUTO_INCREMENT,
    `ID_domaine` int(11) NOT NULL,
    PRIMARY KEY (`ID_competence`,`ID_domaine`),
    KEY `ID_domaine` (`ID_domaine`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    -- Structure de la table `domaine_comp`
    --

    CREATE TABLE IF NOT EXISTS `domaine_comp` (
    `ID_domaine` int(11) NOT NULL AUTO_INCREMENT,
    `nom_domaine` varchar(90) DEFAULT NULL,
    PRIMARY KEY (`ID_domaine`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

    -- --------------------------------------------------------
    -- Structure de la table `perimetre`
    --

    CREATE TABLE IF NOT EXISTS `perimetre` (
    `ID_perimetre` int(11) NOT NULL AUTO_INCREMENT,
    `nom_perimetre` char(20) DEFAULT NULL,
    PRIMARY KEY (`ID_perimetre`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;



    -- Contraintes pour la table `client`
    --
    ALTER TABLE `client`
    ADD CONSTRAINT `client_ibfk_1` FOREIGN KEY (`ID_perimetre`) REFERENCES `perimetre` (`ID_perimetre`) ON DELETE CASCADE ON UPDATE CASCADE;

    -- Contraintes pour la table `client_competences`
    --
    ALTER TABLE `client_competences`
    ADD CONSTRAINT `client_competences_ibfk_1` FOREIGN KEY (`ID_client`) REFERENCES `client` (`ID_client`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `client_competences_ibfk_2` FOREIGN KEY (`ID_competence`) REFERENCES `competences` (`ID_competence`) ON DELETE CASCADE ON UPDATE CASCADE;

    -- Contraintes pour la table `client_domaine_comp`
    --
    ALTER TABLE `client_domaine_comp`
    ADD CONSTRAINT `client_domaine_comp_ibfk_1` FOREIGN KEY (`ID_client`) REFERENCES `client` (`ID_client`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `client_domaine_comp_ibfk_2` FOREIGN KEY (`ID_domaine`) REFERENCES `domaine_comp` (`ID_domaine`) ON DELETE CASCADE ON UPDATE CASCADE;

    -- Contraintes pour la table `collab_client`
    --
    ALTER TABLE `collab_client`
    ADD CONSTRAINT `collab_client_ibfk_1` FOREIGN KEY (`ID_client`) REFERENCES `client` (`ID_client`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `collab_client_ibfk_2` FOREIGN KEY (`ID_collab`) REFERENCES `collab` (`ID_collab`) ON DELETE CASCADE ON UPDATE CASCADE;

    -- Contraintes pour la table `collab_competences`
    --
    ALTER TABLE `collab_competences`
    ADD CONSTRAINT `collab_competences_ibfk_1` FOREIGN KEY (`ID_collab`) REFERENCES `collab` (`ID_collab`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `collab_competences_ibfk_2` FOREIGN KEY (`ID_competence`) REFERENCES `competences` (`ID_competence`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `collab_competences_ibfk_3` FOREIGN KEY (`ID_collab`) REFERENCES `collab` (`ID_collab`) ON DELETE CASCADE ON UPDATE CASCADE;

    -- Contraintes pour la table `competences_domaine_comp`
    --
    ALTER TABLE `competences_domaine_comp`
    ADD CONSTRAINT `competences_domaine_comp_ibfk_1` FOREIGN KEY (`ID_competence`) REFERENCES `competences` (`ID_competence`) ON DELETE CASCADE ON UPDATE CASCADE,
    ADD CONSTRAINT `competences_domaine_comp_ibfk_2` FOREIGN KEY (`ID_domaine`) REFERENCES `domaine_comp` (`ID_domaine`) ON DELETE CASCADE ON UPDATE CASCADE;

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


    Structurellement, ça a l’air correct. Quelques remarques toutefois concernant le métabolisme des données (clauses ON UPDATE et ON DELETE).


    ON UPDATE

    Ne pas utiliser CASCADE, car les clés primaires sont invariantes.


    ON DELETE

    A n’utiliser qu’à bon escient. Je fais donc quelques suggestions :

    Selon votre script, si l’on supprime un périmètre, les clients de ce périmètre acceptent d’être supprimés eux aussi à condition que les tables dépendant de la table CLIENT n’y voient pas d’inconvénient, ce qui est le cas (CASCADE à tous les étages) ; en conséquence, par réaction en chaîne (d’où le terme CASCADE) la suppression d’un périmètre se propage et entraîne la suppression des lignes correspondantes dans les tables client_competences, client_domaine_comp et collab_client.

    Or au niveau sémantique, CLIENT est un type d’entité forte et quand le périmètre auquel il fait référence veut disparaître, un client doit dire niet ! Il faut donc ne pas utiliser la clause ON DELETE CASCADE pour la contrainte client_ibfk_1.

    Par contre, quand on supprime nommément un client, il paraît logique que par cascade le ménage soit fait dans les tables client_competences, client_domaine_comp et collab_client : la clause ON DELETE CASCADE peut être conservée pour les contraintes client_competences_ibfk_1, client_domaine_comp_ibfk_1 et collab_client_ibfk_1.

    En revanche, si on souhaite supprimer un domaine de compétence (devenu par exemple obsolète), il ne faut pas l’accepter si ce domaine est utilisé pour un client, alors que si un collaborateur a la compétence, on peut rompre le lien entre domaine et collaborateur. En résumé, ne pas utiliser la clause ON DELETE CASCADE pour la contrainte client_domaine_comp_ibfk_2, mais la conserver pour la contrainte collab_competences_ibfk_2 : si un client n’utilise pas la compétence X mais que le collaborateur a cette compétence (devenue obsolète), il n’y a guère de raison d’interdire la suppression du lien domaine - collaborateur pour cette compétence.

    Concernant la suppression d’un collaborateur : il faut être prudent, la suppression du dernier collaborateur travaillant pour un client doit être étudiée du point de vue des conséquences. Je précise quand même que si aucun client n’utilise les compétences d’un collaborateur à supprimer, celui-ci disparaître par DELETE, que la clause soit ON DELETE CASCADE ou non.


    NULL

    Tant que faire se peut, éviter NULL ! (logique ternaire délicate à manipuler par les optimiseurs qui sont inhibés, opérateur JOIN pouvant engendrer des erreurs, etc.)


    Table collab_competences

    La contrainte collab_competences_ibfk_3 doit dégager car elle redonde avec la contrainte collab_competences_ibfk_1.
    (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.

  12. #12
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour Fsmrel, et désolé pour ma réponse tardive,

    J'ai appliqué tes consignes (suppression des Delete Cascade, du NULL par défaut dans les tables indiquées et suppression de la contrainte collab_competences_ibfk_3). Il me reste cependant une question, plutôt d'ordre pratique et fonctionnel : soit la table Client_competences ci-dessous



    Lors d'une mise à jour de la base pour rajouter par ex. une compétence, est-il normal de faire deux INSERT INTO, sur les tables "competences" et "client_competences" afin de mettre à jour celle-ci ?

    Merci de ta réponse !

  13. #13
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Ptitdev et Fsmrel,

    Je me permets de m'immiscer, Fsmrel...

    Citation Envoyé par Ptitdev
    Lors d'une mise à jour de la base pour rajouter par ex. une compétence, est-il normal de faire deux INSERT INTO, sur les tables "competences" et "client_competences" afin de mettre à jour celle-ci ?
    ==> oui, c'est normal.

    Sinon, comment le système pourrait-il deviner le nom de la compétence ?...
    D'autre part, 1 compétence peut appartenir à plusieurs clients : il faudrait que le système ne fasse l'INSERT que la première fois ?... difficile.

    Donc, il faut ajouter une compétence par son nom, ce qui lui attribuera un Id unique (auto-incrémenté) et, ensuite, propager l'Id de la compétence nouvellement créée sur les clients adéquats via client_competence.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  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 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir ptitdev,


    Je ne vois pas précisément quel est le problème.

    S’il s’agit seulement d’ajouter une compétence pour elle-même, indépendamment des compétences des clients, il y a mise à jour de la table COMPETENCE, mais la table CLIENT_COMPETENCE n’est pas concernée (ne serait-ce que du fait de la cardinalité 0,N portée par la patte connectant l’entité-type COMPETENCE à l’association-type REQUISE_PAR). Du point de vue SQL, il y a une seule instruction INSERT à exécuter, et elle porte sur la table COMPETENCE.

    S’il s’agit de brancher un (ou plusieurs) client(s) sur une compétence déjà présente dans la table COMPETENCE, seule la table CLIENT_COMPETENCE fait l'objet d'un INSERT.

    S’il s’agit d’ajouter une compétence, pour un (ou plusieurs) client(s) et qu’elle n’est pas déjà présente dans la table COMPETENCE, une 1re instruction INSERT porte sur la table COMPETENCE et un 2e INSERT porte sur la table CLIENT_COMPETENCE.

    Si ma réponse vous laisse sur votre faim, il faudrait que vous reformuliez votre question de façon plus précise.

    Bon courage
    (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
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    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 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par Richard_35 Voir le message
    Je me permets de m'immiscer
    Attendons la réponse de ptidev.
    (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.

  16. #16
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Bonjour et merci Fsmrel et Richard_35,

    Ce que je voulais exprimer, c'est qu'il me paraissait pas très aisé de manipuler des IDs au lieu des noms de compétences et clients; je m'explique :
    par ex: Je souhaite rajouter la compétence "maîtrise de l'ordonnanceur" associée aux clients ClientTest1 et ClientTest2
    1. Je mets à jour la table compétences et je récupère l'ID
    2. je consulte la table Clients pour connaître les IDs associés aux clients
      concernés
    3. je renseigne la table client_competences avec les IDs récupérés



    et tout ça via l'interface PHPmyadmin qui facilite déjà les choses...

    J'ai bien conscience cependant que la vision relationnelle dans son ensemble (et vous l'expliquez très bien d'ailleurs) permet de comprendre comment le SGBDR gére ces mises à jour. Mais n'ayant jamais pratiqué, je me demandais s'il existait une solution plus "rapide" permettant d'éviter le point 2 : la consultation de la table Clients

    Merci à vous pour vos explications oh combien utiles !

  17. #17
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    Juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Ptitdev,

    Citation Envoyé par Ptitdev
    et tout ça via l'interface PHPmyadmin qui facilite déjà les choses...
    ==> l'interface de gestion de la base de données est conçu pour administrer la BdD (création des tables, ajout de champs, visualisation rapide des enregistrements, etc...), et non pour remplacer l'applicatif en lui-même.

    Par exemple, c'est l'application qui présentera une liste déroulante des compétences (par nom) dans la fiche de saisie des clients. Lors du choix, c'est l'application qui stockera l'Id de la compétence, et non son nom.

    En résumé, la modélisation ne doit (surtout) pas s'adapter à l'outil de remplissage des données : c'est l'inverse, qui doit se produire.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  18. #18
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2012
    Messages : 16
    Points : 8
    Points
    8
    Par défaut
    Merci pour ta réponse Richard_35,

    Vu sous cet angle, c'est plus clair, effectivement (bien dissocier la partie application de la BDD), la prochaine étape est donc le codage de l'appli !
    Si un problème au niveau de la conception remontait par la suite, je referai un saut par ici ;-)

    Merci encore à vous deux pour l'aide apportée !

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

Discussions similaires

  1. votre avis sur cette relation
    Par sousou88 dans le forum ALM
    Réponses: 10
    Dernier message: 17/06/2010, 18h07
  2. Votre avis sur les relations entre les tables.
    Par me755 dans le forum Modélisation
    Réponses: 9
    Dernier message: 07/02/2010, 03h48
  3. Votre avis sur mes relations
    Par momo_gea dans le forum Modélisation
    Réponses: 21
    Dernier message: 29/05/2007, 09h36
  4. Donnez votre avis sur les articles de Developpez.com
    Par Geronimo dans le forum C++Builder
    Réponses: 13
    Dernier message: 14/01/2007, 23h00
  5. Qui se sert de Together ici ? votre avis ?
    Par Matthieu Brucher dans le forum Autres
    Réponses: 28
    Dernier message: 25/08/2006, 10h44

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