Instructions: Modèle de données
Le modèle de données capture la conception du stockage permanent des données utilisé par le système. Ces instructions présentent la modélisation de données et son utilisation dans le RUP.
Relations
Description principale

Présentation

Les modèles de données sont utilisés pour conceptualiser la structure du stockage permanent des données utilisé par le système. Le profil du langage de modélisation unifié (UML) pour la conception de base de données fournit aux concepteurs un ensemble d'éléments de modélisation pouvant être utilisés pour développer la conception détaillée de tables dans la base de données et pour modéliser l'agencement de la mémoire physique de la base de données. Le profil UML pour la conception de bases de données fournit aussi des constructions pour modéliser l'intégrité référentielle (contraintes et déclencheurs) et des procédures enregistrées utilisées pour gérer l'accès à la base de données.

Les modèles de données peuvent être construits au niveau de l'entreprise, du service ou de l'individu. Les modèles de données entreprise et service peuvent être utilisés pour fournir les définitions standard des entités métier clés (comme un client ou un employé) qui seront utilisées par toutes les applications d'un commerce ou d'une unité commerciale. Ces types de modèles de données peuvent aussi être utilisés pour définir à la fois le système dans l'entreprise "propriétaire" des données pour une entité métier spécifique et les autres systèmes utilisateurs (abonnés) des données.

Ces instructions décrivent les éléments de modèle du profil UML pour la conception de base de données utilisés pour construire un modèle de données pour une base de données relationnelle. Comme il existe de nombreuses publications sur la théorie générale des bases de données, ces instructions ne reviennent pas dessus. Pour obtenir des informations sur les modèles de données relationnels et les modèles d'objet voir aussi Concept : bases de données relationnelles et orientation objet.

Remarque : Les représentations de modélisation des données contenues dans cette instruction sont basées sur le langage UML 1.3. Lorsque ces instructions ont été écrites, le profil UML 1.4 pour la conception de bases de données n'était pas encore disponible.

Etapes de modélisation de données

Comme décrit dans [NBG01], il y a trois étapes principales dans le développement de modèle de données : conceptuelle, logique et physique.  Ces différentes étapes reflètent les différents degrés de détails de la conception des mécanismes de stockage et d'extraction des données persistantes de l'application. Des informations sur la modélisation conceptuelle de données sont disponibles dans Concepts Modélisation conceptuelle de données.  Vous trouverez des récapitulatifs portant sur la modélisation physique et logique des données dans les deux prochaines sections de cette instruction.

Modélisation logique des données

Dans la modélisation logique de bases de données, le concepteur de base de données doit identifier les entités clés et les relations qui enregistrent les informations importantes que l'application doit conserver dans la base de données.  Pendant les tâches d'analyse du cas d'utilisation, de conception du cas d'utilisation, et de modélisation de la classe, le concepteur de base de données et le concepteur doivent travailler ensemble pour s'assurer que les conceptions en cours des classes d'analyse et de conception pour l'application prendront en charge de manière adéquate le développement de la base de données.  Pendant la tâche de Conception de classe, le concepteur de base de données et le concepteur doivent identifier l'ensemble des classes du modèle de conception qui devront être conservées dans la base de données.

Cet ensemble de classes persistantes dans le modèle de conception fournit une vue modèle de conception qui, bien que différente du traditionnel modèle logique de données, a les mêmes besoins. Les classes persistantes utilisées dans le modèle de conception fonctionnent de la même manière que les entités traditionnelles du modèle logique de données. Ces classes de conception reflètent précisément les données qui doivent être conservées, comme les colonnes de données (attributs) et les relations clé. Ces classes sont donc un très bon point de départ pour la conception physique de base de données.

Il est possible de créer un modèle logique de données à part. Toutefois, dans le meilleur des cas, il finirait par enregistrer les mêmes informations mais sous une forme différente. Dans le pire des cas il ne le ferait pas et ne répondrait donc pas aux besoins métier de l'application. Si la base de données est supposée être utilisée par une seule application, la vue des données de l'application est le meilleur point de départ. Le concepteur de la base de données crée des tables à partir de cet ensemble de classes de conception persistantes pour former un premier modèle physique de données.

Cependant, il peut y avoir des cas dans lesquels le concepteur de base de données sera obligé de créer une conception idéalisée de la base de données indépendante vis à vis de la conception de l'application. Dans ce cas, la conception logique de la base de données est représentée dans un modèle logique de données à part faisant partie de Produit : modèle de données. Ce modèle logique de données décrit les entités logiques clés et les relations nécessaires pour satisfaire les exigences du système concernant les données persistantes cohérentes avec l'architecture d'ensemble de l'application. Ce modèle logique de données peut être construit en utilisant les éléments de conception du profil UML pour la conception de bases de données décrits plus tard dans cette instruction. Pour les projets utilisant cette approche, une collaboration étroite entre les concepteurs de l'application et les concepteurs de la base de données est primordiale pour le succès du développement de la conception de la base de données.

Le modèle logique de données peut être détaillé en appliquant les règles standard de normalisation définies dans Concept: Normalisation avant la modification des éléments du modèle logique de données pour créer la conception physique de la base de données.

La figure ci-dessous décrit la façon primaire d'utiliser les classes du modèle de conception comme source d'informations sur la conception logique de base de données, afin de créer un modèle physique de données initial. Elle illustre aussi l'approche alternative qui consiste à utiliser un modèle logique de données séparé.  

Diagramme décrit dans le texte d'accompagnement.

Approches de la modélisation logique des données

Modélisation physique des données

La modélisation physique de données est la dernière étape du développement dans la conception de bases de données.  Le modèle physique de données est constitué des conceptions détaillées des tables de la base de données et des relations créées initialement à partir des classes de conception persistantes et de leurs relations.  La transformation de classes de modèle de conception en tables est abordée dans Instructions : rétro-conception des bases de données. Le modèle physique de données fait partie du modèle de données ; ce n'est pas un artefact à part entière.

Les tables du modèle physique de données ont des colonnes bien définies, mais aussi des clés et des index. Les tables peuvent aussi avoir des déclencheurs définis pour prendre en charge la fonctionnalité et l'intégrité référentielle du système. En plus des tables, des procédures mémorisées ont été créées, documentées et associées à la base de données dans laquelle la procédure mémorisée sera hébergée.

Le diagramme ci-dessous montre certains des éléments du modèle physique de données.  Cet exemple de modèle fait partie du modèle physique de données d'une application d'enchères en ligne imaginaire. Il comprend quatre tables (Enchère, Offre, Article, et Catégorie de l'enchère), et une procédure mémorisée (Enchère_pm) avec sa classe de conteneur (Gestion de l'enchère).  La figure décrit aussi les colonnes de chaque table, la clé primaire, les contraintes des clés externes et les index définis pour les tables. 

Diagramme décrit dans le texte d'accompagnement.

Exemple d'éléments de modèle (physique) de données

Le modèle physique de données contient aussi les mappages des tables aux unités de stockage physique (espaces table) dans la base de données. La figure ci-dessous est un exemple de ce mappage.  Dans cet exemple, les tables Enchères et Statut de la commande sont mappés vers un espace table appelé PRIMAIRE. Le diagramme illustre le fait de modéliser la réalisation de tables dans la base de données (appelée Pearl Circle dans cet exemple).

Diagramme décrit dans le texte d'accompagnement.

Exemple d'éléments de modèle de stockage de données

Pour les projets où une base de données existe déjà, le concepteur de base de données peut avoir recours à l'ingénierie inverse pour remplir le modèle de données physique.  Voir aussi   Instructions : ingénierie inverse et bases de données relationnelles pour plus d'informations.

Eléments de modèle de données

Cette section décrit les instructions de modélisation générales pour chacun des principaux éléments du modèle de données, d'après le profil UML pour la conception de bases de données. Une brève description de chaque élément de modèle est accompagnée par un exemple d'illustration de l'élément de modèle UML. La section Relation décrit l'utilisation des éléments de modèle.

Package

Les packages standard du langage UML sont utilisés pour regrouper et organiser les éléments du modèle de données.  Par exemple, des packages peuvent être définis pour organiser le modèle de données en deux modèles de données séparés, un modèle physique et un modèle logique.  Les packages peuvent aussi être utilisés pour identifier les groupes de tables liés de manière logique dans les principaux "domaines" des données pour le domaine commercial de l'application en train d'être développée.  La figure ci-dessous décrit un exemple de deux packages de domaines (Gestion des enchères et Gestion du compte utilisateur) utilisés pour organiser les vues et les tables dans le modèle de données.

Diagramme décrit dans le texte d'accompagnement.

Exemple de sujet de domaine de package

Table

Dans le profil UML pour la conception de bases de données, une table est modélisée comme une classe avec un stéréotype de <<Table>>.  Les colonnes de la table sont modélisées comme des attributs avec un stéréotype de <<colonne>>. Une ou plusieurs colonne peuvent être désignées comme clé primaire pour fournir des entrées de ligne uniques dans la table. Les colonnes peuvent aussi être désignées comme clés externes.  Les clés primaires et les clés externes ont des contraintes modélisées respectivement en tant qu'opérations stéréotypées de <<clé primaire>> et de <<clé externe>>.  La figure ci-dessous décrit la structure d'une table utilisée pour gérer des informations sur des objets vendus dans une  vente aux enchères en ligne imaginaire. 

Diagramme décrit dans le texte d'accompagnement.

Exemple de table

Les tables peuvent être liées entre elles grâce aux types suivants de relations :

  • identifiante (agrégation composite)
  • non identifiante (association)

La section Relations de ces instructions montrent comment ces relations sont utilisées. Vous trouverez des informations sur la façon de mapper ces relations à des éléments du modèle de conception dans Instructions : ingénierie inversée et bases de données relationnelles.

Déclencheurs

Un déclencheur est une fonction procédurale conçue pour être exécutée comme le résultat d'une action sur la table dans laquelle le déclencheur est situé. Un déclencheur est exécuté lorsqu'une ligne de la table est insérée, mise à jour ou supprimée. Un déclencheur doit aussi être exécuté avant ou après l'exécution de la commande de la table. Les déclencheurs sont définis comme des opérations dans une table. Les opérations sont stéréotypées <<Déclencheur>>. 

Diagramme décrit dans le texte d'accompagnement.

Exemple de déclencheurs

Index

Les index sont utilisés comme des mécanismes permettant un accès plus rapide aux informations lorsque des colonnes spécifiques sont utilisées pour faire des recherches dans la table.  Un index est modélisé comme une opération dans la table avec un stéréotype d'<<index>>.  Les index peuvent être uniques, groupés ou dégroupés. Les index groupés sont utilisés pour contraindre les lignes de données de la table à être alignées avec l'ordre des valeurs des index. La figure ci-dessous illustre un exemple d'opération d'index (catégorie d'enchère_IX).

Diagramme décrit dans le texte d'accompagnement.

Exemple d'index

Vue

Une vue est une table virtuelle sans mémoire persistante indépendante. Une vue a les caractéristiques et les comportements d'une table. Elle accède aux données des colonnes des tables avec lesquelles la vue a défini des relations. Les vues permettent d'accéder de façon plus efficace aux informations d'une ou plusieurs tables. Elles peuvent aussi être utilisées pour renforcer les règles métier visant à restreindre l'accès aux données des tables. Dans l'exemple ci-dessous, une Vue Enchère a été définie comme une "vue" des informations de la table Enchère décrite dans la section sur la modélisation physique des données de cette instruction.

Les vues sont modélisées comme des classes avec le stéréotype <<vue>>. Les attributs de la vue sont les colonnes des tables utilisées par la vue. Les types de données des colonnes de la vue proviennent des tables ayant une dépendance définie avec la vue.

 Diagramme décrit dans le texte d'accompagnement.

Exemple de vue

Domaine

Un domaine est un mécanisme utilisé pour créer des types de données définis par l'utilisateur pouvant être appliquées à des colonnes à travers des tables multiples. Un domaine est modélisé comme une classe avec le stéréotype <<Domaine>>.  Dans l'exemple ci-dessous, un domaine a été défini pour le code postal "code +4". 

Diagramme décrit dans le texte d'accompagnement.

Exemple de domaine

Conteneur de procédure mémorisée

Un conteneur de procédure mémorisée est un regroupement de procédures mémorisées à l'intérieur du modèle de données. Un conteneur de procédure mémorisée est créé comme une classe UML avec le stéréotype <<Conteneur PM>>. Les conteneurs de procédure mémorisée peuvent être créés dans la conception d'une base de données. Chaque conteneur de procédure mémorisée doit contenir au moins une procédure mémorisée.

Procédure mémorisée

Une procédure mémorisée est une procédure indépendante, résidant généralement sur le serveur de la base de données. Les procédures mémorisées sont documentées comme des opérations regroupées en des classes stéréotypées << Conteneur PM>>. Les opérations sont stéréotypées <<PM>>.  L'exemple ci-dessous montre une opération de procédure mémorisée unique (Enchère_PM) dans une classe de conteneur appelé Gestion Enchère.  Lors de la conception de procédures mémorisées, le concepteur de la base de données doit connaître toutes les conventions de dénomination utilisées par le système de gestion de bases de données relationnelles concerné. 

Diagramme décrit dans le texte d'accompagnement.

Conteneur de procédure mémorisée et exemple de procédure mémorisée

Espace table

Un espace table représente la quantité d'espace de stockage disponible pouvant être allouée aux tables, aux procédures mémorisées et aux index. Les espaces tables sont liés à une base de données spécifique dans une relation de dépendance. Le nombre d'espaces table et la façon dont les tables individuelles seront mappées sur elles dépendent de la complexité du modèle de données. Il peut être utile de diviser les tables consultées régulièrement en espaces table multiples. Les tables ne contenant pas de données consultées régulièrement peuvent être regroupé dans un seul espace table.

Un conteneur d'espace table est défini pour chaque espace table. Un conteneur d'espace table est le périphérique de mémoire physique de l'espace table. Même s'il peut y avoir plusieurs conteneurs d'espaces tables pour un seul espace table, il est préférable qu'un conteneur d'espace table soit affecté à un espace table unique. Les conteneurs d'espace table sont définis en tant qu'attributs de l'espace table ; ils ne sont pas véritablement modélisés.

Diagramme décrit dans le texte d'accompagnement.

Exemple d'espace table

Schéma Début de page

Un schéma documente l'organisation ou la structure de la base de données. Un schéma est représenté comme un package stéréotypé <<Schéma>>. Lorsqu'un schéma est défini comme un package, les tables qui composent ce package devraient être contenues dans le schéma. Une dépendance est créée entre la base de données et le schéma pour documenter la relation entre la base de données et le schéma. 

Diagramme décrit dans le texte d'accompagnement.

Exemple de schéma

Base de données Début de page

Une base de données est une collecte de données organisées de façon à ce que l'on puisse accéder et gérer les informations qu'elles contiennent.  L'accès et la gestion des informations contenues dans la base de données s'effectuent grâce à l'utilisation d'un système de gestion de base de données commercial.  Une base de données est représentée dans le modèle de données comme un composant stéréotypé <<Base de données>>.

Diagramme décrit dans le texte d'accompagnement.

Exemple de base de données

Relations Début de page

Le profil UML pour la conception de base de donnés définit les relations valides entre les principaux éléments du système. Les sections suivantes fournissent des exemples des différents types de relations. 

Non-identifiante

Une relation non-identifiante est une relation entre deux tables qui existent indépendamment dans la base de données. Une relation non-identifiante est sauvegardée en utilisant une association entre les tables. L'association est stéréotypée <<Non-identifiante>>.  L'exemple ci-dessous illustre une relation non-identifiante entre la table Article et la table Catégorie d'enchère.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation non-identifiante

Identifiante

Une relation identifiante est une relation entre deux tables dans laquelle la table enfant doit cohabiter avec la table parent. Une relation identifiante est sauvegardée en utilisant une agrégation composite entre deux tables. L'agrégation composite est stéréotypée <<Identifiante>>. La figure ci-dessous montre un exemple de relation identifiante. Cet exemple montre que les instances de la table enfant (carte de crédit) doivent avoir une entrée associée dans la table parent table (compte utilisateur).

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation identifiante

Pour l'association et l'agrégation composite, la multiplicité doit être définie pour renseigner le nombre de lignes dans la relation. Dans l'exemple ci-dessus, pour chaque ligne de la table compte utilisateur, il peut y a voir 0 ou plus de lignes carte de crédit dans la table carte de crédit. Pour chaque ligne de la table carte de crédit, il y a une ligne exactement dans la table compte utilisateur. La multiplicité est aussi appelée cardinalité.

Vues de la base de données

Lors de la définition d'une relation entre une vue de base de données et une table, une relation de dépendance est utilisée, de la vue vers la table. Le stéréotype de la dépendance est <<Dériver>>. En général, la dépendance de la vue est nommée et son nom est le même que celui de la table définie dans la relation de dépendance avec la base de données.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation de dépendance entre une vue et une table

Espace table

Une relation de dépendance est utilisée pour lier un espace table à une base de données spécifiques. Comme l'indique la figure ci-dessous, une relation est affichée pour montrer que la base de données est dépendante de l'espace table. Dans le modèle, des espaces table multiples peuvent être liés à une base de données unique.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation de dépendance entre un espace table et une base de données

Une relation de dépendance est utilisée pour renseigner la relation entre les espaces table et les tables dans un espace table. Une ou plusieurs tables peuvent être liées à un espace table unique et une table unique peut être liée à plusieurs espaces table. L'exemple ci-dessous indique que la table Enchères est liée à un espace table unique appelé PRIMAIRE.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation de dépendance entre une table et un espace table.

Réalisations

Les réalisations sont utilisées pour établir une relation entre une base de données et les tables qu'elle contient. Une table peut être réalisée par des bases de données multiples dans le modèle de données.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation de dépendance entre une table et une réalisation de base de données.

Procédures mémorisées

Une relation de dépendance est utilisée pour renseigner la relation entre le conteneur de procédure mémorisée et les tables sur lesquelles agissent les procédures mémorisées contenues dans le conteneur de procédure mémorisée. L'exemple ci-dessous décrit ce type de relations en montrant que la procédure mémorisée Enchère_PM sera utilisée pour accéder aux informations contenues dans la table Enchère.

Diagramme décrit dans le texte d'accompagnement.

Exemple de relation de dépendance entre un conteneur de procédure mémorisée et une table

Evolution du modèle de données

Phase de création

Pendant la phase de création, les tâches initiales de modélisation de données peuvent être réalisées en même temps que le développement de prototypes de démonstration du bien fondé de la conception comme faisant partie des tâches de "l'activité de réalisation de synthèse architecturale". Pour les projets où une base de données existe déjà, le concepteur de base de données peut avoir recours à l'ingénierie inverse pour développer un nouveau modèle de données physique basé sur la structure de la base de données existante. Voir aussi Instructions : ingénierie inverse et bases de données relationnelles pour plus d'informations. Des éléments du modèle de données physique peuvent être transformés en éléments du modèle de conception pour prendre en charge des tâches de prototypage démontrant le bien fondé de la conception.

Phase d'élaboration

Le but de la phase d'élaboration est d'éliminer tout risque technique et de produire une architecture stable pour le système. Dans les systèmes à grande échelle, les mauvaises performances résultant d'un modèle de données mal conçu sont un des principaux problèmes liés à l'architecture. La modélisation de données et la mise au point d'un prototype architectural permettant l'évaluation des performances de la base de données sont donc essentielles pour obtenir une architecture stable. De la même façon que les cas d'utilisation importants d'un point de vue architectural sont détaillés et analysés dans chaque itération, les éléments du modèle de données sont définis d'après le développement des conceptions des classes persistantes de cas d'utilisation. A mesure que les conceptions de classes se stabilisent, le concepteur de base de données peut les transformer périodiquement en tables dans le modèle de données et définir les éléments de modèle de stockage de données appropriés.

A la fin de la phase d'élaboration, les principales structures de la base de données (tables, index et colonnes de clés primaires et externes) doivent être mises en place pour prendre en charge l'exécution des scénarios importants d'un point de vue architectural pour l'application. De plus, d'importantes quantités de données doivent être chargées dans la base de données pour prendre en charge la phase de validation des performances architecturales. D'après les résultats des performances, le modèle de données peut avoir besoin d'être ajusté grâce aux techniques d'optimisation, incluant, entre autres, la dénormalisation, l'optimisation des attributs de stockage physique ou de la distribution et l'indexation

Phase de construction

Les restructurations importantes du modèle de données ne doivent pas avoir lieu pendant la phase de construction. Des tables supplémentaires et les éléments de stockage de données peuvent être définis pendant les itérations de la phase de construction d'après la conception détaillée de l'ensemble des cas d'utilisation. Ils doivent être approuvés par les demandes de changement allouées à l'itération. Une des premières préoccupations lors de la phase de construction est de contrôler en permanence les performances de base de données et d'optimiser sa conception pour la dénormalisation, la définition d'index, la création de vues de bases de données et autres techniques d'optimisation.

Le modèle de données physique est l'artefact de conception que le concepteur de base de données gère pendant la phase de construction. Il peut être géré soit en faisant des mises à jour directes dans le modèle, soit en utilisant un outil qui lit les mises à jour qui ont étés faites directement dans la base de données.

Phase de transition

Le modèle de données, comme le modèle de conception, est géré pendant la phase de transition en réponse aux demandes de changement approuvées. Le concepteur de bases de données doit veiller à la synchronisation du modèle de données et de la base de données lorsque l'application subit le test de réception final et est déployé en production.

Considérations sur l'ingénierie aller-retour

Si une équipe de développement utilise des outils de modélisation visuelle ayant la capacité de convertir les classes en tables (et vice-versa) et/ou d'inverser et de rétro-conceptualiser les bases de données, l'équipe doit alors établir des instructions pour gérer la transformation et la conception des processus. Les instructions sont particulièrement utiles pour les grands projets dans lesquels une équipe travaille en parallèle sur la conception de la base de données et de l'application. L'équipe de développement doit définir à quels moments du développement de l'application (cycles de construction et de mise à jour) il faudra procéder à la transformation des classes en tables et à l'inversion de la base de données.  Une fois la base de données initiale créée, l'équipe de développement doit définir des instructions pour que l'équipe gère la synchronisation du modèle de données et de la base de données à mesure que la modélisation et le code du système évoluent pendant le projet.