SAP Business Warehouse

SAP BW powered by SAP HANA:Data Warehouse Modeling

..

PARTICIPANT HANDBOOKINSTRUCTOR-LED TRAINING

.Course Version: 15Course Duration: 5 Day(s)Material Number: 50136494

For Any SAP / IBM / Oracle - Materials Purchase Visit : www.erpexams.com OR Contact Via Email Directly At : [email protected]




SAP Copyrights and Trademarks

© 2017 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP SE or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and othercountries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additionaltrademark information and notices.

Some software products marketed by SAP SE and its distributors contain proprietary softwarecomponents of other software vendors.

National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liablefor errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliatecompany products and services are those that are set forth in the express warranty statementsaccompanying such products and services, if any. Nothing herein should be construed as constituting anadditional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of businessoutlined in this document or any related presentation, or to develop or release any functionalitymentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’strategy and possible future developments, products, and/or platform directions and functionality areall subject to change and may be changed by SAP SE or its affiliated companies at any time for anyreason without notice. The information in this document is not a commitment, promise, or legalobligation to deliver any material, code, or functionality. All forward-looking statements are subject tovarious 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 speakonly as of their dates, and they should not be relied upon in making purchasing decisions.

© Copyright. All rights reserved. iii



Typographic Conventions

American English is the standard used in this handbook.

The following typographic conventions are also used.

This information is displayed in the instructor’s presentation

Demonstration

Procedure

Warning or Caution

Hint

Related or Additional Information

Facilitated Discussion

User interface control Example text

Window title Example text

iv © Copyright. All rights reserved.



Contents

ix Course Overview

1 Unit 1: Data Modeling with SAP Business Information Warehouse (SAPBW) Powered by SAP HANA

3 Lesson: Understanding Modeling Objectives and Issues13 Exercise 1: Identify and Solve Possible Conflicts18 Lesson: Understanding SAP HANA From a Modeling Perspective30 Lesson: Understanding SAP BW From a Modeling Perspective42 Lesson: Comparing SAP BW with SAP HANA57 Lesson: Understand the Strategy for SAP BW on SAP HANA

59 Unit 2: Business Review

60 Lesson: Mapping Current Processes64 Lesson: Getting to Know the ITelO Case Study75 Exercise 2: Log On to the Relevant Applications87 Lesson: Understanding the Relevant Skills and Exercises

89 Unit 3: Global Decision Areas and Best Practice Standards

91 Lesson: Evaluating Global Standards and Local Adaptations101 Lesson: Planning Transport Management107 Exercise 3: Use Object Changeability111 Lesson: Separating Master Data and Transactional Data119 Lesson: Designing a Layered Scalable Architecture (LSA) With

Virtual Layers153 Exercise 4: Identify LSA++ Layers in Existing Models162 Lesson: Understanding Scenarios for SAP BW on SAP HANA171 Lesson: Understanding LSA++ Domains176 Lesson: Understanding Reporting Options179 Exercise 5: Run a Report with Multiple Hierarchies in SAP

BusinessObjects Analysis for Office187 Exercise 6: Navigate Through the World Sales Report in SAP

BusinessObjects Crystal Reports

191 Unit 4: Process of Modeling

192 Lesson: Defining the Sequence of SAP BW Projects198 Lesson: Planning the Phases of a SAP BW Project208 Lesson: Developing a Logical Data Model212 Lesson: Developing an SAP BW Data Model221 Exercise 7: Perform a Requirement Analysis for ITeLO231 Exercise 8: Perform an Architecture Overview251 Exercise 9: Identify Key Fields and Dependent Fields

© Copyright. All rights reserved. v



257 Unit 5: Field-Based Rapid Prototyping

258 Lesson: Getting an Overview SAP HANA Live263 Lesson: Overviewing Business Content273 Exercise 10: Compare Data Models with Business Content293 Lesson: Implementing Field-Based Modeling303 Exercise 11: Create a CompositeProvider Containing Two Open

ODS Views from Different Sources

317 Unit 6: Master Data Modeling in SAP HANA Views

318 Lesson: Using Hierarchies in SAP HANA Views331 Exercise 12: Enhance an Existing Calculation View of Type

Dimension with a Hierarchy

339 Unit 7: Transaction Data Modeling With SAP HANA

340 Lesson: Using Measures in SAP HANA Views353 Exercise 13: Enhance an Existing Calculation View with Formula

and Currency Conversion

367 Unit 8: Master Data Modeling With SAP BW Characteristics

368 Lesson: Listing Tables in the SAP BW Data Model377 Exercise 14: Examine Characteristic Tables391 Lesson: Using Reference Characteristics394 Lesson: Using Hierarchies in SAP BW Characterisitcs397 Exercise 15: Model a Hierarchy417 Exercise 16: Evaluate Time-Dependent Hierarchy Structures

423 Unit 9: Key Figure Modeling in SAP BW

424 Lesson: Defining Key Figures as SAP BW InfoObjects430 Lesson: Creating Translation Types for Currency Translation433 Exercise 17: Create a Currency Translation Type438 Lesson: Creating Translation Types for Quantity Conversion444 Lesson: Creating Key Figures for Non-Cumulatives451 Exercise 18: Create Key Figures for Stock Coverage462 Lesson: Creating a Data Model for Non-Cumulative Values in SAP

BW

vi © Copyright. All rights reserved.



473 Unit 10: Transactional Data Modeling in SAP BW

474 Lesson: Modeling Advanced DataStore Objects (ADSOs)493 Exercise 19: Create ADSOs for the Core EDW Layer510 Lesson: Modeling a CompositeProvider for Agile Data Mart

Scenarios521 Exercise 20: Model a CompositeProvider Based on a SAP HANA

View529 Exercise 21: Integrate an ADSO and a SAP HANA View-Based

Composite Provider537 Lesson: Implementing Tracking History Scenarios543 Exercise 22: Use Different Characteristics or Joined Attributes

for Tracking History Scenarios549 Lesson: Modeling Transformations553 Exercise 23: Copy a Transformation and Check SAP HANA

Optimization561 Exercise 24: Create an InfoSource571 Exercise 25: Perform Currency and Unit Conversion

577 Unit 11: Hybrid Modeling in Mixed Scenarios

578 Lesson: Modeling Mixed Scenarios587 Exercise 26: Generate Views Manually and Automatically594 Lesson: Enhancing Views in SAP HANA597 Exercise 27: Enhance a View

613 Unit 12: Areas of SAP BW Workspaces

614 Lesson: Modeling a SAP BW Workspace627 Exercise 28: Define a Local CompositeProvider637 Exercise 29: Report on a Local CompositeProvider

645 Unit 13: Enhanced Scenarios in SAP BW

646 Lesson: Implementing Enhanced Scenarios in SAP BW649 Exercise 30: Implement an Analytic Process

663 Unit 14: Existing Model Enhancement

664 Lesson: Convert Silos or LSAs to LSA++677 Lesson: Using the SAP BW Remodeling Toolbox679 Exercise 31: Remodel an InfoObject684 Lesson: Remodeling With an SPO in SAP BW

© Copyright. All rights reserved. vii



viii © Copyright. All rights reserved.



Course Overview

TARGET AUDIENCEThis course is intended for the following audiences:

● Technology Consultant

● Application Consultant

● Business Analyst

● Business Process Architect

● Business Process Owner/Team Lead/Power User

● Enterprise Architect

● Program/Project Manager

© Copyright. All rights reserved. ix



x © Copyright. All rights reserved.



UNIT 1 Data Modeling with SAPBusiness InformationWarehouse (SAP BW) Poweredby SAP HANA

Lesson 1

Understanding Modeling Objectives and Issues 3Exercise 1: Identify and Solve Possible Conflicts 13

Lesson 2

Understanding SAP HANA From a Modeling Perspective 18

Lesson 3

Understanding SAP BW From a Modeling Perspective 30

Lesson 4

Comparing SAP BW with SAP HANA 42

Lesson 5

Understand the Strategy for SAP BW on SAP HANA 57

UNIT OBJECTIVES

● Define SAP BW on SAP HANA modeling

● Identify modeling targets

● Prioritize modeling objectives

● Identify suboptimal models

● Understand the advantages of SAP HANA from a modeling perspective

● Understand SAP HANA terms and technical concepts

● Identify the components of a data storage strategy

● Understand the advantages of SAP BW

● Understand how SAP BW modeling relates to SAP HANA modeling

● Recommend a modeling strategy for SAP BW on SAP HANA

● Identify decision areas within SAP BW projects

© Copyright. All rights reserved. 1



● Understand the future strategy for SAP BW on SAP HANA

Unit 1: Data Modeling with SAP Business Information Warehouse (SAP BW) Powered by SAP HANA

2 © Copyright. All rights reserved.



Unit 1Lesson 1

Understanding Modeling Objectives and Issues

LESSON OBJECTIVESAfter completing this lesson, you will be able to:

● Define SAP BW on SAP HANA modeling

● Identify modeling targets

● Prioritize modeling objectives

● Identify suboptimal models

Business Scenarios and Analytic Challenges

Figure 1: Introduction to Data Modeling

Your company has decided to improve its business processes by using SAP BW powered bySAP HANA as a data warehouse solution. You are assigned to develop and implement amodeling strategy. In this unit, you learn how to order and prioritize the expectations.

Motivation: Data Quality

Business decisions are often driven by values collected from information processing systems.Therefore, a lot of reports are distributed. But where do the values come from and howreliable are they?

In large companies, it is common that different teams collect their own data, or calculate theirown values. When representatives of different teams come together in meetings to discussthe company’s strategy facts are presented to support a suggested strategy. Others maydisagree and call on the facts to support their objection. But does everybody use the samefact basis?

Imagine the decision maker asking for the total quantity of tin plate that has been delivered toa specific customer, and getting three different answers:

● The storage department reports that they sold 15 m².

● The strategy department reports that the company sold 15 KG.

● The CRM department reports that the company sold 14 KG.




Figure 2: Understanding Conflicts in Meetings

Without a central data collection strategy, each department relies on their own calculations.When every department keeps their own, independent database, based on the same originalbusiness process, these are called silos. Silos area multiple copies of the same data sourcewith different, independent steps of consolidation, harmonization, and enhancement.

Silos give rise to the following problems:

● Misunderstandings in discussions

● Difficulties with aggregation of errors

● Different beliefs about the truth and the recommended behavior

● Differences in values between different public reports





Motivation: Analytic Challenges

Figure 3: Business Scenarios and Analytic Challenges

Why do different departments get different results? The figure, Business Scenarios andAnalystic Challenges, presents an example that illustrates the following possible reasons fordifferent results

● Different database

Different source tables (for example, an aggregated source table versus a details sourcetable), different filter values, different times, or different source systems regularly lead todifferent extraction results.

● Different actuality of values

If, at an early stage, incorrect data was extracted from the source system that wascorrected later, it is important to synchronize (update) the values in the reporting system.

● Different times of extraction

Values in the source vary. New orders may be added, or status information changes. As aresult, values may differ whether they are extracted in the morning or in the evening.

● Different calculation definitions

How is a margin defined? Which costs need be distracted? Are percentage values used?

● Different steps of calculation

Is an aggregation over different products calculated before a unit conversion is calculatedon an average conversion factor? Or is the conversion executed with a product specificconversion factor before values are aggregated? Is a share (percentage value) calculatedbefore or after a unit conversion is executed?

● Different times of calculation

If conversion factors change, different conversion factors lead to different results.

Lesson: Understanding Modeling Objectives and Issues




● Lack of quality management

There is no control of the reliability of the output.

What can be done to address these problems? On the technical side, many companies decideto implement a data warehouse, like SAP BW powered by SAP HANA, with a central storage ofall enterprise information and fast information processing. However, even the best softwaresolution must be accompanied by a good data modeling strategy.

Data Modeling DirectiveWhat is a data modeling directive? A data modeling directive is a plan for what should bedone, where, when, with which data, and in what way.

Figure 4: Aspects of a Data Modeling Directive

A data modeling directive addresses the following questions on which data is involved:

● Which business processes are the focus?

● Are values needed for the entire enterprise, or for a local subsidiary?

● Which field of data management is intended? Reporting actual values, predictive analysis,or operation planning?

● To which level of detail are the values needed?

● Are current values (up to the very last second) essential? Or is a latency, that is, a delay,acceptable? Is it sufficient to process data once per day?

● Are historical values required? If so, how far back? What should be done if values change?Is it necessary to identify obsolete values?

● In calculations, are intermediate results needed also?

A data modeling directive addresses the following questions on what must be done with thedata:

● Are the values read, copied, processed, or presented?





● Are selection processes used to reduce the set of data?

● Are tables joined with other tables?

● Are values transformed and harmonized?

● Which values need to be checked, for example for referential integrity against duplicates,or for the correct data format against mathematical errors such as a sum of more than100%?

● Is a result just presented as a result on screen, or is it permanently stored?

● Is data archived, or deleted?

A data modeling directive addresses when, and how often, these processes occur, forexample:

● On demand (whenever a business user is interested in the values.)

● At a pre-defined point in time

● Periodically, for example daily or monthly

● Every time the data has changed in the source

A data modeling directive addresses the following questions on where data is read andprocessed:

● Which source systems are used as database, and which target systems are used to storevalues?

● Which tables or views contain the database?

● Are calculations executed in the database, or in the application level?

● Which database is used?

● Which SAP BW objects are needed to meet the approved requirements?

Finally, a data modeling directive addresses the following questions on how the data istreated:

● Are values from imported through flat files, a database connection, or other technologies?

● What are the join conditions?

● What are the filter conditions?

● Which calculations have to be carried out?

● How are plan values derived?

● Which currencies or units are used, and how can values be converted from one currency toanother?

● How are values aggregated?

An Example for a Modeling Directive

You need to define how key figures from the source are made available.

For example, a directive could suggest a raw hub with basic key figures as they are importedfrom the data source. Then, business users can create their own calculations and restrictionson them.





A different solution is a core hub which provides pre-defined calculated or restricted keyfigures for typical use cases. In this case, a data model must define how the new key figuresare derived.

It is also possible to provide both options.

Definition: Data Modeling for SAP BW on SAP HANA

Data Modeling Tasks for SAP BW on SAP HANA

The following are the tasks of a data modeler for a SAP BW powered by SAP HANA project:

● Define an overall reporting and data warehouse strategy.

● Choose which source systems and tables to connect.

● Determine what to do in the source system already, and what to do in the reportingsystem.

● Decide if processes are executed in the SAP HANA database, or in the SAP BW applicationlayer.

● Define properties of SAP HANA and SAP BW objects to store and process these values.

Modeling Policy TargetsModeling policy targets respond to a range of challenges including a range of userrequirements, feature requirements, value derivation requirements, and reportingrequirements.

Challenges: Different Requirements

Figure 5: Different User Requirements

When asked which data storage requirements they need, different business users listdifferent requirements. For example:

● A long-ranging history for several years

● Detailed analysis with all fields from the source

● Real-time availability of the latest changes





Without SAP BW on SAP HANA, realizing all these different requirements results in a slowreporting system.

Challenges: Feature Requirements

Figure 6: Different Feature Requirements

When asked what are the most important features of reporting, different business users pointout different wishes. For example:

● A fast, standardized enterprise report

● Complex calculations

● Flexible possibilities for individual analysis by the business user without involvement of ITtickets

It is impossible to program a tool that accommodates all of these conflicting requirements.SAP BI provides a portfolio of different reporting tools, each of which focuses on one or two ofthese needs.





Challenges: Value Derivation Requirements

Figure 7: Different Value Derivation Requirements

When asked how the values need to be transformed and updated, different business users listdifferent requirements. For example:

● Always keeping a single reliable value within the whole company

● Integrating dynamic values from volatile sources, for example, the internet, twitter, andother social networks

● Accepting individual adjustments

Not all these different requirements can be accommodated in the same report. How can thisproblem be addressed?

Policy CombinationIn some cases, it is possible to combine policies. The following are examples of howconflicting requirements can be accommodated in a combined policy:

● The pre-delivered report is a standard report with reliable truth, but business users canchange a report in a local copy. SAP provides several tools with flexible self-servicefeatures. For example, in SAP BusinessObjects Analysis for Microsoft Office, edition forMicrosoft Excel, it is possible to create individual drill-down options and calculations, andfilters for the top results, or even create highlighting for values below an individuallydefined target value. In SAP BusinessObjects Lumira, business users can change thegraphical display.

● Different options can be delivered within the same project and namespace. For example,there can be a strategic report with a long history and another report with more details forthe current year or month. Or a user can switch between two different hierarchy versionsin one report. A report can list two alternative key figures, for example quantity in KG andquantity in number of pieces.

● In some cases, it may be necessary to establish different projects with their own localreports. Use totally separate key figures, or different filter values to avoid conflicts about





the correct interpretation of values. An example is a company that has a German HRreport without information about the number of sick days per employee, and an Americanreport that orders employees by number of days on leave. Another example is where youhave one project for customer relationship management with a local report showing thenumber of recurring orders, and a sales project with another local report showing thenumber of open orders. However, a global the policy identifies that both use the number oforders, and provide a common ground with harmonized order key figures for both.

Figure 8: Combining Different Options

Target PrioritizationIn some cases, there may be strategic decisions to avoid the inclusion of certain content, orkeep it out of the project focus. Targets may need to be prioritized for one or more of thefollowing reasons

● It is impossible to satisfy both targets. For example, it is impossible to have complexalgorithms that are easy to understand at first sight.

● It is too time-consuming and expensive to produce such results, and not enough budgetfor both versions.

● There are legal or compliance barriers.

● There are global SAP BW standards. For example, if a global decision was made in favor ofshowing a standard product categorization based on the first digits of their technicalnames, other categorizations are not supported.

● It is highly confusing to end users to have different versions.

● The data sources cannot be trusted.

● Other targets have a higher priority.

If the conditions change, the targets might be re-evaluated, and later projects may be set upto accommodate the targets that were left out.





Figure 9: Target Prioritization

Suboptimal Data ModelsAn important target of a good modeling directive should be to avoid confusion about correctvalues. The main target of a good modeling directive is to represent correct andunderstandable values. Why? Even the fastest, most economic, or most flexible way of storingand retrieving values is of no use if the values are incorrect, or incomprehensible.

Figure 10: Modeling Directive Recommendations





Unit 1Exercise 1

Identify and Solve Possible Conflicts

Business Example

In your company, different departments have varying expectations of what a good data modelentails. As a project manager, decide which requirements are more relevant. Some goals mayinitially appear incompatible with one another, or may lead to contradictoryrecommendations. You need to identify potential conflicts and prioritize them.

1. List a minimum of five typical goals for a data modeling project.

2. From the goals you listed, identify two pairs of goals that may give rise to conflicts.

3. Choose one of the pairs, prioritize the conflicting goals you identified, or identify a bestpractice solution to accommodate both goals.




Unit 1Solution 1

Identify and Solve Possible Conflicts

Business Example

In your company, different departments have varying expectations of what a good data modelentails. As a project manager, decide which requirements are more relevant. Some goals mayinitially appear incompatible with one another, or may lead to contradictoryrecommendations. You need to identify potential conflicts and prioritize them.

1. List a minimum of five typical goals for a data modeling project.

a) Examples of typical goals for data modeling include:

● Adhere to legal requirements

● Adhere to global standards

● Improve consistency

● Produce correct values and calculations

● Manage access control

● Fulfill user expectations

● Implement real-time reporting

● Facilitate complete history

● Facilitate flexibility; facilitate offline support

● Facilitate extensibility

● Improve comprehensibility

● Manage costs and development effort

● Reduce reporting time or improve reporting performance

● Reduce data provisioning time or improve staging performance

● Implement local or individual adaptations

● Produce enterprise-wide results

● Process non-homogeneous raw data

● Manage responsibilities

● Reduce storage costs

2. From the goals you listed, identify two pairs of goals that may give rise to conflicts.




a) Examples of potentially conflicting goals include:

● Legal requirements and user expectations

● Access control and user expectations

● Complete history and good reporting performance

● Complete history and storage costs reduction

● Offline support and real-time reporting

● Flexibility and global standards

● Global standards and local or individual adaptations

● Enterprise-wide results and non-homogeneous raw data

● Reporting performance and staging performance

3. Choose one of the pairs, prioritize the conflicting goals you identified, or identify a bestpractice solution to accommodate both goals.a) Examples of ways to prioritize or accommodate conflicting goals include:

● Legal requirements and user expectations: Legal requirements are more importantthan user expectations. If user expectations are unsupportable or contrary to legalrequirements, decline or disregard them.

● Access control and user expectations: Access control requirements often arisesfrom compliance or legal standards. In such cases access control is more importantthan user expectations.

● Complete history and good reporting performance: A slower performance is usuallyacceptable for historical data. If not, use pre-calculation to speed up the reportingperformance.

● Complete history and storage costs reduction: To save storage costs, keep onlycurrent values in storage locations with fast access. Store older, rarely used valuesin cheaper locations, for example, a Near Line Storage (NLS) archive. Often,historical values are needed only on a less detailed level.

● Offline support and real-time reporting: Offline support might be necessary, asclose to real-time as possible. Whenever an online connection is possible, allow theuser to update results. Automatically take snapshots in short intervals.

● Flexibility and global standards: Use standard architecture like the LSA++ that isdesigned for flexibility. Start with a simple standard solution. Produce new releaseswith more flexible options when feasible, depending on time and budget.

● Global standards and local or individual adaptations: Both goals are equallyimportant. Define a global standard in a defined namespace and allow for individualchanges in another namespace. Use different tools to accommodate both goals.For example, a reporting tool for displaying the global standard and a self-servicetool for creating individual adaptations. Apply input parameters with default valuesto encourage users to use the global standard without restricting their options toadapt it.





Date post:	11-Apr-2017
Category:	Education
Upload:	sap-material-certification
View:	16 times
Download:	2 times

SAP Business Warehouse

Education