BI-Datenmanagement (Teil 1): Datenaufbereitung durch den ETL-Prozess

Operative Unternehmensdaten, wie sie im Tagesgeschäft anfallen, unterstützen die Geschäftsprozesse eines Unternehmens. Die Daten beispielsweise aus ERP-, Buchhaltungs- oder Warenwirtschaftssystemen sind ausschließlich auf die Steuerung und Überwachung des Tagesgeschäfts bezogen. Aufgrund dieser Ausrichtung spiegeln sie einen temporären Informationsstand wieder und werden normalerweise durch Folgetransaktionen im Zeitverlauf aktualisiert.

Analytische BI-Anwendungen setzen nur in Ausnahmefällen direkt auf den operativen Datenbeständen auf. In der Regel verlangen sie themenbezogene, integrierte Datensammlungen – etwa nach Kunde, Produkt oder Organisationseinheit. Dazu muss einerseits das aus Sicht des Managements gewünschte, meist aggregierte Datenmaterial dauerhaft über große Zeiträume abgelegt werden. Andererseits müssen große Datenmengen aus mehreren operationalen Datenbanken konsolidiert werden, die dann im Data Warehouse gespeichert werden.

Um Daten aus mehreren operativen Datenquellen zu vereinigen und aufzubereiten werden sie mittels gezielter Umwandlungsaktionen in managementrelevante Informationen überführt. Diese Aktion wird in drei Schritten als so genannter ETL-Prozess vollzogen. ETL bedeutet im einzelnen:

• Extraktion (Extract) der relevanten Daten aus verschiedenen Quellen

• Transformation (Transform) der Daten in das Schema und Format der Zieldatenbank

• Laden (Load) der Daten in das Data Warehouse

Die Erstellung des ETL-Prozesses ist oft der aufwendigste Schritt bei der Data-Warehouse-Entwicklung. Er sollte nicht vernachlässigt werden, denn ein solide aufgebautes Data Warehouse ist nur mit einer qualitativ hochwertigen Datenbasis möglich.

Extraktion

Der erste Schritt des ETL-Prozesses ist die Extraktion. In diesem Anfangsschritt werden die Daten aus den Quellsystemen ausgewählt und für den folgenden Transformationsvorgang vorbereitet. In der Regel wird bei der Extraktion lediglich ein Ausschnitt aus den Quelldaten selektiert.

Die Quellen können aus verschiedenen Informationssystemen mit unterschiedlichen Datenformaten und –strukturen bestehen. Nur im Idealfall sind die Daten in relationalen Datenbanken abgelegt. Oftmals trifft man jedoch auf andere Datenbanksysteme oder auch unstrukturierte Textdaten, die sich nur schwer einlesen lassen.

In Zusammenarbeit mit den Administratoren der operativen Datensysteme ist zu prüfen, ob direkte Durchgriffsmöglichkeiten oder Exportverfahren verfügbar sind. ETL-Tools, wie sie am Ende des Artikel vorgestellt werden, können dabei helfen: Sie ermöglichen den Zugriff auf die vielfältigen Datenformate.

Sofern native Treiber zur Verfügung stehen kann durch das eingesetzte ETL-Tool direkt auf die Datenbanken zugegriffen werden. Wird Windows als Betriebssystem verwendet, bietet sich der Einsatz von ODBC und OLE DB an. Diese durch Microsoft entwickelten Standards legen einheitliche Schnittstellen fest, die durch fast alle Datenbanken und ETL-Tools unterstützt werden.

Um das Data-Warehouse mit aktuellen Daten zu versorgen, muss die Extraktion regelmäßig stattfinden. Dies geschieht entweder synchron mit den Quellen oder asynchron. Die asynchrone Extraktion kann periodisch, ereignisgesteuert oder anfragegesteuert erfolgen. Bei der periodischen Synchronistaion erzeugt die Quelle in regelmäßigen Abständen Auszüge ihrer Daten, die regelmäßig abgefragt werden. Die ereignisgesteuerte Synchronisation generiert nur bei bestimmten Ereignissen einen Auszug - beispielsweise nach einer bestimmten Anzahl von Änderungen. Die anfragegesteuerte Synchronisation schließlich stellt Auszüge erst auf Anfrage bereit.

Es sollte auch beachtet werden, dass für das Auslesen der operativen Datenbestände nur begrenzte Zeitfenster zur Verfügung stehen. Oft kann der Zugriff auf die Quellsysteme nur nachts oder zu bestimmten Ruhezeiten stattfinden. Ansonsten würde der operative Tagesbetrieb durch aufwändige Lese- und Kopiervorgänge behindert werden.

Transformation – 1. Schritt: Filterung

Zentrale Aufgabe des ETL-Prozesses ist die Datentransformation. Hierbei werden die Ausgangsdaten an das geforderte Zielschema angepasst. Die Transformation setzt sich aus den vier Teilprozessen Filterung, Harmonisierung, Aggregation und Anreicherung zusammen. Diese Schritte werden nun etwas ausführlicher vorgestellt. Die folgende Tabelle liefert hierzu den ersten Überblick.

Bestandteile des Transformationsprozesses

Filterung	Extraktion und Bereinigung syntaktischer und inhaltlicher Defekte der Daten
Harmonisierung	Betriebswirtschafliche Abstimmung der gefilterten Daten
Aggregation	Verdichtung der gefilterten und harmonisierten Daten
Anreicherung	Berechnung und Speicherung betriebswirtschaftlicher Kennzahlen

Beim Teilprozess Filterung geht es um die Bereinigung der extrahierten Daten von syntaktischen und semantischen Mängeln. Syntaktische Mängel sind formale Fehler wie falsche Steuerzeichen, semantische Mängel Fehler betriebswirtschaftlich-inhaltlicher Art, etwa offensichtlich falsche Umsatzzahlen.

Die Literatur unterscheidet weiterhin Mängel der 1., 2. und 3. Klasse. Mängel der 1. Klasse lassen sich automatisch erkennen und während des Extraktionsvorgang auch automatisch korrigieren. Bei Mängeln der 2. Klasse erfolgt zwar die Defekterkennung automatisch, die Korrektur muss aber manuell nach dem Extraktionsvorgang vorgenommen werden. Mängel der 3. Klasse schließlich können ausschließlich manuell erkannt und korrigiert werden.

Mängelklassifikation

Bereinigung	1.Klasse	2. Klasse	3. Klasse
	Automatische Erkennung und automatische Korrektur	Automatische Erkennung und manuelle Korrektur	Manuelle Erkennung und manuelle Korrektur
Syntaktische Mängel	Bekannte Formatanpassungen	Erkennbare Formatinkompatibilitäten	-
Semantische Mängel	Fehlende Datenwerte	Ausreißerwerte / unstimmige Wertekonstellationen	Unerkannte semantische Fehler in operativen Quellen
Quelle: Kemper/Finger: Transformation operativer Daten, in: Chamoni/Gluchowski: Analytische Informationssysteme, Springer

Filterung - Drei Klassen von Datenmängeln

Mängel der 1. Klasse sind grundsätzlich automatisch erkennbar und durch bestimmte Algorithmen behebbar. Beispielsweise können auf syntaktischer Ebene interne Format-, Steuer- und Sonderzeichen während der Extraktion identifiziert und durch Zuordnungstabellen (Mapping-Tables) in den extrahierten Daten bearbeitet werden. Analoges gilt für semantische Fehler. Wurden beispielsweise bei der Übertragung von Umsatzdaten einzelne Filialen vergessen, können diese durch Äquivalenzwerte wie monatliche Planwerte oder Ist-Werte des Vormonates ergänzt werden.

Mängel der 2. Klasse können ebenfalls automatisch erkannt werden, müssen aber manuell von Technikern oder Betriebswirten korrigiert werden. Bei syntaktischen Mängeln sind dies etwa bislang nicht berücksichtigte Syntaxvarianten in den operativen Datenquellen. Künftig können diese dann automatisiert behandelt werden.

Auf semantischer Ebene können automatisierte Plausibilitätskontrollen und Wertebereichsüberprüfungen ungültige Datenfelder entdecken. Beispielsweise durch Vergleich von Bilanz- und Kontrollsummen. Je nach Schwere des Fehlers müssen eventuell auch die operativen Quellen korrigiert werden.

Während syntaktische Mängel immer automatisiert erfasst werden können, trifft dies nicht auf semantische Mängel zu. Mängel der 3. Klasse betreffen deshalb ausschließlich semantische Fehler. Dies sind alle Mängel, die sich nicht durch die Prüfverfahren von Klasse-2-Fehlern entdecken lassen, also weder durch Plausibilitäts- noch Wertebereichprüfungen. Vielmehr lassen sich diese Fehler nur durch betriebswirtschaftliche Experten identifizieren. Auch hier müssen eventuell die operativen Quellen korrigiert werden.

Transformation – 2. Schritt: Harmonisierung

Der zweite Transformationsschritt nach der Filterung ist die Harmonisierung der Daten. Hierbei werden die gefilterten und bereinigten Daten zusammengeführt. Vor allem drei Problemklassen müssen hier angegangen werden: Erstens, das Abgleichen von Kodierungen, Synonymen und Homonymen, zweitens, das Auflösen von Schlüsseldisharmonien und drittens, die betriebswirtschaftliche Harmonisierung.

Was beim Abgleichen von Kodierungen, Synonymen und Homonymen passiert, lässt sich an folgenden Beispielen veranschaulichen:

• Einzelne Datenbestände können unterschiedlich kodiert sein. So können Attribute wie Geschlecht in Datenquelle 1 als „M“/“W“ kodiert sein, in Datenquelle 2 als 0-1-Variable.

• Unterschiedliche Attributnamen können die gleiche Bedeutung haben (Synonymie). Beispielsweise kann in Datenquelle 1 für den Namen von Betriebsmitarbeitern das Attribut „Personal“ vorgesehen sein, in Datenquelle 2 aber „Mitarbeiter“.

• Umgekehrt können gleiche Attributnamen unterschiedliche Bedeutungen haben (Homonymie). In Datenquelle 1 kann „Partner“ beispielsweise den Namen von Kunden bezeichnen, in Datenquelle 2 den Namen von Lieferanten

In allen drei Fällen müssen die Daten harmonisiert werden. Im ersten Fall muss der Attributwert einheitlich z.B. auf 0-1-Werte festgelegt werden, im zweiten Fall ist ein identischer Attributname zu wählen und im dritten Fall ein unterschiedlicher Attributname.

Auch hier werden für den Abgleich in der Regel Mapping Tables implementiert, die die gefilterten Dateien über Namensabgleichungen und Kodierungsabstimmungen zu themenorientierten Datensammlungen zusammenführen.

Harmonisierung – Schlüssel- und Betriebswirtschaftliche Harmonisierung

Das zweite Problem bei der Harmonisierung ist die Auflösung von Schlüsseldisharmonien. Wenn die Daten mehrerer Datenbanken zusammengeführt werden ist ein gemeinsamer Primärschlüssel notwendig. Der ist in den seltensten Fällen vorhanden. Gelöst wird das Problem wieder meist mit Hilfe einer Zuordnungstabelle, die beispielsweise für jeden Kunden einen neuen, künstlichen Primärschlüssel generiert. Die Primärschlüssel der operativen Systeme werden dann als Fremdschlüssel mitgeführt, so dass übergreifende Datenauswertungen möglich sind.

Im dritten Teilschritt erfolgt schließlich die Vereinheitlichung betriebswirtschaftlicher Begriffe. Dies ist weniger ein technisches, als betriebswirtschaftlich-organisatorisches Problem. Dabei müssen die operativen Daten – etwa die gebiets- und bereichsspezifische Gültigkeit, die Währung oder Periodenzählweise – in einheitliche Wert überführt werden. So sollten etwa monetäre Größen verschiedener Währungen in einem einheitlichen Währungssystem vorliegen.

Für beide Schritte lassen sich Transformationsregeln implementieren, die diese Harmonisierung erledigen. Damit ist der Harmonisierungsprozesses abgeschlossen. An dessen Ende liegen nun bereinigte und konsistente Daten auf einer Ebene vor, die für Analysezwecke direkt nutzbar wäre.

Transformation – 3. Schritt: Aggregation

Es folgt nun die betriebswirtschaftliche Aufbereitung. Im Aggregationsschritt werden die Daten in die gewünschte Granularität überführt. Sollen die detailliertesten Daten des Data Warehouses beispielsweise tagesaktuelle Werte auf Basis von Produkt- und Kundengruppen bilden, so müssen alle Einzeldaten über Aggregationsalgorithmen zu produktgruppen- und kundengruppenspezifischen Werten auf Tagesbasis zusammengefasst werden.

Auch Vorsummierungen, wie sie bestimmte betriebswirtschaftliche Kennziffern benötigen, werden auf dieser Ebene durchgeführt und in den Datenbestand übernommen. Ziel dabei ist es, Summenwerte zu erzeugen, die aus Performancegründen vorberechnet im Data Warehouse gehalten werden.

Zum Zweck der Aggregation werden meist Dimensionshierarchietabellen entwickelt. An der Spitze solcher Hierarchietabellen steht das Element „Gesamt“ oder „Alle“, in der alle Einzelelemente aggregiert sind. Eine einfache Hierarchie wäre zum Beispiel „Kunde, Kundengruppe, Gesamt“.

Wird nach verschiedenen Kriterien hierarchisiert, entstehen parallele Hierarchien. Diese sind oft notwendig, da im Unternehmen unterschiedliche Zielgruppen und Auswertungszwecke vorhanden sind. Beispielsweise ist ein Kundenmanager eher an Summen auf der Basis von Kundengruppen interessiert, während ein Produktmanager meist auf Summen für bestimmte Produktarten zurückgreift.

Dieses Stadium der Datenaufbereitung ist ein wichtiger Einschnitt, was die „Neutralität“ der Daten betrifft. Mit der Ausrichtung der Datenhaltung auf bestimmte Anwendungsklassen und Zielgruppen wird der Ansatz einer applikationsneutralen Datenmodellierung auf dieser Ebene praktisch aufgegeben.

Transformation – 4. Schritt: Anreicherung

Die Anreicherung ist der letzte Schritt beim Transformieren der Daten. Wie bereits angedeutet werden in diesem Transformationsstadium die Daten um betriebswirtschaftliche Kennziffern expandiert. Es werden Berechnungen durchgeführt und die Ergebnisse den übrigen Daten hinzugefügt – eine weitere Aufweichung der strikten Trennung zwischen Daten und Programmlogik.

Gespeichert werden vor allem Kennziffern, die für mehrere Informationsnachfrager wichtig sein können. Beispielsweise können wöchentliche Deckungsbeiträge auf Produktebene oder jährliche Deckungsbeiträge auf Filialebene kalkuliert und integriert werden. Ersteres kann für den Produktmanager interessant sein, letzteres für Filialleiter und Geschäftsführung.

Die Aufnahme dieser Kenngrößen in den Datenbestand hat mehrere Vorteile. So sind auf Grund der Vorberechnungen Abfragen effizienter durchführbar, die errechneten Werte sind wegen der einmaligen Berechnung konsistenter und es liegt ein abgestimmtes betriebswirtschaftliches Instrumentarium vor.

Die Hauptarbeit des ETL-Prozesses ist mit Extraktion und insbesondere Transformation abgeschlossen. Die ganzen Teilprozesse in dieser Phase finden in einem Bereich statt, den man als Staging Area bezeichnet.

Laden

Es fehlt noch der letzte Schritt von ETL, das „L“, also „Laden“ der geprüften Daten. Beim Laden werden die vorbereiteten Daten in das Data Warehouse integriert. Hierfür müssen sie physisch in die Datenbank des Data Warehouses verschoben werden und darauf aufbauende Datenanalysesysteme aktualisiert werden.

Das Laden aus dem Staging Area in das Data Warehouse soll möglichst effizient geschehen. Generell sollten die ETL-Prozesse aber immer so kurz wie möglich gehalten werden. In der Regel werden nicht bei jedem Aktualisierungsvorgang die kompletten Daten neu aus dem Staging Area geladen. Zeit- und ressourcensparender ist es, nur die modifizierten und neu hinzugekommenen Quellen zu laden. Somit brauchen bereits in der Extraktionsphase lediglich die veränderten Daten selektiert werden. Dazu muss lediglich in jedem zu ladenden Datensatz der Zeitpunkt der letzten Änderung mit abgespeichert werden.

Der Ladevorgang sollte möglichst effizient geschehen, so dass die Datenbank in dieser Zeit nicht oder nur kurz blockiert wird und ihre Integrität gewahrt bleibt. Zusätzlich kann eine Versionshistorie angefertigt werden, in der Änderungen protokolliert werden, so dass auf Daten zurückgegriffen werden kann, die zu früheren Zeitpunkten gültig waren.

Ein weiterer wichtiger Faktor ist, dass die Datenbanken während des Ladens nicht oder nur kurz blockiert werden sollten. Ansonsten ist kein Zugriff der Endanwender auf das Data Warehouse und die Analysewerkzeuge möglich. Der Ladevorgang sollte deshalb stets im Rahmen des zur Verfügung stehenden Zeitfensters abgeschlossen werden. Im Allgemeinen ist dieses Zeitfenster in der Nacht gelegen, da dann die Dienste nicht benötigt werden.

ETL-Tools

Grundsätzlich kann der ETL Prozess in einer beliebigen Programmiersprache umgesetzt werden. Große Unternehmen nutzen aber meist bestehende ETL-Lösungen von Drittherstellern. WebSphere DataStage von IBM beispielsweise ist ein Bestandteil der WebSphere Data Integration Suite und beinhaltet Data Profiling, Data Quality und Cleansing Werkzeuge.

Das ETL-Tool der Firma Ab Initio stellt verschiedene Softwarekomponenten bereit, um die Parallelisierung von Datenströmen, die als Partitionen bezeichnet werden, zu ermöglichen. Es ist von der Architektur her eine Art Generator. Ein ausführbarer ETL-Prozess ist ein Kornshell-Skript, das bei der Entwicklung generiert oder auch manuell erstellt werden kann.

Relativ weit verbreitet ist der Oracle Warehouse Builder. Mit ihm können Daten von verschiedenen Datenquellen auch aus Systemen wie SAP, Sybase oder Informix gelesen und in das Data Warehouse homogenisiert umgewandelt werden. Hier sorgt der Warehouse Builder nicht nur für die Datentransformation, sondern auch – in Verbindung mit Oracle Workflow – für die richtige Reihenfolge unterschiedlicher Lade- und Transformationsschritte, die im Editor des Warehouse Builders als Prozesslandkarte definiert werden können. Daraus entsteht dann automatisch die notwendige Infrastruktur für Reporting und Analyse.

Weitere bekannte ETL-Hersteller und Tools sind beispielsweise der Data Integrator von Business Objects, der Data Mirror von IBM, Informatica Power Center oder Hummingbird Genio.

Fazit

Der ETL-Prozess übernimmt die Bereinigung und Transformation der operativen Daten und stellt sie im Data Warehouse für weitergehende Analysen bereit. Umrahmt von den beiden Endpunkten – der Datenextraktion auf der operativen Seite und dem Laden der bearbeiteten Daten auf Seite des Data Warehouses – übernimmt der Transformationsprozess die entscheidende Aufbereitung in vier Schritten. Diese Aufbereitung erfolgt in den Abschnitten Filterung, Harmonisierung, Aggregation und Anreicherung.

Die beiden ersten Transformationsschritte, Filterung und Harmonisierung, sind für die Bereinigung und Aufbereitung von Daten zuständig, etwa die Angleichung unterschiedlicher Kodierungen und Währungen. Danach sind die Daten prinzipiell bereits für BI-Analysen verwertbar. Die beiden folgenden Schritte der Aggregation und Anreicherung fassen Daten themenspezifisch zusammen und erweitern sie um betriebswirtschaftliche Kennzahlen. Die so erzeugten und ins Data Warehouse geladenen Daten erhalten damit bereits eine bestimmte Ausrichtung auf die Bedürfnisse einzelner Nutzergruppen und Analysezwecke. (ala)