CLASSIC DATASTORE OBJECT VS ADVANCED DATASTORE OBJECT

There have been many architecture level changes in SAP BW/4HANA. One of this
change are data modeling based.
In this article we will walk through the various features and capabilities of ADSOs,
as well as explore how these capabilities help to optimize various tasks in your SAP
BW environment.
At first, we will talk about the classic DSO and his features. After that I will present
you the differences between the classic DSO and the new implemented ADSO.
DSO (DATA STORE OBJECT)
What is DSO?
A DSO is a two-dimensional storage unit which mainly stores transaction data or
master data on a lowest granularity. The data is stored at detailed level.
Types of DSO
When creating a DSO, you must choose the type:

When we create a DSO, the system sets a system ID of ‘SIDs Generation upon
Activation ‘by default. This option can be found in the edit mode settings of a DSO.
If we checked this option, the system will check the SID values for all the
characteristics in the DSO. If a SID value for the characteristic doesn’t exist, the
system will then generate the SIDs. If the SIDs are generated during the Activation,
this process will help the system to improve the runtime performance of a query.
In this way the system doesn’t have to generate SID’s at query runtime. SID values
are always stored in SID table of a InfoObject. Using this SID, the attributes and
texts of a master data InfoObject is accessed. The SID table is connected to the
associated master data tables via the char key.
The following Table shows you the properties of the different DSO types and
architecture:
ADSO (ADVANCED DATA STORE OBJECT)
The Advanced DSO manages to replace all these objects.

Before we create an ADSO we must know that it includes 3 main tables:

1. Inbound Table
 Activation queue table for classic DSO

 Uncompressed fact table of non-SAP HANA optimized InfoCube

 All records with are stored with a technical key
2. Table of Active Data
 Same as classic DSO, contains the current values after activation. The
key of the table is the DSO-Key (more about keys later)
 Compressed fact table of non-SAP HANA optimized InfoCube
3. Change Log
 Same as classic DSO

 Stores the difference between Inbound and Active-table

 Needed for Delta-generation

IMPORTANT STEPS IN CREATING A ADSO

We create an ADSO in the BWMT in Eclipse like all new Objects (in BW 7.5 you
have the possibility top create the classical objects still in SAP GUI, in BW4HANA
you can create only the new objects in BWMT).
In the General tab you will be able to configure activation settings and other
property. At first the user must write a description. After that we have the
possibility to choose a Model Template. In the ADSO you can behave like either
one of the objects from classic BW:

 Acquisition Layer
In this layer you can create objects that cover the “write-optimized” use cases for
classic DSO. It is divided into 3 other layers:
1. Data Acquisition Layer
 Corresponds to a persistent staging area (PSA) and acts as an
incoming storage area in BW for data from source systems
 No use of Active Table, so activation is not needed
 Requests will be loaded into and extracted from the inbound table
 All the records in the Inbound Table contain a Request Transaction
Number (TSN), Data packet, and Data record number
 The inbound (Old name = New Data / Activation Queue Table) table is
accessed to execute a BEx query and for extraction
 Data doesn’t get aggregated
2. Corporate memory with compression feature
 Requests will still be loaded into the inbound table

 Old requests that are no longer needed on detailed level can be

compressed into the active data table.
 To save memory space, the CM – compression ADSO doesn’t use a
Change Log table, only an Inbound Table and an Active Data Table.
  As soon as a load request is activated, the system loads the data into
the Active Table and deletes it from the Inbound Table
 If there are 2 records with the same key, BW/4HANA overwrites all
the characteristics of the record with the characteristics of the lastly
loaded record.
3. Corporate memory with reporting option
 A difference between this template and the “Corporate memory with
compression feature” template is that, the system does not erase data
from the Inbound Table. Instead, the data also remain in the Inbound
Table so that none of the technical information is lost.
 The CM reporting template has no Change Log though
 Another difference is that the data is not extracted from the Active
Table but from the Inbound Table
 Because the data remain in the Inbound Table after activation, these
ADSOs are a good solution for you when you want to store data but save
space by not using a Change Log
 Propagation Layer
 Provides a basis for further distribution and reuse of data
 Corresponds to a standard DataStore object (classic)
 Requests will be loaded into the inbound table
 For reporting the user must activate the loaded requests
 The data is then transferred into the active data table and the deta is
stored in the change log
 The change log is also used to rollback already activated request
 Reporting Layer
 Used to perform queries for analysis
 Corresponds to a standard InfoCube
 The inbound table acts as “F”-table and the active data table as “E”-
table
 It does not have a Change Log. If the Change log table do not exist the
Delta process cannot be done.
 After activation, the Inbound Table is empty
  The user reports on a union of the inbound table and the active data
table
 Planning Layer
It splits in 2 other layers:
1. Planning on Direct Update
 Data is automatically loaded into the Active table, so no need for
activation
 It has no Change Log or Inbound Table
 You can fill the Active table with an API
 also load data to this type of ADSO using a DTP
 Only have an Overwrite option. No summation of key figures like
there is in the Planning on Cube-like ADSO
2. Planning on Cube-like
 Has an Inbound Table and an Active Table

 All characteristic fields are marked as key fields in the Active Table,
which is a necessary requirement to make it suitable for planning.
 Only have a Summation option
PROCESS OF SID GENERATION HIGHLY OPTIMIZED FOR HANA
With the goal to optimize the performance, in BW/4HANA it is possible to set a flag
not only on InfoProvider level, but individually per characteristic of the DSO. The
data integrity check then is only executed on the selected characteristic.

InfoObjects/Fields
As a new feature, you can use fields with simple data types instead of InfoObject.
To do so, go to the Details tab and click the Add Field button. Under Identify, you
can specify in the “With” dropdown menu whether you want to use an InfoObject
or a Field for the definition.
In BW the user can choose whether he is modeling with InfoObjects or fields.
Modelling with InfoObjects brings extra effort, but also brings a lot of advantages.
Before you choose one of this option, you should consider the advantages and the
disadvantages of both of this modeling options.
In the following I will present you a part of the advantages and disadvantages
when you choose the option of modeling with fields:
ADVANTAGES WHEN USING FIELDS:
 If the query contains fields, it can be processed key-based in SAP HANA
 Using fields can enhance the flexibility and range of the data warehouse,
when the data volume is small.
DISADVANTAGES WHEN USING FIELDS
 The services for InfoObjects (attributes and hierarchies for example) are not
available for fields.
  Validity characteristics for DataStore objects (advanced) with non-
cumulative key figures must be InfoObjects.
 InfoObject attributes must be InfoObjects
 A field-based key figure cannot be an exception aggregation
 Planning queries on DataStore objects (advanced) are only supported with
fields as read-only
 If fields are used in the query, the InfoProviders can only be read
sequentially
 In the query on a CompositeProvider, not all data types for fields are
supported (ex. maximum length for fields is 20 characters)

Defining Keys for a ADSO

Also, in this tab we select which fields make up the keys of our ADSO. To define a
key, click on Manage Keys button.
KEY FIELDS
There are 2 types of keys: Primary and Foreign key
Advantages of using Key fields:
 uniquely identify a record in a table.
 Key Fields cannot be NULL
 Used to link two tables
 Main purpose of a foreign key is data validation.
 Read Master Data: using the input field value as a key, you can read the
value of a Characteristic attribute belonging to a specified Characteristic
 Read from advanced DataStore: using the input field value(s) as a
(compounded) key, you can read the data fields of a specified advanced
DataStore Object (DSO)
 Somethings that you don’t wish for is that, 2 records with the same key,
BW/4HANA overwrites all the characteristics of the record with the
characteristics of the lastly loaded record

Disadvantage of not using Key fields:

 Records are not uniquely identified =>Duplicates records allowed
 Performance affected

BENEFITS OF USING A ADSO INSTEAD OF A CLASSIC DSO:

 Simplification of object types
 Can behave like 4 Objects from the classic BW
 Flexibility in data modeling
 Modeling your ADSO using the Reporting Layer settings
 Performance of data loads and activation is optimized for HANA as ADSO is a
HANA native object.