Book a Demo

Author Topic: DB relationships vs UML Associations  (Read 5679 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
DB relationships vs UML Associations
« on: October 19, 2006, 01:30:53 am »
EA handles Data Modelling using a Rational/IBM de facto standard. There is an RFP which has now closed for an OMG specification: [size=13]ab/05-12-02 (Information Management Metamodel (IMM) RFP)[/size]. The EA approach is documented in: [size=13]Database Modeling in UML[/size].

Apart from some bugs - which are just defects in implementation not conceptual problems - the way in which EA has implemented Data Modelling is adequate. An example of such a bug can be found at: [size=13]Bug: DB Relationship Roles[/size]

However, there are some consequences of this implementation that may not be obvious to the casual observer (Me... :D).

Normally, in UML we have the concept that "a named navigable AssociationEnd is an Attribute" [size=10](my emphasis)[/size]. As I point out in: [size=13]BUG: Attribute/AssociationEnd NOT paired[/size], this means that the Target Roles are (the names of) the Source Class' Attributes... (and vice versa...)

However, in EA if the class is stereotyped as «table», this isn't the case.  If the table is the target, for the target role you get a list of the target's unique indexes (including the primary key) only. (Actually you get the names of the appropriately stereotyped operations). If the table is the source, for the source role you should only get the source's defined foreign key constraints.

Now this is as it should be - as per generally accepted data modelling practice. But it isn't standard UML. So be careful!

(Try adding/removing the «table» stereotype and observe the changes in EA's behaviour. Again, I stress this is as it should be - but needs some getting used to...)

As a safeguard, I recommend that you explicitly use one of the two available Data Modelling notations (IDEF1X or Information Engineering) for the inter-table relationships. This can be done via the Diagram Properties dialog. This will alert the user that the behaviour of the Roles will be different!

However, as I point out in: [size=13]Mixed connector notation on diagrams[/size] we will increasingly be mixing association types on the same diagram and will need to be able to alert the user as to the different behaviours by individually assigning the rendering.

HTH,
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
« Last Edit: October 19, 2006, 01:31:16 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Owl Saver

  • EA User
  • **
  • Posts: 37
  • Karma: +0/-0
  • Never give up.
    • View Profile
Re: DB relationships vs UML Associations
« Reply #1 on: October 24, 2006, 08:56:34 pm »
This is a very important topic to me. I expect it is to many people since almost every system built today has a tleast a small database component. Here are some things I would like to see:

-Full support for defining a Domain model and then using transforms to generate the data model and the class model. I currently have an issue with multiple relationships between two Classes.

-Support for both logical and physical names.

-Support for moving data between the database and the runtime classes.

-I still beleive that the long term solution is a full Object Oriented database.

Take Care