When LDM and PDM objects don't match up during compare and merge

When we use compare and merge to update the PDM from the LDM (within a single dm1 file), the attributes and columns don't always match up. I know we can force-match them, but we've found that they match up if we make sure that the 'physical name' on an attribute is the same as the actual name of the column.

This raises several points

  • what if we have one LDM and >1 PDM, where the two PDMs don't use the same naming standards, so the 'matching' columns have different names?
  • how does this name-matching relate to the presence or absence of 'where used' connections between the attributes and columns?
    • we have some examples where columns have a 'where used' link to an attribute, but the attribute doesn't have a link to the column - parhps this is down to the names not matching?
  • what's the best way to make sure attribute and column names match up?
    • please, don't ask me to write a macro - the mismatches are not the 'fault' of the user

BTW, we're still using XE4

  • Hi,

    I don't remember if this is available in XE4, but once you force match these objects together there is an option to save the matches.  On page 5 of the compare wizard you should see a checkbox that looks like this:


    If you check it and then click on the ... button you'll have the option to save the mappings. 

    Once you do that the next time you want to run a compare and merge, those matches you've forced should always match up.

    You can also modify the where used to match up the objects but this usually only works on models in the same dm1 file.

    Hopefully this answers some of your questions.  There isn't an easy way to match up columns in different models if  they don't have a "history" with each other (ie, merged or generated from a model). You have to do the force matching manually but this option  allows you to save those force matches so that at a later date you won't need to force match again.   



  • In reply to Stanley Chan:

    Thanks for the prompt reply, Stanley.

    We can force-match in XE4, but that doesn't always sort the problem out. There are some columns that have a where used link to the wrong attribute. For example column B links to attribute A, and attribute A doesn't link to any column. When we merge from the LDM to PDM, we force match atttribute A to column A. The next compare and merge works OK, but column B now has two where used links, to attribute B and to attribute A; there seems to be no way to get rid of the unwanted link.

    These two models are in the same dm1 file, and the PDM was generated from the LDM; I believe that the naming standards were applied to the PDM after it was generated. We're having difficulty making sure that the LDM and PDM stay in alignment. :(

    We're going to experiment wth generating aew PDM from the LDM, then merging that (carefully, and selectively) into the original PDM.
  • In reply to George McGeachie:

    What would be useful is a way to remove unwanted mappings from columns to attributes
  • In reply to George McGeachie:

    The C/M matching for entities is usually based on names. There are other types of matching that are checked first, like the presence of a universal or user-defined mapping, or if a denormalization mapping was applied to the physical table, but after those things are checked it goes based on owner+table name first, then table name, then entity name.

    Attributes/columns are similar but a bit more complicated. Simple cases like non-FK attributes and columns not involved in denormalization also check column names then attribute names. There's also an additional check for datatype if no other names are matched.

    When you have multiple physical models where the table/column names will necessarily be different than in the logical model, the best way to get good matching is to ensure the logical entity/attribute names are the same. There are several ways to make this happen:

    1) Enable logical name editing under Model Options for the physical model(s) and modify the names by hand for individual objects. Obviously this is only feasible for a small number of cases.
    2) Run the compare between the LDM and PDM but limit the compare to Entity Name and Attribute Name. Do force-matching as needed and then merge all into the physical model to update those logical names to match. (This might also tell you if logical name mismatching is the reason you're not getting the matching you expect.)
    3) Generate a new PDM from the LDM and work from that.

    As far as Where Used, it will always show name matches using a similar algorithm as the C/M uses in additional to objects mapped via universal or user-defined mappings. So if column B naturally matches attribute A because they share a logical name, that match will still show up in Where Used even if you save a mapping between column A and attribute A. The only way to get rid of it would be to change the logical names. There are also more complicated cases relating to FKs and denormalized physical objects that might not exactly fit that, but this is the basic idea.

    Finally, it's been a while since ER/Studio kept any kind of permanent history between objects created from each other. Instead, that history is kept indirectly primarily based on the logical and physical names and denorms. Changing those things can allow you to affect the links in C/M and Where Used to a point where the tool acts as though the objects were created together.
  • In reply to Jason H:

    Thanks for the detailed explanation, Stan. Unfortunately, it doesn't all fit the evidence I can see. We have a matching entity and table, with the following attributes and columns:

    Entity A
    Attribute - Name = Leaf Level (Column Name = Leaf_level)
    Attribute - Name = Leaf Organisation Unit Identifier (Column Name = Leaf Organisation Unit Identifier)

    Table A
    Column - Name = Leaf_Level (Attribute Name = Leaf Level)
    Column - Name = Leaf_ou_id (Column Name = Leaf_ou_id)

    In the client GUI, the Where Used for the "Leaf Level" attribute and column link to each other, as we would expect. The "org unit" column doesn't have any Where Used links, as we would expect, but there are two Where Used links we would NOT expect to see (these aren't user-defined or universal mappings):
    - from "Leaf_Level" column to the "Leaf Organisation Unit Identifier" attribute
    - from "Leaf Organisation Unit Identifier" attribute to the "Leaf_Level" column.

    For some reason, both of the attributes have universal mappings - to themselves. Perhaps somebody did this manually, but it seems unlikely. Over 700 LDM entities and attributes have Universal mappings to themselves. The PDM doesn't have any universal mappings.

    When we run Compare and Merge, we would expect the "Leaf Level" attribute and column to match up, but not the "org unit" ones. That's not what happens. During compare and merge, the match is shown as:

    Attribute "Leaf Organisation Unit Identifier" ------- Column "Leaf_Level".

    This appears to be due to the unexpected link from from "Leaf_Level" column to the "org unit" attribute. Even if I amend the "org unit" attribute and column names so they match up, it still provides this match:

    Attribute "Leaf Organisation Unit Identifier" ------- Column "Leaf_Level".

    In an attempt to correct this, I changed the column name on the "Leaf Level" attribute to an incorrect value, then ran compare and merge to:
    * force match the "leaf level" attribute and column
    * update the column name in the attribute

    In the next compare and merge, the attribute-column matching was as before.

    So, the next step was to change the column name on the "org" attribute to an incorrect value, then run compare and merge:
    * this time the two attribute and column pairs match up as expected

    The 'Where Used' entries haven't changed, they're still incorrect. :(

    So it looks like I need to make sure the attribute name in the PDM matches the attribute name in LDM.

    I think ER/Studio should connect via object ids in a 'generated objects' collection, instead of relying on all this name
    matching, it's too easy to break.
    It would also be great if the contents of the Where Used tab was split into several sub-tabs, for Data Flows, Generation, and Universal Mappings. Our model has a lot of data flows, and they all appear under 'Where Used' - so much clutter :).
  • In reply to Jason H:

    Sorry - thanks Jason (and Stan)