Comment pouvez-vous faire de meilleurs choix pour vous assurer que la conception de votre schéma de base de données aide les utilisateurs, les scientifiques et les analystes de données à trouver ce dont ils ont besoin et à bien l’utiliser ? Suivez ces 10 bonnes pratiques :
Comment concevoir un diagramme entité-relations efficace ?
Un bon diagramme entité-relation est une partie importante du schéma d’une base de données relationnelle. Il s’agit d’une représentation visuelle du modèle de données sous-jacent contenu pour être envoyé de votre source à votre data warehouse. Cela comprend les tables, la structure des dossiers, les équipes commerciales, les étiquettes de données, etc. La provenance d’un modèle de données peut être compliquée, et ce diagramme peut aider en illustrant la multitude potentielle de tables et d’inter-relations qui supportent un modèle de données particulier. Enfin, votre diagramme devrait également être un document vivant et refléter l’état actuel de vos bases de données au fur et à mesure de leur évolution.
Quelle flexibilité pour vos schémas ?
Si votre schéma de données est suffisamment souple pour évoluer en fonction de vos besoins, vous pourrez être en mesure d’effectuer ces mises à jour en comprenant les conséquences de l’évolution de votre infrastructure de données. Pour cela, pensez donc à mettre à jour vos diagrammes de relations. N’oubliez pas, vos données sont un organisme vivant.
Quelle est la finalité de vos données ?
Il est crucial d’avoir une idée précise de la finalité de vos données, en sachant à quoi elles serviront et quelles décisions commerciales elles permettront de prendre afin de concevoir les structures de données appropriées, d’anticiper le volume des requêtes de données, de choisir le meilleur moteur de base de données possible et d’autres questions d’environnement et de gestion. Un bon schéma répond à plusieurs objectifs, notamment réduire les données redondantes, assurer la cohérence des données, garantir leur intégrité, etc.
Quelles sont vos objectifs ?
Un bon moyen de déterminer l’objectif est de créer des exemples de rapports dont vos parties prenantes auront besoin. Si vous commencez par avoir le produit final en tête, vous aurez une meilleure idée de la forme de vos besoins en données. Cela s’applique également aux tableaux de bord de données. Il est nécessaire que les tableaux de bord fournissent des informations exploitables que les responsables pourront utiliser dans leur travail quotidien.
Pourquoi les planifier ?
Plus vous consacrerez d’efforts à la planification en amont et comprendrez à l’avance qui sont les consommateurs de vos données et le public cible de vos rapports qui seront générés à partir de ces données, plus il vous sera facile de produire une base de données efficace.
Bien qu’il soit formidable de pouvoir créer des requêtes et des rapports, vos utilisateurs bénéficieront toujours de la création de quelques échantillons dans le cadre de cet effort de planification pour guider vos plans.
Qui conçoit votre schéma ?
Il est important que vos différentes couches d’abstraction de données, votre interface d’application et vos flux de données soient utiles aux utilisateurs de données et aux analystes qui produiront des rapports et autres produits orientés données. En général, les ingénieurs n’abordent pas les problèmes de la même manière que les analystes de données. Il est donc important que ces deux catégories fassent partie de votre équipe de conception de schémas.
Quelle quantité d’index choisir ?
Par la suite, si votre schéma est correctement conçu, vous disposerez de la bonne quantité d’indexation pour les différents types de requêtes utilisées par vos analystes. Si vous avez trop d’index ou trop peu, aucune de ces deux situations n’est optimale. Trouver le bon équilibre demande de l’expérimentation.
Quelle dénomination utiliser ?
Pour un bon schéma de bases de données, étiqueter vos champs, tables et autres éléments de données avec des noms significatifs est fondamental afin que tous ceux qui manipulent les données puissent comprendre ce que ces éléments signifient au premier coup d’œil. Vous aurez besoin de noms cohérents dans l’ensemble de votre base de données. Pour cela, il faut éviter l’utilisation d’étiquettes réservées au système pour les champs de colonnes ou les noms de tables. On évite également les tirets ou autres signes de ponctuation qui ne feront qu’embrouiller les choses ou nécessiteront une programmation spéciale pour éviter les erreurs et on veille à ce que les noms soient courts et sans modificateurs nécessaires.
Quelle stratégie adopter en amont ?
Le concept de « Security by design » existe depuis des décennies. Une partie de cette conception consiste à ne pas donner de droits d’administration à chaque utilisateur et à chaque développeur, mais plutôt à s’assurer que chaque utilisateur dispose du niveau d’accès approprié à ses besoins. Un tout autre sujet consiste à s’assurer que vos données sensibles et confidentielles soient protégées par le bon niveau de cryptage et qu’elles ne peuvent pas être exportées par des pirates malveillants.
Comment pérenniser ce schéma ?
Votre schéma étant un organisme vivant, vous voulez vous assurer qu’il aura une vie heureuse et utile longtemps après que ses créateurs auront changé de travail ou d’employeur. Le meilleur moyen d’y parvenir est de produire un document soigné et complet qui explique vos choix, comporte de nombreux commentaires dans le code et d’autres informations. Avez-vous expliqué la relation entre les différents champs de chaque table, ou la relation entre vos différentes tables ?
Si vous suivez ces bonnes pratiques, votre schéma de base de données sera d’une utilité optimale, ce qui vous permettra de tirer le meilleur parti de votre data warehouse et d’obtenir des informations exploitables.
Auteure : Juliette Guin, Experte en data integration, Fivetran
(c) Ill. DepositPhotos
Recommandé pour vous
Commenter
Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.
