Sie sind auf Seite 1von 6

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.