Skip to Content

Entering the realms of the SAP HANA Studio

One of my favorite Science Fiction books is the classic Gateway trilogy, by Frederik Pohl. It relates the stories of space travel entrepreneurs. Once upon a time, in the future, people discover alien spaceships by chance. The spaceships can take you to the next galaxy in a spell, without scientists ever finding the real technological reasons behind it. The only thing some pioneers positively find out is that “it works” most of the time. In spite of the risks, there are enough adventurers ready to ride the rockets: They sit down in a strange cockpit, press a couple of buttons, et voilà, they are in outer space at the speed of light.
Actually, we should not roll our eyes too early about the naiveté of such a story: Most people today don’t know how a car works either, but this does not prevent them from using them every day without much ado. The same applies for other technologies.

When I entered the SAP HANA Studio for the first time, it was not initially a “Gateway-like” feeling for me. If you are familiar with Eclipse or with SQL Studio tools, you are not very surprised about your surroundings. Furthermore, when you start taking a close look at some basic functionality for the first time, some questions arise.

One of the FAQs we get, and which, admittedly, also puzzled me a bit at the beginning, is the following:
What is this Attribute View, Analytic View and Calculation View tool differentiation about? Why can’t you simply create database views with the SQL editor? Database views are database views are database views…
Before I offer you some answers, I will summarize how the SAP HANA Studio is structured today from the User Interface perspective. Tools are not immutable and the SAP HANA Studio will evolve over time. However, there are some good reasons why some things look the way they look today. Today the SAP HANA Studio is structured into 2 main areas:

  • The Catalog, which basically contains the raw database tables (in both Column Store, and classic Row store format) organized in Schemas (name spaces). You can either replicate the tables from external systems (e.g. all tables from an Enterprise Procurement Management Data Model in an ERP system) or create your own tables for your project.
  • The Content, which basically contains the Models (à-la-Business-Intelligence, e.g. Master Data views, Star-Schema-like Cubes and corresponding calculations), Procedures and corresponding business authorizations (Analytic Privileges), all of them organized in Packages. Models are organized in 3 Types:
    • Attribute Views: These Column Views give context to Master Data, for example,
    • Analytic Views: These Column Views are built on top of Fact Tables and “shared” Attribute Views, and are equivalent to the Star Schema in Business Warehouse approaches. A Fact Table is a transactional table with measurements (Key Figures), e.g. Revenue, and is surrounded by Dimensions (Attribute Views), e.g. Region, Time, Product, etc. This results into Star-Schema-like Cubes, for example, “Revenue by Product, Region and Year”.
    • Calculation Views: They are built on top of Analytic Views and tables, involve complex calculations and allow a more complex Fact Table structure than with Analytic Views. Example: Calculation Views allow you to combine measures from more than one Fact Table.

The main reason why this structure is the way it is today has to do with the underlying SAP HANA Architecture and its optimization engines. Each type of Column View above has an associated SAP HANA Engine:

  • Attribute Views are managed by the Join Engine
  • Analytic Views are managed by the OLAP Engine
  • Calculation Views (and Procedures too) are managed by the Calculation Engine

These engines strongly optimize performance for the View in question and they hierarchically build on top of each other. In order to optimize performance for your modeling results, the current recommendation is to start “small” as much as you can, that is, to try to solve your modeling problems as much as possible with Attribute Views first (the Join Engine represents a less expensive approach than OLAP and Calculation Engines), then with Analytic Views, and finally, if your particular business problem cannot be efficiently solved in any other “simpler” way, you can always use Calculation Views or Procedures (Calculation Engine).

The current Content Package and Column View structure also enables easy data consumption, and provides both, user friendly graphic modeling capabilities, in addition to more complex scripting functionality (e.g. for Calculation Views and Procedures) to be used whenever required.

Once I learned about these good reasons, I started to grasp the meaning of this ColumnView Trinity mystery, from a historical perspective… The 3 views simply reflect the internal SAP HANA DNA, and try to point developers in the right direction, so that they use the right engines at the right point in time. Furthermore, I expect that future versions deal a bit more elegantly with the needs of the backend.

I am looking forward to further renewal, and the next optimization trend in SAP HANA’s evolutionary path.

Gemma Durany
Co-Founder and COO
Glooobal GmbH

Be the first to leave a comment
You must be Logged on to comment or reply to a post.