Une base de données relationnelle bien conçue permet de garantir l'exactitude, la cohérence et la fiabilité de vos données. Voici quelques conseils en matière de design pour tirer profit de votre base de données.

Pour rationaliser votre activité, vous assurer que vos équipes collaborent à partir d'une seule et même source ou optimiser la gestion de vos données, une base de données relationnelle est idéale.

Les grandes et les petites organisations utilisent des bases de données relationnelles pour stocker, gérer et analyser plus efficacement des informations essentielles dans différents domaines (customer management, content production, product planning, recherche UX, etc.)

Mais attention : toutes les bases de données relationnelles ne se valent pas. Une base de données mal conçue peut rendre l'accès aux informations plus difficile ou altérer vos données alors qu'une base de données bien conçue présente de nombreux avantages :

  • Vous pouvez éviter les données redondantes, dupliquées et invalides. Vous pouvez concevoir votre base de données relationnelle de façon à minimiser les risques liés à la mauvaise qualité des données.
  • Vous pouvez résoudre le problème des données requises manquantes. Si vous identifiez en amont les types de données les plus critiques pour votre workflow, vous pouvez structurer votre base de données de manière à ce qu'elle impose une saisie correcte des données, ou qu'elle alerte les utilisateurs lorsqu'ils n'ont pas saisi une donnée critique.
  • La structure de la base de données est facile à modifier et à entretenir. Les workflows évoluent et vous serez sans doute amené à ajuster la structure de votre base de données. Heureusement, lorsqu'une base de données relationnelle est bien conçue, les changements apportés aux fields d'une table n'affectent pas les autres tables.
  • Les données elles-mêmes sont faciles à modifier. De la même manière, lorsqu'une base de données relationnelle est bien conçue, les modifications apportées aux valeurs d'un field donné dans une table n'affectent pas les autres fields de cette table.
  • Il est plus facile de trouver les informations dont vous avez besoin. Si votre base de données est structurée de façon logique et cohérente (pas de fields ni de tables en double), elle est plus facile à explorer.
  • Vous passez moins de temps à rafistoler votre base de données et mettez ce temps à profit pour avancer. La meilleure base de données est celle dont vous n'avez pas à vous soucier.

Vous pourriez construire une maison sans finaliser les plans, mais vous auriez de sérieux doutes quant à la solidité de la structure. De la même façon, il est préférable de songer consciencieusement au design de votre base de données relationnelle avant de vous lancer.

Tout cela peut sembler décourageant si vous découvrez les bases de données relationnelles, ou même si vous avez déjà construit des bases de données et rencontré des difficultés. Heureusement, il existe des principes en matière de design que vous pouvez suivre pour concevoir des bases de données de qualité.

Qu'est-ce qu'une base de données "bien conçue"?


Le design est donc essentiel pour construire une base de données adaptée à vos besoins. Mais que signifie une base de données bien designée ?

Une base de données bien conçue renforce l'intégrité des données

L'intégrité des données renvoie à l'exactitude, l'exhaustivité et la cohérence globales des informations de votre base de données ; une base de données bien conçue préserve l'intégrité des données en implémentant les processus et les normes proposés lors de la phase de conception.

L'intégrité des données comprend trois aspects techniques spécifiques de la structure d'une base de données relationnelle :

  • L'intégrité des entités (ou intégrité au niveau des tables) garantit qu'une table ne contient pas de records en double et que les valeurs des clés primaires de la table sont toutes uniques et non nulles.
  • L'intégrité du domaine (ou intégrité au niveau des fields) garantit que l'objectif de chaque field est clair et identifiable et que les valeurs de chaque field sont valides, cohérentes et exactes.
  • L'intégrité référentielle (ou intégrité au niveau des relations) garantit que les relations entre les paires de tables sont solides, de sorte que les records dans les tables sont synchronisés chaque fois que des données sont saisies, actualisées ou supprimées dans l'une ou l'autre table.

Une base de données bien conçue permet d'appliquer des business rules

Chaque organisation a ses propres exigences en matière de données, on parle de business rules. Voici quelques exemples : une marque exige que chaque produit de son catalogue se voit attribuer un code alphanumérique unique de huit caractères ; une université exige que ses étudiants ne s'inscrivent pas à plus de six cours par semestre.

Idéalement, votre base de données doit pouvoir appliquer vos business rules ; cela garantit que les données qui entrent dans votre base sont à la fois précises et utiles. Par exemple, si l'université de l'exemple précédent ne tient pas compte de ses business rules lors de la création de sa base de données, un étudiant peut tenter de s'inscrire à 20 cours durant un même semestre - ce qui génère du désordre et donne du fil à retordre à l'administrateur de la base de données.

Comment concevoir votre base de données relationnelle, étape par étape

Si tout cela vous semble fastidieux ou complexe, pas de panique - il existe un processus systématique que vous pouvez suivre pour vous assurer que votre base de données relationnelle suit les bons principes en matière de design, qu'elle est adaptée aux besoins de votre organisation et qu'elle évite les pièges classiques.

Étape 1 : définissez votre but

Avant de commencer à designer votre base de données, posez-vous la bonne question : "Pourquoi je crée cette base de données ?" Est-ce pour gérer des transactions commerciales ? Pour stocker des informations ? Pour résoudre un problème particulier ? Quoi qu'il en soit, prenez le temps d'identifier l'objectif de la base de données que vous allez créer.

Vous pouvez même collaborer avec les managers et les utilisateurs finaux et rédiger ensemble un mission statement (énoncé de mission) pour votre base de données.

En outre, vous devez définir les objectifs des utilisateurs finaux de la base : quelles tâches spécifiques devront-ils effectuer ? Élaborer une liste des objectifs - comme "Produire un rapport mensuel des ventes" - vous aidera à déterminer la bonne structure pour votre base de données.

Étape 2 : analysez les data requirements


Avant de commencer à designer votre base de données, vous devez analyser les data requirements (les besoins en matière de données) de votre organisation. Cela peut sembler intimidant, mais il s'agit simplement d'évaluer la façon dont votre équipe travaille et d'identifier le type de data le plus adapté. Vous pouvez examiner les processus en place et interroger les membres de l'équipe. Posez-vous les questions suivantes :

  • Comment votre organisation collecte-t-elle les données ? Utilisez-vous des tableurs ? Des templates papier ? Une autre base de données ? Quelle que soit la méthode utilisée, trouvez des exemples et examinez-les. Par exemple, votre calendrier éditorial peut se trouver dans un tableur et comporter des colonnes "Auteur", "Date d'échéance", "Editeur", etc.
  • Comment votre organisation présente-t-elle les données ? Utilise-t-elle des PDF ? Des diapositives ? Des pages web ? Examinez tous types de présentation et utilisez-les pour identifier des fields potentiels.
  • Comment les membres de votre équipe utilisent-ils les données ? Interrogez-les pour le savoir et pour identifier les éventuelles failles du système actuel.

Étape 3 : créez une liste d'entités et une liste d'attributs


Après avoir défini les objectifs de votre organisation et analysé vos data requirements, vous devez élaborer une liste d'entités et une liste d'attributs. Dans une base de données relationnelle, une entité est un objet, une personne, un lieu, un événement ou une idée - comme les "clients", les "produits" ou les "projets". Les attributs sont les caractéristiques qui définissent ces entités, comme le "nom", la "quantité", l'"adresse", le "numéro de téléphone" ou le "genre". On peut voir les entités comme des noms et les attributs comme les adjectifs qui décrivent ces noms.

Choisissez des entités et listez-les. Ces entités vous aideront à définir vos tables lors de la phase design et à identifier les attributs nécessaires pour créer votre liste de fields. Par exemple, si vous créez une base de données de talents pour un label, votre liste d'entités pourrait ressembler à ceci :

  • Artiste
  • Agent
  • Lieu
  • Concerts (Gigs)
  • etc.

Ensuite, créez une liste distincte contenant les attributs pertinents pour chaque entité. Ces attributs définiront les fields de vos tables. Dans la base de données de talents, votre liste d'attributs pourrait ressembler à ceci :

  • Nom de l'Artiste
  • Numéro de Téléphone de l'Artiste
  • Nom de l'Agent
  • Numéro de Téléphone de l'Agent
  • Adresse Email de l'Agent
  • Nom du Lieu
  • Adresse du Lieu
  • Dates de concerts (Gig Dates)
  • etc.

Après avoir dressé une liste préliminaire des attributs, vérifiez qu'ils représentent bien les besoins en matière d'informations de votre organisation.

Conseils :

  • Si plusieurs attributs ont des noms différents mais représentent le même concept, dédupliquez-les (supprimez les doublons). Par exemple, si vous avez "Produit No" et "Numéro de produit" sur votre liste, vous devez en supprimer un.
  • Si plusieurs attributs ont des noms similaires mais représentent des concepts différents, renommez-les pour que ce soit plus clair. Par exemple, si vous avez deux attributs "Nom", vous pouvez les renommer "Nom de l'Artiste" et "Nom du Lieu".

Ensuite, passez ces listes en revue avec les membres de l'équipe que vous avez interrogés pour avoir leur avis.

Étape 4 : modélisez les tables et les fields

Après avoir créé vos listes d'entités et d'attributs, vous devez les utiliser pour concevoir la structure de votre base de données relationnelle. Vos entités seront les différentes tables de votre base et vos attributs seront les fields de ces tables.

Prenez vos listes et affectez chaque attribut à vos tables. Par exemple, après avoir affecté les attributs à nos nouvelles tables, notre base de données de talents pourrait ressembler à ceci :

Ensuite, vous devez choisir un primary key field (champ clé primaire) pour chaque table. Une clé primaire est un élément essentiel pour garantir l'intégrité des données. Elle identifie chaque record d'une table et permet d'établir des relations entre différentes tables.

Le primary key field de chaque table doit répondre aux critères suivants :

  • Il doit contenir des valeurs uniques. Cela vous évitera de créer des records en double dans une table.
  • Il ne peut pas contenir de valeur nulle. Une valeur nulle est l'absence de valeur et vous ne pouvez pas utiliser une valeur nulle pour identifier un record.
  • La valeur ne doit pas être souvent modifiée. Idéalement, les valeurs des clés primaires ne doivent être que rarement modifiées.
  • Il ne doit pas s'agir d'informations personnelles sensibles. Les numéros de sécurité sociale, les mots de passe, les informations personnelles sur la santé (Protected Health Information) et d'autres données sensibles peuvent être uniques, mais ne doivent pas être utilisés comme clés primaires parce qu'il est bien plus difficile de sécuriser des données situées à un seul endroit.
  • Idéalement, le nom de la table figure dans son propre nom. Bien que cela ne soit pas strictement nécessaire, le fait d'avoir le nom de la table dans le nom du primary key field peut faciliter l'identification de la table d'où provient le primary key field. Par exemple, "Nom de l'employé" serait évidemment identifiable comme provenant de la table "Employés".

Il est possible que votre liste préliminaire de fields pour une table donnée ne contienne pas un seul field répondant à tous ces critères. Mais vous pouvez combiner deux ou plusieurs fields pour créer un field distinct et unique qui répond à tous ces critères. Par exemple, vous pourriez combiner les valeurs d'un field "Prénom" et d'un field "Nom" pour créer un troisième field "Nom complet" en utilisant une formule de concaténation.

Si cette stratégie ne fonctionne pas, vous pouvez toujours créer un nouveau field conçu spécifiquement pour les codes d'identification uniques, qui servira de primary key field. Des fields comme "ID produit" ou "Numéro de facture" sont souvent créés à cette fin.

Revenons à notre exemple de base de données de talents. Pour la table "Artistes", le field "Nom de l'artiste" est déjà un bon candidat pour la primary key, car il est peu probable que votre maison de disques signe deux artistes avec le même nom. Nous pouvons également choisir "Nom du Lieu" comme clé primaire pour la table "Lieux".

Pour les autres tables, cependant, il serait probablement préférable de créer de nouveaux fields qui concaténent les valeurs des fields existants. Dans la table "Agents", nous pourrions créer un nouveau field - "Nom complet de l'agent" - qui concaténerait les valeurs des fields "Prénom de l'agent" et "Nom de famille de l'agent". Pour la table "Gigs", un artiste pourrait se produire dans le même lieu à plusieurs reprises, nous devrions donc créer un nouveau field qui donne un nom unique à la combinaison spécifique d'un artiste dans un lieu à une date spécifique.

Vous pourriez éventuellement concaténer le nom de l'artiste, le lieu et la date pour créer des valeurs comme "2 Linkz at the Gotham City Metro Club, 02/13/2019", mais cela peut être long et complexe. Vous pouvez également créer un nouveau field - "Gig code" - avec des valeurs code alphanumérique unique (comme "E0023"). Faites en fonction de vos besoins et de ceux de votre équipe.

Étape 5 : établissez des relations entre les tables


Une fois que vous avez identifié vos tables, vos fields et vos primary key fields, vous pouvez commencer à les relier. Vous pouvez faire une première tentative pour définir les relations logiques entre vos différentes tables.

Les relations entre les tables sont créées en reliant les primary key fields et les foreign key fields (champs clé étrangère). Une clé étrangère est un field d'une table qui renvoie à la clé primaire d'une autre table. Par exemple, si vous concevez une base de données de pipeline de ventes, votre table "Deals" peut contenir un foreign key field "Sales Rep", qui sera lié à votre table "Sales Reps" ; si vous concevez une base de données de calendrier de contenu, votre table "Pieces" peut contenir un foreign key field "Editor" et un foreign key field "Author", qui seront tous deux liés à votre table "Staff".

Pour commencer à définir les relations entre vos différentes tables, identifiez les foreign key fields potentiels. Dans une base de données relationnelle idéale, les foreign key fields sont les seuls à pouvoir être dupliqués. Donc, si vous identifiez des fields qui apparaissent dans plusieurs tables, ce sont probablement de bons candidats pour les foreign key fields.

Pour revenir à l'exemple de notre agence de talents, nous pouvons parcourir nos listes de fields par table et identifier les fields qui partagent des noms/concepts avec les primary key fields d'autres tables :

Il existe trois types de relations entre les tables :

  • Les relations "One-to-one", dans lesquelles un record d'une table est lié à un et un seul record d'une autre table. Par exemple, chaque nom de client est associé à un et un seul identifiant client et chaque identifiant client est associé à un et un seul nom de client.
  • Les relations "One-to-many", dans lesquelles un record d'une table peut être relié à un ou plusieurs records d'une autre table. Par exemple, une base de données de suivi de projet avec les tables "Projets" et "Tâches" : chaque projet a plusieurs tâches associées, mais chaque tâche n'est associée qu'à un seul projet.
  • Les relations "Many-to-many", dans lesquelles un ou plusieurs records d'une table peuvent être liés à un ou plusieurs records d'une autre table. Par exemple, une base de données avec les tables "Clients" et "Produits" : un seul client peut acheter plusieurs produits et un même produit est certainement acheté par plusieurs clients.

Il est important de savoir identifier les différents types de relations pour modéliser les business rules de votre organisation. Par exemple, si vous définissez une relation one-to-many, vous pouvez appliquer une règle imposant que les records du côté "many" de la relation ne soient toujours liés qu'à un seul record de l'autre table.

Pour visualiser la façon dont vos tables seront liées les unes aux autres, vous pouvez créer un diagramme entité-relation, ou diagramme ERD. Un diagramme ERD est une sorte de graphique qui utilise des formes pour représenter vos tables et des lignes pour représenter les relations entre vos tables.

Voici un exemple de diagramme ERD pour notre base de données de talents. Les clés primaires (primary keys) ont été marquées par "PK" et les clés étrangères (foreign keys) par "FK". Les différentes formes aux extrémités des lignes indiquent les types de relations entre les entités : la forme en patte d'oie représente "many", tandis que le tiret représente "one". Ainsi, par exemple, la ligne entre les tables "Artists" et "Agents" peut être interprétée comme suit : chaque artiste est associé à un agent, mais chaque agent peut être associé à plusieurs artistes.

Vous vous demandez peut-être : pourquoi définir les relations entre ces tables ? Les relations entre les tables vous permettent d'établir des connexions logiques entre des paires de tables et donc de puiser des données de plusieurs tables simultanément. Cela signifie que vous pouvez rendre vos tables plus efficaces et minimiser les données redondantes. Si vous construisez correctement vos relations, vous pourrez visualiser les données dont vous avez besoin dans n'importe quelle table, à tout moment, et vous n'aurez à les saisir ou à les modifier qu'à un seul endroit.

Pour mieux comprendre comment cela pourrait fonctionner en pratique, revenons encore une fois à l'exemple de notre agence de talents. Supposons que vous vouliez connaître le total des recettes généré par chaque artiste au cours de ses concerts. Comme vous avez déjà établi une relation entre les tables "Concerts" et "Artistes", vous pouvez utiliser cette relation pour rechercher les données pertinentes (relatives aux concerts) par artiste.

Vous pouvez créer un nouveau computed field (field calculé) dans la table "Artistes" - "Total gig revenue" - qui indique le "Revenue generated per gig" pour tous les linked records dans la table "Gigs" par artiste. Un computed field est un field type spécial qui génère automatiquement une valeur en utilisant une ou plusieurs valeurs d'un autre field de la base de données. Comme le computed field s'actualise automatiquement, si vous modifiez une valeur dans le field "Revenue generated per gig" ou ajoutez de nouveaux records pour un artiste, le field "Total gig revenue" se mettra également à jour automatiquement.

Vous pouvez même aller plus loin : pour connaître le total généré par chaque agent grâce à tous les artistes qu'il gère, vous pouvez utiliser la relation établie entre les tables "Artistes" et "Agents" et créer un nouveau computed field dans la table "Agents" - "Artists’ total gig revenue" - qui indique le "Total gig revenue" pour tous les linked records dans la table "Artistes" par agent. Comme ce nouveau computed field dans la table "Agents" est connecté à la table "Gigs" via la table "Artistes", il sera également mis à jour automatiquement si les valeurs de la table "Gigs" changent, même s'il n'y a pas de relation directe entre les tables "Gigs" et "Agents".

Les relations entre les tables existantes vous permettent de créer des computed fields qui se mettent automatiquement à jour dans toutes les tables liées en fonction des modifications apportées à un seul endroit dans une seule table.

Cette base de données modélise les relations décrites dans le diagramme ERD ci-dessus. Cliquez dessus pour voir comment les tables sont reliées les unes aux autres, ou faites-en une copie en cliquant sur le bouton "Copy base".

Étape 6 : établissez des business rules


Après avoir établi la structure globale de votre base de données, il est temps d'intégrer les business rules de votre organisation dans le design de votre base de données. Une fois encore, faites appel aux managers et aux utilisateurs finaux. Consultez-les pour connaitre les contraintes qui auront le plus d'impact sur vos workflows.

D'une manière générale, il existe deux grands types de business rules. Les field-specific business rules font référence aux contraintes imposées à des fields spécifiques. Voici quelques exemples de field-specific business rules : "Les dates figurant sur nos factures de commande de produits doivent être affichées au format ISO "2020-12-22"", "Les adresses email stockées dans le répertoire des employés doivent être valides" ou "Les seules valeurs valides pouvant être sélectionnées pour ce status field sont "À faire", "En cours" et "Fait".

Les relationship-specific business rules font référence aux contraintes imposées aux relations de table. Voici quelques exemples de relationship-specific business rules : "Chaque projet de notre video production tracker doit être lié à un ou plusieurs fact-checkers" ou "Chaque line item de la commande d'un client doit être lié à un seul et unique produit".

La méthode la plus complète pour identifier et mettre en œuvre vos field-specific business rules est d'examiner systématiquement chaque field de chaque table pour déterminer quelles business rules s'appliquent à ce field. Chaque field aura des business rules pertinentes, même si ces règles sont aussi générales que "Chaque valeur dans le field "Prénom de l'employé" doit être une chaîne de caractères composée de lettres". De la même manière, vous pouvez examiner systématiquement chacune des relations de votre base de données et déterminer si elle nécessite ou non des relationship-specific business rules.

À un moment donné, vous devrez probablement modifier vos business rules existantes ou en ajouter de nouvelles. Par exemple, vous pourriez ajouter la valeur "Annulé" dans un status field ne comprenant que les options "À faire", "En cours" et "Fait". Heureusement, si vous avez suivi les étapes précédentes et mis en place une structure de base de données robuste, il devrait être relativement facile d'ajuster vos field- et relationship-specific business rules sans avoir à restructurer toute votre base de données.

Étape 7 : vérifiez votre travail


Vous avez presque terminé le design process de la base de données - il ne vous reste plus qu'à effectuer une dernière vérification de votre base de données. Quelques questions à vous poser lorsque vous examinez chaque table, field et relation :

  • Chaque type d'entité a-t-il sa propre table dédiée ?
  • Y a-t-il des tables qui pourraient être consolidées ou, à l'inverse, décomposées en plusieurs tables ?
  • Y a-t-il des fields en double dans ma base de données qui ne sont pas des foreign keys ?
  • Chacun de mes fields a-t-il des spécifications définies qui correspondent aux business rules de notre organisation ?
  • Les relations entre mes tables ont-elles un sens ?

Si tout vous semble correct, présentez votre base de données aux utilisateurs finaux et aux managers qui l'utiliseront. S'ils sont satisfaits du résultat final, réjouissez-vous ! Soyez fier de votre nouvelle base de données, bien structurée.


Il s'agit d'une adaptation de cet article du blog Airtable.

Vous souhaitez vous former sur Airtable ? Découvrez nos tutoriels et formations Airtable.