Showing posts with label Basics. Show all posts
Showing posts with label Basics. Show all posts

Friday, 26 April 2013

Compounding objects and its purpose

A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. 

In the Compounding tab page, you determine whether you want to compound the characteristic to other InfoObjects. You sometimes need to compound InfoObjects in order to map the data model. Some InfoObjects cannot be defined uniquely without compounding. 

For example, if storage location A for plant B is not the same as storage location A for plant C, you can only evaluate the characteristic Storage Location in connection with Plant. In this case, compound characteristic Storage Location to Plant, so that the characteristic is unique. One particular option with compounding is the possibility of compounding characteristics to the source system ID. You can do this by setting the Master data is valid locally for the source system indicator. You may need to do this if there are identical characteristic values for the same characteristic in different source systems, but these values indicate different objects. 

Recommendation : Using compounded InfoObjects extensively, particularly if you include a lot of InfoObjects in compounding, can influence performance. Do not try to display hierarchical links through compounding. Use hierarchies instead. 

Note : A maximum of 13 characteristics can be compounded for an InfoObject. Note that characteristic values can also have a maximum of 60 characters. This includes the concatenated value, meaning the total length of the characteristic in compounding plus the length of the characteristic itself. Reference InfoObjects If an InfoObject has a reference InfoObject, it has its technical properties:

· For characteristics these are the data type and length as well as the master data (attributes, texts and hierarchies). The characteristic itself also has the operational semantics. 
· For key figures these are the key figure type, data type and the definition of the currency and unit of measure. The referencing key figure can have another aggregation. 

These properties can only be maintained with the reference InfoObject. Several InfoObjects can use the same reference InfoObject. InfoObjects of this type automatically have the same technical properties and master data. The operational semantics, that is the properties such as description, display, text selection, relevance to authorization, person responsible, constant, and attribute exclusively, are also maintained with characteristics that are based on one reference characteristic. 

Example : The characteristic Sold-to Party is based on the reference characteristic Customer and, therefore, has the same values, attributes, and texts. More than one characteristic can have the same reference characteristic: The characteristics Sending Cost Center and Receiving Cost Center both have the reference characteristic Cost Center. Assign Points if useful 

Example : Typically in a organization the employee id are allocated in serial like say 101, 102 and so on. Lets your Organization comes out with a new employee id scheme where the employee id for each location would start with 101. So the employee id starting for India would be India 101 and for UK would be UK/101. Now note that the employee India 101 and US/101 are different. Now if someone has to contact employee 101 he needs to know the location without which he cannot uniquely identify the employee. Hence in this case location is the compounding attribute.

Wednesday, 12 September 2012

OLAP

Introduction to SAP R/3

SAP R/3 is SAP's integrated software solution for client/server and distributed open systems.

The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web server is configured against the database server or how the Web server itself distributes the transaction and presentation logic.

SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:

Data Management 
Application Logic
Presentation

The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.

Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.

When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks.

Data Storage and Data Flow

Extraction, Transformation and Loading (ETL)

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 of SAP BW Architecture:

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.

Classic and Extended Star Schema Comparisons

In 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               SAP BW Star Schema
Cube                                         InfoCube
Fact Table                                 Key Figure or KPI
Dimension Attribute                   Characteristic, Attributes, Hierarchy Node
Dimension Table                        Dimension Table, Master Data Table, External Table, SID Table
-                                                Standard Business Content
-                                                Hierarchies
-                                                MultiCube
-                                                Remote Cube

Advantages of Classic Star Schema


Data access runs performantly due to the small number of joining operations.

There are only join operations between the fact tables and the involved dimension tables.

Disadvantages of Classic Star Schema


Redundant entries exist in the dimension tables

Historization of dimensions is not easy to model. The dimension changing may be done slowly.
No multi language capability
It is difficult to model some hierarchy’s dimension.
Query performance is also made worse, since aggregates and fact data are stored in the same table (fact table).

Advantages of the SAP BW Star Schema


Faster access to data than via long alpha-numeric keys. SAP BW use automatically generated INT4 keys for SID and Dimension ID

Can model in easy way: Historizing, multi-lingual, and shared dimensions. It is happen because of the excavation of master data from the dimension tables using the SID technique.
The query performance is improved here as aggregated key figures can be stored in their own fact tables.

OLAP and OLTP


Online Transaction Processing (OLTP) refers to a class of systems that facilitate and managetransaction-oriented applications, typically for data entry and retrieval transaction processing.

On Line Analytical Processing (OLAP), a series of protocols used mainly for business reporting. Using OLAP, businesses can analyze data in all manner of different ways planning, simulation, data warehouse reporting, and trend analysis.

OLAP and OLTP are two absolutely different systems since they have different purpose and environments. OLAP for analytical compare to OLTP for transactional.

Difference between OLAP and OLTP

Target 


OLTP is used in operative environment to get efficiency through automation of businessprocesses. OLAP is used in informative environment, usually used by management to support in decisions making.


Priorities 


As transactional system, OLTP has high availability and higher data volume.OLAP as analytical system is very simple data and has flexible data access.


Level of detail

OLTP stores data in a very high level of detail, whereas OLAP stores data in aggregation.

Age of data 


OLTP data are current data. It means the data stored in OLTP with minimal history. OLAP data are historical data.


Database operation


Frequent data changes are a feature of operative system. So, in OLTP system we can read, add, change, delete or refresh data. In OLAP, we only can read the data since they are frozen after a certain point for analysis purpose.


Integration of data from various applications (system) 


Since the OLTP system is for operation, it has minimal integration with other applications. In contrast to the OLTP system, OLAP need high integration of information from many application or system because it used for analysis.


Normalization in database 


Due to reduction in data redundancy, normalization is very high requirement in OLTP. In OLAP, typically de-normalized with fewer tables; use of extended star schema and lower performance.

SAP BI Terminology

InfoArea

Info Area is like “Folder” in Windows. InfoArea is used to organize InfoCubes, InfoObjects, MultiProviders, and InfoSets in SAP BW.

InfoObject Catalog 

Similar to InfoArea, InfoObject Catalog is used to organize the InfoObject based on their type. So we will have InfoObjects Catalogs of type Characteristics & KeyFigures.

Info Objects

It is the bsic unit or object in SAP BI used to create any structures in SAP BI. 
Each field in the source system is referred as InfoObject on SAP BI.
We have 5 types of Info Objects: Characteristic, KeyFigure, Time Characteristic, Unit Characteristic, and Technical Characteristic.

Data Source

Data Source defines Transfer Structure.
Transfer Structure indicates what fields and in what sequence are they being transferred from the source system. 
We have 4 types of data source:
Attr: used to load master data attr 
Text: Used to load text data 
Hier: used to load hierarchy data 
Transcation data: used to load transaction data to Info cube or ODS.

Source System

Source system is an application from where SAP BW extracts the data. 
We use Source system connection to connect different OLTP applications to SAP BI.
We have different adapters / connectors available:
SAP Connection Automatic
SAP Connection Manually 
My Self Connection
Flat file Interface
DB connect
External Systems with BAPI

Info Package

Info package is used to schedule the loading process. 
Info package is specific to data source. 
All properties what we see in the InfoPackage depends on the properties of the DataSource.