SAP BW305H Query Design and Analysis with SAP Business Warehouse Powered by SAP HANA PDF Free Download

Query Design and Analysis with SAP Business Warehouse Powered by SAP HANA

.

. PARTICIPANT HANDBOOK INSTRUCTOR-LED TRAINING

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

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 purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in http://global12.sap.com/corporate-en/legal/ Germany and other countries. Please see copyright/index.epx for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components 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 liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. 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 of business outlined in this document or any related presentation, or to develop or release any functionality mentioned 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 are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this 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 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.

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

iv

© Copyright. All rights reserved.

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 HANA

13

Lesson: Describing the Concepts of Business Intelligence (BI) and DataWarehousing on Any Database

25

Exercise 1: Log on to SAP BW and Open the Data Warehousing Workbench

28

Lesson: Outlining the Basics of SAP BW Powered by SAP HANA

38

Lesson: Setting Up SAP BW Modeling Tools in SAP HANA Studio

51

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

61

Unit 2:

62

Report Launching and Navigation in Reports Lesson: Outlining SAP BusinessObjects BI Platform

65

Exercise 3: Log on to BI Launchpad

68

Lesson: Navigating in SAP BusinessObjects Analysis, Edition for Microsoft Office

75

Exercise 4: Navigate in SAP BusinessObjects Analysis, Edition for Microsoft Office

83

Lesson: Navigating in SAP BusinessObjects Design Studio Generic Application

87

Exercise 5: Navigate in SAP BusinessObjects Design Studio Application

99

Unit 3:

100

Simple Queries Lesson: Creating Simple Queries

109 121 122

Exercise 6: Create a Simple Query Unit 4:

Key Figures in Queries Lesson: Configuring Properties of Key Figures

127 136

Exercise 7: Create a Query and Configure Key Figure Properties Lesson: Creating Restricted Key Figures

139

Exercise 8: Create a Query with Restricted Key Figures

146 151

Lesson: Creating Calculated Key Figures Exercise 9: Create a Query with Calculated Key Figures

158

Lesson: Creating Calculated Key Figures with Boolean Operators

159

Exercise 10: Create a Query with Boolean Operators

165

Lesson: Creating Calculated Key Figures with Exception Aggregation

169

© Copyright. All rights reserved.

Exercise 11: Create a Query with Exception Aggregation

v

183

Unit 5:

184

Lesson: Creating Structures

187

Exercise 12: Create a Query with Two Structures

195

Lesson: Resolving Formula Collision and Working with Cells

199 213

Structures in Queries

Exercise 13: Resolve Formula Collision and Work with Cells Unit 6:

214

Characteristics, Attributes, and Hierarchies Lesson: Configuring the Properties of Characteristics

219

Exercise 14: Create a Query and Configure Characteristic Properties

223

Lesson: Creating a Query and Running Display and Navigation Attributes

225

Exercise 15: Create a Query and Run Attributes

229

Lesson: Adding Hierarchies to Reports

233

Exercise 16: Create a Query and Include an External Hierarchy

237

Exercise 17: Create a Query and Compare Options for Hierarchical Display

247

Unit 7:

Variables in Queries

248

Lesson: Explaining Variables

256 259

Lesson: Creating Characteristic Value and Text Variables Exercise 18: Create a Query with Characteristic Value Variables

268

Lesson: Applying Business Content Variables

and Text Variables 271

Exercise 19: Create a Query with Business Content Variables and Variable Offset

276

Lesson: Creating Characteristic Value Variables with a Replacement

279

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

286

Lesson: Creating Formula Variables

Them 287

Exercise 21: Create a Query with Formula Variables

295

Lesson: Creating Hierarchy Variables and Hierarchy Node Variables

297

Exercise 22: Create a Query with Hierarchy Variables and Hierarchy Node Variables

311 312

vi

Unit 8:

Exceptions and Conditions in Queries Lesson: Creating a Query and Including Exceptions

319

Exercise 23: Create a Query and Include Exceptions

326 333

Lesson: Creating a Query and Including Conditions Exercise 24: Create a Query and Include Conditions

© Copyright. All rights reserved.

345

Unit 9:

346

Report-Report Interface Lesson: Applying the Report-Report Interface

351 363

Exercise 25: Apply the Report-Report Interface Unit 10:

Query Performance Optimization

364

Lesson: Optimizing Query Performance

367

Lesson: Applying Performance Monitoring Tools

369

Lesson: Configuring Query Read Mode

371 377

Lesson: Describing the HANA-Optimized Analytic Manager Exercise 26: Configure the Analytic Manager

389

Unit 11:

390 399

Lesson: Managing Query Objects Unit 12:

400 409 410

Query Management

Authorizations Overview Lesson: Describing Authorizations

Unit 13:

Business Intelligence (BI) Products Consuming Queries Lesson: Describing Business Intelligence Products Consuming Queries

© Copyright. All rights reserved.

vii

viii

© Copyright. All rights reserved.

Course Overview TARGET AUDIENCE This 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

x

© Copyright. All rights reserved.

UNIT 1

Introduction to SAP HANA and SAP 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

13

Exercise 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

38

Exercise 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 1 Lesson 1 Describing the Evolution and Data Layout of SAP HANA

LESSON OVERVIEW After 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 OBJECTIVES After completing this lesson, you will be able to: ●

Describe the evolution and data layout of SAP HANA

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 in response to structured queries. With HANA, this is done by accessing main memory, rather than disk, yielding much faster data retrieval times. However, complex applications that need big data volumes could still spend only a small percentage of their total runtime on data retrieval, with much more time spent in processing the data. To support this, complex handling routines need to be implemented, which can deal with these data volumes. In the pre-HANA world of three-tier architecture (data, application, and

2

© Copyright. All rights reserved.

Lesson: Describing the Evolution and Data Layout of SAP HANA

presentation layers), applications first read data from a database, then process them in their memory 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 now necessary 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 have many computing cores, providing impressive performance. Therefore, it is obviously best not to 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 processes from the application layer to the data layer and perform them there. SAP now delivers inmemory applications that were recently impossible, due to performance limitations on prior database and hardware combinations. 1990

2010

Improvement (2016)

CPU

0.05 MIPS/$

7.15 MIPS/$

143x

Memory

0.02 MB/$

5 MB/$

250x

Addressable memory

2 16

2 64

2 48 x

Network speed

100 Mbps

10 Gbps

100x

Disk data transfer

5 MBPS

130 MBPS

25x

© Copyright. All rights reserved.

3

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

SAP HANA Architecture

Figure 3: SAP HANA Architecture

SAP HANA is a database that is embedded into a complete platform, which builds around this database. Features include a Web application server (XS-Engine), components to manage planning, OLAP analytics, predictive cases (planning engine, analytic engine, and predictive engine), 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 (8 bytes) simultaneously during a cycle. This includes the external and internal design of data and address bus, the width of the register set with one. Furthermore, the instruction set is usually designed consistently on 64 bit, unless a backward-compatible legacy (see X86 architecture) is present. This applies in a similar way to the standard addressing modes. The

4

© Copyright. All rights reserved.

Lesson: Describing the Evolution and Data Layout of SAP HANA

bit width of the arithmetic logic unit, in principle, may differ from the address of the unit (as with most 64-bit CPUs). In order to provide more acceleration in data processing, manufacturers have come up with different acceleration techniques. These range from the reduction of write operations on the outer 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. These techniques have one thing in common: In essence, they assume that data is stored on the hard drives, and they are trying to speed up access. Memory is now available not only in much larger capacities than before, it is now also affordable. Thanks to modern 64-bit operating systems, it is usable. The 32-bit address space is limited to 4 GB of memory, while a 64-bit address 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 power to process this data. To address this, in recent years there has been a change from complex CPUs to multi-core processor units. For this innovative computing power, software has to be written in a new, specific way: HANA software has the job of splitting the overall task into many 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 can be 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, and extremely fast communication between processor cores enables parallel processing. Main memory is no longer a limited resource. Modern servers can have several terabytes of system memory, and this allows complete databases to be held in RAM. Currently, server processors have up to 64 cores and 128-core processors will soon be available. With the increasing number of cores, CPUs are able to process much more data per time interval. This shifts the performance bottleneck from disk I/O to the data transfer between CPU cache and main memory.

© Copyright. All rights reserved.

5

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

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 columnwise (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 in rows and columns. Computer memory, however, is organized as a linear sequence. For storing a table in linear memory, two options can be chosen. A row store stores a sequence of records that contains the fields of one row in the table. In a column store, the entries of a column are stored in contiguous memory locations. In addition to a classical row-based data store, SAP HANA can store tables in its columnbased 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 first version 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 in online transaction processing (OLTP) applications requires a balanced approach to insertion and indexing of column data, in order to minimize cache misses. The SAP HANA database allows the developer to specify whether a table is stored column-wise or row-wise. It is also possible to alter an existing column-based table to a row-based one, and vice versa.

6

© Copyright. All rights reserved.

Lesson: Describing the Evolution and Data Layout of SAP HANA

Columnar Data Layout

Figure 7: Columnar Data Layout

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

●

A row-based approach stores a table as a sequence of records, each of which contain the fields of one row. In a column-based table, the entries of a column are stored in contiguous memory locations.

CPU Workload: Row Versus Column Store

Figure 8: CPU Workload

© Copyright. All rights reserved.

7

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

Let’s say we wish to aggregate the sum of all sales amounts using a row-based table. Data transfer from the main memory into the CPU cache always occurs in blocks of a fixed size called cache lines (for example, 64 bytes). With row-based data organization, it may happen that each cache line contains only one “sales” value (stored using 4 bytes), while the remaining bytes are used for the other fields of the data record. For each value needed for the aggregation, new access to the main memory is required. This shows that, with row-based data organization, the operation is slowed down by cache misses that cause the CPU to wait until the required data is available. With column-based storage, all sales values are stored in contiguous memory, so the cache line contains 16 values that are all needed for the operation. The fact that columns are stored in contiguous memory allows memory controllers to use data prefetching to further minimize the number of cache misses. Compression of Column Store Tables

Figure 9: Compression of Column Store Tables

Aside from performance benefits, data management in column stores offers much potential to leverage state-of-the-art data compression concepts. For example, SAP HANA works with bit-encoded values and compresses repeated values, which results in fewer memory requirements compared to a classical row store table. The column store allows for the efficient data compression. This makes it less costly for the SAP HANA database to keep data in main memory. It also speeds up searches and calculations. 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 of distinct column values to consecutive numbers, so that instead of the actual value being stored, the consecutive number is stored, which is typically much smaller.

●

8

Advanced compression

© Copyright. All rights reserved.

Lesson: Describing the Evolution and Data Layout of SAP HANA

Each column can be further compressed using different compression methods, namely prefix encoding, run-length encoding (RLE), cluster encoding, sparse encoding, and indirect encoding. The SAP HANA database uses compression algorithms to determine the 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 suitable because reconstructing the complete row is one of the most expensive operations for a column-based table.

●

Column store If you want to store huge amounts of data that should be aggregated and analyzed in a table, 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, there are ranges of the same values in contiguous memory, so compression methods such as run length 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 or aggregations, can be implemented as loops over an array stored in contiguous memory locations. 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 increases speed. 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

© Copyright. All rights reserved.

9

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

each column. The column-scanning speed of the in-memory column store and the compression mechanisms (especially dictionary compression) already allow read operations with very high performance. In many cases, it is not required to have additional index structures. Eliminating indexes reduces 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 is possible to create additional indexes, if required. In addition, full-text indexes are used to support full-text search. Elimination of materialized aggregates Thanks to its column-scanning speed, the column store makes it possible to calculate aggregates on large amounts of data on the fly with high performance. This eliminates the need for materialized aggregates in many cases. Eliminating materialized aggregates has several advantages. It simplifies data model and aggregation logic, which makes development and maintenance more efficient; it allows for a higher level of concurrency, because write operations do not require exclusive locks for updating aggregated values; and it ensures that the aggregated values are always up to date (materialized aggregates are sometimes updated only at scheduled times). Parallelization Column-based storage simplifies parallel execution using multiple processor cores. In a column store, data is already vertically partitioned. That means operations on different columns 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:

10

© Copyright. All rights reserved.

Lesson: Describing the Evolution and Data Layout of SAP HANA

●

● ●

When a SAP system is migrated to SAP HANA, the SAP tables are automatically migrated into 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 in the 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 relevant application data in memory. Write operations on this compressed data would be costly, as they would require reorganizing the storage structure. Updating and inserting data into a sorted column store table is a costly activity, as the sort order has to be regenerated, and the whole table is reorganized each time. SAP has tackled this challenge by separating these tables into a main storage (readoptimized, sorted columns) and delta storages (write-optimized, non-sorted columns or rows). All changes go into a separate area called the delta storage. The delta storage exists only in main memory. Only delta log entries are written to the persistence layer when delta entries are inserted. There is a regular database activity that merges the delta storage into the main storage. This activity is called delta merge. The figure shows the different levels of data storage, and distinguishes the main storage from the delta storage.

© Copyright. All rights reserved.

11

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

Figure 13: SAP HANA: Insert Only on Delta

LESSON SUMMARY You should now be able to: ●

12

Describe the evolution and data layout of SAP HANA

© Copyright. All rights reserved.

Unit 1 Lesson 2 Describing the Concepts of Business Intelligence (BI) and DataWarehousing on Any Database

LESSON OVERVIEW In 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 OBJECTIVES After completing this lesson, you will be able to: ●

Describe BI and data warehousing on any database

Data Warehousing The goal behind the implementation of classic data processing systems has been, primarily, the acceleration, cost reduction, and automation of processes in individual business areas. In most companies, this is now achieved by Enterprise Resource Planning (ERP) systems and other software tools. The result is that these ERP systems, CRM systems, banking and credit card systems, and corporate governance regulations have exponentially increased the data volumes that require analysis. Some consider this a negative; others, like SAP, think that this enormous amount of electronic information offers major benefits. In parallel, ever-increasing globalization, and the increasing decentralization of organizations has created the need to recognize market trends and to collect information about competitors. This allows the company to react quickly to changes in market conditions. In this Internet age, efficient information processing is important to maintain an advantage over competitors. Due to continuous innovation in data processing, more and more information is stored in a more detailed format. As a result, there is a need both to reduce and structure this data, so it can be analyzed meaningfully. The analysis necessary to create business intelligence from the collected raw data requires a varied tool set. Decision-makers in modern, globally operating enterprises frequently realize that their survival depends on the effective use of this information. Unfortunately, this information is often spread across many systems, and sometimes many countries, making effective use of it very difficult. This is precisely the challenge that modern business intelligence systems attempt to meet. Extensive solutions are required to cover the entire process, from the retrieval of source data to its analysis. Enterprises must be concerned with metadata (business and technical attributes and descriptions of objects) across the enterprise. In

© Copyright. All rights reserved.

13