Data Warehouse brukar översättas med datalager till svenska, men många använder den engelska termen. Enligt definitionen är företagets datalager lagringsplatsen för all historisk information, råmaterialet för företagets beslutsstöd. I praktiken kan man inte samla in all historisk information, men det är åtminstone ett riktmärke.
En nyckel till datalagrets framgång är att analytiker eller beslutsfattare kan ställa komplexa frågor och analyser, utan att riskera att företagets operativa system störs. Eftersom ett datalager kan bli väldigt stort, kräver det enorma krav på systemets prestanda och skalbarhet.
Det innebär att det är vanligt med dataförråd (data mart), som är en delmängd av datalagret speciellt fokuserat på en viss typ av frågor eller analyser. Nackdelen är att datat dubbleras, och därmed ta större plats och längre tid att ladda samtidigt som det finns risk att det finns olika versioner av samma data.
Dagens synsätt är något som växt fram under lång tid av många goda tänkare. Ofta kallas Bill Inmon för datalagrets pappa, men innan honom fanns det flera framträdande namn.
Redan på 1960-talet utvecklades termerna dimensioner och fakta i ett gemensamt forskningsprojekt mellan matproducenten General Mills med Dartmouth College.
Sperry Univac lanserade 1975 sin MAPPER (MAintain, Prepare, and Produce Executive Reports), ett databas- och rapportsystem med världens första 4GL. Det är den första plattformen gjord för att bygga Information Centers (föregångare till dagens Data Warehouse).
En annan inflytelserik person är författaren James Martin. Han har skrivit hundratals böcker och kallas ibland 'informationsålderns guru'. Mest känd är han för boken The Wired Society: A Challenge for Tomorrow, som han skrev redan 1977 och som stödde framväxten av beslutsstöd.
Teradata levererade 1983 världens första massivt parallella databasplattform till Wells Fargo, specifikt konstruerad för beslutsstöd.
Forskare som Martyn Richard Jones, Philip Newman, Joseph Bielawski, Bob Richards, Thaluber mfl på Sperry Corporation publicerade 1985 en artikel om Information Centers, där de bla använder termen MAPPER Data Warehouse.
Barry Devlin och Paul Murphy på IBM publicerade 1988 en artikel med konceptet "business data warehouse", vilket innebär en modellarkitektur för flödet av data från operativa källsystem till system för beslutsstöd.
För att särskilja ett datalager, avsett för läsning, från transaktionsdatabasen, avsedd för lagring, ofta kallad för OLTP (On-Line Transaction Processing), etablerades 1993 begreppet OLAP (On-Line Analytical Processing) av E.F. Codd.
Mer: OLAP
Men det är ändå Bill Inmon som har varit mest framträdande inom datalager. Han började definiera och diskutera begreppet Data Warehouse redan på sjuttiotalet, och han har skrivit många artiklar och hållit många kurser om datalager. 1992 publicerade han den första boken om datalager "Building the Data Warehouse", och han höll den första konferensen om datalager tillsammans med Arnie Barnett. Senare idéer från honom är begreppet "DW 2.0", om nästa generation datalager, och CIF, Corporate Information Factory, som beskriver en större informationsarkitektur vari datalagret ryms.
Sedan nittiotalet har dock Ralph Kimball blivit ett minst lika välkänt namn inom datalager med sin bok The Data Warehouse Lifecycle Toolkit från 1996 och med dess senare efterföljare. Hans viktigaste bidrag är att datalagret skall använda en dimensionell modell och att dimensionerna skall vara samordnade.
Inmon anser att datalagret skall vara normaliserat (enligt den tredje normalformen) och inte dimensionellt. Användarna skall sedan ställa frågor och analyser mot mindre dimensionella dataförråd eller semantiska lager istället för mot det stora normaliserade datalagret. Däremot behöver ej dimensionerna vara samordnade i de olika dataförråden. Inmon förespråkar också ett 'top-down' synsätt vid byggandet av datalagret.
Kimball menar istället att hela datalagret skall vara dimensionellt, tillsammans med eventuella dataförråd. Dataförråden är inte lika viktiga med detta synsätt, och kan undvikas helt om svarstiderna i datalagret är tillräckligt bra. Däremot är det viktigt att de dimensioner som används i datalagret skall vara samordnade (conformed).
Med samordnade dimensioner menas att 'intressanta' dimensioner (tex produkter) använder samma attribut och samma summeringar i olika dataförråd. På detta sätt kan ett datalager byggas baserat på mindre dataförråd. Själva kärnan i Kimball's angreppssätt är att datalagret innehåller samordnade dimensionella databaser redo för analys och att användaren kan fråga datalagret direkt. Kimball tycker alltså att en 'bottom-up' synsätt bör användas vid byggandet.
I ett tillräckligt stort datalager är det idag praxis att data lagras normaliserat eftersom det tar mycket mindre plats än dimensionella data. Däremot erbjuds datat till användarna i en dimensionell form i ett semantiskt lager, eftersom den formen är lättare att förstå och använda för dem.
källa: en.wikipedia.org/wiki/Data_warehouse mfl
Både Inmons och Kimballs modeller medför dock en stelhet i arkitekturen. För att råda bot på detta publicerade Dan Linstedt år 2000 ett nytt modelleringskoncept kallat Data Vault. Syftet är att erbjuda långsiktig historisk datalagring från skiftande källsystem med full flexibilitet och spårning av data oberoende av eventuella ändringar i och från källsystemen.
Mer: DV
Bill Inmon definierade ett datalager på följande sätt:
Ett datalager består normalt av följande delar:
En semantiskt lager eller ett dataförråd består av dimensioner och fakta, vilket har en viss granularitet.
En dimension är något som beskriver ett verksamhetsobjekt eller en händelse. Dimensionens namn är normalt ett substantiv. Dimensionen innehåller attribut som beskriver varje medlem i dimensionen.
Fakta är något som mäter en verksamhetsprocess. Dessa mått är normalt numeriska. De kan ofta summeras, men inte alltid. Det betyder inte att alla numeriska värden är fakta, exempelvis produktstorlek är snarare ett attribut i en dimension som beskriver produkten. Faktaraderna är kopplade till de dimensioner som behövs för att beskriva processen. även händelser kan ses som fakta, vilket kan lagras i en s.k. faktalös faktatabell.
Granulariteten är på vilken nivå som faktat lagras. Det blir datalagrets atomära nivå. Rekommendationen är att alltid använda en fin granularitet som möjligt. Alla fakta i en faktatabell måste ha samma granularitet för att kunna summeras.
Ralph Kimball identifierade problemet med skorstensröret (stove pipe). Ett skorstensrör är vad du får när flera olika oberoende system i företaget identifierar och lagrar sina data på olika sätt. Om man försöker koppla ihop dessa system eller använda dessa data direkt i ett datalager får man en onödigt komplicerad lösning.
För att lösa problemet föreslår Kimball att man använder samordnade (conformed) dimensioner. Med samordning menas att 'intressanta' dimensioner (tex produkter) använder samma attribut och samma summeringar i olika dataförråd. Vilket medför att olika dataförråd kan kopplas samman vid behov.
Ett datamodell i form av en snöflinga innebär att dimensionerna är normaliserade. För att beskriva en medlem i en dimension krävs alltså att databasen söker upp medlemmens attribut i ett flertal underliggande dimensionstabeller.
Ett datamodell i form av en stjärna innebär att dimensionerna är helt dimensionella. Det innebär att attributen dubbellagras i dimensionerna, vilket kräver större plats men gör att svarstiden minskar eftersom sökningar undviks. Däremot är faktatabellen fortfarande normaliserad gentemot dimensionerna.En surrogatnyckel är en primärnyckel i en databastabell som inte innehåller någon information. Dess enda syfte är att vara unik. I ett datalager bör man använda surrogatnycklar i alla dimensionstabeller. Om man använder nycklar från underliggande affärssystem bygger man in ett farligt beroende i datalagret, vilket inte har några fördelar alls.
I en datalager är det normalt att vissa dimensioner ändras långsamt. Ibland är det ointressant att spåra ändringarna. Det kan vara kundens hemtelefonnummer som ändrats, och det kan vara helt ointressant att hålla reda på. Då skrivs attributet helt sonika över. Det kallas för en typ 1-ändring.
I andra fall kan det exempelvis vara en kund som flyttar, och då behöver attributet för adress i dimensionen för kunder ändras. Dessa ändringar kan ha betydelse för analysen och då behöver de kunna spåras. Det kan man göra med hjälp av extra kolumner i dimensionen som visar radens aktuella status. Det kallas för en typ 2-ändring.
Teoretiskt finns det även något som kallas för en typ 3-ändring. Det innebär att man helt enkelt lägger till nya attribut, dvs kolumner, för varje ändrat attribut. Det är dock ingen långsiktigt bra lösning och används knappast aldrig i praktiken.
Sidan skapad 10 maj 2007
Uppdaterat 20 januari 2009 (Mer om OLAP)
Uppdaterat 28 augusti 2011 (Semantiskt lager)
Uppdaterat 29 augusti 2014 (Om prestanda)
Uppdaterat 10 oktober 2017 (Mer historik)
Uppdaterat 18 mars 2020 (Data Vault)
Uppdaterat 3 december 2024 (BI+DV till egen sida)
Sammanställt av Christer Tärning.