Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
Hola. Necesito una tabla de fecha tenue en mi modelo y quiero saber cuál es el preferido y por qué:
Gracias.
Solved! Go to Solution.
@D_PBI gracias por la entrada. Con respecto a su primer punto en SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que traiga del sistema back-end. Esa es la naturaleza del trabajo que tiene que hacer si está realizando cambios en su estructura de datos de subrayado, no importa que sea 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 menos probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación y planificación.
En mi experiencia personal, estoy proporcionando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ninguna instancia en la que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecirlo todo y por eso se llama mejor práctica, ninguna solución es perfecta.
Sólo mis 2 centavos.
@D_PBI gracias por la entrada. Con respecto a su primer punto en SQL, ese caso de uso particular es aplicable para cualquier dimensión / hecho que traiga del sistema back-end. Esa es la naturaleza del trabajo que tiene que hacer si está realizando cambios en su estructura de datos de subrayado, no importa que sea 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 menos probable que haya un cambio en ella, si hay, sí, tiene que abrir cada informe y actualizar el modelo. Planificación y planificación.
En mi experiencia personal, estoy proporcionando soluciones a empresas medianas y grandes durante los últimos 5 años y no recuerdo ninguna instancia en la que haya agregado nuevas columnas en la dimensión de fecha y, por esa misma razón, tengo que actualizar el modelo. No podemos predecirlo todo y por eso se llama mejor práctica, ninguna solución es perfecta.
Sólo mis 2 centavos.
@parry2k
Veo que el OP tiene un año de antigüedad ahora, pero solo quiero agregar mis pensamientos, para confirmación o corrección.
1) Aunque la creación de una tabla de dimensión de fecha en SQL significaría que crea / modifica en un solo lugar (por lo que manejar cualquier cambio (s) sólo una vez), que es bueno, es posible que todavía tenga que atender a cualquier cambio en M dependiendo del cambio SQL realizado - es decir, si usted ha añadido una nueva columna de fecha, si usted ha SELECT * FROM esa tabla, a continuación, los pasos aplicados PQ hecho necesidad de manipular para manejar la columna de fecha adicional traído en, lo que significaría todavía tener que abrir cada informe y configurar en consecuencia.
2) Al usar CALENDARAUTO() en DAX, analizará el rango completo de fechas utilizadas en su modelo de datos. Si tuviera que crear la dimensión Dat en SQL o M, tendría que especificar explícitamente las fechas de inicio y finalización que pueden ser dinámicas.
Además, si, por ejemplo, establece el intervalo de fechas para que sea de 19000101 a 19991231 por adelantado, pero, por ejemplo, la fecha de pedido solo contiene fechas entre 19800101 y 19891231, cuando agrega la tabla de dimensión de fecha a un objeto visual para usarlo como segmentador en la fecha de pedido, no mostraría el objeto visual el rango completo de entre 19000101 y 19991231, sin duda el cliente solicitaría solo los valores de fecha de pedido relevantes (es decir, 19800101 a 19891231) en el objeto visual.
3) Si quería una tabla de dimensión de tiempo, la última que supe, esto no se pudo completar con DAX, por lo que tendría que completar esto en SQL o M.
Cualquier comentario (confirmación/corrección/experiencia) sobre lo anterior sería útil.
Veo que el OP tiene un año de antigüedad ahora, pero solo quiero agregar mis pensamientos, para confirmación o corrección.
1) Aunque la creación de una tabla de dimensión de fecha en SQL significaría que crea / modifica en un solo lugar (por lo que manejar cualquier cambio (s) sólo una vez), que es bueno, es posible que todavía tenga que atender a cualquier cambio en M dependiendo del cambio SQL realizado - es decir, si usted ha añadido una nueva columna de fecha, si usted ha SELECT * FROM esa tabla, a continuación, los pasos aplicados PQ hecho necesidad de manipular para manejar la columna de fecha adicional traído en, lo que significaría todavía tener que abrir cada informe y configurar en consecuencia.
2) Al usar CALENDARAUTO() en DAX, analizará el rango completo de fechas utilizadas en su modelo de datos. Si tuviera que crear la dimensión Dat en SQL o M, tendría que especificar explícitamente las fechas de inicio y finalización que pueden ser dinámicas.
Además, si, por ejemplo, establece el intervalo de fechas para que sea de 19000101 a 19991231 por adelantado, pero, por ejemplo, la fecha de pedido solo contiene fechas entre 19800101 y 19891231, cuando agrega la tabla de dimensión de fecha a un objeto visual para usarlo como segmentador en la fecha de pedido, no mostraría el objeto visual el rango completo de entre 19000101 y 19991231, sin duda el cliente solicitaría solo los valores de fecha de pedido relevantes (es decir, 19800101 a 19891231) en el objeto visual.
3) Si quería una tabla de dimensión de tiempo, la última que supe, esto no se pudo completar con DAX, por lo que tendría que completar esto en SQL o M.
Cualquier comentario (confirmación/corrección/experiencia) sobre lo anterior sería útil.
Hola @yacoubi ,
Puede consultar este blog sobre sql, m y DAX:
https://sqlserverbi.blog/2018/05/12/sql-m-or-dax/
"Si tiene un almacenamiento 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 data mart para crear una única versión de la verdad para la generación de informes. También puede usar herramientas como SSIS o Azure Data Factory para compilar y administrar estos objetos antes de importarlos a Power BI o al modelo de datos de Analysis ServicesAnalysis Services ."
@yacoubi No creo que importe, pero si puede hacerlo en el origen como sql, puede usar la misma vista/tabla en varios informes, pero con DAX y M, debe asegurarse de hacer este paso en cada informe y en el futuro, si agrega otra columna o algo, debe cambiar en cada informe, suponiendo que cada informe tenga su propio conjunto de datos.
Me gustaría❤ elogiossi mi solución ayudara.👉Si puedes pasar tiempo publicando la pregunta, también puedes hacer esfuerzos para dar a Kudos quien haya ayudado a resolver tu problema. ¡Es una muestra de agradecimiento!
⚡Visítenos enhttps://perytus.com, su ventanilla única para proyectos/formación/consulta relacionados con Power BI.⚡
Subscribe to the @PowerBIHowTo YT channel for an upcoming video on List and Record functions in Power Query!!
Learn Power BI and Fabric - subscribe to our YT channel - Click here: @PowerBIHowTo
If my solution proved useful, I'd be delighted to receive Kudos. When you put effort into asking a question, it's equally thoughtful to acknowledge and give Kudos to the individual who helped you solve the problem. It's a small gesture that shows appreciation and encouragement! ❤
Did I answer your question? Mark my post as a solution. Proud to be a Super User! Appreciate your Kudos 🙂
Feel free to email me with any of your BI needs.
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |