Sentraliser dataintegritet

Systemer (dvs. databaser) som administrerer sin egen dataintegritet høres ut som sunn fornuft, og i enkle scenarier er det sunn fornuft. Når forretningsreglene blir komplekse, er det imidlertid vanskeligere å validere dataene på ett sentralt sted.

Når et system (dvs. en database) ikke lenger kan håndheve dataformen, må noe annet ta over. Når kan dette skje?

Telefonnummerformatet i USA er (områdekode) (prefiks) – (nummer), her er et eksempel: (734) 555-3212. Vi snakker om databasen i denne artikkelen for enkelhets skyld, men datalageret trenger ikke å være en database.

Telefonnumre i USA har alltid ti sifre (vi ignorerer det internasjonale sifferet). Telefonnumre kan komme i en rekke formater:

• xxx.xxx.xxxx
• xxx-xxx-xxxx
• (xxx) xxx-xxxx
• (xxx) xxx.xxxx

De fleste databaser er begrenset til datatyper (dvs. tall, strenger, datoer osv.) og støtter ikke formatering. Mange applikasjoner velger å bruke strengdatatypen til å lagre telefonnummeret. Imidlertid godtar strengdatatypen ENHVER streng. For å sikre at telefonnummeret er gyldig, trenger vi et ekstra valideringslag.

I en enkelt applikasjon som kobler seg til en enkelt database, håndheves datavalidering vanligvis i applikasjonen.

Når arkitekturen vokser til to eller flere applikasjoner som deler en database, kan to ting skje:

1. Hver applikasjon har sin egen datavalidering:

2. Det er en sentral tjeneste som applikasjonene kaller for å validere dataene og lagre dataene:

Risikoen ved datavalidering på flere steder er at valideringene kan være ute av synk. Et gyldig format for en applikasjon er kanskje ikke gyldig i en annen applikasjon. I verste fall vil et dårlig format kaste en feil eller, i ekstreme tilfeller, krasje applikasjonen.

Det beste er å sentralisere datavalideringen slik at formatet som lagres i databasen er konsistent for hele organisasjonen. Det finnes selvfølgelig unntak, og jeg antar at flere applikasjoner leser og skriver til en delt database.