A)I would like to know the difference between Additive Delta

and New Status for changed records considering below

shown scenario with effect in Infocube and DSO. I have gone
through the SDN but my doubts aren't cleared fully.

First I have posted this record

CCode DocNo Item. Price Curr.
1000 - 10031 - 10 - 200,00 - INR

Than there is a change in price and following record gets

posted.
CCode DocNo Item. Price Curr.
1000 - 10031 - 10 - 170,00 - INR

I would like to know what will be effect if record gets posted

to DSO as well as Infocube.

Ans1)) In additive delta You will get Difference = second

record- first record = 17000-20000 = -3000

in New Status for changed records you will get chaged

record = 17000.
In additive delta, you can add record direct to cube but not in
ods because in ods it will overwrite = 20000(old) and it is
overwrite by -3000 which will be wrong.

in new status record, you have to update in ods, it will give

you
20000+(before image\change)
20000- (reverse image\ change)
17000+(after image\change)
17000+
in Ods.

with New Status for changed records , you can not add to
cube otherwise it will be wrong = 20000+17000 =
37000(addition)

1)Delta Transfer into BW 

The following update modes are at your disposal in the BW Scheduler:

        Full Update
A Full Update requests all data that meet the selection criteria set in the Scheduler.
        Delta Update
A Delta Update only requests data that has appeared in the source system since the last load.
        Initializing the Delta Process
You need to initialize a delta method before it can work. The initialization selections are taken for
the loading of delta records.
2)To get a clear defination of BW recordmode:
SE11, data type RODMUPDMOD -> click Documentation

RODMUPDMOD
____________________________________________________
Short Text
BW Delta Process: Record Mode

Definition
This attribute describes how a record is updated in the delta process. The various delta processes
support different combinations of the seven possible characteristic values. If a DataSource implements a
delta process that uses several characteristic values, the record mode must be a part of the extract
structure and the name of the corresponding field has to be entered in the DataSource as a cancellation
field (ROOSOURCE-INVFIELD).

The seven characteristic values are as follows:

‘ ‘: The record delivers an after image.

The status is tranferred after something is changed or added. You can update the record into an
IncoCube only if the corresponding before image exists in the request.

‘X’: The record delivers a before image

The status is transferred before data is changed or deleted.

All record attributes that can be aggregated have to be transferred with a reverse +/- sign. The reversal
of the sign is carried out either by the extractor (default) or the Service API. In this case, the indicator
‘Field is inverted in the cancelation field’ must be set for the relevant extraction structure field in the
DataSource.
These records are ignored if the update is a non-additive update of an ODS object.
The before image is complementary to the after image.

‘A’: The record delivers an additive image.

For attributes that can be aggregated, only the change is transferred. For attributes that cannot be
aggregated, the status after a record has been changed or created is transferred. This record can replace
an after image and a before image if there are no non-aggregation attributes or if these cannot be
changed. You can update the record into an InfoCube without restriction, but this requires an additive
update into an ODS Object.

‘D’: The record has to be deleted.

Only the key is transferred. This record (and its DataSource) can only be updated into an ODS Object.

‘R’: The record delivers a reverse image.

The content of this record is the same as the content of a before image. The only difference is with an
ODS object update: Existing records with the same key are deleted.

‘N’: The record delivers a new image.

The content of this record is the same as for an after image without a before image. When a record is
created, a new image is transferred instead of an after image.
The new image is complementary to the reverse image.

The table RODELTAM determines which characteristic values a delta process uses (columns UPDM_NIM,
UPDM_BIM UPDM_AIM, PDM_ADD UPDM_DEL and UPDM_RIM). The table ensures that only useful
combinations of the above values are used within a delta process.

When extracting in the ‘delta’ update mode in the extracted records for the indicator, a DataSource that
uses a delta process can deliver only those characteristic values that are specified in the delta process.

Definition
This indicator describes how a record in the delta process is updated. The various delta processes
support different combinations of the seven possible characteristic values. If a DataSource implements a
delta process that uses several characteristic values, the indicator must be a part of the extract structure
and be entered in the DataSource as a cancellation field (ROOSOURCE-INVFIELD).

The seven characteristic values are as follows:

‘ ‘: The record delivers an after image.

The status is tranferred after something is changed or added. You can update the record into an
IncoCube only if the corresponding before image exists in the request.

‘X’: The record delivers a before image

The status is transferred before data is changed or deleted.

All record attributes that can be aggregated have to be transferred with a reverse +/- sign. The reversal
of the sign is carried out either by the extractor (default) or the Service API. In this case, the indicator
‘Field is inverted in the cancelation field’ must be set for the relevant extraction structure field in the
DataSource.
These records are ignored if the update is a non-additive update of an ODS object.
The before image is complementary to the after image.

‘A’: The record delivers an additive image.

For attributes that can be aggregated, only the change is transferred. For attributes that cannot be
aggregated, the status after a record has been changed or created is transferred. This record can replace
an after image and a before image if there are no non-aggregation attributes or if these cannot be
changed. You can update the record into an InfoCube without restriction, but this requires an additive
update into an ODS Object.

‘D’: The record has to be deleted.

Only the key is transferred. This record (and its DataSource) can only be updated into an ODS Object.

‘R’: The record delivers a reverse image.

The content of this record is the same as the content of a before image. The only difference is with an
ODS object update: Existing records with the same key are deleted.

‘N’: The record delivers a new image.

The content of this record is the same as for an after image without a before image. When a record is
created, a new image is transferred instead of an after image.
The new image is complementary to the reverse image.

‘Y’: The record is an update image.

This kind of record is used in the change log of an ODS object in order to save the value from the update.
This is for a possible rollback and roll- forward for key figures with minimum or maximum aggregation.
This record also has the update value for characteristics (in this case, it is the same as the after image).
Null values are stored for key figures with totals aggregation. An update image is only required when the
value from the update is smaller or larger than the before image for at least one key figure with
minimum or maximum aggregation.

Table RODELTAM determines which characteristic values a delta process uses (columns UPDM_NIM,
UPDM_BIM, UPDM_UIM, UPDM_AIM, UPDM_ADD, UPDM_DEL and UPDM_RIM). The table has to
ensure that only meaningful combinations of the above values are used within a delta process.

When extracting in the Delta update mode in the extracted records for the record mode, a DataSource
that uses a delta process can deliver only those characteristic values that are specified in the delta
process.

3)delta
Direct Delta:In case of Direct Delta LUW's are directly posted to Delta Queue(i.e. RSA7)
and we extract the LUW's from Delta Queue to BW side by running Delta Loads. If we
use Direct Delta it degrades the OLTP system performance because when LUW's are
directly posted to Delta Queue (RSA7) the application is kept waiting until all the
enhancement code is executed.Queued Delta:In case of Queued delta LUW's are posted
to Extractor Queue (LBWQ), by scheduling the V3 job we move the documents from
Extractor queue to Delta Queue(i.e. RSA7) and we extract the LUW's from Delta Queue
to BW side by running Delta Loads. Generally we prefer Queued Delta as it maintain the
Extractor Log which us to handle the LUW's which are missed.Serialized V3 Update:In
case of Serialized V3 delta LUW's are posted to Update Queue (SM13), by scheduling the
V3 job we move the documents from Update queue to Delta Queue(i.e. RSA7) in a
serialized fashion and we extract the LUW's from Delta Queue(RSA7) to BW side by
running Delta Loads. Since the LUW's are moved in a serialized fashion from Update
queue to Delta queue if we have any error document it doesn't lift the subsequent
documents and as it sorts the documents based on the creation time, there every
possibility for frequent failures in V3 job and missing out the delta records. it also
degrades the OLTP Performance as it forms multiple segments with respective to the
change in the language

4)Example for Activating and Updating Data  

The graphic below shows how data is updated in a DataStore object and the effect of the activation step.

...
       1.      Request 1 with amount 10 and request 2 with amount 30 are loaded parallel into the DataStore
object. This takes you to the activation queue. You are given a unique request ID there.

       2.      When you carry out the activation step, the requests are sorted by key, transferred into the
table containing the active data, and immediately deleted from the activation queue. In the table
containing the active data, the amount 10 is replaced by 30 (since Overwrite is set as the update type).

       3.      When you activate the data, the change log is also notified: The old record from the active
table is saved as a negative (-10) and the new record is stored as a positive (+30).

       4.      If all the records are activated, you can update the changes to the data records for the
DataStore object in the related InfoProvider in a separate step. The amount in this example is increased
in the related InfoProviders by 20.

What is the Star Schema ?

The star schema (sometimes referenced as star join schema or simply dimensional model) is the
simplest data warehouse schema, consisting of a single "fact table" with a compound primary
key, with one segment for each "dimension" and with additional columns of additive, numeric facts.
The name star schema is derived from the fact that the schema diagram is shaped like a star.
Why the Star Schema ?
The star schema makes multi-dimensional database (MDDB)functionality possible using a
traditional relational database. Because relational databases are the most common data
management system in organizations today, implementing multi-dimensional views of data using a
relational database is very appealing. Even if a specific MDDB solution is used, its sources likely are
relational databases.
Another reason for using star schema is its ease of understanding. Fact tables in star schema are
mostly in third normal form (3NF), but dimensional tables are in de-normalized second normal form
(2NF). If you want to normalize dimensional tables, they look like snowflakes (see snowflake
schema) and the same problems of 3NF databases arise - you need complex queries and business
users cannot easily understand the meaning of data. Although query performance may be improved
by advanced DBMS technology and hardware, highly normalized tables make reporting difficult and
applications complex.

5) loading data cube

These days, I have been doing a lot of exploring on the SAP Business Warehouse. I did some posts
on SAP Infocubes and SAP BW basicsearlier. Today, I am covering "How to Load Data into
Infocube". Loading data in Infocube involves a series of steps. For the sake of convienence of the
readers, below I have listed down the steps involved in loading data in infocube with a short
description of each of the steps.

1. Creating a Source System - SAP Business Warehouse uses a protocal to find and extract data using
the source system. BW can accept data from SAP R/3, BW solutions, Flat files and other third party
tools.

2. Using Application Components - SAP BW uses application components to organize Infosources.

Application components are arranged in a tree structure and are similar to infoareas in BW infocubes.

3. InfoSource for Data Characteristic - In SAP BW, extracting, transferring, transforming and loading
data is a complex process. Infosources in addition to transfer rules are used in BW in the way in which
the data loading happens.

4. InfoPackages to Load Characteristics data - A characteristic in SAP consists of master data, text and
hierarchy. This master data can also be entered manually in BW. Infopackages are used in selecting,
transfering and loading chracteristics datain BW.

5. Infosources and InfoPackage for transaction data - This final step involves creating an infosource
for transactional data. At the time of creation of an infosource, one needs to select transaction data
rather than master data. Once this is set up, infopackages can be used to upload the transaction data
into BW. Infopackages simply specify how and when the data is loaded.

6} I am looking at the update mode in the

transfer structure. 
There are 3 types. 
1. Full Upload 
2. Latest status of changed records. 
3. Additive delta. 

There is also a update tab on the infopackage. 

1. Full Update 
2. Delta Update 
3. Initaialise delta process (with / without data) 

I am setting up a data model loading transaction data from flat file to psa to ods to an infocube. 

My questions are as follows. 

1. what does "latest status of changed records" mean and please give a business example of when it
would be used. 
2. What does additive data mean and please give a business example of when it would be used? 
3 I was looking at full update and assume this takes all the data in your datasource selection criteria.
When would this be used in comparison to a delta initialize? 
4. What is the connection between the transfer structure update mode and the infopackage update
mode tab. Obviously both need setting. What are the realtionships? 

Hello, 

Let's do it simple : 

You use Full Load when you : 

- just do a one shot of an extraction 
- or when you are sure that you will get only new data (can be day after day, and no data for the
previous were modified or deleted) 
This can be used for FI purposes. Fiscal period after fiscal period (by example), you can do a Full Load
of this fiscal period, because the FI documents may not be modified. 

You use Last Status, when : 

- you may load once a document (Sales Order quantity 120 pce) 
- then with another load, the same document comes again, it is modified and you do not get the
modification but the last situation (sames Sales Order with now quantity 150 pce). 
If you push that to a cube, your final quantity may be 270 pce, and you do not want that. With Last
Status, you can update the ODS, then get the delta done inside BW. 

You use Additive Data when 

- with the same situation above, your new extraction does not contain the new situation, but its
evolution. So, the new extract would contain + 30 pce. That can be pushed to a cube directly. 

So, everything depends on the delta capabilities of your extractor. Maybe you do not need a delta (like
for FI documents), maybe you can not get it (Last Status), maybe you have it (Additive data). 

Depending on the situation, then you always do a Full Update (FI documents again), or ypu need to
Initialize a Delta procedure to : 
- occur a delta inside BW with the ODS (Last Status) 
- accept a delta done in the source system (Addivite delta) 

So, you would get an image or initial situation of the first load from your source system, then get/build
the delta.