Structure of the DataStore Object

The DataStore object (advanced) consists of a maximum three tables: the inbound table, the change log
and the table of active data.
You might not need all three tables. This depends on how you want to use the DataStore object.

The data is initially loaded into the inbound table. The data is either read from the inbound table directly,
or it is activated first and then read from the table of active data. This depends on how the data is used.
The change log contains the change history for the delta update from the DataStore object to other data
targets.

Data Acquisition Layer

With the template for the data acquisition layer, a DataStore object (advanced) is created with fields.
No properties are selected under Modeling Properties:

This type of modeled object corresponds to a persistent staging area (PSA) and acts as an incoming
storage area in BW for data from source systems.

Corporate Memory
The corporate memory contains the complete history of the loaded data.
This displays an intermediate layer. The data is posted to other DataStore objects (advanced) that serve
as architected data marts. It is filled separately from the update in the architected data marts. The
template for the corporate memory is used to create a DataStore object (advanced) with InfoObjects or
fields. Fields are useful if you load data from external sources or if you want flexible modeling and you
only want to assign InfoObjects at a higher point in the data flow.
Corporate Memory Without Compression:
No properties are selected under Modeling Properties:

The requests are loaded into the inbound table and also extracted from it. The data is not aggregated.
When a query is executed, the inbound table is accessed. As the corporate memory mainly serves as a
source for reconstructions, we advise against performing reporting on this object. The query accesses the
data in the inbound table, which does not provide suitable data for reporting because of the technical key.
This type of modeled object corresponds to a write-optimized DataStore object (classic):

Corporate Memory with Compression:

Under Modeling Properties, the Activate/Compress Data property is selected:

The requests are also loaded into the inbound table here. The data is stored at granular level.
. Therefore you first need to update all the data (from the inbound queue) using delta, before you activate
the data. Here you should pay particular attention to compression. You should compress data if you are
certain that the data is consistent. This is because without a change log, you can only delete data
selectively after compression. Request-based deletion is not possible.
If the data is not required with this level of detail, it can be compressed in order to save space. Before you
compress the data, make sure that all the data has been updated from the inbound table using delta and
that all the data is consistent. During compression, the data is aggregated in accordance with the
semantic key and is written to the active data table. In the query, you will then only see the data that has

been compressed. To save memory space, the change log is not filled. Therefore you cannot perform
request-based deletion of data from the DataStore object. You can only delete data selectively.
When a query is executed, the active table is accessed:

Corporate Memory with Compression and Delta Loading:

Under Settings, the Keep Inbound Data, Extract from Inbound Table property is also selected:

This type of object also stores data at granular level. The data can be compressed, but is stored
redundantly in the inbound table in order to prevent the detailed information from being lost. This also
makes it possible to delete the data from the active table and to create it again from the inbound table.

The data is only extracted from the inbound table. When a query is executed, the active table is
accessed:

Data Propagation Layer

The data propagation layer provides a basis for further distribution and reuse of data.
With the template for the data propagation layer, the Activate/Compress Data and Write Change Log are
selected under Modeling Properties:

You can also choose the optional property Unique Data Records, if you are only loading unique data
records.

Requests are loaded into the inbound table. If you want to execute a query on these requests, they must
be activated first. The data is written to the active data table, and the history is stored in the change log.
The change log is also used for the rollback, so that activated requests can also be deleted again.
This type of modeled object corresponds to a standard DataStore object (classic). Unlike with InfoCubelike DataStore objects, this does not provide stable navigation during reporting. When a query is
executed, the active table is accessed:

Reporting Layer
The reporting layer contains the objects that are used to perform queries for analysis.
Reporting on active data only:
With the Reporting on active data only template, the Activate/Compress Data property is selected under
Modeling Properties:

Reporting on Active Data and Inbound Table:

With the Reporting on union of active table and inbound queue template, the Activate/Compress Data and
All Characteristics are Key, Reporting on Union of Inbound and Active Table properties are selected under
Modeling Properties:

This type of modeled object corresponds to a standard InfoCube.

The inbound table corresponds to the InfoCube's F table, while the active data table corresponds to the E
table.
Reporting on this type of DataStore object is consistent and provides stable navigation. A query can be
executed straight after loading. You do not need to compress it beforehand. You have to load deltas, for
example from another DataStore object (advanced). The data is aggregated, thus making it impossible to
overwrite key figures for example. As the change log is not filled, you cannot delete any data from the
DataStore object.
When a query is executed, the active table and the inbound table are accessed:

Modeling Properties
The modeling properties enable you to control how you use your DataStore object (advanced).
You can set the following modeling properties:
Activate/Compress Data
In general, the data is always written to the inbound table. If you choose Activate Data, the data is written
to the table for active data (during the activation/compression process) once it arrives in the inbound
table. There are three options:

Write Change Log: If you choose this option, the delta (new and changed records) is saved in the
change log. The change log is used to extract the delta. You can only delete data from the
DataStore object if the object has a change log.

Keep Inbound Data, and extract from Inbound Table: If you choose this option, no data is saved in
the change log. The extraction process always reads the data in the inbound table again - for
delta extraction or full extraction.

Unique Data Records: If you only load unique data records (data records with non-recurring key
combinations) into the DataStore object, you can select this property. This means the system
does not check whether the record already exists. You have to be sure that no duplicate records
are loaded. This means that the table of active data will only contain unique data records. Data
aggregation is not allowed.

All Characteristics are Key, Reporting on Union of Inbound and Active Table
If you select this property, all the characteristics are included in the key. The system accesses the inbound
table and the active table (using a union across both tables) in the query. In this case, you should only
load additive deltas. The data is aggregated. The properties are comparable with the InfoCube.
Inbound Table as Extended Table
If you use SAP IQ as extended storage for your BW system, you can set the Inbound Table as Extended
Table flag. This means that data is only saved in the persistency layer.

Currency Translation and Unit

Conversion
If you want to perform a currency translation or unit conversion in your DataStore object (advanced), there
are various ways to model this.
InfoObject-Based
If you model your DataStore object with InfoObjects, the reference between the key figures and the
associated currencies or units is guaranteed due to the InfoObject.
This is also recognized by a CompositeProvider, which is defined on the DataStore object.
Only Field-Based
If you only model your DataStore object using fields, then the key figures and currencies or units of
measure can be stored in a field of any type.
If the types are reporting-compatible, then the fields are visible in a CompositeProvider that is defined on
a DataStore object. This means:
A field with the data type quantity (QUAN) must have the following properties:
The length must be > 1 and < 31 and the decimal places >= 0.

 An aggregation behavior must be set.

It must reference a field of type UNIT. This field must have length 3 and cannot have any decimal
places.
A field with the data type currency (CURR) must have the following properties:
The length must be > 1 and < 31 and the decimal places >= 0.
An aggregation behavior must be set.
It must reference a field of type CUKY. This field must have length 5 and cannot have any decimal
places.
If the types are not reporting-compatible, then you need to create an Open ODS view on the DataStore
object, in order to perform the assignment.
Then you can create associations in the CompositeProvider. This allows you to create an assignment
between the key figure and currency/unit of measure field.
Field-Based with Metadata
If you only model your DataStore object using fields, then you can assign the type CURR to the key
figure, for which you want perform a currency translation, and assign the type CUKY to the currency. You
can assign the type QUAN to the key figure, for which you want to perform a unit conversion, and assign
the type UNIT to the unit of measure. You need to specify a field of type CUKY on the key figure.
An association with 0CURRENCY is added for the currency field in the BW back end.
The relationship between the key figure and the currency is then stored in the metadata and a
CompositeProvider defined on the DataStore object can derive the assignment from the relationship.