yacoubi
Hola. Necesito una tabla de fecha tenue en mi modelo y quiero saber cuál es la preferida y por qué:
- Crear tabla en SQL
- Crear en M (Power Query)
- Crear a través de DAX
Gracias.
v-eachen-msft
Hola @yacoubi,
Puede consultar este blog sobre sql, my DAX:
https://sqlserverbi.blog/2018/05/12/sql-m-or-dax/
«Si tiene un almacén de datos de SQL Server, puede usar SQL para crear tablas de dimensiones de fecha. Por lo general, es mejor unificar todos los datos de informes en el almacén de datos o en el mercado de datos para crear una única versión de la verdad para los informes. Puede también use herramientas como SSIS o Azure Data Factory para crear y administrar estos objetos antes de que los datos se importen a Power BI o al modelo de datos de Analysis Services «.
parry2k
@D_PBI gracias por la entrada. Con respecto a su primer punto sobre SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que esté trayendo del sistema backend. Esa es la naturaleza del trabajo que tiene que hacer si va a realizar cambios en su estructura de datos de subrayado, no importa si es una dimensión de fecha o cualquier otra tabla, por lo que no está completamente de acuerdo con ese punto. La mayoría de las veces, este tipo de dimensión, especialmente la dimensión de fecha, está muy bien definida por adelantado y es muy poco probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación, planificación y planificación.
En mi experiencia personal, estoy brindando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ningún caso en el que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecir todo y es por eso que se llama mejor práctica, ninguna solución es perfecta.
Solo mis 2 centavos.
parry2k
@D_PBI gracias por la entrada. Con respecto a su primer punto sobre SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que esté trayendo del sistema backend. Esa es la naturaleza del trabajo que tiene que hacer si va a realizar cambios en su estructura de datos de subrayado, no importa si es una dimensión de fecha o cualquier otra tabla, por lo que no está completamente de acuerdo con ese punto. La mayoría de las veces, este tipo de dimensión, especialmente la dimensión de fecha, está muy bien definida por adelantado y es muy poco probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación, planificación y planificación.
En mi experiencia personal, estoy brindando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ningún caso en el que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecir todo y es por eso que se llama mejor práctica, ninguna solución es perfecta.
Solo mis 2 centavos.
D_PBI
@ parry2k
Veo que el OP tiene un año ahora, pero solo quiero agregar mis pensamientos, para confirmación o corrección.
1) Aunque crear una tabla de Dimensión de fecha en SQL significaría que crearía / enmendaría en un solo lugar (así que maneje cualquier cambio solo una vez), lo cual es bueno, es posible que aún tenga que atender cualquier cambio en M dependiendo de el cambio de SQL realizado, es decir, si ha agregado una nueva columna de fecha, si ha SELECCIONADO * DE esa tabla, entonces los Pasos aplicados de PQ realizados deben manipularse para manejar la columna de fecha adicional traída, lo que significaría que aún tendría que abrir cada informe y configúrelo en consecuencia.
2) Cuando utilice CALENDARAUTO () en DAX, escaneará el rango completo de fechas utilizadas en su modelo de datos. Si tuviera que crear la Dat Dimension en SQL o M, necesitaría especificar explícitamente las fechas de inicio y finalización, que pueden ser dinámicas.
Además, si, por ejemplo, establece el rango de fechas en 19000101 a 19991231 por adelantado, pero, por ejemplo, la Fecha de pedido solo contenía fechas entre 19800101 y 19891231, cuando agregue la tabla Dimensión de fecha a un objeto visual para usar como segmentación en la Fecha de pedido ¿No mostraría el visual el rango completo entre 19000101 y 19991231? Sin duda, el cliente solicitaría que solo se mostraran los valores de Fecha de pedido relevantes (es decir, 19800101 a 19891231) en el visual.
3) Si deseaba una tabla de dimensión de tiempo, lo último que sabía, no se podía completar con DAX, por lo que tendría que completarla en SQL o M.
Cualquier comentario (confirmación / corrección / experiencia) sobre lo anterior sería útil.
v-eachen-msft
Hola @yacoubi,
Puede consultar este blog sobre sql, my DAX:
https://sqlserverbi.blog/2018/05/12/sql-m-or-dax/
«Si tiene un almacén de datos de SQL Server, puede usar SQL para crear tablas de dimensiones de fecha. Por lo general, es mejor unificar todos los datos de informes en el almacén de datos o en el mercado de datos para crear una única versión de la verdad para los informes. Puede también use herramientas como SSIS o Azure Data Factory para crear y administrar estos objetos antes de que los datos se importen a Power BI o al modelo de datos de Analysis Services «.
parry2k
@yacoubi No creo que importe, pero si puede hacerlo en la fuente como sql, puede usar la misma vista / tabla en varios informes, pero con DAX y M, debe asegurarse de realizar este paso en cada informe y en el futuro, si agrega otra columna o algo, debe cambiar en cada informe, asumiendo que cada informe tiene su propio conjunto de datos.
me gustaría ❤ Prestigio si mi solución ayudó. 👉 Si puede dedicar tiempo a publicar la pregunta, también puede hacer esfuerzos para felicitar a quien ayudó a resolver su problema. ¡Es una muestra de agradecimiento!
⚡Visitanos en https://perytus.com, su ventanilla única para proyectos, capacitación y consultoría relacionados con Power BI.⚡
