Infocube, DSO, Multiprovider

Info Cube

 Info Cube is structured as Star Schema (extended) where a fact table is surrounded by different dim table that are linked with DIM'ids. And the data wise, you will have aggregated data in the cubes.

Infocube contains maximum 16(3 are sap defines and 13 are customer defined) dimensions and minimum 4(3 Sap defined and 1 customer defined) dimensions with maximum 233 key figures and 248 characteristic.

The following InfoCube types exist in BI:

. InfoCubes

. VirtualProviders

 

There are two subtypes of InfoCubes: Standard, and Real-Time. Although both  have an extended star schema design, Real-Time InfoCubes (previously called Transactional InfoCubes) are optimized for direct update, and do not need to use the ETL process. Real-Time InfoCubes are almost exclusively used in the BI Integrated Planning tool set. All BI InfoCubes consists of a quantity of relational tables arranged together in a star schema.

Star Schema

In Star Schema model, Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains millions to billions of records. On the other hand dimensional tables are very small. Hence they contain a few thousands to few million records. In practice, Fact table holds transactional data and dimensional table holds master data.

The dimensional tables are specific to a fact table. This means that dimensional tables are not shared to across other fact tables. When other fact table such as a product needs the same product dimension data another dimension table that is specific to a new fact table is needed.

This situation creates data management problems such as master data redundancy because the very same product is duplicated in several dimensional tables instead of sharing from one single master data table. This problem can be solved in extended star schema.

Extended star schema

In Extended Star Schema, under the BW star schema model, the dimension table does not contain master data. But it is stored externally in the master data tables (texts, attributes, hierarchies).

The characteristic in the dimensional table points to the relevant master data by the use of SID table. The SID table points to characteristics attribute texts and hierarchies.

This multistep navigational task adds extra overhead when executing a query. However the benefit of this model is that all fact tables (info cubes) share common master data tables between several info cubes.

Moreover the SID table concept allows users to implement multi languages and multi hierarchy OLAP environments. And also it supports slowly changing dimension.

MultiProvider 

A MultiProvider is a special InfoProvider that combines data from several InfoProviders, providing it for reporting. The MultiProvider itself (InfoSets and VirtualProviders) does not contain any data. Its data comes exclusively from the InfoProviders on which it is based. A MultiProvider can be made up of various combinations of the following InfoProviders:
. InfoCubes
. DataStore objects
. InfoObjects
. InfoSets
. Aggregation levels (slices of a InfoCube to support BI Integrated Planning)

Use
A BEx query can only be written against a single InfoProvider. A MultiProvider is a single InfoProvider to a query but through it, multiple providers can be indirectly accessed.

DataStore object

 Since a DataStore object is designed like a table, it contains key fields (document number and item, for example) and data fields. Data fields can not only be key figures but also character fields (order status, customer, or time, for example). You can use a delta update to update DataStore object data into connected InfoCubes or into additional DataStore objects or master data tables (attributes or texts) in the same system or in different systems. In contrast to multidimensional DataStores for InfoCubes, data in DataStore objects is stored in flat, transparent database tables. Fact and dimension tables are not created.

With DataStore objects, you can not only update key figures cumulatively, as with InfoCubes, but also overwrite data fields. This is especially important for transaction-level documents that change in the source system. Here, document changes not only involve numerical fields, such as order quantities, but also non-numerical ones such as ship-to parties, delivery date, and status. Since the OLTP system overwrites these records when changes occur, DataStore objects must often be moceled to overwrite the corresponding fields and update to the current value in BI.

DS Oject Types

SAP BI distinguishes between three DataStore object types: Standard, Write Optimized, and Direct Update. These three flavors of DataStore Objects are shown in the following figure.

1. The Standard DataStore Object consists of three tables (activation queue, active data table, and change log). It is completely integrated in the staging process. In other words, data can be loaded into and out of the DataStore Objects during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.

Architecture and Functions of Standard DataStore Objects

 

Standard DataStore objects consist of three tables:

Active Data table

This is where the current status of the data is stored. This table contains a semantic (business-related) key that can be defined by the modeler (order number, item, or schedule line, for example). It is very important that the key be correctly defined by the modeler, as a match on the key initiates special delta processing during the activation phase (discussed later). Also, reporting via the BEx uses this table.

Change Log table 

During the activation run, changes are stored in the change log. Here, you can find the complete history of the changes, since the content of the change log is not automatically deleted. The connected targets are updated from the change log if they are supplied with data from the DataStore object in the delta method. The change log is a PSA table and can also be maintained in the PSA tree of the Data Warehousing Workbench. The change log has a technical key consisting of a request, data package, and data record number.

Activation Queue table

During the DTP, the records are first written to this table. This step is necessary due to the complex logic that is then required by the activation process.

Schema for a Standard DataStore Objects

2. Write optimized is a new kind of DataStore Object . It is targeted for the warehouse level of the architecture, and has the advantage of quicker loads.

3. A direct update DataStore object (previous 3.x transactional ODS) has only the table with active data. This means it is not as easily integrated in the staging process. Instead, this DataStore object type is filled using APIs and can be read via a BAPI.