Modelado de datos en un almacenamiento

Sin modelado de datos, cada consumidor tiene que determinar qué tablas están relacionadas entre sí, crear su propia lógica de agregación y adivinar los significados de las columnas. El modelado de datos resuelve este problema mediante la inserción de la estructura, la lógica de negocios y la documentación directamente en el almacenamiento. En un almacén de Microsoft Fabric, preparará los datos para claridad, definirá relaciones entre tablas, normalizará acceso a través de vistas y medidas y publicará modelos semánticos para los informes. Estas opciones de modelado afectan a cada experiencia de nivel inferior, incluidas las consultas de T-SQL, los informes de Power BI y el análisis de lenguaje natural controlado por ia.

Preparación de los datos para el consumo

Antes de definir relaciones o agregar cálculos, debe depurar lo que ven los usuarios. Las tablas de almacenamiento sin procesar suelen contener tablas de almacenamiento provisional, columnas de clave suplentes y marcas internas diseñadas para el procesamiento de ETL, no para el análisis. Estos objetos crean ruido cuando los consumidores examinan los datos. Preparar el almacén para el consumo significa mostrar solo lo que es relevante y hacer que sea comprensible.

En vista de modelo, puede seguir algunos pasos para mejorar la experiencia del consumidor:

• Ocultar objetos internos como tablas de almacenamiento provisional, columnas de clave suplente y artefactos ETL que desordenan la lista de campos.
• Renombre las columnas para utilizar nombres fáciles de entender en ámbito empresarial, en aquellos casos donde los nombres de las columnas del almacén sean técnicos o abreviados. Por ejemplo, cambie el nombre a .
• Agregue descripciones a tablas y columnas para que los consumidores comprendan lo que representan los datos sin hacer referencia a documentación externa.

Estos pasos importan más allá del simple orden. Copilot, presente en los agentes de datos de Power BI y Fabric IQ, se basa en nombres de tabla, nombres de columna y descripciones para interpretar preguntas de lenguaje natural y generar SQL o DAX precisos. Una columna denominada con una descripción como "Región geográfica de la dirección principal del cliente" genera mejores resultados de lenguaje natural que sin descripción.

Con tablas bien organizadas y correctamente nombradas en su lugar, está listo para definir cómo se conectan unas con otras.

Descripción de las relaciones entre tablas

Una relación es una conexión lógica entre dos tablas que permite filtrar, agrupar y agregar entre esas tablas. En un esquema de estrella, las relaciones conectan tablas de hechos a tablas de dimensiones a través de columnas de clave compartidas.

Por ejemplo, una columna que existe en y establece el vínculo que permite el análisis de ventas por atributos de cliente, como región, segmento o tipo de cuenta.

Cada relación tiene dos propiedades importantes.

• La cardinalidad describe cómo se corresponden las filas de las dos tablas. En un esquema de estrella, las relaciones de hechos a dimensiones suelen ser de muchos a uno, lo que significa que muchas filas de hechos se asignan a una sola fila de dimensión.
• La dirección del filtro cruzado determina la forma en que los filtros se propagan entre las tablas. Unidireccional, donde la dimensión filtra la tabla de datos, es la configuración estándar para la mayoría de los diseños de esquema de estrella porque mantiene el comportamiento del filtro predecible y con buen rendimiento.

Sin relaciones definidas, cada consumidor que quiere combinar datos a través de tablas debe escribir una lógica de "JOIN" explícita. Las relaciones eliminan esa repetición mediante la codificación de la conexión una vez. Al crear un modelo semántico a partir del almacenamiento, estas relaciones informan sobre cómo los agentes de datos de Power BI, Copilot y Fabric IQ interpretan los datos. Los agentes de datos, por ejemplo, usan relaciones para generar combinaciones precisas al traducir preguntas de lenguaje natural en SQL.

Estandarizar el acceso de datos con vistas y mediciones

Ahora que las tablas están limpias y conectadas, el siguiente paso es proporcionar a los consumidores formas confiables y coherentes de consultar y calcular los datos. Sin estandarización, cada equipo escribe su propia lógica de combinación, aplica sus propios filtros y define sus propias fórmulas, lo que conduce a resultados en conflicto.

Las vistas proporcionan esta coherencia para los consumidores de T-SQL. Una vista encapsula la lógica de combinación, los filtros y las selecciones de columna en una consulta reutilizable a la que hacen referencia los consumidores como una tabla. Por ejemplo, una vista que combina tablas de hechos y dimensiones, filtra los pedidos completados y expone solo las columnas que los analistas necesitan proporcionan a cada T-SQL consumer un punto de partida confiable. Las vistas también sirven como orígenes de datos estables para los informes. En lugar de crear informes directamente en tablas base que pueden cambiar, puede orientar los informes hacia vistas que presentan una forma coherente.

Las medidas proporcionan la misma coherencia para los cálculos DAX. Una medida es una expresión DAX reutilizable que define un cálculo como un total, un promedio, una relación o un recuento. Para crear medidas directamente en la vista modelo de almacenamiento, seleccione una tabla y agregue una nueva medida. Por ejemplo, una medida Total Sales que suma la columna SalesAmount garantiza que cada consumidor utilice el mismo cálculo.

Dado que la definición de medida reside con los datos, se convierte en la única fuente de verdad para esa métrica. Cuando la empresa cambia la forma en que calcula los ingresos, actualiza la medida en un solo lugar en lugar de realizar un seguimiento de cada informe que contiene su propia fórmula.

Juntas, las vistas y las mediciones cubren ambos lados del consumo: las vistas estandarizan cómo los consumidores de T-SQL acceden y consultan datos, mientras que las mediciones estandarizan cómo aparecen los cálculos empresariales en informes y paneles.

Creación de un modelo semántico para informes de Power BI

Con las tablas preparadas, las relaciones definidas y las vistas y medidas estandarizadas establecidas, el almacén está listo para los informes posteriores. Los equipos que consultan el almacenamiento directamente mediante T-SQL o que se conectan a través de herramientas de terceros pueden trabajar con el modelo de almacenamiento as-is. Sin embargo, cuando quiera crear informes y paneles interactivos de Power BI, la creación de un modelo semántico es el siguiente paso.

Los modelos semánticos creados a partir de un almacén de Fabric usan el modo Direct Lake. A diferencia del modo de importación tradicional, que copia los datos en la memoria de Power BI, Direct Lake lee los datos directamente desde los archivos De OneLake Parquet. Esto significa que los informes reflejan los datos de almacenamiento más recientes sin necesidad de actualizaciones programadas. También significa que evita la sobrecarga de almacenamiento y procesamiento de mantener una copia independiente de los datos.

Captura de pantalla de un informe de Power BI.