Pour qu'une application ait de bonnes performances, vous avez besoin d'un serveur d'applications puissant, d'une bande passante garantie et ample, et d'un travail de programmation bien fait. Mais il y a un aspect qui n'est pas toujours pris en compte et qui a généralement un impact important sur les performances de toute application : le conception de base de données.
Nous allons maintenant examiner les meilleures pratiques de conception de bases de données pour nous assurer que l'accès aux données n'est pas un goulot d'étranglement qui affecte négativement les performances des applications.
A quoi sert une bonne conception de base de données ?
En plus d'améliorer les performances d'accès aux données, une bonne conception offre d'autres avantages, tels que le maintien de la cohérence, de la précision et de la fiabilité des données et la réduction de l'espace de stockage en éliminant les redondances. Un autre avantage d'une bonne conception est que la base de données est plus facile à utiliser et à entretenir. Quiconque doit le gérer n'aura qu'à regarder le diagramme entité-relation (ERD) pour comprendre sa structure.
Les ERD sont l'outil fondamental de la conception de bases de données. Ils peuvent être créés et visualisés à trois niveaux de conception : conceptuel, logique et Physique.
La conception conceptuelle montre un schéma très résumé, avec seulement les éléments nécessaires pour s'entendre sur les critères avec les parties prenantes du projet, qui n'ont pas besoin de comprendre les détails techniques de la base de données. La conception logique montre les entités et leurs relations en détail mais d'une manière indépendante de la base de données.
Il existe de nombreux outils que vous pouvez utiliser pour faciliter la conception de bases de données à partir de DRE. Parmi les meilleurs figurent DbSchema, SQLDBM et Vertabelo.
DbSchema
DbSchema vous permet de concevoir et de gérer visuellement SQL, NoSQL, ou des bases de données Cloud. L'outil vous permet de concevoir le schéma sur un ordinateur et de le déployer sur plusieurs bases de données et de générer de la documentation dans des diagrammes HTML5, d'écrire des requêtes et d'explorer visuellement les données, entre autres. Il offre également la synchronisation de schéma, la génération de données aléatoires et l'édition de code SQL avec auto-complétion.
SqlDBM
SQLDBM est l'un des meilleurs outils de conception de diagramme de base de données, car il permet de concevoir facilement votre base de données dans n'importe quel navigateur. Aucun autre moteur de base de données ou outil de modélisation n'est requis pour l'utiliser, bien que SqlDBM vous permette d'importer un schéma à partir d'une base de données existante. Il est idéal pour travail d'équipe, car il vous permet de partager des projets de conception avec des collègues.
Vertabelo
Vertabelo est un outil de conception de base de données visuel en ligne qui vous permet de concevoir une base de données de manière logique et de dériver automatiquement le schéma physique. Il peut effectuer une rétro-ingénierie, générer des diagrammes à partir de bases de données existantes et contrôler l'accès aux diagrammes en différenciant les privilèges d'accès entre les propriétaires, les éditeurs et les utilisateurs.
Enfin, la conception physique est celle qui ajoute à l'ERD tous les détails nécessaires pour en faire une base de données utilisable dans un SGBD particulier, tel que MySQL, MariaDB, MS SQL Server ou tout autre. Jetons un coup d'œil aux meilleures pratiques à garder à l'esprit lors de la conception d'un ERD afin que la base de données résultante fonctionne au mieux.
Define the type of database to design
On distingue généralement deux types fondamentaux de bases de données : relationnel et dimensions.
Les bases de données relationnelles sont utilisées pour les applications traditionnelles qui exécutent des transactions sur les données, c'est-à-dire qu'elles obtiennent des informations de la base de données, les traitent et stockent les résultats.
D'autre part, les bases de données dimensionnelles sont utilisées pour la création d'entrepôts de données : de grands référentiels d'informations pour l'analyse de données et l'exploration de données pour obtenir des informations.
La première étape de toute tâche de conception de base de données consiste à choisir l'un des deux principaux types de base de données avec laquelle travailler : relationnelle ou dimensionnelle. Il est essentiel que cela soit clair avant de commencer à concevoir. Sinon, vous pouvez facilement tomber dans des erreurs de conception qui finiront par entraîner de nombreux problèmes et seront difficiles (ou impossibles) à corriger.
Adopting a Naming Convention
Les noms utilisés dans la conception de la base de données sont essentiels car, une fois qu'un objet est créé dans une base de données, changer son nom peut être fatal. Changer une seule lettre du nom peut rompre les dépendances, les relations et même des systèmes entiers.
C'est pourquoi il est essentiel de travailler avec une convention de nommage saine : un ensemble de règles qui vous évite d'avoir à essayer 50 possibilités différentes pour trouver le nom d'un objet dont vous ne vous souvenez pas.
Il n'y a pas de guide universel sur ce que devrait être une convention de nommage pour faire son travail. Mais l'important est d'établir une convention de nommage avant de nommer l'un des objets d'une base de données et de maintenir cette convention pour toujours. Une convention de nommage établit des directives telles que l'utilisation d'un trait de soulignement pour séparer les mots ou pour les joindre directement, s'il faut utiliser toutes les majuscules ou les mots en majuscule (style Camel Case), s'il faut utiliser des mots au pluriel ou au singulier pour nommer des objets, etc.
Commencez par la conception conceptuelle, puis la conception logique et enfin la conception physique.
C'est l'ordre naturel des choses. En tant que concepteur, vous pouvez être tenté de commencer par créer des objets directement sur le SGBD pour sauter des étapes. Mais cela vous évitera d'avoir un outil pour discuter avec les parties prenantes pour s'assurer que la conception répond aux exigences de l'entreprise.
Après la conception conceptuelle, vous devez passer à la conception logique pour avoir une documentation adéquate pour aider les programmeurs à comprendre la structure de la base de données. Il est vital de maintenir la conception logique à jour pour qu'elle soit indépendante du moteur de base de données à utiliser. De cette façon, si vous migrez finalement la base de données vers un moteur différent, la conception logique sera toujours utile.
Enfin, la conception physique peut être créée par les programmeurs eux-mêmes ou par un DBA, en prenant la conception logique et en ajoutant tous les détails d'implémentation nécessaires pour l'implémenter sur un SGBD particulier.
Create and maintain a data dictionary
Même si un ERD est clair et descriptif, vous devez ajouter un dictionnaire de données pour le rendre encore plus clair. Le dictionnaire de données maintient la cohérence et la cohérence dans la conception de la base de données, en particulier lorsque le nombre d'objets qu'il contient augmente de manière significative.
L'objectif principal du dictionnaire de données est de maintenir un référentiel unique d'informations de référence sur les entités d'un modèle de données et ses attributs. Le dictionnaire de données doit contenir les noms de toutes les entités, les noms de tous les attributs, leurs formats et types de données, et une brève description de chacun.
Le dictionnaire de données fournit un guide clair et concis de tous les éléments qui composent la base de données. Cela évite de créer plusieurs objets qui représentent la même chose, ce qui rend difficile de savoir à quel objet recourir lorsque vous devez interroger ou mettre à jour des informations.
Maintain consistent criteria for primary keys
La décision d'utiliser des clés naturelles ou des clés de substitution doit être cohérente au sein d'un modèle de données. Si les 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, il n'est pas nécessaire de créer des clés de substitution.
Mais il est courant que les entités soient identifiées par plusieurs attributs de types différents – dates, nombres et/ou longues chaînes de caractères – qui peuvent être inefficaces pour former des clés primaires. Dans ces cas, 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. Et la clé de substitution est la seule option si une entité manque d'attributs qui l'identifient de manière unique.
Use the correct data types for each attribute.
Certaines données nous donnent la possibilité de choisir le type de données à utiliser pour les représenter. Les dates, par exemple. Nous pouvons choisir de les stocker 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. 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.
Dans le cas des dates, il est pratique d'utiliser le type de données du moteur, ce qui facilite la manipulation des données. Si vous devez stocker uniquement la date d'un événement sans spécifier l'heure, le type de données à choisir sera simplement Date ; si vous devez stocker la date et l'heure auxquelles un certain événement s'est produit, le type de données doit être DateTime.
L'utilisation d'autres types, tels que varchar ou numeric, 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.
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. Sinon, vous vous exposez au risque que certaines données dépassent les limites des champs numériques et vous obligent à refactoriser un design alors qu'il est déjà en production.
Use of lookup tables
Certains concepteurs inexpérimentés peuvent penser que l'utilisation excessive de tables de recherche pour normaliser une conception peut compliquer inutilement l'ERD d'une base de données car elle ajoute un grand nombre de tables « satellites » qui ne contiennent parfois qu'une poignée d'éléments. Ceux qui pensent cela doivent comprendre que l'utilisation de tables de recherche a beaucoup plus d'avantages que d'inconvénients. Si la complexité ou la taille d'un ERD pose problème, il existe des outils de conception ERD qui permettent de visualiser les diagrammes de différentes manières pour être compris malgré leur complexité.
Cet exemple de requête illustre l'utilisation correcte des tables de recherche dans une base de données bien conçue :
SELECT
StreetName,
StreetNumber,
Cities.Name AS City,
States.Name AS State
FROM
Addresses
INNER JOIN Cities ON
Cities.CityId = Addresses.CityId
INNER JOIN States ON
States.StateId = Addresses.StateIdDans ce cas, nous utilisons des tables de recherche pour les villes et les États.
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.
Normalize or denormalize according to database type
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. Il améliore la qualité des informations et fournit de multiples outils pour optimiser les performances dans les requêtes complexes.
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.
Designing physical models in parts
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.
Making good use of views and indexes
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.
Lorsque vous pensez que le travail est terminé, il est temps de refactoriser.
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 qui dépassent le cadre de cet article, mais il est bon de connaître leur existence pour les utiliser en cas de besoin.
Avoir cette liste de bonnes pratiques à portée de main chaque fois que vous devez concevoir une base de données vous permettra d'obtenir les meilleurs résultats afin que les applications maintiennent toujours des performances optimales dans l'accès aux données.
