Datalager - Data warehouse

Datalageröversikt
Den grundläggande arkitekturen för ett datalager

Inom databehandling är ett datalager ( DW eller DWH ), även känt som ett företagsdatalager ( EDW ), ett system som används för rapportering och dataanalys och anses vara en kärnkomponent i business intelligence . DW är centrala arkiv för integrerade data från en eller flera olika källor. De lagrar aktuella och historiska data på en enda plats som används för att skapa analytiska rapporter för arbetare i hela företaget.

Data som lagras på lagret laddas upp från operativsystemen (t.ex. marknadsföring eller försäljning). Data kan passera genom en operativ datalagring och kan kräva datarensning för ytterligare operationer för att säkerställa datakvaliteten innan den används i DW för rapportering.

Extrahera, transformera, ladda (ETL) och extrahera, ladda, transformera (ELT) är de två huvudsakliga metoderna som används för att bygga ett datalagringssystem.

ETL-baserat datalager

Det typiska datalageret för extrahera, transformera, ladda (ETL) använder iscensättning , dataintegration och åtkomstlager för att rymma dess nyckelfunktioner. Iscensättningsskiktet eller iscensättningsdatabasen lagrar rådata extraherad från vart och ett av de olika källdatasystemen. Integrationsskiktet integrerar de olika datauppsättningarna genom att transformera data från iscensättningsskiktet som ofta lagrar dessa transformerade data i en databas för operativ datalagring (ODS). De integrerade data flyttas sedan till ännu en databas, ofta kallad datalagerdatabas, där data är ordnade i hierarkiska grupper, ofta kallade dimensioner, och till fakta och aggregerade fakta. Kombinationen av fakta och dimensioner kallas ibland för ett stjärnschema . Åtkomstskiktet hjälper användare att hämta data.

Dataens huvudsakliga källa rensas , omvandlas, katalogiseras och görs tillgänglig för chefer och andra affärspersonal för datagruvning , analys online , marknadsundersökningar och beslutsstöd . Men medlen för att hämta och analysera data, att extrahera, transformera och ladda data och att hantera dataordlistan anses också vara väsentliga komponenter i ett datalagringssystem. Många referenser till datalager använder detta bredare sammanhang. Således inkluderar en utökad definition för datalagring business intelligence -verktyg , verktyg för att extrahera, transformera och ladda data till förvaret och verktyg för att hantera och hämta metadata .

ELT-baserat datalager

ELT -baserad datavarehusarkitektur

ELT -baserat datalagring blir av med ett separat ETL -verktyg för datatransformation. Istället upprätthåller det ett iscensättningsområde inne i själva datalagret. I detta tillvägagångssätt extraheras data från heterogena källsystem och laddas sedan direkt till datalagret innan någon transformation sker. Alla nödvändiga transformationer hanteras sedan inuti själva datalagret. Slutligen laddas den manipulerade datan in i måltabeller i samma datalager.

Fördelar

Ett datalager behåller en kopia av information från källtransaktionssystemen. Denna arkitektoniska komplexitet ger möjlighet att:

  • Integrera data från flera källor i en enda databas och datamodell. Mer samling data till en enda databas så att en enda sökmotor kan användas för att presentera data i en ODS.
  • Lindra problemet med databasisoleringsnivålåsningskonflikter i transaktionsbehandlingssystem orsakade av försök att köra stora, långvariga analysfrågor i transaktionsbehandlingsdatabaser.
  • Behåll datahistorik , även om källtransaktionssystem inte gör det.
  • Integrera data från flera källsystem, vilket möjliggör en central vy över hela företaget. Denna fördel är alltid värdefull, men särskilt när organisationen har vuxit genom fusion.
  • Förbättra datakvaliteten genom att tillhandahålla konsekventa koder och beskrivningar, flagga eller till och med fixa dålig data.
  • Presentera organisationens information konsekvent.
  • Ge en enda gemensam datamodell för alla data av intresse oavsett datakällan.
  • Omstrukturera data så att det är vettigt för affärsanvändarna.
  • Omstrukturera data så att de levererar utmärkt sökresultat, även för komplexa analytiska frågor, utan att påverka operativsystemen .
  • Tillför värde till operativa affärsapplikationer, särskilt CRM -system ( Customer Relationship Management ).
  • Gör frågor om beslutsstöd lättare att skriva.
  • Organisera och avgränsa repetitiva data

Generisk

Miljön för datalager och marts inkluderar följande:

  • Källsystem som tillhandahåller data till lagret eller kartan;
  • Dataintegrationsteknik och processer som behövs för att förbereda data för användning;
  • Olika arkitekturer för lagring av data i en organisations datalager eller datamart;
  • Olika verktyg och applikationer för en mängd olika användare;
  • Metadata, datakvalitet och styrprocesser måste finnas på plats för att säkerställa att lagret eller varukorgen uppfyller dess syften.

När det gäller källsystem som anges ovan säger R. Kelly Rainer, "En vanlig källa för data i datalager är företagets operativa databaser, som kan vara relationsdatabaser".

När det gäller dataintegration säger Rainer: "Det är nödvändigt att extrahera data från källsystem, transformera dem och ladda dem till en datakarta eller lager".

Rainer diskuterar lagring av data i en organisations datalager eller data marts.

Metadata är data om data. "IT -personal behöver information om datakällor, databas-, tabell- och kolumnnamn, uppdatera scheman och åtgärder för dataanvändning".

Idag är de mest framgångsrika företagen de som snabbt och flexibelt kan reagera på marknadsförändringar och möjligheter. En nyckel till detta svar är effektiv och effektiv användning av data och information från analytiker och chefer. Ett "datalager" är ett arkiv med historisk data som organiseras av ämnet för att stödja beslutsfattare i organisationen. När data har lagrats i en datakarta eller ett lager kan den nås.

Relaterade system (data mart, OLAPS, OLTP, prediktiv analys)

En data mart är en enkel form av ett datalager som är inriktat på ett enda ämne (eller funktionellt område), och därför hämtar de data från ett begränsat antal källor som försäljning, finansiering eller marknadsföring. Datamartar byggs och kontrolleras ofta av en enda avdelning inom en organisation. Källorna kan vara interna operativsystem, ett centralt datalager eller extern data. Denormalisering är normen för datamodelleringstekniker i detta system. Med tanke på att data marts i allmänhet endast täcker en delmängd av data som finns i ett datalager, är de ofta enklare och snabbare att implementera.

Skillnad mellan datalager och datamart
Attribut Datalager Datamart
Dataens omfattning företagsövergripande avdelningsövergripande
Antal ämnesområden flera olika enda
Hur svårt att bygga svår lätt
Hur lång tid tar det att bygga Mer mindre
Mängden minne större begränsad

Typer av datamart inkluderar beroende , oberoende och hybriddatamart.

Online analytisk bearbetning (OLAP) kännetecknas av en relativt låg transaktionsvolym. Frågor är ofta mycket komplexa och involverar aggregeringar. För OLAP -system är svarstid en effektiv åtgärd. OLAP -applikationer används i stor utsträckning av Data Mining -tekniker. OLAP-databaser lagrar aggregerade, historiska data i flerdimensionella scheman (vanligtvis stjärnscheman ). OLAP -system har vanligtvis en datalatens på några timmar, i motsats till datamart, där latens förväntas vara närmare en dag. OLAP -metoden används för att analysera flerdimensionella data från flera källor och perspektiv. De tre grundläggande verksamheterna i OLAP är Roll-up (Consolidation), Drill-down och Slicing & Dicing.

Online transaktionsbehandling (OLTP) kännetecknas av ett stort antal korta onlinetransaktioner (INSERT, UPDATE, DELETE). OLTP-system betonar mycket snabb frågebehandling och upprätthållande av dataintegritet i miljöer med flera åtkomst. För OLTP -system mäts effektiviteten med antalet transaktioner per sekund. OLTP -databaser innehåller detaljerade och aktuella data. Schemat som används för att lagra transaktionsdatabaser är entitetsmodellen (vanligtvis 3NF ). Normalisering är normen för datamodelleringstekniker i detta system.

Prediktiv analys handlar om att hitta och kvantifiera dolda mönster i data med hjälp av komplexa matematiska modeller som kan användas för att förutsäga framtida utfall. Prediktiv analys skiljer sig från OLAP genom att OLAP fokuserar på historisk dataanalys och är reaktiv till sin natur, medan prediktiv analys fokuserar på framtiden. Dessa system används också för hantering av kundrelationer (CRM).

Historia

Begreppet datalagring går tillbaka till slutet av 1980 -talet då IBM -forskarna Barry Devlin och Paul Murphy utvecklade "affärsdatalager". I huvudsak var datalagringskonceptet avsett att ge en arkitektonisk modell för flödet av data från operativsystem till beslutsstödsmiljöer . Konceptet försökte ta itu med de olika problemen som är förknippade med detta flöde, främst de höga kostnaderna som är förknippade med det. I avsaknad av en datalagerarkitektur krävdes en enorm mängd redundans för att stödja flera beslutsstödsmiljöer. I större företag var det typiskt för flera beslutsstödsmiljöer att arbeta självständigt. Även om varje miljö tjänade olika användare, krävde de ofta mycket av samma lagrade data. Processen att samla in, rengöra och integrera data från olika källor, vanligtvis från långsiktiga befintliga operativsystem (vanligtvis kallade äldre system ), replikerades vanligtvis delvis för varje miljö. Dessutom granskades de operativa systemen ofta när nya krav på beslutsstöd uppstod. Ofta krävde nya krav att samla in, städa och integrera nya data från " data marts " som var skräddarsydda för att användare ska kunna komma åt dem.

Dessutom, med publiceringen av The IRM Imperative (Wiley & Sons, 1991) av James M. Kerr, blev idén att hantera och sätta ett dollarvärde på en organisations dataresurser och sedan rapportera det värdet som en tillgång i en balansräkning populär . I boken beskrev Kerr ett sätt att fylla ämnesområdedatabaser från data som härrör från transaktionsdrivna system för att skapa ett lagringsområde där sammanfattande data kan utnyttjas ytterligare för att informera beslutsfattande från ledningen. Detta koncept främjade ytterligare tänkande av hur ett datalager kan utvecklas och hanteras på ett praktiskt sätt inom alla företag.

Viktiga utvecklingar under de första åren av datalagring:

  • 1960 -talet - General Mills och Dartmouth College , i ett gemensamt forskningsprojekt, utvecklar termerna dimensioner och fakta .
  • 1970 -talet - ACNielsen och IRI tillhandahåller måttdatamart för detaljhandel.
  • 1970 -talet - Bill Inmon börjar definiera och diskutera termen Data Warehouse.
  • 1975 - Sperry Univac introducerar MAPPER (MAintain, Prepare, and Producing Executive Reports), ett databashanterings- och rapporteringssystem som innehåller världens första 4GL . Det är den första plattformen som är utformad för att bygga informationscenter (en föregångare till modern datalagerteknik).
  • 1983 - Teradata introducerar databasdatorn DBC/1012 speciellt utformad för beslutsstöd.
  • 1984 - Metaphor Computer Systems , grundat av David Liddle och Don Massaro, släpper ett hårdvaru-/mjukvarupaket och GUI för affärsanvändare att skapa ett databashanterings- och analyssystem.
  • 1985 - Sperry Corporation publicerar en artikel (Martyn Jones och Philip Newman) om informationscenter, där de introducerar termen MAPPER data warehouse i samband med informationscentra.
  • 1988 - Barry Devlin och Paul Murphy publicerar artikeln "En arkitektur för ett affärs- och informationssystem" där de introducerar termen "affärsdatalager".
  • 1990 - Red Brick Systems, grundat av Ralph Kimball , introducerar Red Brick Warehouse, ett databashanteringssystem specifikt för datalager.
  • 1991 - James M. Kerr författare IRM Imperative, som föreslår att dataresurser skulle kunna redovisas som en tillgång i en balansräkning, vilket främjar kommersiellt intresse för etablering av datalager.
  • 1991 - Prism Solutions, grundat av Bill Inmon , introducerar Prism Warehouse Manager, programvara för att utveckla ett datalager.
  • 1992 - Bill Inmon ger ut boken Building the Data Warehouse .
  • 1995-Data Warehousing Institute, en vinstdrivande organisation som främjar datalagring, grundas.
  • 1996 - Ralph Kimball ger ut boken The Data Warehouse Toolkit .
  • 2000- Dan Linstedt släpper i allmänhet datavalvmodelleringen , tänkt 1990 som ett alternativ till Inmon och Kimball för att tillhandahålla långsiktig historisk lagring av data som kommer in från flera operativa system, med tonvikt på spårning, revision och motståndskraft mot förändringar av källdatamodellen.
  • 2008- Bill Inmon , tillsammans med Derek Strauss och Genia Neushloss, publicerar "DW 2.0: The Architecture for the Next Generation of Data Warehousing", som förklarar hans top-down-strategi för datalagring och myntar begreppet datavarehus 2.0.
  • 2012 - Bill Inmon utvecklar och gör offentlig teknik känd som "textdisambiguering". Textdisambiguering tillämpar kontext på råtext och omformaterar råtexten och kontexten till ett standarddatabasformat. När rå text har passerat genom textdisambiguering kan den enkelt och effektivt nås och analyseras med standard business intelligence -teknik. Textdisambiguering åstadkommes genom exekvering av textuell ETL. Textdisambiguering är användbar varhelst rå text finns, till exempel i dokument, Hadoop, e -post och så vidare.

Informationslagring

Fakta

Ett faktum är ett värde eller mätning, som representerar ett faktum om den hanterade enheten eller systemet.

Fakta, som rapporterats av den rapporterande enheten, sägs vara på rånivå; t.ex. i ett mobiltelefonsystem, om en BTS ( basöverföringsstation ) tar emot 1 000 förfrågningar om trafikkanalstilldelning, tilldelar 820 och avvisar de återstående, skulle den rapportera tre fakta eller mätningar till ett ledningssystem:

  • tch_req_total = 1000
  • tch_req_success = 820
  • tch_req_fail = 180

Fakta på rånivå aggregeras vidare till högre nivåer i olika dimensioner för att extrahera mer service eller affärsrelevant information från den. Dessa kallas aggregat eller sammanfattningar eller aggregerade fakta.

Om det till exempel finns tre BTS i en stad, kan fakta ovan aggregeras från BTS till stadsnivå i nätverksdimensionen. Till exempel:

  • tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
  • avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3

Dimensionellt kontra normaliserat tillvägagångssätt för lagring av data

Det finns tre eller flera ledande tillvägagångssätt för att lagra data i ett datalager - de viktigaste tillvägagångssätten är det dimensionella tillvägagångssättet och det normaliserade tillvägagångssättet.

Det dimensionella tillvägagångssättet hänvisar till Ralph Kimballs tillvägagångssätt där det anges att datalageret ska modelleras med ett schema för dimensionell modell/ stjärna . Det normaliserade tillvägagångssättet, även kallat 3NF -modellen (Third Normal Form), hänvisar till Bill Inmons tillvägagångssätt där det anges att datalagret ska modelleras med en ER -modell/normaliserad modell.

Dimensionellt tillvägagångssätt

I en dimensions tillvägagångssätt , transaktionsdata är uppdelat i "fakta", vilka i allmänhet numeriska transaktionsdata, och " dimensioner ", som är den referensinformation som ger sammanhang till fakta. Till exempel kan en försäljningstransaktion delas upp i fakta som antalet beställda produkter och det totala priset som betalats för produkterna, och i dimensioner som beställningsdatum, kundnamn, produktnummer, beställning leverans till och fakturering till platser och säljaren ansvarig för att ta emot beställningen.

En viktig fördel med ett dimensionellt tillvägagångssätt är att datalagret är lättare för användaren att förstå och använda. Hämtning av data från datalagret tenderar också att fungera mycket snabbt. Dimensionsstrukturer är lätta att förstå för affärsanvändare, eftersom strukturen är indelad i mått/fakta och sammanhang/dimensioner. Fakta är relaterade till organisationens affärsprocesser och operativa system medan dimensionerna kring dem innehåller sammanhang om mätningen (Kimball, Ralph 2008). En annan fördel med dimensionell modell är att den inte involverar en relationsdatabas varje gång. Således är denna typ av modelleringsteknik mycket användbar för slutanvändarfrågor i datalager.

Modellen av fakta och dimensioner kan också förstås som en datakub . Där dimensionerna är de kategoriska koordinaterna i en flerdimensionell kub, är faktum ett värde som motsvarar koordinaterna.

De främsta nackdelarna med den dimensionella metoden är följande:

  1. För att upprätthålla integriteten hos fakta och dimensioner är det komplicerat att ladda datalagret med data från olika operativsystem.
  2. Det är svårt att ändra datalagerstrukturen om organisationen som använder måttsättet förändrar sättet att göra affärer.

Normaliserat tillvägagångssätt

I det normaliserade tillvägagångssättet lagras data i datalagret enligt i viss mån databasnormaliseringsregler . Tabeller grupperas efter ämnesområden som återspeglar allmänna datakategorier (t.ex. data om kunder, produkter, ekonomi etc.). Den normaliserade strukturen delar upp data i enheter, vilket skapar flera tabeller i en relationsdatabas. När det tillämpas i stora företag är resultatet dussintals tabeller som är sammanlänkade med ett nätverk av kopplingar. Vidare konverteras var och en av de skapade enheterna till separata fysiska tabeller när databasen implementeras (Kimball, Ralph 2008). Den största fördelen med detta tillvägagångssätt är att det är enkelt att lägga till information i databasen. Några nackdelar med detta tillvägagångssätt är att det på grund av antalet inblandade tabeller kan vara svårt för användare att koppla ihop data från olika källor till meningsfull information och få tillgång till informationen utan en exakt förståelse av datakällorna och datastrukturen. av datalagret.

Både normaliserade och dimensionella modeller kan representeras i enhetsrelationsdiagram eftersom båda innehåller sammanfogade relationstabeller. Skillnaden mellan de två modellerna är graden av normalisering (även känd som Normal Forms ). Dessa tillvägagångssätt utesluter inte varandra, och det finns andra metoder. Dimensionella tillvägagångssätt kan innebära normalisering av data till en viss grad (Kimball, Ralph 2008).

I Informations-Driven Business , Robert Hillard föreslår en metod för att jämföra de två metoder baserade på behov av verksamheten problemet informations. Tekniken visar att normaliserade modeller har mycket mer information än deras dimensionella ekvivalenter (även när samma fält används i båda modellerna) men denna extra information kostar användbarheten. Tekniken mäter informationsmängden när det gäller informationsentropi och användbarhet när det gäller Small Worlds -datatransformationsmåttet.

Designmetoder

Nedifrån och upp design

I bottom-up metod data marts först skapats för att ge rapportering och analysmöjligheter för specifik affärsprocesser . Dessa datamart kan sedan integreras för att skapa ett omfattande datalager. Datalagerbussarkitekturen är främst en implementering av "bussen", en samling av överensstämda dimensioner och överensstämda fakta , som är dimensioner som delas (på ett specifikt sätt) mellan fakta i två eller flera datamartar.

Top-down design

Den top-down strategi är utformad med hjälp av en normaliserad företag datamodell . "Atom" data , det vill säga data på största detaljnivå, lagras i datalagret. Dimensionella datamärken som innehåller data som behövs för specifika affärsprocesser eller specifika avdelningar skapas från datalagret.

Hybrid design

Datalager (DW) liknar ofta nav- och ekrarna . Äldre system som matar lagret inkluderar ofta kundrelationshantering och företagsresursplanering , vilket genererar stora mängder data. För att konsolidera dessa olika datamodeller och underlätta extraktomvandlingsbelastningsprocessen använder datalager ofta en operativ datalagring , från vilken informationen analyseras i det faktiska DW. För att minska dataredundans lagrar större system ofta data på ett normaliserat sätt. Datamart för specifika rapporter kan sedan byggas ovanpå datalagret.

En hybrid DW -databas hålls på tredje normala form för att eliminera dataredundans . En normal relationsdatabas är dock inte effektiv för business intelligence -rapporter där dimensionell modellering är vanlig. Små datamärken kan handla data från det konsoliderade lagret och använda den filtrerade, specifika data för faktatabellerna och dimensionerna som krävs. DW tillhandahåller en enda informationskälla från vilken datamartarna kan läsa, och tillhandahåller ett brett utbud av företagsinformation. Hybrid arkitekturen gör en DW bytas ut mot en Master Data Management arkiv där drift (inte statisk) information skulle kunna uppehålla sig.

De data som valvmodellerings komponenter följer nav och ekrar arkitektur. Denna modellstil är en hybriddesign, som består av bästa praxis från både tredje normala form och stjärnschema . Datavalvmodellen är inte en riktig tredje normalform och bryter mot några av dess regler, men det är en top-down-arkitektur med en bottom-up-design. Datavalvmodellen är inriktad på att vara strikt ett datalager. Det är inte inriktat på att vara tillgängligt för slutanvändare, vilket, när det byggs, fortfarande kräver användning av en data-mart eller stjärnschema-baserat utgivningsområde för affärsändamål.

Datalageregenskaper

Det finns grundläggande funktioner som definierar data i datalagret som inkluderar ämnesorientering, dataintegration, tidsvariant, icke-flyktig data och datagranularitet.

Ämnesorienterad

Till skillnad från operativsystemen kretsar data i datalagret kring företagets ämnen. Ämnesorientering är inte databasnormalisering . Ämnesorientering kan verkligen vara användbar för beslutsfattande. Att samla de nödvändiga objekten kallas ämnesorienterat.

Integrerad

Data som finns i datalagret är integrerad. Eftersom det kommer från flera operativsystem måste alla inkonsekvenser tas bort. Konsistenser inkluderar namnkonventioner, mätning av variabler, kodningsstrukturer, fysiska attribut för data och så vidare.

Tidsvariant

Medan operativa system återspeglar nuvarande värden när de stöder den dagliga verksamheten, representerar datalagerdata en lång tidshorisont (upp till 10 år) vilket innebär att den lagrar mest historiska data. Det är huvudsakligen avsett för datamining och prognoser. (Till exempel om en användare söker efter ett köpmönster för en specifik kund måste användaren titta på data om nuvarande och tidigare köp.)

Ej flyktigt

Data i datalagret är skrivskyddade, vilket innebär att de inte kan uppdateras, skapas eller raderas (om det inte finns en lagstadgad eller lagstadgad skyldighet att göra det).

Alternativ för datalager

Aggregering

I datalagringsprocessen kan data aggregeras i datamart på olika abstraktionsnivåer. Användaren kan börja titta på de totala försäljningsenheterna för en produkt i en hel region. Sedan tittar användaren på staterna i den regionen. Slutligen kan de undersöka de enskilda butikerna i ett visst tillstånd. Därför börjar analysen vanligtvis på en högre nivå och går ner till lägre detaljeringsnivåer.

Datalagerarkitektur

De olika metoderna som används för att konstruera/organisera ett datalager som specificeras av en organisation är många. Hårdvaran som används, programvaran skapad och dataresurser som specifikt krävs för korrekt datalagrings funktion är huvudkomponenterna i datalagerarkitekturen. Alla datalager har flera faser där organisationens krav ändras och finjusteras.

Motsatt operativsystem

Operativa system är optimerade för bevarande av dataintegritet och snabbhet för registrering av affärer genom användning av databasnormalisering och en enhetsrelationsmodell . Operativa systemdesigners följer i allmänhet Codds 12 regler för databasnormalisering för att säkerställa dataintegritet. Fullt normaliserade databasdesigner (det vill säga dem som uppfyller alla Codd -regler) resulterar ofta i att information från en affärskontakt lagras i dussintals till hundratals tabeller. Relationsdatabaser är effektiva för att hantera relationerna mellan dessa tabeller. Databaserna har mycket snabb infoga/uppdatera prestanda eftersom endast en liten mängd data i dessa tabeller påverkas varje gång en transaktion behandlas. För att förbättra prestanda rensas vanligtvis äldre data regelbundet från operativsystem.

Datalager är optimerade för analytiska åtkomstmönster. Analytiska åtkomstmönster innebär i allmänhet att man väljer specifika fält och sällan om någonsin select *, vilket väljer alla fält/kolumner, vilket är vanligare i operativa databaser. På grund av dessa skillnader i åtkomstmönster drar operativa databaser (löst, OLTP) nytta av användningen av ett radorienterat DBMS medan analysdatabaser (löst, OLAP) drar nytta av användningen av ett kolumnorienterat DBMS . Till skillnad från operativsystem som upprätthåller en ögonblicksbild av verksamheten, har datalager i allmänhet en oändlig historia som implementeras genom ETL -processer som periodiskt migrerar data från operativsystemen över till datalagret.

Evolution i organisationsanvändning

Dessa termer avser nivån på sofistikering av ett datalager:

Offline operativ datalager
Datalager i detta utvecklingsstadium uppdateras regelbundet (vanligtvis dagligen, veckovis eller månadsvis) från operativsystemen och data lagras i en integrerad rapporteringsorienterad databas.
Offline datalager
Datalager i detta skede uppdateras regelbundet från data i operativsystemen och datalagerdata lagras i en datastruktur som är utformad för att underlätta rapportering.
Datalager i tid
Online Integrated Data Warehousing representerar realtidsdatalagerets stegdata i lagret uppdateras för varje transaktion som utförs på källdata
Integrerat datalager
Dessa datalager samlar in data från olika affärsområden, så att användare kan leta upp den information de behöver i andra system.

Referenser

Vidare läsning