Anwendung des Prinzips der Doppik beim Aufbau eines Data Warehouses

Transkript

1 Anwendung des Prinzips der Doppik beim Aufbau eines Data Warehouses Einführung Einer der Nachteile der Data Warehouse Technologie besteht daran, dass in einem Data Warehouse (DWH ) nur Momentaufnahmen von Daten gespeichert werden; Zusammenhänge zwischen Datenänderungen, Ursachen dieser Änderungen und die Wirkung der Änderungen auf andere Daten solche Informationen fehlen üblicherweise. Die Ursache liegt in der OLAP Technologie, die für den Aufbau eines DWH benutzt wird. Ein DWH besteht normalerweise aus mehreren OLAP-Cubes, in denen Momentaufnahmen von Daten unabhängig voneinander gespeichert werden. Um die Zusammenhänge zwischen Datenänderungen in verschiedenen OLAP-Cubes zu verfolgen, kann das Prinzip der doppelten Buchführung benutzt werden. Prinzip der Doppik Das Wesentliche am Prinzip der doppelten Buchführung besteht darin, dass alle Änderungen immer doppelt erfasst werden und auf Konten registriert werden einmal im Soll und einmal im Haben. Alle Änderungen werden in der Form von Buchungen aufgezeichnet. Eine Buchung belastet gleichzeitig zwei Konten das Soll und das Haben. Das Prinzip der doppelten Buchführung erlaubt eine dynamische Darstellung der Änderungen und man kann, da alle Änderungen doppelt erfasst werden, hierdurch verschiedene Arten von Zusammenhänge abbilden wie z.b. zuvor-danach oder Ursache-Folge. In Bezug auf die Architektur eines DWH kann das Prinzip der Doppik folgenderweise verwendet werden: Definieren wir ein. Ein ist ein mehrdimensionaler Datenwürfel mit einigen Besonderheiten: 1. Ein hat mindestens eine Dimension 2. Ein hat mindestens zwei Measures Summe Soll und Summe Haben 3. Alle weiteren Measures der Konten existieren immer doppelt als Measure Soll und Measure Haben Ein kann beliebig viele zusätzlichen Dimensionen und Measures haben, aber jede neue Measure wird doppelt definiert als Soll und als Haben - Measure. Dimensionen Dimension 1 Dimension 2.. Measures Soll Measures Haben Summe Summe Measure 1 Measure 1 Measure 2 Measure 2

2 Definieren wir noch zwei wichtigen berechneten Measures: 1. Ein Saldo. Differenz zwischen den Soll- und Haben Measures ergibt ein Saldo: = 2. Ein Umsatz. Differenz zwischen der Soll Measure am Ende der Periode und der Soll Measure am Anfang der Periode ergibt Soll-Umsatz, auf die gleiche Weise berechnet man Haben-Umsatz:, =, = Buchung Definieren wir eine Buchung. Eine Buchung ist eine Anweisung, die festlegt, wie die Informationen auf den Konten geändert werden sollen. Durch eine Buchung werden immer zwei Konten betroffen Soll und Haben. Dabei werden die Soll-Measures des Soll-Konten und Haben-Measures des Haben-Konten belastet. Jede Buchung hat ein und eine Summe, die gleich ist sowohl für das Sollals auch für das Haben-Konten. Außerdem enthält eine Buchung alle zusätzlichen Dimensionen und Measures, die für das Soll und das Haben definiert worden sind. Buchung Summe Soll Haben Dimension 1 Dimension 1 Dimension 2 Dimension 2 Measure 1 Measure 1 Measure 2 Measure 2 Es gibt zwei Arten von Buchungen die normalen Buchungen, die die entsprechende Measures der Konten erhöhen und Storno-Buchungen, die die Measures mindern. Beispiel 1. Ein Warenkonto Nehmen wir an, wir möchten unsere Lager als ein multidimensionaler OLAP-Würfel beschreiben. Definieren wir ein OLAP-Würfel mit folgenden Dimensionen und Measures: Warenkonto Measures Soll Measures Haben Summe Summe Menge Menge Dimensionen Mengeneinheit Lager Artikel Alle Wareneingänge werden als Soll von Warenkonto gebucht, alle Warenausgänge als Haben. Da jede Buchung unbedingt zwei Konten belasten muss, definieren wir noch ein Dienstkonto ohne zusätzlichen Dimensionen und Measures:

3 Dienstkonto Measures Soll Measures Haben Summe Summe Dimensionen Die möglichen Buchungen werden dann so aussehen: 3 Warenkonto 1 2 Dienstkonto Liste der Buchungen: 1. Wareneingang: Soll Warenkonto Haben Dienstkonto 2. Warenabgabe: Soll Dienstkonto Haben Warenkonto 3. Interne Warenbewegung: Soll Warenkonto Haben Warenkonto Beispielbuchungen: Nr. Summe Menge ME Lager Artikel Bemerkung Soll Warenkonto 30 Kiste Lager.1 SIE.01 Wareneingang 30 Kisten von SIE.01 Haben Dienstkonto im Wert von 3000 auf den Lager Soll Dienstkonto Warenabgabe 20 Kisten von SIE.01 im Haben Warenkonto 20 Kiste Lager.1 SIE.01 Wert von 2000 vom Lager Soll Warenkonto 10 Kiste Lager.2 SIE.01 Interne Warenbewegung 10 Kisten Haben Warenkonto 10 Kiste Lager.1 SIE.01 SIE.01 im Wert von 1000 von Lager.1 auf den Lager Soll Dienstkonto Warenabgabe 5 Kisten von SIE.01 im Haben Warenkonto 5 Kiste Lager.1 SIE.01 Wert von 500 vom Lager Soll Warenkonto 2 Kiste Lager.1 SIE.01 Verpackungsänderung 2 Kisten von Haben Warenkonto 20 Stück Lager.1 SIE.01 SIE.01 im Wert von 200 im Lager.2 Nach all diesen Buchungen wird Warenkonto so aussehen: Lager Artikel ME Ab Soll Haben Примечание??? Summe Menge Summe Menge Lager.1 SIE.01 Kiste Eingang 30 Kisten von SIE.01 im Wert von 3000 auf den Lager.1 Lager.1 SIE.01 Kiste Abgabe 20 Kisten von SIE.01 im Wert von 2000 vom Lager.1 Lager.1 SIE.01 Kiste Kisten von SIE.01 im Wert von 1000 vom Lager.1 auf den Lager.2 Lager.2 SIE.01 Kiste Kisten von SIE.01 im Wert von 1000 von Lager.1 auf den Lager.2 Lager.2 SIE.01 Kiste Abgabe 5 Kisten von SIE.01 im Wert von 500 vom Lager.2 Lager.2 SIE.01 Kiste Verpackungsänderung 2 Kisten von SIE.01 im Wert von 200 im Lager.2 Lager.2 SIE.01 Stück Verpackungsänderung 2 Kisten von SIE.01 im Wert von 200 im Lager.2 Beispiel2. Lieferantenkonto In einemweiteren Beispiel möchten wir die Information über unseren Lieferanten und deren Umsätze in einem OLAP-Würfel speichern. Definieren wir dafür ein Lieferantenkonto wie folgt:

4 Lieferantenkonto Measures Soll Measures Haben Summe Summe Dimensionen Lieferant Die Wareneingangsbuchungen und einige Warenabgabenbuchungen (Warenrückgabe) werden jetzt anstatt mit dem Dienstkonto mit dem Lieferantenkonto verbucht: 5 4 Lieferantenkonto 1 2 Warenkonto 3 Dienstkonto Liste der Buchungen: 1. Wareneingang: Soll Warenkonto Haben Lieferantenkonto 2. Warenrückgabe: Soll Lieferantenkonto Haben Warenkonto 3. Warenabgabe: Soll Dienstkonto Haben Warenkonto 4. Interne Warenbewegung: Soll Warenkonto Haben Warenkonto 5. Lieferantenausgleich: Soll Lieferantenkonto Haben Lieferantenkonto Beispiel 3. Beispielkontenplan Als Beispiel zeigen wir, wie ein Kontenplan eines Produktionsbetriebes aussehen kann: MwSt Direkte Kosten Indirekte Kosten Produktion Lieferanten Waren Fertige Produktion Verkauf Kunden Inventur Gehalt Steuer Gewinn/ Verlust Bank Jedes in diesem Kontenplan ist ein multidimensionaler OLAP-Würfel. Die Pfeile zeigen die Buchungen, die die typischen Geschäftsprozesse eines Produktionsbetriebes abbilden.

5 Vorteile Die Anwendung des Doppik - Prinzips beim Aufbau eines Data Warehouses hat mehrere Vorteile. Jede Änderung von Daten in einem OLAP-Würfel bezieht sich auf entsprechende Änderung in einem anderen OLAP-Würfel. Hinter jeder Änderung steht eine Buchung, die den Sinn und die Bedeutung der gemachten Änderungen erklärt. In dem Beispiel 2 können wir nicht nur den Warenbestand unseren Lager oder stand unseren Lieferanten bekommen diese Information befindet sich in unseren Konten. Wir wissen auch, was hinter jedem Wareneingang und der Warenabgabe steht. Für die Wareneingänge wissen wir, z.b., welche Waren welcher Lieferant geliefert hat weil die Änderungen auf dem Warenkonto und die Änderungen auf dem Lieferantenkonto miteinander verbunden sind. Noch ein Vorteil hat mit der Änderung des ETL-Prozesses zu tun.. Die einzige Aufgabe des ETL-Prozesses besteht nun darin, die Buchungen auf Basis der Information in den operativen transaktionellen Systemen zu erzeugen und dies kann man leicht formal definieren. Ein weiterer positiver Effekt besteht daran, dass man ein Real-Time Data Warehous aufbauen kann. Falls die Buchungen in Transaktionen des operativen Systems erstellt und gebucht werden, wird die Information im Data Warehouse auch transaktionell das bedeutet, dass diese Informationen auch in den operativen Transaktionen benutzt werden können. RTAS Informationsarchitektur Das oben beschriebene Konzept wurde in einem Real-Time analytics System (RTAS) implementiert. Es besteht aus einer Data Engine, Metadata Repository, einer Buchungs-Engine und einer Abfragen-Engine. Bild 2. Informationsarchitektur des RTAS Externes Informationssystem (EIS) Real-Time analytics System Metadata Repository. Buchungs- Engine Beschreibung von: Objekte des EIS Dimensionen Konten Buchungen Buchungsalgorithmen Abfragen- Engine Data Engine Buchungen Buchungen verdichtet

6 In der Data Engine werden die Buchungen gespeichert und zwei Mal verdichtet ein Mal auf Buchungsebene, zweites Mal auf Kontenebene. Die Verdichtung erfolgt transaktionell mit jeder Buchung. Die verdichteten Daten sind immer konsistent und können für transaktionelle Zwecke verwendet werden. Im Metadaten-Repository werden die Objekte des externen Informationssystems beschrieben, die für die Buchungen relevant sind. Das sind die Belege, die die Buchungen erzeugen und einige Stammdaten, die als dimensionen benutzt werden. Außerdem gehörten zum Repository Informationen über Konten, Buchungen und Buchungsalgorithmen. Die Buchungs-Engine erzeugt Buchungen aufgrund der Information im Metadaten-Repository und schickt diese in die Data Engine. Die Abfragen-Engine dient dazu, Informationen aus der Data Engine zu ermitteln. Eigenschaften des RTAS 1. Den Kern des RTAS bilden Buchungen. Die Buchungen werden von der Buchungsengine erstellt und durchführt. 2. Die Buchungen haben zwei Verdichtungsebenen. In der ersten Stufe sind das die Konten. Ein ist logisch gesehen ein Würfel mit einigen Dimensionen und Measures. Eine weitere Verdichtungsebene hilft bei Abfragen, bei denen Buchungen abgefragt werden (z.b. Umsätze zwischen Konten). Auch diese Verdichtungsebene befindet sich mit den Buchungen immer in einem konsistenten Zustand. Beide Verdichtungsebenen werden aktualisiert soblad eine Buchung angelegt wird, also befinden sich die Buchungen und die Verdichtungsebenen immer in einem konsistenten Zustand. 3. Es ist möglich, im Laufe der Zeit neue Dimensionen für ein zu definieren oder alte Dimensionen zu sperren. 4. Buchungen können mit beliebigem (also auch in der Vergangenheit) angelegt werden, die Konten werden dabei automatisch aktualisiert. Buchungen können auch gelöscht werden. 5. Es ist möglich, auf Kontenebene bestimmte Plausibilitätsprüfungen zu definieren. Z.B. kann man definieren, dass negativen Lagerbestände nicht erlaubt sind. Wenn dann, wenn eine Buchung gebucht wird, die zu einem negativen Lagerbestand führen würde, wird diese Buchung abgelehnt. Das gilt auch für Buchungen, die in der Vergangenheit gebucht werden. 6. Mehrere RTAS-Systeme können konsolidiert werden, so, dass sie dann als ein System funktionieren. 7. Das RTAS arbeitet nicht alleinstehend, sondern zusammen mit z.b. einem ERP-System. Ein Teil des RTAS ist ein Metadata-Repository, in dem alle relevanten Objekte des ERP-System beschrieben werden. Im Repository befindet sich außerdem die komplette Beschreibung des Kontenplanes, der Dimensionen, der Buchungen, Buchungsalgorithmen, Buchungsworkflow und der Beziehungen zwischen den Objekten des ERP-Systems und den RTAS-Objekten. 8. Buchungen können in einem "Synchronmodus" oder in einem "Asynchronmodus" gebucht werden. Wenn man möchte, dass die Buchungen in der Transaktion gebucht werden, in der der Geschäftsprozess abgewickelt wird, dann kann "Synchronmodus" verwendet werden. Z.B. bucht man den Wareneingang im ERP-System und gleichzeitig (in derselben Transaktion) bucht man den Wareneingang im RTAS. In diesem Fall bleiben ERP und RTAS-Systeme immer in einem transaktionell konsistenten Zustand.

7 Wenn die transaktionelle Konsistenz mit dem ERP-System unwichtig ist, können sog. asynchronen Buchungsanfragen verwendet werden. Das ERP-System oder RTAS selbst initiiert die Buchungsanfragen, die dann in einer Buchungswarteschlange angelegt und von der Buchungsengine im Hintergrund abgearbeitet werden. 9. Um die im RTAS gespeicherte Information zu bekommen dient die Abfragenengine. Die Abfragen werden in einem XML-Form definiert. Es gibt zwei Arten von Abfragen - Abfragen auf der Kontenebene und Abfragen auf der Buchungsebene. Hier sind einige Beispiele der Abfragen: <RTAS> <QUERY Object="AccountBalances"> <OUTPUT> <Field Expr="{Product}.{ProductSubcategory}.{ProductCategory}.{Name}" Alias="Category" Optional="true" /> <Field Expr="{Product}.{ProductSubcategory}.{Name}" Alias="Subcategory" /> <Field Expr="{Product}.{ProductModel}.{Name}" Alias="Model" /> <Field Expr="{Product}.{ProductNumber}" Alias="Product" /> <Measure Aggregate="AVG" Expr="{PriceDeb}[2] - {PriceDeb}[1]" Alias="Average income" /> <Measure Aggregate="AVG" Expr="{PriceCred}[2] - {PriceCred}[1]" Alias="Average outcome" /> </OUTPUT> <WHERE> <AND Property="{Account}.{Code}" Operator="=" Value="'STOR'" /> </WHERE> <DATES> <Date Index="2" Value="' '" /> <Date Index="1" Value="' '" /> </DATES> </QUERY> </RTAS> <RTAS> <QUERY Object="Bookings"> <OUTPUT> <Field Expr="{BookingType}.{Name}" Alias="Booking Type" /> <Field Expr="{DocType}.{Name}" Alias="Document Type" /> <Field Expr="{Date}" /> <Field Expr="{Debet}.{Account}.{Name}" Alias="Account Debet" /> <Field Expr="{Credit}.{Account}.{Name}" Alias="Account Credit" /> <Field Expr="{SalesOrderDetail}.{SalesOrderDetailID}" Alias="OrderDet" /> <Measure Aggregate="SUM" Expr="{Price}" Alias="Amount" /> </OUTPUT> <WHERE> <AND Property="{SalesOrderDetail}.{SalesOrder}.{SalesOrderID}" Operator="<" Value="62426" /> </WHERE> <DATES> <Date Index="1" From="' '" To="' '" /> </DATES> </QUERY> </RTAS> <RTAS> <QUERY Object="Bookings"> <OUTPUT> <Field Expr="{DocNumber}" /> <Field Expr="{Document}" /> <Field Expr="{Date}" /> <Field Expr="{PurchaseOrderDetail}.{Product}.{Name}" Optional="true" /> <Field Expr="{WorkOrder}.{DueDate}" Optional="true" /> </OUTPUT> <WHERE> <AND Property="{PurchaseOrderDetail}.{PurchaseOrder}.{PurchaseOrderID}" Operator="=" Value="30" /> </WHERE> <DATES /> </QUERY> </RTAS>

8 Implementierung Das RTAS wird folgenderweise eingesetzt: 1. Man beschreibt die Objekte des Informationssystems 2. Man definiert den Kontenplan, die Konten, deren Eigenschaften und Dimensionen. 3. Man definiert die Plausibilitätsregeln auf der Konten- und Dimensionsebene 4. Man definiert die Buchungen, welche zwischen den Konten durchgeführt werden können. 5. Man legt Buchungsalgorithmen an. Ein Buchungsalgorithmus ist eine Beschreibung davon, wie aus den Eigenschaften eines Objekts des Informationssystems die notwendige Information für eine Buchung ermittelt werden kann. Nachdem die Buchungsalgorithmen definiert sind, kann man Buchungen erzeugen. Buchungen können sowohl offline als auch online angelegt werden. Besonders interessant sind Online-Buchungen, wenn diese innerhalb der operativen Transaktionen durchgeführt werden. In diesem Fall können die Konten einerseits als eine universelle und sehr leistungsfähige operative Datenquelle für die Transaktionen dienen, anderseits können einige Plausibilitätsprüfungen auf der Kontenebene erfolgen. Das entwickelte RTAS ist sehr leistungsfähig. Es ist möglich, Hunderte von Buchungen pro Sekunde in jeder von mehreren unabhängigen Threads zu erzeugen. Die erfasste Buchungsmenge kann Hunderte Millionen von Buchungen beinhalten, ohne die Leistungsfähigkeit des Systems zu beeinträchtigen.