Beispiele: Inverse Formel zur Laufzeit
Im folgenden werden die Laufzeitaspekte inverser Formeln an Hand ausgewählter Beispiele erläutert. Wir setzen voraus, dass Sie eingabebereite und inverse Formeln im Query Designer anlegen können (siehe Eingabebereite Query, Beispiele: Inverse Formel und Inverse Formel definieren)
Wie in der Dokumentation zur Definition inverser Formeln im Query Designer beginnen wir mit dem Beispiel Durchschnittspreis. Wir nehmen an, dass Umsatz (Sales) und Menge (Sales Quantity) eingeschränkte Kennzahlen sind (wobei für Umsatz die Währung auf einen Wert eingeschränkt und eine initiale Mengeneinheit festgelegt ist und für Menge umgekehrt). Beide eingeschränkte Kennzahlen verwenden im Query Designer unter Planung auf Summen die Einstellung Eingegebenen Wert disaggregieren.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summenzeile Werkzeuge (Tools) nicht eingabebereit, weder für die eingeschränkten Kennzahlen Menge und Umsatz noch für die (eingabebereite) Formel Durchschnittspreis (Avg. Price). Die Formel Durchschnittspreis ist hier nicht eingabebereit, da alle Operanden dieser Formel nicht eingabebereit sind.

Wir verdeutlichen die allgemeinen Regeln am Beispiel der eingabebereiten Formel Durchschnittspreis (siehe oben Beispiel 1).
Wir nehmen an, dass der initiale (asymmetrische) Rechenmodus Anwendung findet.
Hier ist der Durchschnittspreis Träger der Formelgruppe, die aus folgenden Elementen besteht: Durchschnittspreis, Umsatz und Menge. Im Query Designer sind die folgenden beiden inversen Formeln definiert worden:
... 1. ‘Umsatz’ = ‘Durchschnittspreis’ * ‘Menge’ 2. ‘Menge’ = NDIV0(‘Umsatz’ / ‘Durchschnittspreis’) |
a. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde. Beide inverse Formeln können für die Formelinversion verwendet werden; das System nimmt die Formel mit der höchsten Formelpriorität, in diesem Falle die Umsatz-Formel.
b. Wir nehmen an, dass die Werte für den Durchschnittspreis und den Umsatz geändert wurden. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
c. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert und die Zelle Umsatz fixiert wurde. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
d. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde und die Zelle Umsatz nicht eingabebereit ist, z.B. weil diese Kennzahl durch eine Datenscheibe geschützt ist. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
e. Wir nehmen an, dass die Werte für den Umsatz oder Menge geändert wurden. Dann spielen inverse Formeln keine Rolle. Das System berechnet den Durchschnittspreis.
f. Wir nehmen an, dass der Wert für den Umsatz geändert und die Zelle Durchschnittspreis fixiert. In diesem Fall ist es eindeutig, dass das System die Umsatz-Formel berechnen muss.
Wir nehmen an, dass der symmetrische Rechenmodus Anwendung findet.
Hier ist der Durchschnittspreis Träger der Formelgruppe, die aus folgenden Elementen besteht: Durchschnittspreis, Umsatz und Menge. Im Query Designer sind die folgenden beiden inversen Formeln definiert worden; zusätzlich hat die Trägerformel die niedrigste Priorität:
... 1. ‘Umsatz’ = ‘Durchschnittspreis’ * ‘Menge’ 2. ‘Menge’ = NDIV0(‘Umsatz’ / ‘Durchschnittspreis’) 3. ‘Durchschnittspreis’ (Trägerformel) |
...
a. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde. Beide inverse Formeln können für die Formelinversion verwendet werden; das System nimmt die Formel mit der höchsten Formelpriorität, in diesem Falle die Umsatz-Formel.
b. Wir nehmen an, dass die Werte für den Durchschnittspreis und den Umsatz geändert wurden. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
c. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert und die Zelle Umsatz fixiert wurde. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
d. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde und die Zelle Umsatz nicht eingabebereit ist, z.B. weil diese Kennzahl durch eine Datenscheibe geschützt ist. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
e. Wir nehmen an, dass die Werte für den Umsatz geändert wurden. Damit wird die Berechnung der Formelgruppe angestoßen. Weil Menge eine höhere Priorität hat, wird Durchschnittspreis beibehalten und auf Menge zurückgerechnet.
f. Wir nehmen an, dass die Werte für den Menge geändert wurden. Damit wird die Berechnung der Formelgruppe angestoßen. Weil Umsatz die höchste Priorität hat, wird Durchschnittspreis beibehalten und auf Umsatz zurückgerechnet.
g. Wir nehmen an, dass der Wert für den Umsatz geändert und die Zelle Durchschnittspreis fixiert. In diesem Fall ist es eindeutig, dass das System die Umsatz-Formel berechnen muss.
In diesem Beispiel nutzen wir drei eingeschränkte Kennzahlen: Umsatz geplant, Umsatz Prognose, Umsatz aktuell. Wir möchten auch die prozentuale Abweichung des geplanten vom vorausberechneten sowie des geplanten vom aktuellen Umsatz planen. Daher legen wir zwei eingabebereite Formeln und die entsprechenden inversen Formeln an.
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom aktuellen Umsatz lautet:
%Dev (P,A) = NDIV0( ‘Umsatz geplant’ % ‘Umsatz aktuell’ ) |
Diese Formelgruppe hat als Elemente: ‘%Dev(P,A)’, Umsatz geplant und Umsatz aktuell.
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom prognostizierten Umsatz lautet:
%Dev (P,F) = NDIV0( ‘Umsatz geplant’ % ‘Umsatz Prognose’ ) |
Diese Formelgruppe hat als Elemente: ‘%Dev(P,F)’, Umsatz geplant und Umsatz Prognose.
Beide Formelgruppen enthalten das Element Umsatz geplant. Wir nehmen an, dass Umsatz aktuell und Umsatz Prognose nicht eingabebereit sind, z.B. weil die Vorausberechnung vom Planungsadministrator vorbereitet wurde. In diesem Fall sind eingabebereit: Umsatz geplant, ‘%Dev(P,A)’ und ‘%Dev(P,F)’. Das System braucht nur Inversionen von ‘%Dev(P,A)’ auf Umsatz geplant und von ‘%Dev(P,F)’ auf Umsatz geplant.
Produkt |
%Dev (P,F) |
%Dev (P,A) |
Umsatz geplant |
Umsatz Prognose |
Umsatz aktuell |
PC Medium |
0 |
10 → 20 |
110 |
110 |
100 |
PC Small |
0 → 10 |
10 |
220 |
220 |
200 |
PC High End |
0 → 10 |
10 → 20 |
330 Error |
330 |
300 |
Gesamt |
0 |
10 |
660 |
660 |
600 |
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil ‘→’. Für eine bessere Übersichtlichkeit enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
...
1. Wenn man ‘%Dev(P,A)’ für ‘PC Medium’ ändert, errechnet das System zuerst im PAI (process after input) den Umsatz geplant und dann im PBO (process before output) die prozentuale Abweichung ‘%Dev(P,F)’.
2. Wenn man ‘%Dev(P,F)’ für ‘PC Small’ ändert, errechnet das System zuerst im PAI den Umsatz geplant und dann im PBO die prozentuale Abweichung ‘%Dev(P,A)’.
3. Wenn man ‘%Dev(P,A)’ und ‘%Dev(P,F)’ in einem Schritt für ‘PC High End’ ändert, versucht das System, Umsatz geplant zu berechnen. Das ist für eine Formelgruppe möglich, bei der anderen aber versucht das System, zugleich auch Umsatz geplant abzugleichen. Dieses Verhalten führt zu einem Fehler, da die anderen Kennzahlen nicht eingabebereit sind und daher nicht über die Berechnung inverser Formeln geändert werden.
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Produkt |
%Dev (P,F) |
%Dev (P,A) |
Umsatz geplant |
Umsatz Prognose |
Umsatz aktuell |
PC Medium |
9.09 |
20 |
120 |
110 |
100 |
PC Small |
21.00 |
10 |
242 |
220 |
200 |
PC High End |
0.00 |
10 |
330 |
330 |
300 |
Gesamt |
4.84 |
15.34 |
692 |
660 |
600 |
In diesem Beispiel möchten wir Kosten einiger Kostenstellen planen. Wir nehmen an, wir haben zwei Kennzahlen Fixe Kosten und Variable Kosten. Fixe Kosten ist nicht eingabebereit, da wir in diesem Beispiel annehmen, dass wir diese Kosten nicht beeinflussen können. Variable Kosten werden geplant. Die Gesamtkosten sind die fixen Kosten zuzüglich der variablen Kosten. Vom vergangenen Jahr haben wir bereits die Gesamtkosten in einer eingeschränkten Kennzahl Kosten LY; hiervon interessieren uns die fixen und die variablen Kostenanteile nicht. Wir möchten allerdings die prozentuale Abweichung der Gesamtkosten von den Gesamtkosten des Vorjahres planen. Diese Überlegungen zusammenfassend, können wir zwei eingabebereite Formeln bilden:
‘Gesamtkosten’ = ‘Variable Kosten’ + ‘Fixe Kosten’ |
Diese Formelgruppe hat als Elemente: Gesamtkosten, Variable Kosten und Fixe Kosten.
Die andere eingabebereite Formel ist:
‘%Dev(T, LY) = ‘Gesamtkosten’ % ‘Kosten LY’ |
Diese Formelgruppe hat als Elemente: ‘%Dev(T,LY)l’, Gesamtkosten und Kosten LY.
Die beiden Formelgruppen sind ineinander geschachtelt, da die Formel Gesamtkosten auch in der Formel ‘%Dev(T,LY)’ verwendet wird.
Kostenstelle |
%Dev (T,LY) |
Gesamtkosten |
Variable Kosten |
Fixe Kosten |
Kosten LY |
4711 |
10 |
110 → 120 |
100 |
10 |
100 |
4712 |
10 → 20 |
220 |
200 |
20 |
200 |
4713 |
10 → 20 |
330 → 400 |
300 Error |
30 |
300 |
Gesamt |
10 |
660 |
600 |
60 |
600 |
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil ‘→’. Für eine bessere Übersichtlichkeit enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
...
1. Wenn man die Gesamtkosten für die Kostenstelle 4711 ändert, errechnet das System zuerst im PAI die Variablen Kosten und rechnet dann im PBO zurück auf die Gesamtkosten und die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’.
2. Wenn man die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ für die Kostenstelle 4712 ändert, errechnet das System zuerst im PAI die Gesamtkosten , weil die Formel eingabebereit ist. Diese implizite Änderung stößt die nächste Formelinversion an. Im Ergebnis berechnet das System auch die Variablen Kosten im PAI. Im PBO rechnet das System dann zurück auf die Gesamtkosten und auf die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’.
3. Wenn man die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ und die Gesamtkosten für die Kostenstelle 4713 in einem Schritt ändert, wurde zugleich auch der einzige eingabebereite Operand der Formel ‘%Dev(T,LY)’ geändert. Damit ist eine Formelinversion für die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ nicht möglich. Das System weist mit entsprechenden Fehlermeldungen darauf hin.
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Kostenstelle |
%Dev (T,LY) |
Gesamtkosten |
Variable Kosten |
Fixe Kosten |
Kosten LY |
4711 |
20 |
120 |
110 |
10 |
100 |
4712 |
20 |
240 |
220 |
20 |
200 |
4713 |
10 |
330 |
300 |
30 |
300 |
Gesamt |
15 |
690 |
630 |
60 |
600 |
Im folgenden zeigen wir ein noch komplexeres Beispiel, indem wir mehrere Werte auf verschiedenen Ebenen des Resultsets in einem Schritt ändern. Wir nehmen an, die folgende Formel hat die höchste Priorität:
‘Menge’ = NDIV0( ‘Umsatz’ / ‘Durchschnittspreis’ ) |
Wie durch die Pfeile ‘ → ’ angezeigt, wurden in der folgenden Tabelle einige Zahlen auf verschiedenen Summationsstufen in einem Schritt geändert. Beachten Sie, dass das System hier zuerst die inversen Formeln aller Ebenen berechnet und dann geänderte oder berechnete Werte auf die Basiskennzahlen disaggregiert.
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 |
3 |
1333.33 → 800 |
PC Small |
4000.00 |
4 → 3 |
1000.00 → 500 |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 |
10 |
1200.00 → 1000 |
Diese Änderungen stoßen die folgenden Berechnungen an:
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 (zeitweilig fixiert) |
4000.00 / 800 (Priorität) |
1333.33 → 800 |
PC Small |
3 * 500 |
4 → 3 |
1000.00 → 500 |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 (zeitweilig fixiert) |
12000.00 / 1000 (Priorität) |
1200.00 → 1000 |
Das Zwischenergebnis ist folgendes:
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 (zeitweilig fixiert) |
5 (berechnet) |
800 (geändert) |
PC Small |
1500 (berechnet) |
3 (geändert) |
500 (geändert) |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 (zeitweilig fixiert) |
12 (berechnet) |
1000 (geändert) |
Die Mengen-Spalte enthält einen geänderten Gesamt -Wert und Änderungen von Werten auf niedrigeren Ebenen. Das System beginnt daher die Disaggregation von 12 – ( 5 + 3 ) = 4 für den einzigen unveränderten Wert des Produktes ‘PC High End’.
Die Umsatz-Spalte enthält (durch Berechnungen in den jeweiligen Zeilen) zeitweilig fixierte Werte und einen geänderten Wert. Das System beginnt daher die Disaggregation von 12000 – ( 4000 + 1500 ) = 6500 für den einzigen unveränderten Wert des Produktes ‘PC High End’.
Das Ergebnis der Berechnung der inversen Formeln und der Disaggregation ist folgendes:
Product |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 |
5 |
800.00 |
PC Small |
1500.00 |
3 |
500.00 |
PC High End |
6500.00 |
4 |
1625.00 |
Total |
12000.00 |
12 |
1000.00 |
Wir erläutern die Laufzeitaspekte des Beispiels Prozentualer Anteil %GT (siehe Beispiele: Inverse Formel, Beispiel 2).
Wir nehmen an, dass der Betrag eine Basis-Kennzahl mit der Verteilungsart für Disaggregation Analogverteilung (zu sich selbst) ist.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summe der Spalte Prozentualer Anteil des Betrages in Hinsicht auf die Gesamtsumme (% Contribution) nicht eingabebereit, da der entsprechende Wert immer 100% ist. Alle übrigen Zellen sind eingabebereit mit Ausnahme der Werte für die Produkte Comes after C++ und MMIX by D.E. Knuth und die Teilsummen für diese Produkte. Die Basis-Kennzahl Betrag (Amount) wird durch eine Datenscheibe geschützt. Im Ergebnis ist auch die Eingabebereitschaft für Prozentualer Anteil (% Contribution) ausgeschaltet: Die Eigenschaft “nicht eingabebereit” wurde durch die Formel %GT von dem Operanden Betrag (Amount) geerbt. Zusätzlich wurde die Eigenschaft “nicht eingabebereit” von der Teilsumme Tools geerbt, da alle Kinder dieses Hierarchieknotens nicht eingabebereit sind.

Der Wert von %GT für die Gesamtsumme ist immer 100%; daher ist das Gesamtergebnis nicht eingabebereit. So bleibt der Wert für %GT auch 100%, wenn man z.B. einen Filter (auf der Achse) für Personal Computer verwendet. Berechnungen mit %GT sind noch möglich, wenn keine Teilsummen, Summen oder Hierarchieknoten angezeigt werden. Es ist auch möglich, die Kennzahl op, in unserem Beispiel Betrag (Amount), auszublenden; der Operand op, hier Betrag (Amount), muss dann aber eingabebereit sein.
Wenn beide, sowohl der Operand op, in unserem Beispiel Betrag (Amount), als auch %GT für dieselbe Ebene in einem einzigen Interaktionsschritt geändert werden, weist das System darauf mit Fehlermeldungen hin. Möglich ist hingegen, das Gesamtergebnis für op, d.h. Betrag (Amount), und die Werte für %GT auf einer tieferen Ebene zu ändern. In diesem Fall nimmt das System den neuen Wert für das Gesamtergebnis und den geänderten Wert %GT, um den neuen Wert für den Operanden op, d.h. Betrag (Amount), auf der tieferen Ebene zu berechnen. Diese beiden Änderungen stoßen eine Disaggregation für den Operanden op, d.h. Betrag (Amount), an.
Das Gesamtergebnis für Betrag (Amount) darf nicht gleich Null sein. Falls das nicht der Fall ist, sind %GT-Zellen nicht eingabebereit.
Werte für %GT können auch außerhalb des Bereichs von 0 bis 100 liegen; im allgemeinen wird dies – nach Disaggregation – zu negativen Werten für den Operanden, d.h. Betrag (Amount), führen.