Was ist Like-for-Like (L4L)
um sicherzustellen, dass nur vergleichbare Elemente verglichen werden.
Elemente können Produkte, Geschäfte, Kundengruppen usw. sein.
Hier können Sie a lesen gute Erklärung zu diesem Thema.
Im aktuellen Fall werde ich eine Lösung für Geschäfte bauen.
Geschäfte können wegen Renovierungsarbeiten, Reparaturen oder aus anderen Gründen öffnen, schließen oder sogar vorübergehend geschlossen werden.
Daher können Filialen beim Vergleich aktueller Ergebnisse mit denen des Vorjahres vergleichbar oder nicht vergleichbar sein. Das bedeutet, dass ein Store, der für einen bestimmten Zeitraum im Vorjahr nicht aktiv struggle, im aktuellen Jahr, in dem er für denselben Zeitraum aktiv struggle, nicht vergleichbar ist.
L4L stellt sicher, dass ein Berichtsbenutzer auswählen kann, ob nicht vergleichbare Geschäfte einbezogen oder ausgeschlossen werden sollen.
Um den L4L-Standing auszuwählen, erstelle ich eine DIM_L4L-Tabelle:
Ich kann die Spalten L4L_Test und Cause als Hierarchie in einem Slicer oder in einem Matrix-Visible verwenden.
Die Geschäfte
Ich habe einige Geschäfte aus dem ContosoRetailDW-Datensatz ausgewählt (Particulars zum ContosoRetailDW-Datensatz im Abschnitt „Referenzen“ unten).
In diesem Fall habe ich mich für die Geschäfte in Italien entschieden.
Hier ist die Liste der italienischen Geschäfte mit den Öffnungs- und Schließungsdaten und den zugewiesenen L4L-Staaten:
In dieser Tabelle habe ich zwei Spalten mit den Öffnungs- und Schließungsterminen zum Monatsende für jedes Geschäft hinzugefügt.
In dieser Tabelle sind alle Filialen aufgeführt, die nicht vergleichbar sind.
Wie Sie sehen, haben die Geschäfte 224 und 226 einen Eröffnungstermin im Jahr 2024, 222 einen Schließungstermin im Jahr 2024 und 222 und 225 waren in den Jahren 2023 und 2024 vorübergehend geschlossen.
Alle anderen Shops werden während der Datenvorbereitung für die Lösung auf vergleichbar (L4LKey = 1) gesetzt.
Worauf Sie achten sollten
Was sind additionally die Anforderungen?
- Wir blicken immer auf das vergangene Jahr zurück. Im Jahr 2025 blicken wir auf das Jahr 2024 und im Jahr 2024 auf das Jahr 2023.
- Der Benutzer muss in der Lage sein, jeden der L4L-Zustände auszuwählen. Wenn kein Bundesstaat ausgewählt ist, werden die Daten nicht gefiltert und alle Geschäfte werden angezeigt.
- Wir wollen die Ergebnisse professional Monat kontrollieren. Es besteht keine Notwendigkeit, die Tagesergebnisse zu ändern.
- Wenn ein Geschäft im Vorjahr seinen Standing von 1 (vergleichbar) in einen anderen ändert, müssen die Daten im aktuellen Jahr gefiltert werden.
Beispielsweise wird im August 2024 ein Geschäft eröffnet. Wenn wir uns nur die Vergleichsdaten für 2025 ansehen, sollten wir für Januar bis Juli 2025 keine Ergebnisse sehen. - Die in den Berichten verwendeten Maßnahmen sollten nicht geändert werden, um die erforderlichen Ergebnisse widerzuspiegeln.
Aufbereitung der Daten
Zuerst muss ich eine Tabelle erstellen, die alle Monate enthält. Darüber hinaus muss es das erste und letzte Datum für jeden Monat im laufenden Jahr und im Vorjahr enthalten.
Dazu erstelle ich eine Tabelle als Referenz aus der Datumstabelle in Energy Question.
Ich behalte nur die folgenden Spalten und entferne alle anderen:
- Monatsschlüssel
- MonthKeyPY
- FirstDayOfMonth
- LastDayOfMonth
- FirstDayOfMonthPY
- LastDayOfMonthPY
Danach entferne ich alle Duplikate.
Die Tabelle L4L_Months sieht folgendermaßen aus:
Als Nächstes habe ich die Lösung in Energy Question erstellt, indem ich die Tabellen „Retailer“, „L4L_Months“ und die Tabelle mit den „Shops“ und den Eröffnungs- und Schließdaten (Tabellenname: L4L_Dates) kombiniert habe.
Erstellen der Energy Question-Lösung
Ich habe aus der Tabelle „Retailer“ eine referenzierte Tabelle erstellt und sie in „Bridge_L4L“ umbenannt.
Ich entferne alle Spalten außer der StoreKey-Spalte.
Als nächstes benötige ich eine Zeile für jeden Retailer und jeden Monat.
Dazu füge ich eine Spalte für die Tabelle L4L_Months hinzu:
Wenn ich alle Spalten der Tabelle L4L_Month erweitere, erhalte ich eine Tabelle mit einer Zeile für jede Kombination aus Geschäft und Monat:
Jetzt erscheint jedes Geschäft mehrmals in der Liste. Um für jedes Geschäft einen eindeutigen Schlüsselwert zu haben, füge ich eine StoreMonthKey-Spalte hinzu:
Als nächstes bereite ich die Tabelle mit den Daten des Geschäfts namens „L4L_Dates“ vor.
Was die Bridge_L4L-Tabelle betrifft, habe ich die L4L_Months-Tabelle zur Shops-Tabelle hinzugefügt, die das Eröffnungs- und Schließungsdatum enthält (siehe Abbildung 2).
Auch hier erweitere ich wie zuvor alle Spalten der Tabelle L4L_Months.
Auch hier erscheint jedes Geschäft mehrfach in der Liste. Ich füge für jedes Geschäft den gleichen eindeutigen Schlüsselwert hinzu (StoreMonthKey):
Textual content.From((StoreKey)) & "_" & Textual content.From((MonthKey))An diesem Punkt verfüge ich über alle notwendigen Informationen, um die Zeilen mit dem richtigen L4L-Standing auszuwählen.
Ich muss dies entsprechend dem Eröffnungs- und Schlussdatum tun und sie mit den Spalten First- und LastDateOfMonthPY vergleichen, wobei ich die erforderliche Logik professional L4L-Standing verwende.
Dazu füge ich eine benutzerdefinierte Spalte mit dem folgenden Ausdruck hinzu:
if (L4LKey) = 2 and
(OpenDate) >= (FirstDayOfMonthPY)
then true
else if (L4LKey) = 3 and
(CloseDate) <= (LastDayOfMonthPY)
then true
else if (L4LKey) = 4 and ((OpenDate) >= (FirstDayOfMonthPY) and (CloseDate) <= (LastDayOfMonthPY))
then true
else falseIch nenne diese Spalte „Gültig“, da sie die richtigen Zeilen für jeden L4L-Zustand markiert.
Als Nächstes filtere ich die Daten, um nur die gültigen Zeilen beizubehalten:
Der nächste Schritt besteht darin, die Bridge_L4L-Tabelle mit der L4L_Dates-Tabelle unter Verwendung der zuvor erstellten StoreMonthKey-Spalten zusammenzuführen:
An dieser Stelle benötige ich nur die Spalte L4LKey aus den L4L_Dates in der Bridge_L4L-Tabelle:
Die meisten Zeilen enthalten eine Null in der Spalte L4LKey.
Alle diese Zeilen beziehen sich auf vergleichbare Filialen und Monate.
Aus diesem Grund ersetze ich alle Nullen durch 1:
Zuletzt habe ich alle Spalten bis auf die notwendigen Spalten entfernt:
Mit diesen Schritten habe ich die Tabelle Bridge_L4L erstellt, die als Filter basierend auf dem ausgewählten L4L-Standing dienen kann.
Was bleibt in Energy BI noch zu tun?
Jetzt muss ich die neue Tabelle Bridge_L4L zwischen den Tabellen Retailer und der Reality-Desk „Retail Gross sales“ platzieren.
Dann kann ich eine Beziehung vom neuen DIM_L4L zur Bridge_L4L-Tabelle hinzufügen.
Um jedoch eine Beziehung aus der Tabelle „Bridge_L4L“ zur Faktentabelle „Einzelhandelsumsätze“ hinzuzufügen, muss ich der Tabelle „Einzelhandelsumsätze“ denselben StoreMonthKey hinzufügen, um das Geschäft für jeden Monat eindeutig zu identifizieren.
Ich mache das in der SQL-Abfrage, um die Faktendaten abzurufen:
SELECT (F).(SaleLineCounter) AS (Sale Line Counter)
,CONVERT(date, DATEADD(yyyy, 16, (F).(DateKey))) AS (DateKey)
,(F).(channelKey)
,(F).(StoreKey)
,CONCAT(CONVERT(nvarchar(25), (F).(StoreKey))
,'_'
,CONVERT(nvarchar(25), YEAR(CONVERT(date, DATEADD(yyyy, 16, (F).(DateKey)))))
,RIGHT('00' + CONVERT(nvarchar(25), MONTH(CONVERT(date, DATEADD(yyyy, 16, (F).(DateKey))))), 2)
) AS (StoreMonthKey)
,(F).(ProductKey)
,(F).(PromotionKey)
,(F).(CurrencyKey)
,(F).(UnitCost)
,(F).(UnitPrice)
,(F).(SalesQuantity)
,(F).(ReturnQuantity)
,(F).(ReturnAmount)
,(F).(DiscountQuantity)
,(F).(DiscountAmount)
,(F).(TotalCost)
,(F).(SalesAmount)
,(F).(DateKeyYear)
FROM (dbo).(v_FactSales) AS (F);Jetzt bekomme ich diese Spalte in der Faktentabelle:
Nach alledem lautet das Datenmodell für die beteiligten Tabellen wie folgt:
Wie Sie sehen, habe ich, wie es sein sollte, nur unidirektionale Eins-zu-Viele-Beziehungen.
Die Ergebnisse
Nachdem ich dem Bericht eine visuelle Matrix mit der L4L-Hierarchie, den Filialen und den Monaten in den Spalten hinzugefügt habe, erhalte ich Folgendes für den Verkaufsbetrag für 2025:
Schauen wir uns die verschiedenen Szenarien an:
- Eröffnung der Shops Florenz und Mailand:
Ihre Eröffnungstermine waren im Mai und im Oktober 2024. Da diese Monate keine Verkäufe für den gesamten Monat enthalten, gelten sie als nicht vergleichbar. Wie Sie sehen können, wechselt der Verkauf zwischen den Zuständen „Nicht vergleichbar – Eröffnung“ und „Vergleichbar“. - Schließung des Shops Contoso Roma:
Das gleiche Bild hier. Das Geschäft in Rom wurde im August 2024 geschlossen. Alle Ergebnisse nach diesem Monat sind als vergleichbar sichtbar. Denken Sie daran, dass es sich hierbei um Demodaten handelt und es in der realen Welt keine Sonderangebote für November und Dezember geben wird. Dem Retailer können jedoch Kosten zugeordnet werden, wenn Sie diese beispielsweise in einem GuV-Bericht analysieren möchten. - Erfrischender Retailer Contoso Torino
Dieses Geschäft struggle zwischen März und Juli 2024 geschlossen. Daher müssen die Verkäufe in diesen Monaten als nicht vergleichbar angesehen werden.
Selbst wenn wir uns das Jahr 2024 ansehen, sehen wir, dass der Rome Retailer korrekt als Refresh gekennzeichnet ist und alle anderen Shops mit Ausnahme der Firenze- und Milan-Shops vergleichbar sind:
Die Ergebnisse entsprechen genau meinen Erwartungen.
Denken Sie daran, dass ich mit Demodaten arbeite und die Daten für geschlossene Geschäfte absichtlich nicht entfernt habe. Dadurch sind die Ergebnisse besser sichtbar.
Wie es anders geht
Dieser Ansatz funktioniert, es gibt jedoch auch andere Möglichkeiten. Es hängt von den Anforderungen ab, welcher Ansatz zu Ihrer State of affairs passt.
- Sie können diese Logik von Energy Question in die Programmiersprache Ihrer Wahl verschieben, z. B. SQL oder Python.
- Dieser Ansatz mit der Bridge-Tabelle ist großartig, da er es uns ermöglicht, die Beziehung zwischen dem Retailer und der Bridge-Tabelle auf bidirektionale Filterung einzustellen und die Shops auszublenden, die nicht zum ausgewählten L4L-Standing passen. Alle Faktentabellen sind mit der Bridge-Tabelle verknüpft, so dass keine zirkulären Abhängigkeiten entstehen können.
- Eine bessere Möglichkeit könnte darin bestehen, den L4L-Standing in die Faktentabelle(n) zu integrieren. Dies würde die Notwendigkeit der Bridge-Tabelle von vornherein vermeiden.
- Möglicherweise entscheiden Sie sich dafür, der Retailer-Dimensionslogik eine Historisierungslogik hinzuzufügen und ihr den L4L-Standing hinzuzufügen. In diesem Fall müssen Sie die L4L-Hierarchie in die Retailer-Tabelle aufnehmen. Dies könnte der beste Ansatz sein, da er eine Commonplace-SCD2-Logik beinhalten würde. Gleichzeitig handelt es sich um eine komplexere Wahl, da sie die Vorbereitung der Retailer-Dimensionstabelle komplexer macht.
Die Wahl des besten Modellierungsansatzes hängt von Ihren Anforderungen und Ihren Fähigkeiten ab.
Abschluss
Heute habe ich Ihnen gezeigt, wie Sie eine Like-for-Like-Lösung erstellen, um Geschäfte über Jahre hinweg zu vergleichen.
Das Ziel, eine Lösung ohne Änderungen an den DAX-Kennzahlen aufzubauen, wurde erreicht. Die gesamte Lösung ist vollständig datengesteuert.
Das ist ein wichtiges Thema. Eine DAX-gesteuerte Logik kann nicht nachhaltig sein, da sie die Notwendigkeit mit sich bringt, zusätzliche DAX-Logik in Ihr Datenmodell zu integrieren. Daran müssen Sie immer denken, wenn Sie neue Maßnahmen hinzufügen.
Darüber hinaus können Leistungsprobleme auftreten, da der Code möglicherweise komplexer und möglicherweise langsamer ist, als er ohne ihn wäre.
Ich bin ein großer Fan von datengesteuerten Lösungen. In den meisten Fällen sind sie besser als komplexer DAX-Code.
Ich hoffe, Sie haben etwas Neues und Interessantes gelernt. Bis bald hier.
Referenzen
Hier ein YouTube-Video von SQLBI über den Aufbau einer L4L-Lösung für Marken:
Wie in meinen vorherigen Artikeln verwende ich den Contoso-Beispieldatensatz. Sie können den ContosoRetailDW-Datensatz kostenlos von Microsoft herunterladen Hier.
Die Contoso-Daten können wie beschrieben unter der MIT-Lizenz frei verwendet werden in diesem Dokument. Ich habe den Datensatz aktualisiert, um die Daten auf aktuelle Daten zu übertragen, und alle für dieses Beispiel nicht benötigten Tabellen entfernt.