Redigerer Hendelseslager

{{kildeløs}}
Et '''hendelseslager''' er en type [[database]] optimalisert for lagring av hendelser.

[[Begrep|Konseptuelt]] lagrer et hendelseslager bare ''hendelsene'' av noe som oppfyller angitte [[Policy|retningslinjer]]. Tanken er at retningslinjen kan utledes av disse hendelsene. Hendelser (og tilsvarende [[data]]) er de eneste "virkelige" [[Faktatabell|faktaene]] som skal lagres i databasen. Instansieringen av alle andre [[Objektorientert programmering|objekter]] kan avledes fra disse hendelsene. [[Kode|Koden]] instansierer disse objektene i minnet. I en hendelseslagerdatabase betyr dette at alle objekter som skal instansieres ''ikke'' lagres i databasen. I stedet instansieres disse objektene når de trengs i kodens minne basert på hendelsene. Etter bruk av disse objektivene (for eksempel visning i et [[brukergrensesnitt]]) blir de instansierte objektene fjernet fra minnet.

== Eksempel på bruk ==
Hendelseslager-konseptet til en database kan for eksempel brukes på [[Polise|forsikrings]]- eller pensjonspoliser. Ved instansieringen av hvert objekt kan man utlede den relevante retningslinjen (person, [[Interessentskap|partner]], ansettelsesforhold, og så videre) i minnet basert på hendelsene i den virkelige verden.

== Dobbel tidslinje ==
En viktig del av en hendelseslager-databaser er at hver hendelse har en dobbel tidslinje. Dette gjør det mulig for hendelseslageret å korrigere feil på hendelser som tidligere har blitt lagt inn i hendelsesdatabasen. 

De to datoene er:
* Gyldig dato er datoen da arrangementet har blitt gyldig.
* Transaksjonsdato er datoen da hendelsen legges inn i databasen.

== Feilkorrigering ==
En annen viktig del av en hendelseslager-databaser er at hendelser som er lagret ikke har lov til å endres. Når de er lagret endres ikke feilaktige hendelser lenger.

Den eneste måten å endre (eller rettere sagt: korrigere) disse hendelsene på er å instansiere en ny hendelse med de nye verdiene og utnytte den doble tidslinjen. Den korrigerende hendelsen vil ha de nye verdiene til den opprinnelige hendelsen, med hendelsesdataene for den korrigerte hendelsen, men med en annen transaksjonsdato. Denne mekanismen sikrer reproduserbarhet til enhver tid, selv i tidsperioden før korreksjonen har funnet sted. Dette gjør det også mulig å reprodusere situasjoner basert på feilaktige hendelser dersom nødvendig.

== Fordeler og ulemper ==
En fordel med hendelseslager-konseptet er at det er mye enklere å håndtere effekten av daterte hendelser (hendelser som trer i kraft før tidligere hendelser og som til og med kan ugyldiggjøre dem). 

Et hendelseslager vil forenkle koden ved tilbakerulling av feilaktige situasjoner, og opprulling av nye korrekte situasjoner vil ikke være nødvendig.

En ulempe kan være at koden må gjenopprette alle objekter i minnet basert på hendelsene hver gang et tjenestekall mottas for en bestemt retningslinje.

== Sammenlignet med vanlige databaser ==
I vanlige databaser kan korrigering av tidligere, feilaktige hendelser med tilbakedatering være smertefullt ettersom det ofte resulterer i at man må rulle tilbake alle tidligere, feilaktige transaksjoner og objekter, og deretter rulle opp de nye, riktige transaksjonene og objektene. I et hendelseslager lagres bare den nye hendelsen (og tilhørende fakta). Koden vil deretter bestemme transaksjonene og objektene på nytt basert på de nye faktaene i minnet.

== Se også ==
* [[Temporal database]], en database som lagrer data relatert til ulike tidsakser (f.eks. fortid, nåtid og fremtid) for å bestemme transaksjoner, gyldighet eller beslutninger

== Eksterne lenker ==
* [http://db-engines.com/en/ranking/event+store DB-Engines Rangering Av Eventbutikker] etter popularitet, oppdateres månedlig

[[Kategori:Databaser]]