DataStore Objects (DSOs)

Definition

A DataStore object serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level.

This data can be evaluated using a BEx query.

A DataStore object contains key fields (such as document number, document item) and data fields that, in addition to key figures, can also contain character fields (such as order status, customer). The data from a DataStore object can be updated with a delta update into InfoCubes (standard) and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.

Unlike multidimensional data storage using InfoCubes, the data in DataStore objects is stored in transparent, flat database tables. The system does not create fact tables or dimension tables.

Use

Overview of DataStore Object Types

Type	Structure	Data Supply	SID Generation	Details	Example
Standard DataStore Object	Consists of three tables: activation queue, table of active data, change log	From data transfer process	Yes	Standard DataStore Object	Operational Scenario for Standard DataStore Objects
Write-Optimized DataStore Objects	Consists of the table of active data only	From data transfer process	No	Write-Optimized DataStore Object	Operational Scenario for Write-Optimized DataStore Objects
DataStore Objects for Direct Update	Consists of the table of active data only	From APIs	No	DataStore Objects for Direct Update	Operational Scenario for DataStore Objects for Direct Update.

Management of DataStore Objects 

Features

The DataStore object is displayed in the top table. You only have to select a DataStore object from the DataStore objects available if you called DataStore object administration from the monitor.

In the top toolbar, choose Contents to display the contents of the table of active data for the DataStore object you have selected. With Delete Contents, you can delete the contents of the DataStore object. You can also display an application log and a process overview.

Tab Page: Contents

You can display the content of the change log table, the newly loaded data table (activation queue), or the active data (A table). You can also selectively delete requests from the DataStore object.

Tab Page: Requests

This tab page provides information about all requests that have run in the DataStore object. You can also delete requests here or schedule an update.

Tab Page: Reconstruction

You use this function to fill a DataStore object with requests that have already been loaded into the BI system or into another DataStore object. This function is only necessary for DataStore objects that obtained their data from InfoPackages.

Tab Page: Archiving

If you have created a data archiving process, you see this additional tab page.

Automatic Further Processing

If you still use a 3.x InfoPackage to load data, you can activate several automatisms to further process the data in the DataStore object. If you use the data transfer process and process chains that SAP recommends you use, you cannot however use these automatisms.

We recommend that you always use process chains.

If you choose the main menu path Environment → Automatic Request Processing, you can specify that the system automatically sets the quality status of the data to OK after the data has been loaded into the DataStore object. You can also activate and update DataStore data automatically. Data that has the quality status OK is transferred from the activation queue into the table of active data, and the change log is updated. The data is then updated to other InfoProviders.

You can also make these settings when you create DataStore objects.

*****************************************************************************

Only switch on automatic activation and automatic update if you are sure that these processes do not overlap.

****************************************************************************

Delete Change Log Data

You can delete data from the change log. To do this, choose Environment → Delete Change Log Data in the main menu.

Persistent Staging Area (PSA)

The Persistent Staging Area (PSA) is the inbound storage area in BI for data from the source systems. The requested data is saved, unchanged from the source system.

Request data is stored in the transfer structure format in transparent, relational database tables in BI. The data format remains unchanged, meaning that no summarization or transformations take place, as is the case with InfoCubes.

****************************************************************************

When loading flat files, the data does not remain completely unchanged, since it is adjusted by conversion routines, where necessary (for example, the date format 31.21.1999 is converted to 19991231 in order to ensure uniformity of data). 

****************************************************************************

You determine the PSA transfer method in transfer rule maintenance.

If you set the PSA when you are extracting data, you get improved performance if you use TRFCs for loading the data. The temporary storage facility in the PSA also allows you to check and change the data before the update into data targets. Coupling the load process for further processing in BI also contributes to an improved load performance. In contrast to a data request with IDocs, a data request in the PSA also gives you various options for further updating data to the data targets. Coupling the load process for further processing in BI also contributes to an improved loading performance. If errors occur when data is processed further, the operative system is not affected.

The PSA delivers the backup status for the ODS (until the total staging process is confirmed). The duration of the data storage in the PSA is medium-term, since the data can still be used for reorganization. However, for updates to ODS objects, data is stored only for the short-term.

In the PSA tree of the Administrator Workbench, a PSA is displayed for every InfoSource. You get to the PSA tree in the Administrator Workbench using either Modeling or Monitoring. The requested data records appear, divided according to request, under the source system they belong to for an InfoSource in the PSA tree.

Features

The data records in BI are transferred to the transfer structure when you load data with the transfer method PSA. One TRFC is performed for each data package. Data is written to the PSA table from the transfer structure, and stored there. A transparent PSA table is created for each transfer structure that is activated. The PSA tables each have the same structure as their respective transfer structures. They are also flagged with key fields for the request ID, the data package number, and the data record number.

Since the requested data is stored unchanged in the PSA, it may contain errors if it contained errors in the source system. If the requested data records have been written to the PSA table, you can check the data for the request and change incorrect data records. 

Depending on the type of update, data is transferred from the PSA table into the communication structure using the transfer rules. From the communication structure, the data is updated to the corresponding data target.

Using partitioning, you can separate the dataset of a PSA table into several smaller, physically independent, and redundancy-free units. This separation can mean improved performance when you update data from the PSA. In the BW Customizing Implementation Guide, under Business Information Warehouse → Connections to Other Systems → Maintain Control Parameters for Data Transfer,you determine the number of data records from which you want to create a partition. Only data records from a complete request are stored in a partition. The specified value is a threshold value.

******************************************************************************

As of SAP BW 3.0, you can use the PSA to load hierarchies from the DataSources released for this purpose. The corresponding DataSources will be delivered with Plug-In (-A) 2001.2, at the earliest. You can also use a PSA to load hierarchies from files.

****************************************************************

Constraints

The number of fields is limited to a maximum of 255 when using TRFCs to transfer data. The length of the data record is limited to 1962 bytes when you use TRFCs.

Data transfer with IDocs cannot be used in connection with the PSA.

InfoProviders

Definition

Generic term for BI objects into which data is loaded or that display views of data. You analyze this data in BEx queries.

Use

InfoProviders are different metaobjects in the data basis that can be seen within query definition as uniform data providers. Their data can be analyzed in a uniform way. The type of data staging and the degree of detail or "proximity" to the source system in the data flow diagram differs from InfoProvider to InfoProvider. However, in the BEx Query Designer, they are seen as uniform objects.

The following graphic shows how InfoProviders are integrated in the dataflow:

Structure

The term InfoProvider encompasses objects that physically contain data:

InfoCubes

DataStore objects

InfoObjects as InfoProviders

Staging is used to load data into these InfoProviders.

InfoProviders can also be objects that do not physically store data but which display logical views of data, such as:

VirtualProviders

InfoSets

MultiProviders

 

Aggregation levels

The following figure gives an overview of the BI objects that can be used in analysis and reporting. They are divided into InfoProviders that contain data and InfoProviders that only display logical views and do not contain any data. In BEx, the system accesses an InfoProvider; it is not important how the data is modeled.

InfoCubes :

InfoCubes are data targets. They describe (from a reporting point of view) a self-contained business-orientated dataset. They can also be seen as InfoProviders if reports and analyses in BW are executed using them.

Only BasicCubes physically contain data in the database. Virtual InfoCubes simply display logical views of a dataset. The type of InfoCube is not important as far as reporting is concerned, as the user cannot distinguish between the two.

Transactional InfoCubes are used only in conjunction with SEM. The data from this kind of InfoCube can be accessed on a read/write basis, allowing users to perform transactions to update the data within the infocube as they wish. Standard InfoCubes differ in that they only allow the user to read-only access.

A RemoteCube is an InfoCube whose transaction data is managed externally outside SAP BW. Only the structure of the RemoteCube is defined in BW. The data is read for reporting using a BAPI from an external system.
An SAP RemoteCube is a RemoteCube that allows the definition of queries with direct access to transaction data in other SAP systems (R/3 for example). The Master data and hierarchies associated with these SAP RemoteCubes are replicated between the other SAP system and BW enabling faster execution of the users queries

A virtual InfoCube with services is an InfoCube that does not have its own physical data storage in BW. A user-defined function module is used as the DataSource. This type of InfoProvider is used primarily in the SAP SEM application.

InfoSets :

An Infoset is a specific kind of InfoProvider that does not contain data itself, but describes two or more data targets that are joined using rules. The data targets can be of type ODS Objects and/or InfoObjects (characteristics with master data).
If one of the InfoObjects contained in the join is a time-dependent characteristic, the join itself becomes time-dependent or a temporal join.

• You can include every ODS object and every InfoObject of the type Characteristic with Master Data in a join.
• A join can contain either the same type of object or different types of objects.
• You can include individual objects in a join, as many times as you want.
• Objects in the join are linked using join conditions (equal join conditions).
• A join condition determines the combination of individual object records included in the result set.

ODS (Operational Data Store) Objects :

An ODS Object stores consolidated datasets and cleansed transactional data from one or more InfoSources on a document (atomic) level. You can analyse this dataset in a BEx query or an InfoSet query.

An ODS object contains key fields (for example, Employee number) and data fields that can also contain character fields (for example, Absence Type, Days Absence) as key figures. An ODS object can act as a Data Mart and be used as an Infosource to update InfoCubes and/or other ODS Objects in the same system or across different systems.

Data is stored in an ODS object in transparent tables (flat database tables) which differs from Infocubes that use a multi-dimensional model. Fact tables and dimension tables are not created.

As with Infocubes, ODS support cumulative updates of key figures, but with ODS objects it is also possible to overwrite data. This is particularly important with document-related structures, since changes made to documents in the source system do not apply solely to numeric fields such as Days Absence, but also to non-numeric fields such as Sickness Reason.

MultiCubes / MultiProviders :

A MultiProvider is a type of InfoProvider that combines data from a number of InfoProviders and makes them available as a whole to reporting. The MultiProvider does not itself contain any data. Its data comes exclusively from the InfoProviders on which it is based. These are combined using a union operation.

The following objects can be combined to form a MultiProvider:
InfoCubes ODS Objects InfoObjects InfoSets

Characteristics:
A characteristic can be an InfoProvider if it has master data and is assigned to an InfoArea. By default, Characteristics are not configured as InfoProviders. They must be explicitly defined as an InfoProvider in the InfoObject maintenance.

Additional Functions in InfoObject Maintenance

Functions

There are other functions available in the InfoObject maintenance in addition to creating, changing, and deleting InfoObjects.

 Documents

This function allows you to display, create or change documents for InfoObjects.

See: Documents.

 Display in Tree

Use this function to display, in a clear tree structure, all the settings for an InfoObject that have been made in the InfoObject maintenance tab pages.

 Version Comparison

This function compares the following InfoObject versions:

·  the active and revised versions of an InfoObject

·  the active and Content versions of an InfoObject

·  the revised and Content versions of an InfoObject

This enables you to compare all the settings made in the InfoObject maintenance tab pages.

 Transport Connection

You can choose and transport InfoObjects. All BW Objects that are needed to ensure a consistent status in the target system are collected automatically.

 Where-Used List

You determine which other objects in BW also use a specific InfoObject.

You can determine what effects changing an InfoObject in a particular way will have, and whether this change is permitted at the moment or not.

Analyzing InfoObjects

You get to the analysis and repair environment by choosing Edit InfoObject from the main menu. You can use the analysis and repair environment to check the consistency of your InfoObjects. 

See Analysis and Repair Environment

Object Browser Using AWB

Using this function in the main menu by means of Environment  → Object Browser Using AWB, you can display the connection between the different BW objects.

For example:

·  Structural dependencies, for example the InfoObjects, from which an InfoCube is structured.

·  Connections between BW objects, such as the data flow from a source system across an InfoCube to a query.

The dependencies can be displayed and exported in HTML format.

Hyperlinks

Technical objects, such as data elements or attributes, are often underlined in the InfoObject maintenance. In this case, use the context menu (right mouse click) to call up a selection of possible functions, including jumping to the detail view (dictionary), table contents, table type, and so on. Double-click to get to the detail display.

Activating in the Background

In some cases (for example when converting large amounts of data), activating an InfoObject can take a very long time. The activation process terminates after a specified amount of time. In these cases, you can activate InfoObjects with the help of a background job. In the InfoObject maintenance, choose Characteristic → Activate in Background.

Maintaining Database Save Parameters

With characteristics: Use this setting to determine how the system handles the table when it creates it in the database: You can access the function using Extras in the main menu. For more information, see DB Save Parameters

Creating InfoObjects: Key Figures :

Procedure

  1.  In the context menu of your InfoObject catalog for key figures, select Create InfoObject.

  2.  Enter a name and a description

  3.  If necessary, define a reference key figure or a template InfoObject.

Template InfoObject: If you choose a template InfoObject, copy its properties to your new key figure so that you can edit them.

Reference key figure: With a reference key figure, the original value is filled from the referenced key figure. However, it is calculated differently with this key figure (either with other aggregations or with Elimination of Internal Business Volume in the query). When creating update rules, a key figure with a reference is not offered. Therefore, it is not possible to create update rules.

  4.  Confirm your entries.

  5.  Edit Tab Page: Type/Units.

  6.  Edit Tab Page: Aggregations.

  7.  Edit Tab Page: Additional Propertiess.

  8.  If you created your key figure with a reference, you get an additional Elimination tab page.

  9.  Save and activate the key figure you have created.

*******************************************************************************

Key figures have to be activated before they can be used.

Save means that all changed key figures in the InfoObject catalog are created, and that the table entries are saved. However, they cannot be used for reporting in InfoProviders yet. The older active version is retained initially.

The system only creates the corresponding data dictionary objects (data elements, domains, programs) after you have activated the key figure. Only then do the InfoProviders use the activated, new version.

*******************************************************************************

Step1: Select the Key figure catalog and right click and select create InfoObject 

 

 

èStep2: Give the technical name and description for key figure. Mention the template key figure to be used if any 

 

 

èStep3: In ‘Type/Unit’ tab you specify the key figure properties like data type quantity or amount etc. and relevant unit 

èStep4: In ‘Aggregation’ tab you specify the aggregation method for the key figure (summation, average etc) 

 

 

èStep5: In ‘Additional Properties’ tab you specify the display properties. These properties are applicable to display of data in reports. 

 

 

Creating InfoObjects: Characteristics

Procedure

  1.  In the context menu of your InfoObject catalog for characteristics, select Create InfoObject.

  2.  Enter a name and a description

  3.  Specify a reference characteristic or a template InfoObject. If you choose a template InfoObject, you copy its properties and use them for the new characteristic. You can edit the properties as required. For more information about reference characteristics, see Tab Page: Compounding in the Reference InfoObject section.

  4.  Confirm your entries.

  5.  Maintain Tab Page: General. You have to enter a description, data type and data length. The following settings and tab pages are optional.

Maintain Tab Page: Business Explorer

Maintain Tab Page: Master Data/Texts

Maintain Tab Page: Hierarchy

  6.  Maintain Tab Page: Attributes. This tab page is only available if you have set the With Master Data indicator on the Master Data/Texts tab page.

Maintain Tab Page: Compounding

  7.  Save and Activate the characteristic you have created.

*****************************************************************************

Before you can use characteristics, they have to be activated.

If you choose Save, the system creates all the characteristics that have been changed and saves the table entries. However, they cannot be used for reporting in InfoProviders yet. If there is an older active version, this is retained initially.

The system only creates the relevant objects created in the data dictionary (data elements, domains, text tables, master data tables, and programs) after you have activated the characteristics. Only then do the InfoProviders use the activated, new version.

In InfoObject maintenance, you can switch between any D, M, or A versions that exist for an InfoObject at any time.

*****************************************************************************

Step 1)

1. Go to transaction code RSA1 to go to the Data Warehouse Workbench.
2. Click the OK button.

 

Step 2)

1. Navigate to Modeling -> Infoobjects
2. Right click on the Characteristic InfoObject Catalog and choose the option “Create InfoObject” as shown below.

Step 3)

1. Give Technical name of the characteristics
2. Give a meaningful Description
3. Reference Characteristics is mentioned if the new characteristic to be created has the same technical properties of some other already existing characteristic.( LCOSTC)
4. Template is specified if the new characteristic to be created has some of the technical properties of an already existing characteristic. (LCOSTC)
5. Hit the enter button.

On completion of the above step, it takes you to the “Edit Screen” of the Infoobject. The Infoobject “Edit Screen” has 6 Tab pages listed below.

1. General
2. Business Explorer
3. Master Data/Texts
4. Hierarchy
5. Attribute
6. Compounding

Let us see each of the tab pages individually.

Tab Page: General

In this Tab Page, enter the following

1. The Technical name of the InfoObject
2. Enter the long and Short description
3. Enter the data type
4. Enter the length.

All other settings in this tab and other tabs are optional.

Tab Page: Business Explorer

1. Each and every setting in the Business Explorer tab page is to set default values in the Business Explorer.
2. The Display:”Text” setting on this page decides whether the value of the characteristic is displayed as a textual description or as a key in the Business Explorer.

Tab Page: Master Data/Texts

1. The Check box “With Master Data checkbox” and/or “With Texts” has to be selected for Master Data bearing Infoobject. By selecting any of these checkboxes, the characteristic is designed to bear master data and it has its own master data tables.
2. If the characteristic needs its own texts, you need to make at least one text selection. The text can be short, medium or long text with 20, 40, or 60 characters respectively.

In the screen shot shown below, the Characteristic has master data table(With master data check box is checked) but does not have Text table(With Texts is unchecked).

Tab Page: Hierarchy

A hierarchy indicates a parent-child relationship which consists of several nodes and leaves.

On the Hierarchy tab page, you determine whether or not the characteristic can have hierarchies and, if so, what properties these hierarchies are allowed to have.

If the “With” hierarchies checkbox is checked, hierarchies can be created for this characteristic. In the below screen shot, the check box is unchecked, hence no hierarchy is created for this info object.

Hierarchy can be created manually or loaded from the SAP system or other non sap source systems. Hierarchy can be used to drill down or extract specific information about the business item.

Example: A real time scenario when Hierarchy can be used is as follows,

Assume in the case of a bank, the relationship between the main bank and the various branches under a bank can be maintained in the form of hierarchy. Where you can extract the information of customer details at any branch about its account, loan, due dates for loan payment and so on.

Tab Page: Attributes

Attributes are nothing but the fields or properties of master data, there are different types of attributes like display attributes, navigational attributes, executive attributes, compound attributes and so on.

1. You determine whether or not the characteristic can have attributes or texts. The attributes are assigned to the characteristic on the Attributes tab page. Several characteristics can be added as attributes of the master data characteristics in the Attribute tab page.
2. Attributes can be marked as navigational or display attribute by clicking on “navigational attribute on/off” button.

• If you define attributes as display attributes, you can use these attributes only as additional information in reporting when combined with the characteristic.
• If you define attributes as navigation attributes, you can use them to navigate in reporting. When a query is executed, the system does not distinguish between navigation attributes and characteristics for an InfoProvider.
• In the example below, company code is navigational.

3. Display and navigation attributes can be marked as time-dependent if a validity period is required for each attribute value.

Tab Page: Compounding

On this tab page, you determine whether or not the characteristic is to be compounded to other InfoObjects. You often need to compound characteristic values to enable characteristic values to be uniquely assigned. Some Info-objects cannot be defined without compounding, also in order to map the data-model you have to compound Info-Objects sometime. If the info-object is defined as an attributes, it cannot be included as compounding object.

Say, for example, cost center 1000 stands for sales and distribution in controlling area 10, and it also stands for sales in controlling area 20. In this case, you would define a cost center to controlling area characteristic Compounding.

Now save and Activate the Infoobject.

Infoarea , Infoobject Catalog & Infoobjects

What is an InfoArea?

• In Business Warehouse, Info-areas are the branches and nodes of a tree structure.
• It is used to organize info cubes and info objects. 
• Each Info-object is assigned to an Info Area.
• Info Area can be thought of as a folder used to hold related files together.

What is Infoobject Catalog?

• Every info object need to be created within an Info Object Catalog.
• It helps in organization and is no way related to reporting functions.
• Example: There are tons of InfoObjects for SAP Financials which can be clubbed into a InfoObject Catalog.  This makes management and maintainence easy.
• An Info Object can be assigned to multiple Catalog

There are 2 types of Info Object Catalog.

1. Characteristic Info Object Catalog
2. Key figure Info Object Catalog

Here is the RoadMAP to create an Infoobject

 

What is an InfoObjects?

Info-Objects take information from the source, then adjust and arrange the information into either a standard or customized report.  Infoobjects are the smallest available information modules/fields in BI. It is needed in info-providers like InfoCubes, DSOs, MultiProviders, Queries etc...  These Info-Providers are made up of Info-objects.

 

Info-object gives all information about the business. For instance company ‘XYZ’ is interested in finding out how much of “product x” shipped on “date x” to “factory x”.  By defining Info-object for specific function like “0MATERIAL”, “0DATE” and “0LOCATION” all the information can be retrieved.

InfoObjects can be classified into the following types:

• Characteristics (for example, customers)
• Key figures (for example, revenue)
• Units (for example, currency, amount unit)
• Time characteristics (for example, fiscal year)
• Technical characteristics (for example, request number)

Characteristics:

Characteristics are Business reference objects used to analyze key figures.

Examples of characteristics InfoObjects:

• Cost center (0COSTCENTER) 
• Material(0MATERIAL)

Keyfigures:

Key figures provide the values to be evaluated. They are numeric information that is reported in the query.      

Examples of key figure InfoObjects:

• Quantity (0QUANTITY)
• Amount (0AMOUNT)

Units:

Units are paired with Key figure values . They provide assign a unit of measurement to a Key Figure Value. For instance 10 Kg where 10 is the KeyFigure and Kg is the unit

Other Examples of Unit Characteristics:

• Currency unit (0CURRENCY) (Holds the currency type of the transaction e.g. $, EUR, USD...)

• Value unit (0UNIT)  (or) unit of measure (Hold the unit of measure e.g. Gallon, Inch, cm, PC)

Time Characteristic:

Time characteristics give time reference to data.

Examples of Time Characteristics:

• Calendar day (0CALDAY)
• Calendar year (0CALYEAR)
• Fiscal year (0FISCYEAR)

Technical Characteristics:

Technical characteristics are SAP standard objects having their own administrative purposes.

Examples of Technical Characteristics:

• Info Object 0REQUID – While loading data to various data targets,  SAP allocates unique numbers which are stored in this Info object
• Info Object 0CHNGID – When aggregate change run is done, a unique number is allocated and stored in this info object.

* Before creating an Info Object, Info Area and Info Object Catalog need to be created.