Introduction
Ces instructions décrivent les méthodes permettant de mapper les classes
de conception persistantes dans le modèle
de conception en tables dans le modèle de
données.
Transformation d'éléments du modèle de conception en
éléments du modèle de données
Les classes persistantes du modèle de conception peuvent être transformées en tables dans le modèle de
conception. Le tableau ci-dessous présente un résumé du mappage entre des éléments du modèle de conception et des
éléments du modèle de données.
Elément du modèle de conception
|
Elément du modèle de données correspondant
|
Classe
|
Table
|
Attribut
|
Colonne
|
Association
|
Relation non identifiante
|
Classe d'association
|
Table d'intersection
|
Agrégation composite
|
Relation identifiante
|
Association à origines et destinations multiples
|
Table d'intersection
|
Multiplicité
|
Cardinalité
|
Association qualifiée
|
Table d'intersection
|
Généralisation (héritage)
|
Table séparée
|
Mappage des classes
persistantes en tables
Les classes persistantes du modèle de conception représentent les informations que le système doit stocker. D'un point
de vue conceptuel, ces classes peuvent ressembler à une conception relationnelle. Par exemple, les classes du modèle de
conception peuvent être représentées comme des entités dans le schéma relationnel. Cependant, lorsqu'un projet passe de
l'élaboration à la construction, les buts du modèle de conception et du modèle de données relationnelles divergent.
Cette divergence s'explique par le fait que le but du développement de base de données relationnelle est de normaliser
des données, tandis que celui du modèle de conception est d'encapsuler les comportements devenus trop complexes.
L'opposition entre ces deux perspectives - données et comportements -crée le besoin de mappage entre des éléments liés
appartenant aux deux modèles.
Dans une base de données relationnelle conforme à la troisième forme normale, chaque ligne des tables -chaque bloc de
données- est considérée comme un objet. La colonne d'une table équivaut à l'attribut persistant d'une classe. N'oubliez
pas qu'une classe persistante peut avoir des attributs non résidents. Le mappage entre les deux mondes est donc facile
lorsqu'il n'existe pas d'associations avec d'autres classes. Le type de données de l'attribut correspond à l'un des
types de données autorisés pour les colonnes.
Exemple
La classe Client suivante :
modélisée en système de gestion de base de données relationnelle (SGBDR) se traduirait par une table appelé Client
contenant les colonnes ID_Client, Nom et Adresse.
Un exemple de cette table pourrait être visualisé de la manière suivante :
Pour chaque attribut persistant, des questions doivent être posées afin d'obtenir des informations supplémentaires qui
seront utilisées pour modéliser de manière appropriée l'objet persistant d'un modèle de données relationnel. Par
exemple :
-
Cet attribut persistant peut-il servir de clé ou être une partie de la clé ? Exemple : "L'attribut X et l'attribut
Z sont les seuls à identifier l'objet". Dans la table Client, l'ID_Client est une clé primaire.
-
Quelles sont les valeurs minimales et maximales de l'attribut ?
-
Sera-t-il possible de faire des recherches en utilisant cet attribut comme une clé ? Il pourrait, par exemple,
faire partie du filtre d'une instruction SELECT comme "Il est habituel de rechercher les instances où Y > 1000."
-
L'attribut a-t-il une description comme "l'attribut X est le nombre de retransmissions pour 100 000 caractères
transmis" ?
-
L'attribut peut-il avoir des valeurs numériques et des conversions souhaitées entre des valeurs numériques
différentes ?
-
Qui peut mettre à jour l'attribut ? Exemple: "T peut être modifié uniquement par les personnes ayant les droits
d'accès nn."
-
Qui est autorisé à lire les attributs ? Exemples: "P peut être lu par les personnes ayant les droits d'accès yy et
zz" ou ""P est inclus dans les vues Vi et Vj."
-
Les informations concernant les volumes et les fréquences sont-elles suffisantes ? Exemples: "Il y a jusqu'à 50 000
occurrences de A" ou "En moyenne, 2000 A sont changés par jour."
-
L'attribut est-il unique ? Exemple: un numéro de permis de conduire est unique.
Les associations entre des objets persistants sont réalisées comme des clés externes aux objets associés. Une clé
externe est une colonne dans une table qui contient la valeur de la clé primaire de l'objet associé.
Exemple :
Partons du principe qu'il existe l'association suivante entre la Commande et le Client :
Lorsque cela est mappé en tables relationnelles, on obtient une table Commande et une table Client. La table Commande
contient des colonnes pour les attributs répertoriés ainsi qu'une colonne supplémentaire appelée ID_Client contenant
les références des clés externes de la clé primaire de la ligne associée dans la table Client. Pour une Commande
passée, la colonne ID-Client contient l'identifiant du client auquel la commande est associée. Les clés externes
permettent au SGBDR de regrouper les informations liées entre elles.
L'agrégation est aussi modélisée en utilisant des relations de clé externe.
Exemple :
Partons du principe qu'il existe l'association suivante entre la Commande et la Ligne article :
Lorsque cela est mappé en tables relationnelles, on obtient une table Commande et une table Ligne article. La table
Ligne article contient des colonnes pour les attributs répertoriés ainsi qu'une colonne supplémentaire appelée
ID_Commande contenant la référence des clés externes de la ligne associée dans la table Client. Pour une Ligne article
donnée, la colonne ID_Commande contient l'ID_Commande de la Commande à laquelle la ligne article est associées. Les
clés externes permettent au SGBDR d'optimiser les opérations de jointure.
Il faut aussi installer une contrainte de suppression en cascade ; elle fournit en effet une intégrité référentielle au
modèle de données. Une fois que cela est fait, à chaque fois qu'une Commande est effacée, toutes ses lignes articles
sont effacées aussi.
Le modèle de données relationnel standard ne prend pas en charge la modélisation d'héritage de façon directe. De
nombreuses stratégies peuvent être utilisées pour modéliser l'héritage. Elles peuvent être résumées de la manière
suivante :
-
Utilisez des tables séparées pour représenter des superclasses et des sous-classes. La table sous-classe doit
contenir une référence de clé externe à la table superclasse. Pour instancier un objet de sous-classe, les deux
classes doivent être jointes. Cette approche est simple d'un point de vue conceptuel et facilite les modifications
apportées au modèle, mais elle souvent réalisée de manière incomplète à cause d'une surcharge de travail.
-
Dupliquez tous les attributs et les associations hérités en tant que colonnes séparées dans la table sous-classe.
Cela équivaut à la dénormalisation dans le modèle de données relationnel standard.
Une technique standard dans la modélisation relationnelle est d'utiliser une entité d'intersection pour représenter les
associations de plusieurs à plusieurs. On peut utiliser la même approche ici : une table d'intersection est utilisée
pour représenter l'association.
Exemple :
Si des Fournisseurs peuvent fournir plusieurs Produits et un Produit être fourni par plusieurs Fournisseurs, la
solution est de créer une table Fournisseur/Produit. Cette table ne contient que les clés primaires des tables
Fournisseur et Produit et sert à relier les Fournisseurs à leurs produits. Le modèle d'objet n'a pas d'analogue pour
cette table ; elle est exclusivement utilisée pour représenter les associations dans le modèle de données relationnel.
Finalisation du modèle de données
Une fois que les classes de conception ont été transformées en tables et en relations convenables dans le modèle de
données, le modèle est détaillée afin de permettre l'implémentation de l'intégrité référentielle et d'optimiser l'accès
aux données à l'aide de vues et de procédures mémorisées. Pour plus d'informations, voir Instructions : modèle de données.
La plupart des outils de conception d'application prennent en charge la génération des scripts en langage de définition
de données des modèles de données et/ou la génération de la base de données du modèle de données. La
rétro-conception de la base de données doit être planifiée comme faisant partie du développement général de
l'application et des tâches d'intégration. La fréquence à laquelle il faut procéder à la rétro-conception de la
base de données du modèle de données dépend de la situation du projet. Pour les nouveaux projets de développement
d'application créant une nouvelle base de données, la première rétro-conception doit faire partie du travail
d'implémentation d'une version stable de l'architecture de l'application, et cela à la fin de la phase
d'élaboration. Dans les autres cas, la première rétro-conception peut être faite pendant les premières itérations
de la phase de construction.
Les types d'éléments de modèle pouvant être rétro-conceptualisés changent en fonction des outils de conception et du
SGBDR utilisés pour le projet. En général, les principaux éléments structurels du modèle de données, dont les
tables, les vues, les procédures mémorisées,les déclencheurs et les index font partie, peuvent être
rétro-conceptualisés dans la base de données.
|