SAP BW305H 7.5

Query Design and Analysis withSAP Business Warehouse Poweredby SAP HANA

..

PARTICIPANT HANDBOOKINSTRUCTOR-LED TRAINING

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

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


SAP Copyrights and Trademarks

© 2016 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 purposewithout the express permission of SAP SE or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well as their respectivelogos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) inGermany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.

Some software products marketed by SAP SE and its distributors contain proprietarysoftware components of other software vendors.

National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informationalpurposes only, without representation or warranty of any kind, and SAP SE or its affiliatedcompanies shall not be liable for errors or omissions with respect to the materials. The onlywarranties for SAP SE or SAP affiliate company products and services are those that areset forth in the express warranty statements accompanying such products and services, ifany. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course ofbusiness outlined in this document or any related presentation, or to develop or release anyfunctionality mentioned therein. This document, or any related presentation, and SAP SE’sor its affiliated companies’ strategy and possible future developments, products, and/orplatform directions and functionality are all subject to change and may be changed by SAPSE or its affiliated companies at any time for any reason without notice. The information inthis document is not a commitment, promise, or legal obligation to deliver any material,code, or functionality. All forward-looking statements are subject to various risks anduncertainties that could cause actual results to differ materially from expectations. Readersare cautioned not to place undue reliance on these forward-looking statements, whichspeak only as of their dates, and they should not be relied upon in making purchasingdecisions.



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

© Copyright. All rights reserved. iii



Contents

ix Course Overview

1 Unit 1: Introduction to SAP HANA and SAP Business Warehouse (BW)

2 Lesson: Describing the Evolution and Data Layout of SAP HANA13 Lesson: Describing the Concepts of Business Intelligence (BI) and

DataWarehousing on Any Database25 Exercise 1: Log on to SAP BW and Open the Data Warehousing

Workbench28 Lesson: Outlining the Basics of SAP BW Powered by SAP HANA38 Lesson: Setting Up SAP BW Modeling Tools in SAP HANA Studio51 Exercise 2: Set Up BW Modeling Tools in SAP HANA Studio

61 Unit 2: Report Launching and Navigation in Reports

62 Lesson: Outlining SAP BusinessObjects BI Platform65 Exercise 3: Log on to BI Launchpad68 Lesson: Navigating in SAP BusinessObjects Analysis, Edition for

Microsoft Office75 Exercise 4: Navigate in SAP BusinessObjects Analysis, Edition

for Microsoft Office83 Lesson: Navigating in SAP BusinessObjects Design Studio Generic

Application87 Exercise 5: Navigate in SAP BusinessObjects Design Studio

Application

99 Unit 3: Simple Queries

100 Lesson: Creating Simple Queries109 Exercise 6: Create a Simple Query

121 Unit 4: Key Figures in Queries

122 Lesson: Configuring Properties of Key Figures127 Exercise 7: Create a Query and Configure Key Figure Properties136 Lesson: Creating Restricted Key Figures139 Exercise 8: Create a Query with Restricted Key Figures146 Lesson: Creating Calculated Key Figures151 Exercise 9: Create a Query with Calculated Key Figures158 Lesson: Creating Calculated Key Figures with Boolean Operators159 Exercise 10: Create a Query with Boolean Operators165 Lesson: Creating Calculated Key Figures with Exception

Aggregation169 Exercise 11: Create a Query with Exception Aggregation

© Copyright. All rights reserved. v



183 Unit 5: Structures in Queries

184 Lesson: Creating Structures187 Exercise 12: Create a Query with Two Structures195 Lesson: Resolving Formula Collision and Working with Cells199 Exercise 13: Resolve Formula Collision and Work with Cells

213 Unit 6: Characteristics, Attributes, and Hierarchies

214 Lesson: Configuring the Properties of Characteristics219 Exercise 14: Create a Query and Configure Characteristic

Properties223 Lesson: Creating a Query and Running Display and Navigation

Attributes225 Exercise 15: Create a Query and Run Attributes229 Lesson: Adding Hierarchies to Reports233 Exercise 16: Create a Query and Include an External Hierarchy237 Exercise 17: Create a Query and Compare Options for

Hierarchical Display

247 Unit 7: Variables in Queries

248 Lesson: Explaining Variables256 Lesson: Creating Characteristic Value and Text Variables259 Exercise 18: Create a Query with Characteristic Value Variables

and Text Variables268 Lesson: Applying Business Content Variables271 Exercise 19: Create a Query with Business Content Variables

and Variable Offset276 Lesson: Creating Characteristic Value Variables with a Replacement

Path from a Query279 Exercise 20: Create Two Queries and Transfer Values Between

Them286 Lesson: Creating Formula Variables287 Exercise 21: Create a Query with Formula Variables295 Lesson: Creating Hierarchy Variables and Hierarchy Node Variables297 Exercise 22: Create a Query with Hierarchy Variables and

Hierarchy Node Variables

311 Unit 8: Exceptions and Conditions in Queries

312 Lesson: Creating a Query and Including Exceptions319 Exercise 23: Create a Query and Include Exceptions326 Lesson: Creating a Query and Including Conditions333 Exercise 24: Create a Query and Include Conditions

vi © Copyright. All rights reserved.



345 Unit 9: Report-Report Interface

346 Lesson: Applying the Report-Report Interface351 Exercise 25: Apply the Report-Report Interface

363 Unit 10: Query Performance Optimization

364 Lesson: Optimizing Query Performance367 Lesson: Applying Performance Monitoring Tools369 Lesson: Configuring Query Read Mode371 Lesson: Describing the HANA-Optimized Analytic Manager377 Exercise 26: Configure the Analytic Manager

389 Unit 11: Query Management

390 Lesson: Managing Query Objects

399 Unit 12: Authorizations Overview

400 Lesson: Describing Authorizations

409 Unit 13: Business Intelligence (BI) Products Consuming Queries

410 Lesson: Describing Business Intelligence Products ConsumingQueries

© Copyright. All rights reserved. vii



Course Overview

TARGET AUDIENCEThis course is intended for the following audiences:

● Application Consultant

● Business Analyst

● Business Process Owner/Team Lead/Power User

● Data Consultant/Manager

● Program/Project Manager

● Technology Consultant

● User

© Copyright. All rights reserved. ix



UNIT 1 Introduction to SAP HANA andSAP Business Warehouse (BW)

Lesson 1

Describing the Evolution and Data Layout of SAP HANA 2

Lesson 2

Describing the Concepts of Business Intelligence (BI) and DataWarehousing on Any Database 13Exercise 1: Log on to SAP BW and Open the Data Warehousing Workbench 25

Lesson 3

Outlining the Basics of SAP BW Powered by SAP HANA 28

Lesson 4

Setting Up SAP BW Modeling Tools in SAP HANA Studio 38Exercise 2: Set Up BW Modeling Tools in SAP HANA Studio 51

UNIT OBJECTIVES

● Describe the evolution and data layout of SAP HANA

● Describe BI and data warehousing on any database

● Explain the basics of SAP BW powered by SAP HANA

● Set up BW modeling tools in SAP HANA Studio

© Copyright. All rights reserved. 1



Unit 1Lesson 1

Describing the Evolution and Data Layout ofSAP HANA

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

● Summarize advantages of SAP HANA

● Describe the evolution of SAP HANA

● Explain the data layout of an insert only columnar in-memory database

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


Introduction to SAP HANA

Figure 1: SAP BW and SAP Business Suite on SAP HANA

SAP software can run on the SAP HANA database, as well as other databases.

One traditional aspect of the HANA database is the ability to store data and retrieve it inresponse to structured queries. With HANA, this is done by accessing main memory, ratherthan disk, yielding much faster data retrieval times. However, complex applications that needbig data volumes could still spend only a small percentage of their total runtime on dataretrieval, with much more time spent in processing the data.

To support this, complex handling routines need to be implemented, which can deal withthese data volumes. In the pre-HANA world of three-tier architecture (data, application, and

2 © Copyright. All rights reserved.



presentation layers), applications first read data from a database, then process them in theirmemory and write results back to the database or provide it to the presentation layer.

Given the immense amount of data that is produced by current business software, sensors,and social networks, this concept is becoming increasingly problematic. Additionally, it is nownecessary to evaluate the volume of data very quickly and deliver results on mobile platforms.This ensures the old paradigm is no longer viable.

The Challenge of Diverse Applications

Figure 2: The Challenge of Diverse Applications

In-memory techniques have all the data in memory, and modern computer systems havemany computing cores, providing impressive performance. Therefore, it is obviously best notto move the data, but the instructions, that is, to have a complex process in the memory,rather than moving data to the application server for execution.

Through in-memory computing, SAP offers an approach to transfer data-intensive processesfrom the application layer to the data layer and perform them there. SAP now delivers in-memory applications that were recently impossible, due to performance limitations on priordatabase and hardware combinations.

1990 2010 Improvement (2016)

CPU 0.05 MIPS/$ 7.15 MIPS/$ 143x

Memory 0.02 MB/$ 5 MB/$ 250x

Addressable memory 216 264 248 x

Network speed 100 Mbps 10 Gbps 100x

Disk data transfer 5 MBPS 130 MBPS 25x

Lesson: Describing the Evolution and Data Layout of SAP HANA




SAP HANA Architecture

Figure 3: SAP HANA Architecture

SAP HANA is a database that is embedded into a complete platform, which builds around thisdatabase. Features include a Web application server (XS-Engine), components to manageplanning, OLAP analytics, predictive cases (planning engine, analytic engine, and predictiveengine), and more. The scope of this platform is enhanced continuously.

Technology Innovations as the Basis for SAP HANA

Figure 4: Technology Innovations as the Basis for SAP HANA

The design of 64-bit processors is such that their arithmetic logic unit can process 64 bits (8bytes) simultaneously during a cycle. This includes the external and internal design of dataand address bus, the width of the register set with one. Furthermore, the instruction set isusually designed consistently on 64 bit, unless a backward-compatible legacy (see X86architecture) is present. This applies in a similar way to the standard addressing modes. The

Unit 1: Introduction to SAP HANA and SAP Business Warehouse (BW)




bit width of the arithmetic logic unit, in principle, may differ from the address of the unit (aswith most 64-bit CPUs).

In order to provide more acceleration in data processing, manufacturers have come up withdifferent acceleration techniques. These range from the reduction of write operations on theouter tracks of the disk sectors on the preprocessing of the data in or on the hard drive itself,to large caches that are designed to reduce the actual number of hits on hard drives. Thesetechniques have one thing in common: In essence, they assume that data is stored on thehard drives, and they are trying to speed up access. Memory is now available not only in muchlarger capacities than before, it is now also affordable. Thanks to modern 64-bit operatingsystems, it is usable. The 32-bit address space is limited to 4 GB of memory, while a 64-bitaddress space can use so much memory that it does not fit into a server.

However, all data in the main memory would be useless if the CPU did not have enough powerto process this data. To address this, in recent years there has been a change from complexCPUs to multi-core processor units. For this innovative computing power, software has to bewritten in a new, specific way: HANA software has the job of splitting the overall task intomany small process strands (threads), which can utilize the large number of parallel cores.Optimal processing of the data is also necessary to provide optimized data structures.

With column-based storage, data is only partially blocked. Therefore, individual columns canbe processed at the same time by different cores.

Changes in Architecture

Figure 5: Changing Architectures

Computer architecture has changed in recent years. Multi-core CPUs are now standard, andextremely fast communication between processor cores enables parallel processing. Mainmemory is no longer a limited resource. Modern servers can have several terabytes of systemmemory, and this allows complete databases to be held in RAM. Currently, server processorshave up to 64 cores and 128-core processors will soon be available. With the increasingnumber of cores, CPUs are able to process much more data per time interval. This shifts theperformance bottleneck from disk I/O to the data transfer between CPU cache and mainmemory.





The main aspects of the SAP HANA database are as follows:

● Column store

● Compression

● Partitioning and parallelization

● Insert only on delta

Column and Row Store Tables

Figure 6: Row Data Layout

The SAP HANA database supports two types of table: those that store data either column-wise (column tables) or row-wise (row tables). SAP HANA is optimized for column storage.

Conceptually, a database table is a two-dimensional data structure with cells organized inrows and columns. Computer memory, however, is organized as a linear sequence. Forstoring a table in linear memory, two options can be chosen. A row store stores a sequence ofrecords that contains the fields of one row in the table. In a column store, the entries of acolumn are stored in contiguous memory locations.

In addition to a classical row-based data store, SAP HANA can store tables in its column-based data store. It is important to understand the differences between these two methods,and why column-based storage can highly increase certain types of data processing.

The concept of column data storage has been used for quite some time. For example, the firstversion of SAP Sybase IQ, a column-based relational database, was released in 1999.Historically, column-based storage was mainly used for analytics and data warehousing,where aggregate functions play an important role. On the other hand, using column stores inonline transaction processing (OLTP) applications requires a balanced approach to insertionand indexing of column data, in order to minimize cache misses. The SAP HANA databaseallows the developer to specify whether a table is stored column-wise or row-wise. It is alsopossible to alter an existing column-based table to a row-based one, and vice versa.





Columnar Data Layout

Figure 7: Columnar Data Layout

Conceptually, a database table is a two-dimensional data structure with cells organized inrows and columns. Computer memory, however, is organized as a linear structure. To store atable in linear memory, two options exist:

● A row-based approach stores a table as a sequence of records, each of which contain thefields of one row.

● In a column-based table, the entries of a column are stored in contiguous memorylocations.

CPU Workload: Row Versus Column Store

Figure 8: CPU Workload





Let’s say we wish to aggregate the sum of all sales amounts using a row-based table. Datatransfer from the main memory into the CPU cache always occurs in blocks of a fixed sizecalled cache lines (for example, 64 bytes). With row-based data organization, it may happenthat each cache line contains only one “sales” value (stored using 4 bytes), while theremaining bytes are used for the other fields of the data record. For each value needed for theaggregation, new access to the main memory is required.

This shows that, with row-based data organization, the operation is slowed down by cachemisses that cause the CPU to wait until the required data is available. With column-basedstorage, all sales values are stored in contiguous memory, so the cache line contains 16values that are all needed for the operation. The fact that columns are stored in contiguousmemory allows memory controllers to use data prefetching to further minimize the number ofcache misses.

Compression of Column Store Tables

Figure 9: Compression of Column Store Tables

Aside from performance benefits, data management in column stores offers much potentialto leverage state-of-the-art data compression concepts. For example, SAP HANA works withbit-encoded values and compresses repeated values, which results in fewer memoryrequirements compared to a classical row store table.

The column store allows for the efficient data compression. This makes it less costly for theSAP HANA database to keep data in main memory. It also speeds up searches andcalculations.

Data in column tables can have a two-fold compression, as follows:

● Dictionary compression

This default method of compression is applied to all columns. It involves the mapping ofdistinct column values to consecutive numbers, so that instead of the actual value beingstored, the consecutive number is stored, which is typically much smaller.

● Advanced compression





Each column can be further compressed using different compression methods, namelyprefix encoding, run-length encoding (RLE), cluster encoding, sparse encoding, andindirect encoding. The SAP HANA database uses compression algorithms to determinethe type of compression that is most appropriate for a column.

Row Versus Column Stores

Figure 10: Row Versus Column-Based Stores

Row stores and column stores are each suitable for use in different scenarios, as follows:

● Row store

If you want to report on all the columns of a table, then the row store is more suitablebecause reconstructing the complete row is one of the most expensive operations for acolumn-based table.

● Column store

If you want to store huge amounts of data that should be aggregated and analyzed in atable, column-based storage is more suitable.

Column tables have several advantages, as follows:

Higher data compression rates

Columnar data storage allows for highly efficient compression. If the column is sorted, thereare ranges of the same values in contiguous memory, so compression methods such as runlength encoding or cluster encoding can be used more effectively.

Higher performance for column operations

With columnar data organization, operations on single columns, such as searching oraggregations, can be implemented as loops over an array stored in contiguous memorylocations. Such an operation has high spatial locality and efficiently utilizes the CPU caches.

In addition, highly efficient data compression not only saves memory but also increasesspeed.

Elimination of additional indexes

In many cases, columnar data storage eliminates the need for additional index structures,because storing data in columns already works in a similar way as having a built-in index for





each column. The column-scanning speed of the in-memory column store and thecompression mechanisms (especially dictionary compression) already allow read operationswith very high performance.

In many cases, it is not required to have additional index structures. Eliminating indexesreduces memory size, can improve write performance, and reduces development efforts.However, indexes are still used in SAP HANA. Primary key fields always have an index and it ispossible to create additional indexes, if required. In addition, full-text indexes are used tosupport full-text search.

Elimination of materialized aggregates

Thanks to its column-scanning speed, the column store makes it possible to calculateaggregates on large amounts of data on the fly with high performance. This eliminates theneed for materialized aggregates in many cases. Eliminating materialized aggregates hasseveral advantages. It simplifies data model and aggregation logic, which makes developmentand maintenance more efficient; it allows for a higher level of concurrency, because writeoperations do not require exclusive locks for updating aggregated values; and it ensures thatthe aggregated values are always up to date (materialized aggregates are sometimes updatedonly at scheduled times).

Parallelization

Column-based storage simplifies parallel execution using multiple processor cores. In acolumn store, data is already vertically partitioned. That means operations on differentcolumns can easily be processed in parallel.

Column and Row Store Tables in SAP

Figure 11: Column and Row Store Tables in SAP

Column and row store tables in SAP function as follows:





● When a SAP system is migrated to SAP HANA, the SAP tables are automatically migratedinto the most suitable storage type. This logic is defined by SAP.

● The majority of tables are held in the column store.

● This information can be accessed in SAP HANA Studio ( Catalog → Open Definition or inthe technical settings of each table in the SAP dictionary (transaction SE13).

Partitioning Data for Faster Processing of Data in Parallel

Figure 12: Partitioning Data for Faster Processing of Data in Parallel

The figure illustrates the partitioning of data for faster processing of data in parallel.

SAP HANA: Insert Only on Delta

The column store uses efficient compression algorithms that help to keep all relevantapplication data in memory. Write operations on this compressed data would be costly, asthey would require reorganizing the storage structure. Updating and inserting data into asorted column store table is a costly activity, as the sort order has to be regenerated, and thewhole table is reorganized each time.

SAP has tackled this challenge by separating these tables into a main storage (read-optimized, sorted columns) and delta storages (write-optimized, non-sorted columns orrows). All changes go into a separate area called the delta storage. The delta storage existsonly in main memory. Only delta log entries are written to the persistence layer when deltaentries are inserted. There is a regular database activity that merges the delta storage into themain storage. This activity is called delta merge. The figure shows the different levels of datastorage, and distinguishes the main storage from the delta storage.





Figure 13: SAP HANA: Insert Only on Delta

LESSON SUMMARYYou should now be able to:






Unit 1Lesson 2

Describing the Concepts of BusinessIntelligence (BI) and DataWarehousing on AnyDatabase

LESSON OVERVIEWIn this lesson, you learn about the following topics:

● The concept of data warehousing

● SAP Business Information Warehouse (SAP BW) server and its functions

● The Data Warehousing Workbench and its uses for SAP BW administrators

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

● Describe BI and data warehousing on any database

Data WarehousingThe goal behind the implementation of classic data processing systems has been, primarily,the acceleration, cost reduction, and automation of processes in individual business areas. Inmost companies, this is now achieved by Enterprise Resource Planning (ERP) systems andother software tools. The result is that these ERP systems, CRM systems, banking and creditcard systems, and corporate governance regulations have exponentially increased the datavolumes that require analysis. Some consider this a negative; others, like SAP, think that thisenormous amount of electronic information offers major benefits.

In parallel, ever-increasing globalization, and the increasing decentralization of organizationshas created the need to recognize market trends and to collect information aboutcompetitors. This allows the company to react quickly to changes in market conditions. In thisInternet age, efficient information processing is important to maintain an advantage overcompetitors.

Due to continuous innovation in data processing, more and more information is stored in amore detailed format. As a result, there is a need both to reduce and structure this data, so itcan be analyzed meaningfully. The analysis necessary to create business intelligence from thecollected raw data requires a varied tool set.

Decision-makers in modern, globally operating enterprises frequently realize that theirsurvival depends on the effective use of this information. Unfortunately, this information isoften spread across many systems, and sometimes many countries, making effective use of itvery difficult. This is precisely the challenge that modern business intelligence systemsattempt to meet. Extensive solutions are required to cover the entire process, from theretrieval of source data to its analysis. Enterprises must be concerned with metadata(business and technical attributes and descriptions of objects) across the enterprise. In




SAP BW305H 7.5

Education

Transcript of SAP BW305H 7.5