Principes et conseils : Modèle de données
Rubriques
Les modèles de données permettent de concevoir la structure des unités de stockage rémanentes utilisées par le système. Le profil de langage UML utilisé pour la conception des bases de données fournit aux concepteurs de bases de données un ensemble d'éléments de modélisation qui peuvent être utilisés pour développer la conception détaillée des tables des bases de données et modéliser la couche de stockage physique de la base de données.
Le profil de base de données UML fournit aussi des constructions destinées à la modélisation de l'intégrité référentielle (contraintes et déclencheurs), et des procédures stockées permettant de gérer les 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'application individuelle. Les modèles de données de niveau entreprise et service peuvent être utilisés pour donner des définitions standards aux entités métier clés (comme le client et l'employé) qui seront utilisées par toutes les applications à l'intérieur de l'entreprise ou de l'unité métier. Ces types de modèles de données peuvent aussi être utilisés, pour définir le système de l'entreprise qui est "propriétaire" des données d'une entité métier spécifique et définir quels autres systèmes sont les utilisateurs (abonnés) des données.
Ces principes et conseils décrivent les éléments du modèle de profil UML de modélisation de la base de données, utilisés pour construire un modèle de données pour une base de données relationnelle. Du fait qu'il existe de nombreuses publications sur la théorie des bases de données générales, ce chapitre n'aborde pas ce sujet. Pour obtenir des informations de fond sur les modèles de données relationnels et sur les modèles d'objets, voir Concepts:
Bases de données relationnelles et orientation objet.
Remarque : Les représentations de modélisation des données contenues dans ce document sont basées sur le langage UML 1.3. A l'époque où ces principes et conseils ont été développés, le profil de modélisation des données UML 1.4 n'était pas disponible.
Comme cela est décrit dans [NBG01], il existe trois étapes générales dans le développement d'un modèle de données : l'étape conceptuelle, logique et physique. Ces étapes de modélisation des données reflètent les différents niveaux de détail du stockage des données persistantes et des mécanismes de récupération de l'application. Vous trouverez une discussion sur la modélisation conceptuelle des données dans Concepts: Modélisation conceptuelle des données. Vous trouverez dans les deux prochaines parties de cette section Principes et conseils, des résumés de la modélisation logique et physique des données.
Dans la modélisation logique des données, le concepteur de la base de données s'intéresse à l'identification des entités clés et des relations, qui recueillent les informations qui sont nécessaires à l'application et doivent rester durablement dans la base de données.
Durant les activités d'analyse du cas d'utilisation, de conception du cas d'utilisation et de conception des classes,
le concepteur de bases de données et le concepteur
doivent collaborer pour s'assurer que les conceptions évolutives de l'analyse et des classes de conception de l'application permettront le développement de la base de données.
Durant l'activité de conception des classes, le concepteur de bases de données et le concepteur doivent identifier l'ensemble des classes du modèle de conception qui nécessiteront la persistance des données dans la base de données.
Cet ensemble de classes persistantes du modèle de conception fournit une vue du modèle de conception qui, bien qu'elle soit différente du modèle logique de données traditionnel, satisfait beaucoup de besoins similaires. Les classes persistantes utilisées dans le modèle de conception fonctionnent de manière identique aux entités traditionnelles du modèle logique des données. Ces classes de conception reflètent précisément les données qui doivent persister, y compris toutes les colonnes de données (attributs) qui doivent persister ainsi que les relations clés. Cela fait des classes de conception un excellent point de départ pour la conception physique de la base de données.
La création d'un modèle de données logique et séparé est optionnelle. Dans le meilleur des cas, cela se terminerait par l'enregistrement des mêmes informations sous une forme différente. Dans le pire des cas, cela ne se produirait pas et ainsi pourrait ne pas satisfaire les besoins métier de l'application. En particulier, si la base de données est destinée à servir une seule application, alors la vue de l'application des données pourrait être le meilleur point de départ. Le concepteur de bases de données créé des tables, à partir de cet ensemble de classes de conception persistantes, pour former un modèle initial physique de données.
Il peut encore exister des situations dans lesquelles on a besoin du concepteur de bases de données pour créer une conception idéalisée de la base de données qui soit indépendante de la conception des applications. Dans ce cas, la conception logique des bases de données est représentée dans un modèle de données séparé et logique qui fait partie de l'ensemble Artefact : Modèle de données. Ce modèle logique de données représente les entités clés logiques et leurs relations, requises pour satisfaire les exigences du système, afin de maintenir des données cohérentes avec l'architecture globale de l'application. Le modèle logique de données pourrait être construit en utilisant les éléments de modélisation du profil UML de conception des bases de données, décrit plus loin dans le chapitre "Principes et conseils". Pour les projets utilisant cette approche, une étroite collaboration entre les concepteurs d'applications et les concepteurs de bases de données est absolument cruciale pour réussir le développement de la conception de la base de données.
Le modèle logique de données pourrait être affiné en appliquant les règles standard de normalisation, tel que cela est défini dans Concepts:
Normalisation avant de faire évoluer les é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 l'approche principale de l'utilisation des classes du modèle de conception, comme la source des informations liées à la conception logique d'une base de données, destinée à générer un modèle physique de données. Elle illustre également l'approche de remplacement 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 des données constitue l'étape finale du développement, dans la conception de la base de données. Le modèle physique de données comporte les conceptions détaillées de la table liée à la base de données et leurs relations initialement créées à partir des classes de conception persistantes et de leurs relations. La mécanique de transformation des classes du modèle de conception en tables est abordée dans
Principes et conseils : Rétro-conception des bases de données relationnelles. Le modèle physique de données fait partie du Modèle de données ;
ce n'est pas un artefact séparé.
Les tables du modèle physique de données comportent des colonnes bien définies, ainsi que des clés et index, quand cela est nécessaire. Les tables pourraient aussi contenir des déclencheurs, définis de manière à supporter la fonctionnalité de la base de données et l'intégrité de référentielle du système.
En plus des tables, des procédures stockées ont été créées, documentées et associées à la base de données dans laquelle résidera la procédure stockée.
Le diagramme ci-dessous décrit un exemple de certains é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 fictive de vente aux enchères en ligne. Il décrit quatre tables (Vente aux enchères, Offre,
Article et Catégorie d'Enchère), avec une procédure stockée (sp_Enchères) et sa classe conteneur (Gestion Enchères). La figure décrit également les colonnes de chaque table, la clé principale et les contraintes de clés externes, et les index définis dans les tables.

Exemple d'éléments du modèle (physique) de données
Le modèle physique de données contient aussi des correspondances des tables vers les unités physiques de stockage (tablespaces) dans la base de données. La figure ci-dessous illustre un exemple de cette correspondance. Dans cet exemple, les tables Enchères et Etat de la commande sont en correspondance par rapport au tablespace appelé PRINCIPAL. Le diagramme illustre également la modélisation de la réalisation des tables, par rapport à la base de données (désignée par PearlCircle, dans cet exemple).

Exemple d'éléments du modèle de stockage des données
Sur les projets dans lesquels il existe déjà une base de données, le concepteur de la base de données peut faire de la génération de code sur la base de données existante, pour remplir le modèle physique de données. Voir Principes : génération de code sur les bases de données relationnelles pour plus d'informations.
Cette section décrit les principes et conseils généraux pour la modélisation de chaque élément majeur du modèle de données, par rapport au profil UML destiné à modéliser la base de données. Une brève description
de chaque élément du modèle est suivie d'une illustration de l'élément du modèle UML, fournie en exemple. La section Relations de ce document inclut une description de l'utilisation des éléments du modèle.
Les packages UML sont utilisés pour regrouper et organiser les éléments du modèle de données.
Par exemple, des packages pourraient être définis pour organiser le modèle de données en modèles logiques et physiques de données séparés. Des packages pourraient également être utilisés, pour identifier les groupes de tables, reliées de manière logique dans le modèle de données, constituant les "domaines" majeurs des données, significatifs pour le domaine métier de l'application en cours de développement. La figure ci-dessous illustre un exemple de deux packages de domaines (Gestion des Enchères et Gestion des comptes clients), utilisés pour organiser les vues et les tables du modèle de données.

Exemple de packages de domaines
Dans le profil UML utilisé pour la modélisation des bases de données, on modélise une table comme une classe avec un stéréotype <<Table>>. Les colonnes de la table sont modélisées comme des attributs avec le stéréotype <<Colonne>>. Une ou plusieurs colonnes peuvent être désignées comme clé principale fournissant les rangées d'entrées uniques de la table. Les colonnes peuvent aussi être désignées comme des clés externes. Les clés principales et les clés externes ont des contraintes associées, qui sont modélisées respectivement, comme les opérations stéréotypées <<Clé principale>> et <<Clé externe>>. La figure ci-dessous décrit la structure d'un exemple de table, pour la gestion des informations concernant les articles vendus aux enchères, dans un système en ligne de ventes aux enchères

Exemple de table
Des tables peuvent être associées à d'autres tables par les types de relations suivants :
- Identification (agrégation composite)
- Non identification (association)
La section Relations de ce guide fournit des exemples sur l'utilisation de ces relations. Les informations concernant la correspondance de ces relations avec les éléments du modèle de conception sont fournies dans Principes et conseils :
génération de code sur les bases de données relationnelles.
Un déclencheur est une fonction procédurale conçue pour s'exécuter, suite à une action réalisée sur la table dans laquelle réside le déclencheur. Un déclencheur est défini pour s'exécuter lorsqu'une rangée de la table est insérée, mise à jour ou supprimée. De plus, un déclencheur est désigné pour fonctionner soit avant, soit après que la commande de table s'exécute.
Les déclencheurs sont définis comme des opérations d'une table. Ces opérations ont le stéréotype
<<Déclencheur>>.

Exemple de déclencheur
Les index sont utilisés comme des mécanismes permettant des accès plus rapides aux informations, lorsque des colonnes spécifiques sont utilisées pour effectuer des recherches dans la table. Un index est modélisé comme une opération de la table, ayant le stéréotype <<index>>. Les index peuvent être désignés comme éléments uniques et peuvent également être désignés comme éléments groupés ou non.
Les index groupés sont utilisés pour forcer l'ordre des rangées de données de la table à s'aligner sur l'ordre des valeurs de l'index. Un exemple d'opération d'index
(IX_catégorieenchères) est décrit dans la figure ci-dessous.

Exemple d'index
Une vue est une table virtuelle qui ne dispose pas d'une mémoire persistante indépendante. Une vue a les caractéristiques et comportements d'une table et accède aux données des colonnes, à partir de la/des table(s) avec laquelle/lesquelles la vue a défini des relations. Les vues sont utilisées pour assurer un accès plus efficace aux informations d'une ou plusieurs tables ; elles peuvent également être utilisées pour appliquer les règles métier de restriction d'accès aux données des tables. Dans l'exemple ci-dessous, une VueVentesauxEnchères a été définie comme "vue" des informations contenues dans la table Vente aux enchères, décrite dans la section modélisation physique des données de ce guide.
Les vues sont modélisées comme des classes, avec le stéréotype <<vue>>. Les attributs de la classe vue sont les colonnes des tables référencées par la vue. Les types de données des colonnes de la vue sont un héritage des tables, ayant une dépendance définie par rapport à 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, qui peuvent être appliqués aux colonnes dans de multiples tables. 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 un code postal "codepostal + 4".

Exemple de domaine
Un conteneur de procédure stockée est un groupe de procédures stockées dans le modèle de données. Un conteneur de procédure stockée est créé comme une classe UML de stéréotype
<<Conteneur SP>>. De multiples conteneurs de procédure stockée peuvent être créés dans la conception d'une base de données. Chaque conteneur de procédure stockée doit avoir au moins une procédure stockée.
Une procédure stockée est une procédure indépendante qui réside habituellement sur le serveur de la base de données. Les procédures stockées sont documentées comme des opérations groupées en classes, dont le stéréotype est <<Conteneur SP>>. Les opérations ont le stéréotype <<SP>>.
L'exemple ci-dessous décrit une seule opération de procédure stockée (SP_Enchères) de la classe conteneur, appelée GestionEnchères. Lorsqu'il conçoit des procédures stockées, le concepteur de la base de données doit avoir connaissance de l'ensemble des conventions utilisées par le SGBD relationnel spécifique.

Exemple de conteneur de procédure stockée et de procédure stockée
Un tablespace représente la quantité d'espace de stockage attribuée à des articles, tels que les tables, les procédures stockées et les index. Les tablespaces sont liés à une base de données spécifique, par une relation de dépendance. Le nombre de tablespaces et la manière dont ils correspondent aux tables individuelles dépend de la complexité du modèle de données. Les tables auxquelles on accédera fréquemment pourront être partitionnées en de multiples tablespaces. Les tables ne contenant pas de grandes quantités de données auxquelles on accède fréquemment, pourront être groupées dans un seul tablespace.
On définit un conteneur de tablespace pour chaque tablespace. Le conteneur de tablespace est le périphérique de stockage physique du tablespace. Bien qu'on puisse avoir de multiples conteneurs de tablespaces pour un seul tablespace, nous vous recommandons d'attribuer un conteneur de tablespace à un seul tablespace. Les conteneurs de tablespscaes sont définis comme des attributs par rapport au tablespace ; ils ne sont pas modélisés de manière explicite.

Exemple de tablespace
Un schéma documente l'organisation ou la structure de la base de données. Un schéma est représenté comme un package qui a le stéréotype <<Schéma>>. Quand un schéma est défini comme un package, les tables qui composent ce package doivent être comprises dans le schéma. On créé un lien de dépendance entre la base de données et le schéma, pour documenter la relation existant entre la base de données et le schéma.

Exemple de schéma
Une base de données est un ensemble de données, organisé de manière à permettre la consultation et la gestion des informations qu'elle contient. La gestion et la consultation des informations de la base de données se font par l'utilisation d'un Système de Gestion de Base de Données (SGBD) commercial. Une base de données est représentée dans le modèle de données, comme un composant de stéréotype <<Base de données>>.

Exemple de base de données
Le profil UML de modélisation de la base de données définit les relations valides entre les éléments majeurs du modèle de données. Les sections suivantes donnent des exemples de différents types de relations.
Non-identification
Une relation de non-identification est une relation entre deux tables indépendantes dans la base de données. Une relation de non-identification est documentée en utilisant une association entre deux tables. L'association a le stéréotype <<Non identification>>. L'exemple ci-dessous décrit une relation de non-identification entre la table Article et la table CatégorieEnchères.

Exemple d'une relation de non-identification
Identification
Une relation d'identification est une relation entre deux tables, dans lesquelles la table enfant doit coexister avec la table parent. Une relation d'identification est documentée, en utilisant une agrégation composite entre deux tables. L'agrégation composite
a le stéréotype <<Identification>>. La figure ci-dessous est un exemple d'une relation d'identification. Cet exemple montre que les instances de la table enfant (CartedeCrédit) doivent comporter une entrée associée dans la table parent (CompteUtilisateur).

Exemple d'une relation d'identification
Concernant l'association et l'agrégation composite, la multiplicité doit être définie pour documenter le nombre de rangées présentes dans la relation. Dans l'exemple ci-dessus, il existe, pour chaque rangée de la table CompteUtilisateur, au minimum 0 rangée de CartedeCrédit dans la table CartedeCrédit. Pour chaque rangée de la table CartedeCrédit, il y a exactement une rangée dans la table CompteUtilisateur.
La multiplicité est également connue sous le nom de cardinalité.
Vues de la base de données
Lorsqu'on définit une relation des vues d'une base de données, on utilise une relation de dépendance, définie de la vue à la table. Le stéréotype de la dépendance est<<Dérivation>>. Habituellement, on nomme la dépendance des vues. Le nom de la dépendance est identique au nom de la table, qui est défini dans la relation de dépendance avec la vue de la base de données.

Exemple d'une relation de dépendance entre la vue et la table
Tablespace
On utilise une relation de dépendance pour créer un lien entre un tablespace et une base de données spécifique.
Tel que décrit dans la figure ci-dessous, la relation est établie pour illustrer que la base de données est dépendante du tablespace. Plusieurs tablespaces peuvent être associés à une seule base de données du modèle.

Exemple d'une relation de dépendance entre le tablespace et la base de données
On utilise une relation de dépendance pour documenter les relations existant entre les tablespaces et les tables, à l'intérieur d'un tablespace. Une ou plusieurs tables peuvent être associées à un seul tablespace, et une seule table peut être associée à plusieurs tablespaces.
L'exemple ci-dessous montre que la table Enchères est attribuée à un seul tablespace nommé PRINCIPAL.

Exemple d'une relation de dépendance entre une table et un tablespace
Réalisations
Les réalisations sont utilisées pour établir la relation entre une base de données et les tables qu'elle comporte. Une table peut être réalisée par les multiples bases de données du modèle de données.

Exemple d'une relation de réalisation entre la table et la base de données
Procédures stockées
On utilise une relation de dépendance pour documenter la relation existant entre le conteneur de procédure stockée et les tables, sur lesquelles agissent les procédures stockées dans les conteneurs de procédure stockée. L'exemple ci-dessous décrit la relation, en montrant que la procédure stockée SP_Enchères sera utilisée pour accéder aux informations de la table Enchères.

Exemple d'une relation de dépendance entre le conteneur de procédure stockée et la table
Dans la phase de création, les activités initiales de modélisation des données peuvent être réalisées conjointement avec le développement de n'importe quel prototype de conception, comme une partie des activités "Réaliser l'enchaînement d'activités de la synthèse architecturale". Concernant les projets dans lesquels il existe déjà une base de données, le concepteur des bases de données peut faire de la génération de code sur la base de données existante, afin de développer un modèle physique de données initial à partir de la structure de la base de données existante. Voir Principes et conseils : génération de code sur les bases de données relationnelles pour plus d'informations. Les éléments du modèle physique de données peuvent être transformés en éléments du modèle de conception, si cela est nécessaire, pour supporter les activités de création d'un prototype de conception.
Le but de la phase d'élaboration est d'éliminer le risque technique et de produire une architecture stable (de base) pour le système. Dans les systèmes à grande échelle, le souci majeur est de constater qu'un modèle de données, conçu de manière incorrecte conduit à de mauvaises performances. Par conséquent, la modélisation des données et le développement du prototype architectural, permettant d'évaluer la performance de la base de données sont essentiels pour réaliser une architecture stable. Au fur et à mesure que les cas d'utilisation significatifs sur le plan architectural sont détaillés et analysés dans chaque itération, les éléments du modèle de données sont définis sur la base du développement des conceptions de classes persistantes à partir des cas d'utilisation. Au fur et à mesure que les conceptions de classes se stabilisent, le concepteur des bases de données peut périodiquement transformer les conceptions de classes en tables, dans le modèle des données et définir les éléments appropriés du modèle de stockage des données.
A la fin de la phase d'élaboration, les structures majeures de la base de données (tables, index et colonnes clés principales et externes) doivent être mises en place pour supporter l'exécution des scénarios significatifs, définis sur le plan architectural pour l'application.
De plus, les volumes représentatifs de données doivent être chargés dans la base de données, pour supporter les tests de performance architecturale. Basé sur les résultats des tests de performance, le modèle de données devra probablement être ajusté par des techniques d'optimisation, incluant de manière non exclusive la dénormalisation, l'optimisation des attributs de stockage physique ou de la distribution et de l'indexation.
Aucune restructuration majeure du modèle de données ne doit se produire durant la phase de construction. Les tables et éléments de stockage des données supplémentaires peuvent être définis durant les itérations de la phase de construction, basées sur la conception détaillée de l'ensemble des cas d'utilisation et sur les demandes de changements validées, alloués à l'itération. L'accent mis sur la conception de la base de données durant la phase de construction permet de surveiller les performances de la base de données. Cela permet également d'optimiser la conception de la base de données, comme cela est nécessaire dans la dénormalisation, la définition d'index, la création des vues des bases de données, et dans d'autres optimisations techniques.
Le modèle physique de données est l'artefact de conception maintenu par le concepteur des bases de données durant la phase de construction. Il peut être maintenu, en actualisant directement le modèle ou suite aux mises à jour de lecture de l'outil qui ont été effectuées directement sur la base de données.
Le modèle de données, comme le modèle de conception, est maintenu durant la phase de transition
en réponse aux demandes de changement validées. Le concepteur des bases de données doit conserver le modèle de données synchronisé avec la base de données, au fur et à mesure que l'application progresse dans le test de réception final et qu'elle est déployée vers la production.
Si une équipe de développement utilise des outils de modélisation visuels modernes, ayant la capacité de convertir les classes en tables (et vice versa) et/ou la capacité d'inverser l'ingénierie ou encore de faire de la rétro-conception sur les bases de données, alors l'équipe devra définir des conseils de gestion de la transformation et des processus d'ingénierie. Ces principes et conseils sont principalement nécessaires pour les grands projets dans lesquels une équipe travaille parallèlement sur la conception de la base de données et de l'application. L'équipe de développement doit définir les points de développement de l'application (cycle construire/distribuer), pour lesquels il conviendra de transformer les classes en tables et d'effectuer une rétro-conception de la base de données. Une fois que la base de données est créée, l'équipe de développement doit définir pour l'équipe, les conseils de gestion concernant la synchronisation du modèle de données et de la base de données, au fur et à mesure que la conception et la programmation du système évoluent dans le projet.
|