Relasjonsdatabaser (RDBMS) strukturerer data som relasjoner, hvor data er delt opp i separate tabeller og linkes sammen. Jeg skal ikke gå gjennom hele teorien her, les evt. denne artikkelen for bakgrunnskunnskap.
Persondata
Mange databaser vil inneholde en tabell PERSON, og som f.eks. kan se slik ut:
...denne tabellen vil i kunne fungere godt, fordi den inneholder eksakt de verdier man trenger i systemet.
Den erfarne vil imidlertid se se at det kan være svakheter i denne oppbygningen:
- Både POSTNR og POSTSTED er oppgitt, noe som bryter ett av prinsippene i et RDBMS; POSTSTED er avhengig av PERSON.POSTNR, ikke PERSON.ID. Løsningen er enkel: En ny tabell POSTSTED med alle poststeder i landet, og med kolonnene POSTNR og POSTSTED. PERSON.POSTSTED fjernes, og linkes inn i datasettet ved uttrekk:
- KJØNN kan utledes fra FNR: det 9. tegnet er oddetall for menn og partall for kvinner (en annen sak er selvfølgelig i hvilken grad man behøver data for kjønn i systemet, men vi antar at dette er tilfellet). Strengt tatt er altså KJØNN overflødig, men det kan argumenteres med at det gjør datauttrekk enklere og mer lesbart om kolonnen beholdes.
- TLF_PRIVAT og TLF_MOBIL kan virke noe gammelmodig, og spørsmålet er vel om det har noen interesse å registrere hjemmetelefonnummer for folk i dag. Om man skal sende SMS er det avgjørende å vite om kontakttelefonen er en mobil eller en fasttelefon, ellers kan disse kolonnene brukes til å registrere to alternative numre - men da vil ofte det alternative nummeret også være en mobil (f.eks. jobbmobil). Det vil være en sjanse for at bruker/operatør vil registrere jobbmobilen i kolonnen TLF_PRIVAT.
- ID vil i et RDBMS-system være en internt generert ID, typisk en heltallsverdi uten mening for omverdenen. Hvorfor ha denne kolonnen når vi har unike FNR ? Jo, fordi FNR kan endres. Jeg har erfaring med tre ulike grunner for endring: 1) Personen endrer kjønn, 2) Personen er innvandrer eller nyfødt og får først tildelt et midlertidig nummer før et permanent, og 3) Fødselsdato endres i ettertid (typisk for de som kommer fra andre land og hvor informasjon har vært utilstrekkelig/feil).
Om FNR brukes som primærnøkkel, må alle kolonner i alle tabeller som identifiserer personen, oppdateres ved en endring. FNR er unik, men ikke statisk. Det diskuteres faktisk en omlegging av det norske fødsels- og personnummerkonseptet, hvor bl.a. et av temaene er å innføre en ikke-informasjonsbærende id.
- ADRESSE vil være utilstrekkelig hvis man både trenger post- og bostedsadresse. I et kunderegister vil et enkelt adressefelt begrense mulighetene for å kunne sende enten via post eller med bil. Dessuten finner vi igjen en avhengighet mellom ADRESSE og POSTNR, hvor PERSON.POSTNR er avhengig av PERSON.ADRESSE og ikke PERSON.ID. Dette er potensielt en omfattende problemstilling, mer om dette i artikkelen om hvor kompleks modell som kan trenges for noe så enkelt som persondata.
Til tross for disse innvendingene kan jeg se tilfeller hvor det ville kunne være greit å opprette en tabell som den over, det avhenger av svaret på de spørsmålene som er diskutert her. Å lage en perfekt modell i seg selv har mindre interesse, men det vil være synd å begå feil som man typisk gjør om man ikke tenker gjennom hvordan data skal brukes og vedlikeholdes i systemet. Et stadig tilbakevendende problem er adresseendringer, fordi denne modellen f.eks. ikke tar høyde for at en person har en adresse som er relevant for en inneværende ordre mens en ny bestilling gjøres til en annen leveringsadresse. Dette kan beskrives som Ren Ondskap...