SAP HANA MODELLING BEST PRACTISES
3
MOTIVATION
SAP HANA Modelling is gaining increasing popularity and importance for our customers as they start to
discover the variety of SAP HANA features and possibilities. After all SAP HANA is much more than a simple
in-memory-database. Customers are starting to use features like modelling of calculation views natively in
SAP HANA, leveraging text-analysis capabilities or getting first hands-on experience with the geo-special
engine. The true potential of SAP HANA can be discovered best when customers start working with SAP
HANA in a native way using HANA Repository and the SAP HANA Extended Application Services (XS)
platform.
The motivation for this document is to provide some recommendations and best practices to avoid known
soft spots and to provide background information and a deeper insight on the SAP HANA system behavior.
The recommendations made in this document are valid for all SAP HANA 1.0 Support Package Stacks (SPSs)
that have been published since the introduction of SAP HANA XS.
ARCHITECTURAL BACKGROUND INFORMATION
SAP HANA Repository
The SAP HANA Repository is SAP HANA’s built-in, out-of-the-box, source code repository. Every entity which
you define in SAP HANA is stored in the SAP HANA Repository. The SAP HANA Repository does not
distinguish between storing SAP HANA native artifacts (e.g. tables, views, procedures) and storing other
artifacts (e.g. xsjs coding, xsodata services, html and java script files).
Besides storing the source code, the SAP HANA Repository controls the activation process that generates
native SAP HANA artifacts in the SAP HANA Catalog. The SAP HANA Catalog contains the metadata and the
physical SAP HANA entities, the tables with the data, the view definitions and the procedures. The
interaction between the SAP HANA Repository and the SAP HANA Catalogue is a complex process which
requires a closer look. This interaction process is also very different from what customers know in an SAP
NetWeaver environment.
While SAP NetWeaver from the very beginning had been designed as a platform to run on top of all
databases supported by SAP, the SAP HANA Repository was designed for the SAP HANA database. This has
implications for the process of activating entities in SAP HANA Repository and its influence on the SAP HANA
Catalogue.
First of all, all objects need to be validated for correctness during the activation process. This validation takes
place on the catalog level (by the SAP HANA database) as well as on the SAP HANA Repository level.
Depending on the type of object being activated the SAP HANA Repository checks all objects that are
depending directly or indirectly ("principle of upwards validation") on the activated object in order to
determine if any object dependencies break during the activation. On the catalogue level, incoming
dependencies are also checked, for example interfaces of used objects like tables, views, etc. This can lead to
a cascade of checks that increases significantly with the "network" of dependent objects and can lead also to
a situation in which objects are checked more than once. The goal and benefit of this behavior is the “self-
healing” aspect of the Repository in the sense that it ensures the achievement of a consistent and valid state
for all software artefacts in the HANA Repository after activation.
The downside of these validation cycles are activation times which are potentially long.