Author Topic: v16.1 - How to define NON-Foreign Key Constraint Associations between DB Tables  (Read 1007 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8509
  • Karma: +250/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Not every association between tables in a Database model is a Foreign Key Constraint.  In our case, we are exploring naming relationships between DB tables.  These associations relationships are (in our view) Associations (under a naming similarity/identity). 
There is a small checkbox at the bottom left of the Foreign Key Constraint dialog "[ ] Automatically show this screen when tables are joined"
However, this is a binary outcome - ALL or Nothing!  Either option is bad for us from user experience and modelling point of view.  Is there any way - using the Model Driven Technologies, we now have to tell EA that this Association is a Foreign Key Constraint while that Association is not?  In this way, we can declaratively make EA provide the dialog when needed and inhibit it when not!

TIA,
Paolo

(Not holding his breath)
« Last Edit: October 11, 2023, 12:04:53 am by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 12784
  • Karma: +533/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
I'm not aware of a way to do that. What we do is use a dependency to show relations that are not technically foreign keys.

In our case we have a database with little to no FK constraints. There are however relations between tables that could have been expressed as FK's. So we document those relations using dependencies.

Geert

PS. size 2 pixels is not readable for me.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8509
  • Karma: +250/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
PS. size 2 pixels is not readable for me.
Blame the Web site for that.  Normally, when this happens, I re-edit to fix what the site has corrupted.  I had to leave this time and couldn't fix it there and then.  It's now fixed.

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

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8509
  • Karma: +250/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
I'm not aware of a way to do that. What we do is use a dependency to show relations that are not technically foreign keys.

In our case we have a database with little to no FK constraints. There are, however, relations between tables that could have been expressed as FK's. So we document those relations using dependencies.

Geert
1) They are conceptually Associations,
2) if you make them Dependencies, then you don't have access to some of the properties that are only available these days for Associations.

We find the restriction of access to the full set of properties very constricting for our modelling.  Just as we can inhibit [  ]  Strict Connector Syntax, it would be cool to be able to [X] Access ALL Properties to allow all the underlying columns of the DB to be available to the modeller.

Paolo
« Last Edit: October 11, 2023, 12:04:38 am by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 12784
  • Karma: +533/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
We create these FK's that are not really FK's using a script. That might be the reason I haven't had any issues like you describe

Geert

Richard Freggi

  • EA User
  • **
  • Posts: 473
  • Karma: +18/-7
    • View Profile
It seems to me that you are describing a dependency between database objects.  Something that would be implemented via a trigger (eg if field x in table 1 is equal to a, then field y in table 2 must be equal to b).
Dependencies are use to model this kind of constraint (and also to model the source objects queried by views).

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8509
  • Karma: +250/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
It seems to me that you are describing a dependency between database objects.  Something that would be implemented via a trigger (eg if field x in table 1 is equal to a, then field y in table 2 must be equal to b).
Dependencies are used to model this kind of constraint (and also to model the source objects queried by views).
Hi Richard, are you referring to what Geert is discussing or my original thesis?

In our case, they are conceptually associations and work fine between all other types of items.  It's just when we try to create the same semantics between DB Tables, EA gets in the way...

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: 473
  • Karma: +18/-7
    • View Profile
It seems to me that you are describing a dependency between database objects.  Something that would be implemented via a trigger (eg if field x in table 1 is equal to a, then field y in table 2 must be equal to b).
Dependencies are used to model this kind of constraint (and also to model the source objects queried by views).
Hi Richard, are you referring to what Geert is discussing or my original thesis?

In our case, they are conceptually associations and work fine between all other types of items.  It's just when we try to create the same semantics between DB Tables, EA gets in the way...

Paolo

Was referring to OP

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8509
  • Karma: +250/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Hi Richard,
These relationships are not implementable (and are not designed to be).  These are relationships designed to inform the user of a potential (possibly abstract) association between the tables based on their name(s).  For example, this table's name includes that table's name.

Some of the relationships are bidirectional and thus cannot be dependencies.

As I mentioned, we use these relationships between all manner of items; it's only DB components (so far) where EA "gets in the way".

Paolo
« Last Edit: October 12, 2023, 11:47:49 pm by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!