API Management 8 Minuten

Warum Du keine veralteten (verrotteten) Datensätze verwenden solltest

Würdest Du in einen verfaulten Apfel beißen? Wahrscheinlich nicht.

Rob Blaauboer
Integration Consultant & WSO2 Trainer
Blog - Outdated data
Scrollen

Es ist schon ein unangenehmes Erlebnis, in einen süß aussehenden Apfel zu beißen, um ihn dann wieder auszuspucken, nachdem du festgestellt hast, dass der Apfel von innen verrottet ist. Deine Erwartung eines leckeren Apfels ist zerstört. So etwas würdest Du wahrscheinlich gerne vermeiden. Dieser Blog handelt jedoch nicht von Äpfeln oder Lebensmitteln. Dieser Blog handelt von anderen Dingen, die mit der Zeit anfangen können zu verrotten, ohne dass Du es merkst. In diesem Blog geht es um verrottende Daten.

Würdest Du bezogen auf das obige Bild, solche Daten verwenden? Die Antwort ist nicht so eindeutig wie bei dem Apfel. Die Frage, die Du Dir stellen musst, ist jedoch die gleiche wie beim Apfel: Wie alt ist er? Wenn man die Antwort auf diese Frage nicht kennt, sollten die Daten nicht mehr verwendet werden. Denn Daten können verrotten, genau wie ein Apfel. 

Was bedeutet verrotten (Daten)? 

Wenn Du es aus einer natürlichen Perspektive betrachtest, dann bedeutet es, dass ein Objekt, z.B. ein Apfel, verfault, was ihn für den Verzehr ungeeignet macht. Der Grund für den Fäulnisprozess ist, dass ein Apfel aus organischem Material besteht. Die Verwesung von organischem Material wird durch die Luftzirkulation, Temperatur, Feuchtigkeit und chemische Zusammensetzung beeinflusst. Andere Materialien verrotten auch, aber nicht durch Bakterien, sondern durch Oxidation. Als Beispiel nehmen wir Eisenoberflächen. Eisen reagiert auf den Sauerstoff in der Luft, was zu Rost führt. Dadurch wird das Material schwächer und es verrottet schließlich ganz. Von daher ist Verrotten in Verbindung mit Daten eine etwas falsche Bezeichnung. Ich benutze es trotzdem, denn es sendet eine klare Botschaft: Daten können veraltet sein und sollten daher nicht mehr verwendet werden. 

Was sind Beispiele für veraltete (verrottete) Daten?

Du denkst vielleicht, dass die Daten nicht verrotten können, wenn sie einmal in ein System eingegeben wurden. Und tatsächlich gibt es keinen physischen Verfall, denn die Daten bleiben unverändert und in einigen Fällen sogar relevant. Einige Daten sind sogar für immer gültig, zum Beispiel Dein Geburtsort und Dein Geburtsdatum. Ein weiteres Beispiel: Wenn Du eine Datenbank mit runden Esszimmertischen hast, bleiben der Durchmesser, der Radius und die Fläche (A = π × r2) für jeden Tisch immer gleich. Aber nicht alle Daten sind so beständig und einige Daten können sich ändern. Einige Daten können in ihrer Gültigkeit variieren und daher verrotten, wie z.B. die Anzahl der Tische, die auf Lager sind, oder der Preis eines Tisches. 

Ich benutze das Wort „verrotten“, denn niemand, der bei klarem Verstand ist, wird einen verrottenden Apfel essen. Du solltest meiner Meinung nach auch keine verrottenden Daten verwenden.

Variable Kundendaten

Wenn du Kundendaten wie Namen, Adressen etc. sammelst, können sich diese Daten ändern. Menschen ziehen um. Kunden verlassen uns. Menschen sterben. Die Liste der tausend Kunden wird möglicherweise weniger verlässlich.

Zeitgebundene Daten können von dem Moment an, in dem sie gespeichert werden, verrotten. 

Datenverfall hat also mit bestimmten Arten von Daten zu tun, die aus einer Vielzahl von Gründen veraltet sein können. Doch die Art, wie Daten verrotten, unterscheidet sich von der Art, wie ein Apfel verrottet. Die Zeit ist einer der wichtigsten Faktoren. Daten können bereits ab dem Moment, in dem sie gespeichert werden, anfangen zu verrotten.

Arbeiten mit veralteten Daten

Nehmen wir an, dass du ein Unternehmen mit 1.000 Kunden in deiner Datenbank hast. Für Marketingzwecke macht dein Marketingassistent einen Export deiner Kundendatenbank, um Kunden mit personalisierten Mailings über neue Produkte, Einblicke, etc. anzusprechen. Der Export und der Import der persönlichen Daten in das CRM-System ist eine Menge Arbeit, daher aktualisiert dein Marketingassistent diesen Export nicht regelmäßig. Inwieweit wird der ursprüngliche Export dieser abstrakten 1.000-Kunden-Datenbank, der gemacht wurde, nach sechs Monaten noch gültig sein? Werdet ihr nach sechs Monaten die gleichen 1.000 Kunden haben, oder werdet ihr mehr, oder weniger haben? Falls du mehr hast. Dann verpasst du Chancen. Wenn du weniger hast, zielst du auf Leute, die nicht mehr deine Kunden sind. Falls du andere Kunden hast, z.B. du hast immer noch 1.000 Kunden, aber 20% davon sind neue Kunden, dann wiederum triffst du nicht ins Schwarze. 

Wie kannst du verhindern, das deine Daten veraltet sind?

Es gibt viele weitere Beispiele für Daten, die das Potenzial haben zu verrotten. Ich schlage vor, dass du dir alle deine Daten ansiehst, um zu sehen, ob sie potentiell anfangen zu faulen. Umso mehr ein organisches Produkt der Luft ausgesetzt ist und je wärmer die Temperatur ist, desto schneller findet der Verrottungsprozess statt. Was sind denn die Verrottungskriterien für deine Daten? Was lässt deine Daten viel schneller verrotten, als du gedacht hast? Und was kannst du dagegen tun?  

Richtig lagern und nutzen

Eine einfache Möglichkeit, Milch länger frisch zu halten, ist, sie in einen Kühlschrank zu stellen. Natürlich sind Daten kein organisches Produkt. Daten sind etwas, das du auf dem neuesten Stand halten musst, damit du sie zuverlässig nutzen kannst. Du musst sie aber auch auf die richtige Art und Weise lagern und nutzen! Damit meine ich, dass du deine Daten überprüfen musst, um herauszufinden, ob sie noch korrekt sind, aber du musst auch darauf achten, ob sie (noch) zu dem Zweck passen, für den du sie verwendest. Das Alter von jemandem als 42 Jahre zu speichern, macht keinen Sinn und ist zwangsläufig veraltet, außer du würdest auch das Datum der Beobachtung aufzeichnen. Speichert man jedoch stattdessen das Geburtsdatum einer Person, kann das Alter abgeleitet werden und das hält deine Daten frisch und verhindert, dass sie verrotten.

Ein einheitliches Modell?

Wenn Daten an verschiedenen Orten und in verschiedenen Formen gespeichert werden, werden die Dinge noch komplexer. Es gibt nicht das eine große Datenmodell, das deine Daten für alle verbindenden Umgebungen frisch gespeichert hält. Und das ist auch gut so, denn die Komplexität eines vereinheitlichenden Modells, das alle Daten auf eine brauchbare Art und Weise verbindet, ist, was mich betrifft, teils heiliger Gral teils Fata Morgana. In anderen Worten, es wäre wunderbar, wenn wir es hätten, aber es ist wirklich nicht machbar aus der Perspektive der Kosten und der Komplexität. Auch aus der Perspektive der Einheitlichkeit der Daten und ihrer Bedeutung, denn Menschen können die gleichen Daten betrachten und sie auf unterschiedliche Weise wahrnehmen. Nehmen wir zum Beispiel ein Bankkonto. Es ist möglich, ein Girokonto zu überziehen (eine Möglichkeit, Geld für Banken zu verdienen), aber nicht ein Sparkonto.

Der Wert historischer Daten

Veraltete Daten müssen nicht zwangsläufig verrottet sein. Die historischen Daten können analysiert werden und ergeben bestimmte Muster, die erkannt werden können. Als Beispiel sei der saisonale Einfluss auf den Umsatz genannt. Die Daten von gestern müssen nicht unbedingt viel über heute aussagen, aber sie sagen vielleicht etwas über den gleichen Tag in der nächsten Woche aus. Alte Daten sind nicht unbedingt wertlos, aber eben auch nicht ihr Gewicht in Gold wert. Du musst pro Situation das Potenzial der Daten bestimmen und mit neuen Daten validieren. 

Unvollständige Daten bedeuten verpasste Chancen

Ein Kunde kann sich als Single registrieren, wenn er etwas in deinem Webshop bestellt, aber woher weißt du mit Sicherheit, dass er oder sie noch Single ist? Du kannst vielleicht aus den Bestellungen, die sie getätigt haben, darauf schließen, aber das ist keine zuverlässige Methode. Das kann zu fehlenden Daten führen und das kann sich in möglichen verpassten Chancen niederschlagen.

Deine Daten verwalten

Deine Daten immer aktuell zu halten, beginnt mit der Art und Weise, wie du sie speicherst. Ein wohl durchdachtes Datenmodell stellt sicher, dass es keine Datenredundanz bei der Speicherung gibt, dass es ein abgestimmtes Entity-Relationship-Diagramm oder Domain-Modell gibt und dass die verwendeten Tabellen und Felder die Daten tatsächlich speichern können. Das erscheint logisch, aber es gibt Situationen, in denen dieselben Daten unterschiedliche Formen des Layouts annehmen können, zum Beispiel US-amerikanische vs. europäische Daten. Aber auch die Kundenadressen und Postleitzahlen können sich zwischen den Ländern unterscheiden.

Wer verwaltet die Daten?

Bist du die Hauptquelle der gespeicherten Daten, oder kommen die Daten von einer anderen Organisation? Falls eine andere Organisation die Quelle ist, kann sie dir in regelmäßigen Abständen Updates zur Verfügung stellen? Es ist wichtig, dass du sicherstellst, dass deine gespeicherten Daten auf dem neuesten Stand sind. Kannst du eine API nutzen, um die Daten zu aktualisieren?

Eine Möglichkeit ist, dass Kunden ihre eigenen Kundendaten aktualisieren können. Du solltest ihnen das leicht machen, indem du alle erdenklichen Hilfen einbaust, z.B. Dropdown-Listen für Städte etc. 

Eine Validierung wie z.B. die PostNL API, die hilft, Adressdaten zu überprüfen, trägt sicherlich dazu bei, die Daten aktuell und korrekt zu halten.

Die Unsicherheit wächst, wenn die Daten altern 

Und schließlich: Halte sie frisch. Arbeite nicht lange mit Extrakten, sondern extrahiere jedes Mal, wenn Daten benötigt werden oder stelle eine Schnittstelle zu diesen Daten bereit. Diese Schnittstellen können APIs sein, aber auch Graph QL Schemas und so weiter. Du kannst sogar mit Algorithmen arbeiten, um die Daten zu analysieren, aber sei vorsichtig mit den Datenschutzregeln. Eine Einwilligung ist in der heutigen Zeit immer eine gute Idee. Suche nach professioneller Unterstützung, wenn nötig. 

Das wichtigste Takeaway lässt sich vielleicht an einem Beispiel verdeutlichen: Wenn ich einen Apfel esse, schaue ich ihn mir immer erst an, bevor ich hineinbeiße. Das Gleiche gilt für die Arbeit mit Daten, schau sie dir an, bevor du sie dir vornimmst.

Danke an Prof. Dr. Martin Kersten (CWI) für die ursprüngliche Idee zum Thema Datenfäule.