Infoset

Definition:

1. InfoSets are specific kind of InfoProviders.
2. InfoSet describes data sources that are defined as a rule as joins of DataStore Objects, standard InfoCubes and/or InfoObjects (characteristics with master data).
3. If one of the InfoObjects contained in the join is a time-dependent characteristic, the join is a time-dependent or temporal join.
4. An InfoSet is a semantic layer over the data sources.
5. Unlike the classic InfoSet, an InfoSet is a BI-specific view of data.

Usage:

1. With activated InfoSets you can define Queries in the BI suite. 
2. InfoSets allow you to analyze the data in several InfoProviders by using combinations of master data-bearing characteristics, InfoCubes and DataStore objects.
3. The system collects information from the tables of the relevant InfoProviders. 
4. When an InfoSet is made up of several characteristics you can map transitive attributes and analyze this master data.
5. You create an InfoSet using the characteristics Business Partner (0BPARTNER) – Vendor (0VENDOR) – Business Name (0DBBUSNAME) and can thereby analyze the master data.
6. You can use an InfoSet with a temporal join to map periods of time. 
7. With all other types of BI object, the data is determined for the key date of the query, but with InfoSets with a temporal join, you can specify a particular point in time at which you want the data to be evaluated. 
8. The key date of the query is not taken into consideration in the InfoSet

Creation of InfoSets

The step by step procedure on how to create InfoSets are described below

Step 1:

Go to InfoProvider tree of the Modeling function area in the Data Warehousing Workbench.

Or RSA1  InfoProvider.

Under your InfoArea  Rclick  Create InfoSet

Step 2

Enter the following descriptions for the new InfoSet:

• Technical name
• Long name
• Short name (optional)

In the Start with InfoProvider section, you determine which InfoProvider you want to use to start defining the 

InfoSet.

Select one of the object types that the system offers you:

• DataStore object
• InfoObject
• Standard InfoCube

If you want to choose an InfoObject, it must be a characteristic with master data. The system provides you 

with the corresponding input help. 

In our example, we have selected a DSO ZAD_DSO1

Choose Continue.

Step 3:

The first time you call the InfoSet Builder you can choose between two display modes: 

• network (DataFlow Control) 
• Tree (TreeControl). 

While the network display is clearer, the tree display can be read by the ScreenReader and is suitable for 

visually-impaired users. 

You can change this setting at any time using the menu path Settings  Display

The Change InfoSet screen appears.

Note: If you want to create a new InfoSet you can also use transaction RSISET to call the InfoSet Builder. 

Step 4:

Now save & activate the InfoSet.

Do’s and Don’ts for InfoSets

• Do not use more than 10 InfoProviders in one InfoSet. It is better to create multiple InfoSets depending on reporting needs.
• Do not use more than 10 joins in one InfoSet (especially if you expect high a data volume).
• InfoSet queries can be used for DataStore objects without the activated BEx Reporting indicator.
• Do not use calculations before aggregation on InfoSet because this may lead to wrong query results.
• If there are InfoSets with time-dependent master data, do not restrict the data by the fields Valid from (0DATEFROM) and Valid to (0DATETO). 

Data Models Using Infosets:

• InfoSets are InfoProviders that logically join data and provide this data for BI queries. 
• InfoSets only reference basic InfoProviders (InfoCubes, DataStore objects, master data InfoObjects), but they contain no data. 
• All the BEx and OLAP services are available (authorizations, texts, variables, hierarchies, calculated key figures) except navigational attributes of InfoSet characteristics.
• In the InfoSet maintenance, you can make field descriptions unique for the BEx user and hide fields of the basic InfoProviders that are not important for reporting.

When to use InfoSets?

1. To join required data from basic InfoProviders.This allows building a relational BI data model with unified views for reporting (several InfoProviders, but only one view). Therefore, we recommend keeping data in smaller, basic InfoProviders that can be flexibly joined for reporting purposes.
2. To allow BEx Reporting on a DataStore object without turning the BEx Reporting indicator on
3. To evaluate time dependencies (for example, join time dependent master data InfoObjects)
4. To be able to create self joins and left outer joins

Join Concepts:

• Inner join: A record can only be in the selected result set if there are entries in both joined tables
• Left outer join: If there is no corresponding record in the right table, the record is part of the result set (fields belonging to the right table have initial values)
• Temporal join: A join is called temporal if at least one member is time-dependent.
• Self join: The same object is joined together

Performance Aspects of InfoSets:

• InfoSets do not have the set of performance tools as InfoCubes (such as aggregates, partitioning, and compression).
• Use left outer joins in InfoSets only when necessary. A left outer join has a significantly worse performance than a corresponding inner join.
• If your reporting requirements on a DataStore Object are very restricted (that is, you want to display only very few, selective records), use an InfoSet on top of the DataStore object and disable the BEx Reporting indicator. This results in better data loading performance, but also in worse performance at BI query runtime if more than 10 records are selected from the DataStore Object.