cancel
Showing results for 
Search instead for 
Did you mean: 

Help - SAP HANA Naming Conventions and Organisation

Former Member
0 Kudos

Hi all,

Anyone have suggestions around best practice for HANA naming conventions and organisation within the Modeler Navigator? EG what have other projects done? I have a BW background and naming conventions are fairly standard - EG Z for customised object 0 for sap delivered usually followed by project name and object type M for multiprovider for example and 001. ZPROJECTM_001.

HANA is different. Unlike BW where you often determine the source of the data by the model flow, in HANA you have to drill into the views to see the associated tables. At high levels like calculated and analytic views the components that make up the model are often other views which you have named. Therefore it becomes more difficult to determine what the model views actually hold. EG At my current client they have material data from multiple systems.

Normally I would suggest naming content like attribute views something like AT_SYS_MATERIAL (Where AT represents HANA object, SYS = source system, and MATERIAL =the source table key or main subject of the model). However, attribute and other views in HANA may have tables sourced from many source systems and often these source systems can change over time. So whats the best way to name a model which will be future proof for the business and useful to first time developers?

In terms of organisation we have 3 root packages so far: Masterdata package (holds global reuseable master data models), Foundation package (holds global reusable business area relevant models like Sales models), and Application package (holds project specific models). I think this makes sense in a packaging perspective but what about the model names themselves?

OBJ_TABLEKEY_Additional description? (EG for a material hierarchy attribute view AT_MATERIAL_HIER).

Perhaps attribute views should have table keys in the name and analytic views should have the business termonology as this makes relevent sense.

Anyone else have any suggestions?

Kind regards,

Danielle

View Entire Topic
Former Member
0 Kudos

Hi Danielle,

In the implementation I was part of, I had the naming conventions for models as follows:

Attribute views - AT_<md_obj> e.g AT_MATERIAL, AT_CUST_SALES etc

Analytic views - AN_<app/proj/fact>_<no> e.g. AN_ORDERS_01  - could be an application/project/fact table name and number as suffix in case you have more than one in the same project/application/fact table

Calculation views - CV_<app/proj>_<no> e.g CV_SALES_01

Having suffix such as HIER, TEXT probably might not make sense because you could have attributes, texts & hier within the same view. Also having the keys on the name could also be difficult in scenarios where:

a. underlying table keys change but you dont want the view name to change as reports/univ are created on top of them

b. you could have composite keys - about 3 or 4 or sometimes more and it could be difficult to fit all in.

Agree with you on the business terminology bit on analytical/calc views makes sense as well as sometimes users would create reports on top of them using excel, visual intelligence etc.

Thanks,

Anooj

Former Member
0 Kudos

Thanks Anooj,

Good to have some more ideas put out there as HANA has only really been available for general use the last year so i think this will be a common question.

Glad to see you on here . Hope all is well.

Regards,

Danielle