Enkelt sannhetskilde

Innen informatikk er en enkelt sannhetskilde en arkitektur for et informasjonssystem hvor man strukturerer informasjonsmodeller og tilhørende datamodeller slik at hvert dataelement har sin mesterkopi på bare ett sted, hvilket som gir normalisering på kanonisk form. Koblinger til dataelementer skjer da bare ved referanse. Siden alle andre steder man finner dataene bare refererer tilbake til den primære «sannhetskilden» vil oppdateringer av dataelementet på den primære plasseringen forplante seg til hele systemet, hvilket kan gi bedre effektivitet og produktivitet, forebygge inkonsistenser, samt gi sterkt forenklet versjonskontroll. Ideelt skal et system med enkelt sannhetskilde levere data som er autentiske, autentiserbare, relevante og refererbare.

Arkitekturer for en enkelt sannhetskilde har blitt brukt i virksomheter for å unngå at det brukes utdatert (og derfor feil) informasjon på grunn av feilkoblede dupliserte eller denormaliserte dataelementer (en direkte konsekvens av forsettlig eller utilsiktet denormalisering av en hvilken som helst eksplisitt datamodell). I arkitekturer uten en enkelt sannhetskilde vil hyppige forgreninger svekke klarhet og produktivitet, noe som medfører arbeidskrevende vedlikeholdsbehov.

Eksempler på bruk

Noen eksempler på implementering av systemer med en enkelt sannhetskilde kan være:

• I elektroniske pasientjournaler: Her er det viktig å validere pasientidentiteten nøyaktig mot et enkelt referanselager som fungerer som en enkelt sannhetskilde. Dupliserte representasjoner av data vil implementeres da ved bruk av pekere i stedet for å duplisere databasetabeller, rader eller celler. Dermed sikrer man at dataoppdateringer til elementer på det autoritative stedet distribueres til alle fødererte databaser. Pasientjournaler er et godt eksempel på hvorfor slike arkitekturer både er nødvendige og utfordrende i implementere.
• Enkeltkilde-publisering: Et generelt prinsipp eller ideal i innholdsforvaltning som er avhengig av å ha en enkelt sannhetskilde, enten via transklusjon eller i det minste substitusjon. Substitusjon skjer via biblioteker av objekter som kan forplantes som statiske kopier som senere oppdateres når det er nødvendig (altså at ny importert utløses av en større oppdateringshendelse, for eksempel når et nytt vitenskapelig fremskritt eller viktige nyheter publiseres).

Implementering

Ontologiske interaksjoner

En forutsetning for at en gitt enkelt sannhetskilde kan eksistere er at det ikke eksisterer mer enn én enkelt sannhet. I mange tilfeller gir ikke dette noen problemer (for eksempel innenfor bestemte navnerom, eller til og med på tvers av dem, så lenge navnekollisjoner eller bredere navnekonflikter blir adekvat håndtert).

Brede sammenhenger og de vanskeligste ontologiske avvikene krever sammenligning ved «epistemisk regime» og avstemming (eller i det minste forhandlinger eller transaksjonselle utvekslinger). Et eksempel på slik forsoning er hvis to teologiske seminarbiblioteker fra to forskjellige religioner (X og Y) kan utveksle informasjon, men at enigheten om sannheten vil ligge på nivået med utsagn som at "religion X hevder at Gud er lilla mens religion Y hevder at Gud er grønn", snarere enn på nivået med "Gud er lilla" eller "Gud er grønn".

Dette plattform-agnostike konseptet har også sivile og utenrikspolitiske bruksområder med tanke på forskjeller mellom ulike jurisdiksjoner sine juridiske definisjoner, som for eksempel hvorvidt et bestemt økonomisk system anses som godt, dårlig eller en mellomting (for eksempel kapitalisme, sosialisme og blandingsøkonomi), juridiske definisjoner av ekteskap (om en pasient er gift eller ikke, og i henhold til hvilken lov), om det biologiske kjønnet er lik det juridiske kjønnet (hvilket kjønn eller kjønnsidentitet en person har ifølge egenmelding eller ifølge noen andre), og så videre.

Arkitekturer

En ideell implementering en enkelt sannhetskilde er sjelden mulig for de fleste virksomheter. Dette skyldes at mange organisasjoner har flere informasjonssystemer som hver har behov for tilgang til data knyttet til de samme entietene (for eksempel kunde). Ofte kjøper virksomehter flere programvare-systemer som hyllevare fra ulike leverandører, og disse kan ikke endres på trivielle måter. Hvert av disse forskjellige systemene må derfor lagre sine egen versjon av felles data eller entiteter, og derfor må hvert system beholde sin egen kopi av en oppføring (og dermed umiddelbart bryte enkeltkilde-tilnærmingen definert ovenfor).

For eksempel vil:

• Et ressursplanleggings (ERP) -system ha behov for å lagre en kundeoppføring
• Et kunderelasjons (CRM) -system ha behov for en kopi av kundeoppføringen (eller deler av den)
• Et lagerforsendelse-system kan også trenge en kopi av noen eller alle kundedataene (for eksempel leveringsadresse)

Det er ikke alltid støtte i programvaren for å erstatte disse oppføringene med pekere til en enkelt sannhetskilde.

For organisasjoner (med mer enn ett informasjonssystem) som ønsker å implementere en enkelt sannhetskilde (uten å endre alt annet enn ett hovedsystem for å lagre pekere til andre systemer for alle entiteter), brukes ofte understøttende arkitekturer som:^{[trenger referanse]}

• Datavarehus
• Grunndataforvaltning (master data management, MDM)
• Hendelseslager, (event store and event sourcing, ER), en database som bare lagrer hendelser og instansierer objekter under presentasjon
• Tjenestebuss (enterprise service bus, ESB)
• Tjenesteorientert arkitektur (service-oriented architecture, SOA)

Datavarehus

Mens det primære formålet med et datavarehus er å støtte rapportering og analyse av data som er kombinert fra flere kilder, mefører også det faktumet at slike data er kombinerte (i henhold til forretningslogikk innebygd i transformasjons- og integrasjonsprosesser) at datavarehuset ofte brukes som en de facto enkelt sannhetskilde. Generelt sett brukes imidlertid ikke dataene som er tilgjengelige fra datavarehuset til å oppdatere andre systemer; snarere blir datavarehuset en enkelt sannhetskilde for rapportering til flere interessenter. I denne sammenheng blir datavarehuset mer korrekt referert til som en enkeltversjon av sannheten siden andre versjoner av sannheten eksisterer i dens operasjonelle datakilder (ingen data stammer fra datavarehuset, det er ganske enkelt bare en rapporteringsmekanisme for data lastet fra driftssystemer).

Grunndataforvaltning

Et system for grunndataforvaltning kan fungere som sannhetskilde for en gitt entitet som kanskje ikke nødvendigvis har en alternativ sannhetskilde i et annet system. Vanligvis fungerer grunndataforvaltning som et knutepunkt for flere systemer, hvorav mange kan være sannhetskilden for oppdateringer av forskjellig informasjon om en gitt entitet. For eksempel kan kunderelasjonssystemet være sannhetskilden for de fleste aspekter av kunden, og oppdateres av en operatør i kundesenteret. Imidlertid kan (for eksempel) en kunde selv også oppdatere adressen sin selv via en kundeportal som fungerer via en annen baksystem-database enn CRM-systemet. Grunndata-applikasjonen mottar da oppdateringer fra to ulike kilder, og fungerer som megler for å bestemme hvilke oppdateringer som skal betraktes som autoritative (gylden oppføring) og syndikerer deretter disse oppdaterte dataene videre til alle abonnementssystemer (normalt via en tjenestebuss).

Hendelseslager og hendelseskilder

Hendelsesorienterte arkitekturer kan implementeres ved å lagre systemtilstanden som en ordnet sekvens av tilstandsendringer. For å gjøre dette trengs et hendelseslager som er en type database designet for å lagre alle hendelsene som endrer tilstanden til systemet.

Tjenestebuss

En tjenestebuss tillater et hvilket som helst antall systemer i en organisasjon å motta oppdateringer av data som har endret seg i et annet system. For å implementere en enkelt sannhetskilde må man identifisere ett enkelt kildesystem med riktige data for enhver entitet. Endringer i denne entiteten (opprettelse, oppdatering og sletting) publiseres deretter via tjenestebussen, og andre systemer som trenger en kopi av disse dataene abonnerer på denne oppdateringen, og oppdaterer følgelig sine egne oppføringer. Hovedkilden for enhver gitte entitet må kunne identifiseres (noen ganger kalt den gyldne oppføringen). Ethvert gitte system kan publisere (altså være sannhetskilde for) informasjon om en bestemt entitet (for eksempel kunde), og også abonnere på oppdateringer fra et annet system for informasjon om en annen entitet (for eksempel produkt).^{[trenger referanse]}

Se også

• Blokkjede, distribuert database for bokføring av transaksjoner
• Enkeltversjon av sannheten, ideal hvor alle data til en organisasjon er lagret i en konsistent og ikke-redundant form
• Databasenormalisering, teknikk for å designe tabeller i relasjonsdatabaser slik at man minimerer duplisering av informasjon
• Ikke gjenta deg selv, et prinsipp i programvareutvikling med mål om å redusere gjentakende programvaremønstre, og erstatte dem med abstraksjoner som bruker datanormalisering for å unngå redundans
• Kildesystem for en oppføring, den autoritative datakilden for en gitt dataelement
• KISS-prinsippet («keep it simple, stupid»)
• Sirkulær rapportering, problem hvor en kilde henter informasjon fra et sted, som deretter bruker den kilden som referanse
• SOLID (objektorientert design), fem designprinsipper for å gjøre objektorienterte design forståelige, fleksible og vedlikeholdbare (Enkeltansvar; Åpen-lukket; Liskov-substitusjon; Grensesnitt-segregering: Avhengighet)
• Transklusjon, inklusjon av en del av et dokument i et annet dokument gjennom referanse
• Unix-filosofien, en mengde med kulturelle normer og filosofiske tilnærmelser
• Virksomhetsarkitektur, samspillet mellem en en virksomhets forretningsstrategi og dets evne til at levere denne