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 :
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.
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.
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.
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.
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.
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.
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.
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.
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.
|