The document discusses different types of information models in SAP HANA including column tables, analytic views, calculation views using SQL, and calculation views using CE functions. It provides recommendations on which type of model to use based on analytical requirements and limitations of each model. Complex calculations, multi-language support, and high performance are some of the factors discussed for choosing the appropriate information model.

1. INFORMATION MODELS

2. INFORMATION MODELS
Column Table is recommended for quick wins. It can be used for simple applications and
showcases. It does not require additional modeling. Therefore, many end user clients easily
consume Column Tables. The disadvantage is that the Column table does not support analytical
privileges, multi-language, and client handling. Complex calculations and logic are shifted to
the client side. Overall performance may be low.
An analytic view is recommended for analytical purposes that require read operations on mass
data. It has high performance on SELECT statements. It can be modeled graphically and is
well-optimized. It has certain limitations in functionality, and one of the requirements is that
measures need to be defined within one single fact table.
Calculation View (SQL) is recommended for scenarios with complex calculations. Building a
calculation view using SQL syntax is easy, and you can quickly convert report queries written
in SQL that you may already have at hand. However, client queries cannot be optimized to the
same extent and could be slower when compared to other models.
Calculation View (CE Functions) is recommended for analytical purposes where complex
calculations cannot be expressed in an analytical view. Client queries are well-optimized and
parallelized. CE functions generally achieve better performance when compared to SQL. An
obstacle may be that the syntax is different compared to the well-known SQL Language.

3. INFORMATION MODELS

4. INFORMATION MODELS
The Column tables exist in the Column Store, and Row-based tables exist in
the Row store.
The SAP HANA architecture consists of different types of engines:
The Join Engine is used to perform all types of joins.
The OLAP Engine is used for calculation and aggregation based on a star
schema or similar in analytic views.
The Calculation Engine is used on top of the OLAP engine or Join Engine for
complex calculations. Such calculations cannot be processed by the Join
Engine or OLAP Engine.
The SQL Optimizer decides the best way to call the engines based on the
involved models and queries.

5. INFORMATION MODELS

6. INFORMATION MODELS
When building new Information Models, you need to understand which engine
is utilized. This slide illustrates the type of engine utilized based on the
designed view.
These are some general rules:
The OLAP Engine handles Analytic Views.
The Join Engine handles Attribute Views.
The Calculation Engine handles Calculation Views.
However, an analytical view with a calculated attribute or an attribute view
containing a calculated attribute is processed as a calculation view. It is
important to consider this during modeling as it can impact the performance of
the data model.

7. INFORMATION MODELS

8. INFORMATION MODELS
During modeling, you need to follow certain principles:
Avoid transferring large result sets of data between the HANA DB and client
applications.
Aim to perform calculations after aggregation.
Avoid complex expressions, such as IF and CASE.
Reduce data transfer between engines.
Aggregate data records by reducing columns or using GROUP BY clauses.
Join on key columns.
Filter data amount as early as possible in the lower layers by using
CONSTRAINTS or Analytical Privileges.

9. INFORMATION MODELS

10. INFORMATION MODELS
When you decide on the view that best suits your Information Model, follow
the decision tree as a guide. The decision tree enables you to identify the view
that you need to create based on the analysis requirements. For best
performance and ease of maintenance, it is recommended to use the first three
levels of the decision tree, if possible.

11. INFORMATION MODELS

12. INFORMATION MODELS
During the development phase of a project, you may be involved in
troubleshooting Analytical Views. To identify problem areas in the Information
Models, you use different types of model validation rules. You can set
preferences on how you want to validate your models in SAP HANA Studio.

13. INFORMATION MODELS

14. INFORMATION MODELS
In SAP HANA Studio, navigate to Windows —> Preferences. Then select SAP
HANA —>Modeler —>Validation Rules.

15. INFORMATION MODELS

16. INFORMATION MODELS
You can select the rules that will be applied during the validation of the
Information Objects. Different validation rules can be applied by choosing the
relevant server version.

17. INFORMATION MODELS

18. INFORMATION MODELS
To validate Information Objects, use the Validate button or right click directly
on the object.
Note that you can also select more than one Information Object and validate
them at once.

19. INFORMATION MODELS

20. INFORMATION MODELS
In the Job Log, on the Current tab, double-click on a job to view more
information about the job. The History tab lists the job logs for a specific time
period set in the Preferences window

21. INFORMATION MODELS

22. INFORMATION MODELS
The system displays View Active and View Inactive in two screens. For
example, when you create an attribute view for the first time, the view active
does not exist in the system before the activation. When you modify an existing
view, you create a new view that starts off as inactive. Before activating, the
previous view is still available as the active version.

23. INFORMATION MODELS

24. INFORMATION MODELS
When both an Inactive View and an Active View exist in the system, View
Active will be in the Read-Only mode. Therefore, the system does not allow
having two different Inactive Views.

25. INFORMATION MODELS

26. INFORMATION MODELS
To view the version history, use the toolbar button or right-click the appropriate
Attribute Views and then select History. The History tab displays only Active
Versions. You can view the version history, such as the name of the user who
activated the view and the activation date and time period from the last
activation.

27. INFORMATION MODELS

28. INFORMATION MODELS
In the modeler, the Where-Used functionality enables you to identify where
exactly are the Information Objects used in the schema. This information is
important to determine the impacts of changes in the data model. To use the
function, right-click the object and then select Where-Used.

29. INFORMATION MODELS

30. INFORMATION MODELS
The Where-Used list displays the number of times the object is used.
It displays the type, name, and package of each object that is currently used for
the selected object.

31. INFORMATION MODELS

32. INFORMATION MODELS
HANA enables you to automatically generate documents about the data model.
These documents provide information of all the objects in a package or details of
previous selected objects. To generate documents, you select the Auto
Documentation button from the toolbar. You can also right-click the Information
Objects and then select Auto Documentation.

33. INFORMATION MODELS

34. INFORMATION MODELS
HANA provides two types of documents – Model Details and Model List.
The Model Details type of document displays the particulars of Information
Objects. The Model List type of document displays a list of each component of
the package.

35. INFORMATION MODELS

36. INFORMATION MODELS
The Generate Document window lists all Information Objects in the content. In
the Source pane, select the objects and then click Add. The selected objects are
listed in the Target pane. To remove the objects from the Target pane, select the
object and then click Remove. You can add objects from different packages to
the same document.

37. INFORMATION MODELS

38. INFORMATION MODELS
The export file type cannot be changed. Only the PDF type is supported
currently. Click Browse to specify the path where you want to save the
generated documents.

39. INFORMATION MODELS

40. INFORMATION MODELS
Performance analysis mode in modeling environment introduces performance
analysis hints and indicators to the HANA Modeler Editor. It is either manually
switched on or can be switched on automatically when an information view is
opened. It displays the hints and indicators about table partitioning and number
of rows.

41. INFORMATION MODELS

42. INFORMATION MODELS
You create schemas to group database objects, such as Tables, Views, and
Procedures. In the context of Schema Mapping the source and target Schema are
referred to as follows:
Authoring Schema = schema name in the source system
Physical Schema = schema name in the target system
During data provisioning, you need to create a schema where all the tables are
imported. You create schemas with an SQL Script statement for which the syntax
is CREATE SCHEMA schema_name [OWNED BY name]. In this syntax,
the CREATE SCHEMA statement creates a schema in the current database and
the parameter OWNED BY specifies the name of the schema owner.
For example, a schema with the name my_schema and the system as the owner
can be created using the syntax CREATE SCHEMA my_schema OWNED BY
system.
When the Schema has been created in the target system, you can, as a first step,
import the relevant tables in it. After that and before importing the Information
Model, you need to perform the Schema Mapping activity, accessible via the
Quick Launch view of the SAP HANA Modeler perspective.

43. INFORMATION MODELS

44. INFORMATION MODELS
You use Schema Mapping to map the Authoring Schemas with the Physical
Schemas in the target system, while transferring information models from a
source system to a target system or in case of importing SAP shipped content.
All schema mappings are maintained in the same window.

45. INFORMATION MODELS

46. INFORMATION MODELS
Consider a source system with an Information Model referring to tables in
physical schema SCHEMA_S1, and a target system with the same tables in
physical schema SCHEMA_S2.
When you export the Information Model from the source system and import
it into the target system, without performing the Schema Mapping activity,
then the imported Information Model will not work, since it will still try to
read its tables from SchemaSCHEMA_S1, which does not exist in the target
system. To prevent this issue, the Schema Mapping has to be maintained, in
order to map the Authoring Schema SCHEMA_S1 to the Physical
Schema SCHEMA_S2. The Information Model can be imported
successfully and after the import it will correctly point to
schema SCHEMA_S2.

47. INFORMATION MODELS
This slide depicts
an example of an
Analytic View in
the source system,
with a
table SALES in
Schema HA300.

48. INFORMATION MODELS

49. INFORMATION MODELS
This slide depicts Schema Mapping, which is a preliminary activity for the
import of the information model.
The Analytic View is imported in a target system, where the table SALES is
stored in Schema STUDENT04. Before importing the model, you need to map
the Authoring Schema HA300 to the Physical Schema STUDENT04 in the
target system.

50. INFORMATION MODELS

51. INFORMATION MODELS
Schema content may derive from multiple or different back-end or authoring
environments. To ease the management of schema mapping in such scenarios,
package-specific schema mappings can be maintained, which override the
default schema mapping. These mappings have to be maintained manually, and
here, mapping happens with package-specific default schema.
Additionally, you can edit the Schema Property of a catalog table in the model
editors.

52. INFORMATION MODELS
Information Models are stored into Packages and in order to export and
import Packages they must be included in a Delivery Unit.

53. INFORMATION MODELS
You can import models from your local system or from a server, which
includes three steps:
Creating the delivery unit
Exporting the models (to client or server)
Importing the models (from client or server)

54. INFORMATION MODELS

55. INFORMATION MODELS
In the context of Data Marts, Content Transport is a two-step integration
into enhanced change and transport system (CTS+) or loose coupling:
manual preparation for server-side export and
automated transport and deployment in the target system through CTS+.
It has the potential for ABAP-based new applications or high-performance
analytics (HPAs). It is a TLOGO-based transport. It encapsulates the SAP
HANA content in the ABAP objects. This type of content transport allows
transport of SAP HANA content with application code through standard
CTS mechanisms.
HANA content transport in the context of SAP NW 7.3 BW, powered by
SAP HANA, leverages the existing transport functionality.

56. INFORMATION MODELS

57. INFORMATION MODELS
You use a Delivery Unit to create a group of transportable objects for content
delivery and to export the information models from the source system to the
target server. To set up a Delivery Unit, choose Delivery Units from
the Quick Launch view.

58. INFORMATION MODELS

59. INFORMATION MODELS
In the Delivery Units dialog box, choose Create. You need to associate the
Packages with the Delivery Units, which is required when you export the
models.

60. INFORMATION MODELS

61. INFORMATION MODELS
You can set various attributes of the delivery unit in the New Delivery
Unit dialog box. You need to enter the
delivery unit name,
responsible user,
delivery unit version in the Version field,
support package version of the delivery unit,
patch version of the delivery unit, and
optional PPMS ID.
The Product and Production Management System (PPMS) ID is one
of the attributes of a delivery unit, which was introduced in SAP HANA
1.0 SP5. PPMS is the central knowledge repository for the technical
information regarding SAP software products and their software
components.

62. INFORMATION MODELS

63. INFORMATION MODELS
You can use the Export option to export the packages and their objects that
make up the delivery unit to the SAP HANA server file system. However,
before exporting, you must create the delivery unit.
Click Export in the Quick Launch tab page.
In the Export screen, select Delivery unit.

64. INFORMATION MODELS

65. INFORMATION MODELS
In the Delivery Unit dialog box, select the delivery unit. Choose whether
to export to the server or to the client. Then, click the Next button.
You can also filter the packages by selecting a Time Interval. However,
you need to have a careful approach with the Filter by time option to
avoid serious object consistency problems. A best practice is to
periodically schedule full exports and have a few exports using Filter by
time in between. When you use Filter by time, it is recommended to use
a From date that corresponds to the date of the last full export. To ensure
that no object changes are missed, and therefore that a consistent export
will be performed its best to use a date and time that is slightly before the
date and time of the last full export.

66. INFORMATION MODELS

67. INFORMATION MODELS
You can use the Import options to import information models from the server
or the client. It takes place in various steps:
First, click Import in the Quick Launch tab page.
In the Import dialog box, select Delivery Unit.

68. INFORMATION MODELS

69. INFORMATION MODELS
In the Import Through Delivery Unit dialog box, select the file repository
on the client or the server to which the models have been exported. Next,
select the models that you want to import. You can then define the parameters
such as Overwrite inactive versions and Activate objects, and finally,
click Finish.
The status of import can be viewed in Job log.

70. INFORMATION MODELS

71. INFORMATION MODELS
The export tool comes with a feature to ease the communication when
working together with SAP to gain support for Information Models. It
provides a method to export the Information Objects to the server in a mode
called SAP Support Mode. You can export only the active objects in this
mode. These objects are exported to the server, and the file can then be sent
to SAP support for troubleshooting purposes.

72. INFORMATION MODELS

73. INFORMATION MODELS
You can copy the standard content shipped by SAP to your local package for
your modeling and reporting use cases by using the Mass Copy functionality. In
general you can copy the SAP delivered content to your own packages in order
to avoid overwriting changes during subsequent imports. The same
functionality can also be used to copy your own modeling objects in between
different packages.
To copy the information objects, select the system and click Next. Then, define
the folder location and select the package or models that you want to export.
Finally, select a target repository and click Finish.

74. INFORMATION MODELS

75. INFORMATION MODELS
This slide describes the procedure to copy the standard content that is shipped
by SAP or an SAP partner to your local repository.
To copy the contents of the objects, the administrator needs to create a
mapping in the _SYS_BI.M_CONTENT_MAPPING table, or you can
maintain it in the Mass Copy dialog.
The procedure to copy the standard content includes these steps:
First, from the Quick Launch tab page, choose Mass Copy
Next, maintain the package mappings.
Choose objects to be copied.
Flag the copy checkbox.
Finally, click Finish.
You can view the status of the content copy in the Job log.

76. INFORMATION MODELS

77. INFORMATION MODELS
The Refactoring functionality allows you to restructure your content objects in
the SAP HANA Systems view without changing their behavior. As you move
the objects, their references are automatically adjusted.
Refactoring allows you to move objects to a new package. You can select
multiple objects simultaneously. The job log will be detailed by object.
To be allowed to perform this task, you need read rights on the old package
and create and activate rights on the target package.
Note that refactoring is run in a job. And it maintains the references between
information models.

78. INFORMATION MODELS

79. INFORMATION MODELS
The Repository includes certain features for translating the metadata texts. To
prepare for translation, you must first maintain some metadata, which is used
by the translation system in the package. This metadata maintenance is done
through the Edit Package Details dialog.
Select the required Terminology Domain to determine the correct terminology
of the text that needs translation.
Enter a Text Collection to associate a package with a collection. This specifies
the language into which the package objects are to be translated.
Enter the text in Hint to provide a suggestion regarding the translation of the
package.
Enter the text in Hint to provide a suggestion regarding the translation of the
package.
Enter a Text Status.
Choose OK.
Hints and text status values for the package are notes to someone who may
later be performing the actual language translation.

80. INFORMATION MODELS

81. INFORMATION MODELS
The Repository Translation Tool (RTT) is a Java-based command line tool that
exports the language files in a standard format so that the customers or the
partners can use them.
RTT implements this process in four steps:
Export: RTT exports the texts in the original language (written by the
developer) from the SAP HANA Repository text tables to the file system.
Upload: RTT uploads the texts from the file system to the SAP translation
system. After this step, the translators can translate the texts from the original
language to the required target languages.
Download: RTT downloads the translated texts from the SAP translation to
the file system.
Import: RTT imports the translated texts from the file system to the SAP
HANA Repository text tables.

82. INFORMATION MODELS

83. INFORMATION MODELS
You can use these rtt commands to perform various tasks:
The command rtt -e -p pack* downloads the translated texts from the
packages that match pack*, rom the translation system. It then imports
the texts into the database using the default configuration file, that
is, rtt.properties.
rtt -i -p pack* downloads the translated texts from the packages that
match pack* from the translation system. It then imports the texts into
the database, using the default configuration file, that is,rtt.properties.
The rtt --export -p pack* -x exports command exports the texts from
the database into the exports directory.
The command rtt --upload -p pack* -x exports uploads the texts in the
exports directory to the translation system.
rtt --download -p pack* -x imports downloads the translated texts into
the imports directory.
The rtt --import -p pack* -x imports command imports the translated
texts from the directory.