Lo que diferencia a Airtable de las aplicaciones ordinarias de hojas de cálculo es su capacidad para vincular conceptos relacionados. Saber cómo representar las relaciones entre diferentes grupos de objetos puede requerir algo de práctica-pero aprendiendo sobre los diferentes tipos de relaciones, puede crear poderosas bases que representen con mayor precisión las complejidades de sus datos.
Este artículo define los diferentes tipos de relaciones entre listas de entidades y proporciona ejemplos para que pueda aprender a identificarlas usted mismo. También explica cómo representar las relaciones de muchos a muchos utilizando una técnica llamada «tablas de unión.»
Tipos de relaciones
De uno a uno
De uno a muchos
Relaciones de muchos a muchos y tablas de unión
Ejemplo 1: Alumnos y clases
Ejemplo 2: Solicitantes y entrevistadores
Ejemplo 3: Clientes, pedidos de clientes, productos y fabricantes
Campos calculados y tablas de unión
Tipos de relación
Airtable es una base de datos. En las bases de datos, hay algunas formas diferentes de describir las relaciones entre diferentes listas de entidades.
Una a una
El tipo de relación más simple es una relación uno a uno. Suponga que tiene una lista de nombres de personas, y una lista de números de la seguridad social. Cada persona tiene sólo un número de la seguridad social, y cada número de la seguridad social está vinculado a una persona. En el contexto de una base Airtable, una relación uno a uno suele representarse mejor consolidando las dos listas de información juntas en una sola tabla, utilizando dos campos.
También es posible demostrar una relación uno a uno utilizando un campo de registro vinculado dentro de la misma tabla. Suponga que tiene una lista de competidores en una competición de patinaje artístico. Para cada pareja de individuos que compiten en una prueba de patinaje por parejas, su relación es de uno a uno, ya que cada pareja sólo tiene otra pareja. Si en este caso se hiciera un campo de registro vinculado en el que la tabla estuviera vinculada a sí misma, entonces sería posible rellenar un campo de parejas con enlaces de registros de la tabla más grande de todos los competidores.
Las relaciones de uno a uno son comparativamente raras porque tiende a ser poco probable que ambos lados de una relación dada puedan coincidir con una y sólo una contraparte. Aquí hay otros ejemplos de relaciones uno a uno:
- Personas-Pasaportes (Cada persona tiene un solo pasaporte de un país determinado y cada pasaporte está destinado a una sola persona.)
- País-Bandera (Cada país tiene una sola bandera y cada bandera pertenece a un solo país.)
- Relaciones de cónyuge (Cada persona tiene un solo cónyuge.)
- Personas-Direcciones (Cada persona puede vivir en una dirección, pero cada dirección puede albergar a una o más personas.)
- Propietarios-Mascotas (Cada mascota tiene un propietario, pero cada propietario puede tener una o más mascotas.)
- Granjero-Equipo (Cada pieza de equipo agrícola es propiedad de un granjero, pero cada granjero puede poseer muchas piezas de equipo.)
- Ingredientes-Recetas (Cada alimento puede usarse en múltiples recetas y cada receta requiere múltiples ingredientes.)
- Médicos-Pacientes (Cada médico ve muchos pacientes y cada paciente ve muchos médicos.)
- Empleados-Tareas (Cada empleado trabaja en muchas tareas a la vez mientras que cada tarea está siendo trabajada por uno o más empleados.)
- Clientes-Productos (Cada cliente puede comprar muchos productos y cada uno de esos productos puede ser comprado por muchos clientes diferentes.)
De uno a muchos
Un tipo de relación más compleja (pero también mucho más común) es de uno a muchos/de hombre a uno. Por ejemplo, si tienes una lista de obras de arte y una lista de museos, cada obra de arte sólo puede estar en un museo a la vez, pero cada museo puede tener muchas obras de arte. En una base, la división de estas dos listas de entidades (museos y obras de arte) en dos tablas le permite almacenar información relevante para cada entidad. En el caso de las obras de arte, esto podría incluir información como el artista y la fecha de realización, y en el caso de los museos, esto podría incluir información sobre el horario de apertura del museo y su dirección.
Si tuviera que hacer una base Airtable que representara una relación de uno a muchos entre una lista de museos y una lista de obras de arte, podría poner cada una de esas listas en una tabla de museos y una tabla de obras. Utilizando campos de registro vinculados, podría entonces configurarlo de manera que cada registro de la tabla de obras esté vinculado a un registro de museo, y cada registro de la tabla de museos esté vinculado a uno o más registros de la tabla de obras.
A menudo tendrá sentido tener las dos mitades de una relación uno a muchos en tablas separadas, pero cuando todas las entidades de la relación son de la misma clase, puede tener más sentido utilizar una tabla autovinculante. Por ejemplo, digamos que tiene un directorio de la empresa con los nombres de todos los empleados: quiere modelar las relaciones entre los gerentes y sus subordinados, dado que cada gerente maneja muchos empleados y cada empleado tiene un solo gerente. Para ello, podrías crear campos de registro vinculados y autovinculados para el gerente y los subordinados de cada individuo.
Aquí hay otros ejemplos de relaciones de uno a muchos:
Muchos-a-muchos
Por último, las entidades también pueden tener una relación muchos-a-muchos. Digamos que tiene una lista de libros, y una lista de autores-cada libro puede tener uno o más autores, y cada autor puede haber escrito múltiples libros. En este caso, tiene muchos libros relacionados con muchos autores. En Airtable, representar la relación entre estas dos listas de entidades es tan sencillo como crear dos tablas y crear campos de registro vinculados.
En Airtable, representar una simple relación de muchos a muchos entre dos listas de entidades es tan sencillo como representar una relación de uno a muchos. Con los campos de registro vinculados, puede configurarlo de manera que cada registro de la tabla de libros esté vinculado a uno o más registros de autores, y cada registro de la tabla de autores esté vinculado a uno o más registros de la tabla de libros.
Al igual que con las relaciones de uno a uno y de uno a muchos, hay ocasiones en las que tiene sentido representar las relaciones de muchos a muchos en una única tabla autovinculante, como cuando todas las entidades son de la misma clase. Supongamos que quiere hacer un seguimiento de las amistades dentro de un grupo de personas. Cada persona puede tener muchos amigos y, a su vez, cada uno de esos amigos puede tener muchos otros amigos. Podrías hacer un seguimiento de esta relación de muchos a muchos en una sola tabla con un campo de registro autoenlazado.
Aquí hay otros ejemplos de relaciones de muchos a muchos:
Relaciones de muchos a muchos y tablas de unión
A menudo, representar una relación de muchos a muchos en Airtable es tan fácil como unir dos tablas. Sin embargo, en algunas situaciones, no sólo necesita saber que existe una relación entre dos entidades, sino que también necesita poder expresar y almacenar otra información sobre esa relación. En estos casos, tendrá que crear una tercera tabla, denominada tabla de unión (o join). Puede pensar en la tabla de unión como un lugar para almacenar los atributos de las relaciones entre dos listas de entidades.
Ejemplo 1: Estudiantes y clases
Si esto suena abstracto, veamos un ejemplo concreto: Suponga que tiene una lista de estudiantes y una lista de clases. Hay una relación muchos-a-muchos entre los estudiantes y sus clases, ya que cada estudiante puede tomar múltiples clases, y cada clase puede tener múltiples estudiantes inscritos. Podrías hacer una tabla de estudiantes y una tabla de clases, enlazarlas y dejarlas así. ¿Pero qué pasa si quieres almacenar información sobre la calificación de cada estudiante en la clase? ¿O el semestre en el que el estudiante tomó la clase? ¿Pones esta información en la tabla de estudiantes, o en la tabla de clases?
Las calificaciones de los estudiantes en sus clases y los tiempos en los que tomaron las clases pueden considerarse atributos de las relaciones entre los estudiantes y las clases en las que se inscribieron. Dado que las relaciones tienen cada una sus propias listas de información relevantes, la mejor manera de proceder es haciendo una tabla de unión.
Construyamos esta tabla de unión paso a paso. Digamos que ya tienes una tabla de alumnos y otra de clases.
Podemos hacer una nueva tabla que tenga un campo vinculado a los alumnos y otro a las clases. Podríamos llamar a la tabla «Grades», «Enrollment», «Students/Classes», o lo que nos ayude a recordar que esta tabla es una tabla de unión entre las tablas Students y Classes.
Todavía tenemos que rellenar el campo primario de esta tabla de unión. Una de las mejores formas de nombrar los registros en una tabla de unión es utilizar una fórmula, que toma datos de otros campos de la tabla para componer un nombre único para cada registro. Esto puede ser especialmente útil para una tabla de unión, ya que a menudo los registros que representan las relaciones entre conceptos no se prestan especialmente bien a un único campo primario. La información relevante para la relación de cada estudiante con una clase (como la calificación, o el semestre en el que se tomó una clase) también se puede poner en esta tabla.
Si volvemos a las tablas Estudiantes o Clases, veremos que se han creado automáticamente nuevos campos vinculados a la tabla de unión. Puede crear campos de rollup o lookup en estas tablas para extraer automáticamente la información de la tabla de unión en las tablas Estudiantes o Clases.
Ejemplo 2: Solicitantes y entrevistadores
Aquí hay otro ejemplo de cuándo querría utilizar una tabla de unión: Tienes una lista de solicitantes de empleo, y una lista de entrevistadores. Cada solicitante pasa por múltiples entrevistas con diferentes entrevistadores, y cada entrevistador realiza múltiples entrevistas con diferentes solicitantes. La entrevista puede considerarse como la relación entre un solicitante y un entrevistador, y como tal necesitaríamos una tabla de unión para almacenar información sobre cada entrevista.
Ejemplo 3: Clientes, pedidos de clientes, productos y fabricantes
Aquí tienes un ejemplo más complejo. Supongamos que quieres hacer una base de Airtable organizando tus listas de clientes y sus pedidos, y de productos y sus fabricantes. Cada cliente puede hacer muchos pedidos, pero cada pedido sólo está asociado a un cliente:
De forma similar, cada fabricante puede hacer muchos productos, pero cada producto sólo puede tener un fabricante:
Cada pedido de cliente puede tener muchos productos, y cada producto puede formar parte de muchos pedidos de clientes:
El problema aquí, sin embargo, es que no hay un buen lugar para almacenar información sobre la cantidad de cada producto en el pedido particular de un cliente. La solución es hacer una tabla de unión entre las tablas de pedidos de clientes y productos, que podemos llamar tabla de partidas de pedidos.
Aquí tienes un ejemplo de cómo quedaría en una base Airtable. La tabla de clientes está vinculada a la tabla de pedidos de clientes:
La tabla de pedidos de clientes está vinculada a la tabla de clientes y a la tabla de partidas de pedidos:
La tabla de partidas de pedido toma los enlaces de la tabla de productos y de la tabla de pedidos de clientes, y la cantidad de cada producto, para crear valores de campo primario únicos para cada una de las líneas.
La tabla de productos está vinculada a las líneas de pedido y a los fabricantes:
Y la tabla de fabricantes está vinculada a la tabla de productos en una relación de uno a muchos.
Campos calculados y tablas de unión
Cuando se tienen tantos campos vinculados, es importante utilizar los campos de búsqueda y rollup en beneficio propio para minimizar la cantidad de entrada de datos que hay que realizar.
Supongamos que quiere tener un campo en la tabla de pedidos de clientes que calcule automáticamente el coste total del pedido de un cliente individual. Para ello, extraería la información de la tabla de productos sobre el coste por unidad en la tabla de partidas del pedido utilizando un campo de búsqueda.
Entonces, con una fórmula, podría calcular el coste total por partida.
Y por último, puede utilizar un campo rollup en la tabla de pedidos de clientes para sumar todo el coste total de todas las partidas del pedido de cualquier cliente.
