Door: Steffi

Veel bedrijven zijn tegenwoordig sterk afhankelijk van data voor het optimaliseren van diverse (interne) processen. Een goed georganiseerd en consistent data warehouse is daarvoor een absolute noodzaak. Meestal omvat een data warehouse verschillende data sets, afkomstig van vaak zeer verschillende bronnen. Het gaat dan niet alleen om datasets van interne diensten en bronnen zoals uw eigen klantengids, maar ook datasets van derden en dus ook verschillende soorten bronnen.

Om de meeste data beschikbaar te maken, staan bedrijven vaak voor de uitdaging om data uit een bron zo te integreren dat deze past bij de structuur in hun domein en dat deze aansluit bij de bedrijfsregels van hun organisatie.

Een deel van deze uitdaging heb ik al behandeld in de Blogpost over het zodanig vertalen van databronnen dat het past in de hoofdstructuur van ons data warehouse. Naast de taak van het vertalen van de databron, hebben we ook regelmatig te maken met potentiële inconsistentie op plaatsen waar onze bedrijfslogica en ons model dit niet mogelijk maken.

Laten we ter illustratie een voorbeeld aanhalen:

De praktijk

Stel, u bent een detaillist die een service van derden gebruikt om uw verkoopproces te beheren. Vaak kunt u met een dergelijke service van derden gegevens over uw klanten, verkoopprocessen en meer ophalen met behulp van een API. De opgehaalde data laadt u in uw datawarehouse in zodat u die data verder kunt analyseren.

Laten we er voorlopig van uitgaan dat u een dataset over uw klanten importeert met contactgegevens zoals het woonadres. Daarnaast importeert u een dataset over verkooporders.

In uw eigen bedrijfsmodel heeft u waarschijnlijk geen verkooporders die niet aan een bekende klant zijn gekoppeld, omdat u anders de bestelling niet daadwerkelijk kunt uitvoeren en factureren. Maar wat moet u doen als de dataset van verkooporders die u uit de API haalt, een order bevat die u niet aan een klant uit de klantdataset uit dezelfde API kunt koppelen?

Dit kan om verschillende redenen gebeuren. In uw data warehouse zou wilt u dit soort gevallen idealiter vermijden, omdat dit uw analyse mogelijk zou vertekenen.

Benadering om potentieel inconsistente gegevens consistent te maken

Het is duidelijk dat we geen magie kunnen toepassen en ontbrekende gegevens kunnen herstellen als we niet weten wat we missen. Maar we kunnen ervoor zorgen dat we alleen gegevens opslaan die daadwerkelijk consistent zijn en voldoen aan onze bedrijfsregels. En we kunnen ervoor zorgen dat we alleen consistente gegevens gebruiken in onze analyses.

Terugkomend op het voorbeeld: we hebben een relatie tussen de klant en een verkooporder en hoewel het datamodel in de bron mogelijk niet voldoet aan onze bedrijfsregels, willen we dat ons datawarehouse dit wel doet. In dit geval beteken het dat we alleen verkooporders willen opslaan die we aan een klant kunnen koppelen in onze klantgegevensset.

Om dit te garanderen, zou de logische volgorde van de stappen er als volgt uit kunnen zien:

  1. Importeer de klantdataset in een productie-schema in het datawarehouse;
  2. Haal de verkooporderdataset op (het is belangrijk dat we dit doen ná het ophalen van de dataset, waarvan de verkooporders afhankelijk zijn. In dit geval de klantdataset);
  3. Sla de verkoopordergegevensset op in een staging-schema in het datawarehouse;
  4. Voeg voor elke verkooporder in het staging-schema de record alleen in een productieschema in als u een bijbehorende klant vindt in uw klantgegevensset in uw datawarehouse;
  5. Elke verkooporder die niet met succes aan een bestaande klant in de dataset van de klant is gekoppeld, blijft in het staging-schema staan.

Voordelen

Bovengenoemde aanpak lijkt op het eerste gezicht misschien ingewikkeld, maar heeft verschillende voordelen:

1. Samenhang

Gegevens die in het productieschema zijn opgeslagen, zijn gegarandeerd consistent en u kunt erop rekenen dat elk record in uw dataset correct is gekoppeld als er records in andere datasets aan zijn gekoppeld.

2. Volledigheid

Hoewel uw datasets mogelijk niet compleet zijn in uw productieschema, kunt u altijd nog steeds analyses uitvoeren op de volledige dataset door de gegevens uit het stagingschema op te nemen. Bovendien maakt het onderscheid in twee schema’s eventuele inconsistenties bij de brongegevens voor u zichtbaar en kwantificeerbaar, waardoor u mogelijk inconsistenties bij de bron kunt oplossen of op zijn minst de aard en oorzaak ervan beter kunt begrijpen.

3. Zelfherstellend proces

Soms kunnen inconsistenties ook slechts tijdelijk zijn. Een voorbeeld: Als er updates of wijzigingen van de gegevens plaatsvinden tussen het opvragen van gegevens voor verschillende datasets, kan het zijn dat de inconsistentie is opgelost op het volgende moment dat u de datasets opvraagt.

In ons bovenstaande voorbeeld kan het zijn dat er tussen het opvragen van de dataset voor klanten en verkooporders een nieuwe klant is aangemaakt die ook een bestelling heeft gedaan. Op het moment wanneer de dataset voor verkooporders wordt opgehaald en opgeslagen is, er sprake is van een bestelling van een klant, die nog niet bestond op het moment dat u de klantdataset opvroeg en opsloeg. In dat geval slaat u met de beschreven aanpak de verkooporder op in het staging-schema, maar voegt u deze niet in uw productieschema in, omdat de gekoppelde klant niet bestaat.

De volgende keer dat u opnieuw gegevens uit die bron importeert, zal de klant bestaan en bij uw productieschema worden ingevoegd. Wanneer u vervolgens de verkooporders ophaalt, kunt u de verkooporder van de nieuwe klant in uw productieschema invoegen.

Samenvatting

Door de beschreven aanpak te volgen, haalt u het beste uit twee werelden: aan de ene kant beschikt u altijd over een volledige dataset door gegevens uit de productie en het stagingschema te combineren, terwijl u aan de andere kant erop kunt vertrouwen dat u alleen consistente gegevens in uw systeem heeft.