Database Reference
In-Depth Information
Il est évident que toutes les associations n-aires alourdissent les clés des tables d'asso-
ciation. Chercher donc à réduire le nombre de colonnes est important et lorsque l'on ne
peut pas le faire, il devient souvent intéressant de créer artiiciellement une entité asso-
ciative (classe artiicielle en UML) ain d'alléger la clé primaire ce qui est grandement
bénéique pour les performances. Il faudra, dans ce cas, ajouter une contrainte d'uni-
cité pour l'ensemble des clés étrangères composant l'association. Cette technique rajoute
effectivement une colonne, mais allège bien des objets physiques sous-jacents à la table,
comme l'écriture de certaines requêtes. La plupart des outils de modélisation permettent
d'automatiser ce genre de transformation.
Traduire ou ne pas traduire ?
Du fait que toutes les relations ne doivent pas forcément être traduites en tables, certaines
classes ne doivent exister qu'au niveau conceptuel. Le procédé qui consiste à ne pas traduire
une relation en table relève davantage d'un point de vue opérationnel que d'un point de vue
conceptuel. En général, il s'opère au niveau physique, où, avant de créer les tables, on se rend
compte de l'inutilité de telle ou telle table et on les élimine du script.
L'exemple suivant illustre la transformation d'un modèle conceptuel qui comporte une classe
relativement abstraite puisqu'il s'agit d'une date. Le modèle logique fait apparaître une relation
qui résulte de la traduction de cette classe.
Figure 2-20 . Une relation à ne pas transformer
Dans la majorité des cas, il n'est pas utile de traduire cette relation en table. Elle est toutefois
indispensable au niveau conceptuel, car elle permet de faire migrer dans la table d'association
la colonne qui représente le jour de visite. Certains la traduiront pour disposer d'une table de
référence de dates, astuce qui permet de faciliter les requêtes interrogeant la base à propos de
dates où aucune visite n'a été réalisée.
 
Search WWH ::




Custom Search