INFOCUBE

InfoCubes

The following sections define BI InfoProviders in more detail, and then concentrate on the primary provider in BI: a InfoCube.

Definition

InfoCubes are the central multidimensional data model in BI. Reports and analyses are based on InfoCubes. An InfoCube describes a self-enclosed data set encompassing one or more related business processes. A reporting user can define or execute queries against an InfoCube.

The following InfoCube types exist in BI:

• InfoCubes
• VirtualProviders 

Only InfoCubes physically contain data in the database. By doing so, they are also data targets, as data can be loaded into them. In contrast, VirtualProviders only represent logical views of a dataset. There is no difference between these InfoCube types as far as the reporting user is concerned. Queries can be defined based on all InfoCube types. InfoCubes are thus InfoProviders, as BI objects are called InfoProviders when queries can be defined/executed based on them in enterprise reporting.

Hint: SAP delivers InfoObjects within BI Content, alongside InfoObjects. The technical name of standard InfoCubes begins with a number, usually 0. You can also define your own InfoCubes. Make sure the technical name begins with a letter between A and Z and that it is 3 to 9 characters in length.

In addition, in many cases, the existing BI Content InfoCube can be changed and not copied to meet your needs. In our exercises case, a cost center transaction InfoCube is a perfect example where we could (in the real world) just have changed. During an upgrade, SAP does not overwrite your changes to our delivered content, unless in a subsequent step you want this to happen.

The following section discusses the InfoCube, relevant for modeling and loading of data.

InfoCubes

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.

Note: A Real-Time InfoCube is a special InfoCube, specially developed for BI Integrated Planning or the older planning tool, BW /SEM (Strategic Enterprise Management) Business Planning and Simulation. Real-Time cubes were previously called Transactional InfoCubes, as the system accesses data in such an InfoCube transactionally. In other words, data is written to the InfoCube (possibly from more than one user at the same time) and instantaneously read again when required. Standard InfoCubes are not suitable here. Use Standard InfoCubes for pure read access (when

reading reference data, for example).

• Fact table

A InfoCube consists of precisely one fact table* in which key figure values are stored. A fact table can contains a maximum of 233 key figures.

*Functional perspective

• Dimension table

A InfoCube usually has a minimum of four dimension tables and a maximum of 16. Of these, 13 of the 16 are customer-created and three are the SAP-supplied dimensions:

• Units dimension table
• Data Package dimension table
• Time dimension table
• Customer dimensions contain SIDs linked to a maximum of 248 characteristics InfoObjects.

Hint: If you have a InfoCube with 13 DIMs x 248characteristics/DIM, you either have a weird business process orbad advice!

• Data Package and Time dimension tables are always present in a InfoCube.
• The Units dimension table only exists if at least one key figure is of type amount quantity.. In this case, a fixed/variable unit/currency needs to be entered with the key figure.
• Dimension tables do not contain the characteristics/characteristic values, but the corresponding SID keys/values.

BI Extended Star Schema: Cost Center Transactions

Master Data Tables and Navigational Attributes

Additional information about characteristics InfoObjects is referred to as master datain the BI system. A distinction is made between the following master data types:

• Attributes
• Texts
• (External) Hierarchies

Although SID tables are also part of a characteristics InfoObject's master data, they are only important from a technical perspective. This will be left for detailed evaluation in BW330. What is important to know is that all of an InfoObject's master data can be used in reporting, as long as the InfoProvider includes the associated InfoObject in its design. For example, since COSTC## is in a dimension of our cost center InfoCube, we have access to the Cost Center master data in our BEx queries. As you can imagine, reports using master data can be slower on average than those that only use characteristics InfoObjects in the dimensions of the InfoCube, as the master data attribute is one more table away from the data.

When we created our InfoObject, we allowed hierarchies. If we subsequently create and activate hierarchies, then hierarchical reports can be created. In addition, for our Text table, we allowed for language support; this means we can put cost center descriptions on the reports in various languages.

Hint: By .hierarchy,. we usually mean an arrangement of objects having a 1:N relationship to each other. In this sense, there are different technical realizations for hierarchies. When you use the word .hierarchy,. you could be referring to relations between characteristics in the dimension, attribute, and/or hierarchy tables in BI. This term is strongly connected with drilldown. (predefined drilldown path) in data warehousing terminology. However, in BI,  drilldown. can also be used without referring to a hierarchy.

In the BI system, .external hierarchies. are presentation hierarchies, which are stored in hierarchy tables as an organizational structure for characteristic values. These are the hierarchies referred to on the Hierarchy tab of the InfoObject maintenance GUI. If the word hierarchy is used, especially with someone who knows generic data warehousing, you must be clear as to what type of hierarchy is being discussed.

Options for Master Data Attributes

1. Do nothing (Display Attribute)

The result is that the attribute (phone number, for example) can only be used as a Tag Along/Display field for a report. It cannot be used for subtotaling or drilldown navigation. An example for us might be the entry date of the cost center. Can you think of any reason someone would want to analyze costs and group them by the date the cost center was established?

2. Enable navigation (InfoObject setting and InfoProvider setting are required) The result is that reporting user can incorporate the attribute in the same manner as they would a characteristic that was inside the dimension table of the InfoCube. They can drill down and subtotal using these navigation-enabled master data attributes.

The InfoCube Design GUI

The figures below show the associated GUIs for creating InfoCubes and InfoAreas.

InfoProviders (including InfoCubes) are Organized in Folders Called InfoAreas

Creating a new InfoArea is as easy as a right-click (context menu) in the root of the InfoProvider tree, or in any lower-level InfoArea. Don't not worry about placement; folders can be reorganized by dragging and dropping them. InfoCubes are also created with the context menu. This time, your cursor needs to be on the folder (InfoArea) under which the InfoCube should be created.

InfoCube Creation GUI

Referencing the preceding figure, the dimensions for your InfoCube are created first. This is done via the context menu on the dimension folder. The technical name of the dimension table is assigned by the system, using the pattern . D<YOUR InfoCube>#., where the first # will be a 1, the second a 2, and so on. You enter a description to help identify to the query author determine the contents (InfoObjects) of the dimension table. Although characteristics InfoObjects can be freely added to your customer-created dimensions, mixing the wrong ones together in a dimension table can cause an unnecessary performance penalties when InfoCubes are accessed. Without spending a day on the concept of dimensional modeling (covered in BW330), the main goal is to combine InfoObjects together in a dimension table that will, when populated with data, keep the dimension table as small as possible. Remember, every unique combination of dimension values generates a new dimension key and the associated data record. Much of the decision process of dimensional modeling can be eliminated, or greatly reduced, by using Business Content content objects.

There are two ways to add InfoObjects to the dimension tables. With the first option, the icons in the top left represent different groupings of InfoObjects, which aid in the search process. The icons, from left to right are:

• AnInfoSource, which is a layout representing cleansed data
• ADataStore object
• AnotherInfoCube
• AnInfoObject catalog
• All InfoObjects in the system

The only purpose of these icons is to limit the number of InfoObjects you have to choose from in building your InfoCube (to prevent choosing the wrong one). The InfoObjects can be added by dragging and dropping them into the desired dimension table. Another option (sometimes the best one for adding InfoObjects) is to again use the context menu (right-click) on the dimension table itself and add them manually using theInfoObject direct input functionality.

 In addition to creating and adding characteristics InfoObjects to the DIM tables, you must add key figures InfoObjects to the folder of the same name. Technically these InfoObjects will end up as fields on the fact table of your InfoCube.

The final task is to decide about navigational attribute status. Some of the InfoObjects you have in your InfoCube might be master data bearing. If the master data attributes for some of these InfoObjects were enabled in the design of the InfoObject (Business Area and Company Code, in our example), you need to decide whether or not to allow this feature for your InfoCube. In our example, we do want to allow subtotaling and navigation for the Company_Code and Business_Area InfoObjects. This will let us run a report summarizing costs by company code connected to the cost center on the transaction. To accomplish this, select the appropriate checkbox in the Navigational Attributes folder of the GUI.

Creating an InfoCube in the InfoProvider Tree

1. In the initial screen of the Data Warehousing Workbench, choose the Modelingfunction area (transaction RSA1) and choose InfoProvider.
2. Create/maintain an InfoArea within the InfoProvider tree.
3. Via the context menu for the InfoArea, choose Create InfoCube..
4. Select an InfoCube type:

·         InfoCube (optionally, select the Real-Time checkbox)

·         VirtualProvider (subtype is required)

Specify a technical name (3 to 9 characters) and a description for the InfoCube/Template InfoCube.

Choose Create and you reach the initial screen of InfoCube maintenance.

InfoCube Maintenance GUI

5. Create dimension tables via the context menu on the Dimensions folder. Choosecontext menu→Properties to set specific technical properties tied to read-and-write performance on a dimension previously created.

Note: Since the system requires at lease one customer-defined dimension, the first dimension table will be provided with the description Dimension 1. Use theProperties option in the context menu to change this description.

6. Select one of the icons in the left corner of the GUI, and enter the appropriate object name to form a master list of the possible objects to use in building your InfoCube (a template). Optionally use the overview of all objects icon to fill the left pane of the GUI with all the InfoObjects in the system. By setting a template filter, you can get a better overview of a particular task. Once a template of objects appears in the left pane, transfer (active) InfoObjects with the following types:

·         Characteristics: Drag to dimension tables created above

·         Time-Characteristics: Drag to the Time dimension supplied by SAP

·         Key Figures: Drag to the Key Figure folder supplied by SAP

Note: Units and Currency InfoObjects will automatically transfer to the Unit dimension when the appropriate key figure is added to the Key Figure folder. In addition, compound InfoObjects will automaticallybe added when the primary InfoObject is added to a dimension.

7. Optional In cases where the characteristics that have been added to the structure list have navigation attributes, you can release these for use by queries on thiscube. Expand the Navigational Attributes folder and select the attributes you want to have available for navigation via the checkbox.
8. Save the new InfoCube and activate it.

Hint:

·     You must activate an InfoCube before it is able to be used in reporting. As a shortcut, the activation step performs a check-and-save function as well.

·   When the InfoCube is activated, the corresponding ABAP dictionary objects are     generated. For the InfoCube, these are the dimension tables and the fact table. As a result, the BI star schema is technically realized. The system generates an additional fact table . the E table . alongside the previous fact table.

·    Except for the text, hierarchy, and E tables, you can display all tables using transaction LISTSCHEMA