Book a Demo

Author Topic: Can the proposed foreign key be overruled?  (Read 14687 times)

PhilPess

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Can the proposed foreign key be overruled?
« on: May 29, 2015, 05:06:52 pm »
I have imported an OpenEdge (Progress) schema in EA v12 with ODBC. Now I'm creating different logical ERD models which correspond to the several functional modules in my back office application.
However I'm expieriencing problems when creating foreign keys. The primary keys of each table are also imported by the reverse engineering wizard. But I can only create foreign keys on the primary keys, which isn't correct in all cases. For example
Table A has a composite primary key of 3 fields and also has 2 generic columns, the functional meaning of the latter 2 depend on their given content.  In Table B there are 5 columns which should be used to compose the foreign key to table A. 3 Of the columns in TableB correspond to the columns in Table A (for example: TableA.LicenseId = TableB.LicenseId etc). The other 2 columns in Table B columns should be linked to the generic (non-primary key) columns in Table A. The column names of the corresponding columns don't match.
Now the foreign key dialog creates dummy columns with an asterix in Table A, and these columns can't be changed. I've a already tried several possible solutions like creating extra constraints, but nothing seems to work.
Probably there will be an easy solution for this common problem. Thanks in advance.  

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Can the proposed foreign key be overruled?
« Reply #1 on: May 29, 2015, 05:15:40 pm »
Phil,

I don't think you can use foreign keys for that.
AFAIK a foreign key always points to the primary key of another table.
W3schools seems to support that:
Quote
A FOREIGN KEY in one table points to a PRIMARY KEY in another table.

You should however be able to add a CHECK constraint to validate the value against a value in another table.
I have my doubts about such a design, but you may have your reasons. ;)

Geert