Performance-Optimierung für SAP BW

2.1 Flache Datenspeicher

Bei flachen Datenspeichern handelt es sich um BW-Objekte, die sich technisch als einfache Tabellen mit Kopf und Zeilen darstellen lassen. Im Kopf befinden sich die Felder, über die Tabellenspalten gebildet werden, während sich in den Zeilen die gespeicherten Informationen befinden.

Diese Tabellen können mit anderen in einer Relation stehen (siehe Abbildung 2.4). Besteht eine Beziehung zu einer oder mehreren anderen Tabellen auf Schlüsselebene, sprechen wir von einer Primär-Fremdschlüsselbeziehung. Die Fremdschlüssel beschaffen (verweisen auf) Werte in der verbundenen Tabelle.

Manche Tabellen stehen allerdings nicht in Relation zueinander, sondern bilden mit anderen Tabellen einen speziellen Modelltyp. Wie sich diese Beziehungen aufbauen können, soll Ihnen die folgende einfache Grafik verdeutlichen (siehe Abbildung 2.3).

Aus einer Reihe von Datenbanktabellen werden Informationen verwendet, um einen flüchtigen Datenwert (Bewegungsdatum) innerhalb eines Datenspeichers zu adressieren. Adressieren ist meiner Ansicht nach in diesem Zusammenhang der wohl beste Ausdruck, da die Kombination der verwendeten Stammdatenschlüssel eine eindeutige Datenbankadresse bildet. Dieser Schlüssel ist wiederum normalisiert und eindeutig.

Abbildung 2.3: Adressierung über Schlüssel

Wie Sie in der Abbildung sehen, befinden sich aus Sicht der Datenbank an derselben Adresse zwei verschiedene Kunden, die unterschiedliche Umsätze generiert haben.

Über ein solches Konstrukt werden in der Regel Stammdaten am InfoProvider miteinander kombiniert und somit die Bewegungsdaten eindeutig den Stammdaten zugeordnet. Auf Stammdatenebene lassen sich dadurch zeitliche Gültigkeiten, Sprachversionen und Hierarchien abbilden und miteinander verknüpfen, was insbesondere bei der mehrdimensionalen Modellierung erhebliche Vorteile hat.

Abbildung 2.4: Prinzip flacher Datenbankobjekte

2.1.1 Merkmale

Merkmale sind in SAP BW die Speicher von unveränderlichen oder selten veränderlichen Werten. Solche Tatsachen können sein:

technische Tatsachen:

Mit welchem Vorgang wurde ein Datensatz geladen (z.B. Request-Nummer)?,

Einheiten-Tatsachen:

Welche Einheit ist zu einem Bewegungsdatum zu verwenden (z.B. Tonnen)?,

zeitliche Tatsachen:

Zu welchem Zeitpunkt ist ein Bewegungsdatum im Kontext eines Vorganges entstanden (z.B. Tag: 10, Monat: Januar, Jahr: 2013)?,

organisatorische (betriebliche) Tatsachen:

Welcher Vorgang hat das Bewegungsdatum erzeugt (z.B. Verkaufsbeleg)?

2.1.2 Merkmale mit Stammdaten

Eine besondere Form stellen Merkmale mit Stammdaten dar. Dabei beschreiben ein oder mehrere Merkmale, Kennzahlen oder Hierarchien ein sogenanntes Trägermerkmal und machen es dadurch eindeutiger. Technisch gesehen kommt es zu einer Tabellenkaskade.

Abbildung 2.5: Attribut Kaskade

Unser Beispiel besagt, dass das Objekt »Erde« über direkte und indirekte Eigenschaften siebenundzwanzig unterschiedliche Zustände hat, also siebenundzwanzig Datensätze pro Datenverarbeitungsvorgang erzeugen kann. Wenn Sie wollen, können Sie gern die tatsächlichen Ausprägungen von »Erde« errechnen.

Stammdaten können nur sich selbst und ihre Werte (Werteliste) liefern oder über Attribute, Texte und Hierarchien das Trägermerkmal beschreiben und es damit konkretisieren. Erlangt ein Merkmal über seine Attribute eine Konkretisierung, nennen wir diesen Zustand Ausprägung. Dabei kann das Trägermerkmal durchaus seine eigenen Werte aufweisen (Erde = Kontinent).

Die Werte der Attribute des Trägermerkmals verhalten sich wie solche in der Werteliste des Trägermerkmals. Das bedeutet, dass im Reporting wie auch im Berichtsdesign ein Merkmal seine eigenen Werte sowie die des Attributs oder der Hierarchie, in einem Kontextmenü als Filterwert zur Verfügung stellt.

Wird ein Trägermerkmal durch Objekte und deren Werte beschrieben, so geschieht das nicht durch die Werte selbst, sondern durch Ersatzschlüssel (Surrogat-ID). Diese Ersatzschlüssel verweisen auf die Stammdatenschlüssel in der Stammdatentabelle des Attributs und werden in der Surrogat-Tabelle des Trägermerkmals abgelegt. Damit ist sichergestellt, dass jedes Objekt unendlich oft verwendet werden kann. Attribute lassen sich grundsätzlich differenzieren in:

• Anzeigeattribute,
• zeitabhängige Attribute,
• Navigationsattribute,
• zeitabhängige Navigationsattribute,
• Texte mit und ohne Sprachabhängigkeit und oder Zeitabhängigkeit,
• Hierarchien.

Durch diese Attribute wird eine extrem hohe Flexibilität und Wiederverwendbarkeit der Objekte erreicht. Somit benötigen Sie nur jeweils ein Objekt. Lassen Sie uns das notwendige Tabellenkonstrukt einmal in Abbildung 2.6 ansehen:

Abbildung 2.6: Surrogat-Tabelle

Die jeweiligen Objekte Ort, Strasse, Nummer, Auftraggeber und Warenempfänger sind nicht fest an Kunden gebunden und können durchaus auch aus einer Hierarchie stammen. So freut sich Frau Meyer bestimmt darüber, dass sie auch an anderen Orten Waren empfangen kann.

Jede Form eines Stammdatums wird in speziellen Tabellen verwendet, die in einer Beziehung zum Trägermerkmal stehen, ohne fest an dieses gebunden zu sein.

Da sich die Werte eines Attributs wie eine Werteliste des Trägermerkmals verhalten, gilt bei Navigationsattributen größte Vorsicht (siehe Abbildung 2.7). Große Navigationsattribute können schnell das Datenmodell sprengen und deutlich verlangsamen.

Abbildung 2.7: Exponentielles Wachstum der Datenlast bei Navigationsattributen

Es handelt sich dabei zwar um eine Worst-case-Berechnung, sie verdeutlich jedoch, dass Daten sich schnell vervielfachen können. Sie müssen gelesen, geladen und gepuffert werden.

Eine weitere Besonderheit bietet die Möglichkeit, ein Trägermerkmal über Attribute zu konkretisieren. Das mutet eher normal an. Ich will Ihnen aber zeigen, wie ungewöhnlich dieses Konstrukt sein kann.

Stellen wir uns vor, wir sollen folgende Reportmöglichkeit physisch modellieren:

Wie hoch sind die Produktionskosten für Furniermaschinen, die das Modul »Kantenglätter« verwenden?

Ziehen wir dazu unsere Tabellensicht zurate:

Abbildung 2.8: Beziehung Produktionskosten zu Merkmalen

Wir stellen fest, dass das Objekt »Produktionskosten« zu den Merkmalen MACHINE und Modul in Beziehung steht. Das bedeutet für uns, dass wir das Merkmal Modul einfach an dem Trägermerkmal MACHINE als Attribut verwenden können. Im Reporting könnten wir dann über eine konstante Selektion festlegen, dass im Modell die Anforderungen für den Bericht sichergestellt sind.

Damit »Modul« nicht einfach als eigenständiges Merkmal verwendet werden kann, können wir den Schalter Ausschließlich Attribut im Merkmal Modul setzen.

Leider ist das zu kurz gedacht. Da die Werte eines Attributs durch eine Surrogat-ID (S-ID) am InfoProvider bekannt gemacht werden, stehen auch alle nicht benutzten Module sämtlicher Maschinen als Dimensions-ID (DIM-IDs) am InfoCube bereit. Wir erzeugen Metadaten, die wir nicht benötigen und verlangsamen damit die Leseperformance.

Die Lösung lautet Klammerung! Dazu werden wir das Objekt MACHINE um ein neues, und darüber das Objekt MACHINE erweitern.

Wir modellieren ein neues Merkmal KMODUL, welches den konstanten Wert »Kantenglätter« trägt (siehe Abbildung 2.9). Das Merkmal KMODUL referenziert auf das Merkmal MODUL und verwendet dadurch dessen Werte.

Abbildung 2.9: Merkmal KMODUL mit Konstante

Danach ordnen Sie dem Merkmal MACHINE Ihr neues Merkmal KMODUL als geklammertes hinzu (siehe Abbildung 2.10). Nehmen Sie in Ihrem InfoCube das Merkmal MACHINE auf. Das geklammerte Merkmal und das Navigationsattribut werden mit aufgenommen (siehe Abbildung 2.11).

Abbildung 2.10: Merkmal MACHINE im InfoCube

Abbildung 2.11: Automatische Übernahme der Merkmale

Vergessen Sie nicht, am InfoCube das Navigationsattribut für Ihr Merkmal MODUL einzuschalten!

Nun können Sie alle drei Merkmale in einer Query als eigenständiges InfoObjekt verwenden, z.B., um Umsatzunterschiede zwischen den Maschinen mit und ohne Kantenglätter zu vergleichen.

Die Klammerung hat darüber hinaus den Vorteil, dass Sie von InfoProvider zu InfoProvider entscheiden können, ob Sie KMODUL gemeinsam mit MACHINE verwenden wollen, bzw., ob Sie nur KMODUL verwenden wollen, aber MACHINE nicht und umgekehrt.

Wenn wir uns das erzeugte Datenmodell ansehen, wird uns schnell klar, was da passiert ist: Unser Objekt MODUL erscheint zweimal, was ja eigentlich nicht geht: einmal als MODUL mit Konstante und einmal als Navigationsattribut zu MACHINE (siehe Abbildung 2.12).

Abbildung 2.12: Datenmodell nach Klammerung

Legen wir eine Transformation zwischen MACHINE und dem InfoCube an (siehe Abbildung 2.13), so stellen wir fest, dass KMODUL uns als Quelle in der konstanten Variante zur Verfügung steht. Wir könnten unseren Cube demnach gezielt mit Daten zur Kombination »Maschine mit Kantenglättern« füllen. Das hält ihn schlank und unsere Performance hoch.

Abbildung 2.13: Fortschreibung von KMODUL

2.1.3 DataStore-Objekte

Eine weitere Form flacher Datenziele sind die sogenannten DataStore-Objekte (DSO).

Grundsätzlich werden drei DSO-Varianten unterschieden:

• Standard–DSO,
• schreiboptimiertes DSO,
• DSO für direktes Schreiben/mit direkter Fortschreibung.

Aus Sicht der Performance ist das Standard-DSO von besonderem Interesse. Es verfügt über drei physische Tabellen, die zum selben Modell gehören. Die Datenfortschreibung erfolgt über korrespondierende Felder.

Jedes DSO modelliert sich über mindestens ein Schlüsselfeld und mindestens ein Datenfeld. Schlüsselfelder sind immer Merkmale, Datenfelder können Merkmale und/oder Kennzahlen sein. Ein DSO kann keine Bewegungsdaten aggregieren oder komprimieren.

Sehen wir uns das Modell eines Standard-DSO in Abbildung 2.14 einmal genauer an:

Abbildung 2.14: Standard-DSO-Modell

Die Activation Queue ist die Eingangsschicht des DSOs. Jeder reguläre Datenladevorgang richtet sich gegen diese Tabelle.

Bei Aktivierung der Datenrequests (vgl. Abschnitt Requestverarbeitung und 5.9) werden diese 1:1 in die Change Log-Tabelle fortgeschrieben und anschließend aus der Activation Queue entfernt. Parallel werden die Daten ohne technischen Schlüssel in die Active Data-Tabelle fortgeschrieben.

Daten, auf die berichtet wird, sind die der Active Data-Tabelle. Werden die neuen Daten, wie das Beispiel in nachfolgender Abbildung 2.15 zeigt, nur angehangen, erfolgt zur Berichtszeit die Berechnung aller Einzelwerte zu einem Gesamtwert. Wie dies vonstattengeht, hängt vom Aggregationsverfahren der Kennzahl ab. Das Beispiel in Abbildung 2.15 geht von einer Summation aus.

Abbildung 2.15: Ergebnis im Reporting

Ein DSO ermöglicht auf Ebene der Active Data-Tabelle die folgenden Operationen:

After Image (siehe Abbildung 2.16):

• Es wird über dem bestehenden der neue Satz geschrieben.
• Die Active Data-Tabelle vergrößert sich nicht.
• Die Veränderung ist in der Change Log nachvollziehbar.

Abbildung 2.16: After Image

Before Image/After Image (siehe Abbildung 2.17):

• Es werden erst ein Entlastungssatz und dann ein Satz mit den neuen Werten geschrieben.
• Die Active Data-Tabelle vergrößert sich um zwei Sätze.
• Die Veränderung ist in der Change Log nachvollziehbar.

Abbildung 2.17: Before Image/After Image

Additive Image (siehe Abbildung 2.18):

• Es wird ein neuer Datensatz angehängt.
• Die Active Data-Tabelle vergrößert sich um einen Satz.
• Die Veränderung ist in der Change Log nachvollziehbar.

Abbildung 2.18: Additive Image

Delete Image (siehe Abbildung 2.19):

• Es wird ein bestimmter Datensatz entleert.
• Die Active Data-Tabelle verändert sich nicht.
• Die Veränderung ist in der Change Log nachvollziehbar.

Abbildung 2.19: Delete Image

Reverse Image (siehe Abbildung 2.20):

• Es wird nur ein Entlastungssatz geschrieben.
• Die Active Data-Tabelle vergrößert sich.
• Die Veränderung ist in der Change Log nachvollziehbar.

Abbildung 2.20: Reverse Image

Da sich die Daten der Change Log pro Ladeprozess erhöhen, besteht hier die Gefahr, dass nicht mehr notwendige Daten aufbewahrt werden und das Datenbanksystem unnötig belasten.

Das Aufbewahren der Ladehistorie ist nur dann sinnvoll, wenn die Datenbestände des DSOs nicht in andere Ziele fortgeschrieben wurden oder aus Revisionsgründen die Daten aufbewahrt werden müssen. In beiden Fällen bietet sich jedoch die Archivierung der nicht mehr benötigten Requests an.

Abbildung 2.21: Beispiel-Change Log zu Active Data