Diseño del esquema de estrella para modelos semánticos

Ha elegido cómo fluyen los datos en el modelo semántico. Ahora diseñe el esquema de estrella que lo organiza para consultas claras y eficaces. Un esquema en estrella conecta las tablas de hechos con las tablas de dimensiones a través de relaciones, creando las rutas de filtrado de las que dependen los informes y el consumo de IA. Si estás familiarizado con la creación de un esquema de estrella en Power BI Desktop, esta unidad se centra en las decisiones de diseño de relación que son importantes a medida que los modelos crecen en complejidad y escala.

Esquema de estrella en un modelo semántico

En un esquema de estrella, las tablas de hechos almacenan eventos empresariales medibles (como transacciones de ventas, líneas de pedido y visitas web) y las tablas de dimensiones proporcionan el contexto descriptivo (como detalles del producto, información del cliente y atributos de fecha). Las tablas de dimensiones filtran las tablas de hechos a través de relaciones, lo que permite a los usuarios segmentar las métricas por cualquier atributo descriptivo.

En un modelo semántico de Fabric, este patrón proporciona propagación de filtros limpios tanto para informes como para el consumo de IA. Cuando Copilot o un agente de datos genera una consulta de lenguaje natural, un esquema de estrella bien organizado proporciona a la inteligencia artificial rutas claras de acceso a los datos correctos. Las relaciones ambiguas o circulares confunden tanto a los consumidores de informes como a las herramientas de inteligencia artificial.

Cómo afecta el modo de almacenamiento a las relaciones

Las relaciones de un modelo semántico se comportan de forma diferente en función del modo de almacenamiento. Comprender estas diferencias es esencial para diseñar el esquema de estrella que funciona bien en distintos escenarios.

Relaciones de Direct Lake

En el modo Direct Lake, el motor lee las relaciones directamente desde los metadatos de la tabla Delta. Las relaciones funcionan mejor cuando:

• Las columnas de clave de dimensión tienen una cardinalidad baja en relación con las filas de la tabla de hechos.
• La integridad referencial se mantiene en los datos de origen. Cuando se mantiene la integridad referencial, el motor usa combinaciones INNER en lugar de combinaciones LEFT OUTER, lo que mejora el rendimiento de las consultas.
• Las columnas usadas en las relaciones se indexan en las tablas delta subyacentes.

Relaciones entre fuentes

Fabric modelos semánticos pueden conectar tablas de diferentes almacenes de datos. Una tabla de hechos de un almacén de lago de datos puede tener una relación con una tabla de dimensiones de un almacén, o con una tabla a la que se accede a través de un punto de conexión de análisis SQL. Estas conexiones entre orígenes usan funcionalidades del modelo compuesto.

Cuando las tablas proceden de orígenes diferentes, el modo de almacenamiento de cada tabla determina cómo funciona la relación en el momento de la consulta. El motor resuelve cada lado de forma independiente y combina los resultados.

Tipos de relaciones

Relaciones de uno a varios

Uno a varios es el tipo de relación más común en un esquema de estrella. Un valor único de una tabla de dimensiones se relaciona con muchas filas de una tabla de hechos. Por ejemplo, una fila de producto en la dimensión Producto coincide con miles de filas de pedidos en la tabla de hechos Ventas.

Configure relaciones uno a muchos con la dirección del filtro fluyendo desde la dimensión (el lado "uno") hacia la tabla de hechos (el lado "muchos"). Este es el patrón estándar de filtro del esquema estrella.

Relaciones de varios a varios

Las relaciones de varios a varios son necesarias cuando ninguna tabla tiene valores únicos para la columna de relación. Use una tabla bridge para resolver estas relaciones. Una tabla puente se sitúa entre dos tablas y contiene combinaciones únicas de las claves de cada lado.

Por ejemplo, si un cliente puede tener varias cuentas y una cuenta puede pertenecer a varios clientes, una tabla de puente de Customer-Account resuelve la relación. La tabla puente tiene relaciones uno a muchos tanto con la tabla "Clientes" como con la tabla "Cuentas".

Dirección del filtro

En la mayoría de las implementaciones de esquemas en estrella, utilice el filtrado unidireccional de la dimensión al hecho. Esto proporciona propagación de filtros predecibles y evita ambigüedad en los resultados de la consulta.

El filtrado bidireccional a veces es necesario para las relaciones de varios a varios o cuando las tablas de dimensiones deben filtrarse por valores de la tabla de hechos. Use filtros bidireccionales con moderación porque pueden degradar el rendimiento de las consultas y crear un comportamiento de filtro inesperado en los informes.

Integridad referencial

La configuración Asumir integridad referencial indica al motor que utilice uniones INNER en lugar de uniones LEFT OUTER al realizar consultas a través de una relación. En los modos Direct Lake y DirectQuery, esta configuración puede mejorar significativamente el rendimiento porque reduce el número de filas que procesa el motor.

Habilite esta configuración cuando esté seguro de que cada valor de clave externa de la tabla de hechos tiene un valor coincidente en la tabla de dimensiones. Si se infringe la integridad referencial, las filas con claves no coincidentes desaparecen silenciosamente de los resultados de la consulta.

Relaciones inactivas y USERELATIONSHIP

Solo puede existir una relación activa entre dos tablas a la vez. Cuando necesite múltiples rutas de relación (como una fecha de pedido y una fecha de envío, ambas relacionadas con la misma dimensión Fecha), active una relación y deje las demás inactivas.

Use la USERELATIONSHIP función en DAX para activar una relación inactiva dentro de un cálculo:

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

Este patrón mantiene limpio el modelo al mismo tiempo que admite varias perspectivas analíticas en los mismos datos.

Gestión del esquema de copo de nieve en modelos semánticos

Los datos de origen a menudo llegan en un esquema de copo de nieve normalizado, donde las tablas de dimensiones se dividen en varias tablas relacionadas. Por ejemplo, una dimensión Product podría dividirse en tablas Product, Subcategory y Category, cada una vinculada a través de claves externas.

En un modelo semántico, tiene dos opciones: aplanar el esquema de copo de nieve en un esquema en estrella o conservar la estructura normalizada.

Aplanar en esquema en estrella

La aplanación significa combinar las tablas de dimensiones normalizadas en una sola tabla de dimensiones desnormalizada. La tabla Producto incluiría directamente las columnas Subcategoría y Categoría, eliminando así las tablas y relaciones adicionales.

Aplanar cuando:

• La tabla de dimensiones combinadas sigue siendo pequeña en relación con la tabla de hechos (lo cual es casi siempre el caso con las tablas de dimensiones).
• Desea rutas de filtrado más sencillas desde la dimensión hasta el hecho. Cada filtro recorre una relación en lugar de una cadena.
• El consumo de inteligencia artificial es una prioridad. Menos tablas y relaciones más sencillas proporcionan Copilot y agentes de datos rutas de acceso más claras a los datos correctos.

Aplane las tablas de dimensiones durante la preparación de datos en almacenes de lagos de datos o flujos de datos, antes de que los datos lleguen al modelo semántico. Utiliza uniones de Power Query, uniones SQL o transformaciones notebook para combinar las tablas normalizadas en una sola dimensión.

Conservación de la estructura de copos de nieve

En algunos casos, mantener la estructura normalizada tiene sentido:

• La jerarquía de dimensiones tiene varios niveles y la aplanación crearía docenas de columnas redundantes.
• Varias tablas de hechos comparten tablas de subdimensiones (como una tabla de categorías compartida que usan los hechos de ventas e inventario) y la desnormalización crearía copias incoherentes.
• La seguridad de nivel de fila debe aplicarse en un nivel específico de la jerarquía.

Al conservar una estructura de copo de nieve, configure las relaciones cuidadosamente. Cada relación en la cadena debe emplear el filtrado unidireccional desde la tabla más externa hacia la tabla de hechos para que los filtros se propaguen correctamente. Un filtro en Categoría debe pasar por Subcategoría, luego por Producto y llegar a la tabla de hechos.

Cuándo usar modelos compuestos para escenarios entre orígenes

Use modelos compuestos cuando el esquema de estrella abarque varios almacenes de datos Fabric o incluya orígenes externos. Entre los escenarios habituales se incluyen los siguientes:

• Tablas de hechos en un almacén de lago de datos con tablas de dimensiones mantenidas en un almacén.
• Datos de streaming en tiempo real de un evento combinados con datos históricos en un almacén de lago de datos.
• Datos de referencia de una fuente externa (Importación) combinados con tablas de hechos nativas de Fabric (Direct Lake).

En estos escenarios, configure el modo de almacenamiento para cada tabla de forma independiente y compruebe que las relaciones entre orígenes funcionan de forma aceptable en los volúmenes de datos esperados.