Berechnungsreihenfolge für dynamische Berechnung ändern

Dynamische Berechnung optimiert die Performance der Batchberechnung und ändert die Reihenfolge, in der Essbase Werte berechnet. Sparse-Dimensionen werden zuerst berechnet. Vorsichtsmaßnahmen ergreifen, wenn Sie Dynamische Berechnung in asymmetrischen Datasets oder mit Two Pass-Elementen verwenden.

Wenn Sie dynamisch berechnete Datenwerte verwenden, ändert sich die Reihenfolge, in der Essbase die Werte berechnet. Dies kann Auswirkungen auf die Verwaltung des Cubes haben.

Berechnungsreihenfolge für dynamische Berechnung

Wenn Sie Dynamische Berechnung verwenden, berechnet Essbase zuerst Werte von Sparse-Dimensionen und dann Dense-Dimensionen. Dense-Werte werden in der Reihenfolge von Konten, Zeit, Zeitreihen, anderen dicht besetzten Dimensionen und schließlich Attributen berechnet.

Wenn Essbase Datenwerte dynamisch berechnet, berechnet es die Daten in einer anderen Reihenfolge als die Reihenfolge der Batchdatenbankberechnung.

Bei Batchberechnungen berechnet Essbase die Datenbank in der folgenden Reihenfolge:

  1. Dimension als Konten getaggt

  2. Dimension getaggt als Zeit

  3. Andere dicht besetzte Dimensionen (in der Reihenfolge, in der sie im Datenbank-Outline angezeigt werden)

  4. Andere Sparse-Dimensionen (in der Reihenfolge, in der sie im Datenbank-Outline angezeigt werden)

  5. Zweistufige Berechnungen

Siehe Berechnungsreihenfolge für Block Storage-Datenbanken.

Bei dynamisch berechneten Werten berechnet Essbase beim Abruf die Werte, indem die Datenbank in der folgenden Reihenfolge berechnet wird:

  1. Sparse-Dimensionen

    • Wenn die als Zeit getaggte Dimension dünn besetzt ist und die Datenbankmodellstruktur Zeitreihendaten verwendet, basiert Essbase die Sparse-Berechnung auf der Zeitdimension.

    • Andernfalls basiert Essbase die Berechnung auf der Dimension, die normalerweise für eine Batchberechnung verwendet wird.

  2. Dichte Dimensionen

    1. Als Accounts getaggte Dimension, falls dicht besetzt

    2. Als Zeit getaggte Dimension, falls dicht besetzt

    3. Zeitreihenberechnungen

    4. Verbleibende dichte Dimensionen

    5. Zweistufige Berechnungen

    6. Attribute

Wenn der Datenabruf Attributelemente verwendet, ist der letzte Schritt in der Berechnungsreihenfolge die Summierung der Attribute. Die Attributberechnung führt eine spontane Aggregation für Datenblöcke aus, die mit den in der Abfrage angegebenen Attributelementen übereinstimmen. Wenn die Abfrage zweistufige Berechnungselemente enthält, wendet die Attributberechnung die Elementformel für die zweistufige Berechnung an, nachdem alle aggregierten Werte erfasst wurden. Diese zweistufige Berechnung verwendet die Datenwerte aus der Attributberechnung, nicht die Werte in einem echten Datenblock.

Durch die Verwendung von Attributelementen in der Abfrage ignoriert Essbase den Wert des Elements "Zeitsaldo" in den dynamischen Berechnungen. Bei Abrufen, die keine Attribute verwenden, wird der Wert des Elements "Zeitsaldo" auf die Berechnungen angewendet. Der Unterschied in der Berechnungsprozedur zwischen der Verwendung und Nichtverwendung von Attributelementen generiert unterschiedliche Ergebnisse für alle Zeitelemente der oberen Ebene, die dynamisch berechnet werden.

Beim Abrufen ohne Attribute werden diese dynamisch berechneten Elemente im letzten Schritt berechnet und wenden daher die Zeitsaldenfunktion korrekt an. Bei Abrufen, die Attribute verwenden, ist die Summierung des Attributs jedoch der letzte angewendete Schritt. Die Differenz in der Berechnungsreihenfolge erzeugt zwei unterschiedliche, vorhersehbare Ergebnisse für Zeitelemente der oberen Ebene, die dynamisch berechnet werden.

Berechnungsreihenfolge für die dynamische Berechnung von zweistufigen Elementen

Dynamische Berechnung ändert die Reihenfolge, in der Essbase Werte berechnet. Treffen Sie Vorsichtsmaßnahmen, wenn Sie Dynamische Berechnung mit zwei Pass-Elementen verwenden. Verwenden Sie stattdessen den Hybridmodus mit der Lösungsreihenfolge.

Beachten Sie die folgenden Informationen, um sicherzustellen, dass Essbase das erforderliche Berechnungsergebnis generiert, wenn Datenwerte für Elemente dynamisch berechnet werden, die als Two-Pass gekennzeichnet sind (siehe Two-Pass-Berechnung).

Hinweis:

Verwenden Sie keine zweistufige Berechnung mit Hybridmodus-Cubes. Verwenden Sie nur Bestellung auflösen.

Wenn mehrere dicht besetzte Dimensionselemente der dynamischen Berechnung als Zwei-Pass-Element gekennzeichnet sind, führt Essbase die dynamische Berechnung im ersten Durchlauf aus und berechnet dann die Zwei-Pass-Elemente in dieser Reihenfolge:

  1. Two-Pass-Elemente in der Accounts-Dimension, sofern vorhanden

  2. Two-Pass-Elemente in der Zeitdimension, sofern vorhanden

  3. Zwei-Pass-Elemente in den verbleibenden dicht besetzten Dimensionen in der Reihenfolge, in der die Dimensionen in der Gliederung angezeigt werden

Nehmen wir beispielsweise in der Datenbank Sample.Basic Folgendes an:

  • Margin% in der Dense Measures-Dimension (die als Accounts getaggte Dimension) ist als Dynamische Berechnung und Two-Pass gekennzeichnet.

  • Die Abweichung in der Dense Scenario-Dimension ist mit Dynamische Berechnung und Two-Pass gekennzeichnet.

Essbase berechnet zuerst das Account-Dimensionselement. Essbase berechnet also die Gewinnspanne in % (aus der Measures-Dimension) und berechnet dann die Abweichung (aus der Scenario-Dimension).

Wenn es sich bei dem Szenario um eine dünn besetzte Dimension handelt, berechnet Essbase zuerst die Abweichung gemäß der regulären Berechnungsreihenfolge für dynamische Berechnungen. Essbase berechnet dann die Gewinnspanne in %. Siehe Berechnungsreihenfolge für dynamische Berechnung.

Diese Berechnungsreihenfolge liefert nicht das erforderliche Ergebnis, da Essbase die Gewinnspanne in % -> Abweichung anhand der Formel für "Gewinnspanne in %" und nicht anhand der Formel für "Abweichung" berechnen muss. Sie können dieses Problem vermeiden, indem Sie das Szenario zu einer dicht besetzten Dimension machen. Dieses Problem tritt nicht auf, wenn die Measures-Dimension (die Accounts-Dimension) dünn besetzt ist, da Essbase die Marge in % immer noch berechnet.

Berechnungsreihenfolge für asymmetrische Daten

Dynamische Berechnung von Essbase ist möglicherweise nicht für die Verwendung mit asymmetrischen Datasets geeignet. Prüfen Sie die Beispiele in diesem Thema anhand Ihres Anwendungsfalls.

Da sich die Berechnungsreihenfolge von Dynamische Berechnung von der von Batchberechnungen unterscheidet, erhalten Sie in einigen Cube-Modellstrukturen möglicherweise andere Berechnungsergebnisse, wenn Sie bestimmte Elemente als Dynamische Berechnung taggen. Diese Unterschiede treten auf, wenn Essbase asymmetrische Daten dynamisch berechnet.

Symmetrische Datenberechnungen erzeugen dieselben Ergebnisse, unabhängig davon, welche Dimension berechnet wird.

Mit dem Dataset im nachstehenden symmetrischen Beispiel ergibt die Berechnung für Qtr1-> Profit dasselbe Ergebnis, unabhängig davon, ob Sie die als Zeit getaggte Dimension oder die als Konten getaggte Dimension berechnen. Wenn Sie die Zeitdimension berechnen, fügen Sie die Werte für Jan, Feb und Mar hinzu:

50+100+150=300

Bei der Berechnung entlang der Accounts-Dimension subtrahieren Sie Qtr1 -> COGS von Qtr1 -> Umsatz: 

600–300=300

Tabelle 21-1: Beispiel einer symmetrischen Berechnung

Zeit -> Konten Jan Feb Mrz Qrt 1

Verkäufe

100

200

300

600

COGS

50

100

150

300

Gewinn (Umsatz - COGS)

50

100

150

300

Asymmetrische Datenberechnungen werden in verschiedenen Dimensionen unterschiedlich berechnet.

Anhand des Datasets im folgenden asymmetrischen Beispiel erzeugt die Berechnung für "Ost -> Umsatz" das richtige Ergebnis, wenn Sie entlang der Market-Dimension berechnen, aber bei der Berechnung entlang der Accounts-Dimension ein falsches Ergebnis. Die Berechnung entlang der Market-Dimension, indem die Werte für New York, Florida und Connecticut hinzugefügt werden, liefert die richtigen Ergebnisse:

50 + 100 + 100 = 250

Die Berechnung entlang der Accounts-Dimension durch Multiplizieren des Werts Ost -> Preis mit dem Wert Ost -> EinheitenVerkauft führt zu falschen Ergebnissen: 

15 * 50 = 750

Tabelle 21-2: Beispiel einer asymmetrischen Berechnung

Markt -> Konten New York Florida Connecticut Ost

Verkaufte Einheiten

10

20

20

50

Price

5

5

5

15

Umsatz (Preis * Verkaufte Einheiten)

50

100

100

250

Im folgenden Outline ist East eine dünn besetzte Dimension, und Accounts ist eine dicht besetzte Dimension:


Diese Abbildung zeigt eine Gliederung, in der East eine dünn besetzte Dimension und Accounts eine dicht besetzte Dimension ist.

Wenn East und Sales als Dynamische Berechnung gekennzeichnet sind, berechnet Essbase ein anderes Ergebnis als das Ergebnis, wenn East und Sales nicht als Dynamische Berechnung gekennzeichnet sind.

Wenn East und Sales keine dynamischen Berechnungselemente sind, liefert Essbase das richtige Ergebnis, indem die folgenden Dimensionen berechnet werden:

  1. Dense Accounts-Dimension – Berechnung der Werte für UnitsSold, Price und Sales für New York, Florida und Connecticut

  2. Dimension "Sparse East" – Aggregierung der berechneten Werte für "UnitsSold", "Price" und "Sales" für New York, Florida und Connecticut, um die Umsatzwerte für "Ost" zu erhalten

Wenn East und Sales Dynamic Calc-Elemente sind, erzeugt Essbase ein falsches Ergebnis, indem die folgenden Dimensionen berechnet werden:

  1. Dimension "Sparse East" - Aggregierung der Werte für "UnitsSold", "Price" und "Sales" für New York, Florida und Connecticut, um die Werte für "East" zu erhalten

  2. Werte für {\b East} -> {\b Sales} – die aggregierten Werte in den Datenblöcken {\b East} übernehmen und eine Formelberechnung mit diesen Werten durchführen, um den Wert für {\b Sales} zu erhalten

Um dieses Problem zu vermeiden und sicherzustellen, dass Sie die erforderlichen Ergebnisse erhalten, taggen Sie das Sales-Element nicht als Dynamische Berechnung.

Lösungsreihenfolge im Hybridmodus

Die Lösungsreihenfolge in Essbase bestimmt die Reihenfolge, in der die dynamische Berechnung im Hybridmodus ausgeführt wird. Sie können die Lösungsreihenfolge anpassen oder die Standardeinstellung akzeptieren, die für hohe Performance und Abhängigkeitsanalysen optimiert ist.

Das Konzept der Lösungsreihenfolge wird bei der Ausführung dynamischer Berechnungen angewendet, unabhängig davon, ob sie durch eine dynamische Elementformel oder eine dynamische Abhängigkeit in einem Berechnungsskript initiiert wurden. Wenn eine Zelle in einer mehrdimensionalen Abfrage ausgewertet wird, ist die Reihenfolge, in der die Berechnungen aufgelöst werden sollen, möglicherweise nicht eindeutig, es sei denn, die erforderliche Berechnungspriorität ist über eine Lösungsreihenfolge angegeben.

Sie können die Lösungsreihenfolge für Dimensionen oder Elemente festlegen oder die Essbase-Standardlösungsreihenfolge verwenden. Sie können für die Lösungsreihenfolge ein Minimum von 0 und ein Maximum von 127 festlegen. Eine höhere Lösungsreihenfolge bedeutet, dass das Element später berechnet wird. Beispiel: Ein Element mit der Lösungsreihenfolge 1 wird vor einem Element mit der Lösungsreihenfolge 2 berechnet.

Wenn der Hybridmodus aktiviert ist, entspricht die Standardlösungsreihenfolge (auch als Berechnungsreihenfolge bezeichnet) am ehesten der von Block Storage-Datenbanken:

Dimensions-/Elementtyp Standard-Lösungsreihenfolgenwert
Gespeicherte Elemente 0
Sparse-Dimensionselemente 10
Dense Account-Dimensionselemente 30
Dense Time-Dimensionselemente 40
Dense Regular-Dimensionselemente 50
Attribute-Dimensionselemente 90
Zweistufige dynamische Elemente 100
Berechnete MDX-Elemente oder benannte Sets (in MDX mit definiert) 120

Zusammenfassend schreibt die Standardlösungsreihenfolge im Hybridmodus vor, dass gespeicherte Elemente vor dynamischen Berechnungselementen und Sparse-Dimensionen vor Dense-Dimensionen berechnet werden, und zwar in der Reihenfolge, in der sie in der Modellstruktur aufgeführt sind (von oben nach unten).

Dynamische Elemente (mit oder ohne Formeln), für die keine Lösungsreihenfolge angegeben ist, erben die Lösungsreihenfolge der zugehörigen Dimension, sofern sie nicht als zweistufig getaggt sind.

Zweistufige Berechnung ist eine Einstellung, die Sie im Block Storage-Modus auf Elemente mit Formeln anwenden können, die zweimal berechnet werden müssen, damit sie den korrekten Wert ergeben.

Hinweis:

Verwenden Sie keine zweistufige Berechnung mit Hybridmodus-Cubes. Verwenden Sie nur Bestellung auflösen.

Die zweistufige Berechnung kann im Hybridmodus nicht angewendet werden. Elemente, die als zweistufig getaggt sind, werden zuletzt berechnet, nach den Attributen. Im Hybridmodus müssen Sie eine benutzerdefinierte Lösungsreihenfolge statt der zweistufigen Berechnung implementieren, wenn die Standardlösungsreihenfolge nicht Ihren Anforderungen entspricht.

Die Standlösungsreihenfolge im Hybridmodus ist für die folgenden Szenarios optimiert:

  • Vorwärtsreferenzen, in denen eine dynamische Elementformel ein Element referenziert, das in der Reihenfolge der Modellstruktur später aufgeführt ist. Im Hybridmodus besteht keine Abhängigkeit von der Reihenfolge der Modellstruktur.

  • Die Aggregation von untergeordneten Werten basierend auf der Reihenfolge der Modellstruktur stimmt am ehesten mit der Aggregation mithilfe von äquivalenten Formeln überein.

  • Dynamische Dense-Elemente als Abhängigkeiten in Sparse-Formeln. Wenn eine Sparse-Formel im Hybridmodus ein dynamisches Dense-Element referenziert, wird die Referenz ignoriert, weil Sparse-Dimensionen zuerst berechnet werden. Um das zu ändern, weisen Sie der Sparse-Dimension einen höheren Lösungsreihenfolgenwert zu (sodass sie später berechnet wird) als der Dense-Dimension.

Lösungsreihenfolge anpassen

Wenn Sie das Verhalten der dynamischen Berechnungen im Hybridmodus anpassen müssen, können Sie dazu die Lösungsreihenfolge von Dimensionen und Elementen anpassen, ohne große Änderungen an der Modellstruktur vornehmen zu müssen.

Wenn Sie eine benutzerdefinierte Lösungsreihenfolge implementieren, wird dadurch die Standardlösungsreihenfolge außer Kraft gesetzt. Wenn Elemente oder Dimensionen die gleiche Lösungsreihenfolge aufweisen, wird der Konflikt anhand der Reihenfolge gelöst, in der sie in der Modellstruktur aufgeführt sind (von oben nach unten).

Die Lösungsreihenfolge des obersten Dimensionselements gilt für alle dynamischen Elemente in der Dimension, es sei denn, Sie passen die Lösungsreihenfolge für bestimmte Elemente an.

Um die Lösungsreihenfolge zu ändern, müssen Sie den Modellstruktureditor in der Essbase-Weboberfläche verwenden oder Smart View verwenden (siehe Solve-Reihenfolge eines ausgewählten POV ändern).

Sie können für die Lösungsreihenfolge ein Minimum von 0 und ein Maximum von 127 festlegen. Eine höhere Lösungsreihenfolge bedeutet, dass das betreffende Element später berechnet wird.

Anwendungsfälle für die Lösungsreihenfolge finden Sie in den Vorlagen für Lösungsreihenfolgen im technischen Abschnitt der Galerie der Anwendungsarbeitsmappen, die sich im Dateienkatalog in Essbase befinden.

Hinweise zur Lösungsreihenfolge in einem Nicht-Hybridmodus

In Aggregate Storage Cubes gilt Folgendes:

  • Die Lösungsreihenfolge ist für alle Dimensionen auf 0 gesetzt.

  • Die Aggregation wird in der Reihenfolge der Modellstruktur ausgeführt. Dabei gelten folgende Ausnahmen:

    • Gespeicherte Hierarchieelemente werden zuerst verarbeitet.
    • Dynamische Hierarchieelemente werden als Nächstes verarbeitet.

In Block Storage Cubes im Nicht-Hybridmodus lautet die Standardlösungsreihenfolge:

  • Sparse vor Dense

  • Accounts vor Time

  • Attribute zuletzt

Hinweis:

Wenn die Lösungsreihenfolge von Elementen der Dimension "Accounts" manuell höher als die Lösungsreihenfolge von Elementen der Dimension "Time" festgelegt wird, wird "Accounts" nach Dynamic-Time-Series-Elementen ausgewertet.