O que distingue a Airtable das aplicações comuns de folha de cálculo é a sua capacidade de ligar conceitos relacionados. Saber representar as relações entre diferentes grupos de objectos pode exigir alguma prática – mas aprendendo sobre os diferentes tipos de relações, pode criar bases poderosas que representam com maior precisão as complexidades dos seus dados.
Este artigo define os diferentes tipos de relações entre listas de entidades e fornece exemplos para que possa aprender a identificá-las você mesmo. Explica também como representar muitas relações usando uma técnica chamada “tabelas de junção”.
Tipos de relação
Uma-a-um
Uma-a-muitas
Many-to-many
Many-to-many relationships and junction tables
Exemplo 1: Estudantes e aulas
Exemplo 2: Candidatos e entrevistadores
Exemplo 3: Clientes, encomendas de clientes, produtos, e fabricantes
Campos calculados e tabelas de junção
Tipos de relacionamento
Airtable é uma base de dados. Nas bases de dados, existem algumas formas diferentes de descrever as relações entre diferentes listas de entidades.
Uma para uma
O tipo mais simples de relação é uma relação de um para um. Suponha que tem uma lista de nomes de pessoas, e uma lista de números da segurança social. Cada pessoa tem apenas um número de segurança social, e cada número de segurança social está ligado a uma pessoa. No contexto de uma base Airtable, uma relação de um para um é normalmente melhor representada pela consolidação das duas listas de informação juntas numa única tabela, utilizando dois campos.
É também possível demonstrar uma relação um-para-um utilizando um campo de registo ligado dentro da mesma tabela. Suponha que tem uma lista de concorrentes numa competição de patinagem artística. Para cada par de indivíduos a competir num evento de patinagem a pares, a sua relação é de um para um, uma vez que cada parceiro tem apenas um outro parceiro. Se neste caso fizesse um campo de registo ligado onde a tabela estava ligada a si própria, então seria possível preencher um campo de parceiros com ligações de registo da tabela maior de todos os concorrentes.
As relações de um-para-um são comparativamente raras porque tende a ser improvável que ambos os lados de uma determinada relação possam ser combinados com uma e apenas uma contraparte. Eis alguns outros exemplos de relações um-para-um:
- Pessoas-Passaportes (Cada pessoa tem apenas um passaporte de um determinado país e cada passaporte destina-se apenas a uma pessoa.)
- Li>Franca do país (Cada país tem apenas uma bandeira e cada bandeira pertence apenas a um país.)
- Relações Esposas (Cada pessoa tem apenas um cônjuge.)
Um-para-muitos
Um tipo de relação mais complexa (mas também muito mais comum) é um-para-muitos/muitos-para-um. Por exemplo, se tiver uma lista de obras de arte e uma lista de museus, cada obra de arte só pode estar num museu de cada vez, mas cada museu pode ter muitas obras de arte. Numa base, a divisão destas duas listas de entidades (museus e obras de arte) em duas tabelas permite-lhe armazenar informação relevante para cada entidade. Para obras de arte, isto poderia incluir informação como o artista e a data de conclusão, e para museus, isto poderia incluir informação sobre o horário de abertura do museu e o seu endereço.
Se fosse para fazer uma base Airtable representando uma relação de um para muitos entre uma lista de museus e uma lista de obras de arte, poderia colocar cada uma dessas listas numa mesa de museus e numa mesa de obras. Utilizando campos de registos ligados, poderia então configurá-la de modo a que cada registo na tabela de obras esteja ligado a um registo do museu, e cada registo na tabela dos museus esteja ligado a um ou mais registos na tabela de obras.
Muitas vezes fará sentido ter as duas metades de uma relação de um para muitos em tabelas separadas, mas quando todas as entidades na relação são da mesma classe, pode fazer mais sentido utilizar uma tabela de autoligação. Por exemplo, digamos que tem um directório de empresas com os nomes de todos os empregados: pretende modelar as relações entre gestores e os seus subordinados, dado que cada gestor gere muitos empregados e cada empregado tem apenas um gestor. Para tal, poderia criar campos de registo auto-ligados para cada gerente e subordinados.
Aqui estão alguns outros exemplos de relações um-para-muitos:
- Endereços de pessoas (Cada pessoa pode viver num endereço, mas cada endereço pode albergar uma ou mais pessoas.)
- Proprietários-Pets (Cada animal de estimação tem um dono, mas cada dono pode ter um ou mais animais de estimação)
- Farmer-Equipment (Cada peça de equipamento agrícola é propriedade de um agricultor, mas cada agricultor pode possuir muitas peças de equipamento)
Many-to-many
P>Por último, as entidades podem também ter uma relação de muitos-a-muitos. Digamos que tem uma lista de livros, e uma lista de autores – cada livro pode ter um ou mais autores, e cada autor pode ter escrito vários livros. Neste caso, tem muitos livros relacionados com muitos autores. Em Airtable, representar a relação entre estas duas listas de entidades é tão simples como fazer duas tabelas e criar campos de registo ligados.
Em Airtable, representar uma simples relação entre duas listas de entidades é tão simples como representar uma relação de um para muitos. Com campos de registos ligados, pode configurá-lo de modo a que cada registo na tabela de livros esteja ligado a um ou mais registos de autor, e cada registo na tabela de autores esteja ligado a um ou mais registos na tabela de livros.
As com relações um-para-um e relações um-para-muitos, há alturas em que faz sentido representar muitas relações numa única tabela de autoligação, tal como quando todas as entidades são da mesma classe. Suponha que quisesse seguir as amizades dentro de um grupo de pessoas. Cada pessoa pode ter muitos amigos, e por sua vez, cada um desses amigos pode ter muitos outros amigos. Poderia rastrear esta relação entre muitos e muitos numa única mesa com um campo de registo de autoligação.
Aqui estão alguns outros exemplos de muitas outras relações:
- Ingredientes-Receitas (Cada item alimentar pode ser usado em múltiplas receitas e cada receita requer múltiplos ingredientes.)
- Doctors-Patients (Cada médico vê muitos pacientes e cada paciente vê muitos médicos.)
- Empregados-Tarefas (Cada empregado trabalha em muitas tarefas de cada vez enquanto cada tarefa é trabalhada por um ou mais empregados.)
- Cli>Cli>Produtos-Produtos-Clientes (Cada cliente pode comprar muitos produtos, e cada um desses produtos pode ser comprado por muitos clientes diferentes.)
Many-to-many relationships and junction tables
Often, representing a many-to-many relationship in Airtable is as easy as linking two tables together. No entanto, em algumas situações, não só é preciso saber que existe uma relação entre duas entidades – também é preciso ser capaz de expressar e armazenar outras informações sobre essa relação. Nestes casos, é necessário criar uma terceira tabela, chamada tabela de junção (ou join). Pode pensar na tabela de junção como um lugar para armazenar atributos das relações entre duas listas de entidades.
Exemplo 1: Estudantes e turmas
Se isso parecer abstracto, vejamos um exemplo específico: Suponha que tem uma lista de alunos e uma lista de aulas. Há uma relação entre os estudantes e as suas turmas, uma vez que cada estudante pode ter várias turmas, e cada turma pode ter vários estudantes matriculados. Pode simplesmente fazer uma tabela de alunos e uma tabela de aulas, ligá-los entre si, e deixá-la assim. Mas e se quisesse guardar informações sobre a nota de cada aluno na turma? Ou qual foi o semestre em que o aluno teve a aula? Coloca esta informação na tabela de alunos, ou na tabela de aulas?
As notas dos alunos nas suas aulas e as horas em que tiveram aulas podem ser consideradas atributos das relações entre os alunos e as aulas em que se inscreveram. Uma vez que cada uma das relações tem as suas próprias listas de informação relevantes, a melhor maneira de proceder é fazer uma tabela de junção.
Vamos construir esta tabela de junção passo a passo. Digamos que já tem uma tabela de alunos e uma tabela de classes.
Podemos fazer uma nova tabela que tenha um campo ligado aos alunos e um campo ligado às aulas. Pode chamar à tabela “Classificações”, “Inscrição”, “Estudantes/Classes”, ou o que quer que seja que o ajude a lembrar-se que esta tabela é uma tabela de junção entre as tabelas Estudantes e Classes.
Ainda precisamos de preencher o campo primário para esta tabela de junção. Uma das melhores formas de nomear registos numa tabela de junção é utilizar uma fórmula, que recolhe dados de outros campos da tabela para compor um nome único para cada registo. Isto pode ser particularmente útil para uma tabela de cruzamentos, pois muitas vezes os registos que representam as relações entre conceitos não se prestam particularmente bem a um único campo primário único. Informações relevantes para a relação de cada aluno com uma classe (como a nota, ou o semestre em que uma classe foi tirada) também podem ser colocadas nesta tabela.
se voltarmos às tabelas de Alunos ou Classes, veremos que novos campos ligados à tabela de junção foram criados automaticamente. Pode criar campos de rollup ou de pesquisa nestas tabelas para puxar automaticamente a informação da tabela de junção para as tabelas de Estudantes ou Aulas.
Exemplo 2: Candidatos e entrevistadores
Aqui está outro exemplo de quando gostaria de utilizar uma tabela de junção: Tem uma lista de candidatos a emprego, e uma lista de entrevistadores. Cada candidato passa por múltiplas entrevistas com diferentes entrevistadores, e cada entrevistador recebe múltiplas entrevistas com diferentes candidatos. A entrevista pode ser considerada como a relação entre um candidato e um entrevistador, e como tal precisaríamos de uma tabela de junção para armazenar informação sobre cada entrevista.
p>Exemplo 3: Clientes, encomendas de clientes, produtos, e fabricantesp>Aqui está um exemplo mais complexo. Suponha que pretende fazer uma base Airtable organizando as suas listas de clientes e as suas encomendas, e produtos e os seus fabricantes. Cada cliente pode fazer muitas encomendas, mas cada encomenda está apenas associada a um cliente:
Simplesmente, cada fabricante pode fazer muitos produtos, mas cada produto pode ter apenas um fabricante:
Cada encomenda de cliente pode ter muitos produtos, e cada produto pode fazer parte de muitas encomendas de clientes:
p>
O problema aqui, no entanto, é que não há um bom local para armazenar informação sobre a quantidade de cada produto numa encomenda específica de um cliente. A solução é fazer uma tabela de junção entre as encomendas dos clientes e as tabelas de produtos, a que podemos chamar tabela de artigos de linha de encomenda.
Aqui está um exemplo de como isso seria numa base Airtable. A tabela de clientes está ligada à tabela de encomendas de clientes:
A tabela de encomendas de clientes está ligada à tabela de clientes e à tabela de itens de linha de encomenda:
A tabela de itens de linha de encomenda toma as ligações da tabela de produtos e da tabela de encomendas dos clientes, e a quantidade de cada produto, para criar valores de campo primários únicos para cada uma das linhas.
A tabela de produtos está ligada aos itens da linha de encomenda e aos fabricantes:
E a tabela de fabricantes está ligada à tabela de produtos numa relação de um para muitos.
Fabricantes.png
Campos calculados e tabelas de junção
Quando tem tantos campos ligados, é importante utilizar campos de pesquisa e campos de rollup a seu favor para minimizar a quantidade de entrada de dados que precisa de efectuar.
P>Ponha a hipótese de querer ter um campo na tabela de encomendas de clientes que calcularia automaticamente o custo total de uma encomenda individual de um cliente. Para o fazer, retiraria a informação da tabela de produtos sobre o custo por unidade na tabela de itens da linha de encomenda usando um campo de pesquisa.
Então, com uma fórmula, poderia calcular o custo total por item da linha de encomenda.
E finalmente, pode usar um campo rollup na tabela de encomendas do cliente para somar todo o custo total de todos os itens da linha de encomenda em qualquer encomenda do cliente.