Middleware Services: Data Quality Assurance - dummies

U moet twee verschillende kwaliteitswaarborgingsservices (QA) in de stroom middleware-services instellen. U moet de eerste QA-taken uitvoeren op basis van het uittreksel uit de gegevensbron voordat u meer middleware-services uitvoert.

Kwaliteitsborging van gegevens: deel I

Probeer zo vroeg mogelijk in het proces fouten en problemen op te sporen (en te corrigeren). Het verplaatsen van gegevens in de pijplijn in de richting van het datawarehouse heeft geen zin als de problemen zo groot zijn dat ze ofwel aanzienlijk meer moeite vereisen om later in het proces te corrigeren of gewoon niet kunnen worden gecorrigeerd.

Dus, wat voor soort problemen moet je zoeken? Hier zijn een paar:

• Waarden in gegevenselementen die een redelijk bereik overschrijden: Een klant heeft bijvoorbeeld de afgelopen maand 150 miljoen bestellingen ingediend of een medewerker heeft 4, 297 jaar bij het bedrijf gewerkt, volgens de werknemersdatabase en de opgeslagen inleverdatum.

• Waarden in gegevenselementen die niet in de officiële en volledige lijst van toegestane waarden passen: Een waarde kan een A-code hebben, bijvoorbeeld wanneer de enige toegestane waarden voor dat veld M en F zijn. (If dat veld werd GENDER genoemd, A staat misschien voor androgyn!)

• Inconsistenties tussen tabellen: Voor vermeldingen in de tabel CUSTOMER_ORDER zijn er geen overeenkomstige vermeldingen (zoals geïdentificeerd door CUSTOMER_ID) in de CUSTOMER_MASTER_TABLE.

• Inconsistenties tussen velden: Records met een onjuiste staat of postcode voor de aangegeven stad.

• Ontbrekende waarden: Records met ontbrekende waarden in bepaalde velden waar ze de inhoud zouden moeten hebben.

• Gaten tussen gegevens: Een brontabel zou bijvoorbeeld één rij met gegevens moeten bevatten die de totale verkochte eenheden en verkoopdollars voor elke maand van de afgelopen twee jaar omvat. Voor een groot aantal klanten bestaan ​​er echter geen rijen voor ten minste één van die maanden.

• Onvolledige gegevens: Als informatie over elk product dat het bedrijf verkoopt verondersteld wordt beschikbaar te zijn, zijn bijvoorbeeld alle producten in het uittreksel opgenomen?

• Overtredingen van bedrijfsregels: Als in een bedrijfsregel wordt vermeld dat slechts één groothandelaar producten kan verkopen aan een van de klanten van het bedrijf, moet u controleren om na te gaan of een klantrecord aangeeft dat er verkopen zijn gedaan via meer dan één groothandel, kan onjuiste gegevens in de bron aangeven.

• Gegevenscorruptie sinds het laatste uittreksel: Als de extractie bijvoorbeeld maandelijks plaatsvindt, moet u gegevenswaarden of sommen bijhouden die constant moeten zijn, zoals VERKOOP PER KLANT PER MAAND.Als in een volgende maand de waarde van SALES PER KLANT PER MAAND voor een bepaalde klant voor een vorige maand verandert, zijn de onderliggende gegevens mogelijk beschadigd.

• Spelling-inconsistenties: De naam van een klant wordt bijvoorbeeld op verschillende manieren gespeld.

Wat doe je als je problemen vindt? U kunt een van de volgende technieken proberen:

• Een regel voor automatische correctie toepassen. Als u bijvoorbeeld een inconsistente spelling vindt, kunt u in een hoofdtabel met eerdere spellingcorrecties opzoeken en de wijziging in de gegevens automatisch aanbrengen.

• Leg de record opzij voor een teamlid om dit later te analyseren en corrigeren. In dit geval kunt u het menselijke deel van de QA doen in combinatie met automatische correctie.

  Er worden bijvoorbeeld zo mogelijk automatische correcties aangebracht en een rapport over andere problemen wordt in een afzonderlijk bestand geplaatst en naar de QA-persoon verzonden. Wanneer de QA-persoon alle handmatige correcties uitvoert, voeg je de correcties weer samen in de gegevens die door het automatische QA-proces zijn gegaan.

• Koel je jets af. Als u voldoende ernstige problemen ontdekt of een onbepaalde hoeveelheid onderzoek nodig hebt, overweeg dan om het hele proces te stoppen totdat u het probleem hebt gevonden en opgelost.

U kunt het QA-proces veel efficiënter en veel minder problematisch maken als u een grondige bronsysteemanalyse uitvoert. Als u een redelijk goed idee hebt over welke soorten gegevensproblemen u in elke gegevensbron kunt vinden, kunt u uw QA-proces opnieuw programmeren om deze problemen te detecteren en (hopelijk) te corrigeren voordat u doorgaat.

In het verleden behandelden organisaties het QA-proces van het Qware-proces als een eenrichtingsstroom. Problemen worden gecorrigeerd voordat de gegevens verder worden verplaatst naar de stroom middleware-processen, maar nooit gecorrigeerd in de gegevensbronnen. De meeste nieuwe datawarehouses hebben een ingebouwde feedbackkring van het QA-proces die problemen met de gegevenskwaliteit in de brongegevens corrigeert.

Kwaliteitsborging van gegevens: deel II

Na voltooiing van de transformatieprocessen moeten de gegevens opnieuw QA'd zijn -. Je weet nooit welk type fouten of verschillen het transformatieproces mogelijk in de gegevens heeft ingevoerd. Nadat er wijzigingen zijn aangebracht, zijn eerdere QA-processen niet langer geldig.

Voer de geconsolideerde, getransformeerde gegevens uit door hetzelfde type QA-stappen als hier besproken. Hoewel je waarschijnlijk niet zoveel rudimentaire fouten vindt (zoals spelfouten of waarden die buiten het bereik liggen) als je een grondige klus hebt gedaan op je eerste klas QA, wil je er toch zeker van zijn. Zorg er verder voor dat de code of scripts die worden gebruikt voor gegevenstransformatie niet per ongeluk leiden tot nieuwe fouten.

Het doel van deze QA op het tweede niveau is ervoor te zorgen dat uw geconsolideerde en getransformeerde gegevens gereed zijn om in de datawarehouse - zodra er nog een stap gebeurt, indien nodig.