Modelado de datos en un almacenamiento

Sin modelado de datos, cada consumidor tiene que averiguar qué tablas se relacionan entre sí, escribir su propia lógica de agregación y adivinar el significado 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 Microsoft Fabric, se preparan los datos para que queden claros, se definen las relaciones entre tablas, se estandariza el acceso mediante vistas y medidas, y se publican modelos semánticos para la elaboración de 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 la vista del modelo, puede realizar varios pasos para mejorar la experiencia del consumidor:

• Ocultar objetos internos como tablas de almacenamiento provisional, columnas de clave suplente y artefactos de ETL que saturan la lista de campos.
• Cambie el nombre de las columnas para usar nombres amigables comerciales donde los nombres de las columnas del almacén sean técnicos o abreviados. Por ejemplo, cambie el nombre CustRgn a Customer Region.
• 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 Customer Region con una descripción como "Región geográfica de la dirección principal del cliente" genera mejores resultados de lenguaje natural que CustRgn sin descripción.

Con las tablas limpias y bien nombradas, está listo para definir cómo se conectan entre sí.

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 CustomerKey columna que existe en y FactSalesDimCustomer 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 en estrella, las relaciones entre hechos y dimensiones suelen ser de muchos a uno, lo que significa que muchas filas de hechos se asignan a una única fila de dimensión.
• La dirección del filtro cruzado determina la forma en que los filtros se propagan entre las tablas. La dirección única, en la que la dimensión filtra la tabla de hechos, es la configuración estándar para la mayoría de los diseños de esquemas en estrella, ya que mantiene el comportamiento del filtro predecible y eficaz.

Sin relaciones definidas, cada consumidor que desea combinar datos de diferentes tablas debe escribir la 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 a datos con vistas y medidas

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 a partir de tablas base que podrían cambiar, puede dirigir los informes a vistas que presenten 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 usuario use 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 medidas cubren ambos lados del consumo: las vistas normalizan cómo los consumidores de T-SQL acceden a los datos y los consultan, mientras que las medidas normalizan 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 el almacenamiento y la sobrecarga de procesamiento al mantener una copia independiente de los datos.