Specialization, inherited attributes and attribute aliasing

[Modesto Vega]

I'll try to come up with a meaningful example but it will take time. We definitely no modelling twice, just adding more detail to the model to remove ambiguity. These diagrams, https://i0.wp.com/bellekens.com/wp-content/uploads/2011/08/assocciationsandattributesmeta2.png?resize=600%2C567&ssl=1 and https://imgur.com/a/EfDjMpQ, are high level designs, they are very conceptual, there are many ways to implement them. Sparx Systems has chosen a particular implementation, it may have some annoying idiosyncrasies but it is not a bad implementation.

I am certainly not proposing to have all attributes in high level diagrams like those but that level of detail may be necessary in more detailed diagrams.

By the way, since you are setting cardinality, you are using some of the functionality provided by this feature. You are just not using the functionality that allows you to set class attributes as MemberEnd properties of associations.

[Paolo F Cantoni]

By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.


Paolo

[Geert Bellekens]

By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.


Paolo

Yes, but they use yet another mechanism to model that.

Geert

[qwerty]

By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.


Paolo

No. The foreign key is some attribute which refers to another class (table) and it will be the name of the column. Just the name of the key in the external table would be needed. That could be modeled with a stereotyped association end that has stereotype properties like isForeignKey and nameOfForeignKey (since linking to attributes is not possible with UML). But definitely you don't need the foreign key twice.

q.

[Modesto Vega]

By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.


Paolo

Exactly, and I would read this post in conjunction with by other post "Overlaying configurable business logic into a physical data model" (https://sparxsystems.com/forums/smf/index.php/topic,46496.0.html). They are 2 facets of the same problem. But explain it could be a very long story.

[SNIP]
No. The foreign key is some attribute which refers to another class (table) and it will be the name of the column. Just the name of the key in the external table would be needed. That could be modeled with a stereotyped association end that has stereotype properties like isForeignKey and nameOfForeignKey (since linking to attributes is not possible with UML). But definitely you don't need the foreign key twice.

In a nutshell, yes. But Sparx implementation is (unfortunately) much more complicated than just that. A Foreign Key, or FK to follow Sparx's own language, is both a relationship (specifically, an Association stereotyped as FK) and a type of Constraint (also stereotyped as FK). In turn, constraints are a type of Operation. Of course, operations do not have an independent existence, they are an operation of a class.
The ends of the association representing a (physical) foreign key must be constraints (not columns), one constraint must be unique index, which is also modelled as an operation, and the other an operation stereotyped as FK. The result is that it is impossible to draw an FK association without using these 2 types of operations. If you attempt to draw an FK association without having an FK operation in the target end, Sparx will create it for you, thus altering the structure of your table. Whoever, thought about this approach had not reversed engineered too many databases where the business logic is configurable and, therefore, do not have foreign keys.

Health disclaimer: Although related, this is not the reason why I wrote this post.

 

[Paolo F Cantoni]

Use the right terms and you'll be able to better understand things.

(It only took me thirty years to realise I'd been using the wrong term all that time!)

HTH,
Paolo

[qwerty]

May I ask which term? (But in general I know what you mean)

q.

[Paolo F Cantoni]

May I ask which term? (But in general, I know what you mean)

q.

Just to be clear the correct term is Foreign Key Constraint!  As such. there is NO requirement that the name of the constraint bears any relationship to the (possibly many) attributes that comprise it^[1].

They are correctly named as Foreign Key Constraints because they are a constraint on the origin table that the values of the attribute(s) in the origin table must be the values of a uniqueness constraint (typically implemented as a primary or alternate key) of the destination table.  There is no requirement that the origin attributes be a key in the origin table, although Inversion Indexes (NOT Keys) are often implemented to make it easy to traverse joins from the destination to the origin table across the Foreign Key Constraint.

Hopefully, that should settle the matter.

Paolo

^[1] Indeed, many RDBMSs generate random names for them.