Concepts used in HANA Implementation at Kaveri

 In-line Declarations
 CDS Views
 View on View Concept
 ALV using IDA (Integrated Data Access)
 Data Modelling (Attribute, Analytic & Calculation Views)
Inline declarations

Inline declarations are intended to make programs leaner and easier to understand. The following rules must also be
observed:

 The rule that dictates no global variables and field symbols means that inline declarations should only be
used in processing blocks that support local data.
 Inline declarations are an exception to the rule that local declarations should only be made at the start of a
procedure. For this reason, they should only be used in easily manageable procedures, to make them easier
to understand.

Inline ABAP DATA declarations are a new concept introduced in release 7.4 which allows you to declare your internal table
variables or work areas within the code that uses them. This is done simply by adding the DATA(wa_data) or @DATA(it_data)
statements.

The easiest way to describe this is to show you a very simple before after ABAP code example. Pre 7.40 you would declare a
work area and read data into it something like this

Example 1:

DATA: it_ekko TYPE STANDARD TABLE OF EKKO,

wa_ekko TYPE EKKO.

READ IT_EKKO INTO WA_EKKO.

Using the new method you would simply just using the following code:

READ TABLE it_ekko INDEX 1 INTO DATA(wa_ekko_new).

Example 2:

DATA: it_ekko TYPE STANDARD TABLE OF t_ekko INITIAL SIZE 0,

wa_ekko TYPE t_ekko.

select ebeln ebelp

statu aedat
matnr menge
meins netpr peinh
up to 10 rows
from ekpo
into CORRESPONDING FIELDS OF TABLE it_ekko.

Using the new @DATA statement you could essentially replace all this with the following ABAP code, which automatically
create an internal table with the correct field structure and drops the selected values into it. AS well as the @DATA note the ,'s
after each field in the SELECT.

select ebeln, ebelp,

statu, aedat,
matnr, menge,
meins, netpr, peinh
up to 10 rows
from ekpo
into TABLE @DATA(it_ekko_new).

Likewise we can use inline declarations in

 LOOP Statement
 READ TABLE Statement
 LEFT SIDE OF VARIABLE ASSIGNMENT
  Field Symbol Declaration
 CATCHING AN EXCEPTION

CDS Views

In general, Core Data Services (CDS) is an enhancement of SQL which allows a simple and harmonized way for the definition
and consumption of semantically rich data models natively in HANA applications – independent of the consumption
technology. The enhancements compare to SQL include:

 Annotations to enrich the data models with metadata

 Associations on a conceptual level, replacing joins with simple path expressions
 Expressions used for calculations and queries in the data model

CDS views, like the well-known dictionary views created and maintained in transaction SE11, are managed by the ABAP data
dictionary. During activation, a database view is created on the HANA layer, yet only the ABAP CDS view (defined in a so-
called DDL source) has to be transported via the ABAP Change and Transport System (CTS). Moreover, the functionality
provided by CDS views can be used on all SAP supported databases.

Example
View on View Concept

View on view concept is nothing but designing a CDS View with multiple sub views, where the complex selection structure is
split into simple selection views.

Example

Created a simple CDS view used in another view.

The above created CDS view is used in another view which is used to display data.
ABAP List Viewer with Integrated Data Access

The ABAP for HANA Development Environment and familiarizes you with the new “ABAP List Viewer with Integrated Data
Access”. The ALV with IDA introduces some major database feature improvements compared to the classical ALV like:

Database improvements when compared to the classical ALV –

 Database paging: Result will be selected from the database in pages – there is no need to transfer the full result set
to the application server any more
 Operations like aggregation, sorting, and filtering in the ALV grid will be pushed down to the database layer

Below example is ALV Table Display for CDS Views – ( ZHT_CDS_FOR_ALV1 )

First create a CDS view in HANA Studio and using ABAP program display output in ALV.
Here we have the new technique called ALV IDA where the data is displayed from CDS view directly without using any
conventional select statements.
Difference in syntax for both Classical ALV & ALV with IDA :-

Classical ALV

Result Table :
ALV with IDA :-

Result Table :
Different Types of Operations on ALV

1. Set Title :-

Result :

2. Remove/Hide the Table Columns:-

Result :

Before :

After :

3. Change Column Heading :-

Result :

4. Select Option :-

Result :

Selection Screen Entry:-

Output :

5. Sorting & Grouping :-

Result :
6. Search for the Term:-

Result :
Data Modeling .
The SAP HANA STUDIO is used for creating data models within SAP HANA. It can be used to explore and
analyze existing data models, make modifications, and build new data models from scratch. The modeler
generally uses the Administration Console and Modeler perspectives and tools of SAP HANA Studio.
Figure 6-1. SAP HANA Studio: Modeler Perspective

Packaged applications for SAP HANA come with their own data models. You can inspect them with SAP
HANA Studio and tailor them to your needs.

BI clients use data models directly for reports. Views that are created inside SAP HANA can be treated by BI
tools as any other table, allowing for direct access for reporting. If you calculate net sales in your data model
and have the HANA engine execute the calculation of net sales in memory and then just send the result set
up to your query tool, it’s much more efficient than having the query tool pull up all the raw data and then
having the BI query execute what the net sales difference .

Application developers use the output of data models as inputs into their applications. For best performance,
application developers will want to maximize the number of calculations that are done in the database and to
reduce the amount of data that’s transferred back up to the application. It, in turn, allows the application
developer to offload the bulk of the calculation logic into the database, making it possible for application logic
to be greatly simplified and for views to be useful across a range of tools.

Different Types of SAP HANA Modeling Views

There are three types of views in data modeling in SAP HANA: attribute views, analytic views,
and calculation views. Understanding how each of these different views provides additional value on the raw
data in the database will help you figure out how to model your data for maximum flexibility and performance.
 Attribute views provide descriptive data about the characteristics of data in your database. This is
“master data” that defines things like hierarchies that describe relationships between data elements. By
constructing attribute views, you create dimensions from which subsequent views can be constructed.
 Analytic views in SAP HANA are optimized for aggregating mass data. Because the database is so
fast, it’s not necessary to store aggregates in the database; rather, you aggregate on the fly in memory.
Analytic views construct a central master “fact table” with key figures. You can use expressions,
operators, and functions to analyze this data.
  Calculation views provide a way to do flexible, complex logic in the database. They are built on top of
one or more analytic or attribute views and allow you do calculations after aggregation and grouping.
Calculations are generally done after grouping at the attribute level and after aggregation at the
analytic level.
figure 6-2 shows a summary of the three types of views in SAP HANA

Figure 6-2

Attribute Views

Suppose our transaction database has a customer ID that links to all the information about a customer
who purchased a given product. By itself, the customer record allows you to compute simple measures, like
total sales by customer.

Attribute views allow you to join relationships together that further describe the data that you’re working with.
By joining your “customer ID” to data in your customer database, you can further subdivide and analyze sales
data according to conditions and relationships which are not present in the original transaction. Because
these joins run in memory and are not limited by disk speeds, you can explore even more complex
relationships than you could in traditional database models and still maintain performance.
 Figure 6-3. SAP HANA Attribute View

Using attribute views allows you to bring data analysis down to size before running complex calculations. In
HANA, it makes sense to apply attribute views as filters, which pull out just the data you need before handing
it of to a complex calculation.

Analytic Views

Analytic views operate on key figures in your database. They are used to model data that includes
measures and to compute operations based on those measures.

An SAP HANA database may have a very large number of records in it, corresponding to individual
transactions. In a typical disk-based database, you’d compute and store a separate table for aggregated data,
so that something like “total sales by day” would be updated periodically and stored separately on disk. In
HANA, this is not necessary since the database is very fast and aggregates are best computed on the fly.
Because these aggregates are computed very rapidly, you can explore a much broader set of queries than if
you had to decide up front which aggregation approach you would be using and commit those records to disk.

The end result of this for modeling is that the analytic views that you build on top of these measures are also
key for reducing the amount of data passed along to subsequent views. Do the aggregation in your database
before you pass that data up to the next level so that the computations happen at the right level. You’ll gain a
lot of performance when the BI tool or the application can deal with data that’s already been aggregated
rather than giving it a firehose dump of data to aggregate.
 Figure 6-4. SAP HANA Analytic View

Calculation Views

One of the exceptional features of SAP HANA is the ability to do calculation views in the database. These
views offer a level of programming flexibility that goes beyond the aggregations found in the analytic views,
and they can bring in data from multiple analytic and attribute views to express complex logic. Calculation
views can have layers of calculation logic, can include measures sourced from multiple source tables, and
can include advanced SQL logic, R code, and more.

Calculation views are visible within HANA as virtual tables, and applications and BI tools can access them in
the same way that they consume other views. Like other views in HANA they are computed as needed, and
intermediate values and aggregates are built on the fly rather than being stored on disk and updated
periodically.

To obtain best results, the modeler should use the full power of the attribute and analytic views before
passing data into the calculation view. Calculations will work best with data that has already been reduced in
size. If your database has a billion records in it, but you only need the calculations to run on a few thousands
of them, you should build your models so that the aggregation and grouping has already occurred before your
calculations run.
 Figure 6-5. SAP HANA Calculation View

SAP HANA Information Modelling which also known as SAP HANA Data Modelling is the heart of HANA
application development.

Since SAP HANA is a radically new database “underneath the hood,” SAP had to provide DBAs, data
architects and others a familiar way to interact with the tables while maintaining a level of abstraction to
ensure that people wouldn’t disrupt the tables. That’s how you get the “virtual” data modeling capabilities of
SAP HANA. Although people can log in and “see” the tables, they aren’t really there, like they are in a
traditional disk-based database. What you’re seeing is a virtual representation of the tables since the actual
tables aren’t physically persisted on the storage medium as they would be in a disk-based database. This
virtual data model allows people incredible flexibility when manipulating the data and protects them from
some of the more nasty effects of playing around with physical tables in the database.

In the context of SAP HANA, data modelling can be viewed as the construction of different types of views of
the data tables maintained in the SAP HANA database. Modelling defines how you are going to access the
data that’s physically stored in HANA tables. Views can be thought of as “virtual” tables that are built up from
underlying data structures in memory or from other views.

From an SAP HANA perspective, data modeling defines how you’re going to store and access your data. By
creating views, you build new layers of access to your data that are derived from what’s in physical RAM
storage, but that is calculated or adapted based on your application needs. The views are built on demand
and are always up to date, and they can contain complex calculations that are computed within the database.

Because SAP HANA is a fast, in-memory database, you can build virtual models that are more flexible and
powerful than those found in typical disk-based database designs. HANA is optimized for aggregating mass
data on the fly, and thus it allows you to build models on top of raw transaction data without first doing pre-
aggregation or creating materialized views.
The concept of a logical view in a database is pretty universal. The logical structure points to where the
physical data is stored. What’s different in HANA is that operations on large quantities of data are so fast that
it’s not necessary to build a persistent additional physical view or an additional index on the data to make it go
fast. Rather than building redundant tables for speed, you aggregate data on the fly. The key in there is that
HANA is not re-persisting the data multiple times for every different view of data that we want to do. It is
stored once and then we can create a lot of different logical views at that point to the data that is physically in
the database for different use cases and different application uses without having to make copies of the data
to support additional views.

Another upside to logical views: Extending data modeling to more stakeholders. The great thing about
creating logical views of the data is that you can allow more people to create those views because their views
don’t change anything about the underlying data store. You might never allow less technical people to access
a traditional database, but with the ability to create logical views of the data that don’t change the underlying
data store (let alone corrupt it), you can allow as many people as are interested to get involved with modeling
in SAP HANA.

With HANA, you’re not modeling to get around disk space constraints, and you don’t need to model and keep
in mind where your data’s partitioned and where it’s coming from and how to best access it from different
storage pieces to reduce the lag time of disks. With HANA you can create queries that are more complex and
still achieve high performance using straightforward SQL statements. If you’re coming from a legacy system
with maybe a hundred different types of models that draw on different master data, you may find that you
need only a tenth that many in HANA because you are no longer having to design models with regard to disk
or data volume constraints. You can blend models together and get a broader view of what’s going on with
the data, with more granularity than you could before.

Becoming proficient at data modeling for HANA is one of the key elements of extracting all of the
performance out of the system. Understanding how the system works, where its speed advantages are, and
how to get the best performance from the system are all best done with hands-on experience.

Example :
Start creating Information model. There are three information views group together under a container called
Package. Package created under CONTENT folder.

1. CREATE HANA PACKAGE:

 Select Content folder.

 Right Mouse Click > New > Package
 Provide Package Definition

2. CREATE ATTRIBUTE VIEW

 Select eFashion package

 Right Click > New > Attribute View
 Provide View Definition
 Next, Select ARTICLE_COLOR_LOOKUP table, Finish
 Add Attributes
 Select ARTICLE_COLOR_LOOKUP_ID > Right Click > Add as Key Attribute
  Validate > Save & Activate
 There are two scenarios in Attribute view.
 Data Foundation: Container of attributes and joins. Details area shows the attributes and Output
columns and their properties
 Semantics: Shows the properties, Columns and Hierarchy.
 Attribute View must have a Key attribute.
 Once attribute columns and key attributes define ,click on Validate and then Save and Activate.

 Repeat above process to create Attribute View for all dimension tables.

3. CREATE ANALYTIC VIEW FOR SHOP_FACT.

  Select efashion package> Right Click > New > Analytic View.
 Provide View Definition.
 Next, Select SHOP_FACT table.
 Next, Select Dimensions.
 Finish
 Add Attributes
o SHOP_FACT,ARTICLE_ID,COLOR_CODE,WEEKID,SHOP_ID
 Add Measures
o MARGIN,AMOUNT_SOLD,QUANTITY.
 Create Calculated Measures.
 Join Fact Tables and Dimensions
 Validate
 Save and Activate.
 Data Preview.
 Analytic View contains Semantics,Logical Joins and Data Foundation scenarios.
 Data Foundation consist of one or more FACT tables.
 Logical Join area containsDimensions and Fact tables linked together in the form of star like structure;Fact table
center surrounded by dimension tables.This is also called as Star Schema.
 Analytic views are created as Column Views under system defined catalog_SYS_BIC.

Calculated columns can be created as shown in below screenshot.

..

Click on Logical Join > right Click on Calculated Column > New Calculated Column
4. CREATE ANALYTIC VIEW FOR PROMOTION FACT: Follow similar process to create Analytic view
for promotion fact.
5. CREATE CALCULATION VIEW USING GRAPHIC VIEW:

 Select eFashion package > Right Click > New > Calculation View..
 Provide View Definition
 Next,Select Analytic Views, Finish
 Select UNION > Link Analytic Views to UNION > Link UNION to OUTPUT
 Select UNION and MAP elements
 Select OUTPUT > Add Attributes and Measures
 Validate > Save & Activate >Data Preview
 Calculation views contains Semantics,Aggregation,Union,Join,Projection objects.
 UNION is used to combine two or more Analytic views.
 Aggregation in Calculation views is highly optimized.
 Calculation views can be created either as GRAPHICAL or SCRIPTED.
 SCRIPTED Calculation view support CE(Calculation Engine) functions,highly optimized for
UNION,AGGREGATION,JOIN.
 Use of CE function recommended over SQL command.