on 09-04-2012 1:39 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Danielle,
You could find some of the best practices and guidelines including the naming conventions here.
https://cookbook.experiencesaphana.com/modeling-data/modeling-concepts/modeling-guidance/
Best Regards,
Vittali
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
New URL for this link :
https://cookbook.experiencesaphana.com/bw/modeling-data/modeling-concepts/modeling-guidance/
User | Count |
---|---|
84 | |
10 | |
10 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.