Table of Contents Basics of SAP , Business Data Warehouse (Week 1 )

.COM

Basic SAP GUI Navigation Data warehousing Need with an Example. SAP History SAP BW vs Other Data warehousing Tools SAP BW vs SAP BI SAP BW Terminology o Master Data o Transaction Data o Landscape Areas of SAP BW o Extraction o Modeling o Reporting Data Warehousing Categories SAP BW & EDW o 2-Dimensional Modeling o Multi Dimensional Modeling ( Star Schema ) o SAP BW Star Schema ( Extended Star Schema )

Administrator Workbench ( Week 2 )

Administrator Workbench ( AWB ) { RSA1 } o Info Area o Info Object Catalog o Info Objects ( Building Blocks ) Characteristics Key Figures o Application Component Area o Info source, Types Flexible , Direct PSA ( Persistent Staging ARea ) Source System Data Source Info Package Flat file extraction ( Master Data ) o Extract Structure o Transfer Structure

o o

Transfer Rules ( Types ) Communication Structure Update Rules ( Types ) Data Targets ODS Info Cubes, Types Multiproviders

Reporting ( Week 3 )

Business Explorer o Bex Query Designer o Bex Analyzer o Restricted Key Figure o Free Characteristics o Filters o Variables o Calculated Key Figures o Navigation Options o Customer Exits o SAP Exits Extraction o LO Cockpit ( LBWE ) o Generic Extraction ( Master Data Upload ) Web Application Designer RRI ( Jump Reports ) Solution Manager Transportation

SAP BI ( Business Intelligence ) 7.0 Data Modeling (Week 4 )

Data Warehouse Workbench Types of Data o Master Data o Transactional Data o Meta Data Data Model o BI Master Data Tables o BI Transaction Data Tables o Star Schema o Extended Star Schema o SID Tables o Structure of Dimension Tables o Dimension Modeling BI Objects

Info Area Info Object Catalog Characteristics / Attributes Attribute Types Time Characteristics Unit Characteristics Technical Characteristics Key Figures Info Object Definition Attribute Types Time Characteristics Unit Characteristics Technical Characteristics Key Figures Info Object Definition

SAP BW Architecture

Theoretically, SAP BW Architecture can be divided into 3 layers: Sources System, SAP BW Server and SAP BW OLAP.

SAP BW Architecture

Source system:

Source system is a reference system that functions as data provider for SAP BW. There four type source system than can be SAP BW provider:

mySAP.com components: SAP BW is fully integrated into mySAP.com component. Currently, predefined extraction structures and program from mySAP.com component are delivered by SAP. Therefore, we can upload data source from mySAP.com component directly into SAP BW. Non-SAP systems: SAP BW is an open architecture that can interface vis--vis tp external OLTP or legacy system. Based on information or data collected from heterogeneous system, SAP BW has possibility to be a consolidated data basis reporting to support management in decision making. Data Providers: Market research result from, for example, AC Nielsen USDun & Bradstreet can be loaded into SAP BW. The uploaded information can be used as benchmarking and measurement again our operative data. External databases: Data from external relational database can be loaded to SAP BW too.

SAP BW Server
SAP BW Server has several features:

Administration Service: The administration service is responsible for organization within SAP BW. Administration service is available through the Administrator Workbench (AWB), a single point of entry for data warehouse development, administration and maintenance tasks in SAP BW. Metadata Service: SAP BW metadata services component provide both an integrated metadata repository where all metadata is stored and a Metadata Manager that handles all requests for retrieving, adding, changing, or deleting meta data. Extraction, Transformation, and Loading (ETL) Services: Depending on the source systems and type of data basis, the process of loading data into the SAP BW is technically supported in different ways. Storage Services: the storage service (known as SAP BW Data Manager) manages and provides access to different data target available in SAP BW, as well as aggregates stored in relational or multidimensional database management system.

SAP BW OLAP
The Online Analytical Processing (OLAP) layer allows us to carry out multi-dimensional analysis of SAP BW data sets. In principle, the OLAP layer can be divided into three components:

BEx Analyzer (Microsoft Excel Based) BEx Web Application BEx Mobile Intelligence.

What I wrote above (Sources System, SAP BW Server and SAP BW OLAP) are the architecture of SAP BW (Business Information Warehouse) in global explanation.

Star Schema
Structure
InfoCubes are made up of a number of InfoObjects. All InfoObjects (characteristics and key figures) are available InfoCube-independently. Characteristics relate to master data with their attributes and text descriptions. An InfoCube consists of several InfoObjects and is structured according to the star schema. This means there is a (large) fact table that contains the key figures for the InfoCube as well as several (smaller) dimension tables which surround it. The characteristics of the InfoCube are stored in these dimensions. An InfoCube fact table only contains key figures, in contrast to an ODS object, whose data part can also contain characteristics. The characteristics of an InfoCube are stored in its dimensions. The dimensions and the fact table are linked to one another via abstract identification numbers (dimension IDs), which are in the key part of the particular database table. As a result, the key figures of the InfoCube relate to the characteristics of the dimension. The characteristics determine the granularity (the degree of detail) at which the key figures are kept in the InfoCube. Characteristics that logically belong together (district and area, for example, belong to the regional dimension) are grouped together in a dimension. By adhering to this design criterion, dimensions are to a large extent independent of each other, and dimension tables remain small with regards to data volume, which is desirable for reasons of performance. This InfoCube structure is optimized for Reporting. The fact table and dimension tables are both relational database tables.

A Star Schema is a multi dimensional data model that organizing information or data in a data warehouse. It is based on a central fact table surrounded by several dimensional tables in shape of a star. Using star schema, we can view business information from many perspectives. SAP calls this schema as Classic Star Schema to differentiate with SAP BW data model developed by SAP.

Fact Table
Fact is the focus of the analysis of business activity (sales value or quantity, for example). It is a measure that is normally (cumulative) and answer the question how much? or how many? The fact data are stored in a highly normalized fact table. In a star schema, typically the fact table is very large with small dimensional tables. The fact tables has a relatively small number of

columns (attributes) and a large number of rows (records) where associated dimension tables to have a large number of columns (attributes) and small number of rows.

Dimension tables
A dimension is a textual description of the dimension or feature of business. The dimension answer the questions who? what? when? where? Dimension data are stored in dimension table. It link to the fact table has a group of similar characteristics. For example, a customer dimension table may contain three characteristics: customer name, address and sales organization. There will be one customer dimension record for each unique combination of these three values. For example, each record in customer dimension may represent a specific customer.

The graphic below show how the dimension tables and fact table are arranged in a star formation. It also shows the connection between the denormalized dimensions tables and the highly normalized fact table.

Classic star schema as data model of data warehouse has some disadvantages (I will explain it next time). To Response the problems with classic star schema, SAP refined this data model and result SAP BW Star Schema. SAP BW Star schema is based on the extended of the classic star schema (aka snowflake schema). The enhancement comes from the fact that the dimension table does not contain master data information. This master data information is stored in separate tables, called master data tables. In SAP BW Star Schema, the distinction is made between two self-contained areas: infocube and surrogate ID (SID) tables.

Infocube
Infocubes are the central objects on which reports and analysis are based in SAP BW. It describes a self-contained data set within a business area, for which we can define queries.

Infocube consist of a central fact table and several surrounding dimension tables. In SAP BW star schema , the facts in a fact table refers to key figure and the dimension attributes refer to characteristics. In contrast to classic star schema concepts, characteristics are not component the dimension tables since the characteristic values are not stored in the dimension tables. They are stored in master data tables. There are foreign keys that replace the characteristics as the component of dimension table, i.e.: SID stand for Surrogate ID. In picture above, these keys are given the prefix SID_. Each Dimension table has a generated primary key, called the dimension key. (In Picture above, the keys are given the prefix DIM_ID_..). As the classic star schema, the primary key of the fact table is made up of dimension keys.

Master data Table or Surrogate ID (SID) Table

In SAP BW, additional information about characteristic is referred to as master data. Master data information is stored in separate tables called master data tables. There are 3 types of master data, i.e.: Attributes, Text and Hierarchies.

Here, SID tables play an important role in linking the data warehouse information structured to the subject-oriented infocubes. The master data tables, text tables, and hierarchy tables are not directly linked to the associated dimension tables. These tables are infocube independent and joined with the dimension tables using SID table. The SID therefore provides the link to the dimension tables.

The connection between Infocube and Master Data Tables

Picture above illustrates the connection between master data table and infocube. Master data tables are connected to an infocube by way of the SID tables. The picture above also explains that in SAP BW star schema, the master data is independent infocube and can be used by several infocubes at the same time.

Extended Star Schema

Could you believe how SAP use the surrogate key concept in its Extended Star Schema Model. Before, I explain this concept. I would like to say some basic design information about model. This model have only one Fact Table and and few dimensions (maximum 16, among them 3 dimensions are predefined.). Each dimension has one or more characteristics(It could be simple object or Master Data (attribute, text, hierarchy)). But these characteristic is referenced by SID. The characteristic values are not stored in the dimension tables. A numerical SID key is generated for each characteristic. This foreign key replaces the characteristic as the component of the dimension table. SID table is separetly maintained and primary key of this table comes from characteristic table. Its mean SID take cares to each characteristic, and if any characteristic contain master data then those characteristics could be independently used by any dimension to avoid replication of master data. This is the great advantage of SID in Extended Star Schema. Fact Table contain key figures (fact, numerical values) and dimensions ids as foreign key. And fact table and dimension are connected relationally, and form Info Cube. I think, this is very interesting post and I m waiting for your question.

Basic differences between Classic and Extended Star Schema

Added by Manoj Kumar, last edited by Neta Regev on Nov 01, 2011 (view change)

Iin Classic star schema, dimension and master data table are same. But in Extend star schema, dimension and master data table are different. (Master data resides outside the Infocube and dimension table, inside Infocubecube). In Classic star schema we can analyze only 16 angles (perspectives) whereas in extended star schema we can analyze in 16*248 angles. Plus the performance is faster to that extent. Below are some of the basic differences between the two.
Classic Star Schema Fact Dimension Attribute Described Attribute Dimension Tables (Contain Master Data) BW Star Schema Key Figure Characteristic Attribute Text External Hierarchies Dimension Tables (do not contain Master data

Dimension = Dimension Table (optional), Dimension = Dimension Table SID Tables, Master Data Tables (optional)

Posted by Premashish Kumar at 6:01 AM Extended Star Schema

The BW extended star schema differs from the basic star schema, in case of extended star schema, we will have Fact table connected to the Dimension table and the Dimension table is connected to the SID table and SID table is connected to the master data tables. Fact Table and Dimension table will be inside the cube. SID table and Master data tables are outside the cube. One Fact table can get connected to 16 Dimension tables, one Dimension table can be assigned with maximum of 248 SID tables (248 characteristics).

When we load Transaction data into InfoCube, System generates DIM ID based on the SIDs and uses the Dim IDs in the Fact Table. Each Characteristic can have its own master data tables (ATTR, TEXT, HIER). Attribute Table is used to store all the attribute data, Text table is used to store the description in multiple languages, Hier table is used to store the Parent-Child data.

Fact Table

Fact Table will have Dimension IDs and Key figures. Maximum DIM IDs 16 Maximum KeyFigure 233 The Dimension IDs in the Fact Table is connected to the Dimension Table. Fact Table must have at least one Dimension ID.

Dimension Table

Dimension Table contains Dimension ID and SID columns. One column is used for Dimension ID. We have maximum of 248 SID Columns. We can assign maximum of 248 characteristics to one dimension.

http://www.information-management.com/infodirect/20020308/4858-1.html-VERY IMPORTANT SITE

http://learn-sapbi.blogspot.in/2011/09/normal-0-false-false-false-en-us-x-none.html http://www.scribd.com/creynolds_40/d/68022697/4-Star-Schema-Limitations
Star Schema

InfoCubes are made up of a number of InfoObjects. All InfoObjects (characteristics and key figures) are available independent of the InfoCube. Characteristics refer to master data with their attributes and text descriptions. An InfoCube consists of several InfoObjects and is structured according to the star schema. This means there is a large fact table that contains the key figures for the InfoCube, as well as several dimension tables which surround it. The characteristics of the InfoCube are stored in these dimensions. The dimensions and the fact table are linked to one another using abstract identification numbers (dimension IDs) which are contained in the key part of the particular database table. As a result, the key figures of the InfoCube relate to the characteristics of the dimension. The characteristics determine the granularity at which the key figures are stored in the InfoCube. Characteristics that logically belong together are grouped together in a dimension. Dimensions are to a large extent independent of each other, and dimension tables remain small with regards to data volume. This is beneficial in terms of performance as it decouples the master data from any specific InfoCube. The master data can be used at a time by multiple InfoCubes. This InfoCube structure is optimized for data analysis. The fact table and dimension tables are both relational database tables. Characteristics refer to the master data with their attributes and text descriptions. All InfoObjects (characteristics with their master data as well as key figures) are available for all InfoCubes, unlike dimensions, which represent the specific organizational form of characteristics in one InfoCube. You can create aggregates to access data quickly. Here, the InfoCube data is stored redundantly and in an aggregated form. You can either use an InfoCube directly as an InfoProvider for analysis and reporting, or use it with other InfoProviders as the basis of a MultiProvider or InfoSet.

Fact Table

The fact data are stored in a highly normalized fact table. In a star schema, typically the fact table is very large with small dimensional tables. The fact tables has a relatively small number of columns (attributes) and a large number of rows (records) where associated dimension tables to have a large number of columns (attributes) and small number of rows.

Dimension Table

Dimension data are stored in dimension table. Dimension table link to the fact table has a group of similar characteristics. For example, a customer dimension table may contain three characteristics: customer name, address

and sales organization. There will be one customer dimension record for each unique combination of these three values. For example, each record in customer dimension may represent a specific customer.

Limitations of Star Schema

In Case of star schema, Master data is stored inside the cube. So Master data cannot be reused in other cubes. Since all the tables inside the cube contains Alpha-numeric data, it degrades query performance. Because processing of numerics is much faster than processing of alphanumeric. In case of Star schema, we are limited to only 16 dimensions.

inShare