> Data > Trop, c’est combien ?

Trop, c’est combien ?

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Jeffrey Bane - Mis en ligne le 29/09/2004 - Publié en Octobre 2003

En conception de base de données, la bonne relation est primordiale

Si le rôle de l'administrateur et du développeur de bases de données modernes se limitait à  coder SQL et à  assurer de bonnes sauvegardes, nous dormirions tous probablement mieux et pourrions consacrer davantage de temps à  nos loisirs. Malheureusement, nous devons aussi avant tout mettre en oeuvre des bases de données efficaces...Cette tâche est l'une des plus délicates dans le monde des bases de données, car la conception et la mise en oeuvre d'une base de données est un exercice lourd de conséquences positives ou négatives.
Le temps et l'expérience aidant, on atteint une certaine aisance malgré l'ampleur de la tâche. Et vous atteignez un point dans votre courbe d'apprentissage de développement de base de données où vous maîtrisez bien l'application des relations many-to-many (M:N) (de plusieurs à  plusieurs) entre les tables. Parfois même, vous vous sentez tellement à  l'aise que vous avez tendance à  abuser de ces relations.
Si vous êtes un développeur de bases de données débutant, la relation M:N risque de vous intimider. Mais, après plusieurs utilisations, vous constaterez qu'elle est relativement simple à  identifier, concevoir et mettre en oeuvre. En général, parvenue à  ce point de maîtrise, la courbe d'apprentissage se heurte à  un mur. Très peu de développeurs et de concepteurs de bases de données se risquent au-delà  des relations « Big 3 » : one to one (1:1), one to many (1:M) et M:N, pour découvrir les autres types de relations pouvant exister dans un schéma relationnel. Peu de gens explorent, mais moins encore maîtrisent, des types de relations plus obscures du genre tertiaire ou nomenclature. Pourtant, ces relations ne sont que de simples extensions des trois types de relations avec lesquelles vous vous sentez à  l'aise. Par exemple, une relation nomenclature n'est rien d'autre qu'une entité qui a des relations M:N avec elle-même. Dans cette relation, une entité pièces est constituée d'autres pièces qui, à  leur tour, sont constituées de - vous l'aviez deviné - encore d'autres pièces. Mais, si l'on comprend les relations M:N, on est tout près de comprendre la relation nomenclature.
Ces types de relations moins usuelles ne doivent pas constituer un mystère dans vos schémas de bases de données. Pour démystifier ces relations, voyons la relation supertype- subtype sous-utilisée et souvent incorrectement mise en oeuvre. Elle est aussi connue sous le nom de relation superclass-subclass. Si vous avez déjà  pratiqué le développement orienté objet, vous connaissez cette relation, dans laquelle plusieurs entités partapartagent certains attributs, mais pas tous.
A noter que dans cet article, je couvre principalement la mise en oeuvre physique d'une relation supertype- subtype, en expliquant la logique de ce type de relation et en soulignant les gains de performances spectaculaires qu'elle permet. Pour une explication approfondie des relations supertype- subtype au niveau logique, voir l'article classique de Michel Poolet « Supertypes and Subtypes », mai 1999, sur www.itpro.fr.

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.

Téléchargez gratuitement cette ressource

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Ce livre blanc expose les problématiques auxquelles sont confrontés les DAF modernes et souligne les bénéfices de la facturation électronique pour la trésorerie. Il dévoile également le processus de déploiement de ce projet de transformation digitale que la réglementation rendra bientôt obligatoire.

Data - Par iTPro.fr - Publié le 24 juin 2010