Objet
  • S'assurer que les données persistantes sont stockées de façon cohérente et efficace.
  • Définir le comportement à implémenter dans la base de données.
Rôle :  Concepteur de base de données 
Fréquence : Une fois par itération
Etapes
Artefacts d'entrée :  Artefacts de sortie : 
Guides d'utilisation de l'outil : 

Détails sur l'enchaînement d'activités : 

Les étapes présentées dans cette activité impliquent que la conception des données persistantes de l'application soient implémentées à l'aide d'un système de gestion de base de données relationnel (SGBDR). Elles supposent que vous soyez familiarisé avec les concepts applicables aux bases de données, incluant la normalisation et la suppression de normalisation, et avec la terminologie propre aux bases de données telle que celle rencontrée dans les références telles que [DAT99]. 

Les étapes de cette activité se rapportent également au langage UML (Unified Modeling Language) utilisé pour la modélisation de bases de données, qui est décrit dans  [NBG01]. Par ailleurs, [NBG01] contient une description générale du processus de modélisation et de conception de bases de données relationnelles à l'aide du langage UML. Pour plus d'informations sur le lien entre les modèles de données relationnels et les modèles d'objet, consultez les concepts de bases de données relationnelles et orientation objets.

Développer un modèle de données logiques (facultatif) Haut de la page

Objet Définir un modèle de conception logique de la base de données.

L'objectif du modèle de données logique consiste à fournir une vue idéalisée des principales entités de données logiques et de leurs relations indépendantes de tout logiciel spécifique ou de toute implémentation de base de données. Il se présente généralement comme un formulaire de modélisation de données (voir lesconcepts de normalisation), qui minimise la redondance et ne crée aucune dépendance de transition. Ce modèle décrit la future base de données sous l'angle de la capture de données et non des applications qui utilisent les données et leurs performances. Il est à noter que le modèle de données logiques est considéré comme faisant partie de l'artefact de modèle de données et non comme un artefact RUP indépendant. Toutefois, il est souvent important de définir des modèles de données logiques individuels pour les projets suivants :

  • projets dans lesquels la conception de la base de données et des applications est développée par des équipes indépendantes.
  • projets dans lesquels plusieurs applications partagent une base de données commune.

Si vous créez un modèle de données logiques, vous pouvez commencer à partir de zéro à l'aide des éléments de modèle décrits dans les Principes et conseils de modèle de données, ou encore utiliser des entités pour chaque classe persistante du modèle d'analyse ou du modèle de conception.

Vous pouvez décider de ne pas créer de modèle de données logiques séparé, surtout si vous concevez une base de données servant une seule application. Dans ce cas, le concepteur de base de données développe le modèle de données physique sur la base des classes persistantes et de leurs associations dans le modèle de conception.

Dans les deux approches, il est important pour le concepteur de base de données et pour le concepteur de collaborer tout au long du processus d'analyse et de conception afin d'identifier les classes de l'artefact de modèle de conception qui nécessitent le stockage des informations dans une base de données. Conformément à la description de l'étape intitulée "Identifier les classes persistantes de l'activité de conception de classes," le concepteur de base de données travaille en collaboration avec le concepteur pour identifier les classes de conception du modèle de conception considérées comme persistantes et susceptibles de devenir des tables de base de données.

Développer une conception de base de données physiqueHaut de la page

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

La conception physique de la base de données inclut 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 sous-jacente du stockage de données.  Additionnés, ces éléments de modèle constituent le modèle de données physique de la base de données.  Ce modèle de données physique est contenu dans l'artefact de modèle de données et ne constitue pas un artefact de modèle indépendant.

Les étapes à réaliser pour le développement de la conception de la base de données physique sont les suivantes :

Définir les domaines Haut de la page

Objet Définir les types réutilisables définis par l'utilisateur. 

Le concepteur de base de données peut utiliser les domaines pour mettre en oeuvre des types de données dans la conception de la base de données. Les domaines sont des types de données définis par l'utilisateur et pouvant être appliqués à la colonne d'une table.  Les domaines possèdent les propriétés d'une colonne sans en posséder le nom. 

Créer un ensemble initial d'éléments de base de données physiqueHaut de la page

Objet Créer les tables et les relations initiales de la 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 des tables et des colonnes de tables, conformément à la description figurant dans les Principes et conseils de modèle de données

Si un modèle de données logique a été créé, ses entités logiques peuvent être utilisées comme base pour la création d'un ensemble initial de tables.

Le concepteur de base de données peut également utiliser les classes persistantes du modèle de conception comme point de départ de création de tables dans le modèle de données physique.  Le concepteur de base de données modélise les classes persistantes et leurs attributs sous forme de  tables et de colonnes, respectivement.  Il doit également définir les relations entre les tables, sur la base des associations entre les classes persistantes du modèle de conception.  Une description du mappage entre les éléments et relations du modèle de conception et les éléments et relations du modèle de données est fournie dans les Principes et conseils de génération de code des bases de données relationnelles.

Si vous utilisez des classes persistantes commencer le modèle (et non un modèle de données logique normalisé), vous devez généralement appliquer certains éléments de normalisation pour éliminer les redondances de données et les dépendances de zones. Pour plus d'informations sur la normalisation de base de données, voir les concepts de normalisation.

Définir les tables de référence Haut de la page

Objet Définir les tables de référence standard utilisées dans le projet.

Des tables de recherche, de validation ou de référence sont souvent utilisées dans le projet. Puisque les données de ces tables font généralement l'objet d'un accès fréquent mais aléatoire, une attention particulière doit être accordée à ces données. Dans le modèle de conception, ces tables peuvent contenir des codes produits standard, des codes régionaux, des codes postaux, des tables de validation de code ou d'autres informations à accès fréquent. Dans les systèmes financiers, ces tables peuvent contenir des listes de codes, des catégories de prix de polices d'assurance ou des taux de conversion. Recherchez dans le modèle de conception les classes en lecture seule, qui fournissent des informations de validation à un grand nombre de clients.

Si la table de référence est peu volumineuse, ne créez pas d'index car cela ajouterait du temps système pour de petites tables. Une table peu volumineuse faisant l'objet d'un accès fréquent tend également à rester en mémoire, car les algorithmes de mise en mémoire cache permettent souvent de conserver les tables à accès fréquent dans le cache de données.

Si possible, assurez-vous que la mémoire cache de la base de données est suffisamment grande pour conserver toutes les tables de référence en mémoire, ainsi que l'"espace de travail" consacré aux requêtes et aux transactions. Le secret de l'augmentation des performances de la base de données réside souvent dans la diminution des E/S du disque.

Une fois que les structures des tables de référence sont définies, déterminez une stratégie de remplissage des tables de référence. Puisque l'accès à ces tables a lieu au début du projet, la détermination des valeurs de référence et le chargement des tables doit souvent s'effectuer au début de l'exécution d'applications. Le concepteur de base de données n'est pas chargé d'obtenir les données, mais il est chargé de déterminer quand et comment les tables de références sont actualisées.

Créer la clé primaire et les contraintes uniques Haut de la page

Objet Définir les colonnes qui permettent d'identifier de façon unique une ligne de la table.
Définir les contraintes applicables aux colonnes pour garantir que les données ou les ensembles de données sont uniques.

Une clé primaire représente une ou plusieurs colonnes permettant d'identifier de façon unique des lignes d'une table. Une table possède une seule clé primaire. Il est souvent possible d'utiliser une clé primaire "naturelle" pour l'identification unique d'une ligne de données (par exemple, le code postal d'une table de référence). La clé primaire ne doit pas contenir de données susceptibles d'être modifiées en fonction de l'environnement. Si la clé "naturelle" est une valeur susceptible d'être modifiée (par exemple le nom d'une personne), il est recommandé de créer une colonne sans saisie de l'utilisateur au moment de la création d'une clé primaire. Cela permet de créer une structure de données dotée d'une plus grande adaptabilité vis-à-vis des modifications apportées à la structure, aux règles ou à l'environnement.

L'utilisation de cette colonne comme clé primaire est un concept essentiel de conception d'entrepôt de données. Les systèmes transactionnels utilisent souvent une clé primaire "naturelle" soumise à des modifications minimales dans une colonne sans saisie de l'utilisateur.

Une contrainte unique indique que les données des colonnes sont uniques sur chaque ligne. Si la contrainte unique se trouve dans une seule colonne, les données d'une ligne spécifique de la colonne spécifiée doivent être uniques, distinctes des données figurant sur une autre ligne de la même colonne. 

Lorsqu'une contrainte unique est définie pour un groupe de colonnes, le caractère unique prend comme base l'ensemble des données des colonnes comprises dans la contrainte. Les données d'une ligne spécifique d'une colonne spécifique doivent être uniques, distinctes des données figurant sur une autre ligne de la même colonne.. Le concepteur de base de données utilise la contrainte unique pour garantir le caractère unique des données métier.

Définir les règles d'application de l'intégrité applicables aux données et au référentiel Haut de la page

Objet Garantir l'intégrité des bases de données.

Les règles d'intégrité des données, également connues sous le nom de contraintes, garantissent que les valeurs de données se trouvent dans des plages définies. Lorsque ces plages peuvent être identifiées, la base de données peut les appliquer. (Cela ne signifie pas que la validation des données ne doit pas être effectuée dans l'application, mais uniquement que la base de données peut servir de "validation de secours" si l'application ne fonctionne pas correctement.) Lorsque des règles de validation des données existent, les contraintes doivent être conçues de façon à les mettre en application.

Une clé étrangère correspond à une ou à plusieurs colonnes d'une table mappée(s) à la clé primaire d'une autre table. Une table peut avoir plusieurs clés étrangères et chacune d'entre elles est mappée à une table différente. Ce mappage (ou relation) entre les tables est souvent appelé relation parent-enfant. La table enfant contient la clé étrangère, mappée à la clé primaire de la table parent. 

La définition des contraintes de clé étrangère est souvent utilisée par l'optimiseur de requêtes pour accélérer les performances des requêtes. Dans un grand nombre de cas, les règles d'application de clé étrangère utilisent des tables de référence.

Supprimer la normalisation de la conception de base de données pour optimiser les performances Haut de la page

Objet Optimiser les structures de données de la base de données afin d'augmenter les performances.

Dans le cas d'un modèle de données relationnel, le mappage initial permet généralement d'obtenir un mappage simple entre les classes et les tables. Si des objets de différentes classes doivent être extraits simultanément, le SGBDR utilise une opération appelée "jointure de tables" pour extraire les lignes relatives aux objets concernés. Pour les données faisant l'objet d'un accès fréquent, les opérations de jointure peuvent représenter un coût informatique élevé. Pour éliminer le coût de cette jointure, une technique standard appelée "suppression de la normalisation" est souvent utilisée.

Elle combine les colonnes de deux tables ou davantage au sein de la même table, ce qui effectue une pré-jointure efficace des informations. Cette technique représente un compromis entre les opérations de mise à jour onéreuses et les opérations d'extraction plus abordables. Elle diminue également les performances du système pour les requêtes qui ne concernent que les attributs de l'un des objets joints dans la table, car tous les attributs sont normalement extraits lors de chaque requête. Si l'application extrait normalement tous les attributs, cela peut augmenter considérablement les performances.

L'application de cette technique à plus de deux tables est rare et augmente le coût des insertions et des mises à jour, ainsi que le coût des requêtes sans jointure. La limiter à deux tables est conseillé, sauf si les avantages d'une plus grande utilisation sont prouvés.

Lorsque les classes sont imbriquées, cette technique peut provenir des classes de conception. Les classes imbriquées peuvent être regroupées dans une table dénormalisée.

Certaines bases de données d'objets appliquent un concept similaire qui consiste à former sur le disque des clusters d'objets liés et de les extraire lors d'opérations uniques. Le concept est le même : réduire le temps d'extraction des objets grâce à la réduction des tâches que le système doit effectuer pour extraire les objets liés de la base de données.

Dans certains cas, l'optimisation du modèle de données peut permettre de détecter des problèmes dans le modèle de conception (goulets d'étranglement, problèmes de modélisation ou conception incomplète). Si cela se produit, soumettez le problème rencontré au concepteur de la classe, et envoyez le cas échéant les demandes de modifications correspondantes.

Optimiser l'accès aux données Haut de la page

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

Une fois que la structure de la table a été conçue, vous devez déterminer les types de requêtes exécutées pour les données. L'indexation est utilisée par la base de données pour accélérer l'accès aux données. Elle est plus efficace lorsque les valeurs des données de la colonne indexée 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és primaires sont souvent utilisées en tant que clés de recherche et pour les opérations de jointure.
  • Il y a peu d'avantages à indexer les tables contenant moins de 100 lignes et quelques colonnes uniquement. En effet, les tables peu volumineuses sont contenues sans difficulté dans la mémoire cache de la base de données.
  • Vous devez également définir des index pour les requêtes fréquentes ou pour celles qui doivent extraire des données rapidement (recherches effectuées pendant qu'une personne attend les résultats). Un index doit être défini pour chaque ensemble d'attributs utilisé en tant que critère de recherche. Par exemple, si le système a besoin de trouver toutes les commandes d'un produit spécifique, il est nécessaire d'utiliser un index dans la table des articles et pour la colonne consacrée aux références de produits.
  • En règle générale, les index doivent uniquement être définis pour les colonnes utilisées comme identificateurs, et non sur les valeurs numériques (bilans comptables ou informations textuelles telles que les commentaires de commandes). Des valeurs de la colonne utilisée comme identificateur sont affectées lorsqu'un objet est créé et qu'il reste inchangé pendant le reste de sa durée de vie.
  • Les index sur chiffres simples (nombres entiers et types de données numériques) sont beaucoup plus faciles et rapides que les index sur chaînes. Au vu des volumes importants de données traités par une requête ou une jointure, les gains s'additionnent rapidement.  Les index sur colonnes numériques ont tendance à occuper beaucoup moins d'espace que les index sur caractères.

En revanche, l'utilisation d'index a un coût : plus une table contient d'index, plus le temps d'insertion et de mise à jour est long. Lorsque vous envisagez l'utilisation d'index, gardez à l'esprit les conseils suivants :

  • N'utilisez pas d'index uniquement dans le but d'accélérer une requête occasionnelle, sauf si elle est exécutée à un point critique nécessitant une vitesse maximale.
  • Sur certains systèmes, les performances d'insertion et de mise à jour sont plus importantes que les performances des requêtes. Par exemple, les applications d'acquisition de données supposent une capture des données en temps réel. Pour ces systèmes, seules des requêtes occasionnelles en ligne sont exécutées et les données sont pour la plupart analysées périodiquement par des applications de traitement par lots utilisées pour la génération de rapports, qui effectuent des analyses statistiques sur ces données. Pour les systèmes d'acquisition de données, supprimez tous les index afin de bénéficier d'un débit maximal. Si des index sont requis, ils peuvent être élaborés juste avant l'exécution des applications d'analyse et de génération de rapports, puis supprimés une fois l'analyse et la génération de rapports terminées.
  • Souvenez-vous que les index comportent des coûts cachés. Par exemple, ils sont consommateurs de temps car ils doivent être mis à jour à chaque insertion, mise à jour ou suppression et occupent de l'espace disque. Assurez-vous que leur utilisation vous sera profitable.

De nombreuses bases de données offrent un grand choix de types d'index. Les plus fréquemment utilisés sont les suivants :

  • Index de type arbre binaireLes index les plus utilisés prennent comme base les structures de données à arbre binaire. Ils sont utiles lorsque les valeurs clés d'index sont distribuées de façon aléatoire et ont une capacité de variation élevée. En revanche, leurs performances sont faibles lorsque les données indexées se trouvent déjà en ordre séquentiel.
  • Index hachés-Moins fréquents ; les valeurs clés sont hachées. Le hachage offre de bonnes performances lorsque la plage des valeurs clés est connue, faiblement variable et unique. Cette technique s'appuie sur l'utilisation de la valeur clé pour le calcul de l'adresse des données recherchées. En raison du besoin de prévisibilité, les index hachés ne sont utiles que pour les tables de recherche de taille moyenne peu modifiées.

Votre choix de stratégie en matière d'indexation et le calendrier de création d'index peuvent avoir un impact important sur les performances. Les chargements de grandes quantités de données doivent s'effectuer sans index (l'index doit dans ce cas être supprimé avant le chargement des données, puis créé de nouveau). En effet, la structure d'index est rééquilibrée à chaque ajout de ligne. Puisque les lignes ultérieures modifieront la structure d'index optimale, le rééquilibrage de l'index lors de l'insertion de chaque ligne constitue un gaspillage. Il est plus rapide et plus efficace de charger les données sans index, puis de créer de nouveau l'index une fois le chargement terminé. Certaines bases de données contiennent des chargeurs de données de masse qui se chargent automatiquement d'effectuer cette opération.

Une autre stratégie d'optimisation des performances de la base de donnes consiste à utiliser les vues. Les vues sont des tables virtuelles qui ne possèdent pas de stockage indépendant. Toutefois, pour le programme ou l'utilisateur, une vue a le même comportement qu'une table. Les vues assurent le support des extractions de données, et peuvent être utilisées pour les mises à jour de données également (en fonction de la structure et du fournisseur de la base de données). Elles contiennent des données issues d'une ou de plusieurs tables accessibles via une instruction de sélection. Le gain de performances a lieu pendant la sélection des données, et il est significatif pour les tables fréquemment interrogées. Les données sont extraites à partir d'un emplacement de la vue (et non via une recherche dans des tables nombreuses ou volumineuses de la base de données).

Les vues jouent par ailleurs un rôle important dans la sécurité de la base de données. Une vue contenant des parties de table peut limiter l'accès aux données sensibles figurant dans cette table.

Définir les caractéristiques de stockage Haut de la page

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

Les concepteurs de base de données utilisent les espaces table pour représenter la quantité d'espace de stockage allouée aux tables, aux index, aux procédures stockées, etc. Un ou plusieurs espaces table sont mappés à 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 comment distribuer ces tables (ainsi que les autres éléments de support de la base de données) dans l'espace de stockage de la base de données.

Lorsque vous déterminez les structures d'espaces table de la base de données, gardez présent à l'esprit que les bases de données n'effectuent pas d'opérations d'E/S sur les lignes, dans les enregistrements ou dans les tables. Elles effectuent ces opérations dans les blocs de disque. La raison en est simple : les opérations d'E/S sur les blocs sont généralement optimisées dans les éléments logiciels et matériels du système. Par conséquent, l'organisation physique des tables et des index de la base de données peut avoir un impact très important sur les performances du système.

Lorsque vous planifiez l'allocation d'espace et l'organisation des pages de disque de la base de données, tenez compte des facteurs suivants :

  • densité des informations contenues dans les pages du disque
  • emplacement des pages sur le disque et sur les unités
  • quantité d'espace disque à allouer à la table

Ces facteurs sont détaillés dans les sections ci-après.

Densité des pages de disque

La densité des pages de disque dépend du niveau de modification des données escompté pour l'avenir. Généralement, une page peu dense est plus à même d'accepter des modifications de valeurs ou l'ajout de données, tandis qu'une page plus remplie permet d'obtenir de meilleures performances de lecture, car une plus grande quantité de données est extraite lors de chaque lecture de bloc.

Pour simplifier la gestion du disque, le concepteur de base de données peut regrouper les tables par niveau de modification. Les trois groupes suivants sont un bon début pour ce type d'organisation :

  • tables très dynamiques
  • tables assez dynamiques
  • tables plutôt statiques

Les tables très dynamiques doivent être mappées à des pages de disque disposant d'une grande quantité d'espace disponible (environ 30 %) ; les tables assez dynamiques doivent être mappées à des pages de disque disposant d'une quantité inférieure d'espace disponible (environ 15 %) ; enfin, les tables principalement statiques doivent être mappées à des pages de disque disposant d'une très faible quantité d'espace disponible (environ 5 %). Les index des tables doivent également être mappés.

Emplacement de page de disque

Une fois que les groupes de tables sont mappés, le concepteur de base de données doit déterminer l'emplacement des pages de disque. L'objectif consiste à tenter d'équilibrer la charge de travail entre plusieurs unités différentes et à réduire ou à éliminer les goulets d'étranglement. Prenez en compte les recommandations suivantes :

  • Ne placez jamais de données sur le même disque que le système d'exploitation, ses fichiers temporaires ou les périphériques de permutation. Ces unités sont déjà très sollicitées et n'ont pas besoin de charge de travail supplémentaire.
  • Placez en ordre les données faisant l'objet d'un accès simultané sur différentes unités afin d'équilibrer la charge de travail. Certains systèmes prennent en charge les canaux d'E/S parallèles. Si c'est le cas, placez les données sur des canaux différents.
  • Placez les index sur une unité différente de celle qui contient les données indexées afin de répartir la charge de travail.
  • Pour obtenir les instructions correspondantes, consultez la documentation du fournisseur de la base de données.
  • Le type de stockage utilisé (par exemple RAID-5, RAID-10, SAN, NAS ou canal) affecte les performances de la base de données. Appliquez les recommandations fournies par le fournisseur de l'équipement de stockage en matière de gestion des performances.

Les E/S de base de données constituent généralement le facteur limitant des performances de base de données. L'équilibrage des E/S est un processus itératif et expérimental. Si vous créez un prototype des performances d'accès aux bases de données pendant la phase d'élaboration ainsi que l'instrumentation appropriée pour surveiller les E/S physiques et logiques, vous pouvez détecter rapidement les problèmes de performances, pendant qu'il est encore temps de modifier en conséquence la conception de la base de données.

Allocation d'espace disque

A l'aide des caractéristiques du mécanisme de conception persistant, évaluez le nombre d'objets à stocker. La quantité d'espace disque requis pour le stockage d'objets varie en fonction du SGBDR utilisé. Lorsque vous calculez la quantité d'espace disque, tenez compte de la croissance due aux ajouts de données.  Pour évaluer l'espace disque requis pour une base de données, faites tout d'abord une estimation de l'espace disque requis pour chaque table, puis calculez les exigences d'espace de toutes les tables.  Consultez l'administrateur de base de données du système SGBDR spécifique afin de déterminer la formule d'estimation d'espace précise.  Voici une procédure générale d'estimation des exigences d'une table en matière d'espace :

  • Calculez la taille moyenne des lignes.  Ce calcul doit inclure toutes les informations de contrôle au niveau de l'enregistrement, ainsi que les informations de contrôle requises pour les colonnes à longueur variable.
  • Calculez le nombre de lignes d'une page ou d'un bloc d'E/S.  Etant donné que les bases de données, pour la plupart, stockent uniquement les enregistrements entiers sur une page ou un bloc d'E/S, le nombre de lignes inclus dans une page ou un bloc est un nombre entier.
  • Calculez le nombre de pages ou de blocs d'E/S requis pour le stockage du nombre estimé d'enregistrements de la base de données.  Ce nombre doit inclure les facteurs de charge.
  • Multipliez le nombre de pages ou de blocs d'E/S requis par la taille de la page ou du bloc d'E/S.
  • Ajoutez le temps système requis pour les index supplémentaires.
  • Ajoutez le temps système requis pour la table.

Une fois que les exigences d'espace table ont été définies :

  • Calculez l'espace total requis par les tables.
  • Ajoutez une quantité d'espace fixe pour la gestion de la base de données.
  • Ajoutez l'espace disque requis pour le journal des transactions et pour le journal d'audit. 

Dans les environnements fréquemment mis à jour, les exigences de rétention applicables au journal d'audit nécessitent de grandes quantités de stockage. La documentation des principaux systèmes de gestion de base de données fournit généralement des instructions détaillées de dimensionnement. Reportez-vous à ces instructions lorsque vous calculez les estimations d'exigences d'espace disque pour la base de données.

Concevoir des procédures stockées pour distribuer le comportement de classe à la base de données Haut de la page

Objet Déterminer si des procédures stockées ou des déclencheurs doivent être utilisés pour l'implémentation des opérations de classe d'accès aux données.

Les bases de données, pour la plupart, prennent en charge une capacité de procédures stockées. Une procédure stockée est un code exécutable utilisé dans l'espace de processus du système de gestion de base de données. Elle permet d'exécuter sur le serveur des actions liées à la base de données sans devoir transférer les données via un réseau. Une utilisation judicieuse des procédures stockées peut améliorer les performances du système.

Les procédures stockées sont généralement des procédures réelles ou des déclencheurs. Les procédures sont exécutées explicitement par une application, contiennent généralement des paramètres et renvoient généralement des valeurs explicites. Les déclencheurs, de leur côté, sont appelés de façon implicite lorsqu'un événement de base de données se produit (par exemple l'insertion, la mise à jour ou la suppression d'une ligne), ne disposent pas d'autre paramètre que celui de modification de la ligne et ne renvoient pas de valeur de retour explicite.

Dans les systèmes de base de données qui manquent de contraintes, les déclencheurs sont souvent utilisés pour mettre en place l'intégrité des données et du référentiel. Sinon, ils sont utilisés lorsqu'un événement doit déclencher (ou entraîner) un nouvel événement. Les déclencheurs sont souvent utilisés pour des questions de sécurité car ils permettent d'auditer l'événement déclencheur.

Les classes du modèle de conception doivent être examinées afin de vérifier si elles contiennent des opérations devant être implémentées à l'aide de la procédure stockée ou de la fonction de déclencheur. Ces opérations potentielles incluent :

  • les opérations qui concernent principalement les données persistantes (création, mise à jour, extraction ou suppression de ces données).
  • les opérations au cours desquelles une requête est incluse dans un calcul (comme par exemple le calcul de la quantité moyenne et la valeur d'un produit du stock).
  • les opérations qui doivent accéder à la base de données pour valider certaines données.

Souvenez-vous que l'amélioration des performances de la base de données implique généralement la réduction des E/S. Par conséquent, si l'exécution d'un calcul sur le serveur du système SGBD réduit la quantité de données acheminées via le réseau, ce calcul doit probablement être effectué sur le serveur.

Collaborez avec le concepteur de la classe de conception pour déterminer la façon dont la base de données peut être utilisée afin d'améliorer les performances. Le concepteur met à jour cette méthode pour indiquer si une ou plusieurs procédures stockées peuvent être utilisées pour l'implémentation de l'opération.

Revoir les résultats Haut de la page

Objet Garantir la qualité et l'intégrité du modèle de données.

Pendant toute la durée de cette activité, vous devez prendre en compte les points de contrôle du modèle de données pour évaluer l'achèvement et la qualité de l'effort.  Par ailleurs, le concepteur de base de données doit régulièrement revoir la structure de base de données implémentée pour s'assurer que le modèle de données est cohérent avec les modifications apportées directement dans la base de données.  Si le projet utilise des outils de modélisation de données prenant 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 de données doit vérifier périodiquement l'état du modèle de données et apporter les modifications requises. 

Les anomalies détectées qui ne seront pas corrigées à ce stade doivent être documentées dans les demandes de modification et éventuellement affectées à une personne chargée de la résolution.




Ce contenu est développé ou partiellement développé par Applied Information Sciences.

RUP (Rational Unified Process)   2003.06.15