Grundsätzlich sei bei diesem Thema auf das folgende Dokument von der SAP verwiesen:
http://help.sap.com/bp_bw370/documentation/Multi_Dimensional_Modeling.pdf
Worum geht es. Um eine performante Abfrage auf der Datenbank zu erreichen, sind viele Dinge notwendig. Die Datenbank und deren Einstellungen spielen eine Rolle. Wie die Daten selbst auf Betriebssystemebene verarbeitet werden. Die Indizierung der einzelnen Tabellen. Die Art der Abfrage.
Aber natürlich hat man sich auch darüber Gedanken gemacht, wie das Datenbankschema aussehen muss. Die eine Alternative wäre eine flache Tabelle, also z. B. ein DSO zu benutzen. Eine andere wäre, ein Datenbankschema in dritter oder vierter Normalform zu haben. Vor bereits langer Zeit hat man dann den Ansatz eines Star Schemas entwickelt. Dieser Ansatz ist vor Allem durch Ralph Kimball sehr bekannt geworden. Das Star Schema wurde auch für SAP realisiert. Wenn mich meine historischen BW-Kenntnisse nicht täuschen, gab es zu den Anfangszeiten des BW kaum mehr als die PSA (welche damals durchaus auch als ODS bezeichnet wurde, wie man es heute noch in der einen oder anderen Verwaltungstabelle wiederfindet) und InfoCubes. InfoCubes sind im Prinzip nichts anderes als ein Star Schema. OK, die SAP spricht vom Erweiterten Star Schema. Manche nennen es auch ein Snowflake Schema. Wie auch immer, der Einfachheit halber, und weil es bei der Modellierung aus meiner Sicht weitgehend egal ist (ich werde noch auf ein Beispiel kommen, wo es nicht egal ist), nenne ich es Star Schema.
Bevor ich auf weitere Details eingehe, noch kurz eine kleine philosophische Betrachtung, ob es überhaupt noch Sinn macht, sich über das Thema zu unterhalten. Seit SAP den BIA/BWA eingeführt hat, und nun auch mit dem Thema HANA bzw. ICE sozusagen In-Memory massentauglich macht, stellt sich die Frage, ob man sich überhaupt noch Gedanken machen muss um eine Modellierung aus Performancegesichtspunkten. Nichts anderes ist ein Star Schema.
Nach meinen bisherigen Erfahrungen ist es so, dass man, hat man sich einmal entschlossen, die Daten im BWA zu verarbeiten, auf eine Modellierung getrost verzichten kann. Evtl. kann man hier nochmal eine Modellierung in Richtung Reduzierung des Speicherplatzes andenken, dies ist jedoch wieder ein ganz anderer Aspekt. Der Performance tut es aus meiner bisherigen Erfahrung keinen Abbruch, ob die Daten in einer Tabelle liegen, oder auf zehn, zwanzig oder mehr Tabellen verteilt sind. Und seit der BWA auch noch Operationen/Berechnungen im BWA selbst durchführen kann (BWA 7.20)....
Nunja, tatsächlich scheinen die Zeiten vorbei zu sein, in denen man sich um das Thema kümmern muss. Natürlich hat noch nicht jedes Unternehmen mit einem SAP BW einen BWA. Aber die Zeit wird es schon richten.
Ist das tatsächlich alles so? Noch lange nicht! Einmal macht auch heute noch nicht jeder InfoCube im BWA Sinn. Auch wenn man dort unbeschränkt Platz hätte. Zum anderen muss man durchaus mit einem Ausfall des BWA rechnen. Soll das bedeuten, dass dann quasi das ganze System weg ist, weil die Antwortzeiten so inakzeptabel lange sind? Es gibt hierbei ein langes für und wieder und immer wieder ganz interessante Diskussionen. Ich jedoch denke die Zeiten der Datenbankmodellierung werden langsam vorbei gehen. Jedoch werden bis dahin noch viele Jahre ins Land gegangen sein. Solange gilt es noch, seinen InfoCube gut zu modellieren.
Leute wie Ralph Kimball haben über das Thema sehr gute Bücher geschrieben. Alles was ich nach all diesen Ausführungen eigentlich möchte, ist meine Erfahrung in diesem Bereich zu teilen. Gerne bin ich offen für Anregungen und Korrekturen. Jedoch habe ich einfach schon zuviele schlechte BW Star Schemata gesehen, und denke diese Zusammenfassung einiger einfacher Regeln kann hilfreich sein.
Regeln für die Multidimensionale Modellierung eines BW Star Schemas:
-> Eine Dimensionstabelle sollte maximal 20 % der Größe der Faktentabelle haben. Besser nur 10%. Grundsätzlich, je kleiner desto besser.
-> Bei mehreren Merkmalen in einer Dimension sind 1:1-, n:1- und 1:n-Beziehungen zu bevorzugen. n:m-Beziehungen sind in der Regel zu vermeiden, es gibt jedoch Ausnahmen, wenn der Platz gering ist und das kartesische Produkt überschaubar bleibt. Bei 1:1- und n:1-Beziehungen sollte überprüft werden, ob nicht eine Zuordnung über Stammdaten möglich ist.
-> Bei mehreren Merkmalen je Dimension sollten die dazugehörigen Stammdaten- bzw. SID-Ta bellen betrachtet werden um abzuschätzen, wohin sich das kartesische Produkt, also die Anzahl aller möglichen Merkmalskombinationen entwickeln könnte.
-> Natürlich müssen die Daten immer auch vom Inhalt her betrachtet werden. Merkmalskombinationen können ungünstig sein, da es zu einer hohen Anzahl an Merkmalskombinationen kommen kann. Jedoch kann es betriebswirtschaftliche Gründe geben, weshalb dies hier nicht der Fall ist.
-> Es sollte wenn möglich und gegeben die Vor- und Nachteile eines Kennzahlen- und Kontenmodells berücksichtigt und miteinander vergleichen werden.
-> Im Zweifelsfall lieber eine Dimension mehr nutzen, als durch das Zusammenlegen von Merkmalen eine Dimension zu vergrößern
-> Nutze Line-Item Dimensionen bei Dimensionstabellen, welche >10-20% der Faktentabelle sind
-> Mit dem Flag für Hohe Kardinalität kann man mehr falsch als richtig machen. Im Zweifelsfall sollte man es unter realistischen Bedingungen testen, wenn man die Zeit hat.
-> Werden Merkmale in Abfragen oft zusammen genutzt, so sollten diese in eine gemeinsame Dimension gepackt werden. Dies kann auch bei einer dadurch resultierenden, leichten Vergrößerung der Dimension Sinn machen. Jedoch nicht, wenn sich die Größe der Dimension dadurch vervielfacht.
-> Ein Star Schema ist nicht statisch. Es sollte soweit möglich die zeitliche Entwicklung berücksichtigt werden. D. h. aus betriebswirschaftlichen Gründen kann es zu neuen Kombinationen von Merkmalen kommen (z. B. neues Werk, geänderte Systematik bei Materialnummern, ...)
-> Ein BW Star Schema darf niemals nach rein betriebswirtschaftichen Gesichtspunkten modelliert werden. Man kann der Einfachheit halber damit beginnen, muss aber letztendlich immer die technische Seite dabei in den Mittelpunkt stellen. Für eine betriebswirtschaftliche Ordnung der Merkmale gibt es immer noch MultiProvider, in denen die Merkmale völlig unterschiedlich zum darunterliegenden Datenmodell angeordnet werden können
-> In der Regel ist es nicht möglich die optimale Modellierung zu finden. Perfektion ist hier fehl am Platz. Man sollte nur sein Handwerk gut verstehen und sich ein paar Gedanken über die Daten gemacht haben.
Es gibt grundsätzlich bei der Modellierung viele Aspekte die zu berücksichtigen sind. Dazu kommen noch spezielle Aspekte welche z. B. das erweiterte Star Schema der SAP betreffen. Ein kleine Falle in die man tappen kann, ist, wenn man z. B. Klammerungen nicht entsprechend berücksichtigt. So habe ich es z. B. schon gelegentlich gesehen, dass die Belegposition als Klammerung die Belegnummer hat. Dadurch ergeben sich eindeutige Kombinationen zu welchen auch eindeutige Stammdaten gut abgelegt werden können. Man darf hierbei nicht den Fehler machen, Und die Position als solche auffassen und modellieren. Ein Blick in die SID-Tabelle zeigt schnell, dass es eine SID pro Kombination Position/Belegnummer gibt. Dies ändert sich auch nicht dadurch, dass die Merkmale selbst in verschiedenen Dimensionen abgelegt werden (was immer der Fall sein sollte, da n:m-Beziehung).
Ich freue mich, sollte es hierzu einmal Kommentare oder eine Diskussion geben.
Keine Kommentare:
Kommentar veröffentlichen