Essbase-Modellstruktur entwerfen
Nachdem Sie ein Essbase-Datenbankmodell entworfen haben, können Sie die Anwendung und Datenbank erstellen und den ersten Entwurf der Modellstruktur erstellen. Der Entwurf definiert alle Dimensionen, Elemente und Konsolidierungen. Verwenden Sie die Gliederung, um Konsolidierungsanforderungen zu entwerfen und zu ermitteln, wo Sie Formeln und Berechnungsskripte benötigen.
Outlines sind Teil einer Essbase-Datenbank (oder eines Cubes), die in einer Essbase-Anwendung vorhanden ist.
Um das zuvor eingeführte Beispiel für die Getränkefirma zu verwenden, hat der TBC-Anwendungsdesigner den folgenden Entwurf für eine Datenbankstruktur ausgegeben. In diesem Plan sind "Jahr", "Kennzahlen", "Produkt", "Markt", "Szenario", "Pakettyp" und "Unzen" Dimensionsnamen. Beobachten Sie, wie TBC Konsolidierungen, Berechnungen und Formeln und Berichtsanforderungen antizipiert hat. Die Anwendungsdesigner verwendeten auch Produktcodes anstelle von Produktnamen, um Produkte zu beschreiben.
-
Jahr. TBC muss Daten monatlich erfassen und die monatlichen Daten nach Quartal und Jahr zusammenfassen. Monatliche Daten, die in Mitgliedern wie Jan, Feb und Mar gespeichert werden, werden in Quartalen konsolidiert. Quartalsdaten, die in Elementen wie Qtr1 und Qtr2 gespeichert sind, werden in Year konsolidiert.
-
Größen. Umsatz, Herstellkosten des Umsatzes, Marketing, Entgeltabrechnung, Sonstige, Anfangsbestand, Zugänge und Endbestand sind Standardkennzahlen. Essbase kann aus diesen Kennzahlen Gewinnspanne, Gesamtaufwand, Gewinn, Gesamtbestand, Gewinn in %, Gewinnspanne in % und Gewinn pro Unze berechnen. TBC muss die Kennzahlen monatlich, vierteljährlich und jährlich berechnen.
-
Produkt. Die Produktcodes sind 100-10, 100-20, 100-30, 200-10, 200-20, 200-30, 200-40, 300-10, 300-20, 300-30, 400-10, 400-20 und 400-30. Jedes Produkt konsolidiert sich in seiner jeweiligen Familie (100, 200, 300 und 400). Bei jeder Konsolidierung kann die TBC nach Größe und Package analysieren, da jedes Produkt Elementen der Attribute "Unzen" und "Pakettyp" zugeordnet ist.
-
Market. Mehrere Staaten bilden eine Region; vier Regionen bilden einen Markt. Die Bundesstaaten sind Connecticut, Florida, Massachusetts, New Hampshire, New York, Kalifornien, Nevada, Oregon, Utah, Washington, Louisiana, New Mexico, Oklahoma, Texas, Colorado, Illinois, Iowa, Missouri, Ohio und Wisconsin. Jeder Staat konsolidiert sich in seiner Region – Ost, West, Süd oder Zentral. Jede Region konsolidiert sich in den Markt.
-
Szenario. TBC leitet Budget- und Istdaten ab und verfolgt sie. Manager müssen Budgets und Istwerte sowie die Abweichung und Abweichung in Prozent überwachen und verfolgen.
-
Packungstyp. TBC möchte sehen, welche Auswirkungen Produktverpackungen auf Umsatz und Gewinn haben. Durch die Festlegung der Dimension des Attributs "Pakettyp" können Benutzer Produktinformationen basierend darauf analysieren, ob ein Produkt in Flaschen oder Dosen verpackt ist.
-
Unzen. TBC verkauft Produkte in verschiedenen Größen in Unzen in verschiedenen Märkten. Durch die Festlegung der Ounces-Attributdimension können Benutzer überwachen, welche Größen sich in welchen Märkten besser verkaufen.
In den nächsten Themen werden die Grundlagen der Dimensions- und Elementeigenschaften sowie die Auswirkungen des Entwurfs auf die Performance erläutert.
Dimensionstypen
Ein Dimensionstyp ist eine Eigenschaft, die Essbase bereitstellt, die einer Dimension besondere Funktionalität hinzufügt. Spezialisierte und häufig verwendete Dimensionstypen sind Zeit, Konten und Attribute.
In diesem Thema werden die folgenden Dimensionen der TBC-Datenbank zur Veranschaulichung von Dimensionstypen verwendet.
Database:Design
Year (Type: time)
Measures (Type: accounts)
Product
Market
Scenario
Pkg Type (Type: attribute)
Ounces (Type: attribute)In der folgenden Tabelle werden die einzelnen Essbase-Dimensionstypen definiert.
Tabelle 1-4: Dimensionstypen
| Dimensionstypen | Beschreibung |
|---|---|
|
Kein Wert |
Gibt keinen bestimmten Dimensionstyp an. |
|
Time |
Definiert die Perioden, für die Sie Daten erfassen und aktualisieren. Sie können nur jeweils eine Dimension als Zeit taggen. Die Time-Dimension aktiviert mehrere Funktionen der Accounts-Dimension, wie z.B. Erst- und Letzt-Salden. |
|
Accounts |
Enthält die Elemente, die Sie messen möchten, wie Gewinn und Bestand, und stellt die integrierte Buchhaltungsfunktion von Essbase zur Verfügung. Es kann immer nur eine Dimension als Account definiert werden. |
|
Attribut |
Enthält Elemente, die zur Beschreibung von Elementen einer anderen sogenannten Basisdimension verwendet werden können. Beispiel: Die Dimension "Pakettyp" enthält ein Element für jeden Verpackungstyp, z.B. "Flasche" oder "Dose", das für Elemente der Dimension "Produkt" gilt. |
|
Land (wird nur für Währungsumrechnungsfunktion verwendet) |
Enthält Daten darüber, wo Geschäftsaktivitäten stattfinden. In einer Länderdimension können Sie die Währung angeben, die in jedem Element verwendet wird. Kanada hat beispielsweise drei Märkte: Vancouver, Toronto und Montreal, die dieselbe Währung verwenden, kanadische Dollar. |
Eigenschaften für die Elementspeicherung
Geben Sie Datenspeichereigenschaften für Elemente an, um zu definieren, wo und wann Konsolidierungen gespeichert werden. Standardmäßig werden Elemente als gespeichert gekennzeichnet: Essbase summiert ihre Werte und speichert das Ergebnis auf übergeordneter Ebene. Sie können die Standardlogik für jedes Element ändern, indem Sie das Eigenschafts-Tag für den Datenspeicher ändern.
In der folgenden Tabelle werden die Auswirkungen beschrieben, die Essbase-Datenspeichereigenschaften auf Elemente haben.
Tabelle 1-5: Essbase-Datenspeichereigenschaften
| Datenspeichereigenschaften | Auswirkungen auf Mitglieder |
|---|---|
|
Daten speichern |
Die Daten für das Element werden in der Datenbank gespeichert Speicherdaten sind die Standardspeichereigenschaft. Essbase summiert die Werte und speichert das Ergebnis auf übergeordneter Ebene. |
|
Dynamische Berechnung |
Die mit dem Element verknüpften Daten werden auf Anforderung durch eine Benutzerabfrage berechnet. Die berechneten Daten werden nicht gespeichert, sie werden verworfen, nachdem die Abfrageanforderung abgeschlossen wurde. |
|
Gemeinsames Element |
Die dem Element zugeordneten Daten stammen von einem anderen Element mit demselben Namen. |
|
Nie gemeinsam verwenden |
Die dem Element zugeordneten Daten werden mit dem übergeordneten Element und seinem untergeordneten Element dupliziert, wenn eine implizite gemeinsame Beziehung vorhanden ist. Die Daten werden mit dem ersten Vorkommen des Elements in Outline-Reihenfolge gespeichert. |
|
Nur Label |
Sie können ein gespeichertes Element in "Nur Label" für Elemente ändern, denen keine Daten zugeordnet sind. Obwohl ein Label-Only-Element keine Daten enthält, kann es einen Wert anzeigen. Das Label taggt nur Mitglieder und erleichtert die Navigation und das Reporting. In der Regel werden nur Label-Elemente nicht berechnet. Beispiel: In der Dimension "Kennzahlen" hat das Element "Verhältnisse" drei untergeordnete Elemente: "Gewinnspanne", "Gewinn %" und "Gewinn pro Unze". Die Elementkennzahlen definieren eine Kategorie von Mitgliedern. Bei der Konsolidierung werden "Gewinnspanne", "Gewinn %" und "Gewinn pro Unze" nicht zu einer sinnvollen Zahl für "Verhältnisse" zusammengefasst. Daher werden "Verhältnisse" nur als Label gekennzeichnet. |
Checkliste für Dimensions- und Elementeeigenschaften
-
Können Sie eine Zeitdimension identifizieren?
-
Können Sie eine Account-Dimension identifizieren?
-
Enthalten die Daten Fremdwährungen? Wenn ja, haben Sie eine Währungspartitionsdimension identifiziert?
-
Können Sie Qualitäten oder Eigenschaften von Dimensionen identifizieren, die als separate Attribute-Dimensionen definiert werden sollen?
-
Welche Elemente benötigen spezielle Datenspeichereigenschaften?
Entwurf einer Gliederung zur Optimierung der Leistung
Positionieren Sie Attribute-Dimensionen am Ende der Essbase-Modellstruktur, positionieren Sie dicht besetzte Dimensionen vor dünn besetzten Dimensionen, und ordnen Sie dünn besetzte Dimensionen zuerst mit den wenigsten Elementen an. Die Position der Dimensionen in einer Modellstruktur und die Speichereigenschaften der Dimensionen wirken sich darauf aus, wie schnell Berechnungen ausgeführt werden und wie lange es für den Abruf von Daten dauert.
Abfrageperformance optimieren
Um die Abfrageperformance zu optimieren, verwenden Sie die folgenden Richtlinien, wenn Sie eine Outline entwerfen:
-
Wenn die Modellstruktur Attribute-Dimensionen enthält, stellen Sie sicher, dass die Attribute-Dimensionen die einzigen dünn besetzten dynamischen Berechnungsdimensionen in der Modellstruktur sind.
-
Platzieren Sie in der Umrisslinie die unbewaffneten Sparse-Dimensionen vor den unbewaffneten Sparse-Dimensionen.
Die unten dargestellte Outline ist für eine optimale Abfrageperformance ausgelegt:
-
Da die Modellstruktur Attributdimensionen enthält, wird die Speichereigenschaft für Standarddimensionen und alle Standarddimensionswerte als Speicherdaten festgelegt.
-
Die Dimension {\b Product} ist die erste der dünn besetzten Dimensionen. Basisdimensionen werden in der Regel mehr als andere Dimensionen abgefragt.
Abbildung 1-5: Entwurf einer Gliederung für optimierte Abfragezeiten

Berechnungsperformance optimieren
Um die Berechnungsperformance zu optimieren, sortieren Sie die dünn besetzten Dimensionen im Outline nach ihrer Anzahl von Elementen, beginnend mit der Dimension, die am wenigsten enthält.
Der nachfolgend dargestellte Umriss ist für eine optimale Rechenleistung ausgelegt:
-
Die kleinste Standarddimension, die dünn ist, Market, ist die erste der dünn besetzten Dimensionen in der Gliederung.
-
Die größte Standarddimension, die dünn besiedelt ist, {\b Product}, liegt unmittelbar über der ersten Attributdimension. Wenn die Modellstruktur keine Attribute-Dimensionen enthält, befindet sich die Product-Dimension am Ende der Modellstruktur.
Abbildung 1-6: Entwurf einer Gliederung für optimierte Berechnungszeiten

Erfüllen Sie die Anforderungen an Berechnung und Abruf
Obwohl sie dieselben Dimensionen enthalten, unterscheiden sich die zuvor gezeigten Beispielumrisse. Um die beste Outline-Sequenz für eine Situation zu bestimmen, priorisieren Sie die Datenabrufanforderungen der Benutzer mit der Zeit, die für die Ausführung von Berechnungen in der Datenbank benötigt wird. Wie oft wird die Datenbank aktualisiert und neu berechnet? Was ist die Natur von Benutzerabfragen? Wie groß ist das erwartete Volumen an Benutzerabfragen?
Ein möglicher Workaround besteht darin, die Dimensionen zunächst in der Gliederung zu positionieren, um die Berechnung zu optimieren. Nachdem Sie die Berechnungen ausgeführt haben, können Sie die Reihenfolge der Dimensionen manuell ändern, um den Abruf zu optimieren. Wenn Sie das Outline speichern, nachdem Sie die Dimensionen neu positioniert haben, legen Sie fest, dass die Datenbank nur nach Index neu strukturiert wird. Bevor Sie Berechnungen erneut ausführen, müssen Sie die Reihenfolge der Dimensionen im Outline ändern, um die Berechnung zu optimieren.