Toad World® Forums

2 questions from a customer


#1
  1.                       When a definition is assigned to a PK attribute (either in notes or comments), and a relationship is established to a child entity, the PK migrates as expected, but the definition does not.  Is this behavior correct?  If so, is there a planned enhancement to enable this functionality?2.                           When assigning role names to child attributes, I have not found a way to have the physical view of the child entity display the correct column name (and data type) – the tool always displays the migrated attribute name in the physical view.  See steps below to replicate this behavior:a.   Create an entity: AP_INVOICES_ALL with the attribute INVOICE_ID (data type number) as the primary key.  b.   Create an entity: AP_INVOICE_DISTRIBUTIONS_ALL with the attribute DISTRIBUTION_LINE_NUMBER (data type number) as the primary key.  c.   Create an entity: PA_COST_DISTRIBUTION_LINES_ALL (no primary key is required for this exercise).d.   Create an identifying relationship between AP_INVOICES_ALL and AP_INVOICE_DISTRIBUTIONS_ALL.  Observe that the PK migrates as expected, and that AP_INVOICES_ALL now has a compound PK.e.   Create a non-identifying relationship between AP_INVOICE_DISTRIBUTIONS_ALL and PA_COST_DISTRIBUTION_LINES_ALL.  Observe the PK migration (INVOICE_ID and DISTRIBUTION_LINE_NUMBER).f.     The desired role names in PA_COST_DISTRIBUTION_LINES_ALL are INVOICE_ID = SYSTEM_REFERENCE2 (data type varchar2 (30)) and DISTRIBUTION_LINE_NUMBER = SYSTEM_REFERENCE3 (data type varchar2 (30)).  g.   **The problem:**  The physical view of PA_COST_DISTRIBUTION_LINES_ALL should clearly show the data types for SYSTEM_REFERENCE2 and SYSTEM_REFERENCE3 as varchar2 (30).  Although I have found a way to display the role name relating the migrated foreign keys to the proper attributes, the physical view of PA_COST_DISTRIBUTION_LINES_ALL shows the column names as the same as the migrated foreign keys, which is INCORRECT.  Furthermore, the data types of the migrated foreign keys depict their origin, and cannot be changed to the correct type.  I can change the column names of in PA_COST_DISTRIBUTION_LINES_ALL to the correct names, but in so doing, I lose the role name relationship to the migrated primary keys.
    

Thanks,

John


#2

Hi John,

  1. Descriptions and Notes belong to PK attribute only and don’t migrate intentionally. Users should be able to write different descriptions/notes to PK and FK attributes. In other words, notes related to PK attribute in parent table are just for the PK attribute. Notes to FK attribute in child table are just for the FK attribute. The same works for descriptions. Migration of notes and descriptions is not planned, but I am sure we can write a small script that will get PK descriptions and notes and put them to appropriate FK attributes.

  2. I created a model that fits your requirements. In general, TDM populates PK and PFK to child entities automatically and the data types are in majority of cases identical (exceptions exist, but that’s a little bit off-topic). If you wish to use different data types for PK and FK attributes, then you will have to create new attributes with the desired names and data types, create a new relationship and remap foreign keys then from the newly added attributes to existing attributes (edit relationship, on tab Foreign keys select FK attribute and press F2, select existing attribute then and confirm changes). See the two attached pictures, please.

I hope I undestood your need well. If not, please don’t hesitate to write me back.

Regards,

Vaclav


#3

Hi John,

  1. Descriptions and Notes belong to PK attribute only and don’t migrate intentionally. Users should be able to write different descriptions/notes to PK and FK attributes. In other words, notes related to PK attribute in parent table are just for the PK attribute. Notes to FK attribute in child table are just for the FK attribute. The same works for descriptions. Migration of notes and descriptions is not planned, but I am sure we can write a small script that will get PK descriptions and notes and put them to appropriate FK attributes.

  2. I created a model that fits your requirements. In general, TDM populates PK and PFK to child entities automatically and the data types are in majority of cases identical (exceptions exist, but that’s a little bit off-topic). If you wish to use different data types for PK and FK attributes, then you will have to create new attributes with the desired names and data types, create a new relationship and remap foreign keys then from the newly added attributes to existing attributes (edit relationship, on tab Foreign keys select FK attribute and press F2, select existing attribute then and confirm changes). See the two attached pictures, please.

I hope I undestood your need well. If not, please don’t hesitate to write me back.

Regards,

Vaclav


#4

Thanks very much for your prompt response Vaclav.

I have replied to the customer inviting him to join our community.

John