Rubriques

Introduction Haut de la page

Ces recommandations décrivent des méthodes de mappage des classes de conception persistantes du modèle de conception dans des tableaux dans le modèle de données

Convertir les éléments de modèles de conception en éléments de modèles de données Haut de la page

Les classes persistantes du modèle de conception peuvent être transformées en tableaux dans le modèle de données.  Le tableau ci-dessous montre un résumé du mappage entre les éléments de modèle de conception et les éléments de modèle de données.

Elément de modèle de conception

Elément de modèle de données correspondant

Classe Tableau
Attribut Colonne

Association

Relation non-identificatoire

Classe d'association

Tableau d'intersection

Agrégation composite

Identifier la relation

Association à origine et à destination multiples

Tableau d'intersection

Multiplicité

Cardinalité

Association conditionnelle

Tableau d'intersection

Généralisation (Héritage) Tableau séparé

Mapper les classes persistantes aux tableauxHaut de la page

Les classes persistantes du modèle de conception représentent l'information que le système doit stocker. Conceptuellement, ces classes peuvent être similaires à une conception relationnelle. (Par exemple, les classes du modèle de conception peuvent apparaître d'une certaine manière comme des entités dans le schéma relationnel.) Cependant, au fur et à mesure qu'un projet passe de l'élaboration à la construction, les objectifs du modèle de conception et du modèle relationnel divergent. Cette divergence vient du fait que l'objectif du développement d'une base de données relationnelle est de normaliser les données, alors que l'objectif du modèle de conception est d'encapsuler des comportements de plus en plus complexes. La divergence de ces deux points de vue - données et comportement - entraîne le besoin d'un mappage entre les éléments associés des deux modèles.

Dans une base de données relationnelle écrite en troisième forme normale, chaque ligne d'un tableau - chaque "uplet"- est considérée comme un objet. Une colonne d'un tableau équivaut à un attribut persistant d'une classe. (Souvenez-vous qu'une classe persistante peut avoir des attributs transitoires.) Ainsi, dans le cas simple dans lequel il n'y a pas d'associations à d'autres classes, le mappage entre les deux mondes est simple. 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

après modélisation dans le système de gestion de base de données relationnelle, est traduit dans un tableau appelé Client, avec des colonnes code client, nom et adresse.

Une instance de ce tableau peut être visualisée en tant que :

Diagramme montrant une partie du tableau objet nouveau client

Attributs persistants et clés Haut de la page

Pour chaque attribut persistant, des questions doivent être posées pour obtenir des informations supplémentaires qui seront utilisées pour modéliser de façon appropriée l'objet persistant dans un modèle de données relationnel. Par exemple :

  • Cet attribut persistant peut-il servir de clé ou d'une partie d'une clé ? Exemple : "L'attribut X, associé à l'attribut Z, identifie l'objet de façon unique." Dans le tableau client, le code client représente une clé primaire.
  • Quelles sont les valeurs minimales et maximales de l'attribut ?
  • Sera-t-il possible d'effectuer une recherche en utilisant cet attribut comme une clé ? Il peut par exemple faire partie d'un filtre dans une instruction de sélection comme "Il est courant de rechercher toutes les instances où Y > 1000."
  • L'attribut possède-t-il une description comme "l'attribut X est le nombre de retransmissions par 100 000 caractères transmis "?
  • L'attribut possède-t-il des valeurs numériques potentielles et des conversions souhaitées entre les différentes valeurs numériques ?
  • Qui est autorisé à mettre à jour l'attribut ? Exemple : "T peut être changé uniquement par les personnes de la classe d'autorité nn."
  • Qui est autorisé à lire l'attribut ? Exemple : "P peut être lu par les personnes de la classe d'autorité yy et zz" ou ""P est inclut dans les vues Vi et Vj."
  • Existe-il des informations appropriées sur les volumes et les fréquences ? Exemples : "Il y a jusqu'à 50 000 occurrences de A" ou "2000 A sont changés en moyenne tous les jours."
  • L'attribut est-il unique ? Exemple : Une seule personne peut avoir le même numéro de permis de conduire.

Mapper les associations entre les objets persistants au modèle de données Haut de la page

Les associations entre deux objets persistants sont réalisées comme des clés étrangères aux objets associés. Une clé étrangère est une colonne d'un tableau qui continent la valeur de clé primaire de l'objet associé.

Exemple :

Supposez 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é dans des tableaux relationnels, le résultat est un tableau commande et un tableau client. Le tableau commande possède des colonnes pour les attributs listés, ainsi qu'une colonne supplémentaire appelée code client et contenant des références de clé étrangère à la clé primaire de la ligne associée du tableau client. Pour une commande donnée, la colonne code client contient l'identifiant du client auquel la commande est associée. Les clés étrangères permettent au système de gestion de base de données relationnelle de relier ensemble les informations associées.

Mapper les associations d'agrégation au modèle de données Haut de la page

L'agrégation est également modelée en utilisant des relations de clé étrangère.

Exemple :

Supposez qu'il existe l'association suivante entre la commande et la ligne article :

Classes commande et ligne article

Lorsque cela est mappé dans des tableaux relationnels, le résultat est un tableau commande et un tableau ligne article. Le tableau ligne article possède des colonnes pour les attributs listés, ainsi qu'une colonne supplémentaire appelée code commande et contenant une référence de clé étrangère à la ligne associée du tableau commande. Pour une ligne article donnée, la colonne code commande contient le code commande de la commande à laquelle la ligne article des associée. Les clés étrangères permettent au système de gestion de base de données relationnelle d'optimiser les opérations liées.

De plus, il est important d'implémenter une contrainte de suppression en cascade qui fournit une intégrité référentielle dans le modèle de données. Une fois que cette tâche est effectuée, à partir du moment où la commande est supprimée, toutes les lignes articles sont supprimées également.

Modéliser les relations de généralisation dans le modèle de données Haut de la page

Le modèle de données relationnel standard ne prend pas en charge l'héritage de modélisation de façon directe . Un certain nombre de stratégies peut être utilisé pour modéliser l'héritage. Elles peuvent être résumées ainsi :

  • Utiliser des tableaux séparés pour représenter la superclasse et la sous-classe. Le tableau sous-classe doit comporter une référence de clé étrangère au tableau superclasse. Pour instancier un objet sous-classe, les deux tableaux doivent être liés l'un à l'autre. Cette approche est simple conceptuellement et facilite les changements au modèle, mais a des résultats souvent médiocres du fait du travail supplémentaire demandé.
  • Dupliquer tous les attributs et les associations héritées en tant que colonnes séparées dans le tableau sous-classe. Cette tâche est similaire à la dé-normalisation dans le modèle de données relationnel standard.

Modéliser les associations à origine et à destination multiples dans le modèle de données Haut de la page

Une technique standard de la modélisation relationnelle consiste à utiliser une entité d'intersection pour représenter les associations à origine et à destination multiples. La même approche peut être appliquée ici : un tableau d'intersection est utilisé pour représenter l'association.

Exemple :

Si les fournisseurs peuvent fournir de nombreux produits, et qu'un produit peut être fourni par de nombreux fournisseurs, la solution est de créer un tableau fournisseur/ produit. Ce tableau ne contiendra que les clés primaires des tableaux fournisseur et produit, et servira de lien entre les fournisseurs et leurs produits associés. Le modèle d'objet n'a pas d'analogue pour ce tableau ; il est utilisé uniquement pour représenter les associations dans le modèle de données relationnel.

Affiner le modèle de donnéesHaut de la page

Une fois que les classes de conception ont été transformées en tableaux et dans les relations appropriées dans le modèle de données, le modèle est affiné selon les besoins pour implémenter une intégrité référentielle et optimiser l'accès aux données par le biais de vues et de procédures stockées. Pour plus d'informations, voir Principes et conseils : Modèle de données.

Utiliser une rétro-conception du modèle de donnéesHaut de la page

La majorité des outils de conception d'application prennent en charge la génération de scripts de langage de définition de données (LDD) à partir de modèles de données et/ou la génération de la base de données à partir du modèle de données.  La rétro-conception de la base de données doit être prévue dans le cadre du développement de l'application et des activités d'intégration globales. La synchronisation et la fréquence de la rétro-conception de la base de données à partir du modèle de données dépend de la situation de projet spécifique. Pour les nouveaux projets de développement d'applications qui créent une nouvelle base de données, la rétro-conception initiale peut devoir être effectué dans le cadre du travail d'implémentation d'une version architecturale stable de l'application à la fin de la phase d'élaboration. Dans d'autres cas, la rétro-conception initiale peut être effectué dans les premières itérations de la phase de construction.  

Les types d'éléments de modèle du modèle de données pouvant subir une rétro-conception varient selon les outils de conception spécifiques et le système de gestion de base de données relationnelle utilisé sur le projet. En général, les éléments structurels majeurs du modèle de données, y compris les tableaux, les vues, les procédures stockées, les déclencheurs et les indexes peuvent subir une rétro-conception dans la base de données.




Ce contenu est développé ou partiellement développé par Applied Information Sciences.

RUP (Rational Unified Process)   2003.06.15