Different attribute names in web interface and subscription views
-
Donnerstag, 10. Januar 2013 15:35
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
Alle Antworten
-
Montag, 28. Januar 2013 14:27It 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.
-
Montag, 28. Januar 2013 15:28
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/
- Als Antwort vorgeschlagen Xavier Averbouch [xavave]Moderator Donnerstag, 31. Januar 2013 11:57
- Als Antwort markiert Peter Jonckheere Mittwoch, 13. Februar 2013 19:50
-
Mittwoch, 13. Februar 2013 19:58I 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.

