none
Different attribute names in web interface and subscription views

    Frage

  • 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

    Donnerstag, 10. Januar 2013 15:35

Antworten

  • 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/

    Montag, 28. Januar 2013 15:28

Alle Antworten

  • It 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 14:27
  • 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/

    Montag, 28. Januar 2013 15:28
  • I 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.
    Mittwoch, 13. Februar 2013 19:58