Book a Demo

Author Topic: EA not updating Foreign Key when the PK is changed?  (Read 4140 times)

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
EA not updating Foreign Key when the PK is changed?
« on: March 19, 2019, 01:39:08 am »
Using Data Modeling MDG it seems that if I change the PK name or I change the parent PK to another attribute, nothing happens to the child FK... it just retains the attribute and datatype of when the relationship was first created.  I have to change the FK manually using the relationship editor.  Is this normal or is there a better way?  EA 13 professional... don't have the (expensive) data modeling version of EA (I don't know if it would make any difference?). 
If FKs do not auto update, I'll try something else for data modeling.  Thanks for any advice!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: EA not updating Foreign Key when the PK is changed?
« Reply #1 on: March 19, 2019, 02:35:49 am »
I would expect that to be the normal behavior yes, regardless of the edition.

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA not updating Foreign Key when the PK is changed?
« Reply #2 on: March 19, 2019, 03:59:03 am »
Using Data Modeling MDG it seems that if I change the PK name or I change the parent PK to another attribute, nothing happens to the child FK... it just retains the attribute and datatype of when the relationship was first created.  I have to change the FK manually using the relationship editor.  Is this normal or is there a better way?  EA 13 professional... don't have the (expensive) data modelling version of EA (I don't know if it would make any difference?). 
If FKs do not auto update, I'll try something else for data modelling.  Thanks for any advice!
Just to clarify Richard, the Foreign Key is not a Key, but a Foreign Key Constraint.  So which PK are you talking about?  The one in the same table as the FKC or the one on the (foreign) table referred to by the FKC?

In the former case, the two concepts have no relationship to each other and in the latter case, the constraint only has to point to a unique key in the referenced table.  So long as changing the PK on the foreign table does not change that constraint, then as Geert says, the behaviour you see is the correct behaviour.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
Re: EA not updating Foreign Key when the PK is changed?
« Reply #3 on: March 19, 2019, 12:14:39 pm »
As Paolo says... 2nd case.  Changes in PK of parent entity should be automatically reflected in the child entity FK.  If they are not, then the child table FK is wrong.  I guess EA won't be my data modeling solution.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA not updating Foreign Key when the PK is changed?
« Reply #4 on: March 19, 2019, 01:59:04 pm »
As Paolo says... 2nd case.  Changes in PK of parent entity should be automatically reflected in the child entity FK.  If they are not, then the child table FK is wrong.  I guess EA won't be my data modeling solution.
I don't think that's what I said. I certainly didn't mean it that way.

If the primary key attribute of the foreign table is PART of the Foreign key constraint, AND the foreign key constraint retains its uniqueness property, and you make another attribute in the foreign table the primary key, the FKC should NOT change (since all the properties of the FKC remain intact).

The decision to change the primary key of the foreign table (to another attribute) AND THEN link the FKC in the child table to the new attribute in the foreign table is a design decision you need to make manually.  The only time it is forced on you is when moving the primary key destroys the uniqueness constraint on the inversion key in the foreign table.

Does that make it clearer?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!