Datenqualität: Interessenkonflikte

Datenqualität: Interessenkonflikte

Zusammenfassung:

Ob auf eine XML-Schema-Validation des XML Inputs verzichtet werden kann, hängt davon ab, daß sich die Dokumentstruktur der Input-Daten (einschließlich Namespaces) nicht ändert. Das ist aber keineswegs sichergestellt.

Idealerweise stellen Datenlieferanten laufend aktualisierte Informationen zur Verfügung. Daten-Consumer verarbeiten die bereitgestellten XML Dokumente mit Hilfe von mehr oder weniger komplexen Verarbeitungslogiken. Ein solide definiertes XML Schema (Elemente, Attribute, Namespaces, Typen) dient beiden Seiten als Arbeitsbasis. So weit die Theorie.

In der Praxis kann es vorkommen, daß die Interessenlage beider Seiten hinsichtlich der Qualität der bereitgestellten Daten (wie auch des XML Schema) unterschiedlich ist. Nicht immer findet eine gegenseitige Abstimmung statt. Welche Konsequenzen kann das haben?

Grundsätzlich gibt es folgende Szenarios:

Die Interessenlage des Datenlieferanten

Ein gängiges Rollenverständnis mancher Datenlieferanten basiert auf dem Argument: "Wir stellen Daten bereit. Was die Anwender damit machen, steht nicht unter unserer Kontrolle." Das mag zutreffen, sollte aber kein Grund sein, mit den Anwendern über deren Bedarfe nicht kommunizieren zu müssen.

Gleichwohl können Datenlieferanten im Regelfall keineswegs souverän und eigenmächtig entscheiden, welche Informationen sie den Empfängern gnadenhalber zukommen lassen wollen. Sie sind ihrerseits abhängig nicht nur vom internen Kostendruck, sondern unter anderem auch von gesetzlichen Regelungen, Management- und Empfängerwünschen sowie deren häufig wechselnden Anforderungen.

Der Lieferant kann die Verpflichtung zu hoher Datenqualität als Belastung empfinden. Ihre Einhaltung zieht zusätzlichen Aufwand nach sich, der sogar ganz erheblich sein kann, kostet also Geld. Ist der Consumer nicht bereit, das zu honorieren, bleibt der Lieferant auf den Kosten sitzen.

In diesem Fall liegt das Interesse des Lieferanten in einer möglichst allgemeinen Definition des XML Schema, die die Anforderungen an die Datenqualität flach hält, sowie an einer Datenstruktur, die sich an möglichst breite Abnehmerkreise richtet.

Definiert der Datenlieferant das XML Schema, ohne die Datenempfänger ausreichend in die Strukturdefinition einzubinden, dann ist es möglich,

Änderungen der XML-Input-Dokumentstruktur

Es kommt gar nicht selten vor, daß eine Änderung der XML Dokumentstruktur unvermeidlich ist. Komplexe Systeme leben nun einmal, Änderungen müssen möglich sein.

Jede Änderung der definierten Datenstruktur erfordert eine entsprechende Anpassung sämtlicher Verarbeitungslogiken, die von dieser Änderung betroffen sind, und zwar auf beiden Seiten: der Datenlieferant muß seine Prozesse anpassen, um die geänderten Daten-Strukturen zu generieren. Jeder Daten Consumer muss seine Programmlogiken zur Verarbeitung des geänderten Inputs ebenso anpassen.

Kleine Ursache: große Wirkung. Eine scheinbar geringfügige Änderung des XML Schema kann überproportional hohe Anpassungen in der Programmlogik auf beiden Seiten nach sich ziehen. Daher ist es sinnvoll, die Notwendigkeit von Änderungen sorgfältig abzuwägen.

Nicht jeder Developer, der das XSD betreut und es schick findet, "mal eben" ein Feld, das bisher klein geschrieben wurde (<xs:element name="lastname"/>), nun plötzlich groß zu schreiben (<xs:element name="Lastname"/>), ist sich bewußt, daß der Datenempfänger anschließend die XPath-Pfade von zwanzig oder fünfzig XSL-Logiken anpassen muß, um die Feldadressierung zu aktualisieren und Informationsverlust zu vermeiden. (Vom Testaufwand gar nicht zu reden.)

Schwierig wird es, wenn jene Seite, die die XSD's ändert (z.B. Datenlieferant), die jeweils andere Seite (hier: Data Consumer) über die Änderungen nicht rechtzeitig informiert. Dann können die Anpassungen nicht rechtzeitig erfolgen, besonders wenn Daten-Consumer auf die Input-Validierung verzichten und stunden-, tage- oder wochenlang nicht bemerken, daß wichtige Informationen fehlen. Das kann teuer werden: die Folgekosten aufgrund entgangener Umsätze, Konventional- oder anderer Strafen können erheblich bis ruinös sein.

Dabei ist es möglich, daß lediglich die Namespaces (die oft Versionsänderungen dokumentieren) betroffen sind, die Adressierbarkeit der Felder jedoch unverändert bleibt. In anderen Fällen ist zusätzlich die Dokumentstruktur betroffen. Sind lediglich die Namespaces betroffen, so ist die Versuchung groß, die Programmlogik von der engen Bindung an die Namespaces zu entkoppeln und eine namespace-unabhängige Programmierung zu verfolgen.

In diesen Fällen ist es möglich, auf die vorgeschaltete XSD-Validierung völlig zu verzichten und statt dessen eine angepasste XML Schema-Validierung in XSLT 2.0 vorzunehmen, die sich lediglich auf die tatsächich verwendeten Felder bezieht, verbunden mit einer individuellen Fehlerbehandlungsroutine, die Namespace-Änderungen als Warnmeldungen reportet.

Die Interessenlage des Datenempfängers

In der Praxis erhalten Datenempfänger häufig irrelevante Informationen, für die sie keine Verwendung haben. Das liegt nicht zuletzt daran, daß die versendeten Daten sich an einen breiten Empfängerkreis wenden.

Andererseits sind dieselben Daten oft unvollständig, so daß der Empfänger darin nicht alles finden kann, was er für seine Zwecke braucht. Das erfordert zusätzlichen Programmieraufwand, oft auch eigene Datenhaltung.

Beides ist meist dann der Fall, wenn das XML Schema ohne gegenseitige Abstimmung durch den Lieferanten definiert wird und dem Consumer nichts anderes übrig bleibt, als willig zu folgen.

pic/XML_Datenaustausch_verwendbareDaten.jpg

Eine Kernfrage ist hier, was der Empfänger mit den Daten machen möchte und welchen Qualitätslevel er anstrebt. Stellt die Folgeprogrammierung nur geringe Anforderungen (z.B. es wird nur gemappt, was gerade verfügbar ist; es wird nicht kalkuliert; ein möglicher Informationsverlust fällt nicht ins Gewicht) dürfte es kaum lohnen, hochpräzise XML Schema - Validierungen zu bemühen.

Sind die Qualitäts-Anforderungen der gesamten Konvertierungsstrecke jedoch sehr hoch, sieht das anders aus. Das gilt auch und insbesondere, wenn die Qualität der empfangenen Daten deutlich niedriger liegt als die Anforderungen der Folgeprogrammierung.

Hat der Consumer Interesse an einer hohen Datenqualität, so bleibt ihm nur, diese beim Lieferanten einzufordern (heißt auch: entsprechend zu honorieren) oder eigene Anstrengungen zu unternehmen, die Qualitätsmängel der gelieferten Informationen zu beheben. Diese eigenen Anstrengungen können erheblich sein.

Betrachten wir die Datenvalidierung von XML Dokumenten mit Hilfe von XML Schema als Zwischenschritt in einer Konvertierungsstrecke, die der Datenempfänger konstruiert. Dieser Zwischenschritt stellt sicher, daß jene Annahmen und Voraussetzungen, auf denen der Developer seine Programmierung des XML Inputs aufbaut, auch zutreffen.

Die präzise Adressierung der Datenfelder mittels XPath setzt korrekte Namespaces, Element- und Attributnamen, Datentypen sowie eine verbindlich definierte Dokumentstruktur zwingend voraus, um Informationsverlust zu vermeiden und den Zusatzaufwand bei der Folgekonvertierung zu minimieren. Daher ist das Interesse des Consumers an einer hohen Qualität der eingehenden Daten groß.

Sehr attraktiv für den Daten-Consumer ist daher das Szenario, das XML Schema eigenständig definieren zu können, und sämtliche Datenlieferanten müssen diesen Vorgaben folgen. Eine Abstimmung findet nicht statt.

Die Anforderungen und die Datenqualität präzise festlegen zu können, ohne sich mit irrelevanten Informationen belasten zu müssen, ist vorteilhaft für den Empfänger, da er am besten weiß (wissen sollte), welche Daten, deren strukturellen Aufbau und Typen er zur Weiterverarbeitung benötigt.

Für die Lieferanten bedeutet dieses Szenario meist Zusatzaufwand. Sie müssen Konvertierungsstrecken unterhalten, um die individuellen Anforderungen der Empfänger zu bedienen.

Ein XML Schema - oder mehrere?

Welchen Vorteil hat es für den Datenempfänger, ein fragwürdiges XML Schema des Lieferanten als Arbeitsbasis zu übernehmen?

Zumal wenn die bereit gestellte Datenqualität derart zu wünschen übrig läßt, daß eine allgemeine Datenvalidierung nicht möglich ist, weil sie allzu oft auf den Fehler laufen, die folgende Transformation nicht stattfinden und insgesamt Informationsverlust verursachen würde?

Was aber sonst? Gar nicht validieren? Auch keine Lösung! Die Gefahr, daß der reale Input so weit von den Voraussetzungen der Programmierlogik abweicht und daher anderweit Informationsverlust verursacht, ist zu groß.

Die Lösung: ein zweites XML Schema muß her! Und zwar nicht zur Abstimmung mit dem Lieferanten, sondern verarbeitungsbezogen. Eines, das die Voraussetzungen der Programmierlogik zuverlässig abbildet, Abweichungen sofort reportet, irrelevante Datenfelder jedoch konsequent ignoriert. Auf diese Weise können unangemeldete Minor und major changes automatisiert gemeldet werden.

Ein zusätzliches XML Schema ist spätestens dann sinnvoll, wenn mehrere Folgetransformationen auf denselben Annahmen und Voraussetzungen beruhen, die vom XML Schema des Lieferanten nicht abgedeckt werden. Jede in der Programmierlogik nicht überprüfte Annahme und Voraussetzung führt mit hoher Wahrscheinlichkeit zu Fehlern und Informationsverlust. Es ist wirtschaftlicher, diese Voraussetzungen einmal(!) durch eine vorherige XML Schema - Validierung zu prüfen, anstatt die Prüfungen in zahlreichen Transformationen immer wieder erneut durchzuführen.

wg / 15. Dezember 2017



Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf:

Vorname
Nachname
Mailadresse







Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

Mobil: 0151. 750 360 61 * eMail: info2018@wilfried-grupe.de

www.wilfried-grupe.de/XSD2_3.html