Cuando empiezas a trabajar con Microsoft Dataverse, uno de los conceptos que más cuesta entender al principio es el de las relaciones entre tablas.
Puedes crear tablas, columnas, formularios y aplicaciones sin demasiada dificultad, pero llega un momento en el que necesitas conectar la información.
Por ejemplo:
Tengo una tabla de empleados.
Tengo otra tabla con los materiales que la empresa entrega a esos empleados.
Y necesito saber rápidamente qué materiales tiene asignados cada persona.
Podría repetir el nombre, correo electrónico y demás información del empleado dentro de cada registro de material.
Pero esa no sería una buena forma de diseñar los datos.
Lo correcto es relacionar las tablas.
En esta guía voy a explicarte qué son las relaciones entre tablas en Dataverse, cómo funcionan las columnas Lookup y cuándo utilizar relaciones uno a muchos, muchos a uno o muchos a muchos.
¿Qué son las relaciones entre tablas en Dataverse?
Las relaciones permiten conectar registros almacenados en diferentes tablas.
Su objetivo es evitar que tengamos que repetir constantemente la misma información y permitir que los datos formen parte de una estructura organizada.
Imagina que tengo una tabla llamada:
Empleado
con estas columnas:
- ID del empleado;
- nombre;
- departamento;
- correo electrónico.
Y otra tabla llamada:
Material entregado
con información como:
- equipo;
- número de serie;
- fecha de entrega;
- estado.
Si un empleado recibe cinco materiales diferentes, no necesito copiar cinco veces su nombre, correo y departamento dentro de la tabla de materiales.
Creo una relación.
De esta forma, cada registro de material puede apuntar al empleado correspondiente.
Este diseño reduce duplicación y ayuda a mantener la información más consistente, una idea relacionada con la normalización de datos que aparece en el documento original.
¿Por qué no guardar toda la información en una única tabla?
Al principio puede parecer más sencillo.
Imaginemos una tabla como esta:
| Empleado | Departamento | Material | Número de serie |
|---|---|---|---|
| Ana | Administración | Portátil | P001 |
| Ana | Administración | Monitor | M025 |
| Ana | Administración | Teléfono | T130 |
Estamos repitiendo los datos de Ana en cada fila.
Ahora imaginemos que Ana cambia de departamento.
Tendríamos que modificar varios registros.
Y si olvidamos actualizar uno, acabaremos con información contradictoria.
En cambio, si tenemos una tabla Empleado y otra tabla Material, los datos personales se almacenan una sola vez.
Los materiales simplemente quedan relacionados con ese registro.
Si modificamos el departamento de Ana, el cambio se realiza una única vez.
Ese es uno de los grandes beneficios de trabajar correctamente con relaciones.
¿Cómo se conectan las tablas en Dataverse?
Cada tabla de Dataverse tiene una clave primaria, que identifica de forma única cada fila o registro.
Normalmente nosotros vemos columnas descriptivas como:
Ana Pérez
pero internamente Dataverse necesita una forma inequívoca de saber qué registro concreto estamos utilizando.
Para relacionar una tabla con otra utilizamos habitualmente una columna de búsqueda o Lookup.
Microsoft explica que crear una nueva columna Lookup establece una relación muchos-a-uno entre la tabla donde estamos trabajando y la tabla a la que hacemos referencia.
Pensemos nuevamente en:
Empleado
y
Material entregado
Dentro de la tabla Material entregado puedo crear una columna:
Empleado
de tipo Lookup.
Ese campo no contiene simplemente un texto como «Ana Pérez».
Está apuntando al registro real de Ana dentro de la tabla Empleado.
Esto es muy importante.
Un Lookup no es lo mismo que escribir el nombre de otra entidad como texto.
¿Qué es una columna Lookup en Dataverse?
Una columna Lookup permite seleccionar un registro de otra tabla.
Por ejemplo, dentro de Material entregado puedo encontrar algo parecido a:
Empleado asignado: Ana Pérez
Visualmente veo el nombre de Ana.
Pero detrás de esa selección existe una relación con su registro dentro de la tabla Empleado.
Gracias a eso puedo posteriormente acceder a otra información asociada a ese empleado.
Por ejemplo:
- departamento;
- correo;
- responsable;
- ubicación;
- materiales entregados.
Microsoft confirma que, en una relación uno-a-muchos, la columna Lookup se crea en la tabla relacionada o lado «muchos».
Este detalle nos ayuda a decidir en qué tabla debemos crear el campo Lookup.
Relaciones uno a muchos en Dataverse
La relación uno a muchos, habitualmente representada como:
1:N
significa que un registro de una tabla puede estar relacionado con varios registros de otra.
Utilicemos el ejemplo original del documento.
Tenemos:
Tabla Empleado
y
Tabla Material entregado
Un único empleado puede recibir varios materiales.
Por ejemplo:
Ana → Portátil
Ana → Monitor
Ana → Teléfono
Aquí tenemos:
1 empleado → muchos materiales
Por tanto, desde la perspectiva de Empleado hacia Material tenemos una relación:
1:N
Microsoft define precisamente las relaciones 1:N como relaciones donde una fila de la tabla principal puede estar asociada con múltiples filas de la tabla relacionada.
Relaciones muchos a uno en Dataverse
Aquí aparece una de las confusiones más habituales.
Una relación 1:N y una relación N:1 no son dos estructuras completamente diferentes.
Muchas veces estamos hablando de la misma relación observada desde lados distintos.
Volvamos al ejemplo.
Desde Empleado puedo decir:
Un empleado puede tener muchos materiales.
Eso es:
Empleado 1:N Material
Pero desde Material puedo decir:
Muchos materiales pueden pertenecer a un empleado.
Eso es:
Material N:1 Empleado
Microsoft refleja exactamente esta dualidad en Dataverse al hablar de relaciones one-to-many y many-to-one.
Yo suelo explicarlo así:
1:N = estoy mirando desde el padre hacia los hijos.
N:1 = estoy mirando desde los hijos hacia el padre.
¿Dónde creo el Lookup en una relación 1:N?
Esta es una pregunta muy práctica.
Si tenemos:
Empleado 1:N Material entregado
¿Dónde debería estar el Lookup?
En Material entregado.
¿Por qué?
Porque cada material necesita indicar a qué empleado está relacionado.
Por tanto, dentro de Material puedo crear:
Empleado asignado → Lookup a Empleado
Desde la perspectiva de Material tenemos:
N:1
Muchos registros de material pueden apuntar a un único empleado.
Microsoft especifica que cuando se crea una relación uno-a-muchos, el lookup queda en la tabla relacionada; si queremos que el lookup aparezca en la tabla que estamos editando, debemos crear una relación muchos-a-uno.
Ejemplo práctico: empleados y materiales
Podemos representarlo así:
Empleado
| ID | Nombre |
|---|---|
| E001 | Ana |
| E002 | Pedro |
Material entregado
| Material | Empleado |
|---|---|
| Portátil | Ana |
| Monitor | Ana |
| Teléfono | Pedro |
Ana existe una sola vez dentro de la tabla Empleado.
Pero dos materiales están relacionados con su registro.
Desde Ana podemos consultar:
- Portátil.
- Monitor.
Y desde el registro del portátil podemos saber inmediatamente:
- qué empleado lo tiene;
- qué información está asociada a ese empleado.
Esto es mucho mejor que repetir todos los datos personales del trabajador dentro de cada fila.
Relaciones muchos a muchos en Dataverse
Existe otro escenario completamente diferente.
Supongamos que tenemos:
Proyecto
y
Empleado
Un empleado puede participar en varios proyectos.
Al mismo tiempo, un proyecto puede tener varios empleados.
Por ejemplo:
Ana → Proyecto A
Ana → Proyecto B
Pedro → Proyecto A
Laura → Proyecto A
Laura → Proyecto C
No podemos representar correctamente este escenario utilizando únicamente una relación uno-a-muchos.
Necesitamos una relación:
N:N
o
muchos a muchos.
El ejemplo procede directamente del documento original: un empleado puede participar en varios proyectos y cada proyecto puede tener varios empleados.
¿Cómo funciona una relación muchos a muchos?
En una relación N:N necesitamos almacenar qué registros están asociados.
Dataverse utiliza para ello una tabla de relación o tabla de intersección.
Microsoft explica que esta tabla almacena los valores necesarios para asociar los registros de ambas tablas.
Conceptualmente podemos imaginar algo así:
Empleado
| ID | Nombre |
|---|---|
| E001 | Ana |
| E002 | Pedro |
Proyecto
| ID | Proyecto |
|---|---|
| P001 | Proyecto A |
| P002 | Proyecto B |
Y entre ellas una relación que registra asociaciones como:
| Empleado | Proyecto |
|---|---|
| Ana | Proyecto A |
| Ana | Proyecto B |
| Pedro | Proyecto A |
Así conseguimos que cada empleado pueda aparecer en diferentes proyectos y cada proyecto pueda contener diferentes empleados.
La tabla intermedia de Dataverse
Aquí hay un detalle técnico importante.
Cuando utilizamos una relación N:N nativa de Dataverse, existe una tabla de intersección administrada por la plataforma.
Microsoft indica que esta tabla contiene la información necesaria para mantener las asociaciones y no está pensada como una tabla normal donde añadimos libremente columnas personalizadas.
Esto importa mucho cuando necesitamos guardar información adicional sobre la relación.
Imaginemos:
Empleado ↔ Proyecto
pero además quiero almacenar:
- función del empleado dentro del proyecto;
- fecha de incorporación;
- horas asignadas;
- porcentaje de dedicación.
En ese escenario ya no quiero almacenar solamente que:
Ana está relacionada con Proyecto A.
Quiero almacenar información acerca de esa participación concreta.
Cuando una relación N:N necesita datos adicionales
Aquí aparece un patrón muy útil.
En lugar de utilizar simplemente una relación muchos-a-muchos automática, podemos crear nuestra propia tabla intermedia.
Por ejemplo:
Participación en proyecto
con columnas como:
- Empleado;
- Proyecto;
- Rol;
- Fecha de inicio;
- Horas asignadas.
Entonces podemos tener:
Empleado 1:N Participación
y
Proyecto 1:N Participación
Microsoft recomienda considerar este enfoque de relación muchos-a-muchos manual cuando necesitamos almacenar información adicional acerca de cada asociación.
Este patrón resulta especialmente importante en aplicaciones empresariales reales.
Un ejemplo todavía más claro
Supongamos que quiero construir una aplicación para cursos.
Tengo:
Alumno
y
Curso
Un alumno puede participar en varios cursos.
Un curso tiene muchos alumnos.
Eso parece una relación N:N perfecta.
Pero ahora necesito guardar también:
- fecha de inscripción;
- estado de matrícula;
- calificación;
- porcentaje completado.
Esos datos no pertenecen únicamente al alumno.
Tampoco pertenecen únicamente al curso.
Pertenecen a la relación entre ese alumno y ese curso.
Por tanto, podría crear una tabla:
Inscripción
Y entonces tendríamos:
Alumno 1:N Inscripción
Curso 1:N Inscripción
Dentro de Inscripción almacenaríamos:
Alumno → Ana
Curso → Power Apps básico
Fecha → 10/08/2026
Estado → Activo
Progreso → 65 %
Ahora tenemos un modelo mucho más flexible.
Cómo decidir qué tipo de relación necesito
Yo utilizaría una pregunta muy sencilla.
Si tengo dos tablas A y B, pregunto:
¿Un registro de A puede estar relacionado con varios registros de B?
Después:
¿Un registro de B también puede estar relacionado con varios registros de A?
Si solamente la primera respuesta es sí:
1:N
Si ambas respuestas son sí:
N:N
Por ejemplo:
Empleado → Material
¿Un empleado puede tener varios materiales?
Sí.
¿Un material concreto puede estar asignado simultáneamente a varios empleados?
Normalmente no.
Entonces:
1:N
Ahora:
Empleado → Proyecto
¿Un empleado puede participar en varios proyectos?
Sí.
¿Un proyecto puede tener varios empleados?
Sí.
Entonces:
N:N
Este pequeño ejercicio ayuda muchísimo antes de crear las tablas.
Relaciones entre tablas y normalización de datos
El documento original menciona un concepto fundamental: la normalización de datos.
La idea no consiste simplemente en dividir información entre muchas tablas.
Consiste en estructurar los datos de manera que evitemos duplicaciones innecesarias y mantengamos relaciones coherentes.
Por ejemplo, en lugar de repetir:
nombre del cliente,
correo electrónico,
teléfono,
dirección,
en cada pedido, creamos:
Cliente
y
Pedido
Después:
Cliente 1:N Pedido
Así la información del cliente existe una sola vez y sus pedidos quedan relacionados con él.
¿Por qué son útiles las relaciones en Dataverse?
El documento resume tres beneficios muy importantes.
Evitan información duplicada
Los datos principales permanecen en su tabla correspondiente.
No necesitamos copiar continuamente los mismos valores en diferentes registros.
Facilitan navegar entre información relacionada
Desde un empleado podemos consultar los materiales que tiene asignados.
Desde un cliente podemos ver sus pedidos.
Desde un proyecto podemos encontrar sus participantes.
Esto resulta especialmente potente cuando después construimos aplicaciones con Power Apps.
Mejoran la integridad y consistencia de los datos
Si el dato existe una sola vez, disminuye el riesgo de mantener varias versiones contradictorias de la misma información.
Texto frente a Lookup: un error habitual
Supongamos que tengo una tabla Pedidos.
Podría crear una columna de texto:
Cliente
y escribir:
Empresa ABC
Pero eso no establece ninguna relación real.
Es únicamente texto.
Si posteriormente el cliente cambia de nombre, puedo terminar con registros antiguos donde aparece:
Empresa ABC
y nuevos donde aparece:
Empresa ABC SL
Dataverse no sabe necesariamente que ambos textos representan exactamente al mismo cliente.
Con un Lookup, en cambio, los pedidos apuntan al registro de cliente.
Podemos cambiar el nombre visible y la relación continúa existiendo.
Este es uno de los motivos por los que comprender los Lookup cambia tanto la manera de construir aplicaciones en Dataverse.
Relaciones y Power Apps
Las relaciones cobran todavía más sentido cuando construimos una aplicación.
Imagina una aplicación para gestionar material informático.
Selecciono a un empleado.
Después quiero visualizar inmediatamente:
- portátiles asignados;
- teléfonos;
- monitores;
- accesorios.
Si las tablas están correctamente relacionadas, esa experiencia resulta mucho más sencilla de construir.
Las relaciones también permiten organizar formularios, vistas y navegación entre registros relacionados dentro del ecosistema de Power Apps y Dataverse. Microsoft mantiene las relaciones como una parte fundamental del diseño de tablas dentro de Power Apps.
Relaciones y Power Automate
La estructura también resulta útil cuando automatizamos procesos.
Por ejemplo:
cuando se asigna un material a un empleado,
Power Automate puede consultar el registro relacionado del trabajador,
obtener determinada información,
enviar una notificación,
actualizar otro sistema,
o iniciar una aprobación.
El flujo ya no depende de coincidencias de texto improvisadas.
Trabaja sobre registros relacionados dentro del modelo de datos.
Errores que recomiendo evitar
Cuando empezamos con Dataverse aparecen algunos errores recurrentes.
Duplicar información que debería estar relacionada.
Si repetimos continuamente los mismos datos, probablemente debamos revisar el diseño.
Utilizar columnas de texto cuando realmente necesitamos un Lookup.
Un nombre escrito como texto no crea una relación entre registros.
Crear N:N para todo.
No todas las relaciones necesitan ser muchos-a-muchos. A veces una estructura 1:N es más sencilla y correcta.
No pensar qué información pertenece a la relación.
Si necesitas almacenar propiedades como fecha, estado, rol o cantidad acerca de una relación N:N, probablemente necesites una tabla intermedia propia.
Empezar a crear la aplicación antes de diseñar el modelo de datos.
Yo recomiendo dibujar primero las tablas y sus relaciones.
Después construir la aplicación.
Una buena estructura de datos simplifica enormemente todo lo que viene después.
Un modelo sencillo para empezar
Antes de abrir Dataverse, puedes dibujar algo como:
Empleado
↓ 1:N
Material entregado
Y:
Empleado
↕ N:N
Proyecto
O, si necesitas información sobre la participación:
Empleado
↓ 1:N
Participación
↑ N:1
Proyecto
Este pequeño esquema puede evitar muchos problemas posteriores.
Relaciones 1:N, N:1 y N:N: resumen rápido
| Relación | Significado | Ejemplo |
|---|---|---|
| 1:N | Uno puede estar relacionado con muchos | Un empleado tiene muchos materiales |
| N:1 | Muchos pueden apuntar a uno | Muchos materiales pertenecen a un empleado |
| N:N | Muchos pueden relacionarse con muchos | Empleados participan en varios proyectos |
| Tabla intermedia propia | Relación N:N con datos adicionales | Empleado + Proyecto + Rol + Fecha |
Lo más importante es recordar que 1:N y N:1 pueden representar la misma relación observada desde perspectivas opuestas.
¿Qué relación debería utilizar en Dataverse?
No empieces preguntándote qué botón debes pulsar.
Empieza pensando en la realidad que quieres representar.
Pregúntate:
¿Qué representa cada tabla?
¿Puede existir este registro sin el otro?
¿Cuántos registros de una tabla pueden relacionarse con la otra?
¿Necesito almacenar información adicional sobre la relación?
Cuando puedes responder esas preguntas, elegir entre 1:N y N:N resulta mucho más sencillo.
Y este es uno de los aprendizajes más importantes cuando comenzamos a trabajar con Dataverse:
una buena aplicación comienza con un buen modelo de datos.
Puedes tener una interfaz espectacular y automatizaciones muy avanzadas, pero si las tablas están mal diseñadas y duplicamos información constantemente, tarde o temprano aparecerán problemas.
Por eso yo dedicaría tiempo primero a diseñar correctamente las tablas, sus Lookup y sus relaciones.
Después construiría Power Apps y Power Automate sobre esa base.
Este contenido ha sido generado o asistido por herramientas de Inteligencia Artificial, bajo la supervisión de EL PROFE OTTO.