Bonsoir Pierre,
Envoyé par
Pierre
Mais pourquoi? QUARTIER, {CommuneId, Quartierid}
C’est la conséquence de l’identification relative. La clé de la table QUARTIER n’est pas le singleton {Quartierid} (cas de l’identification absolue), mais la paire {CommuneId, Quartierid} (cas de l’identification relative) : pour chaque commune, la numérotation de l’attribut Quartierid commence à 1 :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| Table QUARTIER
CommuneId Quartierid
--------- ----------
1 1
1 2
1 3
2 1
2 2
2 3
n 1
n 2
n 3 |
Ted Codd, père du modèle relationnel de données procède de la même façon, voyez son article fondateur de 1970, A Relational Model of Data for Large Shared Data Banks, à la page 381, les figures (3a) et (3b), clés primaires en italiques. En adaptant son exemple aux communes et quartiers, on part de la variable relationnelle COMMUNE non normalisée (au sens de Codd, donc) :
COMMUNE {CommuneId, CommuneNom, QUARTIER {QuartierId, QuartierNom}}
Après normalisation, on a décomposé COMMUNE en COMMUNE et QUARTIER :
COMMUNE {CommuneId, CommuneNom}
QUARTIER {CommuneId, QuartierId, QuartierNom}
Voici ce qu’il écrit à ce propos :
“Normalization proceeds as follows. Starting with the relation at the top of the tree, take its primary key and expand each of the immediately subordinate relations by inserting this primary key domain or domain combination. The primary key of each expanded relation consists of the primary key before expansion augmented by the primary key copied down from the parent relation. Now, strike out from the parent relation all nonsimple domains, remove the top node of the tree, and repeat the same sequence of operations on each remaining subtree.”
Je traduis (en adaptant au besoin les termes utilisés en 1970) :
« La normalisation fonctionne ainsi. En commençant avec la variable relationnelle (relation) au sommet de l’arbre, en prendre la clé primaire et étendre chacune des variables relationnelles qui lui sont directement rattachées en y insérant cette clé primaire (singleton ou multi-attributs). La clé primaire de chaque variable étendue est composée de la clé primaire avant extension, augmentée de la clé primaire recopiée de la variable parente. Ceci fait, virer de la variable parente les attributs qui n’ont plus rien à y faire, virer le nœud au sommet et répéter la séquence des opérations pour chaque sous-arbre restant. »
Envoyé par
Pierre
Pourquoi devoir absolument intégrer la référence de la commune?
Ça n’est évidemment pas un absolu, mais la sémantique marche bien en général avec la performance, la consommation des ressources et tout ce genre de choses du niveau physique.
Par exemple, si on n’utilise pas l’identification relative, la table QUARTIER devra être non seulement dotée d’un index pour la clé primaire {QuartierId}, mais aussi d’un autre index pour la clé étrangère {CommuneId}, sinon bonjour les performances de la jointure des tables COMMUNE et QUARTIER. Si on utilise l’identification relative, un seul index suffit (et n’oubliez pas que le coût des mises à jour d’une table croît singulièrement avec le nombre d’index accrochés à cette table).
Si on n’utilise pas l’identification relative, pour retrouver le nom des communes concernées par le projet Rantanplan, la requête est la suivante (voyez aussi le 4e exemple ici) :
1 2 3 4 5
| SELECT DISTINCT CommuneNom, '' AS '<= Projets - communes'
FROM PROJET AS x JOIN PROJET_QUARTIER AS y ON x.ProjetId = y.ProjetId
JOIN QUARTIER AS z ON y.QuartierId = z.QuartierId
JOIN COMMUNE AS t ON z.CommuneId = t.CommuneId
WHERE ProjetNom = 'Rantanplan' ; |
Alors qu’on diminue le nombre de jointures avec l’identification relative :
1 2 3 4
| SELECT DISTINCT CommuneNom, '' AS '<= Projets - communes'
FROM PROJET AS x JOIN PROJET_QUARTIER AS y ON x.ProjetId = y.ProjetId
JOIN COMMUNE AS z ON y.CommuneId = z.CommuneId
WHERE ProjetNom = 'Rantanplan' ; |
Mais surtout, au-delà de la consommation des ressources, les rafales d’entrées/sorties sur disque sont dans ce 2e cas incomparablement plus performantes (effet cluster que l’on sait maîtriser, contrairement avec l’autre solution).
Etc.
Partager