Hur ska man hantera fel vid import av data till ett datalager? I grunden finns två vägval. Det enklaste är att inte ladda något alls om det uppstår ett fel, enligt principen ”allt korrekt eller inget nytt data”. Felet får rättas i källan och man får ladda om. Det kan vara en bra lösning om fel är ovanliga. I stora datalager är fel tämligen vanliga och då går den metoden inte att använda. Det blir stopp nästan varje gång.
Så en vanlig metod är att exkludera felaktiga data, logga och rapportera. Rapporteringen bör dels gå till de som ansvarar för källsystemet, så de kan rätta felet, dels till användarna, så att det är medvetna om bristerna i datakvaliteten. Den senare gruppen är inte helt enkelt att nå ut med information till.
Stora och små fel
Man kan också agera annorlunda om det är små eller stora fel. Faller några poster av en miljon bort, kanske det inte har så stor betydelse, även om det i vissa fall kan ha det. Faller hälften av posterna bort är det troligen mer allvarligt. Hur stora kvalitetskrav man har spelar också roll. Bygger man en databas för inventering av antal fåglar i landet, finns troligen stor osäkerhet i datainsamlingen. Några ytterligare små fel kanske inte spelar så stor roll. Fast rapporteras ett ovanligt fynd kan fågelskådare gå man ur huse, så det kan få stor betydelse. Skickar man ut ett kontobesked till en bankkund, bör det nog vara helt korrekt. Ofta brukar kunniga användare (typ controllers) vara bättre på att hantera en del fel än mer novisa användare. I många fall räcker det med att det är ungefär rätt.
Vad är rimligt?
En annan fråga är hur strikt ska man vara för att godkänna data? Tidiga IT-system var ofta rätt kräsna och minsta lilla fel avvisades. Idag är många system mer förlåtande. Ett tidrapporteringssystem jag använt, tillät både decimalkomma och punkt vid rapportering av jobbade timmar. Risken finns dock att skriver man 5.000 kan det tolkas som både 5,0 och 5000 timmar (fast det är kanske inte så troligt att man jobbat 5000 timmar en dag). Ju mer välvilligt ett system är att försöka tolka data, desto mer ökar risken för feltolkningar. Vi har väl alla drabbats när mobilen försöker rätta det den tror är en felskrivning.
Städa data
Ska man städa sitt data? Här finns olika skolor. Vissa anser att ett data warehouse strikt ska spegla vad källsystemen rapporterar. Upptäcks fel ska de rättas i källsystemen. De är en bra princip, förutsatt att man kan påverka sina datakällor. Men i vissa fall har man ingen kontroll över källorna. Då kan det vara bättre att rensa ut uppenbart orimliga värden. Men vad är orimligt? Ibland är konstiga värden faktiskt sanna.
Rätt datakvalitet
I grunden blir det en avvägning mellan om systemet ska ha stor tillgänglighet eller vara mycket korrekt. Här finns inget enkelt svar. I vissa system skiljer man därför på preliminärt och verifierat data.
Dataprofilering kan vara ett bra sätt att undersöka datakvaliteten och hitta misstänkta avvikelser. Statistikrapporter misstänkta och uppenbara fel kan vara till stor hjälp för att höja datakvaliteten.
NULL
NULL brukar vålla debatt. Ibland skiljer man dessutom på olika sorters NULL. I vissa fall är uppgiften inte applicerbar – antal sidor i en talbok. I andra fall kan värdet vara relevant, men saknas – dödsdag för en levande person. Faktumet kan också finnas, men vara okänt – antal planeter med liv i vår galax.
Andra menar att man inte ska använda NULL. Vanligt folk förstår inte NULL.
Minimera felkällor
Det bästa är om man kan undvika fel. Fundera över vilka felkällor som kan uppstå och försök förebygga dem. Tappas kontakten med ett källsystem, kanske man kan pröva att läsa igen efter en stund. Gör inte onödiga antaganden om hur data kommer se ut. Det som man tror bör vara ett heltal, kanske kan korrekt innehålla decimaler. Nummer består ofta av andra tecken än siffror, till exempel gatunummer 20B.
Summering
Det finns inget självklart svar på hur fel ska hanteras. Olika lösningar kan fungera bäst i olika situationer. Ytterst är det en fråga som kravställaren bör avgöra, men många gånger kan frågeställningarna vara svåra att ta ställning till. Här behöver vi utvecklare hjälpa beställaren.
