Artefact :
|
![]() |
Le modèle de données décrit les représentations logiques et physiques des données rémanentes utilisées par l'application. Lorsque l'application utilise un système de gestion de base de données relationnelle (SGBD relationnel), le modèle de données peut aussi inclure des éléments modélisés pour les procédures mémorisées, déclencheurs, contraintes, etc, qui définissent l'interaction des composants de l'application avec ce système. | |
Rôle : | Concepteur de base de données | |
---|---|---|
Caractère facultatif/Occurrence: | Facultatif. Phases de création et d'élaboration. | |
Canevas et rapports : |
|
|
Exemples : | ||
Représentation UML : | Package, stéréotypé en tant que <<modèle>>. | |
Informations supplémentaires : | ||
Entrée d'activités : | Sortie d'activités : |
Le modèle de données permet de décrire la structure logique et physique des informations rémanentes gérées par le système. Le modèle de données peut être créé initialement par génération de code à partir des magasins de données (bases de données) rémanentes existantes ou à partir d'un ensemble de classes de conception rémanentes du Modèle de conception.
Le modèle de données est requis chaque fois que le mécanisme de stockage rémanent est basé sur une technologie non orientée objet. Il est spécifiquement nécessaire lorsque la structure de données rémanente ne peut pas être dérivée automatiquement et mécaniquement de celle des classes rémanentes du modèle de conception. Il est utilisé pour définir le mappage entre classes de conception rémanentes et structures de données rémanentes et pour définir ces dernières.
Le tableau de propriétés ci-dessous décrit les éléments du modèle de données. Les définitions des propriétés du modèle présentées dans ce tableau sont compatibles avec les spécifications du profil de modélisation de données de la version 1.3 du langage UML (Unified Modeling Language). Les éléments du profil de modélisation de données de la version UML 1.4 n'ont pas encore été définis.
Nom de la propriété | Brève description | Représentation UML |
---|---|---|
Introduction | Description textuelle servant de brève introduction au modèle. | Valeur marquée, de type "texte court". |
Packages | Packages utilisés pour regroupement dans l'organisation. | Appartenance via l'association "représente", ou récursivement via l'agrégation "propriétaire de". |
Tables | Tables du modèle de données, appartiennent aux packages. | Classes, stéréotypées en tant que <<Table>>. |
Relation | Association simple entre tables du modèle. | Association, stéréotypée en tant que <<Non identifiante>> |
Relation forte | Relation d'agrégation composite entre tables du modèle. | Association, stéréotypée en tant qu'<<Identifiante>> |
Dépendance (Vue à Table) | Dépendance entre tables, vues et autres éléments du modèle | Dépendance, stéréotypée en tant que <<Dérive>> pour les relations de dépendance entre table et vue |
Colonne | Valeurs des données des tables. | Attribut, stéréotypé en tant que <<Colonne>>. |
Domaine | Type de données défini par l'utilisateur. | Classe, stéréotypée en tant que <<Domaine>>. |
Vue | Table virtuelle, composée de colonnes d'une ou de plusieurs tables. | Classe, stéréotypée en tant que <<Vue>>. |
Diagrammes | Diagrammes du modèle, appartiennent aux packages. | Diagrammes de classes décrivant les tables et leurs relations, et diagrammes de composants décrivant la réalisation des tables du modèle sous forme de composants Espaces de tables et Base de données. |
Index | Structures d'accès aux données utilisées pour accélérer l'accès via des chemins d'accès spécifiés. | Opération, stéréotypée en tant qu'<<Index>>. |
Déclencheur | Comportement activé par un événement et associé à des tables. | Opération, stéréotypée en tant que <<Déclencheur>>. |
Contrainte de vérification | Règle de validation sur une colonne ou une table. Peut consister d'une plage de valeurs valides ou de calculs. | Opération, stéréotypée en tant que <<Vérification>>. |
Contrainte d'unicité | Stipule que les données d'une colonne ou d'un ensemble de colonnes doivent être uniques. | Opération, stéréotypée en tant que <<Unique>>. |
Package de procédures mémorisées | Classe utilisée comme "conteneur" pour les opérations de procédures mémorisées | Classe, stéréotypé en tant que <<SP_Container>> |
Procédure mémorisée | Comportement appelé explicitement, associé à des tables ou au modèle global. | Opération, stéréotypée en tant que <<SP>>. |
Schéma | Conteneur pour éléments du modèle de données qui représente la structure d'ensemble de la base de données. Utilisé pour gérer la sécurité et la propriété des tables. | Package, stéréotypé en tant que <<Schéma>>. |
Base de données | Elément de modèle qui représente la base de données physique | Composant, stéréotypé en tant que <<Base de données>> |
Espace table | Unités de stockage physique dans une base de données | Composant, stéréotypé en tant qu'<<Espace table>> |
Le modèle de données peut être lancé dans la Phase de création, dans le cadre du prototype d'architecture, afin de discerner les ressources existantes réutilisables ou d'accélérer la conception. Au cours de la Phase d'élaboration, un modèle de données est développé jusqu'au niveau requis pour atténuer les risques clés et assurer le support des cas d'utilisation significatifs sur le plan de l'architecture. En particulier, il est généralement important lors de la phase d'élaboration de pouvoir disposer d'un mécanisme fiable pour accéder au stockage des données rémanentes (dans la plupart des cas, une base de données) depuis le reste de l'application.
Un concepteur de base de données est responsable de l'intégrité du modèle de données et doit veiller à ce que ce modèle, dans son ensemble, soit correct, cohérent et intelligible.
Pour les projets comportant peu de données rémanentes ou qui ont recours à une transformation simple des classes de conception vers le mécanisme de rémanence, un modèle de données séparé peut être superflu. Pour les projets utilisant un SGBD relationnel pour la rémanence des données, le modèle de données doit être adapté à la sémantique spécifique de la base de données sous-jacente, qui peut varier légèrement d'un SGBD relationnel à l'autre.
RUP (Rational Unified Process)
|