Principes et conseils :
|
Elément de modèle de données |
Elément correspondant de modèle de conception |
---|---|
Tableau | Classe |
Colonne | Attribut |
Relation non-identificatoire |
|
Tableau d'intersection |
Classe d'association Association à origine et à destination multiples Association conditionnelle |
Identifier la relation |
|
Cardinalité |
Multiplicité |
Vérifier la contrainte avec une clause d'énumération | <<Classe>>ENUM |
Schéma | Package |
Certains éléments de modèle du modèle de données n'ont pas de corrélation directe dans le modèle de conception. Ces éléments incluent les tablespaces et la base de données elle-même, qui modélisent les caractéristiques de stockage physique de la base de données et sont représentés en tant que composants. Un autre élément, les vues de base de données, sont des tableaux "virtuels" et n'ont pas de signification dans le modèle de conception. Pour finir, les index des clés primaires des tableaux et de la base de données déclenchent des fonctions qui sont utilisées pour optimiser le fonctionnement de la base de données ont seulement un sens dans le contexte de la base de données et du modèle de données.
Pour chaque tableau que vous souhaitez convertir, créez une classe pour représenter le tableau. Pour chaque colonne, créez un attribut sur la classe avec le type de données approprié. Essayez de faire correspondre le plus étroitement possible le type de données de l'attribut avec le type de données de la colonne associée.
Exemple
Examinez le tableau de base de données client, avec la structure suivante, montré dans la figure ci-dessous :
Nom de colonne | Type de données |
---|---|
Code client | Numéro |
Nom | Varchar |
Rue | Varchar |
Ville | Varchar |
Etat/ province | Char(2) |
Code postal | Varchar |
Pays | Varchar |
Définition de tableau pour le tableau client
A partir de là, nous créons une classe client, avec la structure montrée dans la figure suivante :
Classe client initiale
Dans cette classe client initiale, il y a un attribut pour chaque colonne du tableau client. Chaque attribut a une visibilité publique, dans la mesure où toutes les colonnes de la table d'origine peuvent être interrogées.
Notez que l'"+" icône listée à la gauche de l'attribut indique que l'attribut est "public" ; par défaut, tous les attributs extraits des tableaux SGBDR doivent être publics, car le SGBDR permet généralement à toutes les colonnes d'être interrogées sans restriction.
La classe qui est obtenue à partir du mappage direct tableau-classe contiendra souvent des attributs pouvant être séparés dans une classe indépendante, en particulier dans les cas où les attributs se traduisent dans un certain nombre de classes. Ces "attributs répétés" peuvent résulter de la dénormalisation des tableaux pour les raisons de performance, ou peuvent venir d'un modèle de données excessivement simple. Dans ces cas, séparez la classe correspondante en deux classes ou plus pour représenter une vue normalisée des tableaux.
Exemple
Après avoir défini la classe client ci-dessus, nous pouvons définir une classe adresse contenant toutes les informations sur les adresses (en supposant que notre système contiendra autre chose que des adresses), ce qui donne les classes suivantes :
classe client révisée, avec la classe adresse extraite
L'association obtenue entre ces deux classes est une agrégation, dans la mesure où l'adresse du client peut être considérée comme une partie du client.
Pour chaque relation de clé étrangère dans le tableau, créer une association entre les classes associées, en supprimant l'attribut de la classe mappée à la colonne clé étrangère. Si la colonne clé étrangère a été initialement présentée comme un attribut, supprimez-la de la classe.
Exemple
Présumez la structure pour le tableau commande listé ci-dessous :
Nom de colonne | Type de données |
---|---|
Numéro | Numéro |
Code client | Varchar |
Structure du tableau commande
Dans le tableau commande listé ci-dessus, la colonne code client est une référence de clé étrangère ; cette colonne contient la valeur clé primaire du client associé à la commande. Nous représentons cela dans le modèle de conception comme montré ci-dessous :
Représentation des relations de clé étrangère dans le modèle de conception
La clé étrangère est représentée en tant qu'association entre les classes commande et élément.
Les modèles de données SGBDR représentent des relations à origine et destination multiples avec ce qui a été appelé un tableau de jointure, ou un tableau d'association. Ces tableaux permettent de représenter des relations à origine et destination multiples en utilisant un tableau intermédiaire contenant les clés primaires de deux tableaux différents qui peuvent être reliés l'un à l'autre. Les tableaux de jointure sont requis car une référence de clé étrangère peut uniquement contenir une référence à une seule valeur de clé étrangère ; lorsqu'une seule ligne peut être liée à plusieurs autres lignes d'un autre tableau, un tableau de jointure est requis pour les associer.
Exemple
Examiner le cas où des produits, peuvent être fournis par de nombreux fournisseurs, et où un fournisseur peut fournir un certain nombre de produits. Les tableaux produit et fournisseur ont la structure définie ci-dessous :
|
|
Définition des tableaux produit et fournisseur
Pour relier ces deux tableaux l'un à l'autre afin de trouver les produits proposés par un fournisseur donné, nous avons besoin d'un tableau produit-fournisseur défini dans le tableau ci-dessous.
Tableau produit-fournisseur | |
---|---|
Nom de colonne | Type de données |
Code produit | Numéro |
Code fournisseur . | Numéro |
Définition tableau produit-fournisseur
Ce tableau de jointure contient les clés primaires des produits et des fournisseurs, et les relie. Une ligne du tableau indique qu'un fournisseur spécifique propose un produit spécifique. Toutes les lignes dans lesquelles une colonne Code fournisseur correspond à un code fournisseur spécifique fourniront une liste de tous les produits proposés par ce fournisseur.
Dans le modèle de conception, cette table intermédiaire est redondante, car un modèle d'objet peut représenter directement des associations à origine et à destination multiples. Les classes fournisseur et produit et leurs relations sont montrées dans la figure ci-dessous, ainsi que la classe adresse qui est extraite du tableau fournisseur, selon la discussion précédente.
Représentation de la classe produit et fournisseur
Vous trouverez souvent des tableaux qui possèdent une structure similaire. Dans le modèle de données, le concept de généralisation n'existe pas, il n'y a donc pas de manière de représenter le fait que deux tableaux ou plus ont une structure commune. Parfois la structure commune résulte de la dénormalisation pour la performance, comme c'était le cas ci-dessous avec le tableau adresse "implicite" que nous avons extrait dans une classe séparée. Dans d'autres cas, les tableaux partagent des caractéristiques plus fondamentales que nous pouvons extraire dans une classe parente généralisée avec deux sous-classes ou plus. Pour trouver des possibilités de généralisation, cherchez des colonnes répétées dans plusieurs tableaux, où les tableaux sont plus similaires qu'ils ne sont différents.
Exemple
Examinez les tableaux suivants, produit logiciel et produit matériel, comme indiqués ci-dessous :
|
|
Tableaux produit logiciel et produit matériel
Vous remarquerez que les colonnes surlignées en bleu sont identiques ; ces deux tableaux possèdent sensiblement la même définition, et ne diffèrent que très peu. Nous pouvons représenter ce fait en extrayant une classe produit commune, produit logiciel et produit matériel étant des sous-classes du produit, comme indiqué dans la figure suivante :
Classes produit logiciel et produit matériel, montrant la généralisation de la classe produit
La figure ci-dessous regroupe toutes les définitions de classe et montre un diagramme de classe récapitulatif du système de saisie des commandes (uniquement les principales classes).
Diagramme de classe récapitulatif pour le système de saisie des commandes
Il est plus difficile de reproduire le comportement dans la mesure où les bases de données relationnelles ne sont généralement pas orientées objet et n'ont en apparence rien de commun avec les opérations d'une classe dans le modèle d'objet. Les étapes suivantes peuvent aider à reconstruire le comportement des classes identifiées ci-dessus :
Les classes de conception créées à partir des transformations tableaux-à-classe doivent être organisées en packages de conception et/ou en sous-systèmes de conception adaptés dans le modèle de conception, selon les besoins, en se basant sur la structure architecturale globale de l'application. Référez-vous à Concepts : Organisation en couches et Concepts : Architecture logicielle pour une présentation de l'architecture d'application.
RUP (Rational Unified Process)
|