Data warehouse
Den här artikeln eller det här avsnittet innehåller inaktuella uppgifter och behöver uppdateras. (2023-06) Motivering: Faktauppgifterna i artikeln är i princip från 2006, resten är främst språkputs. Se även diskussionen. Hjälp gärna Wikipedia att åtgärda problemet genom att redigera artikeln eller diskutera saken på diskussionssidan. |
Den här artikeln behöver källhänvisningar för att kunna verifieras. Motivering: Se diskussion. (2023-06) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan. |
Ett data warehouse, även kallat informationslager eller datalager, är en sammanställning av information från flera källor, utförd på ett sådant sätt att det underlättar en avancerad analys av informationen. Sammanställningen har dessutom en sådan struktur, och är försedd med sådana hjälpmedel, att analysen kan utföras utan mera djupgående IT-kunskaper. Tekniker för sökbara datalager är en del av det vidare begreppet big data, som också innefattar datautvinning, det vill säga statistisk dataanalys.
Uppbyggnad
[redigera | redigera wikitext]Ett informationslager är i praktiken alltid databasbaserat; källorna kan dock vara lagrade på flera olika sätt, på något sätt tillgängliga för informationslagret. En mångfald sätt att överföra data finns: via epost, ftp, direkta länkar mellan databaser, med flera.
Analysen av informationen är normalt baserad på flera parametrar, så kallade dimensioner. En dimension motsvaras av minst en databastabell. Det data som analyseras, faktat, lagras också det i en eller flera databastabeller.
Den vanligaste uppbyggnaden av ett informationslager är stjärnschemat (engelska Star Schema), där faktatabellen (eller tabellerna) omges av en dimensionstabell per dimension. Tabellerna i ett stjärnschema är denormaliserade. Strukturen påminner om en stjärna, därav namnet.
En annan vanlig uppbyggnad är snöflingeschemat (engelska Snow Flake Schema), fortfarande med en eller flera faktatabeller i mitten. Dimensionstabellerna är emellertid normaliserade, vanligtvis på tredje normalformen. Man har alltså (vanligtvis) mer än en tabell per dimension, och strukturen påminner vagt om en snöflinga.
I princip är stjärnschemat mer tidskrävande att bygga än snöflingeschemat, men snabbare och enklare att använda. De flesta experter tenderar att förorda stjärnscheman.
Det finns även dimensionslösa informationslager. På grund av att dessa vanligtvis är betydligt mindre effektiva vad gäller söktider, används de främst för mindre datamängder.
Informationshanteringssystem
[redigera | redigera wikitext]Arbetsgången när man bygger ett informationslager brukar benämnas ETL, efter de engelska orden:
- Extraction - extraktion (insamling av rådata) från olika databaser och datafiler
- Transformation - omvandling av data. Samma information kan vara lagrad på helt olika sätt i de olika källorna, och denna måste transformeras, så att den är direkt jämförbar. Till exempel kan datum lagras som "2005-07-29" på en källa, och som "072905" på en annan.
- Loading - laddning av informationen in i de olika databastabeller som ingår i informationslagret.
Metadata
[redigera | redigera wikitext]En viktig del av det lagrade datat är så kallad metadata, "data om data". Metadata utgörs av information som är väsentlig för användningen av informationslagret: Laddningstidpunkt, ändringstidpunkt, beskrivning av innehållet i de olika fälten, relationer mellan olika typer av data med mera. När det gäller beskrivningen av datat är det viktigt med en enhetlig namnkonvention i de fall (allt mer vanliga) då informationslagret skall användas av dotterbolag i många länder.
Det är också vanligt att olika koder (landskoder, felkoder m.m.) förklaras, ofta i olika tabeller.
Användning
[redigera | redigera wikitext]En typisk användning för informationslager är för att underlätta för ledningen av en stor koncern att följa affärsprocesserna. Exempelvis kan man ställa en fråga om hur mycket som sålts av vissa angivna produkter i ett antal länder under vissa år. Det erhållna svaret kan presenteras på flera olika sätt, ofta i form av ett "drillbart bildskärmsdokument" men även som exempelvis grafiska diagram och rapporter på papper. Uttrycket "drillbarhet" kommer av engelskans drill-down, där begreppet avser möjlighet att borra sig ner i materialet. Ett drillbart bildskärmsdokument är ett dokument där man kan markera olika kolumner för att antingen dela upp dem på kortare dimensionsintervall eller summera dem på större intervall. Om datan i ett sådant dokument från början presenteras per månad och land kan man exempelvis välja att summera per år eller dela upp per vecka, alternativt summera per världsdelar eller dela upp per försäljningsområden/län/kommun (motsvarande).
Aggregat
[redigera | redigera wikitext]Eftersom det är brukligt i informationslagermiljö med summeringar av data är det vanligt att spara inte bara ett, utan flera olika aggregat, alltså data som summerats på de vanligaste parametrarna, för att snabba upp sökningarna i drillbara dokument.
Krav på informationslager
[redigera | redigera wikitext]Amerikanen Bill Inmon, som var en av de första som definierade begreppet Data warehouse, satte upp fyra krav på ett informationslager:
- Subjektorienterat - data som berör samma affärsobjekt eller samma (affärsmässiga) händelse lagras logiskt tillsammans
- Tidsvariant (time variant) - förändringar i tiden skall inte raderas, utan lagras som historisk data
- Konstant (non-volatile) - data skrivs aldrig över, utan behålles för historisk analys
- Integrerat - informationslagret hämtar data från alla affärsapplikationer i ett företag (av praktiska skäl måste detta krav vanligtvis modifieras)
Slowly changing dimensions
[redigera | redigera wikitext]Det som är tidsvariant och konstant i ett informationslager är faktat. Dimensionerna kan emellertid också ändras över tiden, till exempel om en kund (eller producent, eller något annat som faktat delas upp efter) ändrar adress och hamnar i en annan region, vilket kan skapa problem när man jämför data. Detta problem är känt som slowly changing dimensions.
Den mest radikala lösningen på detta är att förändringar i tiden aldrig raderas, utan lagras som historisk data, precis som för fakta. Detta har dock i praktiken visat sig opraktiskt; idag lagrar man oftast historisk data bara för en eller ett par dimensioner, och låter de övriga vara utan (det vill säga man skriver över datat). Inte sällan har man över huvud taget ingen historisk dimensionsdata alls. Informationslager tenderar att bli mycket stora, och att lagra stora mängder av historisk data inte bara för faktat (som vanligtvis har få kolumner), utan även för dimensionerna är både tids- och utrymmeskrävande. Det finns också olika tekniker för att lagra dimensionsdata i inte helt fullständig (och därmed utrymmesbesparande) grad.