Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on October 09, 2023, 05:19:03 pm
-
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)
-
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.
-
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
-
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
-
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
-
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).
-
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
-
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
-
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