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

Bonjour,

Citation:

---

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 ?

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

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}

Citation:

---

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 ?

Citation:

---

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 ?

Citation:

---

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 ?:roll:

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

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).

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