Evolutionsprincipen ( Informationens tidshorisont)

Händelser är förändringar i objektens tillstånd. Det finns två slags händelser som är relevanta med Data Warehouse arkitektur, (1) existentiella händelser som skapar nya

objekt och tillståndshändelser som förändrar de berörda objektens attributvärde. I den bemärkelse:

´Data Warehouse innehåller såväl aktuella som historiska och framtids data´

Statusdata och händelsedata. Beroende av hur data integreras i systemen kan man

identifiera två slags integrationsfilosofier. Den första integrationsfilosofi kan bara ge information om det aktuella tillståndet (statusdata) medan den andra integrationsfilosofi kan ge information om så väl historiska data som data om den framtida händelseutvecklingen. Med andra ord, statusdata beskriver det aktuella läget på ett objekt som t.ex. ett konto. Händelse data är data som representerar en händelse som t.ex. ett uttag från kontot ifråga. Man kan beskriva en företags transaktion som en aktivitet som resulterar i en eller flera händelser på databas nivå. ( T.ex. händelse information reflekteras i "insert into” medan status information reflekteras i ”uppdate”). I ett Data Warehouse är möjligt att lagra både status och händelse data Det är dock vanligast att man lagrar status data. Händelse data lagras oftast endast en kortare tid för att sedan arkiveras eller raderas, detta för att spara utrymme. ( Båda typerna lagras dock i databasernas loggfiler, detta för att man skall kunna göra back up eller för att man skall kunna återskapa förlorad data. Dessa loggfiler spelar en viktig roll då man skall fylla Data Warehouse med data )

Transistent data kontra periodisk data. Det är ofta nödvändigt att lagra data i Data

Warehouse om när en viss händelse inträffade. Detta behövs om man skall kunna jämföra speciella händelser vid samma tidpunkter eller vid jämförelser av händelser vid olika tidpunkter.

De flesta operationella verksamhetssystemen brukar använda sig av transistent data vilket innebär att när en händelse inträffar så skrivs det befintliga värdet över med det nya. Detta görs utan att det ursprungliga värdet sparas

.

´Transienta data A = A + B Eller A = A * B´

´Periodiska data C = A + B Eller C = A * B´

Man förlorar alltså det tidigare värdet i databasen. I och med att man använder databaser så har man tillgång till loggfiler och genom detta så kan man återskapa bilden av vad som har varit. Nedan visas ett exempel på hur ursprungliga data skrivs över. Enda sättet att få fram ursprunglig data är sedan att söka i logg filerna. Pilarna visar var ändringarna är gjorde.

Tabell Anstalld(1999-02-08)

Id F_namn E_namn Tillgodo

9090 Olle Carlsson 2190 9091 Pontus Svensson 1531 9192 Bror Nilsson 5568 9793 Anders Berg 110 9898 Peder Gran 465 Tabell 1 Tabell Anstalld(1999-02-11)

Id F_namn E_namn Tillgodo

9090 Olle Carlsson 2190 9091 Pontus Svensson 0 9793 Anders Berg 110 9898 Peder Gran 400 9903 Mats Von Löv 0 Tabell 2 Figur 4:7

I filen syns nu inga spår av de tidigare värdena på data. Det är detta som är utmärkande för transistent data. För att man skall kunna återskapa data så kan man som nämnt använda sig av logg filerna. I loggfilerna finns både status och händelse data lagrad. Filerna kan se ut enligt nedan.

Före 9091 Pontus Svensson 1531 1999-02-08 Update 9091 1999-02-11 -1531 Efter 9091 Pontus Svensson 0 1999-02-11 Tabell 3 Figur 4:8 Loggfil

Periodiska data. Om man jämför transistenta data med den periodiska så är skillnaden att den periodiska inte ändras eller tas bort. Är den väl införd en gång så stannar den där. För att veta det aktuella värdet på ett objekt så får man använda sig av de tids angivelser eller tidsstämplar som det också kallas, som talar om när senaste ändringen är gjord. Den data som har den senaste ändrings stämpeln är den som är den aktuella. I och med att man sparar tidigare värden så kan man lätt gå in och se de historiska

Händelse: Uttag

värdena. Nedan visas ett exempel på detta. Jämför skillnaden med ovan visade exempel.

Tabell Anstalld(1999-02-08)

Id F_namn E_namn Tillgodo Datum Händelse

9090 Olle Carlsson 2190 1999-02-08 C 9090 Pontus Svensson 1531 1999-02-08 C 9192 Bror Nilsson 5568 1999-02-08 C 9793 Anders Berg 110 1999-02-08 C 9898 Peder Gran 465 1999-02-08 C Tabell 4 Tabell Anstalld(1999-02-11)

Id F_namn E_namn Tillgodo Datum Händelse

9090 Olle Carlsson 2190 1999-02-08 C 9091 Pontus Svensson 1531 1999-02-08 C 9091 Pontus Svensson 0 1999-02-11 U 9192 Bror Nilsson 5568 1999-02-08 C 9192 Bror Nilsson 5568 1999-02-11 D 9793 Anders Berg 110 1999-02-08 C 9898 Peder Gran 465 1999-02-08 C 9898 Peder Gran 400 1999-02-11 U 9903 Mats Von Löv 0 1999-02-10 C Tabell 5 Figur 4:9

Det som skiljer de periodiska datatabellerna är de två nya fälten Datum och Händelse. Fältet datum fungerar som tidsstämpel liknande den i databas loggen vilken talar om när en rad blev modifierad, även klockslag kan förekomma. Fältet händelse visar vilken händelse som utfördes vid ett visst datum, som alltså visades i datumfältet. C, U, D, står för create, update, delete. Ut över dessa fält så är tabellerna uppbyggda så att alla data lagras, har de en gång skrivits in så kommer de alltid att finnas där. Detta är en av anledningarna till att kravet på lagringsutrymme ökar snabbt. Detta ställer krav på beslutsprocessen då man skall bestämma vilken nyckeldata som skall lagras så här.

Användningsfrekvens. Identifiering av tidsperioden som krävs för varje

beslutssupport applikation. Detta uppnås genom identifikation av tidsperioden som signifikant för beslutsfattande processen och behovet av nivån på detaljerade data. Till exempel för att svara på en fråga om de möjliga intäkter för uthyrda objekt för det kommande halvåret kanske inte krävs att man undersöker intäkterna för det föregående halvåret men kanske krävs en undersökning av samma månad under de senaste två åren. För övrigt nivån på detaljkravet för att svara denna fråga kan begränsas till jämförelse av aggregerat data och kanske inte kräver tillgång till detaljerat data. Behållningsperioden och nivån på nödvändigt detaljerat data borde vara identifierad för varje beslutssupport applikation.

Avgöra kravet för statistiska exempel på delmängd av data gentemot kravet för detaljerat data. Det är möjligt att reducera volymen av detaljerad information lagrad i Data Warehouse genom att spara en perspektiv exempel av detaljerat data tillsammans med växlande aggregationer för ett komplett set av data. Till exempel för att svara på föregående fråga (Se föregående stycke) kan endast krävas en jämförelse av intäktsmedelvärdet av egendom för uthyrning i varje stad hellre än detaljerad intäkter av varje filial av företaget.