Forum Discussion

Syndicate_Admin's avatar
Syndicate_Admin
Icon for Administrator rankAdministrator
9 months ago

dimensiones degeneradas

Estoy leyendo la documentación de MS sobre modelado de datos y me confundí acerca de las dimensiones degeneradas. Básicamente, MS dice que si solo hay una columna en la tabla de dimensiones y esta columna (por ejemplo, el identificador del pedido de ventas) existe en la tabla de hechos, es mejor eliminar la tabla de dimensiones del identificador del pedido de ventas y filtrar la tabla de hechos utilizando el identificador del pedido de ventas en la propia tabla de hechos (https://learn.microsoft.com/en-us/power-bi/guidance/star-schema#junk-dimensions).

"Una dimensión degenerada hace referencia a un atributo de la tabla de hechos que se requiere para el filtrado. En Adventure Works, el número de pedido de ventas del revendedor es un buen ejemplo. En este caso, no tiene sentido crear una tabla independiente que conste solo de esta columna porque aumentaría el tamaño de almacenamiento del modelo y daría lugar a un desorden en el panel de datos.

En el modelo semántico de Power BI, puede ser adecuado agregar la columna número de pedido de ventas a la tabla de hechos para permitir el filtrado o la agrupación por número de pedido de ventas. Es una excepción a la regla introducida anteriormente de que no debe mezclar tipos de tablas (generalmente, las tablas modelo deben ser de dimensión o de hecho)".

¿Está esto realmente bien? Durante mucho tiempo he pensado que cualquier campo de categoría utilizado para filtrar o agrupar debe provenir de una tabla de dimensiones para: reducir el tamaño del modelo y simplificar el cálculo, evitar errores de existencia automática (https://www.sqlbi.com/articles/understanding-dax-auto-exist/). Pero esta documentación de MS parece romper esta regla de oro.

12 Replies

  • @Jeanxyz ,

    Este es un caso de uso muy específico en el que la tabla de pedidos de ventas no es una dimensión en sí misma porque agrega valores del pedido de ventas que le permitirán recoger datos para las fechas, el cliente, etc., que se conectarían a otras tablas de dimensiones, por lo que al final necesitaría tener un modelo de Snowflake con las ventas conectadas al pedido de ventas y el pedido de ventas conectado a las otras dimensiones.

    En este caso, debe pasar todos los atributos a la tabla de hechos y generar un esquema en estrella y, dado que la columna de pedido de ventas es una sola columna en ese modelo, puede filtrar directamente desde la tabla de hechos.

  • Hola @Jeanxyz, una dimensión degenerada se aplica específicamente cuando el campo produciría una dimensión con una relación 1:1 con su hecho, donde la dimensión solo contiene esa única columna.

    En ese caso, la creación de una dimensión independiente no agrega ningún valor analítico. Acabaría con una tabla que refleja la clave de la tabla de hechos, lo que también aumenta el tamaño del modelo y agrega una relación innecesaria. Power BI tendría que filtrar a través de una combinación, solo para devolver exactamente los mismos datos que obtendría al usar la columna directamente desde la tabla de hechos.

    • Syndicate_Admin's avatar
      Syndicate_Admin
      Icon for Administrator rankAdministrator

      La verdadera pregunta es ¿por qué necesitamos tablas de dimensiones en primer lugar? ¿Está diciendo que la tabla de dimensiones solo se usa para eliminar duplicados de la tabla de hechos? ¿Qué tal la autoexistencia?

      • Syndicate_Admin's avatar
        Syndicate_Admin
        Icon for Administrator rankAdministrator

        Hola @Jeanxyz .

        Principalmente eventos / transacciones de almacenamiento de hechos como cantidades, cantidades y clics, por ejemplo. mientras que las dimensiones almacenan los atributos con los que filtra / segmenta y analiza por tiendas similares, nombres de productos, nombres de clientes.

        Entonces, en lugar de dejar el nombre de la tienda, el nombre del cliente y atributos como edad, sexo, correo electrónico. Crea una tabla de dimensiones que almacena todas las columnas del cliente y tiene una clave de columna.

        Y solo referenciar la clave en el hecho para eliminar textos repetidos y así funcionar mejor y tener menos almacenamiento.

        Si mantiene estos atributos en la tabla Fact:

        • Se repiten millones de veces

        • Aumentan el tamaño del archivo

        • Ralentizan las relaciones