Powerpivot Beweglich Durchschnittlich Dax

Moving Averages, Sums, etc. Die Blaue Linie glättet zufällige Schwankungen, erzählt einen weniger überreaktiven Trend Ich habe vor kurzem erkannt, dass dieses Thema noch nie zuvor in seiner einfachsten Form auf dieser Seite abgedeckt wurde. Eigentlich war es das Thema Ein Gastposten von der geschätzten David Churchward. Und auch durch den gleich geschätzten Kasper de Jonge. Aber keiner dieser Beiträge profitierte von den heute noch verfügbaren v2-Funktionen). Um zu veranschaulichen, was wir mit modernsten Power Pivot Formeln machen können, lasst uns mit diesem einfachen Modell beginnen: Und ein einfacher Pivot: Das Units verkauft Maß ist die gezackte rote Linie in der Tabelle an der Spitze der Post, und Seine Formel ist sehr einfach: Einheiten verkauft SUM (SalesQtySold) Und wir wollen eine Version von Einheiten verkauft, die über einen Zeitraum von 3 Monaten geglättet wird. Moving Sum Lets Beginn mit einer Formel, die eine Summe der letzten 3 Monate (einschließlich der aktuellen) ist: 3 Monate Moving Summe verkauft CALCULATE (Einheiten verkauft, DATESINPERIOD (KalenderDate, LASTDATE (CalendarDate), - 3, Monat)) Und sehen, wie das aussieht: Bewegen 3-Monats-Summe spiegelt den aktuellen Monat und die vorherigen zwei Monate verschieben Durchschnittlich ersten Versuch OK, aber diese Zahl ist größer als ein einziger Monat und stimmt nicht mit der Skala unseres realen Weltgeschäfts überein, also wir Würde nicht wollen, dass wir die durchschnittliche Version davon wollen. Es ist ein 3-Monats-Umzugsbetrag, um den Durchschnitt zu erreichen, wir konnten uns nur durch 3: 3 Monate teilen. Avg Divide 3 3 Monate Moving Sum Units verkauft 3 Wie sieht es aus: 3 Monate Moving Avg Via Divide von 3 Hat einen Nachteil Zwei Monate, da sie die ersten zwei Monate in unserem Kalender sind, summieren wir weniger als 3 Monate im Wert von Verkäufen, aber immer noch durch 3 teilen. So fährt es ungerecht nach unten ihren Durchschnitt. Moving Average Corrected Wir können dies erklären, indem wir unseren Nenner ändern, um eine ähnliche Logik für den Zähler zu verwenden: 3 Monat Moving Avg korrigiert 3 Monate Moving Summe verkauft CALCULATE (DISTINCTCOUNT (KalenderJahr Monat), DATESINPERIOD (CalendarDate, LASTDATE (CalendarDate), - 3, Monat)) Auf Englisch: Nehmen Sie die 3-Monats-Summe, die wir bereits haben, und teilen Sie sie durch die Anzahl der verschiedenen (einzigartigen) Monate, die wir über denselben Zeitraum von 3 Monaten haben. Diese Calc ist mehr fair für die Monate an den Anfangsvariationen Es gibt eine Reihe von Variationen auf diesem Ansatz täglichwöchentlich vierteljährliche Versionen, die Korrektur für Kalender, die über die Reichweite von Daten hinausgehen, wo Sie Verkäufe haben, die Anpassung an benutzerdefinierte Kalender über die größte Formel in der Welt . Etc. aber ich werde abwarten und sehen, was die Leute in den Kommentaren fragen, bevor sie in irgendwelche von denen graben. Es funktioniert But8230 .. Ich arbeite mit Tagen 8211 speziell, ich muss einen rollenden 28 Tage Durchschnitt einer meiner Maßnahmen zu bekommen. Das funktioniert gut, wenn ich das Ergebnis mit meinem Datumsattribut ansehe. Allerdings hat meine Kalender-Dimension auch ein diskretes, nicht-kontinuierliches Attribut namens DateMonth (das sieht aus wie 1-Jan, 2-Jan etc.) Ich hatte gehofft, dass dies mir erlauben würde, dann mein Jahr-Attribut zu nehmen und den 28-Tages-Durchschnitt zu vergleichen Der 1. Januar über mehrere Jahre hinweg. So könnte man ein Liniendiagramm haben, bei dem die Achse 1-Jan bis 31-Dez (ohne Bezug zum Jahr) ist und die Serienkategorie ist bei Jahr, also eine Zeile für jedes Jahr. Hoffe, jemand könnte helfen Die letzte Gleichung lieferte 8211 Moving Average Corrected 8211 liefert einen Nenner mit einem Wert von 12 (dh es ist abhängig von, wenn mein Calendaryear-Monat beginnt. So haben einen korrekten 12 Monate gleitenden Durchschnitt, meine Daten und Kalender müssen Start zur gleichen Zeit). Irgendwelche Vorschläge, die ich mir herausgefunden habe: Was ich tat, war, meine Monate zu beginnen, beginnend mit dem ersten Datum meines Verkaufs (d. h. 40663 ist das letzte Datum, bevor ich anfangen wollte, die Monate zu zählen, in denen meine Verkäufe waren). Hoffe, das kann jemandem helfen, der diesen Blog nach William sucht, du bist ein Lebensretter. Ich habe versucht, herauszufinden, warum mein Nenner 3 für den ältesten Datenmonat hielt, mit dem ich arbeitete. Ich schätze Ihr Beispiel und jede Erklärung, die genau auf meine Situation angewendet wurde. John pullin sagt: Ich habe eine bessere Lösung für die endgültige Kommentar hier 8211 eine, die die Anzahl der Monate berechnet, um zu teilen, wenn Ihre Daten und Kalender nicht gleichzeitig starten. Dies war die ursprüngliche Berechnung: 3 Monate Umzug Avg korrigiert 3 Monate Umzug Summe verkauft CALCULATE (DISTINCTCOUNT (KalenderJahr Monat), DATESINPERIOD (CalendarDate, LASTDATE (KalenderDate), - 3, Monat)) Und seine innerhalb der Teiler, dass die Bearbeitung benötigt wird 8211 richtig zu erarbeiten, wo man sich durch 2 und dann 1 (für die ersten 3 Monate in Ihren Daten) teilen. Die unten stehenden Behandlungsmethoden: 3 Monate Bewegender Durchschnitt 8211 Arbeiten 3 Monate Umzugssumme BERECHNUNG (BERECHNUNG (BAHNEN (WERTE (DimDateCalendarMonth)), FactSales), DATESINPERIOD (DimDateDatekey, LASTDATE (DimDateDatekey), - 3, MONTH)) Wo FactSales Ihr ist Fact table obvs Hoffe das hilft jemand anderes aus 8211 wie es mich verrückt gemacht hat Vikas Gautam sagt: Ich habe eine Frage. Was ist, wenn wir den Durchschnitt der letzten 30 Handelstage oder Arbeitstage benötigen. Natürlich hätten wir eine Datumsspalte, die Handelstage repräsentiert. 1 Monat Durchschnitt mit deiner Formel gewonnen8217t die gleiche Sache. Als Exact 30 Tage8217s Durchschnitt wird hier benötigt. Würden Sie bitte eine Formel vorschlagen. Die schwierige Sache ist die Berechnung basiert auf dem anderen Finanztermin als dem Kalenderdatum, da fast alle vorhandenen Zeit intelligente Datumsfunktionen nicht verwendet werden können. Jede Beispiel Berechnung Formel auf der Grundlage der finanziellen Datum Ich habe eine Menge von Informationen über die Berechnungen auf der Grundlage der Kunden Daten aus dem oben genannten Link 8220Großsten Formel in der world8221. It8217s sehr hilfreich8230 .. Dies ist eine großartige Post von allen. Ich möchte wissen, ob die Verkäufe in einem der letzten drei Monate null sind oder gar keine Verkäufe, dann wie würden die Formeln die Arbeit vorschlagen. Ich möchte die Anzahl der Monate vom aktuellen Monat bis zum letzten drei Monate mit dem Verkauf herausfinden. Sag ich bin im Mai 2014 die letzten drei Monate werden auch Mai 2014. Mär 2014, April 2014 und Mai 2014. Aber Apr 2014 hat keinen Umsatz. So sollte es Summe von Mar und Mai 2014 Umsatz geteilt durch 2 und nicht 3. Nehmen wir an, wir haben Verkäufe für Jun 2014 und Jul 2014. Für Jun 2014 die durchschnittlichen letzten 3 Monate sein sollte (My 2014 Jun 2014) 2. Für Jul 2014 Der Durchschnitt der letzten 3 Monate sollte (Mai 2014 Jun 2014 Jul 2014) 3. Jede Hilfe, um dies zu erreichen wird sehr geschätzt werden. Hey, brillante Lösung. Aber jetzt I8217m auf der Suche nach der gleichen Ergänzung wie CheenuSing erwähnt. Einige Serien in meinen Daten don8217t haben Verkäufe in der letzten Periode, aber andere tun. CheenuSing, hast du die Lösung gefunden, die I8217d am meisten dankbar ist, danke. Im neu mit allen DAX-Funktionen und ganz kämpfen mit meiner gleitenden durchschnittlichen Berechnung. Ich brauche nur den gleitenden Durchschnitt von 3 Monaten zurück NICHT einschließlich der aktuellen Monat. Ich habe versucht mit 8220IF8221 aber nie geklappt. Kann jemand mir mit itSQL Server helfen Denali PowerPivot Alberto Ferrari schrieb bereits über die Berechnung der Bewegungsdurchschnitte in DAX mit einer berechneten Spalte. I8217d möchte hier einen anderen Ansatz vorstellen, indem wir eine berechnete Maßnahme verwenden. Für den gleitenden Durchschnitt I8217m berechnen einen täglichen gleitenden Durchschnitt (in den letzten 30 Tagen) hier. Für mein Beispiel, I8217m mit der PowerPivot-Arbeitsmappe, die als Teil der SSAS tabellarischen Modellprojekte aus dem Denali CTP 3 Samples heruntergeladen werden kann. In diesem Beitrag, I8217m die Entwicklung der Formel Schritt für Schritt. Allerdings, wenn Sie in Eile sind, können Sie direkt zu den endgültigen Ergebnissen unten zu springen. Mit dem Kalenderjahr 2003 auf dem Filter, dem Datum auf Spalten und dem Verkaufsbetrag (aus Tabelle Internet Sales) in den Details sehen die Beispieldaten wie folgt aus: In jedem row8217s Kontext gibt der Ausdruck DateDate den aktuellen Kontext, dh das Datum für diese Zeile . Aber aus einer berechneten Maßnahme können wir nicht auf diesen Ausdruck verweisen (da es keine aktuelle Zeile für die Date-Tabelle gibt), stattdessen müssen wir einen Ausdruck wie LastDate (DateDate) verwenden. Also, um die letzten dreißig Tage zu bekommen, können wir diesen Ausdruck nutzen. Wir können nun unsere Internet-Verkäufe für jeden dieser Tage mit der zusammenfassenden Funktion zusammenfassen: Zusammenfassen (160 DatesInPeriod (DateDate, LastDate (DateDate), - 30, DAY) 160, DateDate 160. quotSalesAmountSumquot 160. Summe (Internet SalesSales Betrag)) Und schließlich, mit der DAX-Funktion AverageX, um den Durchschnitt dieser 30 Werte zu berechnen: Verkaufsbetrag (30d avg): AverageX (160 Zusammenfassen (160160160 DatesInPeriod (DateDate, LastDate (DateDate), - 30, DAY) 160160160, DateDate 160160160. quotSalesAmountSumquot 160160160. Summe (Internet SalesSales Betrag) 160) 160, SalesAmountSum) Dies ist die Berechnung, die wir in unserer Internet Sales Tabelle verwenden, wie im Screenshot unten gezeigt: Wenn man diese Berechnung der Pivot-Tabelle von oben addiert, sieht das Ergebnis so aus: Wenn man das Ergebnis betrachtet, scheint es, dass wir vor dem 1. Januar 2003 keine Daten haben: Der erste Wert für den gleitenden Durchschnitt ist identisch mit dem Tageswert ( Es gibt keine Zeilen vor diesem Datum). Der zweite Wert für den gleitenden Durchschnitt ist eigentlich der Durchschnitt der ersten beiden Tage und so weiter. Das ist nicht ganz richtig, aber ich bin in einer Sekunde auf dieses Problem zurückgekehrt. Der Screenshot zeigt die Berechnung für den gleitenden Durchschnitt am 31. Januar als Durchschnitt der Tageswerte vom 2. bis 31. Januar. Unsere berechnete Maßnahme funktioniert auch bei der Anwendung von Filtern. Im folgenden Screenshot habe ich zwei Produktkategorien für die Datenreihe verwendet: Wie funktioniert unsere berechnete Maßnahme auf höhere Aggregationsebenen Um herauszufinden, I8217m mit der Kalenderhierarchie in den Zeilen (anstelle des Datums). Zur Vereinfachung habe ich die Semester - und Viertelstufen mit Excel8217s Pivot-Tabellenoptionen (ShowHide Felder Option) entfernt. Wie Sie sehen können, funktioniert die Berechnung noch gut. Hier ist das monatliche Aggregat der gleitende Durchschnitt für den letzten Tag des jeweiligen Monats. Sie sehen das deutlich für Januar (Wert von 14.215.01 erscheint auch im Screenshot oben als Wert für 31. Januar). Wenn dies die geschäftliche Anforderung (die für einen Tagesdurchschnitt klingt) klingt, dann funktioniert die Aggregation auf einer monatlichen Ebene gut (sonst müssen wir unsere Berechnung fein abgestimmt haben und das wird ein Thema der kommenden Post sein). Aber obwohl die Aggregation auf einer monatlichen Ebene sinnvoll ist, wenn wir diese Ansicht auf die Tagesniveau erweitern, sehen Sie, dass unsere berechnete Maßnahme einfach den Verkaufsbetrag für diesen Tag zurückgibt, nicht den Durchschnitt der letzten 30 Tage mehr: Wie kann das sein. Das Problem ergibt sich aus dem Kontext, in dem wir unsere Summe berechnen, wie im folgenden Code hervorgehoben: Verkaufsbetrag (30d avg): AverageX (160 Zusammenfassende (160160160 dateinperiod (DateDate, LastDate (DateDate), - 30, DAY) 160160160, DateDate 160160160. quotSalesAmountSumquot 160160160. Summe (Internet SalesSales Betrag) 160) 160, SalesAmountSum) Da wir diesen Ausdruck über den angegebenen Zeitraum auswerten, ist der einzige Kontext, der hier überschrieben wird, DateDate. In unserer Hierarchie verwenden wir verschiedene Attribute aus unserer Dimension (Kalenderjahr, Monat und Tag des Monats). Da dieser Kontext noch vorhanden ist, wird die Berechnung auch durch diese Attribute gefiltert. Und das erklärt, warum wir den aktuellen day8217s Kontext noch für jede Zeile vorhanden sind. Um die Dinge klar zu machen, solange wir diesen Ausdruck außerhalb eines Datumskontexts auswerten, ist alles in Ordnung, da die folgende DAX-Abfrage bei der Ausführung von Management Studio im Internet Sales-Perspektive unseres Modells (unter Verwendung der tabellarischen Datenbank mit denselben Daten) angezeigt wird ): Auswertung (160160160160160160160160160160160160160160160. Summe (Internet SalesSales Betrag) 160160160)) Hier habe ich den Zeitraum reduziert. (160160160160160160160160160.dieAngebotSumquot 160160160160160160160.) Bis 5 Tage und auch ein festes Datum als LastDate (8230) würde dazu führen, dass das letzte Datum meiner Datum Dimensionstabelle, für die keine Daten in den Beispieldaten vorhanden sind. Hier ist das Ergebnis aus der Abfrage: Nach dem Einfügen eines Filters auf 2003 werden jedoch keine Datenzeilen außerhalb von 2003 in die Summe einbezogen. Dies erklärt die obige Bemerkung: Es sah so aus, als hätten wir nur ab dem 1. Januar 2003 Daten. Und jetzt wissen wir warum: Das Jahr 2003 war auf dem Filter (wie man in der ersten Screenshots dieses Beitrags sehen kann) und Daher war es bei der Berechnung der Summe vorhanden. Nun ist alles, was wir tun müssen, um diese zusätzlichen Filter loszuwerden, weil wir unsere Ergebnisse bereits nach Datum filtern. Der einfachste Weg, dies zu tun, ist, die Berechnungsfunktion zu verwenden und ALLE (8230) für alle Attribute anzuwenden, für die wir den Filter entfernen wollen. Da wir einige dieser Attribute (Jahr, Monat, Tag, Wochentag, 8230) haben und wir den Filter von allen, aber das Datumsattribut entfernen wollen, ist die Verknüpfungsfunktion ALLEXCEPT hier sehr nützlich. Wenn du einen MDX-Hintergrund hast, wirst du dich fragen, warum wir bei der Verwendung von SSAS im OLAP-Modus (BISM Multidimensional) kein ähnliches Problem haben. Der Grund dafür ist, dass unsere OLAP-Datenbank Attributbeziehungen hat, also nach dem Festlegen des Datums (Key) Attributs werden die anderen Attribute auch automatisch geändert und wir müssen uns darum kümmern (siehe meinen Beitrag hier). Aber im tabellarischen Modell haben wir keine Attributbeziehungen (nicht einmal ein wahres Schlüsselattribut) und deshalb müssen wir unerwünschte Filter aus unseren Berechnungen eliminieren. Also hier sind wir mit dem 8230 Verkaufsbetrag (30d avg): AverageX (160 Summarize (160160160 dateinperiod (DateDate, LastDate (DateDate), - 30, DAY) 160160160, DateDate 160160160. quotSalesAmountSumquot 160160160. berechnen (Summe (Internet SalesSales Betrag) , ALLEXCEPT (Date, DateDate)) 160), SalesAmountSum) Und das ist unsere letzte Pivot-Tabelle in Excel: Um den gleitenden Durchschnitt zu veranschaulichen, ist hier der gleiche Datenextrakt in einer Chartansicht (Excel): Obwohl wir unsere Daten gefiltert haben 2003 der gleitende Durchschnitt für die ersten 29 Tage des Jahres 2003 korrekt die entsprechenden Tage des Jahres 2002 berücksichtigt. Sie erkennen die Werte für den 30. und 31. Januar von unserem ersten Ansatz, da dies die ersten Tage waren, für die unsere erste Berechnung eine ausreichende Menge an Daten hatte (volle 30 Tage). Ich versuche, einen gleitenden Durchschnitt in meinem Modell zu schaffen. Auf der Suche nach etwas Hilfe. Ich habe versucht, die Details in Alberto Ferraris Blog hier. Aber ich konnte nicht die DayNumber Maßnahme, die Syntax nicht richtig und ich konnte es nicht korrigieren. Mein Modell hat eine Fact-Tabelle mit einer Liste von Fällen, die sich mit einer Date-Tabelle über das Erstellungsdatum verbinden. Ich habe eine zweite Beziehung (Inaktiv) zur Datumstabelle in der Spalte ClosedDate. Ich habe eine Maßnahme: Fall Geschlossen Graf: BERECHNUNG (COUNTROWS (Fall), USERELATIONSHIP (CaseClosedDateKey, DateDateKey)). Ich möchte eine Maßnahme, die die Summe von Case Closed Count für die letzten drei Tage des aktuellen Kontextes erhält. Ich plane dann, diese Nummer um 3 zu teilen, um den bewegten 3-Tage-Durchschnitt zu bekommen. Eine andere Logik, die ich mir vorstellen möchte - wenn der letzte Tag HEUTE ist, dann werden die vorherigen 3 Tage benutzt - die Daten werden alle 15 Minuten aktualisiert, so dass dies um 09:00 Uhr morgens im Durchschnitt geschrumpft wird Es ist kein vollkommener Tag. Jede Hilfe wird geschätzt. Sonntag, 17. Februar 2013 um 5:25 Uhr Heres ein Link zu einem Ansatz mit nur einer berechneten Maßnahme, die Javier Guillen eine Weile zurückschrieb. Ich hoffe, das hilft. Brent Greenwood, MS, MCITP, CBIP Bitte markieren Sie korrekte Antworten und hilfreiche Beiträge brentgreenwood. blogspot Bearbeitet von Brent Greenwood Editor Montag, 18. Februar 2013 um 16:08 Uhr Vorgeschlagen als Antwort von Ed Price - MSFT Microsoft Mitarbeiter, Besitzer Donnerstag, August 22, 2013 7:39 PM Markiert als Antwort von Ed Price - MSFT Microsoft Mitarbeiter, Besitzer Dienstag, 17. September 2013 06:39 Uhr In seinem Beitrag verwendet Alberto die EARLIER-Funktion, die zurückkehrt Ein Wert aus einem früheren Zeilen-Kontext. Dies funktioniert nur in einem iterierenden Ausdruck, wenn dieser Ausdruck in einem vorhandenen Zeilenkontext ausgewertet wird (ein anderer iterierender Ausdruck oder eine berechnete Spalte). Entspricht folgendes die Anforderung (nicht getestet) Fall Geschlossener Zähler - Letzte 3 Tage: BERECHNUNG ( (DATEADD (DateDateKey, -3, Day) DateDateKey)) Die letzte kann mit einem IF-Ausdruck mit der TODAY () - Funktion und dem Anpassen des obigen Musters getan werden.) DATUMBETWEIN (DATEADD (DateDateKey, -3, Day) DateDateKey) Vorgeschlagen als Antwort von Ed Price - MSFT Microsoft Mitarbeiter, Besitzer Donnerstag, 18. August 2013 07:40 Uhr Heres ein Link zu einem Ansatz mit nur eine berechnete Maßnahme, dass Javier Guillen schrieb eine Weile zurück . Ich hoffe, das hilft. Brent Greenwood, MS, MCITP, CBIP Bitte markieren Sie korrekte Antworten und hilfreiche Beiträge brentgreenwood. blogspot Bearbeitet von Brent Greenwood Editor Montag, 18. Februar 2013 um 16:08 Uhr Vorgeschlagen als Antwort von Ed Price - MSFT Microsoft Mitarbeiter, Besitzer Donnerstag, August 22, 2013 7:39 PM Markiert als Antwort von Ed Price - MSFT Microsoft Mitarbeiter, Besitzer Dienstag, 17. September 2013 06:39 Montag, 18. Februar 2013 04:08 PMSQL Server Denali PowerPivot Alberto Ferrari schrieb bereits über die Berechnung der Bewegungsdurchschnitte im DAX Indem man eine berechnete Spalte verwendet. Id möchte hier einen anderen Ansatz vorstellen, indem wir eine berechnete Maßnahme verwenden. Für den gleitenden Durchschnitt Im berechnen einen täglichen gleitenden Durchschnitt (in den letzten 30 Tagen) hier. Für mein Beispiel verwende ich die PowerPivot-Arbeitsmappe, die als Teil der SSAS-Tabularmodellprojekte aus den Denali CTP 3-Samples heruntergeladen werden kann. In diesem Beitrag, Im Entwicklung der Formel Schritt für Schritt. Allerdings, wenn Sie in Eile sind, können Sie direkt zu den endgültigen Ergebnissen unten zu springen. Mit dem Kalenderjahr 2003 auf dem Filter, dem Datum auf Spalten und dem Verkaufsbetrag (aus Tabelle Internet Sales) in den Details sehen die Beispieldaten wie folgt aus: In jedem Zeilenkontext gibt der Ausdruck 8216DateDate den aktuellen Kontext, dh das Datum für diese Zeile . Aber aus einer berechneten Maßnahme können wir nicht auf diesen Ausdruck verweisen (da es keine aktuelle Zeile für die Date-Tabelle gibt), stattdessen müssen wir einen Ausdruck wie LastDate (8216DateDate) verwenden. Also, um die letzten dreißig Tage zu bekommen, können wir diesen Ausdruck verwenden. Wir können nun unsere Internet-Verkäufe für jeden dieser Tage zusammenfassen, indem wir die zusammenfassende Funktion verwenden: Zusammenfassend (DFLEFTIGE (127DateDate, LastDate (8216DateDate), - 30, DAY) Es wurde schließlich die DAX-Funktion AverageX verwendet, um den Durchschnitt dieser 30 Werte zu berechnen: Verkaufsbetrag (30d avg): AverageX (Summarize (DatesInPeriod (8216DateDate, LastDate (8216DateDate), - 30, DAY) 8220SalesAmountSum8221 Summe (8216Internet SalesSales Betrag)), SalesAmountSum) Dies ist die Berechnung, die wir in unserer Internet-Verkaufstabelle verwenden, wie im Screenshot unten gezeigt: Wenn Sie diese Berechnung der Pivot-Tabelle von oben hinzufügen, Das Ergebnis sieht so aus: Betrachtet man das Ergebnis, so scheint es, dass wir vor dem 1. Januar 2003 keine Daten haben: Der erste Wert für den gleitenden Durchschnitt ist identisch mit dem Tageswert (es gibt keine Zeilen vor diesem Datum). Der zweite Wert für den gleitenden Durchschnitt ist eigentlich der Durchschnitt der ersten beiden Tage und so weiter. Das ist nicht ganz richtig, aber ich komme dieses Problem in einer Sekunde zurück. Der Screenshot zeigt die Berechnung für den gleitenden Durchschnitt am 31. Januar als Durchschnitt der Tageswerte vom 2. bis 31. Januar. Unsere berechnete Maßnahme funktioniert auch bei der Anwendung von Filtern. Im folgenden Screenshot habe ich zwei Produktkategorien für die Datenreihe verwendet: Wie funktioniert unsere berechnete Maßnahme auf höhere Aggregationsebenen Um herauszufinden, dass ich die Kalenderhierarchie in den Zeilen (anstelle des Datums) verwende. Zur Vereinfachung habe ich das Semester - und Viertelniveau mit Excels-Pivot-Tabellenoptionen (ShowHide-Felder) entfernt. Wie Sie sehen können, funktioniert die Berechnung noch gut. Hier ist das monatliche Aggregat der gleitende Durchschnitt für den letzten Tag des jeweiligen Monats. Sie sehen das deutlich für Januar (Wert von 14.215.01 erscheint auch im Screenshot oben als Wert für 31. Januar). Wenn dies die geschäftliche Anforderung (die für einen Tagesdurchschnitt klingt) klingt, dann funktioniert die Aggregation auf einer monatlichen Ebene gut (sonst müssen wir unsere Berechnung fein abgestimmt haben und das wird ein Thema der kommenden Post sein). Aber obwohl die Aggregation auf einer monatlichen Ebene sinnvoll ist, wenn wir diese Ansicht auf die Tageshöhe ausdehnen, sehen wir, dass unsere berechnete Maßnahme einfach den Verkaufsbetrag für diesen Tag zurückgibt, nicht den Durchschnitt der letzten 30 Tage mehr: Wie kann das sein. Das Problem ergibt sich aus dem Kontext, in dem wir unsere Summe berechnen, wie im folgenden Code hervorgehoben: Verkaufsbetrag (30d avg): AverageX (Summarize (dateinperiod (8216DateDate, LastDate (8216DateDate), - 30, DAY), 8217DateDate 8220SalesAmountSum8221. Summe (8216Internet SalesSales Betrag)), SalesAmountSum) Da wir diesen Ausdruck über den angegebenen Zeitraum auswerten, ist der einzige Kontext, der hier überschrieben wird, 8216DateDate. In unserer Hierarchie verwendeten wir verschiedene Attribute aus unserer Dimension (Kalenderjahr, Monat und Tag des Monats). Da dieser Kontext noch vorhanden ist, wird die Berechnung auch durch diese Attribute gefiltert. Und das erklärt, warum wir den aktuellen Tag Kontext noch für jede Zeile vorhanden sind. Um die Dinge klar zu machen, solange wir diesen Ausdruck außerhalb eines Datumskontexts auswerten, ist alles in Ordnung, da die folgende DAX-Abfrage bei der Ausführung von Management Studio im Internet Sales-Perspektive unseres Modells (unter Verwendung der tabellarischen Datenbank mit denselben Daten) angezeigt wird (8216DateDate, Datum (2003,1,1), - 5, DAY), 8217DateDate 8220SalesAmountSum8221 Summe (8216Internet SalesSales Betrag))) Hier habe ich den Zeitraum auf 5 Tage reduziert und auch eingestellt Ein festes Datum als LastDate () würde zum letzten Datum meiner Datumsdimensionstabelle führen, für die in den Beispieldaten keine Daten vorhanden sind. Hier ist das Ergebnis aus der Abfrage: Nach dem Einfügen eines Filters auf 2003 werden jedoch keine Datenzeilen außerhalb von 2003 in die Summe einbezogen. Dies erklärt die obige Bemerkung: Es sah so aus, als hätten wir nur ab dem 1. Januar 2003 Daten. Und jetzt wissen wir warum: Das Jahr 2003 war auf dem Filter (wie man in der ersten Screenshots dieses Beitrags sehen kann) und Daher war es bei der Berechnung der Summe vorhanden. Nun, alles was wir tun müssen, ist, diese zusätzlichen Filter loszuwerden, weil wir bereits unsere Ergebnisse nach Datum gefiltert haben. Der einfachste Weg, dies zu tun, ist, die Berechnungsfunktion zu verwenden und ALL () für alle Attribute anzuwenden, für die wir den Filter entfernen wollen. Da wir einige dieser Attribute (Jahr, Monat, Tag, Wochentag) haben und wir den Filter von allen, aber das Datumsattribut entfernen wollen, ist die Verknüpfungsfunktion ALLEXCEPT hier sehr nützlich. Wenn Sie einen MDX-Hintergrund haben, werden Sie sich fragen, warum wir bei der Verwendung von SSAS im OLAP-Modus (BISM Multidimensional) kein ähnliches Problem haben. Der Grund dafür ist, dass unsere OLAP-Datenbank Attributbeziehungen hat, also nach dem Festlegen des Datums (Key) Attributs werden die anderen Attribute auch automatisch geändert und wir müssen uns nicht darum kümmern (siehe meinen Beitrag hier). Aber im tabellarischen Modell haben wir keine Attributbeziehungen (nicht einmal ein wahres Schlüsselattribut) und deshalb müssen wir unerwünschte Filter aus unseren Berechnungen eliminieren. Also hier sind wir mit dem Verkaufsbetrag (30d avg): AverageX (Summarize (dateinperiod (8216DateDate, LastDate (8216DateDate), - 30, DAY), 8217DateDate 8220SalesAmountSum8221 berechnen (Summe (8216Internet SalesSales Betrag), ALLEXCEPT (8216Date8217,8217DateDate )), SalesAmountSum) Und das ist unsere letzte Pivot-Tabelle in Excel: Um den gleitenden Durchschnitt zu veranschaulichen, ist hier der gleiche Datenextrakt in einer Chartansicht (Excel): Obwohl wir unsere Daten auf 2003 den gleitenden Durchschnitt für den ersten gefiltert haben 29 tage von 2003 korrekt die entsprechenden tage von 2002 berücksichtigt. Sie erkennen die Werte für den 30. und 31. Januar von unserem ersten Ansatz, da dies die ersten Tage waren, für die unsere erste Berechnung eine ausreichende Datenmenge (volle 30 Tage) hatte.