Different attribute names in web interface and subscription views
-
Thursday, January 10, 2013 3:35 PM
In the web interface we like to use userfriendly names for the attributes of an entity.
In the generated subscription views we like to see more precise and complete names that are meaningfull to data specialists. E.g. in the web page of the "service" entity we have an attribute called Lifecycle Status, but we would prefer to name the data element "service_LCS" and see that name in the subscription views. As each entity has a LifeCycle Status, it becomes important that we are able to correctly identify them when combining multiple entities in a single report/query.
I understand I could create another layer of views to handle the naming differences, but I would like to see that we are able to separate the name used for the UI field from the name of the data element.
Is there anyway to realize this?
Thanks for your ideas
All Replies
-
Monday, January 28, 2013 2:27 PMIt looks like judging from the silence there is no work around for this. Views on top of the views is probably what you are limited to.
-
Monday, January 28, 2013 3:28 PM
Correct. A second layer of views is the right solution. Note that there are many other reasons to consume the master data through secondary views, eg
-Publishing only rows that have passed validation
-Hiding status columns, change date and other attributes related to data quality or stewardship
-Choosing between the code and name for domain attributes
-Aligning the MDS entity and attribute names to a standardized enterprise model
-Joining across MDS entities to add related attributes to a published entity (for instance if customer -> state -> region, you may want customer.RegionID in downstream system)
David
David http://blogs.msdn.com/b/dbrowne/
- Proposed As Answer by Xavier Averbouch [xavave]Moderator Thursday, January 31, 2013 11:57 AM
- Marked As Answer by Peter Jonckheere Wednesday, February 13, 2013 7:50 PM
-
Wednesday, February 13, 2013 7:58 PMI agree with David. Although I don't like multiple layers of views, we have chosen an approach with a secundary layer of views. As the context of the data is clear in the web UI we there choose for friendly and intuitive naming while in the secundary views we go for a standardized more technical naming which clearly identifies both the entity and the attribute. This makes live a lot easier when multiple views with sometimes similar attributes are combined.

