Data Modeling - V1.0

BI1001 - Data Modeling - v1.
India SAP CoE, Slide 1

Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
Prepare Me
THE GOAL
Data needs to be converted into
• Purpose Information in such a manner
that the Decision Support
• Use System can exploit it to the
fullest.
• Challenges
THE MEANS Designing efficient

BW achieves this goal for the ‘Data Model’
Business community and helps achieve this goal
enhances the analytical
capabilities after Extracting,
Transforming and Storing data
from Operational source
systems. HOW?
Shows this
course
Purpose
• Data modeling is the “backbone” of the BW system.
• It enables staging of information from large amount of

operative and historical data and permits multi-
dimensional analysis according to various business
perspectives.
• Thus the main purpose of data modeling is to structure

and organize all the necessary data for business users for
the purpose of analysis.

Use
• Data Modeling serves as the tool for managing the middle
phase of data warehousing i.e. it helps managing the
staging and transforming phase of data warehousing life
cycle.
• Its main use is to store the summarized data physically in

order to facilitate the BI reporting for the organization.
• It helps shaping and transforming the data to make it

suitable for reporting.
• It provides more flexibility in terms of data transformation as

compared to the source system due to availability of various
methods of data transformation.

Challenges
• Designing a complete and efficient data model that satisfies
the business need is the most important factor to the
success of a BI implementation.
• Identification of relevant business entities and their

relationships is critical while designing a Data model.
• Accurate mapping of the business entities with respect to

Business content objects in BW.
• Designing a comprehensive data model to support requisite

reporting KPIs.

Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
Introduction
• A data model represents classes of business entities,
their attributes, and relationships among those
entities and (often implicit) relationships among those
attributes.
• In data modeling, we structure, organize and store

data for business reporting.

Introduction
• Process Flow
• Data Models
– ERM
– MDM
• Conversion From ERM to MDM
• BW Data model
– Star Schema
– Extended Star Schema

Process Flow
PSA --> InfoSource-> Data Targets-> Infoproviders

Process Flow
• Data that logically belongs together is stored in the source system in the
form of DataSources. DataSources are used for extracting data from a
source system and for transferring data into the BW.
• The PSA is the input storage for data from the source systems in SAP
BW. The required data is then saved in the sources systems in
unchanged form.
• An InfoSource maps the individual fields of the DataSource to the

relevant InfoObjects. The data can then be transformed using transfer
rules.
• Update Rules specify how the data is updated from an InfoSource into a
Data Target
• Afterwards, the data can be updated to other Data targets /

InfoProviders. The InfoProvider provides the data for evaluation in
queries.

Data Models
• The two Data Models relevant in Data Warehousing are:
– ERM (Entity Relationship Model)
– MDM (Multi-Dimensional Model)
• ERM produces a data model of the specific area of

interest, using two basic concepts:
– Entities and
– Relationships between entities
• In MDM information model consists of:

– Numerical facts (or key figures in BW terminology) and
– Dimension attributes, meaning the business terms that
describe these facts

ER Model

ER Model
The strong entities cover the whole

model. All other entities are
dependent on these strong entities.

Multi-Dimensional Model

Multi-Dimensional Model
• The ‘Star schema’ is the most common way of
displaying the relations in an MDM and is therefore
often used as a synonym for the MDM itself.
• The facts (KPIs) are collected in a separate Fact table

and the dimensions (group of entities) are collected in
the Dimension tables.
• The dimension tables are joined to the fact table by

foreign key relationships and primary key relationships

Conversion From ERM to MDM

BW Data Model : Star Schema

BW Data Model: Star Schema
• Dimension tables are
groupings of related
characteristics.
• A dimension table
contains a generated
primary key and
characteristics.
• The keys of the

dimension tables are
interpreted as foreign
keys in the fact table.

BW Data Model: Star Schema
Fact Table
• The individual data records in the fact table are identified uniquely
by the keys of the dimension tables
• The fact table is maintained when transaction data is loaded
• Fact tables must have a relatively small number of columns (key

figures) and a large number of rows (data records)

Drawbacks of Star Schema
• Multilingual descriptions for attributes in the dimension
tables are not supported.
• Secondary indexes for the data are stored as

alphanumeric fields in comprehensive tables. This
makes it more difficult to access the data.
• If attributes of the dimensions change over time, there is

no way of maintaining the old and new values for the
attribute.

Extended Star Schema

• In contrast to the Classic
Star schema,
characteristics are not
components of the
dimension tables.
• A numeric key SID

(surrogate ID) is generated
for each characteristic. It
replaces the characteristic
as a component of the
Dimension table.

• Each Dimension table has a system generated numeric

'primary key' called the Dimension key of DIM ID.
• The primary key of the Fact table is then made up of the

combination of DIM IDs of various dimensions.
Advantages of Extended Star
Schema
• Avoids data redundancy and maintains data consistency as
master data is shared by all InfoCubes
• Multi-lingual capability is possible
• The use of DimIDs and SIDs enable faster access of data

as compared to the alpha-numberic keys of the Classic Star
schema
• It is easy to model Slowly changing dimensions and

Historisation of data using time reference

BW Objects
• The various structures provided for creating a Data
Model in SAP BW are:
– InfoObjects
– InfoCube
– ODS (Operational DataStore)
– MultiProvider
– InfoSet

InfoObjects
• Business evaluation objects are known in BW as
InfoObjects. They are the basic information providers
of BW and the smallest information units in BW.
• They structure the information needed to create
InfoCubes/ODS Objects.
• InfoObject types:
– Characteristics
• Basic
• Time
• Technical
– Key figures

Types of InfoObjects
• Characteristics InfoObjects are business reference
objects which are used to analyze key figures such as
company code, material, product, customer group.
• Key Figures InfoObjects provide values to be evaluated

such as quantity, amount, or number of items.

Types of InfoObjects
• Time characteristics are characteristics such as date,
fiscal year which are time indicators.
• Units Characteristic are 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.
• Technical characteristics are used for administrative

purposes only within BW. An example of a technical
characteristic is the request number in the InfoCube. This is
generated when you load a request as an ID and helps
locate the request at a later date.

Master Data – Attributes, Texts &
Hierarchy
• Characteristics bear master data (i.e. attributes, texts
or hierarchies) in BW.
• ‘Attributes’ are InfoObjects that are logically

subordinate to a characteristic.
• Types of Master Data attributes

– Display Attribute – Used for display purpose in report and
cannot be used for drill-down and filtering purpose. (for e.g.
Material weight or Material colour)
– Navigational Attribute – Navigational attribute can be used for
further analysis in reporting (e.g. Material group, Material
class)

Master Data – Attributes, Texts &
Hierarchy
• The description of the characteristic is stored as
InfoObject ‘text’.
– e.g. Material # 1000023456 has a description viz.
"Metallic Black Part 1L”.
• A ‘hierarchy’ forms a summarization and grouping for a

characteristic according to individual evaluation criteria.
– e.g. Material can have the 4 levels of hierarchy as
Product Category -> Product class-> Material group->
Material. These levels can be used in reporting for
further drill down in data

InfoObject Catalog
• An InfoObject catalog is a collection of InfoObjects
grouped according to application-specific criteria
• Types of InfoObject catalog

– Characteristic: This is the collection of Characteristics
InfoObjects
– Key figure: This is the collection of Key figures
InfoObjects

InfoObject Catalog

InfoCube
• InfoCubes are central objects of multi-dimensional model in SAP
BW. Reports and analysis are based on InfoCubes.
• An InfoCube describes an self-enclosed dataset for business-area

from a reporting point of view.
• An InfoCube consists of several InfoObjects and is structured

according to the star schema.
• An InfoCube is additive in nature, it aggregates data on the basis of

characteristics combinations.
• Types of InfoCubes
– Basic
• Basic InfoCube
• Transactional InfoCube
– Virtual InfoCube
• Remote Cube
• SAP Remote Cube
• Virtual InfoCube with Services
InfoCube

InfoCube
• 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.
• An InfoCube can have maximum of 16 dimensions (3

dimensions are provided by SAP i.e. Time, Data Package and
Unit). A maximum of 256 characteristics can be included in
each dimension.
• Dimension tables should be small with regards to data volume,

which is desirable for reasons of performance.

Transactional InfoCube
• A transactional InfoCube is a special Basic InfoCube,
especially developed for SAP SEM.
• The system accesses data in such a InfoCube is

transactional, in other words, data is written to the InfoCube
and instantly read again when required.
– e.g. In BW BPS, users enter plan data via planning
layouts which is in turn stored in Transactional
InfoCubes.
• A standard Basic InfoCube is optimized for pure read

access and hence not suitable here.

Virtual InfoCube
• Virtual InfoCubes are special InfoCubes. A virtual InfoCube
represents a logical view. Unlike Basic InfoCube, no data is
physically stored in BW. The data is taken from the source
system only after a query has been executed.
• SAP Remote Cube allows one to define queries with direct

access to transaction data in other SAP systems.
• Remote Cube allows reporting using data from non-SAP

systems. the external system transfers the requested data
to the OLAP processor via the BAPI.
• Virtual InfoCube with Services requires a user-defined

function module as a DataSource.

ODS
• An ODS object (Operational DataStore) acts as a
storage location for consolidated and cleaned-up
transaction data (transaction data or master data, for
example) on the document (atomic) level.
• An ODS object contains key fields (for example,

document number/item) and data fields that can also
contain character fields (for example, order status,
customer) and key figures.
• Types of ODS Object

– Basic ODS
– Transactional ODS

ODS

ODS
• Every ODS object is
represented on the database
by three transparent tables:
– Active data: A table
containing current status of
data
– Activation queue: New
data is saved in this table
before it is activated. The
data in this table is deleted
after activation.
– Change log: Contains the
complete (activation)
history of the changes to
ODS data

Transactional ODS
• A transactional ODS object differs from a standard ODS
object in the way it prepares data.
• In a standard ODS object, data is stored in different

versions (active, delta, modified), whereas a transactional
ODS object contains the data in a single version. Therefore,
data is stored in precisely the same form in which it was
written to the transactional ODS object by the application.
• The transactional ODS object is also required by diverse

application such as SAP SEM.
• Transactional ODS objects allow data to be available

quickly. The data from this kind of ODS object is accessed
transactionally and read again, as soon as possible.

Data Targets
• A data target is an object into which data is loaded.
Data targets are the physical objects that are relevant
during data modeling and when loading the data.
• Data targets are:

– InfoObjects (characteristics with attributes or texts)
– InfoCube
– ODS Objects

InfoObject as Data Target
• InfoObjects with attributes or texts can themselves also

be used as data target.
• If you want to turn a characteristic into a Data target /

InfoProvider, you have to assign an InfoArea to the
characteristic. The characteristic is subsequently
displayed in the InfoProvider tree in the Administrator
Workbench.
• The data is then loaded into the master data tables

using the update rules.

Data Targets vs InfoProvider
• Pure ‘Data targets’ do not have queries based on
them.
– An ODS object can be defined so that queries are not
possible (if the BEx Reporting indicator is not set in the
ODS object maintenance). In this case, it is a pure data
target.
– A transactional ODS object is always a pure data target,
for which a BEx query cannot be defined directly, but
only by way of an InfoSet created for it.
• Data targets for which queries can be defined. These

are called ‘InfoProviders’.
– Queries can always defined with Basic InfoCubes. A
Basic Cube is therefore never a pure data target, but
both a Data target and an InfoProvider.

InfoProviders
• An InfoProvider is an object for which queries can be
created or executed in BEx. InfoProviders are the
objects or views that are relevant for reporting.
• Types of InfoProviders:
– MultiProviders
– InfoSets
– Remote Cube
– SAP Remote Cube
– Virtual InfoCube with Services

MultiProvider
• A MultiProviders is a type of InfoProvider that combines data from
a number of InfoProviders and makes it available for analysis
purposes.
• The MultiProviders itself does not contain any data. Its data
comes entirely from the InfoProviders on which it is based.
MultiProviders only exist as a logical definition. These
InfoProviders are connected to one another by a union operation.
• A query based on a MultiProvider is divided internally into

subqueries. There is a subquery for each InfoProvider included in
the MultiProvider. These subqueries are usually processed in
parallel.
– InfoProvider A contains sales actuals. InfoProvider B contains sales
plan data. One can combine the two InfoProviders into one
MultiProvider to compare actual vs plan sales.

MultiProvider
• One can combine InfoCube,
ODS objects, InfoObjects and
InfoSets in a MultiProvider.
• A union operation is used to
combine the data from these
objects into a MultiProvider.
• Here, the system constructs
the union set of the data sets
involved. In other words, all
values of these data sets are
combined.

InfoSet
• InfoSets allows reporting on several InfoProviders by
using combinations of InfoObjects (master data-bearing
characteristics) and ODS objects via a join condition.
• An InfoSet can have following join conditions

– Inner Join
– Left Outer Join
• Inner join and left outer join are only different in the
situation where one of the involved tables does not
contain any suitable record which meets the join
conditions.

Inner vs Left-Outer Join
• Consider ODS object that contains a characteristic PLANT
alongside key figures in its data part. In an InfoSet, a join
between this ODS object and the characteristic PLANT is
defined to enable the attributes of PLANT to be accessed in a
report.
• If an inner join is now used and if an ODS object record

contains a value for PLANT for which they is no entry in the
corresponding master data table, this record is not included in
the results set. Correspondingly, the key figures of this record
would not be considered.
• If, on the other hand, a left outer join (ODS object left outer join
PLANT) is used, the affected record is considered. However,
in this case, all attributes of the (non-existent) characteristic
PLANT are initial. Which behavior is correct depends on the
type of the evaluation required. Both cases can make sense.

InfoSet

Components of ETL
• Components of ETL are:
– Source system
– DataSource
– InfoSource
• Communication Structure
• Transfer Structure
– Transfer Rules
– Update Rules
– Infopackage

Source System
• All systems that provide the SAP Business Information
Warehouse with data are described as source
systems.
• These are as below:

– SAP systems
– SAP Business Information Warehouse systems,
– Flat files, through which metadata is manually maintained, and
transferred into BW by using a file interface,
– A database management system into which data is loaded
from a database supported by SAP, using DB Connect and
not an external extraction program.
– External systems, in which data and metadata is transferred
using staging BAPIs.

Source System

DataSource
• DataSources are used for extracting data from a source system and
for transferring data into the BW.
• DataSources make the source system data available on request to

the BW in the form of the (if necessary, filtered and enhanced)
extraction structure.
• The DataSources subdivide the data that is provided by a source

system into self-contained business areas.
• In SAP source systems, the DataSources are assigned to

applications, for example HR (Human Resources). The advantage
here is that you are able to specifically access data evaluation for this
application.
• The information required for the extraction process, that is, the BW-
relevant properties of the DataSource, is replicated in the BW by
comparing metadata.
InfoSource
• An InfoSource is a set of information that logically belongs together,
summarized into a single unit. It prepares consolidated data for
updating to the data targets.
• InfoSources contain either transaction data or master data

(attributes, texts and hierarchies).
• An InfoSource comprises of Communication structure and Transfer

structure.
• The set of InfoObjects that logically belong together form the

communication structure. The transfer structure is used to transfer
data to the BW system. The data is transferred 1:1 from the transfer
structure of the source system into the BW transfer structure.
• Types of InfoSources
– InfoSources with flexible updating
– InfoSources with direct updating

InfoSource
• Flexible Update
– Here data from the communication structure is loaded
into the data targets (InfoCubes, ODS objects, master
data) using update rules.
– Several data targets can be defined by one InfoSource.
– The InfoSource can contain transaction data and master
data.

InfoSource
• Direct Update
– Master data (characteristics
with attributes, texts or
hierarchies) of an InfoObject
can be updated directly
(without update rules, only
using transfer rules) to the
master data table with an
InfoSource with direct updating.

Communication Structure
• The communication
structure is localized in
the SAP BW and displays
the structure of the
InfoSource.
• It contains all of the

InfoObjects belonging to
the InfoSource of the BW
system.

Transfer Structure
• Transfer Structure is a
selection of
DataSource fields from
a source system.
• The transfer structure

provides the BW with
all the source system
information available
for a business process.
• A transfer structure
always refers to a
DataSource in a source
system and an
InfoSource in a BW

Transfer Rules
• One can transform source system data in the
InfoSource with the help of Transfer rules.
• Transfer rule map the fields of the transfer

structure to that those in the communication
structure, using the different methods
– Direct mapping of InfoObjects
– Constants
– Formulae
– Routines

Update Rules
• Update rules specify how the data (key figures, time
characteristics, characteristics) is updated to data targets
from the communication structure of an InfoSource. Thus an
update rule connects an InfoSource to a Data target.
• An update rule must be specified for each key figure and the
corresponding characteristics of the InfoCube. For an ODS
Object, it must be specified for the data and key fields, and
for an InfoObject it must be specified for the attribute and key
fields.
• The following update types exist:

– No update
– Addition
– Overwriting (with ODS objects and InfoObjects only)

Update Rules
• The different update

methods provided are:
– Source field
– Constant
– Master data attribute
– Formula
– Routine

Infopackage
• Infopackage is used to load data from source system
to BW.
• Following are the different tabs of an Infopackage
– Data Selection : Restricts the data to be loaded
– External Data : For selection of flat files
– Processing : PSA staging options
– Data Target : Targets to be loaded
– Update : Full / Delta / Initial Load
– Schedule : Foreground or Background processing

Infopackage : Processing Types

Infopackage

PSA (Persistent Staging
Area)
• PSA is the inbound storage area for data from the
source systems in BW system.
• The requested data is saved, unchanged from the
source system
• Requested data is stored in the transfer structure
format in transparent, relational database tables in the
BW system.
• The data format remains unchanged, meaning that no
summarization or transformations take place, as is the
case with InfoCubes

Data Mart Concept
• The Data mart interface makes it possible to update data
from one data target into another.
• We have the following options:

– Data exchange of several BW Systems: The data-delivering
system is then referred to as the Source BW, the data-
receiving system as the Target BW. The individual Business
Information Warehouses arranged in such a way are called
data marts.
– Data exchange between BW Systems and other SAP Systems
– Data distribution within a BW System (Myself connection) :

The data mart interface in the Myself System is used to
connect the BW System to itself. This means you can update
data from data targets into other data targets within the
system.

PSA Staging scenarios

Use the staging process for storing data in an ODS object without
InfoCubes, when the transaction data is highly volatile and
constant changes are required to reporting data

Use a staging scenario without ODS levels if you can work without
the advantages of an ODS object (cleansing, transforming,
consolidating, integrating data from different processes, level of
detail of information)
This applies in particular if the system already guarantees the
integrity of the data (CO-PA, General Ledger)

This scenario is also known as a data mart scenario and is

characterized by the data flow from InfoCube to InfoCube, which
is possible within a BW System as well as between several
systems. Data marts created like this offer better overview and
dataset (snapshot) maintenance and allow you to separate the
data according to task area

Data Flow
• Steps involved in creation of
Data model in BW system
– Identify and create InfoObjects
– Create Data target / Infoprovider
– Replicate Datasource from source
system
– Create Infosource
– Assign Datasource to Infosource
– Define Transfer Rules
– Create Update Rules
– Create Infopackage and load data

Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
Creating InfoObjects Catalog
• Step1: Enter transaction RSA1. Right click on the
InfoArea and click on create InfoObject catalog
• Step2: Specify the description and technical name for

the catalog
• Step3: Select between a characteristic or key figure

catalog
• Step4: Click on create icon

Creating InfoObject Catalog
1. Right click on the InfoArea
and click on create InfoObject
catalog to get this screen
2. Give the description and
technical name for the
catalog
4. Click the
‘Create’ icon. 3. Select between a
characteristic or key
figure catalog

Adding InfoObjects to catalog
• Step1: Right click the ‘InfoObject Catalog’ and
choose ‘Change’
• Step2: Select the characteristics or key figures that

needs to be added to the catalog
• Step3: Click on ‘Transfer’ arrow to add the selected

InfoObjects to the InfoObject catalog.
• Step4: Activate the InfoObject catalog

Adding InfoObjects to Catalog
2. Click here to activate
the catalog after adding 1. Select the required
the InfoObjects InfoObjects from the
‘Template’ window and
use the ‘Transfer’
button to add these
Objects to the
InfoObject Catalog.

Creating InfoObject-Characteristic
• Step1: Select the characteristic catalog and right click and select create
InfoObject
• Step2: Provide a technical name and description for characteristic.
• Step3: Specify the general properties for the characteristics (e.g. Data type,
Length etc) in the ‘general’ tab.
• Step4: In ‘Business Explorer’ tab, specify the Reporting properties for the
InfoObject.
• Step5: In ‘Master data/Text’ tab specify if the InfoObject characteristics has
any master data or text by ticking the appropriate checkbox.
• Step6: In the ‘Hierarchy’ tab you can specify if the InfoObject characteristic
has any hierarchy
• Step7: In ‘Attribute’ tab you specify the characteristics that are attributes of
this characteristic.
• Step8: In ‘Compounding’ tab indicate the compounding key for the InfoObject
if the master data stored in this characteristic has compounded primary key.

Creating InfoObjects-Characteristics
1. To create InfoObject in
existing catalog right
click and select create
InfoObject

Here you can specify the

reference characteristics
name in case InfoObject
is using any reference
char
2. Mention the
Reference/ Template
characteristic (if any)

3. Add the general properties like

Data type CHAR, NUMC etc and data
length etc under this tab “General”

4. In this tab you

can specify the
reporting
properties for the
InfoObject

5. When the master data check

box is ticked, the InfoObject will
store master data attributes. One
will have to specify these
attributes in the ‘Attributes’ tab
subsequently.
When the “with Texts” box is

checked then the Characteristic
will contain texts as well.

6. This box is ticked if the

InfoObject has hierarchy to be
stored and then add the
hierarchy properties accordingly
(e.g. Time dependency and
Intervals)

7. If the InfoObject is
ticked as “with master
data” then in this tab we
can add attributes of the
master data

8. In this tab you

can specify the
compounding key
for the InfoObject
(if any)

Creating InfoObject - Key Figure
• Step1: Select the Key figure catalog and right click and select
create InfoObject
• Step2: Give the technical name and description for key figure.
Mention the template key figure to be used if any
• Step3: In ‘Type/Unit’ tab you specify the key figure properties like
data type quantity or amount etc. and relevant unit
• Step4: In ‘Aggregation’ tab you specify the aggregation method for

the key figure (summation, average etc)
• Step5: In ‘Additional Properties’ tab you specify the display

properties. These properties are applicable to display of data in
reports.

1. To create a key figure

InfoObject in existing
catalog right click and
select create InfoObject

2. Enter the key

figure technical
name and the
description.

3. In this tab you can
specify the data type
and details of
currency/unit etc

4. Specify the aggregation
method here for the key
figure

5. Describe the display properties

here. These settings affect the
display of data in reporting

Creating InfoCube
• Step1: Enter Transaction RSA1. Right Click on the InfoArea
and choose “Create” InfoCube and provide technical name
and description for the InfoCube.
• Step2: Select the Characteristics which should be part of the

InfoCube design.
• Step3: Select Time Characteristics and Key Figures.
• Step4: Create dimensions and assign the characteristics to

the dimensions
• Step6: Save and Activate the InfoCube.

Creating InfoCube
1. In RSA1, right click

on an InfoArea and
choose ‘Create
InfoCube’.

Creating InfoCube
2. Provide Technical
name and description
for the InfoCube
3. Select radio
button
4. Click on ‘BasicCube’.
‘Create’
button.

Creating InfoCube
5. In the Characteristics tab, select
the various characteristics required
in the InfoCube design (from the
‘Template’ window to the ‘Structure’
window).

Creating InfoCube
6. Similarly, select and
transfer the ‘Time
Characteristics’ and ‘Key
Figures’.

Creating InfoCube
7. Create dimensions by
clicking on create button.

Creating InfoCube
8. As per business logic,
assign the
characteristics to the
respective dimensions.

Creating InfoCube
9. Save and Activate
the InfoCube

Creating ODS
• Step1: Enter Transaction RSA1. Right click on the
InfoArea and choose “Create ODS”. Provide Technical
name and description for the ODS.
• Step2: Choose infoobjects in Key field and Data fields

of ODS.
• Step3: Adjust ODS settings appropriately.
• Step4: Save and Activate the ODS

Creating ODS

on an InfoArea and
choose ‘Create ODS
Object’.

Creating ODS
for the ODS
3. Click on
‘Create’
button.

Creating ODS
5. Choose
appropriate
settings of ODS
4. Choose Infoobjects
in key fields and data
fields section from left
hand panel

Creating ODS
6. Save and
Activate ODS

Creating MultiProvider
• Step1: Enter Transaction RSA1. Right Click on Infoarea and
select ‘Create MultiProvider’. Provide technical name and
description for the MultiProvider.
• Step2: Select Data Targets (InfoCube, ODS and InfoObject
or Infosets) on which MultiProvider should be based.
• Step3: Select the Characteristics which should be part of the
MultiProvider design.
• Step4: Select Time Characteristics and Key figures.
• Step5: Create dimensions and assign the characteristics to
the dimensions.
• Step6: Identify the characteristics, time characteristics and
key figures in ‘Identification’ tab.
• Step7: Save and Activate the MultiProvider.


on an InfoArea and
choose ‘Create
MultiProvider’.

for the MultiProvider
3. Click on
‘Create’
button.

4. Select Data Targets (InfoCube,

ODS and
InfoObject or Infosets) on which
MultiProvider would be based

5. In the Characteristics, Time

characteristics and Key figures tab,
select the various characteristics/key
figures required in the InfoCube
design (from the ‘Template’ window to
the ‘Structure’ window).

6. Create dimensions by
clicking on create button.

7. As per business logic,
assign the
characteristics to the
respective dimensions.

8. Click on
Identification pushbutton
on Characteristics, Time
Characteristics and Key
figures tab to identify
InfoObjects from
underlying data targets

9. For each InfoObject in MultiProvider,

identify the corresponding InfoObject
from data target

10. Save and Activate the

MultiProvider.

Creating InfoSet
• Step1: Enter Transaction RSA1. Right Click on InfoArea and
select ‘Create InfoSet’. Provide technical name and
description for the InfoSet.
• Step2: Choose ODS or InfoObject on which you want to build

InfoSet.
• Step3: Select the characteristics/key figures required in

InfoSet design and join the common characteristics via Inner
or Left Outer Join.
• Step 4: Save and Activate InfoSet.

Creating InfoSet

on an InfoArea and
choose ‘Create InfoSet’.

Creating InfoSet
for the InfoSet.
3. Choose ODS or
InfoObject on which
you want to build
InfoSet.

Creating InfoSet
4. Select the
characteristics/key
5. Join the common
figures required in
characteristics via Inner
InfoSet design or Left Outer Join.

Creating InfoSet
5. Save and
Activate InfoSet.

Creating Flat File Source System
• Step1: In RSA1 transaction, select ‘Source System’.
• Step2: Right click on Source System in right panel

and select ‘Create’.
• Step3: Select ‘File System’.
• Step4: Provide a Logical System Name and Source

System name.

2. Right click on ‘Source

System’ and select
‘Create’.
1. In RSA1
transaction, select
‘Source System’.

3. Select ‘File
System’.

4. Enter a ‘Logical
system name’ and
‘Source system
name’.

5. Flat file Source

system is now
created.

Creating InfoSource
• Step1: In InfoSource menu (RSA1 transaction), right
click on an Application component and select ‘Create
InfSource’.
• Step2: Choose the InfoSource type (Flexible or Direct

Update) and provide technical name and description
to InfoSource.
• Step3: Enter the InfoObjects to be included in

Communication structure.
• Step 4: Save and Activate the InfoSource.

Creating InfoSource
1. Right click on
Application
component and
select ‘Create
InfoSource’.

Creating InfoSource
2. Choose the
InfoSource type (Flexible
or Direct Update) and
provide technical name
and description to
InfoSource.

Creating InfoSource
3. Select a template
or key in the
InfoObjects in
Communication
Structure.

Creating InfoSource
4. Save and
Activate the
InfoSource.

Assigning DataSource to
InfoSource
• Step1: Right click the InfoSource and select ‘Assign
DataSource’.
• Step2: Select the Source System of the DataSource.
• Step3: Select the DataSource existing in this source

system and confirm assignment.

InfoSource
1. Right click the

InfoSource and
select ‘Assign
DataSource’.

InfoSource
2. Select the
Source System
of the
DataSource’.

InfoSource
3. If multiple DataSources are
available, then system prompts
to choose Datasource. Select
appropriate Datasource and
press ‘Yes’ to confirm
assignment of DataSource to
InfoSource.

InfoSource
4. System proposes
assignment of InfoObjects to
Datasource fields or we can
manually assign InfoObjects to
fields from Datasource.

Creating Update Rule
• Step1: Right click on Data Target and then select
“Create update rule”.
• Step2: Specify the Update type, update method and unit

for key figure calculation.
• Step3: Specify the Update method for the characteristics
• Step4: Specify the Update method for time

characteristics.
• Step5: Check and activate the update rule

1. Right click on an
Infocube and choose
‘Create Update Rules’.

2. In the below screen, specify

an InfoSource/ ODS/ InfoCube
appropriately.

3. For each key figure,

specify mapping with
appropriate source
InfoObject.

For InfoCube we have two
update type
– Addition
– No Update
There exists three update

method for Key figures
– Source key Fig
– Formula
– Routine
One can also specify

‘currency translation’
function here.

4. Specify appropriate
mapping for Characteristics
and Time Characteristics.

Creating Infopackage
• Step1: Right click on Source system below the selected
InfoSource and choose ‘Create Infopackage’.
• Step2: Enter Infopackage Description.
• Step3: Enter appropriate restrictions in ‘Data Selection’

tab. For Flat file data load, enter the path for flat file in
‘External Data’ tab. Select appropriate processing type in
‘Processing’ tab. Select Data targets to be loaded in
‘Data Target’ tab. Select update type in ‘Update’ tab.
Start Infopackage load in ‘Schedule’ tab.

1. Right click on Source

system below the selected
InfoSource and choose ‘Create
Infopackage’.

2. Enter
Infopackage
description.

3. Enter restrictions (if any) in

‘Data Selection’ tab.

4. Enter path for flat file in

‘External Data’ tab.

5. Select appropriate
processing type in
‘Processing’ tab.

6. Select data targets to be

loaded in ‘Data Targets’ tab.

7. Select update type in

‘Update’ tab.

8. Start Infopackage load in

‘Schedule’ tab.

Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
LetMe
• For the following scenario develop a data model in BW
– A flat file source system (CSV file) provides the following
information
– Identify InfoObjects (Characteristics and Key Figures)

– Identify key fields and data fields of ODS
– Create ODS Object as data staging layer
– Create Infosource
– Create Update Rules between InfoSource and ODS
– Identify Dimensions of InfoCube
– Create InfoCube for Sales summary (without sales order
granularity)
– Create Update Rules between ODS and Infocube
– Create Infopackage for loading data in ODS and InfoCube

Transactions Used
• RSA1 : Administrator Work Bench.

• RSA11: Create and Maintenance of Data Targets and
InfoProviders.
• RSA12: Create and Maintenance InfoSource.
• RSA13: Create and Maintenance of Source System.
• RSA14: Create and Maintenance InfoObjects.
• RSA15: Create and Maintenance of PSA.
• RSD1: Edit infoobjects

Data Modeling
1 PrepareMe
2 TellMe
3 ShowMe
4 LetMe
5 HelpMe
HelpMe
Browse through the below links for Self Study
1. http://help.sap.com/saphelp_nw04/helpdata/en/e3/e60138
fede083de10000009b38f8cf/frameset.htm
2. http://service.sap.com/bi

Data Modeling - V1.0

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Data Modeling - V1.0

Cargado por

Copyright:

Formatos disponibles

BI1001 - Data Modeling - v1.

India SAP CoE, Slide 1

THE MEANS Designing efficient

• It enables staging of information from large amount of

• Thus the main purpose of data modeling is to structure

India SAP CoE, Slide 5

• Its main use is to store the summarized data physically in

• It helps shaping and transforming the data to make it

• It provides more flexibility in terms of data transformation as

India SAP CoE, Slide 6

• Identification of relevant business entities and their

• Accurate mapping of the business entities with respect to

• Designing a comprehensive data model to support requisite

India SAP CoE, Slide 7

• In data modeling, we structure, organize and store

India SAP CoE, Slide 9

India SAP CoE, Slide 10

PSA --> InfoSource-> Data Targets-> Infoproviders

India SAP CoE, Slide 11

• An InfoSource maps the individual fields of the DataSource to the

• Afterwards, the data can be updated to other Data targets /

India SAP CoE, Slide 12

• ERM produces a data model of the specific area of

• In MDM information model consists of:

India SAP CoE, Slide 13

India SAP CoE, Slide 14

The strong entities cover the whole

India SAP CoE, Slide 15

India SAP CoE, Slide 16

• The facts (KPIs) are collected in a separate Fact table

• The dimension tables are joined to the fact table by

India SAP CoE, Slide 17

India SAP CoE, Slide 18

India SAP CoE, Slide 19

• The keys of the

India SAP CoE, Slide 20

• The fact table is maintained when transaction data is loaded

• Fact tables must have a relatively small number of columns (key

India SAP CoE, Slide 21

• Secondary indexes for the data are stored as

• If attributes of the dimensions change over time, there is

India SAP CoE, Slide 22

India SAP CoE, Slide 23

• A numeric key SID

India SAP CoE, Slide 24

• Each Dimension table has a system generated numeric

• The primary key of the Fact table is then made up of the

• Multi-lingual capability is possible

• The use of DimIDs and SIDs enable faster access of data

• It is easy to model Slowly changing dimensions and

India SAP CoE, Slide 26

India SAP CoE, Slide 27

India SAP CoE, Slide 28

• Key Figures InfoObjects provide values to be evaluated

India SAP CoE, Slide 29

• Units Characteristic are required so that the values for the

• Technical characteristics are used for administrative

India SAP CoE, Slide 30

• ‘Attributes’ are InfoObjects that are logically

• Types of Master Data attributes

India SAP CoE, Slide 31

• A ‘hierarchy’ forms a summarization and grouping for a

India SAP CoE, Slide 32

• Types of InfoObject catalog