Créer une nouvelle base Airtable pour en faire un véritable système d'information ne s'improvise pas. Il faut d'abord faire un travail de conception de votre base de données. Le diagramme entité-relation (ERD - Entity Relationship Diagram) est la première et indispensable étape de conception avant de démarrer la mise en place de votre base.

Pourquoi ? Parce que vous ne savez pas encore quelles sont les tables dont vous allez avoir besoin dans votre base pour représenter votre système.

Entité ➡ Table

Le diagramme entité-relation est le moyen le plus simple pour documenter les résultats de l'analyse du système que vous souhaitez modéliser et structurer dans une base. Le diagramme entité-relation va représenter les entités (c'est-à-dire les objets physiques ou virtuels) en jeu dans votre système et leurs relations. Ces entités vont devenir les tables de votre base.

Pour créer votre diagramme entité-relation je vous recommande l'outil gratuit Diagrams.net

Exemple :

Vous souhaitez créer une base Airtable pour piloter votre salon de coiffure. Le brief (simplifié à son essence) du système serait :  

Un client commande une coiffure (un service). Vous souhaitez centraliser toutes les informations en une base : Nombre de commandes, chiffre d'affaire, informations sur les clients et votre catalogue de services.

On peut identifier ici 3 entités : Client, Commande, Service. On peut représenter le diagramme comme ceci :

Vous constaterez que les liens entre les entités sont différents.

Les différents types de relations

On distingue 3 types de relations entre les entités d'un système :

Type 1 : One to One (1-to-1)

Un élément (record) d'une entité (table) est lié à un et un seul élément d'une autre entité.

Exemple : Une personne et un numéro de sécurité sociale.

Une personne ne peut avoir qu'un numéro de sécurité sociale. Un numéro de sécurité sociale ne peut être attribué qu'à une seule personne.

Dans ce cas, la création d'une entité distincte n'est pas évidente, car le numéro de sécurité sociale peut devenir un simple attribut (un field) de votre table Personnes.

Type 2 : One to Many (1-to-M)

Un élément (record) d'une entité (table) peut être relié à un ou plusieurs éléments d'une autre entité.  Et dans l'autre sens (Many to One).

Exemple : Un client et une commande.

Une client peut passer plusieurs commandes. Mais une commande ne peut être passée que par un seul client (sauf en cas de possibilité de commande groupée).

Dans notre salon de coiffure, la relation est bien One to Many, car une coupe de cheveux (un service) ne peut être commandée que par un seul client.

Type 3 : Many to Many (1-to-M)

Un ou plusieurs éléments (records) d'une entité (table) peuvent être liés à un ou plusieurs éléments d'une autre table.

Exemple : Un film et un acteur.

Plusieurs acteurs peuvent jouer dans un film. Et un acteur peut jouer dans plusieurs films.

Type 4 : Many to Many avec Attribut

Il existe un quatrième type de relation. C'est lorsqu'un attribut appartient aux deux éléments dans une relation many to many. Dans ce cas, nous aurons besoin d'une table de jonction.

Exemple : Le rôle d'un acteur dans un film.

Un acteur a un rôle dans un film. Donc le rôle est lié en même temps à un acteur et à un film. Sauf dans le cas particulier où le même acteur joue plusieurs rôles.

Je pense évidement à Eddy Murphy dans Un prince à New York qui joue 4 rôles dans le même film, mais on ne s'en rend compte qu'au générique de fin !

Pour aller plus loin, je vous invite à visionner cette vidéo :


Concevoir une base Airtable avec une structure adaptée requiert un minimum d'exercice et d'expérience. C'est ce que vous allez apprendre à faire dans le cadre de notre Formation Airtable.