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 :

Validation modélisation SQL


Sujet :

Schéma

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 59
    Points : 19
    Points
    19
    Par défaut Validation modélisation SQL
    Bonjour à tous,

    Soit des entités simples "elements" (par exemple des articles).
    Lorsqu'on entre dans la base un "element" on souhaite le lier à d'autres "elements" de la même table, que l'on nommera "compléments".
    Ainsi, un élément est lié à un ou plusieurs compléments.

    Peut-on faire une table "complements" dont les deux champs seraient en fait composés de la PRIMARY KEY de "elements" ?

    Schéma simpliste de la chose :

    elements
    {
    id int auto-increment PRIMARY
    name varchar(50)
    }

    complements
    {
    id_element1 int FK
    id_element2 int FK
    }

    Merci par avance de vos avis et conseils à ce sujet

    Avairet

  2. #2
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    Bonjour,
    Peut-on faire une table "complements" dont les deux champs seraient en fait composés de la PRIMARY KEY de "elements" ?
    Oui bien sur.
    Un petit coup d'oeil dans la FAQ Merise devrait lever tes doutes.
    Comment exprimer une relation reflexive ?

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 59
    Points : 19
    Points
    19
    Par défaut
    Merci de ta confirmation ! Et pour le lien vers les bonnes sections de la FAQ.
    Car je n'avais pas le terme de "relation réflexive" en tête...

    Je fais ce genre de relations depuis longtemps, mais mon chef de projet m'a dit récemment que ce n'était pas correct "SQLellement parlant"... sans que je sache si c'était la réflexivité qui le gênait ou autre chose (genre FK ou PK).

    Une dernière validation, dans mon exemple pour la table "complements", est-ce judicieux, obligatoire ou superflu de créer une PRIMARY_KEY constituée de mes deux champs id_element1 et id_element2 ?

    Avairet

  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 777
    Points
    30 777
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par avairet
    Une dernière validation, dans mon exemple pour la table "complements", est-ce judicieux, obligatoire ou superflu de créer une PRIMARY_KEY constituée de mes deux champs id_element1 et id_element2 ?
    C’est obligatoire. Par construction, toute table doit avoir une clé, tout comme une entité doit avoir un identifiant (cf. la FAQ Merise mentionnée à juste titre par TheLeadingEdge). Dans le contexte SQL, appelons cela "clé primaire". Sans clé, Complements n’est pas une table, mais ce qu’on appelle un sac (bag). Un sac peut comporter des lignes en double, mais une table ne le peut pas et le rôle de la clé est de nous prémunir en ce sens. En effet, une table est un ensemble, que l’on manipule avec des opérateurs ensemblistes (Union, Projection, Produit, etc.) et le comportement de ces opérateurs devient incertain dès qu’il y a des doublons. En outre, apprendre une chose deux fois ne signifie pas que cette chose soit pour autant deux fois plus vraie...

    Quant aux colonnes composant la clé :

    Si pour un id_element1 on peut avoir plusieurs id_element2 et réciproquement (cas des nomenclatures), on est dans un scénario "plusieurs-à-plusieurs" (many-to-many) et l’on code :
    PRIMARY KEY {id_element1, id_element2}
    Si pour un id_element1 on a un seul id_element2 et plusieurs id_element1 pour un id_element2 (cas des hiérarchies), on code :
    PRIMARY KEY {id_element1}
    Si pour un id_element1 on a un seul id_element2 et réciproquement, on code :
    PRIMARY KEY {id_element1}
    UNIQUE {id_element2}
    (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
    Profil pro
    Inscrit en
    Février 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 59
    Points : 19
    Points
    19
    Par défaut
    Dans le contexte SQL, appelons cela "clé primaire". Sans clé, Complements n’est pas une table, mais ce qu’on appelle un sac (bag).
    Et donc on n'utilise jamais de sac (bag) dans les DB ? C'est vraiment interdit ?

    Simple hypothèse : si je mets un Index sur chaque colonne de "complements", voire un Index sur deux colonnes, mais pas de PRIMARY_KEY, suis-je toujours dans le cas d'un sac ?

    Par construction, toute table doit avoir une clé, tout comme une entité doit avoir un identifiant
    Si je te suis bien, ma table "complements" n'est pas une "entité", donc l'identifiant n'est pas obligatoire, mais la clé oui ?

    En outre, apprendre une chose deux fois ne signifie pas que cette chose soit pour autant deux fois plus vraie...
    Euh... là excuse moi, mais je ne comprends pas ?

    En tout cas, je te remercie infiniment pour la précision de ta réponse ! Et notamment pour la formulation qui me permet de choisir les colonnes composant ma clé primaire !

    Avairet

  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 777
    Points
    30 777
    Billets dans le blog
    16
    Par défaut Précision sur les BD d'aujourd'hui
    Citation Envoyé par avairet
    Et donc on n'utilise jamais de sac (bag) dans les DB ? C'est vraiment interdit ?
    SQL le permet, mais les résultats sont alors imprévisibles. Maintenant, si vous voulez jouer avec des bâtons de dynamite...

    Citation Envoyé par avairet
    Simple hypothèse : si je mets un Index sur chaque colonne de "complements", voire un Index sur deux colonnes, mais pas de PRIMARY_KEY, suis-je toujours dans le cas d'un sac ?
    Il y a encore 20 ans, les SGBD ne fournissaient pas la clause PRIMARY KEY : on utilisait alors des index de type UNIQUE comme palliatifs. Aujourd’hui, on utilise bien entendu la clause.

    Citation Envoyé par avairet
    Si je te suis bien, ma table "complements" n'est pas une "entité", donc l'identifiant n'est pas obligatoire, mais la clé oui ?
    Si au niveau MCD Merise, Complements est une association-type, par définition elle n’a pas d’identifiant propre, disons qu’elle hérite des identifiants des entités-types qu’elle met en relation. En conséquence, lors du processus de dérivation du MCD en MLD, cet héritage se traduit par une matérialisation de la clé primaire :

    PRIMARY KEY {id_element1, id_element2} si la relation est de type plusieurs-à-plusieurs,
    PRIMARY KEY {id_element1} si la relation est de type un-à-plusieurs, etc.

    Citation Envoyé par fsmrel
    En outre, apprendre une chose deux fois ne signifie pas que cette chose soit pour autant deux fois plus vraie...
    J’ai repris une blague de Ted Codd, père du Modèle Relationnel de Données (dont les Bases de données relationnelles d'aujourd'hui sont des réalisations partielles, plus ou moins fidèles), qui a dit exactement :
    "If something is true, saying it twice doesn’t make it more true."
    Autrement dit, si dans la table Complements, on a deux lignes ayant même valeur <elem1, elem2>, on dit en fait deux fois la même chose. On n’en apprendrait pas davantage s’il y avait un milliard de lignes ayant cette même valeur : une fois suffit donc, ni plusse, ni moinsse (no more no less).
    (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
    Profil pro
    Inscrit en
    Février 2008
    Messages
    59
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 59
    Points : 19
    Points
    19
    Par défaut
    Merci pour cette remarquable réponse qui m'en a appris plus sur les BD en quelques heures qu'en quelques années !

    Et vive Ted Codd... c'est pour moi aussi, un leitmotiv de ne pas me répéter inutilement !

    Peut-être à une prochaine fois pour d'autres éclaircissements.

    Avairet

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

Discussions similaires

  1. <check-valid-connection-sql>
    Par miss_poopoucy dans le forum Wildfly/JBoss
    Réponses: 2
    Dernier message: 18/10/2012, 19h19
  2. valider du sql pour mysql
    Par arm3366 dans le forum Requêtes
    Réponses: 5
    Dernier message: 09/01/2012, 16h41
  3. Réponses: 5
    Dernier message: 02/12/2010, 17h04
  4. [SQL-Server] Warning: mssql_query(): supplied argument is not a valid MS SQL-Link resource
    Par danny3107 dans le forum PHP & Base de données
    Réponses: 1
    Dernier message: 21/01/2010, 22h27
  5. Réponses: 4
    Dernier message: 25/12/2005, 19h46

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