Besonderheiten der Datenintegration

3.3.1.1 Funktionale Besonderheiten der Datenintegration

Durch Schnittstellen wird die Verbindung zwischen einem Quellsystem und dem DWS hergestellt. Handelt es sich bei der Schnittstelle um einen direkten Zugriff, so werden die Daten aus den produktiven Tabellen des operativen Systems gelesen.

Bei einem indirekten Zugriff wird von dem operativen System ein Datenabzug bereit-gestellt. Je nach Quellsystem kann der Abzug in verschiedenen Formaten vorliegen:

als Tabelle, als View, als Text-Datei oder als Datei in einem Spezialformat. Eine Feh-lerquelle der Schnittstelle ist das Einlesen von Spezialformaten.

Als Standard- bzw. Trivialformate gelten relationale Tabellen als auch strukturierte Text-Dateien im CSV- oder XML-Format. Ein Spezialformat ist beispielsweise ein COBOL Copybook, welches sich im Bereich von Mainframe-Anwendungen finden lässt und gerade bei Versicherungs- und Finanzunternehmen eine hohe Verbreitung hat. Die Komplikation bzw. Komplexität bei Copybooks entsteht hauptsächlich durch

Kapitel 3 - Testen während der Entwicklung

Mehrfachdefinitionen (Redefinitionen) von Teilbereichen eines Datensatzes und die daraus resultierenden Mehrfachstrukturen. Im Listing 3-1 ist exemplarisch eine Schnittstelle für Versicherungsschäden als Copybook implementiert. Je nach Versi-cherungsprodukt (Kraftfahrt oder Privathaftpflicht) enthält die Struktur entweder die spezifischen Attribute „HSN“, „TSN“ und „SF-Klasse“ bzw. „Grobfahrlässig“ und

„Selbstbeteiligung“. Für die Unterscheidung, ob es sich bei einem Datensatz um ei-nen Kraftfahrt- oder um eiei-nen Privathaftpflicht-Datensatz handelt, muss in dem Da-tenintegrationsprozess die entsprechende Logik implementiert werden.

01

05 PRIVATHAFTPFLICHT REDEFINES KRAFTFAHRT.

10 GROBFAHRLAESSIG PIC X(06).

Die Säuberung der eingelesenen Daten geschieht durch das Anwenden von Quali-tätsregeln sowie das Reagieren auf Verletzungen der Regeln. Damit ergeben sich als mögliche Fehler das falsche Anwenden der Qualitätsregeln sowie das falsche Rea-gieren auf die Verletzung von Regeln. [vgl. The07, S. 2f; Kam10, S. 9f] Die regeln lassen sich einteilen in technische Qualitätsregeln sowie fachliche Qualitäts-regeln. Die fachlichen Qualitätsregeln werden vom Fachbereich bzw. Auftraggeber vorgegeben und beziehen sich auf die fachlichen Inhalte der Daten und ob diese in sich stimmig sind. Einfache Regeln können etwa lauten, dass die Postleitzahl zu ei-nem Ort passen muss, ein Kunde mit „Gold-Status“ auch tatsächlich den dafür benö-tigten Umsatz erreicht hat oder zu einer Warenlieferung auch eine Bestellung

vor-Kapitel 3 - Testen während der Entwicklung

liegt. Die Regeln müssen spezifiziert sein und werden dann vom Entwickler imple-mentiert. Aus technischer Sicht werden darüber hinaus noch weitere Regeln ange-wendet. Der gesamte Integrationsprozess stützt sich auf ein fest definiertes Format der Daten, bestehend aus Datentypen und -längen, Genauigkeiten von Dezimalwer-ten oder das Vorkommen von NULL-Werten. Wird das Format nicht eingehalten, bricht der Prozess im günstigsten Fall mit einem harten Programmfehler ab, etwa einer NULL-Pointer-Exception oder mit einer Format-Exception bei einem alphanu-merischen Wert in einem nualphanu-merischen Feld. Schlimmer hingegen können Fehler aufgrund von zu kurzen oder zu ungenauen Datentypdefinitionen sein. Da es sich bei den verarbeiteten Kennzahlen häufig um Geldbeträge handelt, ist eine absolute Ge-nauigkeit der Zahlen unerlässlich. In Listing 3-2 sowie in Abbildung 3-5 ist ein Bei-spiel gegeben, in dem es bei einer Gleitkommazahl vom Typ Float zu einem ab-weichenden Wert kommt. Eine solche Wertezuweisung führt jedoch nicht zwingend zu einem Programmabbruch. Daher müssen Regeln angewendet werden, mit denen die Daten auf die Einhaltung ihrer Typendefinition geprüft werden. Entstehen können Formatabweichungen vor allem, wenn das Quellsystem seine Schnittstellendaten als Text-Datei bereitstellt, weil diese im Gegensatz zu einer Datenbanktabelle keine Typsicherheit garantieren können.

01 02 03 04

Float f = new Float(1234567.89);

Double d = new Double(1234567.89);

System.out.println("Float : " + f);

System.out.println("Double: " + d);

Listing 3-2: Ungenauigkeit bei Gleitkommazahlen [Eigene Darstellung]

Abbildung 3-5: Ungenauigkeit bei Gleitkommazahlen [Eigene Darstellung]

Kapitel 3 - Testen während der Entwicklung

Auf die Verletzung einer Regel kann auf vier verschiedene Weisen reagiert werden:

[vgl. Kem10, S. 25]

• Autokorrektur des Datensatzes

• Aussteuerung des Datensatzes zur manuellen Nachbesserung

• Sofortiger Abbruch des gesamten Prozesses

• Bedingter Abbruch nach Überschreitung einer Anzahl von Regelverletzungen

Eine Autokorrektur ist bei dem oben genannten Beispiel des Kundenstatus nach Um-satz möglich: Der Kunde bekommt bei einem zu geringen UmUm-satz automatisch den entsprechenden niedrigeren Status zugeordnet. Eine Aussteuerung ist hingegen bei der falschen Zuordnung von Postleitzahl und Ort nötig, da nicht automatisch erkenn-bar ist, ob nun die Postleitzahl oder der Ort der eigentlich korrekte Wert ist. Bei den technischen Regeln wird es hingegen bei einer Verletzung zu einem Prozessabbruch kommen. Ein bedingter Abbruch kann dabei unterschiedlich formuliert sein, zum Bei-spiel dass ab einer bestimmten Anzahl regelwidriger Sätze pro aktueller Lieferung abgebrochen werden soll oder wenn im Vergleich zur vorherigen Datenlieferung sig-nifikant mehr Regelverstöße vorliegen. Dafür muss die Anzahl der Regelverstöße entsprechend protokolliert werden.

Für die Harmonisierung werden sogenannte Mapping-Tabellen verwendet, um die verschiedenen Schlüssel der Quellsysteme zu vereinheitlichen. [vgl. Kim04, S. 48]

Für jedes System gibt es eine Spalte in der Mapping-Tabelle sowie eine Übersetzung der Schlüsselausprägungen in das einheitliche Format. In der Tabelle 3-3 ist exemp-larisch eine Mapping-Tabelle für verschiedene Schlüssel des Geschlechts gegeben.

Mittels einem einfachen JOIN über die Spalte des Quellsystems kann nun der jeweils gültige einheitliche Schlüssel abgefragt werden. Als möglicher Fehler kann während der Harmonisierung daher das Nicht-Auffinden eines Schlüssels auftreten, etwa wenn der JOIN über eine falsche Spalte stattfindet oder aber die Schlüsselüberset-zungen für ein Quellsystem noch nicht eingetragen sind.

Einheitlicher Schlüssel Quellsystem 1 Quellsystem 2 Quellsystem ...

M m männlich ...

W f weiblich ...

Kapitel 3 - Testen während der Entwicklung

Tabelle 3-3: Mapping-Tabelle [Eigene Darstellung]

Der Aufbau der multidimensionalen Datenstruktur (Sternschema) geschieht in zwei Schritten: Zuerst werden die Dimensionstabellen erstellt, anschließend die Faktenta-bellen. Beim Erstellen der Dimensionstabellen ist zu beachten, wie Veränderungen innerhalb von Dimensionen behandelt werden sollen. Im einfachsten Fall ist eine Di-mension fix und ändert sich nicht, zum Beispiel besteht ein Jahr immer aus vier Quartalen, die Quartale jeweils aus drei Monaten. Bei der Produktdimension kann es jedoch passieren, dass sich die Produktgruppe eines Produktes ändert. Kimball et al.

[vgl. Kim04, S. 183ff] nennen diese Problematik Slowly Changing Dimensions (SCD) und geben dafür drei Lösungsszenarien vor: Der geänderte Wert in der Dimension wird überschrieben (Typ 1), der geänderte Wert wird als neuer Satz in die Dimensi-onstabelle aufgenommen und mit einem Zeitstempel versehen (Typ 2) oder für den geänderten Wert wird eine neue Spalte in die Dimensionstabelle eingefügt (Typ 3).

Es muss also geprüft werden, ob das Verfahren der sich ändernden Dimensionen korrekt angewendet wird. [vgl. Rai08, S. 481] In der folgenden Tabelle ist das Vorge-hen bei einer Typ 2 SCD für die Organigrammdimension exemplarisch angedeutet.

SurrogatKey ID Name Job GueltigVon GueltigBis 2132 11514 Max Mustermann Student 01.09.2003 31.08.2006 5929 11514 Max Mustermann Entwickler 01.09.2006 31.05.2011 9284 11514 Max Mustermann Manager 01.06.2011 31.12.9999

Tabelle 3-4: Typ 2 SCD [Eigene Darstellung]

3.3.1.2 Nichtfunktionale Besonderheiten der Datenintegration

Ein Datenintegrationsprozess muss in einem vorgegebenen Zeitfenster (z.B. nachts von 1 Uhr bis 3 Uhr) abschließen, weil ansonsten abhängige Folgeprozesse wie die Berechnung der OLAP-Würfel nicht rechtzeitig starten können. Somit ist auch das Überprüfen der Ausführungsgeschwindigkeit sehr wichtig. Hierbei muss auch analy-siert werden, wie der Integrationsprozess auf größere Datenmengen reagiert. [vgl.

Rai08, S. 482ff; The07, S. 3]

Kapitel 3 - Testen während der Entwicklung

Durch die Datenintegrationsprozesse werden die Informationen aus den verschiede-nen Quellsystemen zusammengespielt und aufbereitet. Aus Gründen der Revisions-sicherheit ist deshalb besonders auf die Benutzbarkeit in Form der Dokumentation zu achten. Gerade im Versicherungs- und Finanzsektor, wo besonders strenge Rege-lungen von Aufsichtsbehörden existieren, muss gewährleistet sein, dass bei einer Überprüfung der Datenintegrationsprozesse durch einen Wirtschaftsprüfer eine Do-kumentation der Prozesse vorgewiesen werden kann. Es muss für fachkundige Dritte belegt werden können, woher die Daten ursprünglich kommen und wie und warum sie in den Prozessen verarbeitet werden.