Eine häufige Anforderung an Business-Intelligence-Systeme ist eine integrierte Umrechnung von Währungskursen. Typische Zielsetzungen sind einerseits die Vergleichbarkeit von Geschäftseinheiten in unterschiedlichen Währungsräumen (z.B. innerhalb und außerhalb der Euro-Zone) und die korrekte Aggregation von Daten mit unterschiedlicher Währungseinheit, andererseits jedoch auch die Ermittlung von Währungskurseffekten bei beispielsweise gegenüber der Planung geänderten Kursen.

Konzeption

Wichtigste Vorüberlegung ist die gewünschte Umrechnungsrichtung. Grundsätzlich zu unterscheiden sind drei Fälle:

Unidirektionale Umrechnung von Lokalwährung in Konzernwährung
Beispiel: Tochtergesellschaften in Nicht-Euro-Ländern berichten ihre Umsatzzahlen in lokaler Währung; im zentralen System sollen die Werte in Konzernwährung aggregiert werden, um so einen Benchmark zu ermöglichen sowie den Gesamtumsatz zu ermitteln.

Unidirektionale Umrechnung von Konzernwährung in Lokalwährung
Beispiel: Umsatzzahlen oder Preise aus dem zentralen System werden an Vertriebsbüros in Nicht-Euro-Ländern übermittelt und sollen dort lokalen Vergleichsgrößen gegenübergestellt werden.

Bidirektionale Umrechnung zwischen Lokalwährungen und der Konzernwährung
Beispiel: In der Konzernzentrale sollen zu Benchmarkzwecken sämtliche Daten aller Töchter gesammelt, in Konzernwährung umgerechnet und konsolidiert werden. Im Gegenzug werden die Töchter mit den Zahlen ihrer Vergleichspartner in der jeweils gültigen lokalen Währung versorgt. Alle Unternehmenszahlen sind folglich in allen Systemwährungen verfügbar.

In einer lehrbuchgerechten Systemarchitektur aus relationalem Data Warehouse (z.B. Microsoft SQL Server 2008) und daraus bestückten OLAP-Cubes (z.B. Microsoft Analysis Services), auf die später die Endanwender mit Business-Intelligence-Werkzeugen (z.B. Bissantz DeltaMaster) zugreifen, bieten sich hinsichtlich der Implementierung zwei generelle Alternativen an: Entweder kann die Umrechnung bereits physikalisch in der relationalen Datenbank erfolgen, was eine Vervielfachung des Datenvolumens zur Konsequenz hat, oder aber die Rechenlogik erfolgt zur Laufzeit mit Hilfe von Formeln innerhalb der OLAP-Datenbank, was bei größeren Datenmenden und/oder komplexen Dimensionsstrukturen zu Performanceeinbußen führen kann.

Unsere Erfahrungen führen zu der Faustregel “unidirektionale Umrechnung in SQL, bidirektionale Umrechnung in OLAP”. Die Begründung ist so einfach wie pragmatisch: Da der negative Effekt einer ad-hoc-Kalkulation mitunter nicht absehbar ist, ist die physikalische Vorberechnung aus Performancegründen vorzuziehen. Bei unidirektionaler Umrechnung (siehe die oben beschriebenen Fälle 1 und 2) ist das Resultat maximal eine Verdoppelung der ursprünglichen Datenmenge und wird daher billigend in Kauf genommen. Existiert jedoch eine Anforderung nach bidirektionaler Umrechnung, vervielfacht sich das Volumen abhängig von der Anzahl der beteiligten Währungen. Datenaktualisierungszeiten und der erforderliche Speicherplatz können dabei in unvertretbarem Maße ansteigen.

Implementierung

Fall A: Implementierung im relationalen Data Warehouse

Alle monetären Basisdaten (Bewegungsdaten) müssen direkt oder durch Joins (z.B. über die Heimatwährung der liefernden Geschäftseinheit) eine Währungseinheit enthalten.

Die Währungskurse werden in einer separaten Tabelle gepflegt. Eine typische Struktur lautet “Zeit-Wertart-Währung-Kurs”. Die Kurse können in beliebiger Granularität (Jahres-, Monats- oder Tageskurse, Von-bis-Gültigkeit etc.) gespeichert werden. Das untenstehende Beispiel verwendet eine Logik “Kurs gültig ab”, wodurch geringerer Aufwand bei der Kurspflege entsteht, der SQL-Join jedoch geringfügig komplexer wird.

Die Umrechnung – Lokalwährung in Konzernwährung oder umgekehrt – erfolgt durch einen Join der Bewegungsdaten mit der Kurstabelle über die gewünschten Kriterien (mindestens Zeit und Währung, ggf. auch Wertart) und einfaches Ausmultiplizieren.

Das Ergebnis muss wiederum eine Währungsspalte enthalten, in die jedoch idealerweise nicht das Kürzel der Konzernwährung (z.B. “EUR”), sondern als konstanter Begriff “Konzernwährung” geschrieben wird. So bleiben auch bereits in Konzernwährung berichtete Rohdaten stets separat von den umgerechneten Ergebnissen.

Im Ergebnis werden die Bewegungsdaten maximal doppelt gespeichert.

Der Endanwender steuert seine Betrachtung über eine zusätzliche Dimension, in der die einzelnen Währungen oder aber die Unterscheidung “Lokalwährung” vs. “Konzernwährung” möglich ist.

Fall B: Implentierung im OLAP-Cube

Die Vorbereitung der Bewegungsdaten und der Kurstabelle erfolgt in identischer Form wie oben beschrieben. Der Vorgang der Multiplikation der Basisdaten mit den Umrechnungskursen findet jedoch mit Hilfe von Berechnungen innerhalb der OLAP-Datenbank (hier: Microsoft Analysis Services 2005/2008) statt.

Zunächst werden zwei neue Dimensionen modelliert: Die erste (“Währung”) enthält alle beteiligten Währungen; die zweite (“Währungssicht”) dient der Umschaltung zwischen Lokalwährung, Konzernwährung und individuell ausgewählter “Zielwährung”.

Der OLAP-Cube wird ergänzend zu seinen ursprünglichen Inhalten um eine zusätzliche MeasureGroup ergänzt, die die Kurse speichert:

Idealerweise ist die Aggregationsregel für die Kurs-Measure auf die Eigenschaft “LastNonEmpty” zu setzen. Damit wird es möglich, auf Tagesebene in beliebigen Abständen Kurse zu speichern, wobei jeder Kurs jeweils bis zur nächsten Änderung gültig bleibt (Bestandslogik). So erübrigt sich die Speicherung sämtlicher – auch unveränderter – Kurse zu jedem Zeitpunkt. Diese von Microsoft unter dem Titel “Extended Business Intelligence” geführte Einstellung ist jedoch nur in der Enterprise Edition von Analysis Services 2005/2008 verfügbar.

Um das OLAP-Datenbanken immanente, für unsere Zielsetzung jedoch unerwünschte Verhalten, Werte zuerst entlang der verwendeten Dimensionen zu aggregieren und erst zuletzt etwaige Rechenregeln anzuwenden, zu unterbinden, muss zwingend mit Scope-Befehlen gearbeitet werden, die die Granularitätsebene der Berechnung detailliert vorgeben:

Sofern der Cube auch nichtmonetäre Measures (z.B. Absatzmengen) enthält, sind in die Scope-Anweisung nur die gewünschten Measures einzubeziehen.

Der Endanwender navigiert über die beiden neuen Dimensionen Währungssicht und Währung. Alle nicht sinnvollen Kombinationen werden per Scope-Anweisung eliminiert:

Mit Hilfe der Dimension Währungssicht können komplexere Kurseffekte auch elegant mit der in DeltaMaster integrierten Deckungsbeitragsflussrechnung analysiert werden, indem die Währungssichten “orig. Währung” (Lokalwährung) und “nach Euro” (Konzernwährung) als Abweichungsdimension verwendet werden.

Verwendung von Stichtags- und Durchschnittskursen

Nach identischer Logik ist die Erweiterung des Modells um Stichtags- und Durchschnittskurse möglich. Ein typisches Anwendungsbeispiel ist die Abbildung von Finanzzahlen in Form von Gewinn- und Verlustrechnung sowie Bilanz, wobei unterschiedliche Positionen mit unterschiedlichen Kursarten behandelt werden müssen.

Hierzu wird in der Kurstabelle ein weiteres Feld zur Unterscheidung zwischen Stichtags- und Durchschnittskurs benötigt, und eine Mappingtabelle pro Analysewert dient der Zuordnung der Kursart zur jeweiligen Kennzahl.