Search code examples
hanahana-sql-script

Why Does HANA Table Name Have A "/"?


There are a few things I've needed to get used to in using HANA SQL.
Like using all upper case, but what I really don't understand is why "/" is necessary.
Because of the "/" I must enclose the table name in "..." (double quotes).

"_SYS_BIC"."NGDW.SM.PVT/MY_TABLE_NAME"

What is the significance of the "/"?
Why can't it be a "."(dot)?

"_SYS_BIC"."NGDW.SM.PVT.MY_TABLE_NAME"

Is it because HANA only allows so many levels using "."?
I have tried to search for an explination, but have been unsuccessful.
If I can understand why, it will help me remember the necessary syntax.


Solution

  • Good question and one that cannot be answered by only looking at HANA (the database).

    SAP Business Warehouse (SAP BW), SAP's data warehouse application, has used this way of naming database objects for many years, way before HANA was even thought of.

    If you see table and view names like /BIC/<this_is_a_name> then these are SAP BW objects (or from applications using the BW technology).
    For all practical matters, this is a way of creating namespaces for DB objects.

    Now, SQL DBs come with a namespace mechanism for DB objects - the one you mentioned using periods . between different name components.

    <DB name>.<schema name>.<object name> is a common scheme for that.

    However, not all DBMS support/supported this many years ago, when SAP BW was first developed (around 1996/7 if I'm not mistaken). Oracle, for example, supports only one schema per DB user. So to make "namespaces" within this default schema, one has to do it "within" the object name.

    SAP has chosen the forward-slash / to segment the object names and due to the object naming rules specified for SQL this requires that the name must be quoted, as you pointed out.

    Would that be any different if the separator character was a period .?
    Not at all. As the period character has special meaning for SQL, the DBMS would try to interpret it as part of the

    <DB name>.<schema name>.<object name>

    mentioned above.

    If more than these two periods are provided, the DBMS does not know what is meant by that.

    When it comes to the "graphical views" (information models) in SAP HANA, then there is another aspect that comes into play.
    The classic XS modeling/development is oriented around a central repository of development artifacts. All source code for DB objects and XSJS (JavaScript) programs are stored in this repository and "activated" (think compile and deploy) from there.
    The organisation structure in this repository is "packages" which behave like folders and sub-folders very similar to what you find in e.g. JAVA projects). In this package-structure, every individual object can be uniquely addressed via its full "path", e.g. <main package>.<sub-package>.<sub-sub-package>/<objectname>.

    This is where the mix of periods . and forward slash / in the view name comes from.

    Note, that all this is still on a conventional level, i.e. it is technically absolutely possible to create calculation views without all that namespace zip-zap. You just cannot use the graphical modeling tools for that then.