InfoProviders:

Data Targets                                                                              Non-Data Targets

Data Targets:  

An InfoCube is the central object in BI for the storage of data. It is the most used object for storing data and generating queries due to the relational structure of the tables. The structure of the InfoCube was set up specifically to be able to execute and run query processes as quickly as possible. InfoCube can answer any question about events that have happened, not events that have not happened. For example, suppose you are interested in knowing the product orders that have run during the month that have not had any variance between standard costs and actual costs. The InfoCube doesn't hold information about any event that has not happened---and the production orders that don't have a variance have not happened.

A DataStore object serves as a storage location for consolidated and cleansed transaction data on a document (operational) data level, or it can be used for the storage of master data for analysis. With DataStore objects it is also possible to overwrite data fields. This is particularly important with document-related structures. If documents (for example, sales orders transactions) are changed in the source system, these changes include both numeric fields, such as the order quantity, and nonnumeric fields, such as the ship-to party, status, and delivery date, can be updated into the DataStore object and the change statuses can be tracked by the "change log" in the DataStore object. Another task that the DataStore object can be used for is the update of the current data in another object. This uses the delta updating functionality and can update data into an InfoCubes and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems.

You can indicate an InfoObject of type Characteristic as an InfoProvider if it has attributes and/or texts. The data is then loaded into the master data tables using the transformation rules. It is not possible to use transformation rules to load hierarchies. You also need to have the field for the connection to the InfoArea so that the InfoObject can be identified as an InfoProvider and therefore execute a query against this object.

Non-Data Targets: 

As mentioned before, the Data Target InfoProviders are only able to show you events that have happened, but with Non-Data Targets you have the ability to create combinations so that additional reporting requests can be satisfied.

A query based on a MultiProvider is divided internally into subqueries. There is a sub-query for each InfoProvider included in the MultiProvider. These subqueries are usually processed in parallel. Technically there are no restrictions with regard to the number of InfoProviders that can be included in a MultiProvider. However, I recommend that you include no more than ten InfoProviders in a single MultiProvider, because splitting the MultiProvider queries and reconstructing the results for the individual InfoProviders takes a substantial amount of time and is generally counterproductive.

InfoSets are a specific kind of InfoProvider that describe DataSources that are defined as joins of DataStore objects, InfoCubes, and InfoObjects (not other MultiProviders). Because the InfoSet is a join of data, you can control the view of the information from an InfoSet. By this I mean that you can set up the InfoSet so that the query can answer questions, such as questions about an event that has not happened. For example, if you use a master data-bearing InfoObject during the creation of the InfoSet and identify this as the outer join, the master data will be a required value in the column and therefore show situations were there has been no activity. As a real-world example, I worked with a company that wanted to see what each of its different divisions sold during each month---and not only what they did sell, but also other products that they didn't sell. Therefore, setting up an InfoSet and using the master data as the left outer join, I was able to generate a query that had all the divisions and the products listed in the rows and the periods in the columns. All products were displayed, even if there were no sales for that period. Note:  A join condition determines the combination of individual object records that are included in the results set.
InfoSets allow you to analyze the data in several InfoProviders by using combinations of master data-bearing characteristics, InfoCubes, and DataStore objects. The system collects information from the tables of the relevant InfoProviders. When an InfoSet is made up of several characteristics, you can map transitive attributes and analyze this master data. Note: Transitive attributes are attributes at the secondary level. Suppose, for example, you have an InfoObject called Customer that has an attribute of Region, and that attribute, Region, has an attribute of Country. You can set up a process so that you can report on Country via Customer.

Virtual InfoCubes are InfoProviders with transaction data that is not stored in the objects themselves, but is read directly for analysis and reporting purposes. The relevant data can be from the BI system or from other SAP or non-SAP systems. Virtual Providers only allow read access to data. The different Virtual Providers are based on the data transfer process, on a BAPI (Business Application Program Interface), or on the function module.
Virtual Provider based on Data Transfer Process is used if you require up-to-date information from an SAP source system, but it is suggested that you only access a small set of data and that you only use this process for a specific set of users. There are specific situations where the use of this type of Virtual Provider is important---for example, if you are looking to validate information that was uploaded into the BI system and you use this Virtual Provider to access the same table you used for the upload. You could create a query against this Virtual Provider to review the information directly from the source system and then compare it to the uploaded data (more than likely you would compare the data from the Virtual Provider query with the data in the PSA (Persistent Staging Area) since this is the initial table that is used for an uploading/staging area and the data in the PSA has not be altered by any programs in BI).
Virtual Provider based on BAPI is different from the DTP Virtual Provider because the transaction data is read for analysis and reporting from an external system using a BAPI (Business Application Program Interface) and not specifically from an SAP source.
Virtual Provider based on Functional Modules are used if you want to display data from non-BI DataSources in BI without having to copy the dataset into the BI structures. The data can be local or remote. You can also use your own calculations to change the data before it is passed to the OLAP processor. In comparison to other Virtual Providers, this one is more generic. It offers more flexibility, but also requires a higher implementation effort.