Existe un eterno dilema en cuanto a si emplear Medidas o Columnas calculadas dentro de nuestros modelos de datos... Se ha hablado y se seguirá hablando largo y tendido sobre el tema (ver artículo).
Pero la respuesta siempre será la misma: Usa las medidas siempre.
Así lo recomienda el mismo Microsoft en su documentación..., y no creo que el creador de todo esto se equivoque ;-)
Ahora bien, tampoco nos volvamos locos con este tema...
En ocasiones aporta mucho más modificar algún otro aspecto de nuestro diseño del Modelo... por ejemplo el tipo de datos de cada campo.
Veremos hoy como un sencillo cambio en el tipo de datos en nuestros campos aporta una mejora sustancial en nuestro modelo.
Para verificar esta mejora usaré la aplicación DAX Studio (https://daxstudio.org/), con una de las herramientas de análisis que ofrece: VertiPaq Analyzer Metrics Preview.
Pero antes conozcamos cuáles son estos tipos de datos.
Puedes leer algo más aquí.
En particular, nos centraremos en los formatos numéricos:
Número decimal (decimal number) - equivaldría al tipo Double clásico.
Número entero (whole number) - equivaldría al tipo Integer (Int64).
Moneda (currency) - equivaldría al tipo Fixed decimal number.
En general todos ellos se almacenan o requieren 8 bytes de almacenamiento.
Al cargar datos desde nuestras hojas de cálculo, Power Pivot, toma los tipos de datos aplicados o por defecto de nuestras celdas, lo que puede llevarnos a la catástrofe, en especial si arrastramos gran número de decimales...
En nuestro caso, al emplear Excel, deberemos tener la precaución y huir del formato de 'Número decimal' que admitiría hasta quince decimales, y podría 'incluir un regalito de 'punto flotante' (leer), lo que haría bastante daño a nuestro modelo de datos.
Por tanto, una muy buena práxis para nuestros modelos es optimizar el tipo de datos de nuestras columnas, asignando a las columnas numéricas, los tipos:
-número entero
-moneda (que admite hasta cuatro decimales!)
Veamos un ejemplo concreto sobre una tabla con 167.453 registros dentro de un modelo de relaciones como muestra la imagen siguiente.
Un sencillo modelo con dos tablas cargadas (TblVENTAS y TblPRECIOS) y al que hemos añadido una Tabla de Calendario o Fechas, relacionándolos como se muestra.
A la TblVENTAS hemos incorporado cuatro columnas calculadas con la misma fórmula:
=tblVENTAS[Unidades]*RELATED(tblPRECIOS[Precio])
A cada una de esas columnas, con idéntico cálculo, le he asignado un tipo de datos distinto: Número decimal, Número entero, Moneda y el último TRUE/FALSE.
Con las columnas calculadas creadas abriremos DAX Studio e iremos a la ficha 'Advanced' y presionaremos el botón: View Metrics lo que nos mostrará estos resultados:
En un rápido análisis comprobamos como las columnas de tipo texto son las más pesadas de nuestra tabla y modelo... y como de entre las cuatro columnas calculadas, la de tipo TRUE/FALSE es la menos pesada con diferencia (también la que menos aporta en cuanto a cálculo), y también las diferencias, mínimas, en los tipos Entero, Decimal o Moneda.
Quizá un +/- 5% de reducción pueda parecer poco... pero en grandes bases de datos (imagina 10 millones de registros) la cosa tiene su importancia. Y el coste del cambio no puede ser más sencillo.
No olvidemos además el hecho de que con este cambio evitaremos siempre el potencial problema del 'punto flotante'.
Pero la respuesta siempre será la misma: Usa las medidas siempre.
Así lo recomienda el mismo Microsoft en su documentación..., y no creo que el creador de todo esto se equivoque ;-)
Ahora bien, tampoco nos volvamos locos con este tema...
En ocasiones aporta mucho más modificar algún otro aspecto de nuestro diseño del Modelo... por ejemplo el tipo de datos de cada campo.
Veremos hoy como un sencillo cambio en el tipo de datos en nuestros campos aporta una mejora sustancial en nuestro modelo.
Para verificar esta mejora usaré la aplicación DAX Studio (https://daxstudio.org/), con una de las herramientas de análisis que ofrece: VertiPaq Analyzer Metrics Preview.
Pero antes conozcamos cuáles son estos tipos de datos.
| Tipo de datos en Excel | Tipo de datos en DAX | Descripción |
|---|---|---|
| Número entero | Un valor entero de 64 bits (ocho bytes) 1, 2 | Números que no tienen posiciones decimales. Los números enteros pueden ser números positivos o negativos, pero deben ser números enteros comprendidos entre-9223372036854775808 (-2 ^ 63) y 9.223.372.036.854.775.807 (2 ^ 63-1). |
| Número decimal | Un bit 64 (ocho bytes) real 1, 2 | Los números reales son números que pueden tener posiciones decimales. Los números reales cubren una amplia variedad de valores: |
| Valores negativos de-1,79e E + 308 a-2.23 E-308 | ||
| Cero | ||
| Valores positivos desde 2.23 E-308 hasta 1,79e E + 308 | ||
| Sin embargo, el número de dígitos significativos está limitado a 15 dígitos decimales. | ||
| VERDADERO/FALSO | Boolean | Un valor verdadero o falso. |
| Texto | String | Cadena de datos de caracteres Unicode. Puede ser cadenas, números o fechas representadas en un formato de texto. |
| La longitud máxima de la cadena es 268.435.456 caracteres Unicode (256 megapíxeles) o 536.870.912 bytes. | ||
| Fecha | Fecha y hora | Fechas y horas en una representación de fecha y hora aceptada. |
| Las fechas válidas son todas las fechas posteriores al 1 de enero de 1900. | ||
| Moneda | Moneda | El tipo de datos moneda permite valores comprendidos entre-922.337.203.685.477,5808 y 922.337.203.685.477,5807 con cuatro dígitos decimales de precisión fija. |
| N/D | En blanco | Un espacio en blanco es un tipo de datos en DAX que representa y reemplaza los valores NULL de SQL. Puede crear un espacio en blanco usando la función BLANK y probar los espacios en blanco con la función lógica, esblanco. |
Puedes leer algo más aquí.
En particular, nos centraremos en los formatos numéricos:
Número decimal (decimal number) - equivaldría al tipo Double clásico.
Número entero (whole number) - equivaldría al tipo Integer (Int64).
Moneda (currency) - equivaldría al tipo Fixed decimal number.
En general todos ellos se almacenan o requieren 8 bytes de almacenamiento.
Al cargar datos desde nuestras hojas de cálculo, Power Pivot, toma los tipos de datos aplicados o por defecto de nuestras celdas, lo que puede llevarnos a la catástrofe, en especial si arrastramos gran número de decimales...
En nuestro caso, al emplear Excel, deberemos tener la precaución y huir del formato de 'Número decimal' que admitiría hasta quince decimales, y podría 'incluir un regalito de 'punto flotante' (leer), lo que haría bastante daño a nuestro modelo de datos.
Por tanto, una muy buena práxis para nuestros modelos es optimizar el tipo de datos de nuestras columnas, asignando a las columnas numéricas, los tipos:
-número entero
-moneda (que admite hasta cuatro decimales!)
Veamos un ejemplo concreto sobre una tabla con 167.453 registros dentro de un modelo de relaciones como muestra la imagen siguiente.
Un sencillo modelo con dos tablas cargadas (TblVENTAS y TblPRECIOS) y al que hemos añadido una Tabla de Calendario o Fechas, relacionándolos como se muestra.
A la TblVENTAS hemos incorporado cuatro columnas calculadas con la misma fórmula:
=tblVENTAS[Unidades]*RELATED(tblPRECIOS[Precio])
A cada una de esas columnas, con idéntico cálculo, le he asignado un tipo de datos distinto: Número decimal, Número entero, Moneda y el último TRUE/FALSE.
Con las columnas calculadas creadas abriremos DAX Studio e iremos a la ficha 'Advanced' y presionaremos el botón: View Metrics lo que nos mostrará estos resultados:
En un rápido análisis comprobamos como las columnas de tipo texto son las más pesadas de nuestra tabla y modelo... y como de entre las cuatro columnas calculadas, la de tipo TRUE/FALSE es la menos pesada con diferencia (también la que menos aporta en cuanto a cálculo), y también las diferencias, mínimas, en los tipos Entero, Decimal o Moneda.
Quizá un +/- 5% de reducción pueda parecer poco... pero en grandes bases de datos (imagina 10 millones de registros) la cosa tiene su importancia. Y el coste del cambio no puede ser más sencillo.
No olvidemos además el hecho de que con este cambio evitaremos siempre el potencial problema del 'punto flotante'.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.