Menú principal Navegación de mensajes Calculando una media móvil en PowerPivot Hace dos semanas prometí hablar sobre cómo generar una media móvil en PowerPivot, pero la semana pasada me desvié diciéndole una manera genial de mostrar vídeos de YouTube en sus páginas de SharePoint usando Una parte web encontrada en CodePlex que algunos miembros de mi equipo de trabajo encontraron. Fue tan fácil de implementar, que sólo tenía que compartirlo con todos ustedes. Sin embargo, volviendo de nuevo al tema de calcular una media móvil, la primera pregunta podría ser lo que es una media móvil y, a continuación, por qué desea utilizar uno. Un promedio móvil es simplemente la suma de dos o más valores dependientes del tiempo en los que la suma se divide entonces por el número de valores utilizados. Por ejemplo, si estuviera hablando de los precios de las acciones, es posible que desee utilizar algo así como una media móvil de 7 días para amortiguar el efecto de los picos de cada día o caídas en el precio de las acciones que no son indicativos de la tendencia general de las acciones. (Algunos inversionistas a largo plazo usan promedios móviles de un período incluso más largo.) Eso no significa que si una acción se desploma o se eleva que me sentaría hasta que el promedio móvil me diga que actúe. Cualquier buen inversor de acciones le dirá que hay muchos otros factores internos y externos a una empresa que podría obligar a su mano para vender o comprar cualquier acción en particular. Pero el punto es, y esta es la respuesta a la segunda pregunta, una media móvil amortigua la aleatoriedad para que pueda ver más fácilmente el patrón general de los números que estoy siguiendo. Ok, así que supongamos que trabajo para Contoso y quería saber si las ventas están subiendo, bajando o generalmente plana. Si miro las ventas diarias, es probable que los números fluctúen de arriba abajo en ningún patrón particular que me impida detectar una tendencia general. La siguiente figura muestra las ventas diarias de Contoso diarias de Contoso durante un período de 3 meses durante el verano de 2008. Elegí mostrar los datos como un gráfico para ayudar a mostrar cómo las ventas fluctúan por día revelando información que podría no ser capaz de ver tan fácilmente si hubiera Creó una tabla de los mismos valores. Por supuesto, podría trazar un año completo o más, pero para ver días individuales, tendría que ampliar el gráfico sustancialmente. Sin embargo, incluso con este período de tiempo más pequeño, puedo ver que las ventas fluctúan bastante bien. Pero podría preguntarse si las ventas aumentan, disminuyen o permanecen iguales. Si tengo un buen ojo, podría decir que las ventas pico hacia finales de julio y luego retroceder un poco como el gráfico se mueve en agosto. Pero eso no es tan obvio como el hecho de que hay una gran cantidad de fluctuaciones diarias. Entonces, cómo puedo visualizar visualmente las tendencias con las ventas de media móvil. Ahora, con el propósito de esta ilustración, voy a crear una media móvil de cuatro días, pero sinceramente, no hay un número correcto de períodos en una media móvil. De hecho, debería experimentar con diferentes períodos de tiempo para ver qué período de tiempo me permite detectar no sólo las tendencias generales, sino también en este caso en que estoy mostrando las ventas de la tienda, en los cambios estacionales. Ya sé que si muestro datos por día, puedo usar la siguiente fórmula para calcular las ventas diarias de nuestro canal de tienda. (Sí, podría simplemente usar SalesAmount y aplicar un slicer de canal para usar sólo las ventas de la tienda, pero permite seguir con el ejemplo.) Puedo usar esta medida calculada para calcular las ventas de días anteriores para cualquier día mediante la creación de la siguiente medida. Usted puede ser capaz de adivinar que la fórmula para calcular las ventas de hace dos días y hace tres días, respectivamente son: StoreSales2DayAgo: CALCULATE (StoreSales, DATEADD (DimDateDateKey, -) Con estos cuatro valores calculados para cada día, puedo calcular la suma de estos valores y dividir por 4 para obtener un promedio móvil de 4 días usando El siguiente valor calculado: FourDayAverage: (StoreSales StoreSales1DayAgo StoreSales2DayAgo StoreSales3DayAgo) / 4.0 Ahora, si vuelvo a mi página de gráfico, debería ver que Excel actualiza la lista de campos para incluir las nuevas medidas calculadas. Si a continuación agrego el campo FourDayAverage al cuadro Valores creando una segunda serie en el gráfico, ahora tengo las ventas diarias reales y el promedio móvil de cuatro días que se muestran en el mismo gráfico. El único problema es que también quiero cambiar el formato de gráfico para mostrar las ventas diarias (mi primera serie de datos) como columnas y mi promedio móvil (mi segunda serie de datos) como una línea. Cuando hago clic derecho en el gráfico y selecciono Cambiar tipo de gráfico, puedo seleccionar Combo como el tipo de gráfico como se muestra en la figura siguiente. En este caso, la gráfica de línea de columna agrupada es exactamente lo que quiero. Debido a que agregué la serie de media móvil al último de los valores, se convierte por defecto en la línea y todas las demás series de datos aparecen como columnas agrupadas. Como sólo tengo un valor por día, el gráfico muestra una columna individual por día. Si hubiera entrado mi serie de datos en el área Valores en el orden equivocado, podría simplemente usar este cuadro de diálogo para seleccionar el tipo de gráfico para cada serie. Cuando hago clic en Aceptar en este cuadro de diálogo, mi gráfico ahora se parece a lo siguiente, que muestra más claramente la mayor parte de la tendencia general y menos fluctuación diaria. Pero espera, hay una manera más fácil de hacer esto Por qué sí hay. Pero para aprender a hacer eso, tendrá que esperar hasta la próxima semana. Post navigation Mis archivos Suscríbase por correo electrónico Temas de los que habloEstoy intentando crear una media móvil de 12 meses para los datos de la plantilla usando el siguiente DAX (siguiendo una entrada en el blog de Javier) El problema es que la medida de Ending Headcount es una medida calculada y no una columna valor. Por lo tanto, sigo recibiendo el siguiente mensaje de error: 1 quotMeasure Monthly Headcount12 Month AVG Headcount. La función MEDIA sólo acepta una referencia de columna como el número de argumento 1quot No quiero realmente poner la lógica para finalizar Headcount en la consulta anterior. Hay alguna manera alrededor de este btw. Intenté y hago una SUMA (Ending Headcount) / CountRows (.) Y SUMA sólo acepta una referencia de columna también. Gracias por tu ayuda. Frank Cambiado tipo Ed Price - MSFT Empleado de Microsoft, Propietario Martes 10 de Diciembre de 2013 6:58 AM Sin respuesta Lunes 4 de Marzo de 2013 16:47 Todas las respuestas Sigue siendo un problema? Responder una pregunta interesante Crear un artículo wiki al respecto Domingo, 24 de noviembre de 2013 2:22 Microsoft está realizando una encuesta en línea para entender su opinión sobre el sitio web de Msdn. Si decide participar, se le presentará la encuesta en línea cuando abandone el sitio Web de Msdn. Te gustaría participar 2016 Microsoft. Todos los derechos reservados. Promedio de los promedios móviles Siempre he sido un creyente firme de que los promedios móviles probablemente dar una mejor visión de las tendencias dentro de un negocio que una línea de tendencia simple asociada a un conjunto de valores como las ventas mensuales (aunque tienden a revisar estos dos valores juntos). La razón de esto es que una tendencia puede ser sesgada por uno o dos valores que pueden no ser representativos de la empresa subyacente, tales como picos asociados a la estacionalidad o un evento específico. Cuando BillD destacó una consulta sobre este concepto en sus comentarios sobre Profit amp Loss (Parte 2) Compare and Analyze. Pensé que sería una gran idea flexionar nuestro dataset de PampL para proporcionar una cierta capacidad del promedio móvil. En este post, explicaré qué promedios móviles se pretende ofrecer y explicar cómo calcularlos usando los elementos de ventas de los datos de ejemplo utilizados en la serie Período de pérdida de beneficios. A continuación, agregaré la flexibilidad para que los usuarios seleccionen el tiempo que debe considerar el cálculo del promedio móvil, el número de períodos de tendencia que se mostrarán y la fecha de finalización del informe. Qué es una media móvil La medida media móvil más común se refiere generalmente como una media móvil de 12 meses. En el caso de nuestros datos de ventas, para un período determinado, esta medida sumaría los últimos 12 meses de ventas anteriores e inclu - yendo el mes analizado y luego se dividiría por 12 para mostrar un valor promedio de ventas para ese período. En términos financieros, la ecuación es, por tanto, muy sencilla: 12 meses de media móvil suma de las ventas de los últimos 12 meses / 12 Esto todo parece muy sencillo, pero hay una gran complejidad si queremos poner el promedio móvil (representado como 12 En el ejemplo anterior) en las manos del usuario, darles el poder de seleccionar el número de períodos de tendencia a mostrar y el mes que el informe debe mostrar hasta. El conjunto de datos El conjunto de datos que se utiliza parece algo como a continuación. Nota Im usando PowerPivot V1. Visor de diseño está disponible en V2, pero Ive hash esto juntos nada inteligente Usted notará que FACTTran (nuestro conjunto de datos para ser analizado) está vinculado a DIMHeading1, DIMHeading2 y DIMDataType para proporcionar una cierta categorización a nuestro conjunto de datos. Ive también vinculado a las fechas que es un conjunto secuencial de fechas que más que cubre el tiempo de nuestro conjunto de datos. Esta tabla lleva una cierta información adicional estática basada en la fecha: Una vez más, no era absolutamente el registrar en la escala picante de Robs. Le aseguran que usted estará consiguiendo un entrenamiento más intenso de DAX mientras que continuamos. Como estas medidas de fecha no se esperan sean dinámicas, las he codificado en la ventana de PowerPivot. Esto permite que se calculen en la actualización de archivos, pero no será necesario volver a calcular para cada operación de corte que elimina la sobrecarga de rendimiento de nuestra última medida dinámica. Por razones que Ill vienen a más tarde, también necesito la fecha de fin de mes en mi tabla de hechos como no puedo usar la fecha de fin de mes en mi tabla de fechas en mis medidas. Puedo sin embargo tirar el mismo valor a través de mi tabla de FACTTran usando la medida siguiente: Tan qué son estas mesas desvinculadas del mA La razón de estas tablas debe hacer evidente como continuamos. En resumen, theyre va a ser utilizado como parámetros o encabezados en nuestro informe. La razón por la que existen y que theyre no vinculados con el resto de nuestros datos es simplemente porque no quiero que sean filtrados por nuestras medidas. En su lugar, quiero que conduzcan el filtrado. Configuración de tabla dinámica inicial Voy a mostrar una serie de datos organizados en columnas mensuales. Al usuario se le darán rebanadoras para fijar la fecha de finalización del mes (el último período que se mostrará en el informe), el número de períodos para la media móvil (que en última instancia será parte de nuestro cálculo de divisor) y el número de períodos para la tendencia El número de columnas mensuales que mostraremos en nuestra tendencia). Podemos establecer estas rebanadoras de inmediato y vincularlas con el pivote. Obviamente, necesito una fecha de fin de mes como un encabezado de columna, pero que hasta cierto punto Ive dado esto lejos antes. En resumen, necesito usar mi campo MADatesMonthEndDate. La razón es que este campo no está vinculado a nuestro conjunto de datos y por lo tanto no se verá afectado por otros filtros. Si utilizo un campo de fecha que es parte de mi conjunto de datos o parte de una tabla vinculada, los valores disponibles pueden ser filtrados por las selecciones de los usuarios. Puedo conseguir alrededor de esto usando una expresión de ALL () para darme los valores correctos, pero el problema es que la columna todavía se filtra y mis resultados todos se exhibirán en una columna. Es difícil de explicar hasta que lo veas así que por favor sigue adelante y prueba su valor golpear la pared de ladrillo para realmente entender Calculando la suma de las ventas de los últimos X Meses La primera parte de nuestra ecuación es calcular el valor total de las ventas en todos los períodos dentro Un periodo de tiempo dinámico para ser seleccionado por el usuario. Para esto utilizo una función de cálculo que se parece a esto: Im usando una medida base llamada CascadeValueAll que se creó en Profit amp Loss El arte del subtotal en cascada. Im entonces filtrar esa medida para limitar mi conjunto de datos a los registros que se refieren a las ventas y un tipo de datos de reales (es decir, eliminar el presupuesto). Esto es un simple filtrado de una función CALCULATE. Sin embargo, se vuelve un poco más sabroso con el tercer filtro que limita el conjunto de datos a una serie de fechas que dependen de las selecciones de usuarios en cortadoras y nuestro encabezado de columna de fecha. La función DATESBETWEEN tiene la sintaxis DATESBETWEEN (fechas, fecha de inicio, fecha de finalización) y funciona de esta manera: Configure el campo que requiere el filtrado (DatesData). He encontrado que esto funciona mejor si se trata de una tabla vinculada de fechas secuenciales sin interrupciones. Si tiene alguna pausa, hay una posibilidad de que no obtenga una respuesta, ya que la respuesta que usted evalúa debe estar disponible en la tabla. Mi fecha de inicio es una función DATEADD que calcula la fecha del encabezado de la columna menos el número de meses que el usuario ha seleccionado en la rebanadora del número medio de periodos móviles. Utilizo la función LASTDATE (VALUES (MADatesNextMonthStartDate)) para recuperar el valor NextMonthStartDate de la tabla MADates que se relaciona con la fecha representada en el encabezado de columna. A continuación, rebobinar por el número de meses seleccionados en la rebanadora utilizando MAX (MAFunctionPeriodsMovingAverageNoPeriods) -1. El -1 se usa para retroceder en el tiempo. La razón por la que uso NextMonthStartDate y un múltiplo de 1 se explica más claramente en Slicers para seleccionar últimos períodos X. Mi fecha de finalización es simplemente el MonthEndDate como se muestra en el encabezado de columna del informe. Esto se calcula usando LASTDATE (VALUES (MADatesMonthEndDate).Esto es genial, pero mi medida no está teniendo ninguna cuenta de mi período de exposición hasta la selección y la tendencia número de períodos que he seleccionado. Por lo tanto, debemos limitar la medida para ejecutar sólo cuando ciertos Los parámetros se mantienen como verdaderos basados en estas selecciones Sólo quiero que los valores se muestren cuando la fecha de mi encabezado de columna es: Menor o igual que la Fecha de fin de mes seleccionada en mi Mostrar Períodos Hasta Seccionador Y Mayor o igual que el Mes de fin seleccionado Fecha MENOS el número seleccionado de períodos en mi rebanadora de Trend No of Periods. Para ello, utilizo una sentencia IF para determinar cuándo debe ejecutarse mi función CALCULATE. Leva a llamar a esta medida SalesMovingAverageTotalValue La sentencia IF funciona de la siguiente manera: Primero necesito determinar Que estoy evaluando sólo donde tengo un valor para MADateMonthEndDate. Si no lo hago, consigo que el viejo error favorito en mi evaluación posterior que dice que una tabla de valores múltiples se proporcionó a continuación, evaluar para determinar si mi columna título fecha (VALUES (MADatesMonthEndDate) es menor o igual que la fecha seleccionada en la rebanadora de fin de mes (LASTDATE (datesDateMonthEnd) Y (ampamp) La fecha de mi encabezado de columna es mayor o igual a una fecha calculada que es X períodos anteriores a los períodos seleccionados Up To como se selecciona en el Slicer. Utilizo una función DATEADD para esto similar a la utilizada en mi función CALCULATE excepto que estaba ajustando la fecha por el valor seleccionado en la rebanadora Trend No of Periods. Con esto en su lugar, tenemos las ventas totales para el período seleccionado relacionadas con las selecciones de los usuarios. Así que mi tabla está ahora limitada al número de períodos de tendencia seleccionados y representa la fecha de finalización del mes seleccionada. Así que ahora solo dividimos por Moving Average No de Períodos Derecha eh NO Hemos calculado nuestras ventas totales para el período en relación con las selecciones de los usuarios. Se le perdonaría por sugerir que simplemente dividimos por el número de periodos de media móvil seleccionados. Dependiendo de sus datos, puede hacerlo, pero el problema es que el conjunto de datos no puede contener el número seleccionado de períodos, especialmente si el usuario puede seleccionar una fecha de fin de mes que se remonta en el tiempo. Como resultado, tenemos que averiguar cómo pueden estar presentes períodos en nuestra medida SalesMovingAverageTotalValue. Esta medida es esencialmente la misma que mi medida SalesMovingAverageTotal. La única diferencia real es que contamos los valores de fecha distintos en nuestro conjunto de datos en lugar de llamar a la medida CascadeValueAll. He mencionado anteriormente que había una razón por la que necesitaba la fecha de fin de mes que se celebrará en mi mesa de FACTTran y esta es la razón. Si utilizo cualquier otra tabla que contenga la fecha de finalización del mes, esa tabla no se habrá filtrado en la forma en que se ha filtrado el conjunto de datos principal. Por ejemplo, mi tabla de fechas tiene una serie de fechas que abarca mi marco de tiempo de dataset y más. Como resultado, la evaluación con respecto a esta tabla deducirá que la tabla sí tiene fechas que preceden a mi conjunto de datos y, por lo tanto, no hay evaluación de si hay una transacción en el conjunto de datos para esa fecha. Como puede ver, ya que mi conjunto de datos se ejecuta a partir del 1 de julio de 2009, sólo tengo 9 períodos de datos para evaluar para mi 31/03/2010 columna. Si me hubiera dividido por 12 (como por mi Selección de Moving Average No de Períodos de selección), tendría una respuesta muy equivocada. Obviamente, esto es un poco artificial, pero es digno de consideración. Y ahora el simple bit Puedo entender que las dos últimas medidas han tomado un poco de absorción, especialmente trabajando cuando los campos de fecha particular debe ser utilizado. Para algunos alivio de luz, la medida siguiente no le impondrá impuestos Esta es una división simple con un poco de error de verificación para evitar cualquier nasties. Cuando todas estas medidas son portátiles, puedo crear otra tabla dinámica en la misma base que la anterior (con SalesMovingAverageValue dado un alias de media móvil), mover algunas cosas, agregar una medida para las ventas reales Valor para el mes (no voy a entrar en eso ahora, pero es una medida simple CALCULATE con un poco de inteligencia de tiempo) y luego reconfigurar para que parezca lo siguiente: Puedo entonces conducir un gráfico de línea simple y aplicar una línea de tendencia a mi medida real Con el gráfico convenientemente ocultando mi cuadrícula de datos que lo conduce. Como puede ver, una tendencia en mi medida real muestra una disminución constante. Sin embargo, mi Promedio móvil muestra una tendencia relativamente estable, aunque no ligeramente mejorada. Por lo tanto, la estacionalidad de algunos otros picos está, por lo tanto, involucrada y la realidad es que ambas medidas probablemente necesitan ser revisadas lado a lado. Para aquellos de ustedes que lean esto que estén interesados en ver el libro de este ejemplo, voy a publicar esto en un post futuro cuando tomo este análisis un paso más para cubrir toda la PampL. Siento hacerte esperar. Espero que esto te ayude a salir BillD Un punto más a la nota Los águilas Eyed DAX profesionales por ahí probablemente han notado que mis funciones IF sólo contienen un cálculo para evaluar cuando la prueba lógica llega a una respuesta verdadera. La razón es que la función asume BLANK () cuando no se proporciona una condición de evaluación falsa. No he resuelto si theres cualquier impacto de rendimiento utilizando este método en grandes conjuntos de datos. Su hasta usted qué usted eligió hacer y si cualquier persona puede convencerme porqué codificar la condición falsa como BLANCO () es la mejor práctica, cambiaré rápidamente mis hábitos Este poste tiene 6 comentarios Renato Lyke dice:
No comments:
Post a Comment