Tâche: Conception de bases de données
Cette tâche explique comment concevoir une base de données afin d'implémenter la persistance au sein d'une application.
Disciplines: Analyse et conception
Objet
  • S'assurer que le stockage des données persistantes est effectué de manière cohérente et efficace.
  • Définir le comportement à implémenter dans la base de données.
Relations
Description principale

Au cours des étapes de cette tâche, nous partons du principe que la conception de la persistance des données dans l'application sera implémentée au moyen d'un système de gestion de base de données relationnelle (SGBDR). Vous devez connaître les concepts relatifs à la base de données, notamment la normalisation et la dénormalisation, et la terminologie propre aux bases de données présentée dans des références telles que [DAT99]. 

Les étapes de cette tâche se réfèrent également au profil Unified Modeling Language (UML) pour la modélisation des bases de données, abordé dans  [NBG01]. De plus, [NBG01] contient une description générale du processus de modélisation et de conception des bases de données relationnelles à l'aide du langage UML.  Pour obtenir des informations sur la relation entre les modèles de données relationnels et les modèles d'objet, consultez le Concept : Bases de données relationnelles et orientation objet.

Etapes
Développement du modèle de données logique (facultatif)
Objet Définir un modèle de conception logique de la base de données.

Le modèle de données logique vise à présenter une vue idéalisée des entités de données logiques clé et de leurs relations, indépendamment de tout logiciel ou implémentation de bases de données spécifiques. Il adopte généralement la troisième forme de normalisation des données (voir Concept : Normalisation), qui minimise les redondances et garantit l'absence de dépendances transitives. Dans ce modèle, l'apparence de la base de données lors de l'enregistrement de données compte plus que les applications qui utilisent les données et les performances de ces applications. Remarquez qu'un modèle de données logique est considéré comme une partie intégrante du Produit : Modèle de données, et non comme un produit RUP à part. Cependant, il est souvent important de définir des modèles de données logiques spécifiques pour :

  • les projets dans lesquels les conceptions de l'application et de la base de données sont développées par des équipes différentes.
  • les projets comportant plusieurs applications qui partagent une base de données commune.

Si vous créez un modèle de données logique, vous pouvez tout innover au moyen des éléments de modèle cités dans les Instructions relatives au produit : Modèle de données ou commencer votre création à partir d'entités pour chaque classe persistante du Modèle d'analyse ou du Modèle de conception.

Vous pouvez choisir de ne pas créer de modèle de données logique spécifique, en particulier si vous concevez une base de données utilisée en tant que seule application. Dans ce cas, le concepteur de base de données développe le modèle de données physique en fonction de l'ensemble de classes persistantes et de leurs associations dans le modèle de conception.

Dans chacune des approches, il est important que le concepteur de base de données et le concepteur collaborent tout au long du processus d'analyse et de conception, afin d'identifier les classes du Produit : Modèle de conception qui doivent stocker des informations dans une base de données. Comme indiqué dans l'étape "Identification des classes persistantes" de la Tâche : Conception de classes, le concepteur de base de données travaille avec le concepteur pour identifier les classes de conception du modèle de conception qui sont considérées comme persistantes et susceptibles de devenir des tables dans une base de données.

Développement de la conception physique d'une base de données
Objet Définir la conception physique détaillée de la base de données.

La conception physique d'une base de données comprend des éléments de modèle (tels que des tables, des vues et des procédures stockées) qui représentent la structure physique détaillée de la base de données, et des éléments de modèle (tels que des schémas et des espaces table) qui représentent la conception du stockage de données sous-jacent.  Ensemble, ces éléments de modèle forment le modèle de données physique de la base de données.  Ce modèle est contenu dans le Produit : Modèle de données et ne constitue pas un produit de modèle à part.

Les étapes détaillées du développement de la conception physique d'une base de données sont les suivantes :

Définition des domaines

Objet Déterminer des types définis par l'utilisateur qui peuvent être réemployés. 

Le concepteur de base de données peut utiliser des domaines pour appliquer des standards de types tout au long de la conception de la base. Les domaines sont des types de données définis par l'utilisateur qui peuvent s'appliquer à une colonne de table.  Ils possèdent les propriétés d'une colonne sans son nom. 

Création des éléments initiaux de conception physique d'une base de données

Objet Créer les tables et les relations initiales d'une base de données.

Le concepteur de base de données modélise les éléments du modèle de données physique à l'aide de tables et colonnes de table, comme décrit dans les Instructions relatives au produit : Modèle de données

Si un modèle de données logique a été créé, ses entités logiques peuvent servir de base à un ensemble de tables initial.

Sinon, le concepteur de base de données peut accélérer la création du modèle en utilisant les classes persistantes du modèle de conception comme point de départ pour les tables du modèle de données physiques.  Le concepteur de base de données modélise les classes persistantes et leurs attributs respectivement sous forme de tables et de colonnes.  Il doit également définir les relations entre les tables selon les associations entre les classes persistantes du modèle de conception.  Les Instructions relatives au produit : Rétro-conception des bases de données relationnelles décrivent le mappage des éléments et relations du modèle de conception vers les éléments et relations du modèle de données.

Si vous construisez votre modèle à partir de classes persistantes et non à partir d'un modèle de données logique normalisé, vous serez généralement amené à appliquer une forme de normalisation afin d'éliminer les redondances de données et les dépendances entre des champs autres que les champs de clé. Voir Concept : Normalisation pour plus d'informations sur la normalisation de la base de données.

Définition des tables de référence

Objet Définir les tables de référence standard utilisées tout au long du projet.

Il existe souvent des tables standard de consultation, de validation ou de référence utilisées tout au long du projet. Les données de ces tables changent souvent et sont souvent consultées ; elles méritent donc une attention particulière. Dans le modèle de conception, ces tables peuvent contenir des codes produit standard, des codes postaux, des tables d'impôts, des tables de validation du code de région ou d'autres informations auxquelles on accède fréquemment. Dans les systèmes financiers, ces tables peuvent contenir des listes de codes de police, des catégories de notation de police d'assurance ou des taux de conversion. Dans le modèle de conception, cherchez des classes qui sont principalement en lecture seule et qui fournissent des informations à des fins de validation pour un grand nombre de clients.

Si la table de référence est petite, ne l'indexez pas. L'indexation risque en effet d'ajouter une surcharge pour les petites tables. Une petite table d'accès fréquent tend également à rester en mémoire, car les algorithmes d'utilisation de l'antémémoire gardent les tables d'accès fréquent dans la mémoire cache des données.

Si possible, assurez-vous que la mémoire cache de la base de données est assez grande pour garder toutes les tables de référence et un espace nécessaire à la gestion des requêtes et des transactions. Le secret de l'amélioration des performances d'une base de données consiste souvent à réduire le nombre d'entrées-sorties sur le disque.

Après avoir défini les structures des tables de référence, déterminez une stratégie pour renseigner ces tables. L'accès à ces tables étant effectué à peu près en début de projet, il est souvent nécessaire de déterminer les valeurs de référence et de charger les tables relativement tôt lors de l'exécution de l'application. Si le concepteur de base de données n'est pas responsable de l'obtention de données, il est néanmoins chargé de déterminer le mode opératoire de l'actualisation des tables de référence et le moment où elle doit avoir lieu.

Création de la clé primaire et des contraintes d'unicité

Objet Définir la ou les colonnes qui identifient de manière unique une ligne de table.
Définir les contraintes sur les colonnes qui garantissent l'unicité des données ou de l'ensemble de données.

Une clé primaire désigne une ou plusieurs colonnes qui identifient de manière unique les lignes d'une table. Chaque table contient une seule clé primaire. Il existe souvent une clé "naturelle" qui permet d'identifier une ligne de données de façon unique (par exemple, le code postal dans une table de référence). La clé primaire ne doit pas contenir de données susceptibles d'évoluer avec l'environnement métier. Si la clé "naturelle" est une valeur qui risque de changer (comme le nom d'une personne), nous recommandons alors au concepteur de base de données de créer, pour la clé primaire, une seule colonne sans signification métier, non saisie par l'utilisateur. Ainsi, la structure de données créée est plus flexible face aux changements apportés dans la structure, l'environnement et les règles du métier.

L'utilisation en tant que clé primaire d'une colonne sans signification métier et non saisie par l'utilisateur est un concept essentiel dans la conception d'un entrepôt de données. Les sytèmes transactionnels choisissent souvent une clé primaire "naturelle" susceptible de subir un changement minime, plutôt qu'une colonne non significative, non renseignée par l'utilisateur.

Une contrainte d'unicité indique que les données de la colonne ou de l'ensemble des colonnes sont uniques pour chaque ligne. Si la contrainte d'unicité s'applique à une colonne, les données d'une ligne particulière de la colonne spécifiée doivent être différentes des données d'une autre ligne de cette colonne. 

Si la contrainte d'unicité est définie pour un groupe de colonnes, l'unicité concerne l'ensemble des données de ces colonnes, prises de manière collective. Il n'est pas nécessaire que les données d'une ligne d'une colonne spécifiée soient différentes des données d'une autre ligne de cette colonne. Le concepteur de base de données utilise la contrainte d'unicité pour garantir le caractère unique des données métier.

Définition des règles d'intégrité des références et des données

Objet Garantir l'intégrité de la base de données.

Les règles d'intégrité des données, également appelées contraintes, garantissent que les valeurs des données se situent dans des plages définies. Lorsque des plages peuvent être identifiées, la base de données peut les faire respecter. Cela ne signifie pas que vous devez omettre le processus de validation des données dans l'application, mais seulement que la base de données peut servir de "valideur en dernier ressort", en cas de mauvais fonctionnement de l'application. Lorsque des règles de validation existent, les contraintes de la base de données doivent être conçues de manière à les faire respecter.

Une clé externe désigne une ou plusieurs colonnes de table mappées à la clé primaire d'une autre table. Une table peut comporter de nombreuses clés externes, et chaque clé externe est mappée à une table différente. Ce mappage, ou relation, entre les tables est souvent désigné comme une relation parent-enfant. La table enfant contient la clé externe qui est mappée à la clé primaire de la table parent. 

La définition de clés externes est également souvent utilisée par l'optimiseur de requêtes pour accélérer les requêtes.  Dans de nombreux cas, les règles pour le respect de la clé externe utilisent des tables de référence.

Dénormalisation de la conception de la base de données à des fins d'optimisation et d'amélioration des performances

Objet Optimiser les structures de données de la base de données pour de meilleures performances.

Dans le cas d'un modèle de données relationnel, le mappage initial résulte souvent en un mappage simple classe-table. Si des objets de différentes classes doivent être extraits simultanément, le SGBDR effectue une opération appelée "jointure de table" pour extraire les lignes relatives aux objets concernés. Pour les données d'accès fréquent, les opérations de jointure peuvent coûter cher en termes de calcul. Afin d'éliminer le coût d'une jointure, on recourt souvent à une technique relationnelle standard appelée "dénormalisation".

La dénormalisation regroupe des colonnes de deux tables différentes ou plus dans une même table, réunissant ainsi les informations à l'avance. Elle reflète le choix d'effectuer des opérations d'extraction moins coûteuses, au détriment des opérations de mise à jour plus coûteuses. Cette technique réduit également les performances du système dans les requêtes qui ne concernent que les attributs de l'un des objets effectivement joints dans la table dénormalisée, car tous les attributs sont normalement extraits dans toutes les requêtes. Les performances s'améliorent de façon significative lorsque l'application souhaite généralement obtenir tous les attributs.

La dénormalisation de plus de deux tables est rare et accroît le coût des insertions et des mises à jour, ainsi que celui des requêtes autres que les requêtes de jointure. Il est bon de limiter la dénormalisation à deux tables, à moins de pouvoir fournir une preuve solide et convaincante des avantages à tirer d'une stratégie inverse.

La dénormalisation peut être induite par les classes de conception lorsqu'elles sont imbriquées. Les classes imbriquées peuvent être mappées vers une table dénormalisée.

Certaines bases de données objet permettent la réalisation d'un processus semblable à la dénormalisation, dans lequel les objets associés sont rassemblés sur le disque dur et extraits en une seule opération. Le concept est semblable : il s'agit de réduire le temps d'extraction en diminuant la quantité de travail fournie par le système pour extraire des objets associés de la base de données.

Dans certains cas, l'optimisation du modèle de données peut faire apparaître des problèmes dans le modèle de conception, notamment des goulots d'étranglement en termes de performances, une modélisation insuffisante ou des conceptions incomplètes. Le cas échéant, discutez de ces problèmes avec le concepteur de la classe, en lançant si nécessaire des procédures de demande de changement.

Optimisation de l'accès aux données

Objet Rendre l'accès aux données efficace grâce à l'indexation.
Rendre l'accès aux données efficace grâce aux vues de la base de données.

Après la conception de la structure des tables, vous devez déterminer les types de requêtes à effectuer sur les données. L'indexation est utilisée par les bases de données pour accélérer l'accès. Elle est le plus efficace lorsque les valeurs des données de la colonne en cours d'indexation sont relativement distinctes.

Prenez en compte les principes d'indexation suivants :

  • La colonne de clé primaire de la table doit toujours être indexée. Les colonnes de clé primaire sont souvent utilisées comme clés de recherche pour les opérations de jointure.
  • Les tables contenant moins de 100 lignes et un petit nombre de colonnes ont peu intérêt à être indexées. Généralement, ces petites tables tiennent facilement dans la mémoire cache de la base.
  • Il est également nécessaire de définir des index pour les requêtes fréquentes ou les requêtes qui nécessitent une extraction rapide des données (en général, toute recherche effectuée pendant qu'une personne est susceptible d'attendre). Un index doit être défini pour chaque groupe d'attributs utilisés ensemble comme critères de recherche. Par exemple, si le système doit être capable de trouver toutes les Commandes dans lesquels apparaît un certain produit, il est nécessaire de créer un index sur la colonne du numéro de produit dans la table Ligne article.
  • En principe, les index doivent être définis uniquement sur les colonnes utilisées comme identifiants, et non sur des valeurs numériques, telles que les soldes d'un compte, ni sur des informations textuelles, telles que les commentaires de commandes. Les valeurs des colonnes d'identifiant tendent à être attribuées lors de la création de l'objet et restent invariables pendant toute la vie de l'objet.
  • Les index créés sur des nombres simples (types de données numériques et entiers) sont beaucoup moins complexes et plus rapides que les index créés sur des chaînes. Etant donné qu'une requête ou une jointure importante nécessite le traitement d'un volume de données conséquent, les petites économies s'accumulent très vite. Les index créés sur des colonnes numériques tendent à consommer beaucoup moins d'espace que les index créés sur des caractères.

D'un autre côté, le recours aux index n'est pas gratuit : plus une table contient d'index, plus le temps de traitement des insertions et mises à jour est long. Lorsque vous envisagez d'utiliser des index, gardez à l'esprit les précautions suivantes :

  • N'indexez pas dans le seul but d'accélérer une requête peu fréquente, à moins que cette requête ait lieu à un instant critique et qu'il soit essentiel d'atteindre une vitesse maximale.
  • Dans certains systèmes, les performances de mise à jour et d'insertion sont plus importantes que les performances de requête. Un exemple courant : les applications d'acquisition de données de fabrication dans lesquelles les données de qualité sont enregistrées en temps réel. Dans ces systèmes, seules des requêtes en ligne occasionnelles sont exécutées, et la plupart des données sont analysées périodiquement par des applications de génération de rapports par lots qui effectuent des analyses statistiques. Dans les systèmes d'acquisition de données, supprimez tous les index pour atteindre un débit maximal. Si des index sont nécessaires, ils peuvent être reconstruits juste avant la génération de rapports par lots et l'exécution des applications d'analyse, puis supprimés au terme de la génération de rapports et de l'analyse.
  • Souvenez-vous toujours que les index ont des coûts cachés. Par exemple, ils consomment du temps pour leur mise à jour (chaque insertion, mise à jour ou suppression a un coût) et occupent de l'espace disque. Assurez-vous du caractère avantageux de leur utilisation.

De nombreuses bases de données offrent un choix de types d'index. Les plus courants sont les suivants :

  • Index B-tree - Le type d'index le plus utilisé repose sur une structure en arbre binaire. Ils sont utiles lorsque des valeurs clé d'index sont réparties de manière aléatoire et tendent à subir de grandes variations. Cependant, ils tendent à donner des résultats insuffisants lorsque les données en cours d'indexation suivent déjà un ordre séquentiel.
  • Index hachés - Plus rarement, les valeurs de clé d'index sont hachées. Le hachage offre de meilleures performances lorsque la plage des valeurs de la clé d'index est connue, relativement constante et unique. Cette technique repose sur l'utilisation de la valeur de clé pour calculer l'adresse des données concernées. En raison du besoin de prévisibilité, les index hachés tendent à être utiles uniquement pour les tables de consultation de taille moyenne peu souvent modifiées.

Vos choix de stratégie d'indexation et de temps de création d'index peuvent avoir un impact important sur les performances. Les chargements de données conséquents doivent être effectués sans index (il suffit de supprimer l'index, charger les données, puis recréer l'index). En effet, la structure de l'index est rééquilibrée à chaque ajout de ligne. Etant donné que les lignes suivantes vont modifier la structure d'index optimale, le rééquilibrage de l'index à chaque insertion de ligne vous fera perdre beaucoup de temps. Il est plus rapide et plus efficace de charger les données sans index, puis de recréer l'index au terme du chargement de données. Certaines bases de données proposent des chargeurs de grande quantité de données qui effectuent l'opération automatiquement.

L'utilisation des vues constitue une autre stratégie d'optimisation des performances d'accès à la base de données. Les vues de la base de données sont des tables virtuelles qui ne possèdent pas de stockage propre et indépendant. Toutefois, pour le programme (ou utilisateur) appelant, une vue se comporte comme une table. Une vue autorise l'extraction de données et peut également être utilisée pour mettre à jour les données, selon la structure de la base de données et le fournisseur de bases de données. La vue contient des données d'une ou plusieurs tables auxquelles il est possible d'accéder à l'aide d'une seule instruction SELECT. Les gains de performances ont lieu lors de la sélection de données, en particulier dans les tables faisant souvent l'objet de requêtes. Les données sont extraites à partir d'un seul emplacement (la vue), ce qui évite d'effectuer une recherche dans les nombreuses ou grandes tables de la base de données.

Les vues jouent également un rôle important dans la sécurité de la base de données. Une vue qui contient des parties d'une table peut restreindre l'accès aux données contenues dans la table de la base.

Définition des caractéristiques de stockage

Objet Concevoir l'attribution d'espace et l'organisation des pages du disque concernant la base de données.

Un concepteur de base de données utilise les espaces table pour représenter le volume d'espace de stockage attribué aux tables, index, procédures stockées, etc. Un ou plusieurs espaces table sont mappés vers une base de données. Le concepteur de base de données doit analyser les tables du modèle de données pour déterminer leur mode de répartition, ainsi que d'autres éléments de support de la base de données, dans l'espace de stockage de la base.

Lorsque vous déterminez les structures de l'espace table pour la base de données, souvenez-vous que les bases de données n'effectuent pas d'entrées-sorties sur des lignes, des enregistrements ou même des tables entières. Elles effectuent des entrées-sorties sur des blocs disque. La raison en est simple : les opérations d'entrée-sortie sur les blocs sont généralement optimisées dans le logiciel et le matériel sur le système. En conséquence, l'organisation physique des tables et des index dans la base de données peut avoir un impact considérable sur les performances du système.

Lorsque vous planifiez l'attribution d'espace et l'organisation des pages du disque pour la base de données, prenez en compte les facteurs suivants :

  • la densité des informations dans les pages du disque
  • l'emplacement des pages sur le disque ou sur plusieurs disques
  • le volume d'espace disque à attribuer à la table

Ces facteurs sont abordés dans les sections suivantes.

Densité des pages du disque

La densité des pages du disque dépend des prévisions concernant les changements des données au fil du temps. Une page moins dense accepte mieux les changements apportés aux valeurs ou l'ajout de données au cours du temps, mais une page de données plus dense offre de meilleures performances de lecture, car la quantité de données extraite par lecture de bloc est plus élevée.

Pour simplifier la gestion du disque, le concepteur de base de données peut regrouper des tables en fonction de leur tendance au changement. Les trois groupes suivants constituent un bon point de départ pour ce type d'organisation :

  • tables très dynamiques
  • tables légèrement dynamiques
  • tables essentiellement statiques

Les tables très dynamiques devraient être mappées à des pages de disque qui contiennent beaucoup d'espace vide (par exemple 30%), les tables légèrement dynamiques à des pages qui contiennent moins d'espace vide (par exemple 15%), et les tables essentiellement statiques à des pages qui contiennent très peu d'espace vide (par exemple 5%). Les index de ces tables doivent suivre ce type de mappage.

Emplacement des pages du disque

Après avoir mappé les groupes de table, le concepteur de base de données doit déterminer l'emplacement des pages du disque. Le but est de répartir au mieux la charge de travail entre un certain nombre d'unités disque afin de réduire ou d'éliminer les goulots d'étranglement. Tenez compte des instructions suivantes :

  • Ne placez jamais de données sur le même disque que celui du système d'exploitation, de ses fichiers temporaires ou de ses unités de pagination. Ces unités sont déjà suffisamment encombrées sans l'ajout d'une charge de travail supplémentaire.
  • Placez sur différentes unités les données auxquelles l'utilisateur accède simultanément, afin d'équilibrer la charge de travail. Certains systèmes prennent en charge les canaux d'entrées-sorties parallèles. Si c'est le cas, placez les données sur différents canaux.
  • Placez les index et les données associées sur des unités différentes afin d'étaler la charge de travail.
  • Reportez-vous à la documentation du fournisseur de bases de données pour obtenir des instructions.
  • Le type de stockage utilisé (par exemple, RAID-5, RAID-10, SAN, NAS et association à un canal) influe sur les performances de la base de données. Utilisez les instructions de votre fournisseur de stockage concernant les performances.

Les entrées-sorties de la base de données limitent généralement ses performances. L'équilibrage des entrées-sorties est un processus itératif expérimental. Lors de la phase d'élaboration, effectuez un prototype des performances de l'accès à la base de données, accompagné des instruments appropriés pour surveiller les entrées-sorties physiques et logiques, afin de mettre au jour les problèmes de performances pendant qu'il est encore temps d'ajuster la conception de la base.

Attribution d'espace disque

A l'aide des caractéristiques du mécanisme de conception de persistance, évaluez le nombre d'objets à stocker. Le volume d'espace disque nécessaire au stockage des objets varie de SGBDR en SGBDR. Lors du calcul de l'espace disque, assurez-vous de prendre en compte la croissance due aux ajouts de données.  Pour évaluer l'espace disque nécessaire à une base de données, évaluez d'abord l'espace disque requis pour chaque table, puis calculez les exigences d'espace pour toutes les tables.  Consultez le manuel d'administration de base de données relative au produit SGBDR concerné afin de connaître la formule précise d'estimation de la taille.  Voici quelques étapes générales à suivre pour estimer les exigences d'une table en termes d'espace :

  • Calculez la taille moyenne d'une ligne.  Ce calcul doit comprendre toutes les informations de contrôle au niveau de l'enregistrement, ainsi que les informations de contrôle requises pour les colonnes de longueur variable.
  • Calculez le nombre de lignes que pourra contenir une page ou un bloc d'entrées-sorties. De nombreuses bases de données stockant uniquement des enregistrements complets sur une page ou un bloc d'entrées-sorties, il devrait s'agir du nombre entier de lignes que pourra contenir une page ou un bloc d'entrées-sorties.
  • Calculez le nombre de pages ou de blocs d'entrées-sorties nécessaires au stockage du nombre d'enregistrements estimé dans la base de données.  Le nombre d'enregistrements estimé doit inclure tous les facteurs de charge.
  • Multipliez le nombre de pages ou de blocs d'entrées-sorties requis par la taille de la page ou du bloc.
  • Ajoutez toute surcharge pour les index supplémentaires.
  • Ajoutez toute surcharge fixe pour la table.

Après avoir défini les exigences en termes d'espace table :

  • Calculez le total de l'espace requis par les tables.
  • Ajoutez tout volume fixe d'espace nécessaire à la gestion de la base de données.
  • Ajoutez l'espace disque nécessaire au journal des transactions et à la trace de contrôle. 

Dans un environnement fréquemment mis à jour, les exigences de conservation de la trace de contrôle nécessitent des volumes de stockage importants. La documentation des principaux systèmes de gestion de base de données sur le marché fournit généralement des instructions détaillées sur l'estimation des volumes. Veillez à suivre ces instructions lorsque vous évaluez les exigences de la base de données en termes d'espace disque.

Conception des procédures stockées pour distribuer le comportement des classes à la base de données

Objet Déterminer la nécessité d'utiliser des procédures mémorisées ou des déclencheurs pour implémenter les opérations de classe d'accès aux données.

La plupart des bases de données prennent en charge une capacité de procédure stockée. Une procédure stockée est un code qui peut être exécuté dans l'espace de processus du système de gestion de base de données. Elle permet d'effectuer sur le serveur des actions relatives à une base de données, sans nécessiter le transfert des données dans un réseau. L'utilisation judicieuse des procédures stockées peut permettre d'améliorer les performances du système.

Les procédures stockées sont habituellement de deux types : procédures effectives ou déclencheurs. Les procédures sont exécutées explicitement par une application, possèdent généralement des paramètres et fournissent une valeur de retour explicite. A l'inverse, les déclencheurs sont appelés de manière implicite lorsqu'un événement de base de données se produit (par exemple, insertion d'une ligne, mise à jour d'une ligne ou suppression d'une ligne). Ils ne possèdent aucun autre paramètre que la ligne en cours de modification (puisqu'ils sont appelés implicitement) et ne fournissent pas de valeur de retour explicite.

Dans les systèmes de base de données qui manquent de contraintes, les déclencheurs permettent souvent de faire respecter l'intégrité des références et des données. Dans d'autres cas, ils tendent à être utilisés lorsqu'un événement doit déclencher (ou causer) un autre événement. Ils sont aussi fréquemment utilisés à des fins de sécurité lors du contrôle de l'événement déclencheur.

Il est nécessaire d'examiner les classes de conception du modèle de conception pour vérifier si elles contiennent des opérations qui doivent être implémentées à l'aide d'une procédure stockée ou d'un déclencheur. Les opérations candidates sont les suivantes :

  • toutes les opérations qui concernent essentiellement des données persistantes (création, mise à jour, extraction ou suppression de ces données).
  • toutes les opérations dans lesquelles un calcul implique une requête (telles que le calcul de la quantité et de la valeur moyennes d'un produit en stock).
  • les opérations qui doivent accéder à la base de données pour valider les données.

Souvenez-vous que l'amélioration des performances d'une base de données passe généralement par la réduction des entrées-sorties. Par conséquent, si effectuer un calcul sur un serveur SGBDR permet de réduire le volume de données circulant dans le réseau, il sera préférable d'opter pour cette solution.

Collaborez avec le concepteur de la classe de conception pour discuter des moyens d'utilisation de la base de données pour améliorer les performances. Le concepteur mettra à jour la méthode d'une opération pour indiquer si une ou plusieurs procédures stockées peuvent être employées pour implémenter cette opération.

Revue des résultats
Objet S'assurer de la qualité et de l'intégrité du Modèle de données.

Tout au long de cette tâche, vous devez constamment vous référer à la Liste de contrôle : Modèle de données pour évaluer l'exhaustivité et la qualité de l'effort.  De plus, le concepteur de base de données doit régulièrement réviser la structure implémentée de la base de données, afin de vérifier la cohérence du modèle de données avec tous les changements directement effectués dans la base.  Si le projet utilise des outils de modélisation de données qui prennent en charge la synchronisation du modèle de données avec la structure physique de la base de données, le concepteur de la base doit régulièrement confronter l'état du modèle de données avec la base de données et effectuer les ajustements nécessaires. 

Les défauts identifiés qui ne seront pas corrigés dans cette étape doivent être détaillés dans les Demandes de changement, puis assignés à une personne qui en deviendra propriétaire et sera chargée de sa résolution.

Plus d'informations