Essbase-Berechnungen definieren

Konsolidierung von Dimensionen und Elementen

Wenn Sie Elemente von Standarddimensionen definieren, taggt Essbase die Elemente automatisch mit dem Konsolidierungsoperator "+" (Pluszeichen für Addition). Das bedeutet, dass während der Konsolidierung Elemente hinzugefügt werden, um den Wert des übergeordneten Elements abzuleiten. Gegebenenfalls können Sie eine Elementkonsolidierungseigenschaft ändern.

Konsolidierung ist die am häufigsten verwendete Berechnung in Essbase. In diesem Thema wird die Product-Dimension zur Veranschaulichung von Konsolidierungen verwendet.

Die TBC-Anwendung verfügt über mehrere Konsolidierungspfade:

Einzelne Produkte werden in Produktfamilien zusammengefasst, und Produktfamilien werden in Produkt konsolidiert. Die TBC-Modellstruktur erfordert auch mehrere Konsolidierungspfade. Einige Produkte müssen in mehreren Kategorien konsolidiert werden.
Die Staaten werden in Regionen zusammengefasst, und die Regionen konsolidieren sich in den Markt.
Monate werden zu Quartalen summiert, Quartale zu Jahr konsolidiert.

Konsolidierungsoperatoren definieren, wie Essbase Daten für jedes Element in einer Verzweigung zum übergeordneten Element zusammenfasst. Beispiel: Mit dem Standardadditionsoperator (+) fügt Essbase 100‑10, 100‑20 und 100‑30 hinzu und speichert das Ergebnis in ihrem übergeordneten Element, 100, wie unten gezeigt.

Abbildung 1-7: TBC-Produktdimension

Diese Abbildung zeigt Konsolidierungsoperatoren in einer Gliederung, wie im Text vor dem Bild beschrieben.

Die Product-Dimension enthält hauptsächlich Additionsoperatoren (+), die angeben, dass jede Gruppe von Elementen hinzugefügt und zum übergeordneten Element zusammengefasst wird. Die Diät enthält einen Tilde-Operator (~), der angibt, dass Essbase das Diät-Element nicht in die Konsolidierung des übergeordneten Elements "Produkt" einbezieht. Das Diät-Mitglied besteht ausschließlich aus Mitgliedern, die geteilt werden. Die TBC-Produktmanagementgruppe möchte Diätgetränke in Berichten isolieren können, sodass TBC ein separates Diätmitglied erstellt hat, das sich nicht auf die Gesamtkonsolidierung auswirkt.

Auswirkung von Position und Operator auf Konsolidierung

Essbase berechnet die Daten einer Verzweigung in Top-down-Reihenfolge. Beispiel: Wenn zwei Elemente mit einem Additionsoperator (+) und ein drittes Element mit einem Multiplikationsoperator (*) gekennzeichnet sind, fügt Essbase die ersten beiden Elemente hinzu und multipliziert diese Summe mit dem dritten Element.

Da Essbase bei der Konsolidierung immer mit dem obersten Element beginnt, sind die Reihenfolge und die Labels der Elemente wichtig.

Konsolidierung gemeinsamer Elemente

Gemeinsame Elemente wirken sich auch auf Konsolidierungspfade aus. Mit dem gemeinsamen Elementkonzept können zwei Elemente mit demselben Namen dieselben Daten gemeinsam verwenden. Das gemeinsame Element speichert einen Zeiger auf Daten, die im anderen Element enthalten sind. Daher speichert Essbase die Daten nur einmal. Gemeinsame Elemente müssen in derselben Dimension enthalten sein. Daten können von mehreren Elementen gemeinsam verwendet werden.

Checkliste für Konsolidierung

Mit der folgenden Checkliste können Sie Konsolidierung definieren:

Haben Sie die Konsolidierungen in der Gliederung identifiziert?
Haben Sie jedes Element mit dem richtigen Konsolidierungsoperator versehen?
Haben Sie ein gemeinsames Member-Tag für angegebene Member angegeben?
Wären gemeinsame Elemente effizienter, wenn sie innerhalb einer Attribute-Dimension (mit Ausnahme von "Gemeinsam") erstellt werden?

Tags und Operatoren für Dimension "Beispielkennzahlen"

Die Measures-Dimension, die als Accounts getaggt ist, ist die komplexeste Dimension in der fiktiven TBC-Modellstruktur, da sie sowohl Zeit- als auch Kontendaten verwendet. Es enthält auch Formeln und spezielle Tags, mit denen Essbase die Modellstruktur berechnen kann.

Untersuchen Sie die von TBC definierten Measures-Dimensionstags. Viele der Eigenschaften der Measures-Dimension werden in den vorherigen Themen behandelt: Addition (+), Subtraktion (–) und keine Konsolidierungsoperatoren (~) sowie Konten und Label only-Tags:

Die Elementnamen {\b Inventory} und {\b Ratios} unterstützen den Benutzer bei der Datennavigation. Sie enthalten keine Daten und erhalten daher nur ein Label-Tag.
Die Measures-Dimension selbst hat nur ein Label-Tag. Einige Elemente von Kennzahlen haben ein Tag Dynamische Berechnung.
Einige Mitglieder von Measures haben ein Zeitsaldo-Tag (TB First oder TB Last).

Abbildung 1-8 Dimension für TBC-Kennzahlen

Diese Abbildung zeigt Elementeigenschaften, wie Konsolidierungsoperatoren und Tags, in der Dimension "BC-Kennzahlen", wie im Text vor dem Bild beschrieben.

Kontendimensionsberechnungen

Die als Konten getaggte Essbase-Dimension kann spezielle Eigenschaften verwenden, die sich auf Berechnungen auswirken. Zeitsalden-Tags oder -Eigenschaften enthalten Anweisungen für Essbase, wie Konten berechnet werden, die zeitperiodenabhängig sind. Abweichungsberichtseigenschaften definieren, wie Essbase die Differenz zwischen Ist- und Budgetdaten berechnet.

In diesem Thema werden zwei Berechnungsformen für eine als Accounts getaggte Dimension erläutert.

Zeitsaldoeigenschaften

Um Zeitsaldoeigenschaften verwenden zu können, müssen Sie eine Dimension als Accounts und eine andere als Time gekennzeichnet haben Die Tags "Erster", "Letzter", "Durchschnitt" und "Aufwand" sind ausschließlich für die Verwendung mit Accounts-Dimensionselementen verfügbar.

In der TBC Measures-Dimension stellt das Öffnen von Bestandsdaten den Bestand dar, den die TBC zu Beginn eines jeden Monats trägt. Der Quartalswert für "Eröffnungsbestand" entspricht dem Eröffnungswert für den ersten Monat im Quartal. Für das Öffnen des Bestands ist das Tag für den Zeitsaldo erforderlich, TB zuerst.

Die Endbestandsdaten stellen den Bestand dar, den die TBC am Ende jedes Monats trägt. Der Quartalswert für "Endbestand" entspricht dem Endwert für den letzten Monat im Quartal. Für "Bestand beenden" ist das Tag für den Zeitsaldo erforderlich, TB zuletzt. In der folgenden Tabelle werden die Zeitsalden-Tags für die Accounts-Dimension definiert.

Tabelle 1-6: Accounts Member-Tags

Tags	Beschreibung
Zeitsaldo zuletzt	Der Wert für das letzte untergeordnete Element wird in das übergeordnete Element übertragen. Beispiel: Der März wird in Qtr1 übertragen.
Zeitsaldo zuerst	Der Wert für das erste untergeordnete Element wird in das übergeordnete Element übertragen. Beispiel: Jan wird in Qtr1 übertragen.

In der folgenden Tabelle zeigen Qtr1 (zweite Spalte von rechts) und Year (rechts außenstehende Spalte), wie sich die Konsolidierung in der Zeitdimension auf die Zeitsaldeneigenschaften in der Accounts-Dimension auswirkt. Daten werden nur für das erste Quartal angezeigt.

Tabelle 1-7: TBC-Konsolidierungen, die von den Eigenschaften für Zeitsalden betroffen sind

Dimensionen	Jan	Feb	Mrz	Qrt 1	Jahr
Kontenmitglied 1	11	12	13	36	Qtr1 + Qtr2 + Qtr3 + Qtr4
Kontenmitglied 2 (TB First)	20	25	21	20	20
Kontenmitglied 3 (TB Letzter)	25	21	30	30	Wert von Qtr4

Normalerweise basiert die Berechnung eines übergeordneten Elements in der Zeitdimension auf der Konsolidierung und den Formeln der untergeordneten Elemente des übergeordneten Elements. Wenn ein Element in einer Kontenverzweigung jedoch als TB First markiert ist, stimmt jedes übergeordnete Element in der Zeitdimension mit dem Element überein, das als TB First markiert ist.

Beispiele finden Sie unter Eigenschaften für Zeitsaldo.

Abweichungs-Reporting

Eine TBC-Essbase-Anforderung ist die Möglichkeit, Abweichungsberichte für Ist- und Budgetdaten auszuführen. Für die Berechnung des Abweichungsreportings muss jeder Artikel, der eine Aufwendung für das Unternehmen darstellt, über ein Spesenreporting-Tag verfügen. Bestandsmitglieder, Gesamtaufwendungselemente und das COGS-Element erhalten jeweils ein Spesenabrechnungs-Tag für Abweichungsberichte.

Essbase stellt zwei Eigenschaften für Abweichungsberichte bereit: Aufwand und Aufwand (Standard). Abweichungsreporting-Eigenschaften definieren, wie Essbase die Differenz zwischen Istwerten und Budgetdaten in Elementen mit der @VAR- oder @VARPER-Funktion in ihren Elementformeln berechnet.

Wenn Sie ein Element als Aufwand kennzeichnen, berechnet die Funktion @VAR Budget - Ist. Beispiel: Wenn der budgetierte Betrag $100 und der tatsächliche Betrag $110 beträgt, beträgt die Abweichung -10.

Ohne das Tag "Spesenabrechnung" berechnet die Funktion @VAR "Ist - Budget". Beispiel: Wenn der budgetierte Betrag $100 und der tatsächliche Betrag $110 beträgt, beträgt die Abweichung 10.

Formeln und Funktionen

Formeln berechnen Beziehungen zwischen Elementen in der Essbase-Modellstruktur. Sie können Formeln auf Elemente oder in einem Berechnungsskript anwenden. Funktionen sind vordefinierte Routinen, die spezielle Berechnungen durchführen und Gruppen von Elementen oder Datenwerten zurückgeben. Formeln umfassen Operatoren und Funktionen sowie Dimensionsnamen, Elementnamen und numerische Konstanten.

Essbase unterstützt die folgenden Operatoren:

Mathematische Operatoren, die arithmetische Operationen ausführen
Bedingungsoperatoren, die logische Bedingungen in Berechnungen erstellen
Dimensionsübergreifende Operatoren, die auf Datenwerte bestimmter Kombinationen von Datenbankelementen verweisen

Die Essbase-Funktionen umfassen mehr als 175 vordefinierte Routinen, um die Berechnungsfunktionen von Essbase zu erweitern. Essbase umfasst die folgenden Funktionen:

Boolesche Funktionen, die einen bedingten Test bereitstellen, indem sie einen Wert TRUE oder FALSE zurückgeben
Mathematische Funktionen, die spezielle mathematische Berechnungen durchführen
Beziehungsfunktionen, die Datenwerte innerhalb einer Datenbank während einer Berechnung basierend auf der Position des aktuellen Elements suchen
Bereichsfunktionen, die einen Elementbereich als Argument für eine andere Funktion oder einen Befehl deklarieren
Finanzfunktionen, die spezielle Finanzberechnungen durchführen
Elementgruppenfunktionen, die auf einem angegebenen Element basieren und Elementlisten generieren
Zuordnungsfunktionen, die Werte, die auf einer übergeordneten Ebene eingegeben werden, untergeordneten Elementen zuordnen
Prognosefunktionen, die Daten bearbeiten, um Daten zu glätten, Daten zu interpolieren oder zukünftige Werte zu berechnen
Statistische Funktionen, die erweiterte Statistiken berechnen
Datums- und Zeitfunktionen, die Datums- und Zeitmerkmale in Berechnungsformeln verwenden
Berechnungsmodusfunktionen, die den Berechnungsmodus angeben, mit dem Essbase eine Formel berechnet

Die Measures-Dimension verwendet die folgenden Formeln:

Gewinnspanne = Umsatz - COGS
Gesamtaufwendungen = Marketing + Entgeltabrechnung + Sonstige
Gewinn = Gewinnspanne - Gesamtaufwand
Gewinn % = Gewinn % Umsatz
Gewinnspanne % = Gewinnspanne % Umsatz
Gewinn pro Unze = Gewinn / @ATTRIBUTEVAL(@NAME(Ounces))

Essbase verwendet Konsolidierungsoperatoren, um die Elemente "Gewinnspanne", "Gesamtaufwand" und "Gewinn" zu berechnen. Die Formel "Margin%" verwendet einen %-Operator, d.h. "Margin als Prozentsatz des Umsatzes ausdrücken". Die Profit%-Formel verwendet denselben %-Operator. Die Formel "Gewinn pro Unze" verwendet einen Geschäftsbereichsoperator (/) und eine Funktion (@ATTRIBUTEVAL), um die Rentabilität nach Unze für Produkte mit einer Größe von Unzen zu berechnen.

Hinweis:

In der Formel "Profit per Ounce" wird die Funktion @NAME auch zur Verarbeitung der Zeichenfolge "Ounces" für die Funktion @ATTRIBUTEVAL verwendet.

Eine vollständige Liste der Operatoren, Funktionen und Syntax finden Sie unter Berechnungsfunktionsliste. Siehe auch Formeln für Block Storage-Cubes entwickeln.

Dynamische Berechnungen

Wenn Sie Datenbankberechnungen entwerfen, können Sie ein Element als Dynamische Berechnung-Element definieren. Wenn Sie ein Element als Dynamische Berechnung taggen, berechnet Essbase die Kombinationen dieses Elements beim Abrufen der Daten, anstatt die Elementkombinationen während der regulären Datenbankberechnung vorab zu berechnen.

Dynamische Berechnungen verkürzen die reguläre Datenbankberechnungszeit, können jedoch die Abrufzeit für dynamisch berechnete Datenwerte erhöhen.

In der folgenden Gliederung enthält die Dimension "BC-Kennzahlen" mehrere Elemente, die als Dynamische Berechnung getaggt sind: Gewinn, Gewinnspanne, Gesamtaufwand, Gewinnspanne % und Gewinn %.

Abbildung 1-9 TBC Measures-Dimension, Tags für Dynamische Berechnung

Diese Abbildung zeigt die Elemente in der Dimension "BC-Kennzahlen", die als dynamische Berechnung getaggt sind, wie im Text vor dem Bild beschrieben.

Wenn eine allgemeine Datenbankberechnung durchgeführt wird, werden die Elemente der dynamischen Berechnung und die entsprechenden Formeln nicht berechnet. Diese Elemente werden berechnet, wenn ein Benutzer sie abfragt, z.B. aus Smart View. Essbase speichert die abgefragten Werte nicht, sondern berechnet die Werte für jede nachfolgende Abfrage neu.

Um zu entscheiden, wann Datenwerte dynamisch berechnet werden sollen, sollten Sie Ihre Prioritäten in den folgenden Bereichen berücksichtigen:

Optimale reguläre Berechnungszeit (Batchberechnung)
Geringe Festplattenplatzbelegung
Kürzere Zeit für die Datenbankumstrukturierung
Schneller Datenabruf für Benutzer
Kürzere Backup-Zeit

Siehe Dynamische Berechnung von Datenwerten.

Zweistufige Berechnungen

Die Two-Pass-Eigenschaft funktioniert nur für Elemente der Essbase-Dimension, die als Accounts getaggt sind, und für Elemente, die als Dynamische Berechnung getaggt sind. Dieses Label gibt an, dass einige Elementformeln zweimal berechnet werden müssen, um den gewünschten Wert zu erhalten.

In der TBC-Datenbank enthalten Margin % und Profit % das Label Two-Pass.

Das folgende Beispiel veranschaulicht, warum "Gewinn %" (basierend auf der Formel "Gewinn % Umsatz") ein Two-Pass-Tag aufweist. Die Tabellen haben fünf Spalten (Spaltenüberschriften werden von links nach rechts als Dimension, Jan, Feb, Mar und Qtr1 bezeichnet) und drei Zeilen (mit Gewinn, Umsatz und Gewinn % gekennzeichnet). Jan, Feb, Mar und Qtr1 sind Elemente der Year-Dimension. Gewinn, Umsatz und Gewinn in % sind Elemente der Measures-(Accounts-)Dimension.

Im folgenden Beispiel werden die anfänglichen Daten definiert, die in Essbase geladen werden sollen. Die Datenwerte für Profit -> Jan, Profit -> Feb und Profit -> Mar sind 100. Der Datenwert für Sales -> Jan, Sales -> Feb und Sales -> Mar ist 1000.

Tabelle 1-8: In Essbase geladene Daten

Dimension	Jan	Feb	Mrz	Qrt 1
Gewinn	100	100	100	N/V
Vertrieb	1.000	1.000	1.000	N/V
Gewinn %	N/V	N/V	N/V	N/V

Zuerst berechnet Essbase die Measures-Dimension. In der folgenden Tabelle sind die Datenwerte für Profit % -> Jan, Profit % -> Feb und Profit % -> Mar 10%.

Tabelle 1-9: Daten nach der Berechnung der Kennzahlendimension durch Essbase

Dimension	Jan	Feb	Mrz	Qrt 1
Gewinn	100	100	100
Vertrieb	1.000	1.000	1.000
Gewinn %	10 %	10 %	10 %	N/V

Als Nächstes berechnet Essbase die Year-Dimension. Die Daten werden über die Dimension zusammengefasst. In der folgenden Tabelle sind die Datenwerte für Profit -> Qtr1 (300) und Sales -> Qtr1 (3000) korrekt. Der Datenwert für "Gewinn % -> Quartal 1" (30%) ist falsch, weil "Gewinn %" als zweistufige Berechnung getaggt ist.

Tabelle 1-10: Daten nach der Berechnung der Year-Dimension durch Essbase

Dimension	Jan	Feb	Mrz	Qrt 1
Gewinn	100	100	100	300
Vertrieb	1.000	1.000	1.000	3000
Gewinn %	10 %	10 %	10 %	30%

Essbase berechnet dann den Gewinnprozentsatz bei jedem Vorkommen des Elements "Profit %" neu. In der folgenden Tabelle ist der Datenwert für Profit % -> Qtr1 (10%) nach dem zweiten Durchlauf korrekt.

Tabelle 1-11: Daten nach der Neuberechnung des Gewinnprozentsatzes durch Essbase

Dimension	Jan	Feb	Mrz	Qrt 1
Gewinn	100	100	100	300
Vertrieb	1.000	1.000	1.000	3000
Gewinn %	10 %	10 %	10 %	10 %

Checkliste für Berechnungen

Verwenden Sie die folgende Checkliste, wenn Sie eine Essbase Block Storage-(BSO-)Berechnung entwerfen:

Erreicht die Standardberechnungslogik genaue Ergebnisse?
Welche Elemente benötigen Formeln?
Welche Mitglieder benötigen Zeitsaldotags?
Welche Elemente erfordern Abweichungsberichte?
Welche Elemente benötigen eine Zwei-Pass-Berechnung?
Welche Elemente können als Dynamische Berechnung getaggt werden?