Wednesday, October 6, 2010

Compounding Info Object

In Compounding a Field or another Object is attached to an Info Object. A Compounding Characteristic is when object's definition is incomplete without the definition of the another Characteristic Info Object.


For the better understanding the Info Object - Location (0PP_LOCAT) has to be assigned with  a Compound Info Object - Plant (0PLANT).


Here Plant(0PLANT) is the Superior Info Object of the Location(0PP_LOCAT)


The Info Object 0Plant has to be Installed/Created/ Activated first, later followed by Location(0PP_LOCAT)


While creating the Info Object itself we need to assign the Superior Object like below at Compounding Tab Page of Info Object.


Compounding Info Object Acts as a compounding Primary Key at the Master Data Table.


When a compounded Info object is included in an Info cube, all corresponding info objects are added to the Info cube. 


If Location(0PP_LOCAT) is to be included in the Info Cube , Plant (0Plant) is automatically added to the Info Cube. 




When a Compounded Info object is included in the DSO , all corresponding Objects are added to the DSO Key fields/Data Fields.


If Location(0PP_LOCAT) is to be included in the DSO , Plant (0Plant) is automatically added to the DSO. 


The below video explains: 










If an info object is defined as an attribute, it cannot be included as compounding object.




The total length of the compounding info objects cannot exceed 60 characters.


An Info Object which is defined as an Attribute only setting can not be included in Compounding object.


The Compounding Info Objects at BEx Report out put will be 0PLANT/0PP_LOCAT.









Surrogate ID -- Master Data Tables

Standard Info cube consists of fact table surrounded by many dimension table. SID table links these Dimension tables to master data tables.

SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO.  In SAP BI Extended star schema, the distinction is made between two self contained areas: Info cube & Master data tables and connecting SID tables.

The master data doesn't reside in the Extended Star schema but resides in separate tables which are shared across all the star schemas in SAP BI.

An Unique Numeric ID , the SID is generated which connects the dimension tables of the infocube to that of the master data tables.
The dimension tables contain the DIM IDs and SIDs of a particular Characteristic Info Object. Using this SID Table the Master data ( attributes and texts of Info Object) is accessed.

 List of Technical Tables  

F  - Fact Table - Uncompressed Fact Table - Contains Direct data for cube Request wise ( Based on B-Tree Index ) 
E  - Fact Table - Compress cube - Contains compressed data without Request IDs( Request ID would be 'zero') ( based on  Bitmap Index ) 
   
M - View of Master Data Table  - /BI0/MMATERIAL
P - Time Independent Master Data Table - /BI0/PMATERIAL
Q  - Time Dependent Master Data Table - 
/BI0/QMATERIAL

H - Hierarchy table  - /BI0/HMATERIAL
J  - Hierarchy interval table  - /BI0/JMATERIAL
K - Hierarchy SID table - /BI0/KMATERIAL
I  - SID Hierarchy structure      - /BI0/IMATERIAL
S  - SID table  - /BI0/SMATERIAL
X - Time Independent SID table for Attr - /BI0/XMATERIAL
Y  - Time Dependent SID table fir Attr  - 
/BI0/YMATERIAL

T  - Text Table - /BI0/TMATERIAL 
   

SID -- Master data Tables


Surrogate Keys are automatically generated uniform keys, which are uniquely identifying specific real-world key values. 


SID are only the connectivity link between DIM IDs and Master Data Tables .


Let us take an Example of a Material Master Data Tables and understand the various connectivities with SID table.











Monday, September 20, 2010

Definitions of some Objects in BI/BW

Info Area:

Element for grouping meta-objects in the BI system.

Each InfoProvider is assigned to an InfoArea. The resulting hierarchy is displayed in the Data Warehousing Workbench.

In addition to their properties as an InfoProviders, InfoObjects can also be assigned to different Info Areas.

Info Area is a Top Level Object, which contains the data models in it .


In general, Info Areas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an Info Area. Through an InfoObject Catalog, each Info Object is assigned to an Info Area as well.


The Info Area contains all objects used to evaluate for a business logical process.


Info Area in which Info Providers are stored.


Info Object Catalogs:


An Info Object catalog is a collection of InfoObjects grouped according to application-specific criteria. 


There are two types of InfoObject catalogs: Characteristic and Key figure.


Info Objects, (characteristics and key figures) are the basic data model of SAP Business information warehouse(BW/BI).


And the Info objects are stored in folders, it also called the “InfoObject catalogs”, the infoobject catalogs are also stored in a folder called Info Areas.


An Info Object catalog is assigned to an Info Area.


An Info Object can be included in several Info Object catalogs.


Info Objects:


Business evaluation objects are known in BI/BIW as InfoObjects. They are divide into characteristics (for example, customers), key figures (for example, revenue), units (for example, currency, amount unit), time characteristics (for example, fiscal year) and technical characteristics (for example, request number). 


Info Objects are the smallest information units in BI/BW.


They structure the Information needed to create the data targets.








Info Objects with attributes or texts can be either a pure data target or an Info Provider (if it is being reported).




Application Component







Application Components are used to organize Data Sources. They are analogous to the Info Areas .






DataSource

A DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information.
 Four types of DataSources exist:
DataSources for transaction data
DataSources for characteristic attributes
DataSources for characteristic texts
DataSources for characteristic hierarchies

If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BI/BW system. 


Info Package:
An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage's technical name.






PSA

Persistent Staging Area is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.
The PSA stores data in its original source system format. In this way, it gives us a chance to examine / analyse the data before we process them to further destinations. Most probably it is a temporary storage area, based on the client data specifications and settings.
SID

SID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.

Star schema
A star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing(OLAP).







Business Content

Business Content is a complete set of BI/BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, Info Cubes, key figures, characteristics, Transformations and extractors for SAP R/3, and other mySAP solutions.




Compound attribute

A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.




Data packet size

For the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.




Data Warehouse

Data Warehouse is a dedicated reporting and analysis environment based on the star schema database design technique and requiring special attention to the data ETTL process.




Delta update

The Delta update option in the InfoPackage definition requests BI/BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.

Tuesday, September 14, 2010

Connecting Master Tables to InfoCubes Via SID Tables


In order to cover the re-alignment of master data attributes, the master data tables in a BI Data model are not linked directly to Info Cubes ( but connected via Surrogate Keys ) as the following, simplified, picture below explains:







As you can see, pointer or translation tables called SID (Surrogate-ID) tables are used in the BI data model to link the master tables of the BI data model to Info Cubes.

The above graphic shows a simplified version of what types of SID tables exist .

SID Tables
SID tables play an important role in linking the data warehouse information structures to the InfoCubes and Data Store Objects. To speed up access to InfoCubes and DataStore Objects and to allow an independent master data layers, each characteristic and attribute is assigned a SID column and their values are encoded into 4-byte integer values.

InfoObject definition and SID tables
To offer optimal performance with the various data models with respect to master data access, three different SID tables might be generated.


SID tables with respect to master data:






  •  The SID table is always generated if an InfoObject is not defined as ‘attribute only’ (tab page general).This table is used if the access to an Infocube or DataStore Object uses a navigational attribute or if the access is via a characteristic without attributes. Name of the table: /BIC/S

  • The non-time dependent attribute SID table of a characteristic for access via non-time dependent attributes. Name of the table: /BIC/X

  • The time dependent attribute SID table of a characteristic for access via time dependent attributes.Name of the table: /BIC/Y



    All these SID tables are automatically maintained during master data load. SID tables are also maintained
    during InfoCube load if no referential integrity check is enforced (InfoPackage).


    But in case of Line Item Dimension the SID table acts as a Dimension Tables, that means NO Dimension table is created for this .



    Dimensions with only one characteristic (line item dimensions)
    It is very often possible in this model to assign only one characteristic to a dimension.This will probably occur with specific reporting requirements or if for example you have the document line item in your model which occupies lot of space of Fact table. In these situations a dimension table means only overhead. BI allows you define this kind of dimension as a line item dimension (Check box dimension definition while creation of Info cube). In doing this no dimension table will be generated for this dimension. As dimension table will serve the SID table of this characteristic. The key in the fact table will be the SID of the SID Table.

    pictures explains





    Thursday, March 4, 2010

    Info Set ( Join )
    Info Set is a Virtual Provider. Info Sets allow you to analyze the data in several Info Providers by using combinations of master data-bearing characteristics, Info Cubes and Data Store objects. The system collects information from the tables of the relevant Info Providers. If you are joining large sets of data from the master data or from DSO objects, SAP recommends that you use an Info Set. This improves performance as fewer temporary tables are required and the join is executed in the database itself.
    Joins are 4 types

    : 1) Left outer Join
    2) Right outer Join.
    3) Temporary Join...based on any Date field.
    4) Equal Join
    Inner Join:

    In case of inner join there should be an entry in all the tables use in the view.


    Outer Join:

    With the use of outer join you can join the tables even there is no entry in all the tables used in the view. Inner join between table 1 and table 2, where column D in both tables in the join condition is set the same:

     Table 1 Table 2
     Inner Join
    ---- ---- ---- ---- ---- ---- ---- ---- ----
    A B C D D E F G H
     ---- ---- ---- ---- ---- ---- ---- ---- ----
     a1 b1 c1 1 1 e1 f1 g1 h1
    a2 b2 c2 1 1 e1 f1 g1 h1
     a4 b4 c4 3 3 e2 f2 g2 h2
    ---- ---- ---- ---- ---- ---- ---- ---- ----

    Left outer join between table 1 and table 2 where column D in both tables set the join condition: Table 1 Table 2
    A B C D D E F G H
    a1 b1 c1 1 1 e1 f1 g1 h1
    a2 b2 c2 1 3 e2 f2 g2 h2
    a3 b3 c3 2 4 e3 f3 g3 h3
    a4 b4 c4 3 --- ---- ------------

     Left Outer Join

    A B C D D E F G H
    a1 b1 c1 1 1 e1 f1 g1 h1
    a2 b2 c2 1 3 e2 f2 g2 h2
    a3 b3 c3 2 4 e3 f3 g3 h3
    a4 b4 c4 3 --- ---- ------------
    -----------------------------------------------------
    A B C D D E F G H
    ------------------------------------------------------
    a1 b1 c1 1 1 e1 f1 g1 h1
    a2 b2 c2 1 1 e1 f1 g1 h1
     a3 b3 C3 2 NULLNULLNULLNULLNULL
    a4 b4 c4 3 3 e2 f2 g2 h2

    What makes difference between Inner Join & Left Outer Join

     Inner join returns only the matching records from both tables.Left outer join returns complete details of left table which are matching with right table and non matching records also.

     The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.

    The set of hits determined by an inner join can therefore be a subset of the hits determined with an outer join.

    Database views implement an inner join. The database therefore only provides those records for which there is an entry in all the tables used in the view. Help views and maintenance views, however, implement an outer join. Temporal Join

    Join containing at least one time-dependent characteristic For example, a join contains the following time-dependent Info Objects (in addition to other objects that are not time-dependent).

     InfoObjects in the join                Valid from      Valid to
     Cost center (0COSTCENTER) 01.01.2009 31.05.2009
    Profit center (0PROFIT_CTR) 01.06.2009 31.09.2009

    Where the two time-intervals overlap, means the validity area that the Info Objects have in common, is known as the valid time-interval of the temporal join.

    Temporal join                       Valid from       Valid to

    Valid time-interval           01.03.2009          31.05.2009

    You define an Info Set via the characteristic PROFIT Center, which contains the responsible person (RESP) as the time-dependent attribute and the characteristic COSTCENTER that also contains person responsible as a time-dependent attribute.

    These characteristics contain the following records:


     Profit Center      Responsible Person   DATEFROM*      DATETO*
    BI A 01.01.2009 30.06.2009
    BI B 01.07.2009 31.12.9999

     Cost Center Profit Center Responsible Person  DATEFROM*  DATETO*
    4711                        BI              X                   01.01.2009          31.05.2009
    4711                        BI              Y                   01.06.2009          31.12.2009
     4711                       BI              Z                    01.01.2009           31.12.9999

    If both characteristics are used in a join and connected via PROFITCENTRE, it is not true that all six possible combinations are valid for the above records. Instead only the following four:


    PROFITC                      RESP     Cost Center      Profit Center        Responsible Person
    BI                                A                     4711                      BI            X (01.01.2009-31.05.2009)
    BI                                A                      4711                      BI          Y (01.06.2009-30.06.2009)
    BI                                B                      4711                      BI           Y (01.07.2009-31.12.2009)
    BI                               B                      4711                       BI            Z (01.01.2009-31.12.9999)

    Equal Join

    A join condition determines the combination of records from the individual objects that are included in the resulting set. Before an Info Set can be activated, the join conditions have to be defined in such a way (as equal join condition) that all the available objects are connected to one another either directly or indirectly.

    An Equal Join is possible only with Same Values Technical Requirement is such way that both the Values has same Data Type & Length for Equal Join.

    Equal Join

    Table1                                     Table 2

                               Equal Join
     X                   ------------------- X

    welcome

    hi everybody.. how ru.. this is test post