To co odróżnia Airtable od zwykłych aplikacji arkuszy kalkulacyjnych to jego zdolność do łączenia ze sobą powiązanych koncepcji. Wiedza o tym, jak reprezentować relacje pomiędzy różnymi grupami obiektów może wymagać trochę praktyki – ale poprzez poznanie różnych typów relacji, możesz stworzyć potężne bazy, które dokładniej reprezentują złożoność Twoich danych.
Ten artykuł definiuje różne typy relacji pomiędzy listami encji i dostarcza przykłady, abyś mógł nauczyć się je identyfikować. Wyjaśnia również, jak reprezentować relacje wiele do wielu przy użyciu techniki zwanej „tabelami węzłowymi”.
Typy relacji
Jeden-do-jednego
Jeden-do-wielu
Związki wiele-do-wielu i tabele węzłowe
Przykład 1: Uczniowie i klasy
Przykład 2: Kandydaci i ankieterzy
Przykład 3: Klienci, zamówienia klientów, produkty i producenci
Pola obliczeniowe i tabele węzłowe
Rodzaje relacji
Airtable jest bazą danych. W bazach danych istnieje kilka różnych sposobów na opisanie relacji pomiędzy różnymi listami encji.
Jeden do jednego
Najprostszym rodzajem relacji jest relacja jeden do jednego. Załóżmy, że masz listę nazwisk ludzi i listę numerów ubezpieczenia społecznego. Każda osoba ma tylko jeden numer ubezpieczenia społecznego, a każdy numer ubezpieczenia społecznego jest powiązany z jedną osobą. W kontekście bazy Airtable, relacja jeden do jednego jest zwykle najlepiej reprezentowana przez konsolidację dwóch list informacji razem w jednej tabeli, przy użyciu dwóch pól.
Możliwe jest również zademonstrowanie relacji jeden do jednego przy użyciu pola powiązanego rekordu w ramach tej samej tabeli. Załóżmy, że posiadamy listę zawodników startujących w zawodach łyżwiarstwa figurowego. Dla każdej pary osób startujących w zawodach łyżwiarstwa parami, ich relacja jest jeden do jednego, ponieważ każdy partner ma tylko jednego innego partnera. Jeśli w tym przypadku stworzyłbyś pole połączonego rekordu, gdzie tabela byłaby połączona z samą sobą, wtedy byłoby możliwe wypełnienie pola partnerów z linkami rekordów z większej tabeli wszystkich zawodników.
Związki jeden-do-jednego są stosunkowo rzadkie, ponieważ jest mało prawdopodobne, że obie strony danego związku mogą być dopasowane do jednego i tylko jednego odpowiednika. Oto kilka innych przykładów relacji jeden do jednego:
- Ludzie-Paszporty (Każda osoba ma tylko jeden paszport z danego kraju i każdy paszport jest przeznaczony tylko dla jednej osoby.)
- Kraj-Flaga (Każdy kraj ma tylko jedną flagę i każda flaga należy tylko do jednego kraju.)
- Związki małżeńskie (Każda osoba ma tylko jednego współmałżonka.)
Jeden do wielu
Bardziej złożonym (ale również o wiele bardziej powszechnym) typem relacji jest jeden do wielu/jeden do jednego. Na przykład, jeśli masz listę dzieł sztuki i listę muzeów, każde dzieło sztuki może być tylko w jednym muzeum w tym samym czasie, ale każde muzeum może mieć wiele dzieł sztuki. W bazie, podzielenie tych dwóch list podmiotów (muzeów i dzieł sztuki) na dwie tabele pozwala na przechowywanie informacji istotnych dla każdego podmiotu. W przypadku dzieł sztuki, mogą to być informacje takie jak artysta i data ukończenia, a w przypadku muzeów, mogą to być informacje o godzinach otwarcia muzeum i jego adresie.
Jeśli miałbyś stworzyć bazę Airtable reprezentującą relację jeden do wielu pomiędzy listą muzeów i listą dzieł sztuki, mógłbyś umieścić każdą z tych list w tabeli muzeów i tabeli dzieł. Używając połączonych pól rekordów, można by to skonfigurować tak, że każdy rekord w tabeli prac jest powiązany z jednym rekordem muzeum, a każdy rekord w tabeli muzeów jest powiązany z jednym lub więcej rekordami w tabeli prac.
Często ma sens posiadanie dwóch połówek relacji jeden do wielu na oddzielnych tabelach, ale gdy wszystkie encje w relacji są tej samej klasy, może mieć więcej sensu użycie tabeli samowiązującej. Na przykład, załóżmy, że masz katalog firmowy z nazwiskami wszystkich pracowników: chcesz modelować relacje pomiędzy menedżerami i ich podwładnymi, biorąc pod uwagę, że każdy menedżer zarządza wieloma pracownikami, a każdy pracownik ma tylko jednego menedżera. Aby to zrobić, można utworzyć samopodłączające się pola rekordów dla każdego menedżera i podwładnych.
Oto kilka innych przykładów relacji jeden do wielu:
- Osoby-Adresy (Każda osoba może mieszkać pod jednym adresem, ale pod każdym adresem może mieszkać jedna lub więcej osób.)
- Właściciele-Zwierzęta (Każde zwierzę ma jednego właściciela, ale każdy właściciel może mieć jedno lub więcej zwierząt.)
- Rolnik-Sprzęt (Każdy kawałek sprzętu rolniczego jest własnością jednego rolnika, ale każdy rolnik może posiadać wiele sztuk sprzętu.)
Many-to-many
Na koniec, encje mogą mieć również relacje many-to-many. Załóżmy, że masz listę książek i listę autorów – każda książka może mieć jednego lub więcej autorów, a każdy autor może napisać wiele książek. W tym przypadku masz wiele książek powiązanych z wieloma autorami. W Airtable, reprezentowanie relacji pomiędzy tymi dwoma listami encji jest tak proste, jak tworzenie dwóch tabel i tworzenie połączonych pól rekordów.
W Airtable, reprezentowanie prostej relacji wiele do wielu pomiędzy dwoma listami encji jest tak samo proste, jak reprezentowanie relacji jeden do wielu. Dzięki połączonym polom rekordów możesz ustawić, że każdy rekord w tabeli książek jest połączony z jednym lub więcej rekordami autorów, a każdy rekord w tabeli autorów jest połączony z jednym lub więcej rekordami w tabeli książek.
Tak jak w przypadku relacji jeden-do-jednego oraz jeden-do-wielu, istnieją sytuacje, w których sensowne jest reprezentowanie relacji wiele-do-wielu w pojedynczej, samodzielnie linkującej się tabeli, np. gdy wszystkie encje są tej samej klasy. Załóżmy, że chcesz śledzić przyjaźnie w grupie ludzi. Każda osoba może mieć wielu przyjaciół, a z kolei każdy z tych przyjaciół może mieć wielu innych przyjaciół. Moglibyśmy śledzić tę relację wiele do wielu w pojedynczej tabeli z samopodłączającym się polem rekordu.
Oto kilka innych przykładów relacji typu many-to-many:
- Składniki-Przepisy (Każdy artykuł spożywczy może być użyty w wielu przepisach, a każdy przepis wymaga wielu składników.)
- Lekarze-Pacjenci (Każdy lekarz widzi wielu pacjentów, a każdy pacjent widzi wielu lekarzy.
- Pracownicy-Zadania (Każdy pracownik pracuje nad wieloma zadaniami w tym samym czasie, podczas gdy każde zadanie jest opracowywane przez jednego lub więcej pracowników.)
- Klienci-Produkty (Każdy klient może kupić wiele produktów, a każdy z tych produktów może być zakupiony przez wielu różnych klientów.
Zależności many-to-many i tabele łączące
Często, reprezentowanie relacji many-to-many w Airtable jest tak proste jak łączenie dwóch tabel razem. Jednakże, w niektórych sytuacjach, nie musisz tylko wiedzieć, że istnieje relacja pomiędzy dwoma podmiotami – musisz również być w stanie wyrazić i przechowywać inne informacje na temat tej relacji. W takich przypadkach musisz utworzyć trzecią tabelę, zwaną tabelą złączenia (lub join). Możesz myśleć o tabeli złączenia jako o miejscu do przechowywania atrybutów relacji pomiędzy dwoma listami encji.
Przykład 1: Studenci i klasy
Jeśli brzmi to abstrakcyjnie, spójrzmy na konkretny przykład: Załóżmy, że mamy listę uczniów i listę klas. Istnieje relacja many-to-many pomiędzy studentami i ich klasami, ponieważ każdy student może brać udział w wielu zajęciach, a każda klasa może mieć wielu zapisanych studentów. Mógłbyś po prostu stworzyć tabelę uczniów i tabelę klas, połączyć je razem i pozostawić to tak jak jest. Ale co jeśli chciałbyś przechowywać informacje o ocenach każdego studenta w klasie? Albo w którym semestrze uczeń uczęszczał na zajęcia? Czy umieścić te informacje w tabeli studentów, czy w tabeli klas?
Oceny studentów z ich zajęć oraz czas, w którym uczestniczyli w zajęciach mogą być uznane za atrybuty relacji pomiędzy studentami a klasami, do których się zapisali. Ponieważ każda z tych relacji ma swoją własną listę informacji, najlepszym sposobem jest stworzenie tabeli łączącej.
Zbudujmy taką tabelę łączącą krok po kroku. Powiedzmy, że mamy już tabelę uczniów i tabelę klas.
Możemy stworzyć nową tabelę, która będzie miała pole związane z uczniami i pole związane z klasami. Możemy nazwać tę tabelę „Grades”, „Enrollment”, „Students/Classes” lub jakkolwiek inaczej, aby zapamiętać, że ta tabela jest tabelą łączącą tabele Students i Classes.
Wciąż musimy wypełnić pole główne dla tej tabeli łączącej. Jednym z najlepszych sposobów na nazwanie rekordów w tabeli połączeniowej jest użycie formuły, która pobiera dane z innych pól w tabeli, aby skomponować unikalną nazwę dla każdego rekordu. Może to być szczególnie użyteczne w przypadku tabel połączonych, ponieważ często rekordy reprezentujące relacje między pojęciami nie nadają się szczególnie dobrze do pojedynczego, unikalnego pola głównego. Informacje istotne dla relacji każdego studenta z klasą (takie jak ocena lub semestr, w którym zajęcia były prowadzone) mogą być również umieszczone w tej tabeli.
Jeśli wrócimy do tabel Students lub Classes, zobaczymy, że nowe pola powiązane z tabelą łączącą zostały utworzone automatycznie. Możesz utworzyć pola rollup lub lookup w tych tabelach, aby automatycznie przeciągnąć informacje z tabeli węzłowej do tabel Uczniowie lub Klasy.
Przykład 2: Kandydaci i osoby przeprowadzające rozmowy kwalifikacyjne
Jest jeszcze jeden przykład, kiedy chciałbyś użyć tabeli węzłowej: Masz listę kandydatów do pracy i listę osób przeprowadzających rozmowy kwalifikacyjne. Każdy kandydat przechodzi przez wiele wywiadów z różnymi ankieterami, a każdy ankieter prowadzi wiele wywiadów z różnymi kandydatami. Rozmowa kwalifikacyjna może być traktowana jako relacja pomiędzy aplikantem a ankieterem, i jako taka będzie nam potrzebna tabela łącząca do przechowywania informacji o każdej rozmowie kwalifikacyjnej.
Przykład 3: Klienci, zamówienia klientów, produkty i producenci
Oto bardziej złożony przykład. Załóżmy, że chcesz stworzyć bazę Airtable organizującą listy klientów i ich zamówień oraz produktów i ich producentów. Każdy klient może składać wiele zamówień, ale każde zamówienie jest powiązane tylko z jednym klientem:
Podobnie, każdy producent może wytwarzać wiele produktów, ale każdy produkt może mieć tylko jednego producenta:
Każde zamówienie klienta może mieć wiele produktów, a każdy produkt może być częścią wielu zamówień klienta:
Problemem jest jednak to, że nie ma dobrego miejsca do przechowywania informacji o ilości każdego produktu w konkretnym zamówieniu klienta. Rozwiązaniem jest stworzenie tabeli łączącej tabele zamówień klienta i produktów, którą możemy nazwać tabelą pozycji zamówienia.
Przykładowo wygląda to w bazie Airtable. Tabela clients jest połączona z tabelą clients orders:
Tabela clients orders jest połączona z tabelą clients oraz z tabelą order line items:
Tabela Pozycje zamówień pobiera łącza z tabeli Produkty i tabeli Zamówienia klientów oraz ilość każdego produktu, aby utworzyć unikalne wartości pola głównego dla każdego z wierszy.
Tabela produkty jest powiązana z pozycjami linii zamówienia i producentami:
A tabela producenci jest połączona z tabelą produkty w relacji jeden do wielu.
Pola obliczeniowe i tabele połączeń
Gdy masz tak wiele połączonych pól, ważne jest, aby używać pól wyszukujących i pól rolowanych na swoją korzyść, aby zminimalizować ilość danych, które musisz wprowadzić.
Załóżmy, że chcesz mieć pole w tabeli zamówień klienta, które automatycznie oblicza całkowity koszt zamówienia indywidualnego klienta. Aby to zrobić, należałoby pobrać z tabeli produktów informacje o koszcie jednostkowym do tabeli pozycji zamówienia za pomocą pola lookup.
Następnie, za pomocą formuły, można by obliczyć całkowity koszt dla każdej pozycji zamówienia.
I na koniec, możesz użyć pola rollup w tabeli zamówień klienta, aby zsumować całkowity koszt wszystkich pozycji zamówienia w zamówieniu danego klienta.
