Wat Airtable onderscheidt van gewone spreadsheet applicaties is zijn vermogen om gerelateerde concepten aan elkaar te koppelen. Weten hoe de relaties tussen verschillende groepen objecten moeten worden weergegeven, vergt enige oefening, maar door de verschillende soorten relaties te leren kennen, kunt u krachtige bases maken die de complexiteit van uw gegevens nauwkeuriger weergeven.
Dit artikel definieert de verschillende soorten relaties tussen lijsten van entiteiten en geeft voorbeelden, zodat u ze zelf kunt leren identificeren. Ook wordt uitgelegd hoe je veel-op-veel relaties kunt weergeven met behulp van een techniek die “junction tables” wordt genoemd.
Relatiesoorten
Een-op-een
One-to-many
Many-to-many-relaties en junction tables
Voorbeeld 1: Studenten en klassen
Voorbeeld 2: Sollicitanten en interviewers
Voorbeeld 3: Klanten, klantorders, producten, en fabrikanten
Gerekende velden en junction tables
Relatiesoorten
Airtable is een database. In databases zijn er een paar verschillende manieren om de relaties tussen verschillende lijsten van entiteiten te beschrijven.
Een-op-een
De eenvoudigste soort relatie is een een-op-een relatie. Stel, je hebt een lijst met namen van mensen, en een lijst met sofi-nummers. Elke persoon heeft maar één sofinummer, en elk sofinummer is gekoppeld aan één persoon. In de context van een Airtable-basis wordt een één-op-één-relatie gewoonlijk het best weergegeven door de twee lijsten met informatie samen te voegen in één tabel, met gebruikmaking van twee velden.
Het is ook mogelijk om een één-op-één-relatie aan te tonen met behulp van een gekoppeld recordveld binnen dezelfde tabel. Stel dat je een lijst hebt van deelnemers aan een kunstschaatswedstrijd. Voor elk paar personen dat deelneemt aan een schaatswedstrijd is de relatie één-op-één, omdat elke partner slechts één andere partner heeft. Als je in dit geval een gekoppeld recordveld zou maken waarin de tabel aan zichzelf is gekoppeld, dan zou het mogelijk zijn om een veld met partners in te vullen met recordlinks uit de grotere tabel met alle deelnemers.
Eén-op-één-relaties zijn relatief zeldzaam, omdat het onwaarschijnlijk is dat beide zijden van een bepaalde relatie kunnen worden gekoppeld aan één en slechts één tegenhanger. Hier zijn enkele andere voorbeelden van één-op-één-relaties:
- People-Passports (Elke persoon heeft slechts één paspoort van een bepaald land en elk paspoort is bestemd voor slechts één persoon.)
- Landen-vlag (Elk land heeft maar één vlag en elke vlag hoort maar bij één land.)
- Spousal-relaties (Elke persoon heeft maar één echtgenoot.)
Eén-op-veel
Een complexer (maar ook veel gebruikelijker) type relatie is één-op-veel/mens-op-één. Als je bijvoorbeeld een lijst met kunstwerken hebt en een lijst met musea, dan kan elk kunstwerk maar in één museum tegelijk zijn, maar elk museum kan wel veel kunstwerken hebben. Door deze twee lijsten van entiteiten (musea en kunstwerken) in een basis op te splitsen in twee tabellen kunt u informatie opslaan die relevant is voor elke entiteit. Voor kunstwerken zou dit informatie kunnen zijn zoals de kunstenaar en de datum van voltooiing, en voor musea zou dit informatie kunnen zijn over de openingstijden van het museum en het adres.
Als je een Airtable basis zou maken die een één-op-veel relatie weergeeft tussen een lijst van musea en een lijst van kunstwerken, zou je elk van deze lijsten in een tabel met musea en een tabel met werken kunnen plaatsen. Met behulp van gekoppelde recordvelden zou je het dan zo kunnen opzetten dat elk record in de werktabel gekoppeld is aan een museumrecord, en elk record in de museumtabel is gekoppeld aan een of meer records in de werktabel.
Het zal vaak zinvol zijn om de twee helften van een one-to-many-relatie in afzonderlijke tabellen te hebben, maar wanneer alle entiteiten in de relatie van dezelfde klasse zijn, kan het zinvoller zijn om een tabel met zelfkoppeling te gebruiken. Stel bijvoorbeeld dat u een bedrijfsgids hebt met de namen van alle werknemers: u wilt de relaties tussen managers en hun ondergeschikten modelleren, aangezien elke manager vele werknemers beheert en elke werknemer slechts één manager heeft. Om dit te doen, zou u zelf-koppelende gekoppelde recordvelden kunnen maken voor de manager en ondergeschikten van elk individu.
Hier volgen enkele andere voorbeelden van one-to-many-relaties:
- People-Addresses (Elke persoon kan op één adres wonen, maar elk adres kan een of meer personen huisvesten.)
- Eigenaren-Huisdieren (Elk huisdier heeft één eigenaar, maar elke eigenaar kan een of meer huisdieren hebben.)
- Boer-Materieel (Elk landbouwwerktuig is eigendom van één boer, maar elke boer kan vele werktuigen bezitten.)
Many-to-many
Tot slot kunnen entiteiten ook een many-to-many-relatie hebben. Stel dat je een lijst met boeken hebt, en een lijst met auteurs – elk boek kan een of meer auteurs hebben, en elke auteur kan meerdere boeken hebben geschreven. In dit geval heb je veel boeken die gerelateerd zijn aan veel auteurs. In Airtable is het weergeven van de relatie tussen deze twee lijsten met entiteiten net zo eenvoudig als het maken van twee tabellen en het creëren van gekoppelde recordvelden.
In Airtable is het weergeven van een eenvoudige veel-op-veel relatie tussen twee lijsten met entiteiten net zo eenvoudig als het weergeven van een één-op-veel relatie. Met gekoppelde recordvelden kunt u het zo instellen dat elk record in de boekentabel gekoppeld is aan een of meer auteurrecords, en dat elk record in de auteurstabel gekoppeld is aan een of meer records in de boekentabel.
Zoals bij één-op-één-relaties en één-op-veel-relaties is het soms zinvol om veel-op-veel-relaties in een enkele, zelf-linkende tabel weer te geven, bijvoorbeeld wanneer alle entiteiten tot dezelfde klasse behoren. Stel dat u de vriendschappen binnen een groep mensen wilt bijhouden. Elke persoon kan veel vrienden hebben, en elk van die vrienden kan op zijn beurt weer veel andere vrienden hebben. U zou deze veel-op-veel relatie in een enkele tabel kunnen bijhouden met een zelf-linkend recordveld.
Hier volgen enkele andere voorbeelden van many-to-many-relaties:
- Ingrediënten-Recipes (Elk voedingsmiddel kan in meerdere recepten worden gebruikt en elk recept vereist meerdere ingrediënten.)
- Dokters-Patiënten (Elke dokter ziet meerdere patiënten en elke patiënt ziet meerdere dokters.)
- Werknemers-Taken (Elke werknemer werkt aan vele taken tegelijk, terwijl aan elke taak door een of meer werknemers wordt gewerkt.)
- Klanten-Producten (Elke klant kan vele producten kopen, en elk van die producten kan door vele verschillende klanten worden gekocht.
Many-to-many relaties en junction tables
Vaak is het weergeven van een many-to-many relatie in Airtable zo eenvoudig als het koppelen van twee tabellen aan elkaar. In sommige situaties moet u echter niet alleen weten dat er een relatie is tussen twee entiteiten – u moet ook andere informatie over die relatie kunnen uitdrukken en opslaan. In deze gevallen moet je een derde tabel maken, een zogenaamde junction (of join) table. Je kunt de junction table zien als een plaats om attributen van de relaties tussen twee lijsten van entiteiten op te slaan.
Voorbeeld 1: Studenten en klassen
Als dat abstract klinkt, laten we dan eens naar een specifiek voorbeeld kijken: Stel, je hebt een lijst met studenten en een lijst met klassen. Er is een veel-op-veel relatie tussen de studenten en hun klassen, want elke student kan meerdere klassen volgen, en voor elke klas kunnen meerdere studenten ingeschreven zijn. Je zou gewoon een tabel met studenten en een tabel met klassen kunnen maken, ze aan elkaar koppelen, en het daarbij laten. Maar wat als je informatie wilt opslaan over de cijfers van elke student in de klas? Of welk semester die student de les heeft gevolgd? Zet je deze informatie in de tabel met studenten, of in de tabel met klassen?
De cijfers van de studenten in hun klassen en de tijdstippen waarop zij de klassen volgden, kunnen worden beschouwd als attributen van de relaties tussen de studenten en de klassen waarin zij zich hebben ingeschreven. Aangezien de relaties elk hun eigen relevante lijsten met informatie hebben, is de beste manier om te werk te gaan het maken van een junction table.
Laten we deze junction table stap-voor-stap opbouwen. Stel dat je al een tabel met leerlingen en een tabel met klassen hebt.
We kunnen een nieuwe tabel maken met een veld dat is gekoppeld aan leerlingen en een veld dat is gekoppeld aan klassen. Je kunt de tabel “Cijfers”, “Inschrijving”, “Studenten/Klassen” noemen, of wat je maar helpt herinneren dat deze tabel een verbindingstabel is tussen de tabellen Studenten en Klassen.
We moeten nog steeds het primaire veld voor deze verbindingstabel invullen. Een van de beste manieren om records in een junction table een naam te geven is door gebruik te maken van een formule, die gegevens uit andere velden in de tabel gebruikt om een unieke naam voor elk record samen te stellen. Dit kan bijzonder nuttig zijn voor een junction table, omdat de records die de relaties tussen concepten weergeven zich vaak niet bijzonder goed lenen voor een enkel uniek primair veld. Informatie die relevant is voor de relatie tussen een student en een klas (zoals het cijfer, of het semester waarin een klas werd gevolgd) kan ook in deze tabel worden gezet.
Als we terugkeren naar de tabellen Students of Classes, zien we dat nieuwe velden die zijn gekoppeld aan de junction table automatisch zijn aangemaakt. U kunt rollup- of lookup-velden in deze tabellen maken om automatisch informatie uit de junction table naar de tabellen Students of Classes te halen.
Example 2: Sollicitanten en interviewers
Hier volgt een ander voorbeeld van wanneer u een junction table zou willen gebruiken: Je hebt een lijst met sollicitanten en een lijst met interviewers. Elke sollicitant doorloopt meerdere interviews met verschillende interviewers, en elke interviewer organiseert meerdere interviews met verschillende sollicitanten. Het interview kan worden gezien als de relatie tussen een sollicitant en een interviewer, en als zodanig hebben we een junction table nodig om informatie over elk interview op te slaan.
Exemplaar 3: Klanten, klantorders, producten en fabrikanten
Hier volgt een complexer voorbeeld. Stel dat u een Airtable-basis wilt maken met lijsten van klanten en hun orders, en producten en hun fabrikanten. Elke klant kan veel orders plaatsen, maar elke order is slechts aan één klant gekoppeld:
Op dezelfde manier kan elke fabrikant veel producten maken, maar elk product kan slechts één fabrikant hebben:
Elke klantorder kan veel producten hebben, en elk product kan deel uitmaken van veel klantorders:
Het probleem hier is echter dat er geen goede plaats is om informatie op te slaan over de hoeveelheid van elk product in de specifieke order van een klant. De oplossing is om een verbindingstabel te maken tussen de klantbestellingen en de productentabellen, die we de tabel met bestelregelitems kunnen noemen.
Hier volgt een voorbeeld van hoe dat er in een Airtable-basis uit zou zien. De cliententabel is gekoppeld aan de clientbestellingentabel:
De clientbestellingentabel is gekoppeld aan de cliententabel en aan de orderregelitems tabel:
De tabel met bestelregelitems neemt de koppelingen van de tabel met producten en de tabel met klantenbestellingen, en de hoeveelheid van elk product, om unieke primaire veldwaarden voor elk van de regels te maken.
De tabel met producten is gekoppeld aan de orderregelitems en de fabrikanten:
En de fabrikantentabel is gekoppeld aan de productentabel in een één-op-veel relatie.
Gerekende velden en verbindingstabellen
Wanneer u zoveel gekoppelde velden hebt, is het belangrijk om lookup- en rollup-velden in uw voordeel te gebruiken om de hoeveelheid gegevensinvoer die u moet uitvoeren tot een minimum te beperken.
Voorstellend dat u een veld in de tabel met klantbestellingen wilt hebben dat automatisch de totale kosten van de bestelling van een individuele klant berekent. Om dit te doen, zou u de informatie over de kosten per eenheid uit de productentabel in de tabel met bestelregelitems opnemen met behulp van een lookup-veld.
Daarna zou u met een formule de totale kosten per regelitem kunnen berekenen.
En ten slotte kunt u een rollup-veld in de tabel met klantorders gebruiken om de totale kosten van alle regelitems in een bepaalde klantorder op te tellen.
