Vad är ETL-process (extrahera, transformera, ladda) i datalager?

what is etl extract

Denna fördjupade handledning om ETL-processen förklarar processflöde och steg som är involverade i ETL-processen (extraktion, transformation och belastning) i datalager:

Denna handledning i serien förklarar: Vad är ETL-process? Dataextraktion, transformation, laddning, platta filer, vad är iscenesättning? ETL-cykel, etc.

Låt oss börja!!

=> Kolla in den perfekta utbildningsguiden för datalager här.

Vad du kommer att lära dig:

• ETL (Extract, Transform, Load) Process Fundamentals
  • Vad är ETL-process i datalager?
  • Datautvinning
    • Extraktionsmetoder i datalager
    • Extrahera ändrade data
  • Datatransformation
    • Hur implementerar jag transformation?
  • Data laddas
  • Platta filer
    • Bearbetar fasta filer med fast längd
    • Bearbetar avgränsade platta filer
  • Syfte med iscensättningsområdet
  • Designa Staging Area
  • ETL-processflöde
• Slutsats
  • Rekommenderad läsning

ETL (Extract, Transform, Load) Process Fundamentals

Målgrupp

• Datalager / ETL-utvecklare och testare.
• Databasproffs med grundläggande kunskap om databaskoncept.
• Databasadministratörer / big data-experter som vill förstå datalager / ETL-områden.
• Högskoleexaminerade / nybörjare som letar efter datalagerjobb.

Vad är ETL-process i datalager?

Vi vet alla att datalager är en samling av enorma datamängder för att ge information till affärsanvändarna med hjälp av Business Intelligence-verktyg.

För att tjäna detta ändamål bör DW laddas med jämna mellanrum. Data i systemet samlas in från ett eller flera operativa system, platta filer etc. Processen som tar data till DW kallas ETL Process . Extraktion, transformation och laddning är ETL: s uppgifter.

# 1) Extraktion: Alla föredragna data från olika källsystem som databaser, applikationer och platta filer identifieras och extraheras. Datautvinning kan slutföras genom att köra jobb under icke-öppettider.

# 2) Transformation: De flesta extraherade data kan inte laddas direkt in i målsystemet. Baserat på affärsreglerna kan vissa omvandlingar göras innan data laddas.

Till exempel, en målkolonndata kan förvänta sig att två källkolumner sammanfogade data som inmatning. På samma sätt kan det finnas komplex logik för datatransformation som behöver expertis. Vissa data som inte behöver någon omvandling kan flyttas direkt till målsystemet.

Transformationsprocessen korrigerar också data, tar bort eventuella felaktiga data och fixar eventuella fel i data innan de laddas.

# 3) Laddar: All den samlade informationen laddas i måldatalagertabellerna.

Datautvinning

Datautvinning spelar en viktig roll i utformningen av ett framgångsrikt DW-system. Olika källsystem kan ha olika egenskaper hos data, och ETL-processen kommer att hantera dessa skillnader effektivt samtidigt som data extraheras.

' Logisk datakarta ”Är ett basdokument för datautvinning. Detta visar vilka källdata som ska gå till vilken måltabell och hur källfältet mappas till respektive måltabellfält i ETL-processen.

Nedan följer stegen som ska utföras under utformningen av logiska datakartor:

• En datalagerarkitekt utformar det logiska datakartdokumentet.
• Genom att hänvisa till detta dokument skapar ETL-utvecklaren ETL-jobb och ETL-testare skapar testfall.
• Alla specifika datakällor och respektive dataelement som stöder affärsbesluten kommer att nämnas i detta dokument. Dessa dataelement fungerar som ingångar under utvinningsprocessen.
• Data från alla källsystem analyseras och alla typer av dataavvikelser dokumenteras så att detta hjälper till att utforma rätt affärsregler för att sluta extrahera fel data till DW. Sådana uppgifter avvisas här.
• När den slutliga käll- och måldatamodellen har designats av ETL-arkitekterna och affärsanalytikerna kan de gå igenom med ETL-utvecklarna och testarna. Genom detta kommer de att få en tydlig förståelse för hur affärsreglerna ska utföras i varje fas av extraktion, transformation och laddning.
• Genom att gå igenom kartläggningsreglerna från detta dokument bör ETL-arkitekter, utvecklare och testare ha en god förståelse för hur data flyter från varje tabell som dimensioner, fakta och andra tabeller.
• Varje typ av datain manipuleringsregler eller formler nämns också här för att undvika extrahering av fel data. Till exempel, extrahera endast de senaste 40 dagarna av data, etc.
• Det är ETL-teamets ansvar att gå igenom informationen enligt företagets krav, att ta fram alla användbara källsystem, tabeller och kolumndata som ska laddas in i DW.

Logiskt datakartdokument är i allmänhet ett kalkylblad som visar följande komponenter:

Extraktionsflödesdiagram:

Ange tidsfönstret för att köra jobben till varje källsystem i förväg, så att ingen källinformation skulle missas under extraktionscykeln.

Med ovanstående steg uppnår extraktionen målet att konvertera data från olika format från olika källor till ett enda DW-format, vilket gynnar hela ETL-processerna. Sådana logiskt placerade data är mer användbara för bättre analys.

Extraktionsmetoder i datalager

Beroende på käll- och måldatamiljöer och affärsbehov kan du välja den extraktionsmetod som passar din DW.

# 1) Logiska extraktionsmetoder

Datautvinning i ett datalagersystem kan vara en engångsfull belastning som görs initialt (eller) det kan vara inkrementella belastningar som uppstår varje gång med konstanta uppdateringar.

youtube till mp3 längre än 90 minuter

• Full extraktion: Som själva namnet antyder extraheras källsystemets data helt till måltabellen. Varje gång denna typ av extraktion laddar hela aktuella källsystemdata utan att beakta de senast extraherade tidsstämplarna. Företrädesvis kan du använda fullständig extraktion för de initiala lasterna eller tabeller med färre data.
• Inkrementell extraktion: Uppgifterna som läggs till / ändras från ett visst datum kommer att övervägas för inkrementell extraktion. Detta datum är affärsspecifikt som senast extraherade datum (eller) sista orderdatum etc. Vi kan hänvisa till en tidsstämpelkolumn från själva källtabellen (eller) en separat tabell kan skapas för att endast spåra detaljerna för extraktionsdatum. Att hänvisa till tidsstämpeln är en viktig metod under inkrementell extraktion. Logik utan tidsstämpel kan misslyckas om DW-tabellen har stora data.

# 2) Fysiska extraktionsmetoder

Beroende på källsystemens kapacitet och begränsningar av data kan källsystemen tillhandahålla informationen fysiskt för extraktion som online-extraktion och offline-extraktion. Detta stöder någon av de logiska extraktionstyperna.

• Online-extraktion :: Vi kan direkt ansluta till alla källsystemsdatabaser med anslutningssträngarna för att extrahera data direkt från källsystemstabellerna.
• Offline extraktion :: Vi ansluter inte direkt till källsystemets databas här, utan källsystemet tillhandahåller data uttryckligen i en fördefinierad struktur. Källsystem kan tillhandahålla data i form av platta filer, dumpfiler, arkivloggar och tabellutrymmen.

ETL-verktyg är bäst lämpade för att utföra komplexa dataextraktioner, valfritt antal gånger för DW, även om de är dyra.

Extrahera ändrade data

När den initiala belastningen är klar är det viktigt att överväga hur man extraherar data som ändras från källsystemet ytterligare. ETL-processteamet bör utforma en plan för hur man implementerar extraktion för de initiala lasterna och de inkrementella belastningarna i början av själva projektet.

För det mesta kan du överväga strategin 'Granskningskolumner' för den stegvisa belastningen för att fånga dataändringarna. Generellt kan källsystemstabellerna innehålla granskningskolumner som lagrar tidsstämpeln för varje infogning (eller) modifiering.

Tidsstämpeln kan fyllas i av databasutlösare (eller) från själva applikationen. Du måste säkerställa noggrannheten i granskningskolonnernas data, även om de laddas på något sätt, för att inte missa de ändrade uppgifterna för stegvis belastning.

Under den inkrementella belastningen kan du ta hänsyn till det maximala datumet och tiden för den senaste belastningen och hämta alla data från källsystemet med tidsstämpeln större än den senaste belastningstidsstämpeln.

När du extraherar data:

• Använd frågor optimalt för att bara hämta de data du behöver.
• Använd inte Distinct-klausulen mycket eftersom det sänker sökfrågan.
• Använd SET-operatörer som Union, Minus, Intersect försiktigt eftersom det försämrar prestanda.
• Använd jämförelse nyckelord som liknande, mellan, etc i var sats, snarare än funktioner som substr (), to_char (), etc.

Datatransformation

Transformation är processen där en uppsättning regler tillämpas på extraherad data innan källsystemets data laddas direkt till målsystemet. De extraherade uppgifterna betraktas som rådata.

Omvandlingsprocessen med en uppsättning standarder ger all olik data från olika källsystem till användbar data i DW-systemet. Datatransformering syftar till datakvaliteten. Du kan hänvisa till dokumentet för mappning av data för alla logiska omvandlingsregler.

Baserat på transformationsreglerna om någon källinformation inte uppfyller instruktionerna, avvisas sådan källinformation innan den laddas in i mål-DW-systemet och placeras i en avvisningsfil eller avvisande tabell.

Transformationsreglerna anges inte för data för kolumner med rak belastning (behöver inte ändras) från källa till mål. Därför kan datatransformationer klassificeras som enkla och komplexa. Datatransformationer kan innebära kolumnkonverteringar, omformatering av datastruktur etc.

Nedan följer några av de uppgifter som ska utföras under datatransformation:

# 1) Val: Du kan välja antingen hela tabelldata eller en specifik uppsättning kolumndata från källsystemen. Valet av data slutförs vanligtvis vid själva extraktionen.

Det kan finnas fall där källsystemet inte tillåter att välja en specifik uppsättning kolumndata under extraktionsfasen, sedan extrahera hela data och göra valet i transformationsfasen.

# 2) Delning / sammanfogning: Du kan manipulera den valda informationen genom att dela eller ansluta den. Du kommer att bli ombedd att dela upp den valda källdata ännu mer under transformationen.

Till exempel, om hela adressen är lagrad i ett enda stort textfält i källsystemet, kan DW-systemet be att dela upp adressen i separata fält som en stad, stat, postnummer etc. Detta är enkelt för indexering och analys baserat på varje komponent individuellt.

Medan sammanfogning / sammanslagning av två eller flera kolumner används data i stor utsträckning under transformationsfasen i DW-systemet. Detta betyder inte att man slår samman två fält i ett enda fält.

Till exempel, om information om en viss enhet kommer från flera datakällor, kan insamling av informationen som en enda enhet kallas för att sammanfoga / slå samman data.

# 3) Konvertering: De extraherade källsystemets data kan vara i olika format för varje datatyp, all all den extraherade informationen bör därför konverteras till ett standardiserat format under transformationsfasen. Samma typ av format är lätt att förstå och lätt att använda för affärsbeslut.

# 4) Sammanfattning: I vissa situationer kommer DW att leta efter sammanfattade data snarare än detaljerade data på låg nivå från källsystemen. Eftersom data på låg nivå inte är bäst lämpade för analys och frågor av företagsanvändare.

Till exempel, försäljningsdata för varje utcheckning kanske inte krävs av DW-systemet, daglig försäljning av biprodukt (eller) daglig försäljning av butiken är användbar. Därför kan sammanfattning av data utföras under omvandlingsfasen enligt företagets krav.

# 5) Berikning: När en DW-kolumn bildas genom att kombinera en eller flera kolumner från flera poster, kommer datarikning att ordna om fälten för en bättre bild av DW-systemet.

# 6) Formatera versioner: Formatrevisioner sker oftast under transformationsfasen. Datatypen och dess längd revideras för varje kolumn.

Till exempel, en kolumn i ett källsystem kan vara numeriskt och samma kolumn i ett annat källsystem kan vara en text. För att standardisera detta ändras datatypen för denna kolumn till transform under transformationsfasen.

# 7) Avkodning av fält: När du extraherar data från flera källsystem kan data i olika system avkodas annorlunda.

Till exempel, ett källsystem kan representera kundstatus som AC, IN och SU. Ett annat system kan representera samma status som 1, 0 och -1.

Under datatransformationsfasen måste du avkoda sådana koder till korrekta värden som är förståliga för företagsanvändarna. Följaktligen kan ovanstående koder ändras till Aktiv, Inaktiv och Avstängd.

# 8) Beräknade och härledda värden: Genom att överväga källsystemets data kan DW lagra ytterligare kolumndata för beräkningarna. Du måste göra beräkningarna baserat på affärslogiken innan du lagrar den i DW.

# 9) Konvertering av datum / tid: Detta är en av de viktigaste datatyperna att koncentrera sig på. Datum- / tidsformatet kan skilja sig åt i flera källsystem.

Till exempel, en källa kan lagra datumet som den 10 november 1997. En annan källa kan lagra samma datum i 11/10/1997-format. Följaktligen, under datatransformationen, bör alla datum / tidvärden konverteras till ett standardformat.

# 10) Av duplicering: Om källsystemet har dubbla poster, se till att endast en post laddas till DW-systemet.

Transformationsflödesdiagram:

Hur implementerar jag transformation?

Beroende på komplexiteten i datatransformationer kan du använda manuella metoder, transformationsverktyg (eller) kombination av båda, vilket som är effektivt.

# 1) Manuella tekniker

Manuella tekniker är tillräckliga för små DW-system. Dataanalytiker och utvecklare kommer att skapa program och skript för att omvandla data manuellt. Denna metod kräver detaljerad testning för varje del av koden.

Underhållskostnaden kan bli hög på grund av de förändringar som sker i affärsregler (eller) på grund av chansen att få fel med ökningen av datamängder. Du bör ta hand om metadata från början och även med varje förändring som sker i transformationsreglerna.

# 2) Transformationsverktyg

Om du vill automatisera det mesta av omvandlingsprocessen kan du anta omvandlingsverktygen beroende på budget och tidsram för projektet. Medan du automatiserar bör du lägga god kvalitet på att välja verktyg, konfigurera, installera och integrera dem med DW-systemet.

Praktiskt taget Fullständig omvandling med verktygen i sig är inte möjlig utan manuellt ingripande. Men de data som transformeras av verktygen är verkligen effektiva och korrekta.

För att uppnå detta bör vi ange rätt parametrar, datadefinitioner och regler i transformationsverktyget som input. Från de angivna ingångarna registrerar verktyget själva metadata och denna metadata läggs till i den totala DW-metadata.

Om det finns några ändringar i affärsreglerna, skriv bara in dessa ändringar i verktyget, resten av transformationsändringarna kommer att tas om hand av verktyget själv. Därför är en kombination av båda metoderna effektiv att använda.

Data laddas

Extraherad och transformerad data laddas in i mål-DW-tabellerna under Load-fasen i ETL-processen. Verksamheten bestämmer hur laddningsprocessen ska ske för varje tabell.

Lastningsprocessen kan ske på följande sätt:

• Initial belastning: Läser in data för att fylla i respektive DW-tabeller för första gången.
• Inkrementell belastning: När DW-tabellerna har laddats tillämpas resten av de pågående ändringarna regelbundet.
• Full uppdatering: Om några tabeller som används behöver uppdateras, tas nuvarande data från den tabellen bort och laddas om. Omladdning liknar den ursprungliga belastningen.

Titta på exemplet nedan för bättre förståelse för laddningsprocessen i ETL:

# 1) Under den första belastningen säljs data som säljs den 3^rdJuni 2007 laddas in i DW-måltabellen eftersom det är de ursprungliga uppgifterna från ovanstående tabell.

#två) Under den inkrementella belastningen måste vi ladda data som säljs efter 3^rdJuni 2007. Vi bör överväga alla poster med det sålda datumet större än (>) föregående datum för nästa dag. Därför den 4^thJuni 2007, hämta alla skivor med såld datum> 3^rdJuni 2007 genom att använda frågor och ladda endast de två posterna från tabellen ovan.

Den 5^thJuni 2007, hämta alla skivor med såld datum> 4^thJuni 2007 och laddar bara en post från ovanstående tabell.

# 3) Under Full uppdatering laddas alla ovanstående tabelldata in i DW-tabellerna åt gången oavsett det sålda datumet.

Den laddade informationen lagras i respektive dimension (eller) faktatabeller. Data kan laddas, läggas till eller slås samman till DW-tabellerna enligt följande:

# 4) Ladda: Data laddas in i måltabellen om den är tom. Om det finns vissa data i tabellen tas bort befintlig data och laddas sedan med den nya informationen.

Till exempel,

Befintliga tabelldata

Ändrade data

Data efter laddning

# 5) Lägg till: Append är en förlängning av ovanstående belastning eftersom den fungerar på redan data existerande tabeller. I måltabellerna lägger Append till mer data till befintlig data. Om någon dubblettpost hittas med indata kan den läggas till som duplikat (eller) den kan avvisas.

Till exempel,

Befintliga tabelldata

Ändrade data

Data efter tillägg

# 6) Destruktiv sammanslagning: Här jämförs inkommande data med befintlig måldata baserat på primärnyckeln. Om det finns en match uppdateras den befintliga målposten. Om ingen matchning hittas infogas en ny post i måltabellen.

Till exempel,

Befintliga tabelldata

Ändrade data

Data efter konstruktiv sammanslagning

# 7) Konstruktivt går: Till skillnad från destruktiv sammanslagning, om det finns en matchning med den befintliga posten, lämnar den den befintliga posten som den är och infogar den inkommande posten och markerar den som den senaste informationen (tidsstämpel) med avseende på den primära nyckeln.

hur man kör en torrentfil

Till exempel,

Befintliga tabelldata

Ändrade data

Data efter konstruktiv sammanslagning

Tekniskt sett är uppdatering enklare än att uppdatera data. Uppdateringen behöver en speciell strategi för att endast extrahera de specifika ändringarna och tillämpa dem på DW-systemet medan Refresh bara ersätter data. Men att uppdatera data tar längre tid beroende på datamängderna.

Om du har sådana uppdateringsjobb att köra dagligen kan du behöva ta ner DW-systemet för att ladda data. Istället för att få ner hela DW-systemet för att ladda data varje gång kan du dela och ladda data i form av få filer.

Anteckna körtiden för varje belastning under testningen. Om någon information inte kan laddas in i DW-systemet på grund av att nyckelfel matchar etc, ge dem sätten att hantera sådan typ av data. Se till att laddad data testas noggrant.

Laddningsflödesdiagram:

Platta filer

Platta filer används ofta för att utbyta data mellan heterogena system, från olika källoperativsystem och från olika källdatabassystem till datalagerapplikationer. Platta filer är mest effektiva och enkla att hantera för homogena system.

Platta filer används främst för följande ändamål:

# 1) Leverans av källdata: Det kan finnas få källsystem som inte tillåter DW-användare att komma åt sina databaser av säkerhetsskäl. I sådana fall levereras data via platta filer.

På samma sätt kommer datan från externa leverantörer eller mainframesystem i huvudsak i form av platta filer, och dessa kommer att FTP'as av ETL-användarna.

# 2) Arbets- / iscensättningstabeller: ETL-processen skapar iscensättningstabeller för sitt interna syfte. Associeringen av mellanläggstabeller med de platta filerna är mycket enklare än DBMS eftersom läsning och skrivning till ett filsystem är snabbare än att infoga och fråga en databas.

# 3) Förberedelse för bulkbelastning: När extraherings- och transformationsprocesserna har gjorts Om inte in-stream-bulkbelastningen stöds av ETL-verktyget (eller) Om du vill arkivera data kan du skapa en platt-fil. Denna platta fildata läses av processorn och laddar in data i DW-systemet.

Platta filer kan skapas på två sätt som 'Flat-filer med fast längd' och 'Avgränsade platta filer'. Platta filer kan skapas av de programmerare som arbetar för källsystemet.

Låt oss se hur vi bearbetar dessa platta filer:

Bearbetar fasta filer med fast längd

I allmänhet har platta filer kolumner med fast längd, därför kallas de också som positionella platta filer. Nedan är layouten för en platt-fil som visar de exakta fälten och deras positioner i en fil.

Layouten innehåller fältnamn, längd, startposition vid vilken fälttecknet börjar, den slutposition där fälttecknet slutar, datatypen som text, numerisk, etc. och eventuella kommentarer.

Beroende på datapositionerna kommer ETL-testteamet att validera dataens noggrannhet i en platt fil med fast längd.

Bearbetar avgränsade platta filer

I avgränsade platta filer separeras varje datafält med avgränsare. Denna avgränsare anger start- och slutposition för varje fält. I allmänhet används ett komma som en avgränsare, men du kan använda vilken annan symbol som helst eller en uppsättning symboler.

Avgränsade filer kan ha .CSV-tillägg (eller) .TXT-tillägg (eller) utan tillägg. Utvecklarna som skapar ETL-filerna kommer att ange den faktiska avgränsningssymbolen för att bearbeta den filen. I den avgränsade fillayouten kan den första raden representera kolumnnamnen.

Samma som positionella plattfiler kommer ETL-testteamet uttryckligen att validera noggrannheten för den avgränsade plattfildata.

Syfte med iscensättningsområdet

Huvudsyftet med iscensättningsområdet är att lagra data tillfälligt för ETL-processen. Iscenesättningsområdet kallas bakrummet till DW-systemet. ETL-arkitekten bestämmer om den ska lagra data i iscensättningsområdet eller inte.

Staging hjälper till att få data från källsystem väldigt snabbt. Samtidigt om DW-systemet misslyckas behöver du inte starta processen igen genom att samla in data från källsystemen om iscensättningsdata redan finns.

Efter dataextraktionsprocessen är här skälen till att infoga data i DW-systemet:

# 1) Återställbarhet: De befolkade iscensättningstabellerna lagras i själva DW-databasen (eller) de kan flyttas till filsystem och kan lagras separat. Vid någon tidpunkt kan iscensättningsdata fungera som återställningsdata om något transformations- eller laddningssteg misslyckas.

Det kan finnas chanser att källsystemet har skrivit över de data som används för ETL, så att hålla extraherade data i iscensättning hjälper oss för någon referens.

# 2) Säkerhetskopiering: Det är svårt att ta upp stora mängder DW-databastabeller. Men säkerhetskopior är ett måste för alla katastrofåterhämtningar. Därför, om du har iscensättningsdata som extraheras data, så kan du köra jobben för omvandling och laddning, därmed kan den kraschade informationen laddas om.

För att säkerhetskopiera iscensättningsdata kan du ofta flytta iscensättningsdata till filsystem så att det är enkelt att komprimera och lagra i ditt nätverk. När det behövs, komprimera bara filer, ladda in mellanlagringstabeller och kör jobb för att ladda om DW-tabellerna.

# 3) Granskning: Ibland kan en revision ske på ETL-systemet för att kontrollera datalänken mellan källsystemet och målsystemet. Revisorerna kan validera de ursprungliga ingångsdata mot utdata baserat på omvandlingsreglerna.

Insamlingsdata och säkerhetskopiering är mycket hjälpsamma här även om källsystemet har informationen tillgänglig eller inte. Eftersom granskning kan ske när som helst och under vilken period som helst (eller) tidigare data. Iscenesättningsområdets arkitektur bör vara väl planerad.

Designa Staging Area

I datalagret kan data för mellanstegsdesign utformas enligt följande:

Med varje ny belastning av data i iscensättningstabeller kan befintlig data raderas (eller) underhållas som historisk data för referens. Om data raderas kallas det ett ”Transient staging area”.

Om data upprätthålls som historik, kallas det ett ”beständigt iscenesättningsområde”. Du kan också designa ett iscensättningsområde med en kombination av ovanstående två typer som är ”Hybrid”.

Här är de grundläggande reglerna som ska vara kända när du utformar iscenesättningsområdet:

• Endast ETL-teamet ska ha tillgång till datainställningsområdet. Frågan på iscensättningsdata är begränsad till andra användare.
• Tabeller i iscensättningsområdet kan läggas till, modifieras eller släppas av ETL-dataarkitekt utan att involvera andra användare. Eftersom iscensättningsområdet inte är ett presentationsområde för att generera rapporter fungerar det bara som en arbetsbänk.
• ETL-arkitekten ska uppskatta datalagringsmåttet för iscenesättningsområdet för att ge information till DBA- och OS-administratörer. Administratörer tilldelar utrymme för iscensättning av databaser, filsystem, kataloger etc.

Om stagingområdet och DW-databasen använder samma server kan du enkelt flytta data till DW-systemet. Om servrarna skiljer sig åt använder du FTP (eller) databaslänkar.

ETL-processflöde

En standard ETL-cykel kommer att gå igenom nedanstående processsteg:

• Starta ETL-cykeln för att köra jobb i sekvens.
• Se till att alla metadata är klara.
• ETL-cykeln hjälper till att extrahera data från olika källor.
• Validera extraherade data.
• Om iscensättningstabeller används laddar ETL-cykeln in data i iscensättning.
• ETL utför omvandlingar genom att tillämpa affärsregler, genom att skapa aggregat osv
• Om det finns några fel kommer ETL-cykeln att göra det tillkännagivande i form av rapporter.
• Sedan laddar ETL-cykeln data i måltabellerna.
• Tidigare data som måste lagras för historisk referens arkiveras.
• Resten av data som inte behöver lagras rengörs.

ETL-processflödesdiagram:

Slutsats

I den här handledningen lärde vi oss de viktigaste begreppen för ETL-processen i Data Warehouse. Nu ska du kunna förstå vad som är datautvinning, datatransformation, dataladdning och ETL-processflödet.

Läs den kommande handledningen för att lära dig mer om Data Warehouse Testing !!

=> Besök här för den exklusiva datalagringsserien.

Rekommenderad läsning

• Data Warehouse Testing Tutorial med exempel | ETL Testguide
• De 10 bästa datakartningsverktygen som är användbara i ETL-processen (2021 LIST)
• ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
• Data Mining: Process, Techniques & Major Issues In Data Analysis
• Data Mining Process: Modeller, Process Steps & Challenges Involved
• ETL Testing Intervju Frågor och svar
• Topp 10 ETL-testverktyg 2021
• Topp 10 populära datalagerverktyg och testtekniker