Quelles sont les étapes de la conception d'une base de données ?

La conception de la base de données est l'un des facteurs les plus importants contribuant aux performances d'une application. Par conséquent, la qualité de la conception de la base de données est de la plus haute importance. La conception de la base de données consiste à organiser efficacement les données en fonction des flux de travail des produits, de la future feuille de route et des modèles d'utilisation attendus.

Le résultat d'un exercice de conception de base de données est un modèle de données. Un modèle de données représente tous les objets, entités, attributs, relations et contraintes du système. D'une manière générale, les modèles de données peuvent être de deux types :logiques ou physique . La représentation du modèle de données se fait en créant un diagramme ER, également appelé diagramme de relation d'entité, diagramme ERD ou diagramme de base de données.

Le modèle de données physique se rapporte aux détails de mise en œuvre réels dans la base de données. Le modèle de données logique, d'autre part, fait abstraction des aspects techniques de la mise en œuvre. Cela rend le modèle de données logique consommable pour l'entreprise. L'une des principales différences entre les deux modèles est que le modèle logique est indépendant de la base de données, tandis que le modèle physique doit être spécifique à la base de données utilisée.

Une conception de base de données appropriée est souvent sous-estimée et négligée lors du développement d'applications. Le coût de cette négligence est généralement réalisé beaucoup plus tard lorsque de nouvelles fonctionnalités d'application arrivent ou lorsque d'anciennes fonctionnalités doivent être modifiées. C'est à ce moment que la conception de la base de données cesse d'avoir un sens. Bien qu'il ne soit pas possible de pérenniser la conception d'une base de données, il est tout à fait possible de faire l'effort de mieux comprendre les cas d'utilisation métier et de concevoir la base de données en conséquence. En savoir plus sur les conseils pour une meilleure conception de base de données ici.

Dans cet esprit, passons en revue les étapes de conception de la base de données.

Étape 1 :Recueillir les besoins de l'entreprise

La première étape consiste à discuter avec l'entreprise de ses besoins. Si la conversation est efficace, elle devrait aboutir à suffisamment d'informations pour commencer à travailler sur un modèle de données conceptuel, qui est une abstraction du modèle logique. Parler à l'entreprise, tout d'abord, fournit une image complète des processus métier, qui, à son tour, fournit des informations sur les différents points de données qu'il est important pour l'entreprise de capturer et de suivre. Par exemple, dans un modèle de réservation de taxi, il convient de se poser les questions suivantes :

L'entreprise souhaite-t-elle que les données de suivi des véhicules figurent dans la base de données, qu'il y ait ou non un trajet actif ? Si oui, alors le champ vehicle_trip_id dans le tableau vehicle_trips serait nullable . Sinon, il ne sera pas nullable .
L'entreprise souhaite-t-elle connaître l'historique des modifications apportées à trip_status ? stocké dans la base de données ? Si oui, alors à chaque fois le trip_status changements, il y aura un autre enregistrement dans les trips table. Sinon, chaque fois que le trip_status changements, trip_status sera mis à jour sur place.

Comme le montre cet exemple, en fonction des intrants de l'entreprise, vous finirez par choisir une option plutôt qu'une autre. Cela conduirait à changer les entités concernées et leurs relations.

La collecte des exigences implique également généralement d'engager une conversation sur la sécurité des données, comme les données à masquer et à chiffrer. L'exercice de collecte des exigences aboutit à un document d'exigences souvent soutenu par une ébauche de travail du modèle de données conceptuel.

Étape 2 :Comprendre la feuille de route commerciale

Les entreprises changent leurs processus tout le temps; leur capacité d'adaptation les rend moins susceptibles d'échouer. Changer les processus métier signifie changer les workflows et les modèles de données. Bien qu'il ne soit pas possible de connaître ces changements longtemps à l'avance, il est certainement possible d'être à jour avec la feuille de route de l'entreprise.

Par exemple, si une entreprise envisage de cibler une nouvelle région géographique, le modèle devra prendre en charge la prise en charge linguistique, les devises, les fuseaux horaires, etc. Les avantages de la compréhension de la feuille de route commerciale à long terme se manifestent souvent par une transition plus fluide vers de nouveaux processus commerciaux.

Permettez-moi de partager un autre exemple, qui concerne davantage les priorités commerciales en constante évolution. Le secteur des taxis a été durement touché au début de la COVID-19. En tant que compagnie de taxi, vous voulez agir de manière préventive pour assurer aux gens que vous faites tout pour que votre voyage en taxi soit le plus sûr possible, que le véhicule soit désinfecté tous les jours, que le chauffeur porte un masque du tout fois, et qu'il y a du désinfectant pour les mains disponible dans la cabine. Maintenant, pour capturer toutes ces informations, changez pour deux entités, drivers et vehicles , serait nécessaire. Plusieurs champs d'indicateur booléen doivent être ajoutés à ces entités pour répondre à ce cas d'utilisation métier.

Étape 3 :Identifiez les entités et les attributs

Une fois les exigences commerciales recueillies, les informations peuvent être utilisées pour identifier les entités ainsi que l'ensemble essentiel d'attributs. Une ou plusieurs entités correspondent généralement directement aux processus métier, et la relation entre ces entités imite également le flux de travail des processus métier.

Cette étape est également utilisée pour identifier les attributs qui serviront d'identifiants dans les entités. Les identificateurs se traduisent en clés primaires dans le modèle physique. En outre, il est également courant de spécifier des types de données pour tous les attributs de cette étape.

Par exemple, dans le modèle de réservation de taxi, vous devrez identifier les attributs qui serviront de champs obligatoires pour l'enregistrement des utilisateurs et des chauffeurs à partir de l'application de réservation. L'enregistrement de l'utilisateur se ferait à l'aide de user_phone et l'enregistrement du conducteur se ferait à l'aide de driver_phone .

De même, d'autres entités et attributs sont identifiés au cours de cette étape, après avoir été mappés aux workflows des processus métier.

Étape 4 :Identifiez les relations

Après avoir identifié les entités et leurs attributs, l'étape suivante consiste à définir les relations entre les entités en fonction des flux de travail métier qui ont été documentés lors de la phase de collecte des exigences. En plus d'établir qu'il existe une relation entre deux entités, il est également important d'identifier lequel des quatre types de relation suivants existe entre elles. Considérons deux entités arbitraires, A et B :

Un-à-un → Un enregistrement dans A correspond à au plus un enregistrement dans B.
Un-à-plusieurs → Un enregistrement dans A correspond à plusieurs enregistrements dans B.
Many-to-one → Plusieurs enregistrements dans A correspondent à au plus un enregistrement dans B.
Many-to-many → De nombreux enregistrements dans A correspondent à de nombreux enregistrements dans B.

Dans le modèle de réservation de taxi, un seul type de relation a été utilisé, c'est-à-dire un à plusieurs. Prenez la relation entre users et trips par exemple. Dans le modèle, on suppose qu'un seul utilisateur peut être lié à un trajet, ce qui implique qu'il n'y a pas de taxis partagés ou groupés. Mais s'il y avait des taxis partagés ou regroupés, il y aurait peut-être eu une relation plusieurs à plusieurs entre les users et trips , si plusieurs utilisateurs partagent le même trip_id .

Étape 5 :Créer un diagramme ER logique

Une fois les entités, les attributs et les relations d'entité définis, l'étape suivante immédiate consiste à dessiner le diagramme ER. Toutes les étapes énumérées ci-dessus peuvent être effectuées dans Vertabelo. Il n'y a pas de règles absolues sur la manière dont la modélisation logique est censée être effectuée, à l'exception peut-être de la notation de référence.

Par exemple, jetez un oeil à l'exemple suivant d'un diagramme ER logique. Il capture un flux de travail commercial simple d'une entreprise de taxi, où un utilisateur peut réserver un trajet avec la possibilité de suivre le véhicule.

Étape 6 :Valider le diagramme ER logique

La modélisation logique est un processus dans lequel de nombreuses informations commerciales doivent être traduites en une conception de base de données. Sans vérifications approfondies, cette phase de développement de la base de données est sujette à des erreurs qui peuvent s'avérer assez coûteuses par la suite.

Pour s'en occuper, Vertabelo dispose d'une liste complète de vérifications pouvant être effectuées sur un modèle logique. Les vérifications peuvent être effectuées à toutes les granularités, du modèle dans son ensemble aux attributs individuels, et tout le reste. Certaines des vérifications simples sont :

Les noms d'entités, d'attributs, de relations, etc. ne peuvent pas être nuls et doivent être uniques.
Une entité doit avoir au moins 1 attribut.
Des identifiants (PK) doivent être définis pour chaque entité.
Le modèle doit utiliser l'un des types de données répertoriés pour les attributs.

Toutes ces vérifications sont facultatives et peuvent être configurées pour être ignorées, si un autre cadre de validation est en place. Une validation appropriée de Vertabelo vous aide à passer à l'étape suivante avec le minimum de friction possible.

Étape 7 :Créer un diagramme ER physique

Une fois le diagramme ER logique créé, l'étape suivante consiste à créer un modèle de données physique. Le modèle de données physique sera spécifique à la base de données dans laquelle vous souhaitez déployer le modèle de données. Toutes les bases de données ont leur propre implémentation des règles de nomenclature, des types de données et des contraintes. Pour cette raison, le langage de définition de données (DDL) diffère souvent d'une base de données à l'autre.

Pour créer un modèle de données physique, procédez comme suit :

Rechercher le type de données le plus proche dans la base de données cible pour remplacer le type de données générique sélectionné dans le modèle de données logique.
Suivez les règles de nomenclature pour les tables, les colonnes et les contraintes prescrites par la base de données cible.
Modifier le modèle pour l'aligner sur les workflows de requête prédéfinis. Cela entraîne généralement une augmentation de la redondance pour sauvegarder les jointures.
Enfin, vous pouvez créer des index, des partitions, des clés de distribution et des clés de tri. C'est à ce moment que vous pouvez créer des modifications améliorant les performances du modèle.

Ces étapes peuvent être effectuées à l'aide de n'importe quel outil de modélisation de données que vous pouvez utiliser pour créer un modèle de données à partir de zéro. Cependant, Vertabelo a la possibilité de convertir un modèle de données logique en un modèle de données physique à part entière pour tous les principaux systèmes de base de données tels que MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery, etc. Une fois le modèle de données logique converti en modèle de données physique, vous pouvez continuer avec les quatre étapes dont nous avons parlé.

Vertabelo a également la possibilité d'ajouter des scripts de pré- et post-déploiement au niveau de la table ainsi que des commentaires au niveau très granulaire du modèle. Les commentaires s'avèrent utiles lorsque la fonctionnalité de génération de documentation offerte par Vertabelo est utilisée. Le document de la base de données peut être exporté dans l'un des trois formats suivants :HTML, PDF ou DOCX.

Poursuivant avec l'exemple de réservation de taxi, examinons le modèle de données physique généré par Vertabelo.

Étape 8 :Valider le diagramme ER physique

Tout comme le diagramme ER logique a été validé, Vertabelo dispose d'un outil pour valider les diagrammes ER physiques avec plusieurs vérifications supplémentaires, comme l'existence ou non de FK et si la longueur d'un nom de table ou d'un nom de colonne dépasse la limite en fonction de la base de données sélectionnée.

La validation n'a pas besoin d'être exécutée explicitement. Cela se produit au fur et à mesure que le diagramme est modifié. Les problèmes liés au modèle appartiennent à l'une des trois catégories suivantes :erreurs, avertissements et conseils, par ordre décroissant de gravité. Il existe un article utile et bien écrit qui parle des erreurs courantes commises lors du processus de conception de la base de données.

Étape 9 :Résoudre les problèmes liés au diagramme ER physique

Les résultats de la validation peuvent identifier des problèmes qui doivent être corrigés. Voici quelques-uns des problèmes les plus courants :

Clés étrangères manquantes là où les relations d'entité ont été définies.
Clés primaires manquantes dans les tables.
Types de données non pris en charge pour la base de données sélectionnée.

Une fois ces problèmes et d'autres similaires résolus, le modèle est prêt à être exporté vers un script SQL déployable pour le système de gestion de base de données sélectionné.

Étape 10 :Générer les scripts DDL pour déployer le modèle

La conception de bases de données ne consiste pas seulement à créer des diagrammes ER. Un exercice de modélisation de données à l'aide de diagrammes ER ne réussit que s'il aboutit à quelque chose de déployable. Vertabelo dispose d'une option pratique pour exporter le modèle physique vers un script SQL prêt à être déployé. Une fois généré, tous les problèmes en attente peuvent être résolus directement dans le script SQL.

Cependant, la modification du script SQL généré n'est pas recommandée. Cela provoque une dérive entre le modèle de données physique et le script SQL déployé sur la base de données, ce qui peut également signifier une dérive entre les tables réelles et la documentation de la base de données.

Maintenant que nous avons atteint la fin du processus de conception de la base de données, examinons le code SQL généré par Vertabelo.

Partagez vos pensées

La conception de bases de données est une activité à fort impact dans le développement de logiciels. Le domaine de la conception de bases de données a évolué au fil des ans avec de nouvelles façons de représenter la conception pour l'entreprise, pour les ingénieurs et pour les analystes de données. Cela a souvent donné lieu à de nouveaux types de diagrammes, de normes de modélisation et de notations. Une grande partie de l'évolution a été couverte dans la section sur les principes fondamentaux de la conception.

Nous serons heureux de voir quelles ont été vos expériences dans la conception de bases de données. Écrivez-nous à [email protected].