Showstopper 1: Vervuilde gegevens
Auteur: Rick F. van der Lans
Geschreven: april 2001
Gepubliceerd in: BI Quarterly, jaargang
3, nummer 2

Er is veel software beschikbaar om een datawarehouse-omgeving op te tuigen. Maar deze omgeving blijft altijd een garbage-in garbage-out systeem hoeveel we ook in dure ETL-tools, prachtige OLAP-tools, en super snelle databaseservers investeren. Indien onze gegevens niet 'schoon' genoeg zijn, kunnen we het datawarehouseproject wel in de ijskast zetten.
Ik pleit er altijd voor dat reeds aan het begin van een datawarehouseproject geďnventariseerd wordt wat de kwaliteit van de brongegevens is. Nog voordat we software gaan aanschaffen - dus voordat we zware investeringen gaan doen - dienen we de mate van gegevensvervuiling in kaart gebracht te hebben. Te veel vervuilde gegevens zijn, zoals de Amerikanen zo mooi zeggen, een showstopper.
De drie cruciale vragen hierbij zijn:
1. hoe detecteer je vervuilde gegevens
2. hoe bepaal je dan wat de correcte gegevens zouden moeten zijn
3. čn hoe corrigeer je ze?
Voor het detecteren van vervuilde gegevens bestaan enkele producten. Er zijn er die bijvoorbeeld adresgegevens analyseren en kijken of alle voorkomende waarden bestaan. Maar dit werkt alleen als deze producten een lijst met correcte adresgegevens tot hun beschikking hebben. Een andere manier is door gegevens te visualiseren. Door naar de patronen te kijken, kan een analist mogelijk afwijkende of vreemde patronen ontdekken. Een derde mogelijkheid is dat iemand met kennis van de gegevens en de materie door de records met gegevens bladert en simpelweg elk gegeven bestudeert (een activiteit die doet denken aan het hertellen van de stembiljetten in Florida vorig jaar). Maar welke aanpak u ook kiest, dat zal een tijdrovende activiteit zijn.
Maar ondanks alle producten en mogelijkheden zullen we zeker niet alle vervuilde gegevens vinden. En stel dat we een fout vinden, wat had dan de correcte waarde moeten zijn? Een geboortedatum van 1813 voor een huidige werknemer is een ongeloofwaardige waarde, maar wat moet die waarde dan wel zijn? Enkele bedrijven hebben dit probleem opgelost door een afdeling te starten waarin werknemers niets anders doen dan de correcte gegevens te zoeken. Dit doen ze bijvoorbeeld door klanten en zakelijke partners te bellen, papieren rapporten te bestuderen en de gegevens te vergelijken met lijsten correcte gegevens. Ook dit is een zeer arbeidsintensieve activiteit.
En trouwens, hoe en waar corrigeren we? Soms wordt voorgesteld om de gegevens in de bronsystemen (de productiedatabases) te corrigeren. Uiteraard is dit geen slecht idee, maar het is wel dweilen met de kraan open, want vervuilde gegevens blijven binnenkomen. Een veelgekozen aanpak behelst controle van de gegevens op het moment dat ze het datawarehouse binnenkomen. Echter, rapporten die gedraaid worden op de bronsystemen zijn dan niet consistent met de rapporten die we op het datawarehouse draaien. Dit kan organisatorisch originele effecten geven!
Wat we zeker moeten doen is de oorzaak oplossen. Hoe komt het dat vervuilde gegevens ingevoerd kunnen worden? De reden is dat de dataentry-applicatie niet waterdicht is en het voor de gebruikers te makkelijk maakt vervuilde gegevens in te voeren. Ik denk dat we iedereen die betrokken is bij het ontwerpen en bouwen van productiesystemen heel duidelijk moeten maken hoe vervuild sommige bronsystemen zijn en dat we daar bij de ontwikkeling van nieuwe bronsystemen echt iets aan moeten gaan doen.
Kortom, het detecteren van vervuilde gegevens, het vinden van de correcte gegevens en vervolgens het corrigeren van de gegevens is een complexe en tijdrovende bezigheid. Wel komen er steeds meer producten op de markt die ons hierbij kunnen assisteren, zoals die van Human Inference, Trillium en Vality, maar ook die kunnen dit werk niet volautomatisch uitvoeren. Ongeacht de beschikbaarheid van deze producten kunnen we ons datawarehouseproject gerust in de ijskast plaatsen, als we het probleem van de gegevensvervuiling niet gedegen oplossen. Laten we daarom aan het begin van elk datawarehouseproject eerst analyseren hoe groot dit probleem is, voordat we er geld aan uitgeven.