locked
Best practives for parallel hierarchies in MDS? RRS feed

  • Question

  • I have 2 hierarchies that converge on one of the levels.

    What is the best practices of implementing parallel hierarchies in MDS? Any examples from real life?

    Example (Component1 is assembled at Line1):

    Product Hierarchy

    Widget1

        |---Assembly1

             |---Component1 ---|

             |---Component2     |

        |---...                          |

    Organization                  |

    |---Factory1                     |

         |---Line1---------------|

         |---Line2

    |---...

    Thank you!





    • Edited by Michael_L_ Wednesday, September 5, 2012 7:15 PM
    Tuesday, September 4, 2012 10:28 PM

Answers

  • As Anthony points out, these do need to be in the same model to create the shared references. However, you can have more than one hierarchy in the model. Since you are looking at this as a hierarchy, then can we assume that a component is assembled on one and only one line? If that is the case, then you can:

    - create an entity for Factory

    - create a separate entity for Assembly Lines, where each line has a unique code (of course), name, and Factory lookup (DBA on Factory)

    - In the Component entity, create an "Assembly Line" attribute and make it a DBA referencing Assembly Lines.

    - Now you could create a derived hierarchy to report Components by Line or even Components by Factory.

    But... If these are already in separate models, you would need to essentially duplicate the Line info in your Components entity (boo), but then you might be able to export the data with subscription views and join the output for reporting.

    • Marked as answer by Elvis Long Thursday, September 13, 2012 1:06 AM
    Tuesday, September 11, 2012 4:40 PM

All replies

  • So typically you create one model per functional area.

    http://msdn.microsoft.com/en-us/library/ee633746

    However the warning I will give you, if you have functional areas that cross over it gets more complicated.

    i.e. Your company may have Divisions, and products may be manufactured by a specific multiple division, however by the book Division and Product would really be their own model.

    Unfortunately you cannot add domain specific attributes between models, so you have to make a choice to either muddy the waters and make a model that is multiple functional areas, or create some sort of process (ETL, BizTalk, etc) that will sync specific entities between models.

    Friday, September 7, 2012 7:13 PM
  • As Anthony points out, these do need to be in the same model to create the shared references. However, you can have more than one hierarchy in the model. Since you are looking at this as a hierarchy, then can we assume that a component is assembled on one and only one line? If that is the case, then you can:

    - create an entity for Factory

    - create a separate entity for Assembly Lines, where each line has a unique code (of course), name, and Factory lookup (DBA on Factory)

    - In the Component entity, create an "Assembly Line" attribute and make it a DBA referencing Assembly Lines.

    - Now you could create a derived hierarchy to report Components by Line or even Components by Factory.

    But... If these are already in separate models, you would need to essentially duplicate the Line info in your Components entity (boo), but then you might be able to export the data with subscription views and join the output for reporting.

    • Marked as answer by Elvis Long Thursday, September 13, 2012 1:06 AM
    Tuesday, September 11, 2012 4:40 PM