Administration & Operations

BW310HData Warehousing with SAP Business Warehouse powered by SAP HANA

PARTIC IPANT HANDBOOKINSTRUCTOR-LED TRAINING

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

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

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 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 Germany and other countries. Please see http://globall2.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 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.



http://globall2.sap.com/corporate-en/legal/

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

Window title

A

O»

Example text

Example text

© Copyright. All rights reserved.



0

IV © Copyright. All rights reserved.



Contents

ix Course Overview

1 U n itl: Introduction to SAP HANA

2 Lesson: Describing the Evolution and the Data Layout of SAP HANA

13 Lesson: Describing the Concepts of Business Intelligence (Bl) and

Data Warehousing on Any Database

20 Lesson: Outlining the basics of SAP Business Warehouse powered

by SAP HANA

35 Exercise 1: Use the Data Warehousing Workbench

45 Unit 2: Master Data in SAP Business Warehouse powered by SAP HANA

46 Lesson: Describing Characteristic InfoObjects

61 Exercise 2: Create an InfoObject Characteristic

67 Exercise 3: Create a Global Transfer Routine

71 Lesson: Creating a generic DataSource

81 Exercise 4: Create a Generic DataSource

89 Lesson: Creating Transformation and Data Transfer Process (DTP)

for attribute master data loading

95 Exercise 5: Create Transformation and DTP for Attribute Master

Data

103 Lesson: Outlining the Difference Between Classic and Graphical

Data Flow Modeling

109 Exercise 6: Create a Graphical Data Flow

115 Exercise 7: Load Text Master Data Using the Graphical Data

Flow

126 Lesson: Deleting and Activating Master Data

129 Exercise 8: Reload and Activate Changed Master Data

© Copyright. All rights reserved. v



137 Unit 3: Transactional Data in SAP Business Warehouse (SAP BW)

139

145

153

155

160

168

179

185

193

204

217

229

241

246

255

263

264

272

293

304

309

317

318

331

339

347

Lesson: Exploring the SAP HANA Studio

Exercise 9: Explore SAP HANA Modeler

Lesson: Creating a key figure InfoObject

Exercise 10: Create a Key Figure in the Data Warehousing

Workbench

Lesson: Introducing SAP Business Warehouse (SAP BW)

InfoProvider

Lesson: Modeling DataStore Objects (Advanced)

Exercise 11: Create a DataStore Object (Advanced) (InfoCube-

like)

Lesson: Creating a Data Flow for Transaction Data

Exercise 12: Load Transaction Data into a DataStore Object

(Advanced)

Lesson: Creating a DataStore Object (Advanced) (classic DSO-like)

and Loading Data from a Flatfile DataSource

Exercise 13: Create a DataStore Object (Advanced) (Classic

DSO-like)

Exercise 14: Load Data from Flatfile DataSource into the

DataStore Object (Advanced)

Exercise 15: Overwrite Plan Data in an DataStore Object

(Advanced) (DSO-like)

Lesson: Modeling CompositeProviders

Exercise 16: Create a CompositeProvider

Unit 4: HANA Native Modeling

Lesson: Outlining Data Provisioning in SAP HANA

Lesson: Introducing SAP HANA native modeling

Exercise 17: Create Calculation Views Using SAP HANA

Modeling

Lesson: Combining SAP Business Warehouse (SAP BW)

InfoProvider with SAP HANA Views

Exercise 18: Enhance CompositeProvider with SAP HANA View

Unit 5: Open ODS Views

Lesson: Creating Open ODS Views

Exercise 19: Create Open ODS Views

Lesson: Creating DataSources from Open ODS View

Exercise 20: Create DataSources from Open ODS View




353 Unit 6: Advanced SAP Business Warehouse (SAP BW) Topics

355

381

393

402

407

415

420

443

450

457

463

469

Lesson: Explaining the details of data transformation and data

transfer process (DTP) in SAP Business Warehouse (SAP BW)

Exercise 21: Create Transformations and Load Attribute and

Text Master Data with DTP

Exercise 22: Create Transformations and Load Transaction

Data with DTP

Lesson: Explaining InfoObjects Enhancements for SAP Business

Warehouse powered by SAP HANA

Lesson: Administrating DataStore object (advanced)

Exercise 23: Delete and Compress Requests of a DataStore

Object (Advanced)

Lesson: Introducing Process Chains

Exercise 24: Create a Simple Process Chain

Lesson: Explaining SAP HANA Delta Merge in SAP Business

Warehouse (SAP BW)

Exercise 25: Perform an SAP HANA Delta Merge in SAP BW

Lesson: Introducing Business Intelligence (Bl) Content

Lesson: Introducing S4/HANA

vii

0




Course Overview

TARGET AUDIENCE

This course is intended for the following audiences:

• Application Consultant

• Business Analyst

• Business Process Owner/Team Lead/Power User

• Program/Project Manager

• Technology Consultant

• User

© Copyright. All rights reserved. IX



Lesson 1

Describing the Evolution and the Data Layout of SAP HANA 2

Lesson 2

Describing the Concepts of Business Intelligence (Bl) and Data Warehousing on Any Database 13

Lesson 3

Outlining the basics of SAP Business Warehouse powered by SAP HANA 20

Exercise 1: Use the Data Warehousing Workbench 35

UNIT OBJECTIVES

• Describe the evolution and the data layout of SAP HANA

• Describe the concepts of Business Intelligence (Bl) and data warehousing

• Introduce SAP Business Warehouse powered by SAP HANA

© Copyright. All rights reserved. 1



Unit 1 Lesson 1

Describing the Evolution and the Data Layout of SAP HANA

LESSON OVERVIEW

This lesson introduces SAP HANA. The lesson explains the key advantages of SAP HANA as well as its architecture.

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


Introduction to SAP HANA

Released Jan 2013 Released APR 2012With HANA DB 1.0 S P3 and SAP BW7.3 1 S P4/7.30 S P5

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

SAP Software can run on database (DB) or on the SAP HANA database.

One traditional aspect of the SAP HANA database is the ability to store data and retrieve it in response to structured queries. This is done by accessing the main memory, not disk, yielding much faster data retrieval times. However, complex applications that require big data volumes could still spend only a small percentage of their total run time on data retrieval, with much more time spent in processing the data.

2 © Copyright. All rights reserved.



Lesson: Describing the Evolution and the Data Layout of SAP HANA

To support this, complex handling routines need to be implemented, which can deal with these data volumes. Pre-SAP HANA, there databases had a three tier architecture: data, application, and presentation layers. Databases read data, the database memory processed the data, and wrote results back to either the database, or to the presentation layer. However, given the immense amount of data that is produced by current business software, sensors, and social networks, this concept is becoming increasingly problematic. Adding to this, you now have to evaluate the volume of data very quickly and deliver results on mobile platforms. This makes the old paradigm no longer viable.

In-memory techniques store all the data in memory, and modern computer systems have many computing cores that provide an impressive performance. It is obvious not to move the data, but the instructions. Why not have a complex process in the memory instead of moving the data to the application server to execute?

Under the slogan, 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 in-performance limitations on prior database and hardware combinations.

Transactional Real-time Analytics,Data Entry Structured Data

Sources: Machines, Transaction Apps, User Interaction, etc.

r CPUs(multi-Core +

Cache) Main Memory

Sources: Reporting, Classical Analytics,

Planning, Simulation

EventProcessing Stream Data

DataManagement

Text Analytics, Unstructured

Data

Sources: machines, sensors, high volume systems

Sources: web, social, logs, support system,

etc.

Figure 2: Challenge of Diverse Applications

Diverse applications include the following:

• Transactional Data Entry sources:

Machines

- Transaction Apps

- User Interaction

• Real-time Analytics and Structured Data Sources:

Reporting

- Classical Analytics

Planning

- Simulation




Unit 1: Introduction to SAP HANA

• Event Processing Stream Data sources:

- Machines

- Sensors

- High volume systems

• Text Analytics, or unstructured data, sources:

- Web

- Social

■ Logs

- Support system

Table 1: Technology Drivers

1990 2010 2015 Improvement

CPU in MIPS/s 0.05 7.15 70.8 1,416

Memory in MB/s 0.02 5 120 6,000

AddressableMemory

216 264 264 248x

Network Speed in MB/s

2 125 300 150

Disk Data Transfer MB/s

5 130 300 60





SAP HANA Architecture

SAP Business Objects Bl Solutions Other Applications

Other Applications

________ S£_______

Non SAP Data Sources

1. Hardware Optimization

Figure 3: SAP HANA Architecture

SAP HANA is a database which is embedded into a complete platform which builds around this database. It consists of a web application server (XS-Engine), components to manage planning, online analytical processing (OLAP) analytics, predictive cases (such as planning engine, analytic engine, and a predictive engine) and many more. The scope of this platform is enhanced continuously.

HW Technology Innovations SAP SW Technology Innovations

Multi-Core Architecture (8x8 core CPU per blade)Massive parallel scaling with many blades One blade ~ $ 50.000 = 1 Enterprise Class Server

a +l Row and Column Store

** 0 *

tCompression

m j w Partitioning

64Bit address space - 2 TB in current servers 1000GB/s datathroughput Dramatic decline in price/performance No Aggregate Tables

Figure 4: Technology Innovations as Basis for SAP HANA

© Copyright. All rights reserved. 5 SABFor Any SAP / IBM / Oracle - Materials Purchase Visit : www.erpexams.com OR Contact Via Email Directly At : [email protected]



64-bit processors are designed in a way that their arithmetic logic unit can process simultaneously 64 bits (8 bytes) during a cycle. This includes the external and internal design of data and the 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) are present. Similarly, this applies to the standard addressing modes, the 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 designed different acceleration techniques. These techniques range from the reduction of write operations on the outer tracks of the disk sectors during 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 the hard drives. These techniques have one thing in common, they assume that data is stored on the hard drives, and they are trying to speed up access. Memory is now available in much larger capacities than before, it is more affordable, and thanks to modern 64-bit operating systems, this memory is usable for the first time. The 32-bit address space is limited to four gigabytes of memory, while one with 64-bit addressing can use so much more memory that it cannot fit into a server.

However, all data in main memory is useless if the CPU does not have enough power to process this data. To address this, in recent years there has been a great change on complex CPUs to multi-core processor units. For this innovative computing power, software has to be written in a specific way. SAP 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.

Traditional SAP HANA

CPU

itrtrfrtrtitrtrtrtns t) a

Partitioning Compression Insert Onlyon Delta

Logging and Backup

Storage

Disks Solid State Flash HDD

Figure 5: Computer Architecture is Changing





Computer architecture has changed in recent years. Now, multi-core CPUs are standard, and the extremely fast communication between processor cores enables parallel processing. Main memory is not 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. Due to 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.

The following are the four main concepts of the SAP HANA database:

• Column Store

• Compression

• Partitioning and Parallelization

• Insert only on Delta

Column and Row Store Tables

• Data is stored tuple-wise• Leverage co-location of attributes for a single tuple• Low cost for reconstruction, but higher cost for sequential scan of a single attribute

Row Row Row

Row Operation:

IA B C A B C A B C A B C

_______ _______A_______A_______XRow

XRow

XRow

XRow

Figure 6: Row Data Layout

Row Data Layout:

• Data is stored tuple-wise

• Leverage co-location of attributes for a single tuple

• Low cost for reconstruction, but higher cost for sequential scan of a single attribute

The SAP HANA database supports two types of tables, 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 structure with cells organized in rows and columns. Computer memory however is organized as a linear sequence. When storing a table





in linear memory, you have two options to choose from, as shown in the figure, Row Data Layout.

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. * •

• Data is stored attribute-wise• Leverage sequential scan-speed in main memory• Tuple reconstruction is expensive

Column Column Column

Column Column Column

Figure 7: Columnar Data Layout

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 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 row-based, and vice versa.

Columnar Data Layout:

• Data is stored attribute-wise

• Leverage sequential scan-speed in main memory

• Tuple reconstruction is expensive

Conceptually, a database table is a two-dimensional data structure with cells organized in rows and columns. However, computer memory is organized as a linear structure. To store a table in memory, you have two options:





• A row-based approach stores a table as a sequence of records, each of which contain the fields of one row.

• A column-based approach, where the entries of a column are stored in contiguous memory locations.

Row Store

Column Store

HD

456 France Corn 1000

457 Italy Wheat 900

458 Spain Rice 600

459 Italy Rice 800

460 Denmark Corn 500

461 Denmark Rice 600

462 Belgium Rice 600

463 Italy Rice 1100

ilnS)

I Order Country Product Color Sales |

456 France Corn 1000

457 Italy Wheat 900

458 Spain Rice 600

459 Italy Rice 800




463 Italy Rice 1100

,in5) iinS)

Figure 8: CPU Workload Row Versus Column-Store

For example, you want to aggregate the sum of all Sales amounts using a row-based table. Data transfer from the main memory into the CPU cache happens in blocks of a fixed size called Cache Lines (for example, 64 bytes). Using 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, a new access to main memory is required.

When using row-based data organization the operation can be slowed down by cache misses which cause the CPU to wait until the required data is available. However, with column-based storage, all sales values are stored in contiguous memory, in this case the cache line contains sixteen values which are all needed for the operation. In addition, the fact that columns are stored in contiguous memory allows memory controllers to use data prefetching to further minimize the number of cache misses.





• Dictionary per column• Uses data-driven fixed-length bit encodings• Operations directly on compressed data, using integers• More in cache, less main memory access

Logical Table

Order Country Product Sales

456 France Com 1000

457 Italy Wheat 900

458 Spain Rice 600

459 Italy Rice 800




463 Italy Rice 1100

1

2

3

4

5

Dictionary

Belgium

Denmark

France

Italy

Spain

Compressed column (bit

fields)

1 3

2 4

3 5

4 4

5 2

6 2

7 1

8 4

9

Figure 9: Compression of Column-Store Tables * •

Apart from performance reasons, data management in column store offers much more potential to leverage state-of-the-art data compression concepts at the same time. For example, SAP HANA works with bit encoded values and compresses repeated values, which results in much less memory requirements compared to a classical row store table.

The column store allows for the efficient compression of data. 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 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 typically much smaller consecutive number is stored.

• Advanced Compression: This method means 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 which type of compression is most appropriate for a column.

Use row based store in the following cases:

Mainly distinct values in the source database

This leads to a low compression rate

All the columns of the table are relevant

No aggregation or search required

Table has a minor number of records





Some system tables are stored in the row-store

Use column based store in the following cases:

• Large number of rows, where column based operations will be processed

• High compression rate

• Large number of columns

• Very good suitability for analytical applications (read access)

• When a SAP system is migrated to SAP HANA, the SAP tables are automatically migrated into the storage type suited best.This logic is defined by SAP.

• The majority of tables is 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).

a 11 • ■ a e %« HDB (USER03)

4 k " ' C a ta log

t> »_■ Public Synonyms

p -gEPM .M O D EL

f •% HANA.XS.BASE

4 - £ SAPCIA

p (ep Column Views

P EPM Models

t> EPM Query Sources

p w Functions

p (£j- Indexes

p Procedures

P <—■ Sequences

P k i; Synonyms

4 & Tables - Filter: ‘ /BtC/AUOOOSOJf

“ /BIC/AUOOOSOIOO

HDB (U S E R 03 ) wdflbmt7211.wdf.sep.corp01

Jable Nam e

/B IC/AUOOOSOIOO

Columns Indexes Further Properties Runtime Information

General

Total Memory Consumption (K8):

Number of Entries: 17,762

Size on Disk (KB):

Partition Specification:

HASH 1 l O f i S i 0 g T PffD.NW .lPOS

Detaih for Table

Schema:

SAPCIA

I Type I

Column S torej

lemory Consumption in Main Storage (KB):

Memory Consumption in Delta Storage (KB):

Estimated Maximum Memory Consumption (KB): 1,063

Figure 10: Column and Row Store Tables in SAP

When an SAP system is migrated to SAP HANA, the SAP tables are automatically migrated into the storage time suited best. 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 S E 13).





Storage separation (Main and Delta)• Enables high

compression and high write performance at the same time

f -Compressedand Read optimized

Data compression in main storage

Main Memory

WriteOperations

Column to be stored (sorted)

Main Delta

Read Operations

Delta Merge operation• Asynchronously• Compressed

Write operations* Only in Delta• The update is

performed by inserting

f \Write

optimized

Read operations • From both main

and Delta storage

Delta 1: Column store (not sorted)Delta 2: Row store

Figure 11: 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 very costly activity, as the sort order has to be regenerated and this the whole table is reorganized each time. For this reason SAP has addressed this challenge by separating these tables into a Main Storage (read-optimized, 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 into the main storage. This activity is called Delta Merge. The figure, SAP HANA — Insert Only on Delta, shows the different levels of data storage and distinguishes the main storage from the Delta storage.

LESSON SUMMARYYou should now be able to:





Unit 1 Lesson 2

Describing the Concepts of Business Intelligence (Bl) and Data Warehousing on Any Database

LESSON OVERVIEW

This lesson introduces SAP Business Warehouse (BW). The three layer architecture of BW is explained. This lesson also describes the range of InfoProviders that are used to store and access data in SAP BW.

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

• Describe the concepts of Business Intelligence (Bl) and data warehousing

SAP Business Warehouse (BW)

The goal of the implementation of classic data processing systems is, the acceleration, cost reduction, and automation of processes in individual business areas. This is 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 is of benefit.

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, information is stored in a more detailed format. As a result, there is a need to reduce and to 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 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 information difficult. This is 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 addition, they need to consolidate and create homogenous global master data, as well as massive amounts of transaction data, in differing degrees of aggregation.

In heterogeneous system landscapes, a particular challenge is the extraction and preparation of consolidated transaction data and master data from different source systems. The

SAR40





increasing demand for high-quality business information means that, in addition to an integrated data collection process, detailed data analysis and multimedia presentation options are also required. The demand for business intelligence solutions that incorporate all of these features is immense.

The business intelligence software relies on the data that comes from the source systems, but this information cannot easily be used for targeted analysis. Therefore, the source data is, initially, cleansed, technically and semantically prepared (homogenized). The data is then stored in the Data Warehouse component of the business intelligence software. Analyzing this information with strong and flexible reporting tools then helps to better understand the enterprise information and create knowledge. This knowledge may help the organization define, or redefine, its business strategy, and support the business processes derived from it. The online transaction processing (OLTP) environments (ERP) and the online analytical processing (OLAP) environments (Business Intelligence) are interdependent entities. The figure, OLTP and OLAP Environment shows how both environments interact.

SAP BW Three Layers Architecture

Table 2: Targets of a Data Warehouse Solutions

Layer Details

Reporting Layer Flexible data analysis

• Quality of information (flexible analysis tools)

Standardized and uniform reporting tool

Performance (ad-hoc) reporting

■




Administration & Operations

Education

Transcript of Administration & Operations