La performance d’une application est liée à de nombreux facteurs en relation avec le système, le réseau mais aussi la bonne conception de la base de données.

La bonne conception d’une base de données permet une cohérence des données et un meilleur un accès fluide à celle-ci évitant les goulots d’étranglement par exemple. Elle permet également une facilité d’utilisation et d’entretien. Il suffit alors de regarder le diagramme entité-relation (ERD) pour comprendre sa structure.

Fig. 1 : Exemple de MDC (model conceptuel de données)

De nombreux outils sont utilisés pour faciliter la conception de bases de données à partir de DRE. Parmi les meilleurs figurent DbSchema, SQLDBM et Vertabelo.

              Avant de passer au travail de conception, il est des étapes à observer afin d’aboutir à une base performante facile d’utilisation et d’entretien. Nous nous intéresserons à la conception des bases de données relationnelles.

Etablir une règle de nommage

              Il s’agit d’établir une règle de nommage saine des objets de la base car une fois qu’un objet est créé, il est impossible d’en modifier le nom sans provoquer la rupture des relations entre objets voir du système tout entier. Il n’existe pas de guide universel pour les règles de nommage. Il est toutefois préconisé que les noms donnés aux différents objets soient parlants et dans une certaine homogénéité (majuscule/minuscules, …). Il est également déconseillé d’employer les caractères accentués ou spéciaux, des espaces (é, è, ê, ï, ç, %, $ … ). En ce sens, l’alphabet anglais se prête bien à la construction des noms des objets.

              Il faut également éviter l’utilisation des mots réservés come « Date » et préférer l’inderscore plutôt que de coller é mots : (écrire date_production plutôt que DateProduction). On peut aussi préfixer les noms des tables ou des colonnes pour éviter une utilisation accidentelle d’un mot réservé (product_, user_)

Toujours commencer par la conception conceptuelle puis logique puis physique

              Il ne faut jamais commencer directement par la conception directe de la base de données sur le SGBD. Dans le cas contraire, on saute l’étape où il faut discuter avec les parties prenantes ce qui induit un manque d’information et la construction d’une base incomplète ne répondant pas aux exigences d’une entreprise.

Créer et maintenir un dictionnaire de données

              Le dictionnaire de données rassemble l’ensemble des informations nécessaires pour créer une base de données : le nom des entités, des attributs, leurs formats et types de données, et une brève description de chacun. Il résulte d’un échange avec l’ensemble des parties prenantes et de l’exploitation des documents relatifs aux données de la base qu’on est appelés à créer.

Maintenir des critères cohérents pour les clés primaires

Une clé primaire est un identifiant unique et non NULL qui distingue une entité. Certaines entités d’un modèle de données ont des identifiants uniques qui peuvent être gérés efficacement en tant que clés primaires de leurs tables respectives (Matricule du salarié dans une table d’employé). Il n’est donc pas nécessaire de créer des clés de substitution.

Dans le cas contraire, où l’entité est par exemple identifiée par plusieurs attributs de types différents – dates, nombres et/ou longues chaînes de caractères qui ne peuvent pas être unique et donc inefficaces pour former des clés primaires, il est préférable de créer des clés de substitution de type numérique entier, qui offrent une efficacité maximale dans la gestion des index. Ce dernier cas est le plus souvent utilisé.

Une clé primaire peut également être composée de la concaténation de clés primaire de 3 tables par exemple (relation ternaire).

Fig. 2 : Exemple de relation ternaire

Utiliser les types de données corrects pour chaque attribut

              Il s’agit principalement de la gestion des dates et des données numériques impliquées ou non dans un calcul mathématique. 

Nous pouvons choisir de stocker les dates dans des champs de type date, des champs de type date/heure, des champs de type varchar, ou encore des champs de type numérique. Il est toutefois pratique d’utiliser le type de données du moteur, ce qui facilite la manipulation des données. Si l’on doit stocker uniquement la date d’un événement sans spécifier l’heure, le type de données Date est approprié. Dans le cas où l’on veut stocker la date et l’heure d’un événement c’est le type DateTime qu’il faut choisir.

L’utilisation d’autres types, tels que varchar ou numérique, pour stocker les dates peut être pratique, mais uniquement dans des cas très particuliers. Par exemple, si l’on ne sait pas à l’avance dans quel format une date sera exprimée, il est pratique de la stocker sous forme de varchar. Si les performances de recherche, le tri ou l’indexation sont essentiels dans la gestion des champs de type date, une conversion précédente en flottant peut faire la différence. Mais il vaut mieux déterminer ou définir le format de la date.

Un autre cas est celui des données numériques qui ne sont pas utilisées pour des opérations mathématiques mais pour identifier une entité, comme un numéro de permis de conduire ou un code postal.

Les données numériques non impliquées dans les opérations mathématiques doivent être représentées sous forme de varchar, en appliquant des validations de format dans l’enregistrement pour éviter les incohérences ou les répétitions. Dans le cas contraire, il y a un risque que certaines données dépassent les limites des champs numériques ce qui oblige à refactoriser un design alors qu’il est déjà en production.

Utilisation des tables de recherche

Les avantages des tables de recherche incluent la réduction de la taille de la base de données, amélioration des performances de recherche, et imposer des restrictions sur l’ensemble de données valides qu’un champ peut contenir, entre autres. Il est également recommandé que toutes les tables de recherche incluent un champ Bit ou Booléen qui indique si un enregistrement de la table est en cours d’utilisation ou est obsolète. Ce champ peut être utilisé comme filtre pour éviter les éléments obsolètes en tant qu’options dans l’interface utilisateur de l’application.

Normaliser ou dénormaliser selon le type de base de données

Dans les bases de données relationnelles utilisées pour les applications traditionnelles, la normalisation est un must. Il est bien connu que la normalisation réduit l’espace de stockage requis en évitant les redondances. Elle améliore la qualité des informations et fournit de multiples outils pour optimiser les performances dans les requêtes complexes. En voici quelques exemples :

  • Chaque cellule doit avoir une seule valeur et non une liste de valeur
  • Chaque attribut doit dépendre directement de la clé primaire
  • Chaque colonne non clé soit indépendante de toutes les autres colonnes : si chaque valeur peut servir à un calcul, aucune valeur ne doit être le résultat d’un calcul (exemple : Montant TVA est un résultat qui dépend de la colonne prix)

Cependant, dans d’autres types de bases de données, une technique connue sous le nom de dénormalisation est appliquée. Dans les bases de données dimensionnelles, utilisées comme entrepôts de données, la dénormalisation ajoute certaines informations redondantes utiles dans les tables de schéma.

Bien qu’ils semblent être des concepts opposés, la dénormalisation ne signifie pas défaire la normalisation. Il s’agit en fait d’une technique d’optimisation appliquée à un modèle de données après l’avoir normalisé pour simplifier l’écriture de requêtes et le reporting.

Conception de modèles physiques en pièces

Dans un projet de développement logiciel, le concepteur de base de données présente un modèle conceptuel à grande échelle aux parties prenantes, dans lequel aucun détail de mise en œuvre n’est affiché. À son tour, pour travailler avec les développeurs, le concepteur doit fournir un modèle physique avec tous les détails de chaque entité et attribut. Cependant, les deux modèles n’ont pas besoin d’être complètement créés au début du projet.

Lors de l’application Méthodologies Agiles, chaque développeur au début de chaque cycle de développement utilise une ou plusieurs user stories au cours de ce cycle. Le travail du concepteur de base de données est de fournir à chaque développeur un sous-modèle physique qui inclut uniquement les objets dont ils ont besoin pour une unité de travail.

À la fin de chaque cycle de développement, les sous-modèles créés au cours de ce cycle sont fusionnés afin que le modèle physique complet prenne forme parallèlement au développement de l’application.

Faire bon usage des vues et des index

Les vues et les index sont deux outils fondamentaux dans la conception de bases de données pour améliorer les performances des applications. L’utilisation de vues permet de gérer des abstractions qui simplifient les requêtes, en masquant les détails de table inutiles. À leur tour, les vues facilitent les tâches d’optimisation des requêtes pour les moteurs de base de données, car elles leur permettent d’anticiper la manière dont les données seront obtenues et de choisir les meilleures stratégies pour fournir des résultats de requête plus rapidement.

Les index peuvent améliorer la performance d’une requête lente basée sur l’expérience utilisateur une fois la base de données en production. Cependant, la création d’index peut être effectuée dans le cadre des tâches de conception de la base de données, en anticipant les besoins de l’application.

Pour la création d’index, vous devez avoir une idée approximative de l’ampleur de chaque table – en termes de nombre d’enregistrements – puis créer des index pour les plus grandes tables. Pour choisir les champs à inclure dans un index, il faut considérer principalement ceux représentant les clés étrangères et ceux qui serviront de filtres dans les recherches.

La refactorisation 

La conception d’une base de données peut toujours être améliorée. Lorsqu’aucune modification n’est apportée à la base de données en raison de nouvelles exigences ou de nouveaux besoins commerciaux, c’est une bonne occasion d’effectuer des procédures de refactorisation qui améliorent la conception. Le refactoring signifie simplement cela : introduire des changements qui améliorent une conception sans affecter la sémantique de la base de données.

Il existe de nombreuses techniques de refactorisation pour améliorer la conception d’une base de données. Notamment un outil, LIQUIBASE permettant d’ajouter une table par exemple, renommer une colonne etc.

Article réalisé par Smail G. – DBA – Noury Solutions

Tags
Commentaires récents