Today I read some articles about ELT versus ETL, I have noticed the large amount of information available about ETL and the smaller amount of information out there concerning ELT data integration approach. So, without writing another article of what is the difference between them or which one is better, I have decided to introduce this approach from my point of view.

ELT stands for Extract, Load, Transform.
This approach, extracts the data from the source and then uses the database to make transformation to it, after the load process has taken place and before integrating it into the data warehouse itself:
ELT Overview

Looking at the overview, it is a good idea to to do a little drill down of the process. The first step of course is extracting the data from the source, after which comes the load process. The loading stage does not necessarily load the data into the data warehouse tables themselves, but usually this data is loaded into a staging area, which is located on the destination DB. So far, it looks like this:
ELT Destination Overview

Focusing on the staging area only, it is a common thing to have some kind of data flow within the staging area, this flow may differ from a simple table to a complicated set of different objects involved, all depending on the logic of the transformation wanted to be achieved and the tools used for this task. For example, a flow may look like this:
ELT Flow Example

Considering the fact, that the DB is not only the final destination point anymore, but becomes the heart of data integration process it is quite understandable that developing and maintaining such systems will require more attention of the DBA in charge of the data warehouse. Other things, that come to mind when thinking about ELT, are the pros and cons of such a concept. It is quite obvious that the data integration process will have the strengths and weakness of the integration tool and the database’s capabilities, so when choosing a combination of these two, one should choose well.