Instrucciones para relaciones uno a uno
Este artículo está dirigido a ti, como modelador de datos que trabaja con Power BI Desktop. Proporciona instrucciones sobre cómo trabajar con relaciones de modelo de uno a uno. Se puede crear una relación uno a uno cuando ambas tablas contienen una columna de valores comunes y únicos.
Nota
En este artículo no se incluye una introducción a las relaciones de modelo. Si no está familiarizado con las relaciones, sus propiedades o cómo configurarlas, se recomienda que primero lea el artículo Relaciones de modelos en Power BI Desktop.
También es importante que conozca el diseño del esquema de estrella. Para más información, vea Descripción de un esquema de estrella e importancia para Power BI.
Hay dos escenarios que implican relaciones uno a uno:
Degenerar dimensiones: Se puede derivar una dimensión degenerada a partir de una tabla de hechos.
Los datos de fila se distribuyen entre las tablas: una sola entidad de negocio o asunto se carga como dos (o más) tablas de modelo, posiblemente porque sus datos provienen de almacenes de datos diferentes. Este escenario puede ser común para tablas de dimensiones. Por ejemplo, los detalles de los productos maestros se almacenan en un sistema de ventas operativo y los detalles adicionales de los productos se almacenan en un origen diferente.
Sin embargo, es inusual que relacione dos tablas de hechos con una relación uno a uno. Esto se debe a que ambas tablas de hechos necesitarían tener la misma dimensionalidad y granularidad. Además, cada tabla de hechos necesitaría columnas únicas para permitir que se cree la relación del modelo.
Dimensiones degeneradas
Cuando se usan columnas de una tabla de hechos para filtrar o agrupar, puede considerar la posibilidad de que estén disponibles en una tabla independiente. De este modo, se separan las columnas usadas para filtrar o agrupar de esas columnas usadas para resumir las filas de hechos. Esta separación puede:
- Reduzca el espacio de almacenamiento.
- Simplifique los cálculos del modelo.
- Contribuir a mejorar el rendimiento de las consultas.
- Ofrezca una experiencia de panel de datos más intuitiva a los autores de informes.
Considere una tabla de origen denominada Sales
que almacena los detalles de referencia de líneas de órdenes de venta en dos columnas.
La columna OrderNumber
almacena el número de pedido y la columna OrderLineNumber
almacena una secuencia de líneas dentro del orden.
En la imagen siguiente, observe que las columnas de número de pedido y número de línea de pedido no se han cargado en la tabla Sales
. En cambio, sus valores se usaron para crear una columna de clave sustituta denominada OrderLineNumberID
. (El valor clave se calcula multiplicando el número de pedido por 1000 y luego agregando el número de línea de pedido).
La tabla de dimensiones Sales Order
proporciona una experiencia enriquecida para los autores de informes con dos columnas: Sales Order
y Sales Order Line
. Estas columnas concretas soportan diseños de informe que necesitan filtrar, agrupar o explorar en profundidad pedidos y líneas de pedidos.
Dado que la tabla Sales Order
se deriva de los datos de ventas, debe haber exactamente el mismo número de filas en cada tabla. Además, debe haber valores coincidentes entre cada columna de OrderLineNumberID
.
Los datos de fila se distribuyen entre las tablas
Considere un ejemplo que implica dos tablas de dimensiones relacionadas de uno a uno: Product
y Product Category
. Cada tabla representa los datos importados y tiene una columna SKU
(unidad de mantenimiento de existencias) que contiene valores únicos.
Aquí hay un diagrama de modelos parcial de las dos tablas.
La primera tabla se denomina Product
y contiene tres columnas: Color
, Product
y SKU
. La segunda tabla se denomina Product Category
y contiene dos columnas: Category
y SKU
. Una relación uno a uno asocia las dos columnas SKU
. La relación se filtra en ambas direcciones, que es siempre el caso de las relaciones uno a uno.
Para ayudar a describir cómo funciona la propagación del filtro de relación, la siguiente imagen muestra algunas filas de tabla. Todos los ejemplos de este artículo se basan en estos datos.
Los detalles de las filas de las dos tablas se describen en la siguiente lista con viñetas:
- La tabla
Product
tiene tres filas:SKU
CL-01,Product
T-shirt,Color
GreenSKU
CL-02,Product
Jeans,Color
BlueSKU
AC-01,Product
Hat,Color
Blue
- La tabla
Product Category
tiene dos filas:SKU
CL-01,Category
ClothingSKU
AC-01, accesoriosCategory
Observe que la tabla Product Category
no incluye una fila para la SKU del producto CL-02. Discutiremos las consecuencias de esta fila ausente más adelante en este artículo.
En el panel de datos , los autores de informes encuentran campos relacionados con el producto en dos tablas: Product
y Product Category
. Veamos qué sucede cuando los campos de ambas tablas se agregan a un objeto visual de tabla. En este ejemplo, la columna SKU
se obtiene de la tabla Product
.
Observe que el valor de Category
para la SKU del producto CL-02 es BLANK. Esto se debe a que no hay ninguna fila correspondiente en la tabla Product Category
para este producto.
Recomendaciones
Cuando sea posible, le recomendamos que evite crear relaciones de modelo uno a uno cuando los datos de fila se distribuyan entre tablas de modelos. Esto se debe a que este diseño puede:
- Contribuye al desorden del panel Datos, enumerando más tablas de las necesarias.
- Dificulta que los autores de informes encuentren campos relacionados, ya que se distribuyen entre varias tablas.
- Limite la capacidad de crear jerarquías, ya que sus niveles deben basarse en columnas de la misma tabla.
- Genera resultados inesperados cuando no hay una coincidencia completa de filas entre las tablas.
Las recomendaciones específicas difieren dependiendo de si la relación uno a uno es intragrupo de origen o entre grupos de origen. Para obtener más información sobre la evaluación de relaciones, consulte Relaciones de modelo en Power BI Desktop.
Relación uno a uno intragrupo de origen
Cuando existe una relación uno a uno intragrupo de origen entre las tablas, recomendamos consolidar los datos en una sola tabla de modelo. Para ello, puede combinar las consultas de Power Query.
Los pasos siguientes presentan una metodología para consolidar y modelar los datos relacionados uno a uno.
Combinar consultas: al combinar las dos consultas, tenga en cuenta la integridad de los datos en cada consulta. Si una consulta contiene un conjunto completo de filas (como una lista maestra), combine la otra consulta con ella. Configure la transformación de combinación para usar una combinación externa izquierda, que es el tipo de combinación predeterminado. Este tipo de combinación garantiza que mantendrá todas las filas de la primera consulta y las complementará con las filas coincidentes de la segunda consulta. Expanda todas las columnas requeridas de la segunda consulta en la primera consulta.
Deshabilitar la carga de consultas: asegúrese de deshabilitar la carga de la segunda consulta. De esta manera, no cargará su resultado como una tabla modelo. Esta configuración reduce el tamaño de almacenamiento del modelo de datos y ayuda a despejar el panel Datos.
En nuestro ejemplo, los autores de informes ahora encuentran una sola tabla denominada
en el panel de Datos de . Contiene todos los campos relacionados con el producto. Reemplazar los valores que faltan: si la segunda consulta tiene filas no coincidentes, los valores NULL aparecen en las columnas introducidas a partir de ella. Cuando corresponda, considere la posibilidad de reemplazar valores NULL por un valor de token. El reemplazo de los valores que faltan es especialmente importante cuando los autores de informes filtran o agrupan por los valores de la columna, ya que los valores EN BLANCO podrían aparecer en los objetos visuales del informe.
En la imagen siguiente, observe que la categoría de la SKU del producto CL-02 ahora lee [Sin definir]. En la consulta, las categorías nulas se reemplazaron por este valor de texto de token.
Crear jerarquías: si existen relaciones entre las columnas de la tabla ahora consolidada, puede ser recomendable crear jerarquías. De esta forma, los autores de informes identificarán rápidamente las oportunidades para informar de la exploración de objetos visuales.
En nuestro ejemplo, los autores de informes ahora pueden usar una jerarquía que tenga dos niveles:
Category
yProduct
.
Si le gusta cómo las tablas independientes ayudan a organizar sus campos, todavía le recomendamos consolidar en una sola tabla. Todavía puede organizar sus campos, pero utilizando carpetas para mostrar.
En nuestro ejemplo, los autores de informes pueden encontrar el campo Category
dentro de la carpeta de visualización Marketing
.
Si de todas formas decide definir relaciones uno a uno intragrupo de origen en su modelo, cuando sea posible, asegúrese de que haya filas coincidentes en las tablas relacionadas. Como una relación uno a uno intragrupo de origen se evalúa como una relación normal, podrían surgir problemas de integridad de datos en los objetos visuales del informe como espacios en blanco. (Puede ver un ejemplo de una agrupación EN BLANCO en el primer objeto visual de la tabla presentado en este artículo).
Relación uno a uno entre grupos de origen
Cuando existe una relación uno a uno entre grupos de origen entre las tablas, no hay un diseño de modelo alternativo, a menos que consolide previamente los datos en los orígenes de datos. Power BI evaluará la relación del modelo uno a uno como una relación limitada. Por lo tanto, tenga cuidado de asegurarse de que haya filas coincidentes en las tablas relacionadas, ya que las filas no coincidentes se eliminan de los resultados de la consulta.
Ahora se verá qué sucede cuando los campos de las dos tablas se agregan a un objeto visual de tabla y existe una relación limitada entre las tablas.
El primer objeto visual de tabla, que usa una relación de grupo entre orígenes, muestra solo dos filas. Falta la SKU del producto CL-02 porque no hay ninguna fila coincidente en la tabla Product Category
. El segundo objeto visual de tabla, basado en una sola tabla consolidada del modelo, muestra tres filas.
Contenido relacionado
Para obtener más información sobre este artículo, consulte los recursos siguientes: