Instructions: Rétro-conception des bases de données relationnelles
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.
Relations
Description principale

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 :

Classe Client

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 :

Diagramme affichant une partie de la table objet Nouveau client

Attributs persistants et clés

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.

Associations de mappage entre des objets persistants du modèle de données

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 :

Diagramme UML montrant l'association 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.

Mappage d'associations d'agrégation au modèle de données

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 :

Classes Commande et 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.

Modélisation des relations de généralisation dans le modèle de données

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.

Modélisation des associations de plusieurs à plusieurs dans le modèle de données

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.

Rétro-conception du 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.