Funktionale Prüftechniken für die Datenintegration

Für das Testen der Spezialformate bietet sich die Äquivalenzklassenbildung an. Im oben genannten Beispiel der Versicherungsschäden als COBOL Copybook kann ein Datensatz entweder zu dem Versicherungsprodukt „Kraftfahrt“ oder „Privathaftpflicht“

gehören. Das hierfür ausschlaggebende Attribut „Versicherungsprodukt“ muss abge-fragt werden und daraus die entsprechend gültige Redefinition beim Einlesen ange-wendet werden. Die Unterscheidungsregel kann etwa lauten, dass die Versiche-rungsproduktausprägungen 100, 101 und 102 einen Privathaftpflichtschaden darstel-len und die Ausprägungen 200, 201 und 202 einen Kraftfahrtschaden. Somit ergeben sich dafür zwei Äquivalenzklassen. Gerade bei solchen Legacy-Dateien kann unter Umständen nicht garantiert werden, dass die Schlüsselausprägungen genau in den beiden genannten Wertebereichen liegen. Mögliche „Datenleichen“ können mit ande-ren Ausprägungen auftauchen und müssen folglich ausgesteuert werden. Für diese ungültigen bzw. unbekannten Datensätze ergibt sich eine dritte Äquivalenzklasse:

Produkt Äquivalenzklassen Repräsentant

Privathaftpflicht 𝑃 = {100,101,102} 101

Kraftfahrt 𝐾 = {200,201,202} 202

Unbekannt 𝑈 = ((𝑥 ∈ {0, … ,999}) ∧ (𝑥 ∉ (𝑃 ∪ 𝐾))) 303 Tabelle 3-5: Äquivalenzklassen für COBOL Copybook

[Eigene Darstellung]

Kapitel 3 - Testen während der Entwicklung

In der Abbildung 3-6 ist das Einlesen des Copybooks exemplarisch angedeutet (im-plementiert in dem Datenintegrationswerkzeug Talend¹⁹). Das Copybook (eine im EBCDIC-Format kodierte Datei) wird eingelesen und je nach Ausprägung der Spalte

„Versicherungsprodukt“ in eine Staging-Tabelle geschrieben. Die Unterscheidungs-regeln führen einfache Wertvergleiche durch und sind in Java-Syntax implementiert.

Unbekannte Datensätze werden in einer CSV-Datei protokolliert. Wenn der Job mit den drei Repräsentanten ausgeführt wird, muss jeweils ein Datensatz in den beiden Tabellen geschrieben worden sein und ein Datensatz in der CSV-Datei protokolliert worden sein.

Abbildung 3-6: Einlesen eines COBOL Copybooks (Talend) [Eigene Darstellung]

Für das Überprüfen der Datenqualitätsregeln können der Ursache-Wirkungs-Graph und Entscheidungstabellen herangezogen werden. Jede Regel entspricht dabei einer Ursache. Ob ein Datensatz übernommen oder verworfen wird sind die zwei mögli-chen Wirkungen. Werden bei den abgewiesenen Datensätzen Schwellwerte über-wacht oder Autokorrekturen angewendet, ergeben sich hierdurch zusätzliche Ursa-chen und Wirkungen.

19 Weitere Informationen unter http://www.talend.com (Abgerufen 01.01.2012)

Kapitel 3 - Testen während der Entwicklung

Die Regeln haben oftmals einen aufeinander aufbauenden Charakter. Gestartet wird mit den syntaktischen Qualitätsregeln, denn diese bilden den Grundstein dafür, dass ein Datensatz überhaupt weiterverarbeitet werden kann und harte Programmabbrü-che (etwa NULL-Pointer) während des Datenintegrationsprozesses ausgeschlossen werden. Darauf folgen die semantischen Regeln, die beispielsweise prüfen, ob er-laubte Wertebereiche eingehalten wurden. Nur wenn alle Regeln eingehalten wer-den, wird der Datensatz zur weiteren Verarbeitung übernommen. Andernfalls wird der Datensatz abgewiesen und protokolliert. Eine exemplarische Implementierung eines solchen Ablaufes sowie die Umsetzung der syntaktischen Schemaüberprüfung (Datentypen, Längen, NULL) ist in der Abbildung 3-7 dargestellt. Dabei wird bei der Überschreitung von Schwellwerten der gesamte Ablauf abgebrochen.

Abbildung 3-7: Datenqualitätsregeln (Talend) [Eigene Darstellung]

Für dieses Beispiel ergeben sich drei Wirkungen und vier Ursachen:

• Wirkungen

o W1 : ein Datensatz wird übernommen

Kapitel 3 - Testen während der Entwicklung

o W2 : ein Datensatz wird ausgesteuert o W3 : die Verarbeitung wird abgebrochen

• Ursachen

o U1 : ein Datensatz entspricht dem Schema o U2 : ein Datensatz entspricht dem Wertebereich o U3 : ein Datensatz entspricht der Regel „...“

o U4 : ein Schwellwert wird überschritten

Die Zusammenhänge der Ursachen und Wirkungen lauten wie folgt: Ein Datensatz wird genau dann übernommen (W1), wenn alle Regeln eingehalten wurden (U1 bis U3

erfüllt) und der Schwellwert nicht überschritten wurde (U4 nicht erfüllt). Ein Datensatz wird abgelehnt (W2), sobald eine Regel nicht eingehalten wurde (U1 oder U2 oder U3

nicht erfüllt). Der Prozessabbruch (W3) erfolgt, sobald der Schwellwert überschritten wurde (U4). Abbildung 3-8 zeigt einen entsprechenden Ursache-Wirkungs-Graphen und die Tabelle 3-6 die daraus abgeleitete Entscheidungstabelle mit insgesamt fünf Testfällen.

Abbildung 3-8: Ursache-Wirkungs-Graph - Qualitätsregeln [Eigene Darstellung]

Kapitel 3 - Testen während der Entwicklung

Tabelle 3-6: Entscheidungstabelle - Qualitätsregeln [Eigene Darstellung]

Die Überprüfung der Harmonisierung und der Übersetzung in das Sternschema (in-klusive SCD) als auch die Überprüfung der korrekten Aggregation können ebenfalls über Ursache-Wirkungs-Graphen und Entscheidungstabellen durchgeführt werden.

Die Ursachen bei der Harmonisierung und Dimensionsverarbeitung können sein, dass ein Schlüssel in der Mapping- bzw. Dimensionstabelle entweder gefunden wird oder nicht. Als Wirkungen ergibt sich dann das entsprechende Umsetzen des Schlüssels.

Für eine Typ 1 SCD gelten beispielsweise folgende Ursachen und Wirkungen:

• Ursachen

o U1 : zu einer ID existiert ein Eintrag in der Dimensionstabelle o U2 : ein Attribut zu einer ID hat sich geändert

• Wirkungen

o W1 : ein neuer Eintrag wird in der Dimensionstabelle eingefügt o W2 : bestehender Eintrag in der Dimensionstabelle wird aktualisiert o W3 : bestehender Eintrag in der Dimensionstabelle wird übernommen

Die Zusammenhänge lauten: Wenn zu einer ID noch kein Eintrag in der Dimensions-tabelle existiert (U1 nicht erfüllt), wird ein neuer Eintrag in die Dimensionstabelle ein-gefügt (W1). U1 ist erforderlich für U2, denn ein Attribut kann sich nur geändert haben, wenn es zu der ID bereits einen Eintrag gegeben hat. Bei einer Attributänderung (U2

Kapitel 3 - Testen während der Entwicklung

erfüllt) wird der Eintrag in der Dimensionstabelle aktualisiert (W2) bzw. wenn keine Änderung erfolgt (U2 nicht erfüllt), wird der bestehende Eintrag übernommen (W3). In der folgenden Abbildung ist der resultierende Ursache-Wirkungs-Graph gegeben. Die Tabelle 3-7 zeigt die Entscheidungstabelle mit drei Testfällen.

Abbildung 3-9: Ursache-Wirkungs-Graph - Typ 1 SCD [Eigene Darstellung]

Ursachen U1 Eintrag existiert bereits N J J U2 Attribut hat sich geändert - J N

Wirkungen

W1 Neuer Eintrag J N N

W2 Eintrag aktualisieren N J N

W3 Eintrag übernehmen N N J

T1 T2 T3

Tabelle 3-7: Entscheidungstabelle - Typ 1 SCD [Eigene Darstellung]

Die Struktur eines Datenintegrationsprozesses wie in Abbildung 3-7 stellt einen Kon-trollfluss dar. Die Orchestrierung der verschiedenen Funktionsbausteine ergibt die Knoten und Kanten des Kontrollflussgraphen. Durch die Verwendung eines grafi-schen Datenintegrationswerkzeuges wird der Kontrollflussgraph automatisch gene-riert bzw. die Implementierung geschieht kontrollflussorientiert. Somit kann der Da-tenintegrationsprozess auch kontrollflussorientiert überprüft werden. Der

Grundge-Kapitel 3 - Testen während der Entwicklung

danke bei dieser Prüftechnik ist die Bewertung der Abdeckung der Strukturelemente des Datenintegrationsprozesses durch Testfälle. Eine einfache Forderung an die Testfälle kann sein, dass jeder Funktionsbaustein bzw. Knoten mindestens einmal ausgeführt werden muss (Anweisungsüberdeckung). Für den Datenintegrationspro-zessausschnitt in Abbildung 3-7 wird unter dieser Betrachtung gefordert, dass die Komponenten „Lese EBCDIC-Datei“, „Schema Check“, „Wertebereich Check“,

„Schema Schwellwert“, „Wertebereich Schwellwert“, „Schema Protokoll“, „Wertebe-reich Protokoll“ und „Abbrechen“ alle mindestens einmal durch entsprechende Test-fälle zur Ausführung kommen. Dabei ist es egal, ob die Funktion „Abbrechen“ durch die Überschreitung des Schema- oder Wertebereichschwellwertes zustande kommt.

Erst mit der Forderung nach der Zweigüberdeckung (alle Kanten) werden auch tat-sächlich beide Fälle abgedeckt.

Abbildung 3-10: Datenflussgraph (Talend) [Eigene Darstellung]

Kapitel 3 - Testen während der Entwicklung

Wie es der Name bereits ausdrückt, verarbeitet der Datenintegrationsprozess Daten.

Attribute werden aus einer Quelle gelesen, verarbeitet und in ein Ziel geschrieben.

Somit bietet sich das datenflussorientierte Testen als weitere Prüftechnik an. Für das datenflussorientierte Testen muss der bestehende Kontrollflussgraph um die Zugriffe auf die Attribute erweitert werden. Wie sich die Attributzugriffe gestalten, ergibt sich aus der näheren Betrachtung der Funktionsweise eines Datenintegrationswerkzeu-ges. Am Beispiel von Talend soll dies hier verdeutlicht werden: Jeder Knoten bzw.

jeder Verarbeitungsschritt in einem Talend-Prozess besitzt sein eigenes Schema bzw. seine eigenen Attribute. Der Datenfluss ergibt sich, wenn die Attributwerte von einem Schema an das nächste Schema übergeben werden. In der Abbildung 3-10 wird dieses Vorgehen veranschaulicht. Die linke Spalte zeigt den Prozess als Über-sicht. Die von einem Knoten ausgehenden Kanten sind mit dem jeweiligen Sche-manamen beschrieben. Der erste Verarbeitungsschritt liest aus einer Tabelle mittels SELECT * FROM zeilenweise alle Attribute (ID, Vorname, Nachname, Telefonnum-mer, Umsatz) und weist die einzelnen Werte den Attributen des ersten Schemas „s1“

zu. Das gesamte Schema „s1“ besteht aus den Attributen:

• „s1_ID“

• „s1_Vorname“

• „s1_Nachname“

• „s1_Telefonnummer“

• „s1_Umsatz“

Im zweiten Schritt werden in dem Schema „s2“ die ID und der Umsatz aus „s1“ über-nommen und der Vor- und Nachname einfach als Name konkateniert. Die Telefon-nummer wird nicht übernommen. Das Schema „s2“ hat sich im Vergleich zu „s1“ ge-ändert und besteht lediglich aus den drei Attributen:

• „s2_ID“

• „s2_Name“

• „s2_Umsatz“

Im dritten Schritt findet anhand des Umsatzes aus „s2“ eine Entscheidung statt (Um-satz größer 10.000). Der Datenfluss wird in die zwei Schemata „s3“ und „s4“ aufge-teilt (entsprechend mit den Attributen „s3_ID“, „s4_ID“ etc.) und für die weitere Verar-beitung bereitgestellt. Die mittlere Spalte der Abbildung zeigt die entsprechenden Variablenzugriffe (def, c-use, p-use) des Datenflusses je Schema. Es ist zu

erken-Kapitel 3 - Testen während der Entwicklung

nen, wie bei jedem Knoten eine Variable x mittels def(x) und c-use(x) von Schema zu Schema übertragen wird. Für die Entscheidung anhand des Umsatzes wird auf die Variable „s2_Umsatz“ über p-use zugegriffen.

In der rechten Spalte ist zur Verdeutlichung der Vorgehensweise der für den Prozess zugrundeliegende Talend-Quellcode²⁰ in vereinfachter Form dargestellt. Für die Durchführung des datenflussorientierten Tests wird der Quellcode jedoch nicht benö-tigt.

Abbildung 3-11: Datenflussanomalieanalyse (Talend) [Eigene Darstellung]

Auf Basis des Datenflussgraphen kann zusätzlich eine Anomalieanalyse durchge-führt werden. Von Interesse ist hierbei vor allem das Aufdecken von du-Anomalien.

Eine solche Anomalie ist die Definition einer Variablen, ohne dass sie verwendet wird. Sie tritt etwa auf, wenn der Datenintegrationsprozess beim Einlesen von Daten

20 Talend verwendet für seine Funktionalitäten im Hintergrund Java. Da das System offen ist, kann der Quellcode eingesehen werden.

Kapitel 3 - Testen während der Entwicklung

aus einer Tabelle alle Spalten selektiert, für die tatsächliche Verarbeitung aber nicht alle Attribute relevant sind. Die Vermeidung der du-Anomalie kann die zu verarbei-tende Datenmenge gravierend verringern und dadurch deutlich zur Steigerung der Verarbeitungsgeschwindigkeit beitragen. In der Abbildung 3-11 wurde der Datenin-tegrationsprozess und der vereinfachte Quellcode aus Abbildung 3-10 mit den für die Anomalieanalyse benötigten Zugriffsarten für Variablen angepasst. Hier wird die du-Anomalie bei dem Attribut der Telefonnummer ersichtlich: Das Attribut s1_TELEFON wird im ersten Verarbeitungsschritt definiert und in keinem der weiteren Schritte refe-renziert. Beim Verlassen des Prozesses wird das Attribut wieder undefiniert. Da die Telefonnummer keine Rolle für den Prozess spielt, kann sie in dem SELECT -Statement ausgeschlossen werden.

Das Slicing als statische Fehleranalyse wird von vielen Datenintegrationswerkzeugen unterstützt. Als Slicing-Instrumente bieten sie die Impact Analyse sowie die Data Li-neage Analyse an. Beide Analysen dienen der Aufdeckung, wo und wie die einzel-nen Attribute in den Integrationsprozessen verarbeitet werden. Der Unterschied ist dabei der Standpunkt der Betrachtung: Die Impact Analyse ist anterograd und die Data Lineage Analyse retrograd. Das bedeutet, dass mittels Impact Analyse zu ei-nem Attribut ermittelt werden kann, in welchen nachfolgenden Prozessschritten die-ses Attribut verwendet wird. Bei der Data Lineage Analyse kann umgekehrt aufge-deckt werden, welche vorgelagerten Prozessschritte an der Ausprägung eines Attri-butes partizipieren. Beide Methoden eigenen sich gleichermaßen, um einen Über-blick erlangen zu können, wie die einzelnen Attribute aufeinander einwirken. In der nachfolgenden Abbildung ist eine Impact Analyse in Talend dargestellt. Die Analyse wurde für das Attribut „Versicherungsscheinnummer“ (VSNR) durchgeführt. Die ret-rograde Perspektive startet mit dem Schreiben (Write) in eine Tabelle. Seinen Ur-sprung hat das Attribut in einer anderen Tabelle (Read). Von zwei weiteren Prozess-schritten wurde die VSNR verwendet (Set). Für die Art der Attributverwendung wird hierbei keine Unterscheidung vorgenommen, ob es ein Zugriff für eine Berechnung (c-use) oder Entscheidung (p-use) ist.

Kapitel 3 - Testen während der Entwicklung

Abbildung 3-12: Data Lineage Analyse (Talend) [Eigene Darstellung]

Aufgrund der hohen Komplexität der Datenintegrationsprozesse empfiehlt es sich, auch eine Stilanalyse sowie Reviews durchzuführen. Ausschlaggebende Punkte für die Stilanalyse sind dabei, dass die einzelnen Knoten und Kanten in den Prozessen verständlich benannt sind und mögliche Konventionen eingehalten wurden. Der kon-trollierende Blick eines zweiten, unabhängigen Entwicklers kann gerade bei den komplizierten Mechanismen der Dimensionserstellung (z.B. Typ 2 SCD) helfen.

Im Dokument Hochschule Wismar (Seite 60-70)