SQL Transform in BODS

SQL Transformation

Summary:-

SQL transformation is used to perform standard SQL Operations in Data services but it is not supports all SQL operations. It supports only retrieval operations (select statements).Using SQL transformation we can’t manipulates (Insert, Delete, Update) the data.

SQL transformation and lookup function have done same operations. .. Performance of SQL transformation is very good compared to lookup function.

Prerequisite:-

• SQL transformation supports only tables not files or other sources in SQL text.

Example Scenario:-

• In this scenario, we have three source tables as shown in figure 1, 2 and 3 but we want 3 source tables’ data information in one target table based on business requirement.
• In this condition we go for SQL transformation. SQL transformation is used to join the 3 source tables and gets the output in single target as shown in figure 4.
• NOTE: – You can get same output using lookup function but it will take more time compared to sql transformation

Figure 1: Sample Source Data1

Figure 2: Sample Source Data2

Figure 3: Sample Source Data3

Figure 4: Sample Target Data

Figures 5, 6 and 7 shows the object hierarchy for validation transformation job, ETL job flow and the way we define the SQL statements respectively.

Figure 5: SQL Transformation Object Hierarchy

Figure 6: SQL Transformation ETL Job Flow

In SQL Transformation:-

Data store:

• The name of the Data Store that Data Services uses to access the tables referred to in SQL text.

SQL Text:-

• In SQLtext, select statement is used to get the data from three tables using join condition.

Update Schema:-

• Click the option updateschema to populate the output schema for the SQL SELECT statement. 

• You can these options in below figure 7.

Figure 7: Defining SQL statements in SQL text for SQL Transformation

SQL Transform - When should you use it?

Never!

You were expecting a longer post about this? Well alright then, never ever!

Whenever I see tons of SQL Transforms around a Data Services job, it is normally a sign of a lazy developer. Some-one who had written out the queries in SQL, and instead of building proper data flows using the Query transform and other built in Data Services functionality, just copied and pasted the sql into the SQL transform.

But what's wrong with that? Well plenty!

DS is NOT a glorified scheduler

For starters, you just bought a not-inexpensive ETL tool that you are now just using as a query scheduler. If all you want to do is automate your queries then write them into a  stored procedure and schedule it on the database. Don't waste your money on a world class ETL tool.

You've just broken Impact and Lineage analysis

One of the biggest selling points of using a tool like DS, is you can visually see where a field is used in your ETL and where its data ultimately ends up. Likewise, you can see where a particular piece of data came from by tracing it all the way back to the source system.

This is a fantastic governance tool for managing your warehouse. You can see if, and where, making a change to a source system will affect your data warehouse.

The second you put a SQL transform in the way, you've just broken your impact and lineage analysis. DS treats it as a black box, so whether you are using the lineage in the management console, Data Services Designer View Where Used function, or in Information Steward, you have just rendered it useless.

In the Datastore below it appears is if none of the tables are being used in any jobs.

But then after a little searching I find an SQL transform.

I look inside it and what do I find?

And this query is hardly complex. It wouldn't have taken very long to develop as a proper data flow with the Query transform, and now some future developer could make changes to the job thinking that they have everything covered, but not realize that 3 extra tables were hidden inside an SQL transform.

I can't tell you how many times I've needed to make a change, right clicked on the table in the data store and chosen View Were Used, made all my changes, only to later discover I've missed one that a developer hid in a SQL transform.

Squinting at code

One of the great things about using a GUI based ETL tool is that you can open a data flow and immediately get an idea of what it is doing. You can see the tables on the screen, see which transforms they flow through and understand what is happening to the data and where it is going. With a SQL transform you have to open it up, squint at the code to try and figure out what it is up to.

For simple SQL that's not a big deal, but a complicated query with plenty of tables and joins.... well now you're wasting my time, and my client's money too!

Should you really never use the SQL transform?

I worked in a company where they had a ban on using the SQL transform. Turn in your code with one in it, and it got returned to you to have it rewritten without the SQL transform. No exceptions.

I will admit, there are times when you will just have to use the SQL transform, but these should be rare exceptions. Sometimes you need to do something very complex, that's maybe only available on the database, so you have to use the SQL transform to take advantage of it.

Before you do it though, think really hard about whether you couldn't achieve the same thing using Data Services built in transforms. Even if you have to split it out over multiple data flows, it will still be better than using the SQL transform.