You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.201.0.0/16 has been blocked (disabled) by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 23:54, 31 July 2024.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:55, 18 August 2022
- Expiry of block: 13:55, 18 April 2025
Your current IP address is 44.201.113.141. The blocked range is 44.201.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((Short description|Procedure in computing))
[[File:Conventional ETL Diagram.jpg|alt=Conventional ETL diagram|thumb|Conventional ETL diagram<ref name="Kimball 2004" />]]
((Data transformation))

In [[computing]], '''extract, transform, load''' ('''ETL''') is a three-phase process where data is [[Data extraction|''extracted'']] from an input source, [[Data transformation|''transformed'']] (including [[Data cleaning|cleaning]]), and [[Data loading|''loaded'']] into an output data container. The data can be collated from one or more sources and it can also be output to one or more destinations. ETL processing is typically executed using [[software application|software applications]] but it can also be done manually by [[sysop|system operator]]s. ETL software typically automates the entire process and can be run manually or on reccurring schedules either as single jobs or aggregated into a batch of jobs.

A properly designed ETL system extracts data from source systems and enforces [[data type]] and data validity standards and ensures it conforms structurally to the requirements of the output. Some ETL systems can also deliver data in a presentation-ready format so that application developers can build applications and end users can make decisions.<ref name="Kimball 2004">((Cite book|title=The data warehouse ETL toolkit : practical techniques for extracting, cleaning, conforming, and delivering data|last=Ralph.|first=Kimball|date=2004|publisher=Wiley|others=Caserta, Joe, 1965-|isbn=978-0764579233|location=Indianapolis, IN|oclc=57301227))</ref>

The ETL process is often used in [[data warehouse|data warehousing]].<ref>((Cite journal|last=Denney|first=MJ|date=2016|title=Validating the extract, transform, load process used to populate a large clinical research database|journal=International Journal of Medical Informatics|volume=94|pages=271–4|doi=10.1016/j.ijmedinf.2016.07.009|pmc=5556907|pmid=27506144))</ref> ETL systems commonly integrate data from multiple applications (systems), typically developed and supported by different [[vendor|vendors]] or hosted on separate computer hardware. The separate systems containing the original data are frequently managed and operated by different [[stakeholder (corporate)|stakeholder]]s. For example, a cost accounting system may combine data from payroll, sales, and purchasing.

Data extraction involves extracting data from homogeneous or heterogeneous sources; data transformation processes data by data cleaning and transforming it into a proper storage format/structure for the purposes of querying and analysis; finally, data loading describes the insertion of data into the final target database such as an [[operational data store]], a [[data mart]], [[data lake]] or a data warehouse.<ref>((Cite web|url=https://www.edq.com/blog/what-is-etl-extract-transform-load/|title=What is ETL? (Extract, Transform, Load) ((!)) Experian|last=Zhao|first=Shirley|date=2017-10-20|website=Experian Data Quality|language=en-US|access-date=2018-12-12))</ref><ref>((Cite web|url=https://www.theregister.co.uk/2018/06/04/data_integration_is_hard/|title=Extract, transform, load? More like extremely tough to load, amirite?|first=Trevor|last=Pott|date=4 June 2018|website=[[The Register]]|language=en|access-date=2018-12-12))</ref>

== Extract ==

ETL processing involves extracting the data from the source system(s). In many cases, this represents the most important aspect of ETL, since extracting data correctly sets the stage for the success of subsequent processes. Most data-warehousing projects combine data from different source systems. Each separate system may also use a different data organization and/or [[File format|format]]. Common data-source formats include [[relational database]]s, [[flat-file database]]s, [[XML]], and [[JSON]], but may also include non-relational database structures such as [[IBM Information Management System]] or other data structures such as [[Virtual Storage Access Method|Virtual Storage Access Method (VSAM)]] or [[ISAM|Indexed Sequential Access Method (ISAM)]], or even formats fetched from outside sources by means such as a [[web crawler]] or [[data scraping]]. The streaming of the extracted data source and loading on-the-fly to the destination database is another way of performing ETL when no intermediate data storage is required. 

An intrinsic part of the extraction involves data validation to confirm whether the data pulled from the sources has the correct/expected values in a given domain (such as a pattern/default or list of values). If the data fails the validation rules, it is rejected entirely or in part. The rejected data is ideally reported back to the source system for further analysis to identify and to rectify incorrect records or perform [[data wrangling]].

== Transform ==

In the [[data transformation]] stage, a series of rules or functions are applied to the extracted data in order to prepare it for loading into the end target.

An important function of transformation is [[data cleansing]], which aims to pass only "proper" data to the target. The challenge when different systems interact is in the relevant systems' interfacing and communicating. Character sets that may be available in one system may not be so in others.

In other cases, one or more of the following transformation types may be required to meet the business and technical needs of the server or data warehouse:
((More citations needed|date=May 2019))
* Selecting only certain columns to load: (or selecting [[null (SQL)|null]] columns not to load). For example, if the source data has three columns (aka "attributes"), roll_no, age, and salary, then the selection may take only roll_no and salary. Or, the selection mechanism may ignore all those records where salary is not present (salary = null).
* Translating coded values: (''e.g.'', if the source system codes male as "1" and female as "2", but the warehouse codes male as "M" and female as "F")
* Encoding free-form values: (''e.g.'', mapping "Male" to "M")
* Deriving a new calculated value: (''e.g.'', sale_amount = qty * unit_price)
* Sorting or ordering the data based on a list of columns to improve search performance
* [[Join (relational algebra)#Joins and join-like operators|Join]]ing data from multiple sources (''e.g.'', lookup, merge) and [[Record linkage|deduplicating]] the data
* Aggregating (for example, rollup — summarizing multiple rows of data — total sales for each store, and for each region, etc.)
* Generating [[surrogate key|surrogate-key]] values
* [[Transpose|Transposing]] or [[Pivot table|pivoting]] (turning multiple columns into multiple rows or vice versa)
* Splitting a column into multiple columns (''e.g.'', converting a [[comma separated values|comma-separated list]], specified as a string in one column, into individual values in different columns)
* Disaggregating repeating columns
* Looking up and validating the relevant data from tables or referential files
* Applying any form of data validation; failed validation may result in a full rejection of the data, partial rejection, or no rejection at all, and thus none, some, or all of the data is handed over to the next step depending on the rule design and exception handling; many of the above transformations may result in exceptions, e.g., when a code translation parses an unknown code in the extracted data

== Load ==

The load phase loads the data into the end target, which can be any data store including a simple delimited flat file or a [[data warehouse]]. Depending on the requirements of the organization, this process varies widely. Some data warehouses may overwrite existing information with cumulative information; updating extracted data is frequently done on a daily, weekly, or monthly basis. Other data warehouses (or even other parts of the same data warehouse) may add new data in a historical form at regular intervals — for example, hourly. To understand this, consider a data warehouse that is required to maintain sales records of the last year. This data warehouse overwrites any data older than a year with newer data. However, the entry of data for any one year window is made in a historical manner. The timing and scope to replace or append are strategic design choices dependent on the time available and the [[business]] needs. <!-- is this part of "load"? -->More complex systems can maintain a history and [[audit trail]] of all changes to the data loaded in the data warehouse.
As the load phase interacts with a database, the constraints defined in the database schema — as well as in triggers activated upon data load — apply (for example, uniqueness, [[referential integrity]], mandatory fields), which also contribute to the overall data quality performance of the ETL process.

* For example, a financial institution might have information on a customer in several departments and each department might have that customer's information listed in a different way. The membership department might list the customer by name, whereas the accounting department might list the customer by number. ETL can bundle all of these data elements and consolidate them into a uniform presentation, such as for storing in a database or data warehouse.
* Another way that companies use ETL is to move information to another application permanently. For instance, the new application might use another database vendor and most likely a very different database schema. ETL can be used to transform the data into a format suitable for the new application to use.
* An example would be an [[expense and cost recovery system]] such as used by [[Accounting|accountants]], [[consultant]]s, and [[law firm]]s. The data usually ends up in the [[Law practice management software|time and billing system]], although some businesses may also utilize the raw data for employee productivity reports to Human Resources (personnel dept.) or equipment usage reports to Facilities Management.

== Real-life ETL cycle ==

The typical real-life ETL cycle consists of the following execution steps:

# Cycle initiation
# Build [[reference data]]
# Extract (from sources)
# [[data validation|Validate]]
# Transform ([[data cleaning|clean]], apply [[business rule]]s, check for [[data integrity]], create [[Aggregate (data warehouse)|aggregates]] or disaggregates)
# Stage (load into [[staging (data)|staging]] tables, if used)
# [[Audit report]]s (for example, on compliance with business rules. Also, in case of failure, helps to diagnose/repair)
# Publish (to target tables)
# [[Archiving|Archive]]

== Challenges ==

ETL processes can involve considerable complexity, and significant operational problems can occur with improperly designed ETL systems.

The range of data values or data quality in an operational system may exceed the expectations of designers at the time validation and transformation rules are specified. [[Data profiling]] of a source during data analysis can identify the data conditions that must be managed by transform rules specifications, leading to an amendment of validation rules explicitly and implicitly implemented in the ETL process.

Data warehouses are typically assembled from a variety of data sources with different formats and purposes. As such, ETL is a key process to bring all the data together in a standard, homogeneous environment.

Design analysis<ref>((Cite journal|last=Theodorou|first=Vasileios|date=2017|title=Frequent patterns in ETL workflows: An empirical approach|journal=Data & Knowledge Engineering|volume=112|pages=1–16|doi=10.1016/j.datak.2017.08.004|hdl=2117/110172|hdl-access=free))</ref> should establish the [[scalability]] of an ETL system across the lifetime of its usage — including understanding the volumes of data that must be processed within [[service level agreement]]s. The time available to extract from source systems may change, which may mean the same amount of data may have to be processed in less time. Some ETL systems have to scale to process terabytes of data to update data warehouses with tens of terabytes of data. Increasing volumes of data may require designs that can scale from daily [[batch processing|batch]] to multiple-day micro batch to integration with [[message queue]]s or real-time change-data-capture for continuous transformation and update.

== Performance ==

ETL vendors benchmark their record-systems at multiple TB (terabytes) per hour (or ~1 GB per second) using powerful servers with multiple CPUs, multiple hard drives, multiple gigabit-network connections, and much memory.

In real life, the slowest part of an ETL process usually occurs in the database load phase. Databases may perform slowly because they have to take care of concurrency, integrity maintenance, and indices. Thus, for better performance, it may make sense to employ:
* ''Direct path extract'' method or bulk unload whenever is possible (instead of querying the database) to reduce the load on source system while getting high-speed extract
* Most of the transformation processing outside of the database
* Bulk load operations whenever possible

Still, even using bulk operations, database access is usually the bottleneck in the ETL process. Some common methods used to increase performance are:
* [[partition (database)|Partition]] tables (and indices): try to keep partitions similar in size (watch for <code>null</code> values that can skew the partitioning)
* Do all validation in the ETL layer before the load: disable [[data integrity|integrity]] checking (<code>disable constraint</code> ...) in the target database tables during the load
* Disable [[database trigger|triggers]] (<code>disable trigger</code> ...) in the target database tables during the load: simulate their effect as a separate step
* Generate IDs in the ETL layer (not in the database)
* Drop the [[database index|indices]] (on a table or partition) before the load - and recreate them after the load (SQL: <code>drop index</code> ...<code>; create index</code> ...)
* Use parallel bulk load when possible — works well when the table is partitioned or there are no indices (Note: attempting to do parallel loads into the same table (partition) usually causes locks — if not on the data rows, then on indices)
* If a requirement exists to do insertions, updates, or deletions, find out which rows should be processed in which way in the ETL layer, and then process these three operations in the database separately; you often can do bulk load for inserts, but updates and deletes commonly go through an [[API]] (using [[SQL]])

Whether to do certain operations in the database or outside may involve a trade-off. For example, removing duplicates using <code>distinct</code> may be slow in the database; thus, it makes sense to do it outside. On the other side, if using <code>distinct</code> significantly (x100) decreases the number of rows to be extracted, then it makes sense to remove duplications as early as possible in the database before unloading data.

A common source of problems in ETL is a big number of dependencies among ETL jobs. For example, job "B" cannot start while job "A" is not finished. One can usually achieve better performance by visualizing all processes on a graph, and trying to reduce the graph making maximum use of [[parallel computing|parallelism]], and making "chains" of consecutive processing as short as possible. Again, partitioning of big tables and their indices can really help.

Another common issue occurs when the data are spread among several databases, and processing is done in those databases sequentially. Sometimes database replication may be involved as a method of copying data between databases — it can significantly slow down the whole process. The common solution is to reduce the processing graph to only three layers:

* Sources
* Central ETL layer
* Targets

This approach allows processing to take maximum advantage of parallelism. For example, if you need to load data into two databases, you can run the loads in parallel (instead of loading into the first — and then replicating into the second).

Sometimes processing must take place sequentially. For example, dimensional (reference) data are needed before one can get and validate the rows for main [[Fact table|"fact" tables]].

== Parallel processing ==

A ((as of|2009|alt=recent)) development in ETL software is the implementation of [[Parallel computing|parallel processing]]. It has enabled a number of methods to improve overall performance of ETL when dealing with large volumes of data.

ETL applications implement three main types of parallelism:

* Data: By splitting a single sequential file into smaller data files to provide [[Parallel Random Access Machine|parallel access]]
* [[pipeline (computing)|Pipeline]]: allowing the simultaneous running of several components on the same [[data stream]], e.g. looking up a value on record 1 at the same time as adding two fields on record 2
* Component: The simultaneous running of multiple [[process (computing)|processes]] on different data streams in the same job, e.g. sorting one input file while removing duplicates on another file

All three types of parallelism usually operate combined in a single job or task.

An additional difficulty comes with making sure that the data being uploaded is relatively consistent. Because multiple source databases may have different update cycles (some may be updated every few minutes, while others may take days or weeks), an ETL system may be required to hold back certain data until all sources are synchronized. Likewise, where a warehouse may have to be reconciled to the contents in a source system or with the general ledger, establishing synchronization and reconciliation points becomes necessary.

== Rerunnability, recoverability ==

Data warehousing procedures usually subdivide a big ETL process into smaller pieces running sequentially or in parallel. To keep track of data flows, it makes sense to tag each data row with "row_id", and tag each piece of the process with "run_id". In case of a failure, having these IDs help to roll back and rerun the failed piece.

Best practice also calls for ''checkpoints'', which are states when certain phases of the process are completed. Once at a checkpoint, it is a good idea to write everything to disk, clean out some temporary files, log the state, etc.

== Virtual ETL ==

((as of|2010)), [[data virtualization]] had begun to advance ETL processing. The application of data virtualization to ETL allowed solving the most common ETL tasks of [[data migration]] and application integration for multiple dispersed data sources. Virtual ETL operates with the abstracted representation of the objects or entities gathered from the variety of relational, semi-structured, and [[unstructured data]] sources. ETL tools can leverage object-oriented modeling and work with entities' representations persistently stored in a centrally located [[hub-and-spoke]] architecture. Such a collection that contains representations of the entities or objects gathered from the data sources for ETL processing is called a metadata repository and it can reside in memory or be made persistent. By using a persistent metadata repository, ETL tools can transition from one-time projects to persistent middleware, performing data harmonization and [[data profiling]] consistently and in near-real time.

== Dealing with keys ==

[[Unique key]]s play an important part in all relational databases, as they tie everything together. A unique key is a column that identifies a given entity, whereas a [[foreign key]] is a column in another table that refers to a primary key. Keys can comprise several columns, in which case they are composite keys. In many cases, the primary key is an auto-generated integer that has no meaning for the [[Business entity (computer science)|business entity]] being represented, but solely exists for the purpose of the relational database - commonly referred to as a [[surrogate key]].

As there is usually more than one data source getting loaded into the warehouse, the keys are an important concern to be addressed. For example: customers might be represented in several data sources, with their [[Social Security number]] as the primary key in one source, their phone number in another, and a surrogate in the third. Yet a data warehouse may require the consolidation of all the customer information into one [[Dimension (data warehouse)|dimension]].

A recommended way to deal with the concern involves adding a warehouse surrogate key, which is used as a foreign key from the fact table.<ref>Kimball, The Data Warehouse Lifecycle Toolkit, p. 332</ref>

Usually, updates occur to a dimension's source data, which obviously must be reflected in the data warehouse.

If the primary key of the source data is required for reporting, the dimension already contains that piece of information for each row. If the source data uses a surrogate key, the warehouse must keep track of it even though it is never used in queries or reports; it is done by creating a [[lookup table]] that contains the warehouse surrogate key and the originating key.<ref name="Rizzi, Data Warehouse Design p. 291">Golfarelli/Rizzi, Data Warehouse Design, p. 291</ref> This way, the dimension is not polluted with surrogates from various source systems, while the ability to update is preserved.

The lookup table is used in different ways depending on the nature of the source data.
There are 5 types to consider;<ref name="Rizzi, Data Warehouse Design p. 291"/> three are included here:
;Type 1
:The dimension row is simply updated to match the current state of the source system; the warehouse does not capture history; the lookup table is used to identify the dimension row to update or overwrite
;Type 2
:A new dimension row is added with the new state of the source system; a new surrogate key is assigned; source key is no longer unique in the lookup table
;Fully logged
:A new dimension row is added with the new state of the source system, while the previous dimension row is updated to reflect it is no longer active and time of deactivation.

== Tools ==

An established ETL framework may improve connectivity and [[scalability]].((citation needed|date=December 2011)) A good ETL tool must be able to communicate with the many different [[relational database]]s and read the various file formats used throughout an organization. ETL tools have started to migrate into [[enterprise application integration]], or even [[enterprise service bus]], systems that now cover much more than just the extraction, transformation, and loading of data. Many ETL vendors now have [[data profiling]], [[data quality]], and [[Metadata (computing)|metadata]] capabilities. A common use case for ETL tools include converting CSV files to formats readable by relational databases. A typical translation of millions of records is facilitated by ETL tools that enable users to input csv-like data feeds/files and import them into a database with as little code as possible.

ETL tools are typically used by a broad range of professionals — from students in computer science looking to quickly import large data sets to database architects in charge of company account management, ETL tools have become a convenient tool that can be relied on to get maximum performance. ETL tools in most cases contain a GUI that helps users conveniently transform data, using a visual data mapper, as opposed to writing large programs to parse files and modify data types.

While ETL tools have traditionally been for developers and IT staff, research firm Gartner wrote that the new trend is to provide these capabilities to business users so they can themselves create connections and data integrations when needed, rather than going to the IT staff.<ref>((cite web|title=The Inexorable Rise of Self Service Data Integration|url=http://blogs.gartner.com/andrew_white/2015/05/22/the-inexorable-rise-of-self-service-data-integration/|work=Gartner|date=22 May 2015|access-date=31 January 2016))</ref> Gartner refers to these non-technical users as Citizen Integrators.<ref>((cite web|title=Embrace the Citizen Integrator|url=https://www.gartner.com/doc/2891817/embrace-citizen-integrator-approach-improve|work=Gartner|access-date=September 29, 2021))</ref>

== ETL vs. ELT ==

((main|Extract, load, transform))
[[Extract, load, transform]] (ELT) is a variant of ETL where the extracted data is loaded into the target system first.<ref name="AWS Data Warehousing 9" >Amazon Web Services, Data Warehousing on AWS, p. 9</ref> The architecture for the analytics pipeline shall also consider where to cleanse and enrich data<ref name="AWS Data Warehousing 9" /> as well as how to conform dimensions.<ref name="Kimball 2004" /> Some of the benefits of an ELT process include speed and the ability to more easily handle both unstructured and structured data.<ref>((Cite web |last=Mishra |first=Tanya |date=2023-09-02 |title=ETL vs ELT: Meaning, Major Differences & Examples |url=https://www.analyticsinsight.net/etl-vs-elt-meaning-major-differences-examples/ |access-date=2024-01-30 |website=Analytics Insight |language=en-US))</ref>

[[Ralph Kimball]] and [[Joe Caserta]]'s book The Data Warehouse ETL Toolkit, (Wiley, 2004), which is used as a textbook for courses teaching ETL processes in data warehousing, addressed this issue.<ref>((Cite web|url=https://www.oreilly.com/library/view/the-data-warehouse/9780764567575/|title = The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data &#91;Book&#93;))</ref>

Cloud-based data warehouses like [[Amazon Redshift]], Google [[BigQuery]], [[Microsoft Azure Synapse Analytics]] and [[Snowflake Inc.]] have been able to provide highly scalable computing power. This lets businesses forgo preload transformations and replicate raw data into their data warehouses, where it can transform them as needed using [[SQL]].

After having used ELT, data may be processed further and stored in a data mart.<ref>Amazon Web Services, Data Warehousing on AWS, 2016, p. 10</ref>

Most data integration tools skew towards ETL, while ELT is popular in database and data warehouse appliances. Similarly, it is possible to perform TEL (Transform, Extract, Load) where data is first transformed on a blockchain (as a way of recording changes to data, e.g., token burning) before extracting and loading into another data store.<ref>((cite book |last1=Bandara |first1=H. M. N. Dilum |last2=Xu |first2=Xiwei |last3=Weber |first3=Ingo |title=Proceedings of the European Conference on Pattern Languages of Programs 2020 |chapter=Patterns for Blockchain Data Migration |year=2020 |pages=1–19 |doi=10.1145/3424771.3424796 |arxiv=1906.00239|isbn=9781450377690 |s2cid=219956181 ))</ref>

== See also ==

*[[Architectural pattern]] (EA reference architecture)
*[[CMS Pipelines]]
*[[Create, read, update and delete]] (CRUD)
*[[Data cleansing]]
*[[Data integration]]
*[[Data mart]]
*[[Data mesh]], a domain-oriented data architecture
*[[Data migration]]
*[[Data transformation (computing)]]
*[[Electronic data interchange]] (EDI)
*[[Enterprise architecture]]
*[[Legal Electronic Data Exchange Standard]] (LEDES)
*[[Metadata discovery]]
*[[Online analytical processing]] (OLAP)
*[[Online transaction processing]] (OLTP)
*[[Spatial ETL]]

== References ==

((Reflist))

((Data))
((Data warehouse))
((Authority Control))

[[Category:Extract, transform, load tools| ]]
[[Category:Data warehousing]]

Pages transcluded onto the current version of this page (help):

Extract, transform, load (edit)
Template:Ambox (view source) (template editor protected)
Template:As of (view source) (template editor protected)
Template:Authority Control (view source) (semi-protected)
Template:Authority control (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite book (view source) (protected)
Template:Cite journal (view source) (protected)
Template:Cite web (view source) (protected)
Template:DMCA (view source) (template editor protected)
Template:Data (edit)
Template:Data transformation (edit)
Template:Data warehouse (edit)
Template:Data warehouses (edit)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:Hlist/styles.css (view source) (protected)
Template:Main (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:More citations needed (view source) (template editor protected)
Template:Navbox (view source) (template editor protected)
Template:Navbox with collapsible groups (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:Pagetype (view source) (protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Sidebar (view source) (template editor protected)
Template:Yesno (view source) (protected)
Module:Arguments (view source) (protected)
Module:Authority control (view source) (template editor protected)
Module:Authority control/config (view source) (template editor protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:Format link (view source) (template editor protected)
Module:Hatnote (view source) (template editor protected)
Module:Hatnote/styles.css (view source) (template editor protected)
Module:Hatnote list (view source) (template editor protected)
Module:Labelled list hatnote (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Navbox with collapsible groups (view source) (template editor protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Sidebar (view source) (template editor protected)
Module:Sidebar/configuration (view source) (template editor protected)
Module:Sidebar/styles.css (view source) (template editor protected)
Module:String (view source) (protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Extract, transform, load.

Retrieved from "https://en.wikipedia.org/wiki/Extract,_transform,_load"