Dmm302 - Sap Hana Data Warehousing: Models for Sap Bw and SQL DW on SAP HANA

Public
DMM302 - SAP HANA Data Warehousing: Models
for SAP BW and SQL DW on SAP HANA

© 2016 SAP SE or an SAP affiliate company. All rights reserved. 2Public
Speakers
Bangalore, October 5 - 7
Sreepriya, G
Las Vegas, Sept 19 - 23
Marc Bernard
Josh Djupstrom
Barcelona, Nov 8 - 10
Juergen Haupt
Ulrich Christ

Disclaimer
The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of
SAP. Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or
any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this
presentation or any related document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms
directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice.
The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality.
This presentation is provided without a warranty of any kind, either express or implied, including but not limited to, the implied
warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation is for informational
purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this
presentation, except if such damages were caused by SAP’s intentional or gross negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially
from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only
as of their dates, and they should not be relied upon in making purchasing decisions.

Agenda
SAP HANA DW directions
SAP HANA DW - evolving the DWH to a Business Analytics Platform
SAP HANA DW and DWH data model
 Dynamic dimensional model for BW on HANA – business and pattern-driven HANA DW
– Building a flexible DWH core capable absorbing changes with minimal impact
– Building agile extensions of the DWH core integrating any raw/ field data
 Composition Model for SAP HANA SQL DW – customer-defined HANA DW
Summary

Application driven approach, SAP BW as EDW
application with integrated services
• SAP BW as an application serves as a platform offering all
required data warehousing services via one integrated
repository
 No additional tools for modelling, monitoring and managing
the data warehouse required, but can be integrated
SAP BW
SAP HANA
Scheduling &
Monitoring
Modeling Planning
OLAP
Lifecycle
Management
ETL
Scheduling
Tool
Modeling Tools
Planning
Tool
Monitoring
Tool
Lifecycle
Management Tool
ETL
Tool
SQL driven approach, SAP HANA with loosely
coupled tools and platform services, logically
combined
 Database approaches require several loosely couple tools
to fulfill the necessary tasks with separate repositories
 A combination of tools (such as best of breed) used to build
the data warehouse
SAP – Data Warehousing approaches
Two approaches
SAP HANA

SAP HANA DWSAP HANA DW SAP HANA DWSAP HANA DWSAP HANA DWSAP HANA DW
Optional Components
DW Foundation
Power
Designer
HANA EIM
Business
Warehouse
SAP HANA
Platform
SAP HANA
Platform
Planning and Definition VisionExecution and delivery
2015 2016 - 2018
Market presence in Data Warehousing
with a clear roadmap
Strong and simplified
offering with tight integration
Convergence into one technology
stack addressing BW and SQL
based DW needs
DWH
Foundation
Power
Designer
HANA
EIM
Business
Warehouse
SAP HANA PlatformSAP HANA Platform
DW ModelingDW Modeling DW ETL & DMDW ETL & DM
SAP HANA
Platform
SAP HANA
Platform
Analytics , BI Suite, Predictive Analytics , BI Suite, Predictive Analytics , BI Suite, Predictive
Hadoop
SAP HANA Vora
Hadoop
SAP HANA Vora
Hadoop
SAP HANA Vora
Hadoop
SAP HANA Vora
Hadoop
SAP HANA Vora
Hadoop
SAP HANA Vora
Statement of Direction – Current DW Portfolio

Public
SAP HANA DW - evolving the DWH to a
Business Analytics Platform

Traditional DWH layer architecture / LSA (Layered Scalable Architecture)
Still appropriate on SAP HANA ?
Business Integrated DWH/
Propagation Layer
Propagation Layer
Architected Data Marts
SourceSource
Staging
Acquisition Layer
Raw DWH/
Open ODS Layer
Query-ready data
Cross source
harmonized, cleansed data
• Source related data with DWH
services
• For comparison with integrated
DWH
Prepare data for DWH
Source data
Topdownmodeling
• Hierarchical Architecture
• Data Mart Layer as the query able
layer
• All Layers primarily as service
provider for the Data Mart Layer
• Data moved from layer to layer
• Costly top down modeling process –
time to market ….
• ..
Still the only way?

Propagation Layer
historic
historic
SAP HANA DW
The ‚simplified DWH‘ perspective of LSA++
Business/ Service Level
Requirements
Architected Data MartsArchitected Data Marts
most recent
Virtual Data Marts/ Virtual Transformations
BottomupBottomup
Topdown
Data In-Hub/ Staging
Acquisition Layer
Raw DWH/
Open ODS Layer
actual/ most recent
SourceSource / Data Lake/ Data Lake
• Integrated business entities & values
• Integrate multiple sources/ raw DWHs
 Virtual Data Marts on any Layer
 Virtual Transformations
 Source dominated DWH
 Source driven DWH entities & values
Normally obsolete
 Virtual Transforms
 Data Consumption

SAP HANA DW and Business Analytics Platform
Emancipation of data, communication, integration, orchestration
SAP HANA promotes a DWH Core that supports
1. Flexibility extending the persisted DWH
2. Agility virtually extending the persisted DWH
3. Direct Analytics on DWH layers – no explicit Data
Mart Layer
4. Virtual Combination of DWH layers – reduce
redundancies
5. Virtual Combination of DWH with remote data
(federation, the Business Analytics Platform)
6. Evolutionary Data Warehouse – complement
Top-Down solutions with Bottom-Up approach - service
level driven

From DWH to Business Analytics Platform
The Logical Data Warehouse perspective of LSA++ for SAP HANA DW
Data In-Hub/ ODS Raw DWH
Business
Integrated DWH
Data Lake Analytical Area/
Virtual Solution
CommunicationCommunication CommunicationCommunication CommunicationCommunication
Communication, Integration & Orchestration
SAP HANA & BW Services
 Non hierarchical, loosely coupled Information Areas
 Clear service definitions
 Communication, Integration, Orchestration rules
ERP, S/4HANA

Public
SAP HANA DW and DWH data model

Business Integrated DWH
Data-InHub
Raw DWH
Source
SAP HANA DW & DWH data models
Data Models in concert – for query-performance, flexibility & ease of integration
Data Models everywhere:
Dimensional Model
Data Marts: Dimensional Model
• Dimensional Model
• Composition Model
• Data Vault Model
3NF Model
3NF Model
The data warehouse data model for a SAP HANA
DW should promote
• Performant querying on persisted DWH Layer
data without creation of additional persisted
Data Marts
• Ease of integration of any data outside of the
HANA DW (Agility)
• Flexibility covering classic DWH requirements
Persisteddata
Virtual Data Marts
• Dimensional Model
• Composition Model
• Data Vault Model

Legacy Source Model Observations:
• GUIDs (BINARY(16)) as Keys e.g.
NODE_KEY of SNWD_SO
• Date-fields as DECIMAL(21,7) e.g.
CREATED_AT of SNWD_SO
• Hierarchical relations via foreign-key e.g.
PARENT_KEY of SNWD_EMPLOYEES
• Business-Keys as attributes e.g.
PRODUCT_ID of SNWD_PD
From legacy 3NF source model to a HANA DW data model
Basis for our examples
Master data
Transactiondata
Master data

Public
Dynamic dimensional model for BW on HANA –
business and pattern-driven HANA DW
Building a flexible DWH core capable absorbing changes with minimal impact

Data In-Hub/ Staging
Acquisition Layer
BW on HANA and LSA++
Modeling the core DWH using InfoObjects - examples
Business/ Service Level Requirements
Architected Data MartsArchitected Data Marts
Virtual Data Marts/ Virtualization
BottomupBottomup
Topdown
 Source dominated DWH
 Source driven DWH entities & values
• Integrated business entities & values
• Data from multiple sources/ raw DWHs
Raw DWH/
Open ODS Layer
SourceSource / Data Lake/ Data Lake
Propagation Layer

BW dimensional modeling - BW flat star schema until BW 740 SP8
Automated star schema generation
Flat InfoCube, DSO (classic)
FACT Table
Dimension
e.g. Product
BW on HANA
Flat Star Schema
InfoObject
InfoObjects
Nav. Attributes
InfoObject
Nav. Attributes
InfoObject
Nav. Attributes
InfoObject
Nav. Attributes
Dimension
e.g. Customer
Dimension
e.g. Location
Dimension
Time
Keywords:
• Fact data & dimension data defined via InfoObjects
• InfoObjects of Fact-table define Dimensions
• Automated Association of Master Data (Dimensions)
• Highly de-normalized i.e. all attributes of a Dimension
in one place (InfoObject p-/q-table)
• High performance schema but
• Limited flexibility adding new attributes
• Limited flexibility adding new relationships (e.g. n:m)

BW dimensional modeling
BW views define the dynamic star schema – 1st
overview
FACT Table
Dimension
e.g. Product BW on HANA
Dynamic Star SchemaInfoObject
InfoObjects/ Fields
Nav. Attributes
Open ODS View Master
Nav. Attributes
Nav. Attributes
InfoObject
Nav. Attributes
Dimension
e.g. Customer
Dimension
e.g. Location
Dimension
Time
DSO (advanced), DB-Table/ View,
InfoCube, DSO (classic),
CompositeProvider/
Open ODS View Type Fact
Keywords:
• Persistency's defined by InfoObjects or
Fields
• Star Schema defined by a BW View i.e.
CompositeProvider/ Open ODS View type
fact
• Flexible and Agile Association of
Dimensions i.e. InfoObject or Open ODS
View type master
• Partitioned/ split Dimensions
• Snow-flaked Dimensions (transitive
attributes)

BW on HANA dimensions modeling using InfoObjects
Complete de-normalization of master data into InfoObjects – example 1
SNWD_PD
NODE_KEY
PRODUCT_ID
TYPE_CODE
CREATED_BY
CREATED_AT
CHANGED_BY
CHANGED_AT
NAME_GUID
DESC_GUID
SUPPLIER_GUID
TAX_TARIF_CODE
MEASURE_UNIT
WEIGHT_MEASURE
WEIGHT_UNIT
CURRENCY_CODE
PRICE
PRODUCT_PIC_URL
DUMMY_FIELD_PD
CATEGORY
VARBINARY(16)
NVARCHAR(10)
NVARCHAR(2)
VARBINARY(16)
DECIMAL(21,7)
VARBINARY(16)
DECIMAL(21,7)
VARBINARY(16)
VARBINARY(16)
VARBINARY(16)
SMALLINT
NVARCHAR(3)
DECIMAL(13,3)
NVARCHAR(3)
NVARCHAR(5)
DECIMAL(15,2)
NVARCHAR(255)
NVARCHAR(1)
NVARCHAR(40)
<pk>
<fk3>
<fk2>
<fk5>
<fk6>
<fk4>
<fk1>
SNWD_PD_CATGOS
CATEGORY
MAIN_CATEGORY
NVARCHAR(40)
NVARCHAR(40)
<pk>
was created
was changedhas name
has
supplier
has category
has description
from
Employee master
from
Employee master
from Business-
Partner master
from
Category master
BW Dimension modeling using InfoObjects as
we did it for a long time : all Attributes
assigned to one InfoObject
InfoObject IPD_DIM_1
with Attributes
Product_ID
Primary-key
dependent attributes
Employee -
Foreign-key
Business-Partner -
Foreign-key
Employee -
Foreign-key
De-normalization using
DB-views or Extractors:
join all Product-relevant data
direct Product-Key
dependent
attributes
Product related
Source Tables DB-View

Modeling the DWH-core with BW on HANA
Advanced DSO
not for querying
Assignsourcetoviewfields
BusinessPartner: IBP_ID
Employess: IEMP_ID
SalesOrder: SO_ID
SalesOrder_Item: SOI_POS
Product: IPD_DIM_1
Time: SO_CR_AT
AssociateDimensions:
AssociateInfoObjects/OpenODSViews
Dimensions / InfoObjects
Fact table = advanced DSO
Dynamic Star Schema = CompositeProvider
All product relevant
attributes in
InfoObject
IPD_DIM_1

What happens, if we forgot to bring
an attribute MAIN-CATEGORY into
the InfoObject IPD_DIM_1?
Add the MAIN-CATEGORY to
IPD_DIM_1 to and reload IPD_DIM_1
(the Dimension) ?
What happens, if a complete new
source arise with a set of product-
attributes?
How to deal with all the time-
characteristics ?
Add all new attributes to IPD_DIM_1 and
reload IPD_DIM_1 (the Dimension) ?

Pros and cons of completely de-normalized dimensions/ InfoObjects
from
Employee master
from
Employee master
from Business-
Partner master
from
Category master
Completely de-normalized
Dimensions
• High performance even for complex queries– ‚no‘ joins during run-time
• Works best in stable situations (rare changes to ‘joined‘ master data)
• Means redundancies and thus realignment situations if ‘joined‘ master
data have to be initialized newly
• New attributes of ‘joined‘ master data or integrating new attributes from a
new source means change and reload of dimensions / InfoObjects
• Working as a ‘shared‘ Dimension serving multiple Star Schemas/ fact
tables (business needs) makes it difficult to maintain big entity
dimensions / InfoObjects like for Product, Business Partner etc
InfoObject IPD_DIM_1
with Attributes
Product_ID
Primary-key
Employee -
Foreign-key
Business-Partner -
Foreign-key
Employee -
Foreign-key
BW on HANA offers new features modeling DWH Dimensions/
InfoObjects more flexible if volatility of situation requires it
• InfoObject transitive Attributes (snow-flaking) - BW on HANA V 7.50 SP4
• Split Dimension into multiple InfoObjects/ Open ODS type master

BW on HANA dynamic dimensional model
More flexibility – more agility
BW on HANA Dynamic Star Schema
• Virtual Star Schema modeling via CompositeProvider and Open ODS Views of type fact
• Dimensions modeling for flexibility
• InfoObject transitive Attributes (snow-flaking)
• Partitioned/ Split Dimension into multiple InfoObjects/ Open ODS Views type master
• Federating data across layers for agility
• Remote Dimensions (parts of) via Open ODS Views type fact
• Remote Fact-tables
• Mixed scenarios
• …
Flexibility as DWH capability smoothly adopting changes physically (source-model and data)
Agility as DWH capability interacting and integrating data virtually and physically with minimized IT involvement
BW on HANA goes the direction for increased flexibility of physically modeling data and of agile, scalable
integration of any data

BW on HANA dynamic star schema – flexibility & agility
Define Dimensions
BW managed:
• Advanced DSO dominated by
InfoObjects or BW-type compatible Fields
BW managed:
InfoObject tables
CompositeProvider Open ODS View
BW managed:
• Advanced DSO dominated by fields
• HANA Upsert/ Insert-table of BW
HANA DataSource
Define Facts
Open ODS View InfoObject
De-normalized
Split/ partitioned/ Satellites
Snow-flaked/ transitive Attr.
persisteddata
Logical Partitioned
Data w. Aging (NLS)
Just data
Modeled data
Foreign managed:
• Local HANA tables/ DB-views
(mix scenarios)
Foreign managed:
• Remote/ virtual tables/ DB-views
(federation scenarios)
Raw DWH Layer / Open ODS Layer / Data InHub/ Data Lake/ Source Layer
Business Integrated DWH Layer / Propagation Layer
Temporal join

Transitive attributes – snow-flaking an InfoObject dimension – example 2
What happens, if we forgot to bring an
attribute MAIN-CATEGORY into the
InfoObject IPD_DIM_1?
The MAIN-CATEGORY (IPD_CATM) is
navigational attribute of CATEGORY
(IPD_CAT)
Context menu
• Assign navigational attribute
IPD_CATM of navigational attribute
IPD_CAT as transitive attribute
• Original, other, new InfoObject as
transitive attribute
MAIN-CATEGORY (IPD_CATM) is transitive
attribute and behaves like a navigational
attribute of IPD_DIM_1

Modeling the DWH-Core with BW on HANA
Transitive attributes – snow-flaking an InfoObject dimension – example 3
de-normalized Dimension
Snow-flaking:
• Eliminate attributes from the
dimension table that are not direct
dependent from the primary-key
• Eliminate navigational attributes
from an InfoObject that are
dependent from a navigational
attributes
normalized snow-flaked
Product Dimension

InfoObject transitive attributes – snow-flaking
Normalize a de-normalized Dimension – example 3
InfoObject IPD_SNOWF
has only a few navigational
attributes
• Assign navigational attribute of navigational
attribute as transitive attribute
• Original, other, new InfoObject as transitive
attribute
• Multiple snow-flaking of same InfoObject
(Employee) via referencing InfoObjects
• All Date-InfoObjects have standard navigational
time attributes
Context menu
Marked navigational attributes that
have navigational attributes

Normalize a de-normalized Dimension – example 3
has only a few navigational
attributes
has active transitive attributes

BW dynamic star schema with snow-flaked dimension – example 3
Fact-aDSO
Composite Provider builds
Dynamic Star Schema
Time Dimension
Generated from
SO Creation Date
InfoObjects IPD_SNOWF with
transitive attributes
Product Dimension
Transitive attributes

InfoObject transitive attributes
Modeling simple hierarchical relations – example 4
SNWD_EMPLOYEES
NODE_KEY
PARENT_KEY
EMPLOYEE_ID
FIRST_NAME
MIDDLE_NAME
LAST_NAME
INITIALS
SEX
LANGUAGE
PHONE_NUMBER
FAX_NUMBER
MOBILE_NUMBER
EMAIL_ADDRESS
LOGIN_NAME
PR_ADDRESS_GUID
VAL_START_DATE
VAL_END_DATE
CURRENCY
SALARY_AMOUNT
ACCOUNT_NUMBER
BANK_ID
BANK_NAME
EMPLOYEE_PIC_URL
VARBINARY(16)
VARBINARY(16)
NVARCHAR(10)
NVARCHAR(40)
NVARCHAR(40)
NVARCHAR(40)
NVARCHAR(10)
NVARCHAR(1)
NVARCHAR(1)
NVARCHAR(30)
NVARCHAR(30)
NVARCHAR(30)
NVARCHAR(255)
NVARCHAR(12)
VARBINARY(16)
NVARCHAR(8)
NVARCHAR(8)
NVARCHAR(5)
DECIMAL(15,2)
NVARCHAR(10)
NVARCHAR(10)
NVARCHAR(255)
NVARCHAR(255)
<pk>
<fk1>
<fk2>
Source master data e.g.
EMPLOYEES references
itself via PARENT_KEY –
what means a hierarchical
relationship
If a navigational attribute addresses
the same master data like the
Characteristic itself proceed as
follows:
• Create Reference-Characteristic
for PARENT_KEY (IEMP_PAR)
that references the Employee-
Characteristic (IEMP_ID) .
• Define the navigational Attributes
of the Characteristic IEMP_PAR
(PARENT_KEY) as transitive
Attributes
• Use again reference-
characteristics to define the
wanted transitive attributes
Source
Input DataSource
Propagation Layer
Propagation Layer
reference

InfoObject transitive attributes
Modeling simple hierarchical relations – example 4
From ‘parent’
InfoObject IEMP_PAR referencing
IEMP_ID

BW dynamic dimensional modeling
BW dynamic star schemas – snow-flaked dimensions
FACT Table
Dimension
e.g. Product
BW on HANA
Dynamic Star Schema
InfoObject
InfoObjects/ Fields
Nav. Attributes
Nav. Attributes
Nav. Attributes
InfoObject
Nav. Attributes
Dimension
e.g. Customer
Dimension
e.g. Location
Dimension
Time
DSO (advanced), DB-Table/ View,
InfoCube, DSO (classic),
CompositeProvider/
Open ODS View Type Fact
Keywords:
• Persistency's defined by InfoObjects or
Fields
• Star Schema defined by a BW View
i.e. CompositeProvider/ Open ODS
View type fact
• Flexible and Agile Association of
Dimensions i.e. InfoObject or Open
ODS View type master
• Partitioned/ split Dimensions
• Snow-flaked Dimensions (transitive
attributes)
InfoObject
Nav. Attributes

Modeling InfoObject dimensions
De-normalized or snow-flaked via transitive attributes?
de-normalized
Product Dimension
normalized snow-flaked
Product Dimension
Any mixture of de-normalized and
normalized snow-flaked modeling
As always: this is not a black or white question!
Modeling snow-flaked InfoObject dimensions make sense
• If foreign key entities and its attributes have different owners/ volatility
compared to the direct attribute of the primary-key of the Dimension /
InfoObject
• Keeping the core-dimension-table (InfoObject) slim, transparent and
maintainable
• If the value of de-normalizing foreign key attributes isn‘t obvious in the
business context of a dimension e.g. Employee that created a Product and
her/ his privat address
Modeling snow-flaked InfoObject dimensions make little sense
• If the values of the foreign-key attributes will not change
• Should be carefully examined if the cardinality of the primary key is high
Snow-flaking dimensions is a flavor of virtualization compared
to a de-normalized Dimension. A de-normalized dimension
means nothing else than materialized joins. Snow-flaking
dimensions means joining the data building the dimensions at
run-time.

Simplification – InfoObjects supporting transitive attributes
New with SAP BW 7.5 SP4 – a BW roadmap slide
Transitive Attributes for InfoObjects
 Add navigational attributes of one InfoObject as navigation attributes to
another InfoObject
 Ability to extend a star schema to snow flaking
• At present two levels are allowed
Increased Flexibility, Maintainability, Less Redundancy
 Changes in parent InfoObjects do not affect children
 Easier data provisioning / staging to InfoObjects (e.g. 3NF sources) and
advanced DataStore Objects
0COSTCENTER 0COMP_CODE 0PROFIT_CTR 0PCA_DEPART
0PROFIT_CTR 0RESP_USER 0PCA_DEPART
InfoObject Nav. Attr.
Nav. Attr.InfoObject Transitive
Attribute
(joined at runtime)

BW dynamic star schema – flexibility through split/ partitioned dimensions
Define Dimensions
BW managed:
BW managed:
InfoObject tables
BW managed:
HANA DataSource
Define Facts
De-normalized
persisteddata
Logical Partitioned
Data w. Aging (NLS)
Just data
Modeled data
Foreign managed:
(mix scenarios)
Foreign managed:
Temporal join

Complex Business Entities
The need for flexible master data modeling
Customer example:
Challenges of master data modeling:
• Semantically different understanding of a Material
 PBG – Product corporate
 PRD – Sales Product
 ART – Article
 and a lot more: techn. materials, packaging ....
• Elements of material hierarchy as material
• Multitude of attributes
UB – Operating Division
BU – Business Unit
SBU – Strategic Business Unit
MG – Main Group
AC - Sub Group
Complex Business Entities
Pretty clear: De-normalize all Attributes into a single InfoObject is no solution!

Product Dimension
Dimension_Y
Dimension_X
BW on HANA dynamic star schema –
Split/ partition dimensions using InfoObjects – build dimension satellites* - example 5
InfoObject_1 NAV_ATTR_1A
Dynamic Star Schema modeling
InfoObject_2 NAV_ATTR_2A NAV_ATTR_2B
BW Dynamic Star Schema – Multiple InfoObjects form a Split/ Partitioned Dimension:
InfoObjects
NAV_ATTR_2C
NAV_ATTR_1B
IPD_TEC IPD_SIZE ..
DSO (advanced)
(DSO (classic), InfoCube)
Composite Provider
F_InfoObject_1
F_InfoObject_2
IPD_SNOWF_1
F_Key_Fig_1
F_Key_Fig_N
IPD_SNOWF_2
IPD_SNOWF IPD_CAT IPD_MCAT
• Multiple InfoObjects associated to
same source InfoObject create a
split / partitioned dimension
(satellites)
Dimensions/ Master Data Modeling
persisted data
modeling
InfoObjects -
Generated tables
InfoObject_1
InfoObject_2
Key_Fig_1
Key_Fig_N
IPD_SNOWF
Product Dimension
Satellites
*The term ‘Satellites’ was introduced by Dan Linstedt

Managing complex master data through partitioned/ split dimensions
Multiple InfoObjects for same DWH entity – create dimension satellites - example 5
Better: split/ partition the Dimension
creating a new BW master data object –
here a new InfoObject
new attributes for
Product arrive from
different owner
Integrate new attributes
into existing Dimension
(InfoObject) i.e. de-normalize further ?
Snow-flaking does not help
• A CompositeProvider allows mapping (advanced DSO)
source InfoObjects or Fields to multiple CompositeProvider
target fields . Each CompositeProvider target field allows
associating different InfoObjects together forming a split /
partitioned dimension
Scenario area
CompositeProvider
Model InfoObjects
Source
Model

Managing complex master data through partitioned/ split dimensions
CompositeProvider addressing multiple InfoObjects for same DWH entity - example 5
• A CompositeProvider allows mapping (advanced DSO)
source InfoObjects or Fields to multiple CompositeProvider
target fields . Each CompositeProvider target field allows
associating different InfoObjects together forming a split /
partitioned dimension
Product Dimension
Part: InfoObject IPD_SNOWF with
Transitive Attribute Main Category
Output area
CompositeProvider
Preview
CompositeProviderSatellite with
commercial data
Satellite with
technical data
Product Dimension
Part: InfoObject IPD_TEC with
Navigational Attribute Product Size technical

BW dynamic star schema and business integrated layer flexibility
Partition/ split dimension into dimension satellites using InfoObjects
Attributes of a DWH entity may behave
differently caused by different owners and
different business requirements
• Storing attributes with different behavior together in a
single dimension (InfoObject) may impact overall
stability, maintenance and availability
• In this case you should examine splitting/ partitioning
the dimension creating Dimension Satellites using
multiple InfoObjects
Summary: We can achieve flexibility with respect to Master Data introducing new attributes without impacting existing
• Persisted data (downtime)
• Data Flows and transformations (stability, testing)
Snow-flaking (transitive Attributes) and splitting dimensions into dimension satellites means that we invest gained HANA
performance into flexibility through virtualization, joining dimension data at query run-time

Introducing n:m relations at any time with minimal impact - example 6
What's about adding new attributes to a combination of DWH-entities i.e. adding attributes to an n:m relation between two
Entities?
Example: you have PRODUCT and BUSINESS_PARTNER in the fact table
• Product has attributes
• Business-Partner has attributes
And we now we want to add attributes at PRODUCT - BUSINESS_PARTNER level e.g. DISCOUNT– How to do it without
impacting existing persisted data and data flows of the Business Integrated/ Propagation Layer?
Pretty simple:
• Create a new InfoObject that compounds PRODUCT with BUSINESS_PARTNER and define the new Attributes like
DISCOUNT as navigational attribute and load the InfoObject
• In a CompositeProvider add PRODUCT a second time (split dimension!) as target and associated the new Compound-
InfoObject – that’s it!

Introducing n:m relations at any time - example 6
Compound InfoObject IPDBP_ID
Modeling n:m relationship between
Product & B-Partner
On CompositeProvider-level virtual integration
of new compound InfoObject IPDBP_ID like
any other split-dimension satellite is done
without touching any existing persistency
(advanced DSO(s), InfoObject(s)) !
InfoObjects
related to Product
InfoObjects
related to B-Partner
InfoObjects
related to Product & B-Partner
CompositeProvider
Sources





Introducing n:m relations at any time without changing existing persisted data or data flows - example 6
Product Dimension
InfoObject IPD_SNOWF with
Product-B-Partner Dimension
New InfoObject IPDBP_ID
On CompositeProvider-level virtual integration of new Compound InfoObject IPDBP_ID is done like any
other split Dimension satellite without touching any existing persistency or flow!
Output area
CompositeProvider
Preview
CompositeProvider
Associate compound
InfoObject
IPDBP_ID

Public
Dynamic dimensional model for BW on HANA –
business and pattern-driven HANA DW
Building agile extensions of the DWH core integrating any raw/ field data

BW on HANA dynamic modeling
Agility through cross layer solution modeling – from DWH to a Business Analytics Platform
So far we learned about the Flexibility modeling the Business Integrated/ Propagation Layer with BW on HANA (…LSA++ for
Simplified Data Warehousing)
• A stable, consistent and flexible Core-DWH follows a Top-Down modeling approach designing first the InfoObjects and
followed by Dimensions and Facts
The Core-DWH is the fundament transforming a DWH into a Business Analytics Platform i.e. enabling new solutions
combining, integrating and orchestrating data across layers.
Extending the Core-DWH towards a Business Analytics Platform we need the agility of tools (BW & HANA) and processes
that support
• Combination, integration, orchestration of any data with this Core-DWH
• Scalability reaching from ‘on short notice’ to ‘persisted’ integration
In short – we need a Bottom-Up Logical Data Warehousing strategy (… LSA++ for Logical Data Warehousing)

SAP HANA DW and Business Analytics Platform
Emancipation of data, communication, integration, orchestration
SAP HANA promotes a DWH Core that supports
1. Flexibility extending the persisted DWH
2. Agility virtually extending the persisted DWH
3. Direct Analytics on DWH layers – no explicit Data
Mart Layer
4. Virtual Combination of DWH layers – reduce
redundancies
5. Virtual Combination of DWH with remote data
(federation, the Business Analytics Platform)
6. Evolutionary Data Warehouse – complement
Top-Down solutions with Bottom-Up approach - service
level driven

From DWH to Business Analytics Platform
The Logical Data Warehouse perspective of LSA++ for SAP HANA DW
Data In-Hub/ ODS Raw DWH
Business
Integrated DWH
Data Lake Analytical Area/
Virtual Solution
 Non hierarchical, loosely coupled Information Areas
 Clear service definitions
 Communication, Integration, Orchestration rules
ERP, S/4HANA

Dynamic - being flexible & agile – agility through cross layer modeling & virtual integration
Define Dimensions
BW managed:
BW managed:
InfoObject tables
BW managed:
HANA DataSource
Define Facts
De-normalized
persisteddata
Logical Partitioned
Data w. Aging (NLS)
Just data
Modeled data
Foreign managed:
(mix scenarios)
Foreign managed:
Temporal join

Recall: Modeling functions and integration with BW on HANA
Cross layer modeling - integrating top-down and bottom-up modeling
Integration modeling
 Map fields to InfoObjects
Function modeling
 Queries
 Schemas
 Persistencies, Staging
Integration modeling
InfoObjects Fields
HANA BW Modeling Options
Integration before Function Function before Integration

Making BW on HANA a Business Analytics Platform
Steps integrating data from any layer/ location with BW dynamic dimensional model
Expanding an existing BW dynamic dimensional model of Business Integration (Propagation) Layer based on
InfoObjects with any data from any layer (local or remote):
• Addressing data
• remote via BW HANA-DataSources and HANA Smart Data Integration
• local via BW HANA-DataSources
• Semantics and model integration
• Open ODS Views type fact, master or text
• Physical integration
• BW HANA DataSources managed replication of remote data (Upsert-, Insert-Tables)
• Advanced DSO using Fields/ InfoObjects
• Transformations i.e. prepare raw data for use with DWH context data
• BW Transformations and Structures (DataSource, InfoSource, advanced DSO)
• HANA/ sql transformations - flavor of Mixed Scenarios
• HANA SDQ (Smart Data Quality) - flavor of Mixed Scenarios (not in focus of lecture)
• Or a combination (clear guidelines necessary!)

Query/ CompositeProvider / HANA Model
Table
SQL/ HANA View
HANADB
Table TableaDSO View/Table
aDSO
Recall: Open ODS Views & BW dynamic dimensional model
Modeling raw/ field data with Open ODS Views
Query/ CompositeProvider / HANA Model
Open
ODS View
Master data
InfoObject
RawDWH
Integrated
DWH
Open
ODS View
Master data
Open
ODS View
Fact data
InfoObject
Master data
Virtual Data Mart
View/Table
 The BW metadata model for field data consists of entities – the
Open ODS Views – defining
– Semantics of sources
(fact, master.. data)
– Semantics of source-fields
(characteristic, key figure,…)
– Associations to other Open ODS Views
– Associations to InfoObjects
 ODS Views are view constructs on various
types of source objects
– BW aDSOs/ InfoSource/ DataSources
– DB tables & SQL/ HANA views
– Virtual tables -HANA Smart Data Access
 The source object of an ODS view can be
exchanged
 From a BW-OLAP perspective, ODS Views can be consumed like
InfoProviders (facts) or InfoObjects (master data, text)

What means dynamic? Being flexible & agile
Modeling a Dimension in BW on HANA
Defined by one or any combination of
1. InfoObject + Navigational Attributes
2. InfoObject + Navigational Attributes + (Navigational Attributes of a
Navigational Attribute) – snow-flaking / transitive Attributes
3. Splitting Dimensions in multiple InfoObjects and/ or Open ODS Views
4. Open ODS View type master on aDSO w. Fields/ InfoObjects (Raw Layer)
5. Open ODS View type master on Table/ DB-view (replicate, Data InHub)
6. Open ODS View type master on HANA virtual table (remote/ federation)
Source
Flexible &
Agile




Integrating data from any layer using Open ODS Views
Model & semantics integration: introduce new n:m relationship virtually - example 7
CompositeProvider
Open ODS View type master
Fact data
Advanced DSO
Source

Integrating data from any layer using Open ODS Views
Model & semantics integration: introduce new n:m relationship virtually - example 7
Product-B-Partner Dimension
Open ODS View O_PD_BPA_V
On CompositeProvider-level virtual integration of a table or DB-view via an Open ODS View O_PD_BPA_V
is done fully virtually like with any other split Dimension satellite without touching any existing data or flow!
New relations 1:n, n:m or just new attributes can be introduced at any time with no impact on existing solutions!
Product Dimension
InfoObject IPD_SNOWF with

BW dynamic dimensional modeling and Open ODS Views
Agile data integration across layers via Open ODS Views as Dimension Satellites (Split/ Partition)
• Attributes of an entity may reside in
different layers
• The BW Dynamic Model split dimension
pattern allows addressing multiple
persisted dimension satellites
• Dimension persistencies described by
fields (table, DB-View, advanced DSO) are
integrated via Open ODS Views
Open ODS View
O_PD_BPA_V
CompositeProvider
IPD_ID_1
IPD_ID_2
Attributes
INFOOBJECT
IPD_SNOWFDSO (advanced)DSO (advanced)
PRODUCT: IPD_SNOWFPRODUCT: IPD_SNOWF
……
Analytic Area
Product Dimension
Business Integrated DWH Layer/
Propagation Layer
Attributes
Product Dimension Satellites
DSO (advanced) /
Local/ remote table/view
DSO (advanced) /
Local/ remote table/view
RAW DWH Layer/ Open ODS/
Data In-Hub/ Source

• Addressing data
• remote via BW HANA DataSources and HANA Smart Data Integration
• local via BW HANA DataSources
• Semantics and model Integration
• Physical Integration
• HANA/ SQL View transformations - flavor of Mixed Scenarios

DB-View Transform: Integration Joins, any Transform
BW on HANA transformation options for virtual data integration
Virtual integration between Business Integration Layer and Raw / Source Layers
Tables remote or local
<Fields>
BW DataSource
<Fields>
BW InfoSource
<Fields>/ <InfoObjects>
BW advanced DSO
BW advanced DSO
<InfoObjects>
CompositeProvider
Master/ Fact Open ODS View
InfoObject
<InfoObjects>
SQL/ HANA
Views
SQL/ HANA
Views
virtual integration
Raw DWH /
Open ODS Layer
Propagation Layer
InHub/ Inbound /
Source
DataSource Transform : Integration Type/ Length
Open ODS View Transform - we do our best
Options performing data Transformations integrating virtually Raw DWH/ Open ODS Layer or source level data with
Business Integrated DWH/ Propagation Layer data using Open ODS Views
DB-View Transform: Integration Joins, any Transform
BW Transform: Integration
Transforms

Virtual integration between Business Integration Layer and Raw / Source Layers – example 8
• Join tables
• Provide key-mappings from
source to DWH-key e.g.
• Raw key (NODE_KEY ->
PRODUCT_ID)
• EMPC_CREATED_BY ->
EMPC_EMPLOYEE_ID
• Provide transforms – sql-cast
SQL/ HANA
Views
BW DataSource
<Fields>
• Provide BW DWH Business
transforms e.g.
• CUKY, CURR, DATS, UNIT,..
• Provide generic transforms e.g.
• DEC -> CHAR …
Tables remote or local
<Fields>
• Provide generic transforms
• Provide DWH semantics and
associations
• Be part of Dynamic Dimensional
Model
Master/ Fact Open ODS View
a date
The
DWH-
key
a currency
a
currency-
code
Join
key-mapping
delivered
Access tables directly

Virtual integration between Business Integration Layer and Raw / Source Layers – example 8
Tables  SQL-View  BW DataSource  Master Open ODS View  Dimension (Satellite) in CompositeProvider
CompositeProvider
Satellite part of
Business Integrated DWH
Satellite part of
Source

Key transformations for virtual data integration
Key mapping between layers is the prerequisite for integration
CompositeProvider
Open ODS View
aDSO –
master data
aDSO-
key info
HANA View
master data aDSO
HANA View
Join and/ or do
mapping of Raw
keys to Business
keys
Business Integrated
DWH/
Propagation Layer
Raw DWH /
Open ODS Layer
Virtual mapping of Raw DWH keys to
Business Integrated DWH keys
• HANA View for complex integration
transformations between Business
Integrated DWH and Raw DWH (Mix
Scenario)
• Simple key-mappings with provided in an
aDSO or InfoObject can be handled via
CompositeProvider and Open ODS View
What is the difference to storing the key-mapping
information persisted with Business Integrated data
or Raw DWH data?
• If you want to become mapping changes
immediately effective to all data – virtualization is
the solution
• If you want to keep the key-mapping for already
loaded data – persist the key mapping or go for
temporal joins (Slowly Changing Dimensions Type
2)
Open ODS View
Simple map -
BW Scenario
Open ODS View
HANA View
On Key aDSO
HANA View
Join
Simple map –
mix Scenario
associate
join
Generated HANA Views
complex map –
mix Scenario

Key transformations for virtual data integration –
Example 9
aDSO –
master data
aDSO -
key info
RawDWH/
OpenODSLayer
Business Integrated Key IPD_ID

Simple transform using CompositeProvider - Example 9.1
aDSO -
key info
aDSO –
master data
join
Associate Open
ODS View
Raw DWH /
Open ODS Layer
Join
Transform
Semantics
/ model
transform
Create Open ODS View
Integrate
CompositeProvider
associating
raw
Product Satellite
to mapped keys

Simple transform using HANA Views - Example 9.2
Generated HANA Views
aDSO –
master data
aDSO -
key info
Generated
HANA Views
"_SYS_BIC"."PM_T_2016/R_I_PD_MAP_VIEW"
Generated SQL View


Create Open ODS View

CompositeProvider
associating
raw
Product Satellite
with mapped keys
Key mapping established
In Open ODS View
Join
Transform
Semantics
/ model
transform
Integrate

Key transformations for virtual data integration

• Addressing data
• remote via BW HANA DataSources and HANA Smart Data Integration
• local via BW HANA DataSources
• Semantics and model Integration
• Physical Integration
• HANA/ SQL View transformations - flavor of Mixed Scenarios

SAP HANA
SAP BW
HANA
Remote Source
Table/View
Smart Data Integration
Smart Data Access
Advanced
DSO
HANA DataSource
DIRECT
ACCESS
OpenODS View
Virtual
CompositeProvider
Virtual
REAL TIME
Streaming
Table/View
REPLICATION
Platform Integration – HANA SDI
New with SAP BW 7.5 SP4
67Public© 2016 SAP SE or an SAP affiliate company. All rights reserved.
Integration Scenarios with SAP BW – General Availability
• Direct access to any Smart Data Integration (SDI) remote source*
via Open ODS View
• SDI real-time replication managed by HANA DataSource
• UPSERT table for actual view / INSERT table for history preserving
• Replicate source data in original format to BW (using HANA data types)
• Inbuilt mapping of source data types to ABAP data types when using HANA
DataSource in reporting or ETL loads within BW
• Direct access from OpenODS View to HANA DataSource
• Full / delta upload into advanced DataStore Objects
• Real-time streaming from UPSERT / INSERT table into advanced DataStore
Object possible
• SAP HANA Multi-tenant Database Container (MDC) support for HANA
DataSource (SAP BW 7.5 SP5, BWMT 1.15)**
• SAP HANA DataSource Integration with Streaming Process Chains
UPSERT
Table
* See Documentation: Data Provisioning Adapters
** See SAP Note 2312583
INSERT
Table

Public
Composition Model for SAP HANA SQL DW –
customer-defined HANA DW

Selecting a data model for HANA SQL-DW
3NF Model
Data Vault model
Composition model

Extremely different ways modeling a DWH
Dimensional model (Kimball) and data vault model (Lindstedt, Inmon)
SNWD_PD_DE_NORMALIZED
NODE_KEY
PRODUCT_ID
TYPE_CODE
CREATED_BY
CREATED_AT
CHANGED_BY
CHANGED_AT
NAME_GUID
DESC_GUID
SUPPLIER_GUID
TAX_TARIF_CODE
MEASURE_UNIT
WEIGHT_MEASURE
WEIGHT_UNIT
CURRENCY_CODE
PRICE
PRODUCT_PIC_URL
WIDTH
DEPTH
HEIGHT
DIM_UNIT
DUMMY_FIELD_PD
CATEGORY
MAIN_CATEGORY
BP_ROLE
EMAIL_ADDRESS
PHONE_NUMBER
FAX_NUMBER
WEB_ADDRESS
BP_ID
COMPANY_NAME
LEGAL_FORM
EMPLOYEE_ID
LAST_NAME
FIRST_NAME
EMAIL_ADDRESS2
PARENT_KEY
NODE_KEY2
NODE_KEY3
LANGUAGE
NODE_KEY4
TEXT
VARBINARY(16)
NVARCHAR(10)
NVARCHAR(2)
VARBINARY(16)
DECIMAL(21,7)
VARBINARY(16)
DECIMAL(21,7)
VARBINARY(16)
VARBINARY(16)
VARBINARY(16)
SMALLINT
NVARCHAR(3)
DECIMAL(13,3)
NVARCHAR(3)
NVARCHAR(5)
DECIMAL(15,2)
NVARCHAR(255)
DECIMAL(13,3)
DECIMAL(13,3)
DECIMAL(13,3)
NVARCHAR(3)
NVARCHAR(1)
NVARCHAR(40)
NVARCHAR(40)
NVARCHAR(3)
NVARCHAR(255)
NVARCHAR(30)
NVARCHAR(30)
NVARCHAR(255)
NVARCHAR(10)
NVARCHAR(80)
NVARCHAR(10)
NVARCHAR(10)
NVARCHAR(40)
NVARCHAR(40)
NVARCHAR(255)
VARBINARY(16)
VARBINARY(16)
VARBINARY(16)
NVARCHAR(1)
VARBINARY(16)
NVARCHAR(255)
Foreignkeyspointtoentities
‘No‘ foreign keys
foreign keys modeled as entities (links – red tables)
transactional Hub data
transactional/
factdata
‘split‘ data-
atomize
Dimensional modeled
persisted DWH
Data Vault modeled
persisted DWH
‘join’ data –
de-normalize
3NF modeled –
source data
What DWH model fits best
to SAP HANA DWH ?

HANA SQL DW - selecting a DWH data model
Customer preferences – situation - requirements
De-
normalized
Atomic
Dimensional Composition Data Vault
SQL-DW Data Vault
 Fully traceable and auditable
 Full history tracking
 Full flexibility
 Need of persisted Star Schemas
- Agility ? Complexity ?
Composition Model for HANA
SQL-DW
 Query-able DWH
 Customer-defined services
 Scalable flexibility
Dimensional Model
 High Performance DWH-Querying
 Business oriented
BW Dynamic Dimensional
scalable Composition model

Composition model for HANA SQL-DW
Introduction
The composition model follows the SAP HANA direction minimizing
persisted data in our landscape i.e.
 Enable direct querying on any persisted DWH layer
 Avoid persisted Star schema creation on top of persisted DWH layer
 Be pragmatic with respect to usage and degree of DWH services &
patterns (-> customer decisions)
 History/ Versioning
 Auditability
 Flexibility (e.g. usage of surrogate keys, degree of normalization)
 …
 Be scalable with respect to later introduction of DWH services through
virtualization
Satellites – split attributesSatellites – split attributes
Entity – the key(s)Entity – the key(s)
The composition model for a HANA SQL-DW is a pragmatic modeling approach
 Combining strengths of the dimensional model with other modeling approaches (e.g. data vault)
 Having business requirements in focus instead of theoretical paradigms

Entity–satellite* pattern design basics
Ownership:
Volatility - Stability
History –
Snapshot
Federated -
RepositoryBottom up (incremental) –
Top down (comprehensive)
High volume -
Normal
Entity-Satellite Design Drivers
Raw (Source Key) -
Integrated (Business Key/
Surrogate Key)
Normalized (flexible) –
De-normalized (agile)
Real time -
DWH services
Entity as root:
• Query/ retrieval
• Consistency
• Load synchronization
• Integration
Entity – the key(s)Entity – the key(s)
DWH Design Drivers
*The term ‘Satellites’ was introduced by Dan Linstedt

Modeling the HANA SQL-DW with composition model
Example A – SNWD source model

Modeling the HANA SQL-DW with composition model
Example A – from 3NF to composition model
3NF model tables composition model tables

BK-PK11 BK-PKA FROM TO
time-dependent
Attr13 Attr14BK-PK11 BK-PKA FROM TO
time-dependent
Attr13 Attr14
Entity-satellite pattern
BK-PKA
technical attributes
entity ‘A‘ entity table
BK-PKA FROM TO
time-dependent attributes
A1 A2 A3 A4 BK-PKB BK-PKC C1 BK-PKD
entity ‘A‘ satellite tables (time-dependent)
BK-PKA
not time-dependent
Attr11 Attr12 BK-PKXBK-PKA
not time-dependent
Attr11 Attr12 BK-PKXBK-PKA
not time-dependent attributes
A5 A6 A7 A8 A9 BK-PKX X1 X2 X3
entity ‘A‘satellite tables (not time-dependent)
Entity B Entity D

Entity-satellite pattern – entity tables
Entities define the subjects like Materials, Employees, Sales-Orders … and get an own entity table
• Entity tables store field(s) that define the business key as primary key
• DWH Surrogate-keys may be used
• Technical Fields
• Origin
• Date when inserted
• Once inserted these fields are never changed or deleted
Special entity design options
• n:m relationships between entities
• E.g. Material on Plant level

Entity-satellite pattern – satellites tables
The composition model seperates the attributes of an entity from the entity keys
• Satellites tables store the attributes of an entity
• Attributes of core entities should be stored in different satellite tables taken ownership, volatility, …. into account
• The satellite tables inherit the primary key of the entity
• Satellites are either of type Snapshot or Versioned
• Versioned Satellite tables have in addition a Valid_From field
as part of the primary key
• 1:n relations are stored as foreign-keys in satellites
• 1:n relations may be stored as dedicated entity table
• The field DWH_ACTIVE_RECORD addresses the actual record
• Records are never deleted (‘reset’ DWH_ACTIVE_FROM)
Satellite-Snapshot Satellite-Snapshot

Entity-satellite pattern – special aspects
• History/ versions for attribute needs always a satellite table
• Actual snapshot attributes may be stored in the entity table for
simplicity reasons (transaction data entities for example)
Satellite-Snapshot
Satellite-Snapshot

• Versioned and snapshot data ?
• Volatile situation, core entity ?
 Entity + snow-flaked versioned and
snapshot satellites
• Versioned data ?
 Add a versioned satellite:
• Just actual data (snapshots) ?
 Add a snapshot satellite:
Evolutionary DWH design with composition model
Start simple and evolve – minimize impact of model changes
• Just actual data (snapshots) ?
• Stable situation, simple entity ?
 A simple dimension table will do:
newattributesarrive
new attributes arrive
requirements increase
challenging requirements
Start simple and evolve
twobasicoptions

Virtual data marts with calculation views on composition model
Example – querying the DWH layers
EPM_BUSINESS_PARTNER_DIM_ACT
EPM_STAR_SO_HDR

Composition model for HANA DW
BW on HANA takes over management of entities and satellites
3NF Model
Composition Model with BW on HANA

BW on HANA takes over management of entities and satellites
Calculation views build virtual data marts
BW_BUSINESS_PARTNER_DIM_ACT
Composition model with
BW on HANA
Generated Views on
Composition Model with
BW on HANA
Build Dimension & Fact
Views on Composition
Model with BW on HANA

Composition model for HANA DW
Virtual data marts on SQL-DW and BW on HANA
Star Schema on Composition Model on
HANA SQL-DW
Star Schema on Composition Model on
BW on HANA
… the result is the same …

SAP HANA DW data model
Streamlining proven DWH services – use the value of virtualization - summary
SAP HANA DW data model direction:
Evolving a DWH to a Business Analytics Platform
• The BW on HANA dynamic dimensional model and
• The composition model for SAP HANA SQL-DW
Both modeling approaches support
1. A flexible persisted DWH capable absorbing changes
with minimal impact
2. An agile DWH capable integrating virtually any data –
local or remote
3. Direct Analytics on DWH layers – no explicit Data Mart Layer
4. Virtual Combination of DWH layers – reduce redundancies
5. Evolutionary Data Warehouse in addition to core-DWH
deployment – complement Top-Down solutions with Bottom-Up
approach - service level driven
two sides of the
same coin

Thanks for attending this session.
Please complete your
session evaluation for
DMM302.
Contact information:
Juergen Haupt
juergen.haupt@sap.com
Ulrich Christ
Dr.
ulrich.christ@sap.com
Feedback

Further information
Related SAP TechEd sessions:
DMM265 – SAP HANA Data Warehousing: Introduction to Data Modeling in SAP HANA
DMM213 – SAP HANA Data Warehousing: Data Lifecycle Management and Data Aging
DMM270 – SAP HANA Data Warehousing: Simplified Modeling with SAP BW 7.5 SP4
DMM272 – SAP HANA Data Warehousing: Mixed Scenario for SAP BW and SQL DW on SAP HANA
DMM300 – Mixed Scenarios for SAP HANA Data Warehousing: Overview and Experiences
Hands-On Workshop
Lecture
Hands-On Workshop
Hands-On Workshop
Lecture
SAP Public Web
scn.sap.com
www.sap.com
SAP Education and Certification Opportunities
www.sap.com/education
Watch SAP TechEd Online
www.sapteched.com/online

SAP TechEd Online
Continue your SAP TechEd
education after the event!
Access replays of
 Keynotes
 Demo Jam
 SAP TechEd live interviews
 Select lecture sessions
 Hands-on sessions
 …
http://sapteched.com/online

Dmm302 - Sap Hana Data Warehousing: Models for Sap Bw and SQL DW on SAP HANA

More Related Content

What's hot

Viewers also liked

Similar to Dmm302 - Sap Hana Data Warehousing: Models for Sap Bw and SQL DW on SAP HANA

More from Luc Vanrobays

Recently uploaded

Dmm302 - Sap Hana Data Warehousing: Models for Sap Bw and SQL DW on SAP HANA