Page 1 of 6

Index

Page No

InfoObjects 1

Data source

Page 2 of 6

Info objects Definition

Business evaluation objects are known in BI as InfoObjects. They are divided into 1. characteristics (for example, customers), 2. key figures (for example, revenue), 3. Units (for example, currency, amount unit), 4. time characteristics (for example, fiscal year) and 5. Technical characteristics (for example, request number).

Use
InfoObjects are the smallest units of BI. Using InfoObjects, information is mapped in a structured form. This is required for constructing InfoProviders. InfoObjects with attributes or texts can themselves also be InfoProviders (if in a query).

Structure
Characteristics are sorting keys, such as company code, product, customer group, fiscal year, period, or region. They specify classification options for the dataset and are therefore reference objects for the key figures. In the InfoCube, for example, characteristics are stored in dimensions. These dimensions are linked by dimension IDs to the key figures in the fact table. The characteristics determine the granularity (the degree of detail) at which the key figures are kept in the InfoCube. In general, an InfoProvider contains only a sub-quantity of the characteristic values from the master data table. The master data includes the permitted values for a characteristic. These are known as the characteristic values. The key figures provide the values that are reported on in a query. Key figures can be quantity, amount, or number of items. They form the data part of an InfoProvider. Units are also required so that the values for the key figures have meanings. Key figures of type amount are always assigned a currency key and key figures of type quantity also receive a unit of measurement. Time characteristics are characteristics such as date, fiscal year, and so on. Technical characteristics have only one organizational meaning within BI. An example of this is the request number in the InfoCube, which is obtained as ID when loading requests. It helps you to find the request again. Special features of characteristics: If characteristics have attributes, texts, or hierarchies at their disposal then they are referred to as master data-bearing characteristics. Master data is data that remains unchanged over a long period of time. Master data contains information that is always needed in the same way. References to this master data can be made in all InfoProviders. You also have the option of creating characteristics with references. A reference characteristics provides the attributes, master data, texts, hierarchies, data type, length, number and type of compounded characteristics, lower case letters and conversion routines for new characteristics.

Page 3 of 6
A hierarchy is always created for a characteristic. This characteristic is the basic characteristic for the hierarchy (basic characteristics are characteristics that do not reference other characteristics). Like attributes, hierarchies provide a structure for the values of a characteristic. Company location is an example of an attribute for Customer. You use this, for example, to form customer groups for a specific region. You can also define a hierarchy to make the structure of the Customer characteristic clearer. Special features of key figures: A key figure is assigned additional properties that influence the way that data is loaded and how the query is displayed. This includes the assignment of a currency or unit of measure, setting aggregation and exception aggregation, and specifying the number of decimal places in the query.

Integration
InfoObjects can be part of the following objects:
...

1. Component of an InfoSource An InfoSource is a quantity of InfoObjects that logically belong together and are updated in InfoProviders. 2. Composition of an InfoProvider: An InfoProvider consists of a number of InfoObjects. In an InfoCube, the characteristics, units, and time characteristics form the basis of the key fields, and the key figures form the data part of the fact table of the InfoCube. In a DataStore object, characteristics generally form the key fields, but they can also be included in the data part, together with the key figures, units and time characteristics. 3. Attributes for InfoObjects

DataSource

Definition
A DataSource is a set of fields that provide the data for a business unit for data transfer into BI. From a technical viewpoint, the DataSource is a set of logically-related fields that are provided to transfer data into BI in a flat structure (the extraction structure), or in multiple flat structures (for hierarchies). There are four types of DataSource:
DataSource for transaction data DataSource for master data DataSource for attributes DataSource for texts DataSource for hierarchies

Use
DataSources supply the metadata description of source data. They are used to extract data from a source system and to transfer the data to the BI system. They are also used for direct access to the source data from the BI system. The following image illustrates the role of the DataSource in the BI data flow:

Page 4 of 6

The data can be loaded into the BI system from any source in the DataSource structure using an InfoPackage. You determine the target into which data from the DataSource is to be updated during the transformation. You also assign DataSource fields to target object InfoObjects in BI.

Scope of DataSource Versus 3.x DataSource

3.x DataSource In the past, DataSources have been known in the BI system under the object type R3TR ISFS; in the case of SAP source systems, they are DataSource replicates. The transfer of data from this type of DataSource (referred to as 3.x DataSources below) is only possible if the 3.x DataSource is assigned to a 3.x InfoSource and the fields of the 3.x DataSource are assigned to 3.x InfoSource InfoObjects in transfer structure maintenance. A PSA table is generated when the 3.x transfer rules are activated, thus activating the 3.x transfer structure. Data can be loaded into this PSA table. If your dataflow is modeled using objects that are based on the old concept (3.x InfoSources, 3.x transfer rules, 3.x update rules) and the process design is built on these objects, you can continue to work with 3.x DataSources when transferring data into BI from a source system. DataSource As of SAP NetWeaver 7.0, a new object concept is available for DataSources. It is used in conjunction with the changed objects concepts in data flow and process design (transformation, InfoPackage for loading to the PSA, data transfer process for data distribution within BI). The object type for a DataSource in the new concept - called DataSource in the following - is R3TR RSDS. DataSources for transferring data from SAP source systems are defined in the source system; the relevant information of the DataSources is copied to the BI system by replication. In this case one speaks

Page 5 of 6 of DataSource replication in the BI system. DataSources for transferring data from other sources are defined directly. A unified maintenance UI in the BI system, the DataSource maintenance, enables you to display and edit the DataSources of all the permitted types of source system. In DataSource maintenance you specify which DataSource fields contain the decision-relevant information for a business process and should therefore be transferred. When you activate the DataSource, the system generates a PSA table in the entry layer of BI. You can then load data into the PSA. You use an InfoPackage to specify the selection parameters for loading data into the PSA. In the transformation, you determine how the fields of the are assigned to the BI InfoObjects. Data transfer processes facilitate the further distribution of data from the PSA to other targets. The rules that you set in the transformation are applied here. Overview of Object Types A DataSource cannot exist simultaneously in both object types in the same system. The following table provides an overview of the (transport-relevant) metadata object types. The table also includes the object types for DataSources in SAP source systems:
DataSource Type BI: Object Type of A or M Version BI: Object Type of Shadow Version (Source System Independent) R3TR SHDS (Shadow object delivered in its own table with release and version) R3TR SHFS for nonreplicating source systems SHMP for replicating source systems, that is SAP source systems (shadow object delivered in its own table with source system key) SAP Source System: Object Type of A Version

SAP Source System: Object Type of D Version

DataSource

R3TR RSDS

R3TR OSOA

R3TR OSOD

3.x DataSource

R3TR ISFS

R3TR OSOA

R3TR OSOD

Restriction
The new DataSource concept cannot be used for transferring data from external systems (metadata and data transfer using staging BAPIs), for transferring hierarchies, or when using the IDoc transfer method.

Recommendation
We recommend that you adjust the data flow for the DataSource as well as the process design to the new concepts if you want to take advantage of these concepts If you want to migrate an existing data

Page 6 of 6 flow, first use the emulation of DataSource 3.x to convert other objects in the data flow or to define new ones. You can then migrate the 3.x DataSource to a DataSource and benefit from the new concepts in your scenario. More information: Data Flow in the Data Warehouse and Migrating Existing Data Flows.