Trop, c’est combien ?

Les divers modes de transport constituent
un bon exemple de la relation supertype-
subtype. Les voitures, camions
et cyclomoteurs sont tous des
types de véhicules. Par conséquent, les
voitures, les camions et les cyclomoteurs
sont tous des subtypes du supertype
véhicule. Tous les types de véhicules
possèdent certains attributs
comme prix, couleur, poids, etc. En revanche,
d’autres attributs, comme la
longueur du plateau, ne s’appliquent
qu’aux camions. De même, la capacité
de remorquage ne concerne pas un
cyclomoteur mais est un attribut nécessaire
pour les voitures et les
camions. A l’aide de cet exemple, la figure 1 montre une mise en oeuvre
classique de la relation supertype-subtype.
Dans le schéma de la figure 1, j’ai
représenté le supertype et chaque subtype
comme une table séparée, résultant
en quatre tables base de données.
La table supertype contient toutes les
colonnes communes aux subtypes, et
chaque table subtype ne contient que
les colonnes spécifiques à  ce type de
véhicule. La colonne NumberOfDoors,
par exemple, n’existe que dans les
tables subtype Cars et Trucks, tandis
que la colonne Price, qui s’applique à 
tous les types de véhicules est dans la
table supertype Vehicles. Les tables
subtype partagent aussi une clé primaire
avec la table supertype. Par
exemple, dans la table Vehicles, si un
enregistrement avec une valeur de clé
primaire de 10 est un camion, l’enregistrement
associé dans la table Trucks
a aussi une valeur de clé primaire de
10. Bien que les relations entre une
table supertype et des tables subtype
ne soient pas toujours de 1:1 dans une
mise en oeuvre supertype-subtype,
dans cet exemple, chaque véhicule
sera toujours d’un type, créant trois relations
1:1.
A noter que la table supertype
Vehicles a une colonne nommée Type.
Cette colonne est un discriminateur de
subtype. Elle dispense d’effectuer une
vérification d’existence sur les tables
subtype afin d’extraire une information
détaillée. Si la colonne Type n’existait
pas, il faudrait consulter les trois
tables subtype pour trouver l’enregistrement
qui a la même clé primaire que
le supertype.
A première vue, on pourrait se demander:
pourquoi s’embarrasser d’un
tel design et pourquoi ne pas mettre
simplement tous les types de véhicules
dans une table ? La figure 2 montre une
variante, à  une table, de l’information
tirée du schéma de la figure 1. Bien que
l’on puisse économiser une jointure de
table en concevant ainsi la base de données,
cette table est peu efficace d’un
point de vue relationnel. Le champ NomberOfDoors n’a pas de sens pour
un cyclomoteur et si les acheteurs de
ce genre d’engin se soucient de la hauteur
du siège, ce détail est sans intérêt
pour une voiture. Je n’ai jamais vu un
cyclomoteur avec un plateau de camion.
En conséquence, on introduit
beaucoup de nulls dans la table.
Imaginons une relation supertype-subtype
qui a 30, 40 ou même 100 subtypes
contenant 1 000 attributs non en
commun. L’inefficacité du stockage et
des coupures de pages provoquées par
une table avec un millier de colonnes
pourrait facilement éliminer l’avantage
d’économiser une jointure de table,
particulièrement si les attributs non en
commun utilisent de longs champs de
caractère. Bien que je vous encourage
à  envisager toutes les possibilités de
mise en oeuvre, nous nous contenterons
dans cet exemple du schéma à 
quatre tables.