In-Line Declarations CDS Views View On View Concept ALV Using IDA (Integrated Data Access) Data Modelling (Attribute, Analytic & Calculation Views)
In-Line Declarations CDS Views View On View Concept ALV Using IDA (Integrated Data Access) Data Modelling (Attribute, Analytic & Calculation Views)
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:
Using the new method you would simply just using the following code:
Example 2:
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.
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:
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
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 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
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 :
Before :
After :
4. Select Option :-
Result :
Output :
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.
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.
Repeat above process to create Attribute View for all dimension tables.
..
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.