Ce qui distingue Airtable des tableurs ordinaires, c’est sa capacité à lier des concepts connexes entre eux. Savoir comment représenter les relations entre différents groupes d’objets peut demander un peu de pratique – mais en apprenant les différents types de relations, vous pouvez créer des bases puissantes qui représentent plus précisément les complexités de vos données.
Cet article définit les différents types de relations entre les listes d’entités et fournit des exemples pour que vous puissiez apprendre à les identifier vous-même. Il explique également comment représenter les relations de plusieurs à plusieurs à l’aide d’une technique appelée « tables de jonction ».
Types de relations
Une à une
Une à plusieurs
Relations plusieurs à plusieurs et tables de jonction
Exemple 1 : étudiants et classes
Exemple 2 : Candidats et enquêteurs
Exemple 3 : Clients, commandes de clients, produits et fabricants
Champs calculés et tables de jonction
Types de relations
Airtable est une base de données. Dans les bases de données, il existe quelques façons différentes de décrire les relations entre différentes listes d’entités.
Une à une
Le type de relation le plus simple est une relation une à une. Supposons que vous ayez une liste de noms de personnes, et une liste de numéros de sécurité sociale. Chaque personne n’a qu’un seul numéro de sécurité sociale, et chaque numéro de sécurité sociale est lié à une seule personne. Dans le contexte d’une base Airtable, une relation biunivoque est généralement mieux représentée en consolidant les deux listes d’informations dans une seule table, en utilisant deux champs.
Il est également possible de démontrer une relation biunivoque en utilisant un champ d’enregistrement lié dans la même table. Supposons que vous ayez une liste de concurrents dans une compétition de patinage artistique. Pour chaque paire d’individus concourant dans une épreuve de patinage en couple, leur relation est biunivoque, puisque chaque partenaire n’a qu’un seul autre partenaire. Si, dans ce cas, vous faisiez un champ d’enregistrement lié où la table était liée à elle-même, il serait alors possible de remplir un champ de partenaires avec des liens d’enregistrement provenant de la table plus grande de tous les concurrents.
Les relations biunivoques sont comparativement rares, car il tend à être improbable que les deux côtés d’une relation donnée puissent correspondre à une et une seule contrepartie. Voici quelques autres exemples de relations biunivoques :
- Personnes-Passeports (Chaque personne ne possède qu’un seul passeport d’un pays donné et chaque passeport est destiné à une seule personne.)
- Pays-Drapeau (Chaque pays n’a qu’un seul drapeau et chaque drapeau n’appartient qu’à un seul pays.)
- Relations entre conjoints (Chaque personne n’a qu’un seul conjoint.)
Une à plusieurs
Un type de relation plus complexe (mais aussi beaucoup plus courant) est une relation une à plusieurs/une à un. Par exemple, si vous avez une liste d’œuvres d’art et une liste de musées, chaque œuvre d’art ne peut être que dans un seul musée à la fois, mais chaque musée peut avoir de nombreuses œuvres d’art. Dans une base, la division de ces deux listes d’entités (musées et œuvres d’art) en deux tables vous permet de stocker des informations pertinentes pour chaque entité. Pour les œuvres d’art, cela pourrait inclure des informations comme l’artiste et la date de réalisation, et pour les musées, cela pourrait inclure des informations sur les heures d’ouverture du musée et son adresse.
Si vous deviez faire une base Airtable représentant une relation un à plusieurs entre une liste de musées et une liste d’œuvres d’art, vous pourriez mettre chacune de ces listes dans une table musées et une table œuvres. En utilisant des champs d’enregistrement liés, vous pourriez ensuite le configurer de sorte que chaque enregistrement dans la table des œuvres soit lié à un enregistrement de musée, et que chaque enregistrement dans la table des musées soit lié à un ou plusieurs enregistrements dans la table des œuvres.
Il sera souvent judicieux d’avoir les deux moitiés d’une relation un-à-plusieurs sur des tables distinctes, mais lorsque toutes les entités de la relation sont de la même classe, il peut être plus judicieux d’utiliser une table auto-lien. Par exemple, supposons que vous disposez d’un annuaire d’entreprise contenant les noms de tous les employés : vous souhaitez modéliser les relations entre les responsables et leurs subordonnés, étant donné que chaque responsable gère de nombreux employés et que chaque employé n’a qu’un seul responsable. Pour ce faire, vous pourriez créer des champs d’enregistrement liés auto-liés pour le manager et les subordonnés de chaque individu.
Voici d’autres exemples de relations un-à-plusieurs :
- Personnes-Adresses (Chaque personne peut vivre à une adresse, mais chaque adresse peut abriter une ou plusieurs personnes.)
- Propriétaires-Appareils domestiques (Chaque animal domestique a un propriétaire, mais chaque propriétaire peut avoir un ou plusieurs animaux domestiques.)
- Farmer-Equipement (Chaque équipement agricole appartient à un agriculteur, mais chaque agriculteur peut posséder plusieurs équipements.)
Many-to-many
Enfin, les entités peuvent également avoir une relation many-to-many. Disons que vous avez une liste de livres, et une liste d’auteurs – chaque livre peut avoir un ou plusieurs auteurs, et chaque auteur peut avoir écrit plusieurs livres. Dans ce cas, vous avez de nombreux livres liés à de nombreux auteurs. Dans Airtable, la représentation de la relation entre ces deux listes d’entités est aussi simple que de faire deux tables et de créer des champs d’enregistrement liés.
Dans Airtable, la représentation d’une simple relation many-to-many entre deux listes d’entités est tout aussi simple que la représentation d’une relation one-to-many. Avec les champs d’enregistrement liés, vous pouvez le configurer de sorte que chaque enregistrement de la table des livres soit lié à un ou plusieurs enregistrements d’auteur, et que chaque enregistrement de la table des auteurs soit lié à un ou plusieurs enregistrements de la table des livres.
Comme pour les relations un-à-un et les relations un-à-plusieurs, il est parfois judicieux de représenter les relations plusieurs-à-plusieurs sur une seule table auto-lien, par exemple lorsque toutes les entités sont de la même classe. Supposons que vous souhaitiez suivre les amitiés au sein d’un groupe de personnes. Chaque personne peut avoir de nombreux amis, et chacun de ces amis peut à son tour avoir de nombreux autres amis. Vous pourriez suivre cette relation many-to-many sur une seule table avec un champ d’enregistrement auto-lien.
Voici d’autres exemples de relations plusieurs à plusieurs :
- Ingrédients-Recettes (Chaque article alimentaire peut être utilisé dans plusieurs recettes et chaque recette nécessite plusieurs ingrédients.)
- Docteurs-Patients (Chaque médecin voit plusieurs patients et chaque patient voit plusieurs médecins.)
- Employés-Tâches (Chaque employé travaille sur plusieurs tâches à la fois tandis que chaque tâche est travaillée par un ou plusieurs employés.)
- Clients-Produits (Chaque client peut acheter plusieurs produits et chacun de ces produits peut être acheté par plusieurs clients différents.)
Relations de plusieurs à plusieurs et tables de jonction
Souvent, représenter une relation de plusieurs à plusieurs dans Airtable est aussi facile que de relier deux tables ensemble. Cependant, dans certaines situations, vous n’avez pas seulement besoin de savoir qu’il existe une relation entre deux entités – vous devez également être capable d’exprimer et de stocker d’autres informations sur cette relation. Dans ce cas, vous devez créer une troisième table, appelée table de jonction (ou de jointure). Vous pouvez considérer la table de jonction comme un endroit où stocker les attributs des relations entre deux listes d’entités.
Exemple 1 : étudiants et classes
Si cela vous semble abstrait, examinons un exemple spécifique : Supposons que vous ayez une liste d’étudiants et une liste de classes. Il existe une relation many-to-many entre les étudiants et leurs classes, puisque chaque étudiant peut suivre plusieurs classes, et que chaque classe peut avoir plusieurs étudiants inscrits. Vous pourriez simplement créer une table des étudiants et une table des classes, les relier entre elles et en rester là. Mais qu’en est-il si vous souhaitez stocker des informations sur la note de chaque étudiant dans la classe ? Ou le semestre au cours duquel l’étudiant a suivi le cours ? Mettez-vous ces informations dans la table des étudiants, ou dans la table des classes ?
Les notes des étudiants dans leurs classes et les moments où ils ont suivi les classes peuvent être considérés comme des attributs des relations entre les étudiants et les classes dans lesquelles ils se sont inscrits. Comme les relations ont chacune leurs propres listes d’informations pertinentes, la meilleure façon de procéder est de faire une table de jonction.
Construisons cette table de jonction étape par étape. Disons que vous avez déjà une table des élèves et une table des classes.
Nous pouvons faire une nouvelle table qui a un champ lié aux élèves et un champ lié aux classes. Vous pourriez appeler cette table « Grades », « Enrollment », « Students/Classes », ou tout ce qui vous aide à vous souvenir que cette table est une table de jonction entre les tables Students et Classes.
Nous devons encore remplir le champ primaire de cette table de jonction. L’une des meilleures façons de nommer les enregistrements dans une table de jonction est d’utiliser une formule, qui prend les données d’autres champs de la table pour composer un nom unique pour chaque enregistrement. Cela peut s’avérer particulièrement utile pour une table de jonction, car souvent les enregistrements représentant les relations entre les concepts ne se prêtent pas particulièrement bien à un champ primaire unique. Les informations pertinentes pour la relation de chaque étudiant avec un cours (comme la note, ou le semestre au cours duquel un cours a été suivi) peuvent également être mises dans cette table.
Si nous revenons aux tables Étudiants ou Classes, nous verrons que de nouveaux champs liés à la table de jonction ont été créés automatiquement. Vous pouvez créer des champs rollup ou lookup sur ces tables pour tirer automatiquement les informations de la table de jonction vers les tables Étudiants ou Classes.
Exemple 2 : Candidats et enquêteurs
Voici un autre exemple de cas où vous voudriez utiliser une table de jonction : Vous avez une liste de candidats à un emploi, et une liste d’intervieweurs. Chaque candidat passe plusieurs entretiens avec différents intervieweurs, et chaque intervieweur accueille plusieurs entretiens avec différents candidats. L’entretien peut être considéré comme la relation entre un candidat et un interviewer, et en tant que tel, nous aurions besoin d’une table de jonction pour stocker des informations sur chaque entretien.
Exemple 3 : Clients, commandes de clients, produits et fabricants
Voici un exemple plus complexe. Supposons que vous vouliez faire une base Airtable organisant vos listes de clients et leurs commandes, et de produits et leurs fabricants. Chaque client peut passer plusieurs commandes, mais chaque commande n’est associée qu’à un seul client :
De même, chaque fabricant peut fabriquer plusieurs produits, mais chaque produit ne peut avoir qu’un seul fabricant :
Chaque commande client peut avoir de nombreux produits, et chaque produit peut faire partie de nombreuses commandes client :
Le problème ici, cependant, est qu’il n’y a pas de bon endroit pour stocker les informations sur la quantité de chaque produit dans la commande particulière d’un client. La solution consiste à faire une table de jonction entre les tables des commandes des clients et des produits, que nous pouvons appeler la table des articles de la ligne de commande.
Voici un exemple de ce à quoi cela ressemblerait dans une base Airtable. La table des clients est liée à la table des commandes des clients:
La table des commandes des clients est liée à la table des clients et à la table des postes de commande:
La table des articles de ligne de commande prend les liens de la table des produits et de la table des commandes des clients, ainsi que la quantité de chaque produit, pour créer des valeurs de champ primaire uniques pour chacune des lignes.
La table des produits est liée aux articles de ligne de commande et aux fabricants:
Et la table des fabricants est liée à la table des produits dans une relation un-à-plusieurs :
Champs calculés et tables de jonction
Lorsque vous avez autant de champs liés, il est important d’utiliser les champs de consultation et de rollup à votre avantage pour minimiser la quantité de saisie de données que vous devez effectuer.
Supposons que vous souhaitiez disposer d’un champ dans la table des commandes clients qui calculerait automatiquement le coût total de la commande d’un client individuel. Pour ce faire, vous tireriez les informations de la table des produits sur le coût unitaire dans la table des postes de la commande à l’aide d’un champ de consultation.
Puis, avec une formule, vous pourriez calculer le coût total par poste.
Et enfin, vous pouvez utiliser un champ de rollup dans la table des commandes des clients pour faire la somme de tous les coûts totaux de tous les articles de ligne de commande dans la commande d’un client donné.
.