Principes et conseils :
|
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é |
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 :
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 :
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 :
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 :
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.
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 :
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.
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 :
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.
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.
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)
|