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.
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é.
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.
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).
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.
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.
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.
Exemple de sujet de domaine de package
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.
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.
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>>.
Exemple de déclencheurs
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).
Exemple d'index
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.
Exemple de vue
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".
Exemple de domaine
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.
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é.
Conteneur de procédure mémorisée et exemple de procédure mémorisée
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.
Exemple d'espace table
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.
Exemple de schéma
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>>.
Exemple de base de données
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.
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).
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.
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.
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.
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.
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.
Exemple de relation de dépendance entre un conteneur de procédure mémorisée et une table
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.
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
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.
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.
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.
|