Update Strategy Transformation Overview

By PenchalaRaju.Yanamala

Transformation type:
Active
Connected

When you design a data warehouse, you need to decide what type of information
to store in targets. As part of the target table design, you need to determine
whether to maintain all the historic data or just the most recent changes.

For example, you might have a target table, T_CUSTOMERS, that contains
customer data. When a customer address changes, you may want to save the
original address in the table instead of updating that portion of the customer row.
In this case, you would create a new row containing the updated address, and
preserve the original row with the old customer address. This shows how you
might store historical information in a target table. However, if you want the
T_CUSTOMERS table to be a snapshot of current customer data, you would
update the existing customer row and lose the original address.

The model you choose determines how you handle changes to existing rows. In
PowerCenter, you set the update strategy at two different levels:

Within a session. When you configure a session, you can instruct the
Integration Service to either treat all rows in the same way (for example, treat all
rows as inserts), or use instructions coded into the session mapping to flag rows
for different database operations.
Within a mapping. Within a mapping, you use the Update Strategy
transformation to flag rows for insert, delete, update, or reject.

Note: You can also use the Multigroup External Procedure transformation to flag
rows for insert, delete, update, or reject.

Setting the Update Strategy

To define an update strategy, complete the following steps:

To control how rows are flagged for insert, update, delete, or reject within a
mapping, add an Update Strategy transformation to the mapping. Update
Strategy transformations are essential if you want to flag rows destined for the
1.same target for different database operations, or if you want to reject rows.
Define how to flag rows when you configure a session. You can flag all rows for
insert, delete, or update, or you can select the data driven option, where the
Integration Service follows instructions coded into Update Strategy
2.transformations within the session mapping.
Define insert, update, and delete options for each target when you configure a
session. On a target-by-target basis, you can allow or disallow inserts and
3.deletes, and you can choose three different ways to handle updates.
Related Topics:
Setting the Update Strategy for a Session
Flagging Rows Within a Mapping

For the greatest degree of control over the update strategy, you add Update
Strategy transformations to a mapping. The most important feature of this
transformation is its update strategy expression, used to flag individual rows for
insert, delete, update, or reject.

The following table lists the constants for each database operation and their
numeric equivalent:

Operation Constant Numeric Value

Insert DD_INSERT 0
Update DD_UPDATE 1
Delete DD_DELETE 2
Reject DD_REJECT 3

The Integration Service treats any other value as an insert.

Forwarding Rejected Rows

You can configure the Update Strategy transformation to either pass rejected
rows to the next transformation or drop them. By default, the Integration Service
forwards rejected rows to the next transformation. The Integration Service flags
the rows for reject and writes them to the session reject file. If you do not select
Forward Rejected Rows, the Integration Service drops rejected rows and writes
them to the session log file.

If you enable row error handling, the Integration Service writes the rejected rows
and the dropped rows to the row error logs. It does not generate a reject file. If
you want to write the dropped rows to the session log in addition to the row error
logs, you can enable verbose data tracing.

Update Strategy Expressions

Frequently, the update strategy expression uses the IIF or DECODE function
from the transformation language to test each row to see if it meets a particular
condition. If it does, you can then assign each row a numeric code to flag it for a
particular database operation. For example, the following IIF statement flags a
row for reject if the entry date is after the apply date. Otherwise, it flags the row
for update:

IIF( ( ENTRY_DATE > APPLY_DATE), DD_REJECT, DD_UPDATE )

To create an Update Strategy transformation:

1.In the Mapping Designer, add an Update Strategy transformation to a mapping.

2.Click Layout > Link Columns.
Drag all ports from another transformation representing data you want to pass
3.through the Update Strategy transformation.
In the Update Strategy transformation, the Designer creates a copy of each port
you drag. The Designer also connects the new port to the original port. Each port
in the Update Strategy transformation is a combination input/output port.
Normally, you would select all of the columns destined for a particular target.
After they pass through the Update Strategy transformation, this information is
flagged for update, insert, delete, or reject.
4.Open the Update Strategy transformation and rename it.
The naming convention for Update Strategy transformations is
UPD_TransformationName.
5.Click the Properties tab.
6.Click the button in the Update Strategy Expression field.
The Expression Editor appears.
Enter an update strategy expression to flag rows as inserts, deletes, updates,
7.or rejects.
8.Validate the expression and click OK.
9. Click OK.
Connect the ports in the Update Strategy transformation to another
10.transformation or a target instance.

Aggregator and Update Strategy Transformations

When you connect Aggregator and Update Strategy transformations as part of

the same pipeline, you have the following options:

Position the Aggregator before the Update Strategy transformation. In this

case, you perform the aggregate calculation, and then use the Update Strategy
transformation to flag rows that contain the results of this calculation for insert,
delete, or update.
Position the Aggregator after the Update Strategy transformation. Here,
you flag rows for insert, delete, update, or reject before you perform the
aggregate calculation. How you flag a particular row determines how the
Aggregator transformation treats any values in that row used in the calculation.
For example, if you flag a row for delete and then later use the row to calculate
the sum, the Integration Service subtracts the value appearing in this row. If the
row had been flagged for insert, the Integration Service would add its value to
the sum.

Lookup and Update Strategy Transformations

When you create a mapping with a Lookup transformation that uses a dynamic
lookup cache, you must use Update Strategy transformations to flag the rows for
the target tables. When you configure a session using Update Strategy
transformations and a dynamic lookup cache, you must define certain session
properties.

You must define the Treat Source Rows As option as Data Driven. Specify this
option on the Properties tab in the session properties.

You must also define the following update strategy target table options:

Select Insert
Select Update as Update
Do not select Delete

These update strategy target table options ensure that the Integration Service
updates rows marked for update and inserts rows marked for insert.
If you do not choose Data Driven, the Integration Service flags all rows for the
database operation you specify in the Treat Source Rows As option and does not
use the Update Strategy transformations in the mapping to flag the rows. The
Integration Service does not insert and update the correct rows. If you do not
choose Update as Update, the Integration Service does not correctly update the
rows flagged for update in the target table. As a result, the lookup cache and
target table might become unsynchronized.

Setting the Update Strategy for a Session

When you configure a session, you have several options for handling database
operations, including updates.

Specifying an Operation for All Rows

When you configure a session, you can select a single database operation for all
rows using the Treat Source Rows As setting.

Table 28-1 displays the options for the Treat Source Rows As setting:

Table 28-1. Specifying an Operation for All Rows

SettingDescription
Insert Treat all rows as inserts. If inserting the row violates a primary or foreign
key constraint in the database, the Integration Service rejects the row.
Delete Treat all rows as deletes. For each row, if the Integration Service finds a
corresponding row in the target table (based on the primary key value),
the Integration Service deletes it. Note that the primary key constraint
must exist in the target definition in the repository.
Update Treat all rows as updates. For each row, the Integration Service looks for
a matching primary key value in the target table. If it exists, the
Integration Service updates the row. The primary key constraint must
exist in the target definition.
Data Integration Service follows instructions coded into Update Strategy and
Driven Custom transformations within the session mapping to determine how to
flag rows for insert, delete, update, or reject.
If the mapping for the session contains an Update Strategy
transformation, this field is marked Data Driven by default.
If you do not choose Data Driven when a mapping contains an Update
Strategy or Multigroup External Procedure transformation, the Workflow
Manager displays a warning. When you run the session, the Integration
Service does not follow instructions in the Update Strategy or Multigroup
External Procedure transformation in the mapping to determine how to
flag rows.

Table 28-2 describes the update strategy for each setting:

Table 28-2. Update Strategy Settings

Setting Use To
Insert Populate the target tables for the first time, or maintain a historical data
warehouse. In the latter case, you must set this strategy for the entire
 data warehouse, not just a select group of target tables.
Delete Clear target tables.
Update Update target tables. You might choose this setting whether the data
warehouse contains historical data or a snapshot. Later, when you
configure how to update individual target tables, you can determine
whether to insert updated rows as new rows or use the updated
information to modify existing rows in the target.
Data Exert finer control over how you flag rows for insert, delete, update, or
Driven reject. Choose this setting if rows destined for the same table need to be
flagged on occasion for one operation (for example, update), or for a
different operation (for example, reject). In addition, this setting provides
the only way you can flag rows for reject.

Specifying Operations for Individual Target Tables

Once you determine how to treat all rows in the session, you also need to set
update strategy options for individual targets. Define the update strategy options
in the Transformations view on Mapping tab of the session properties.

You can set the following update strategy options:

Insert. Select this option to insert a row into a target table.

Delete. Select this option to delete a row from a table.
Update. You have the following options in this situation:
Update as Update. Update each row flagged for update if it exists in
- the target table.
-
Update as Insert. Inset each row flagged for update.
-
Update else Insert. Update the row if it exists. Otherwise, insert it.
Truncate table. Select this option to truncate the target table before loading
data.

Update Strategy Checklist

Choosing an update strategy requires setting the right options within a session
and possibly adding Update Strategy transformations to a mapping. This section
summarizes what you need to implement different versions of an update
strategy.

Only perform inserts into a target table.

When you configure the session, select Insert for the Treat Source Rows As
session property. Also, make sure that you select the Insert option for all target
instances in the session.

Delete all rows in a target table.

When you configure the session, select Delete for the Treat Source Rows As
session property. Also, make sure that you select the Delete option for all target
instances in the session.
Only perform updates on the contents of a target table.

When you configure the session, select Update for the Treat Source Rows As
session property. When you configure the update options for each target table
instance, make sure you select the Update option for each target instance.

Perform different database operations with different rows destined for the same
target table.

Add an Update Strategy transformation to the mapping. When you write the
transformation update strategy expression, use either the DECODE or IIF
function to flag rows for different operations (insert, delete, update, or reject).
When you configure a session that uses this mapping, select Data Driven for the
Treat Source Rows As session property. Make sure that you select the Insert,
Delete, or one of the Update options for each target table instance.

Reject data.

Add an Update Strategy transformation to the mapping. When you write the
transformation update strategy expression, use DECODE or IIF to specify the
criteria for rejecting the row. When you configure a session that uses this
mapping, select Data Driven for the Treat Source Rows As session property.

Update Strategy

When there is a provision for "update as update", Update as insert" and "Update else
Insert" in the "Properties of sessions" -> "Targer Options" why do you need "Update
Strategy" transformation.

andrewconlan
1 posts since
Mar 8, 2004
Currently Being Moderated

Mar 8, 2004 3:01 PM in response to: srid pag

Update Strategy

The "update as update", "update as insert", "update else insert" provisions means that if a
row is tagged as an update it will perform the checked function.

If a row is tagged as an update and you have checked the "update as update" option then
PowerCenter will update the row by issuing an update statement.
If a row is tagged as an update and you have checked the "update as insert" option then
PowerCenter will insert the row by issuing an insert statement.

If a row is tagged as an update and you have checked the "update else insert" option the
PowerCenter will update the row if it exists in the target and insert it if it doesn't exist.
This option will take quite a bit of overhead.

The update strategy transformation is used to control how you want to tag rows (insert,
update, delete, reject). It is commonly used when working with slowly changing
dimensions.

Update Strategy

I very well understood this, I would like to know the difference between both.

What is update strategy doing by which we cannot do using "Target Load options" which
also have "Update as Update", "Update as Insert" and "Update else insert".

dclevenger
160 posts since
May 29, 2002
Currently Being Moderated

Mar 21, 2004 6:51 PM in response to: srid pag

Update Strategy

Hopefully this will shed additional light. The sole purpose of the Update Strategy
transformation is to help distinguish which type of DML row row the Server should
'create'. The sole function of the Target Load Option switches is to serve as 'release
mechanisms' to tell the Server which DML statement-types it should release to the
database for this run of the session.

Target Load Options Example:

Ignoring the Update Strategy for a few minutes, if you know in advance that all your
rows will be INSERT rows, then select 'Treat Source Rows as' = insert, and only insert
rows will be created, right? (Same for all updates, all deletes). The Target Load options in
the session are for the sole purpose of dictating whether those rows get physically
released from the Transformation engine, to the writer. If you created nothing but
INSERTS and UNcheck the Insert option on the Target Load options, the inserts simply
go nowhere -- they die in the engine. Not that you would DO that since nothing would get
loaded -- but that is the power of those switches.

In the case of inserts only, it does not matter what you select for updates or deletes
(uncheck them both, or not) because your mapping is creating nothing but inserts and
those switches are ignored. In the case of all deletes, the scenario is the same.

If you are creating updates only, you have the choice on how the Server should process
the updates as Andrew described. If you select 'updates as updates', the Server leaves
your updates as normal UPDATE DMLs. Like all inserts/all deletes, only that one switch
is important - should they or should they not get released? Similarly, if you have none of
the 3 update options checked, the transactions die.

Continuing on (switch power coming up), if you select 'update as insert' (rarely used)
switch them all to inserts. NOW the power of the insert switch matters ALSO. If you
have the Server convert them all to inserts - but uncheck insert - they all die. And nothing
gets loaded. Again, not that you would do that and in most cases you could just set them
as inserts to begin with.

If you select Update Else Insert -- the same 2 switches matter again. The Server creates
an UPDATE DML transaction. If the database can locate it, it does the update. If not, the
transaction goes back into the session engine. The Server switches it to an INSERT DML
statement, right? Again, if you UNchecked the insert option, the new INSERT statement
dies. It does not get released to the writer. THis of course is the laborious overhead
Andrew mentioned. Nice for testing but in production, lookups in advance of all this are
more efficient.

Now -- the Update Strategy transformation:

It simply allows you to write logic for the Server to do a row-by-row analysis to
distinguish which rows should be set as INSERTS, UPDATES, DELETES (or ignored),
based on the data on the row. Use the 'Treat Source Rows as' option = Data Driven, when
using it.

Result: You could end up with a mixture of row types -- but the Target Load options
ALWAYS still apply.
Example: a mapplet may contain Update Strategy logic that creates INSERTS,
UPDATES and DELETES -- but sometimes want to process only the DELETES, or only
the UPDATES. The next time you use the mapplet, you may want it for the first-of-the-
month run after you truncate a table, to run the new INSERT rows -- only. To process the
INSERTS only, simply UNcheck all update and delete Target Load Options and the
UPDATES and DELETES die.

Hope that clarifies.

bswarbrick
92 posts since
May 29, 2002
Currently Being Moderated

Sep 3, 2004 5:11 PM in response to: Dottie Clevenger

Update Strategy

I have a? on this. I have a mapping that does inserts 2 2 tables or uppdates. An audit is
also inserted in both cases. So I route my data and use an update stratgey. Pass 1 does 3
Inserts to 3 tables. Pass 2 does Updates to 2 and insert to one. (Without an update strategy
I marked the option as insert and selected the insert or update options on each target and
this does not work - should it?).

With the update strategy, in the second pass I was updating table 1 and table 2 and
inserting in table 3. The data came from the same expression so i made this
DD_UPDATE. In the target I set data driven and options of update as update, update as
update and update as insert for the targets. I got an error on table 3 saying 'insert not
allowed on table'. I then checked the insert option as well and this worked. But I can't
understand why. I select update as insert, why should I also select insert?

Thanks
saurabh_chopra
1 posts since
Mar 31, 2010
Currently Being Moderated

Jul 7, 2010 8:46 AM in response to: brian swarbrick

Awesome :) Clevenger, to add

Awesome Clevenger, to add to your explanation, its needed for rejected records ..
only possible way of dealing with them :P

~Saurabh