Single Source of Truth (SSoT, DWH)

Single Source of Truth (SSoT) heeft betrekking op de vraag welke data in een datwarehouse (dwh) authentiek is.

Traduttore, traditore

In een dwh ontstaat al snel een enorme hoeveelheid data. In mijn ervaring komt die data uit twee bronnen:

Import
Intern gegenereerde data - En dit is al snel véél meer data dan wat er geïmporteerd wordt. Net onze hersenen: We zijn veel beter in het intern genereren van informatie, dan dat we via onze zintuigen ontvangen.

Elke keer dat data wordt verwerkt, is er een kans dat informatie verloren gaat, of verminkt raakt. Kwestie van toenemende entropie. Dat speelt op een elementair niveau.

Voorbeelden

De betekenis van een entiteit (bv. de naam van een kolom) is open voor verschillende interpretaties
Data uit 'gevestigde' bronnen, zoals Channable of Exact zijn ambivalent omdat gebruikers eigen velden hebben gedefineerd waarvan ze zelf ook niet meer goed weten wat het precies betekent, of omdat ze de betekenis van vaste kolommen anders interpreteren dan dat de makers van Channable of Exact het bedoeld hebben
Data is geaggregeerd (bv. omzetcijfers inclusief niet nader gespecificeerde transportkosten)
Vergelijkbare data uit verschillende bronnen is niet 100% hetzelfde (bv. financiële resultaten Bol.com en Amazon), meestal vanwege aggregatie
Verschil in aantal significante cijfers: Prima te voorkomen, maar alleen als je goed oplet - Bv. bij import van percentages vanuit Excel
Vertaalproblemen: Van een klant kreeg ik een deel van de omschrijvingen in het Frans, en een deel in het Spaans, terwijl ik het in het Engels en Duits nodig heb
Soms is data te ingewikkeld of te ongestructureerd om 100% accuraat te verwerken binnen een gestelde planning. Dan worden er bv. vereenvoudigingen toegepast
Waar gewerkt wordt, worden fouten gemaakt. Kwestie van statistiek: Op een gegeven moment onstaan er fouten
Voortschrijdend inzicht: Sommige van mijn projecten lopen al een paar jaar, waarbij ik oa. data gebruik die ik al vanaf het begin heb. Ik vraag me regelmatig af wat er zou veranderen als ik die data opnieuw vanaf scratch zou genereren.
In sommige tabellen heb ik een veld ingevoegd om de betrouwbaarheid van records aan te geven. Het enige lastige: Ik kan daar geen absolute schaal voor verzinnen, en zelfs een kwalitatieve aanduiding zoals redelijk, is tricky. Wat ik bv. vijf jaar geleden aanduidde als redelijk, is nu waarschijnlijk al snel onbetrouwbaar.

Maar waarom is dat een probleem?

Goede vraag: Waarom is het een probleem als data niet altijd even betrouwbaar is? Nix is perfect, toch? Nou...

GIGO: Garbage In, Garbage Out - de kwaliteit van de output wordt beperkt door de kwaliteit van de input. Maar dit is nog niet eens zo'n groot probleem
Signaal/ruis-verhouding beperkt analyse: Door fouten verdwijnt informatie in de ruis. Ik kan steeds minder met die data doen, want bij elke verdere bewerking neemt de signaal/ruis-verhouding toe - Dit is een écht probleem
Verificatie: Verificatie is altijd al problematisch: Als data een x-aantal keer verwerkt wordt, is het lastig om nog te verifiëren of iets klopt. Als die data daarnaast onbetrouwbaar is, wordt dit veel lastiger. Bij het schrijven van rapportages was dit voor mij al een onthutsend lastig probleem (bv. een rapport zegt dat de omzet van product-x vorig seizoen 10% hoger was dan in hetzelfde seizoen vorig jaar - Hoe verifiëer je dat, zo lang het niet om een triviale hoeveelheid gegevens gaat?)

Wat is authentiek?

Het probleem dat hierboven werd geschetst, maar dan anders geformuleerd:

Welke data is authentiek?
Welke data is onveranderd sinds ik er de beschikking over heb gekregen

Dit vraagstuk is belangrijk voor verificatie van resultaten, waaronder of de fout bij mij ligt, of bij de bron van de data.

Oplossing: Brontabellen

De oplossing die ik heb gekozen: importtabellen of brontabellen zijn authentiek. Die data is dus zo ruw mogelijk. Belangrijk dat deze brontabellen gemakkelijk zijn te vergelijken met de oorspronkelijke bron (bv. aangeleverde spreadsheets of XML-bestanden).

Nieuw probleem: Importtabellen zijn onwerkbaar

In de praktijk zijn importtabellen onwerkbaar: Die data is gewoon té ruw om bruikbaar te zijn. Al is het maar omdat de namen van kolommen verwarrend is, of omdat de data te ongestructureerd is (bv. verschillende talen die door elkaar heen lopen).

Oplossing: Tussentabellen als abstractielaag

De oplossing: Tussentabellen gebruiken als abstractielaag: Die importtabellen worden via vaste procedures (bij voorkeur sprocs) verwerkt tot tussentabellen. In het dwh hebbenn deze de extentie _tmp, want het zijn immers tijdelijke tabellen: Voortdurend worden deze tabellen opnieuw gegenereerd aan de hand van de brontabellen. Deze tussentabellen zijn gestandaardiseed, zodat ik er gemakkelijk mee kan werken.