Author Topic: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints  (Read 394 times)

BruceTOGAF2

  • EA User
  • **
  • Posts: 74
  • Karma: +0/-0
    • View Profile
In Sparx we use UML Class notation to build Logical Data Models to form the basis of a Physical Data Model. We use the Relationship connector to show cardinality.  How can we use Sparx UML Class notation to (1) identify Foreign Key Constraints (2) indicate that 2 combined attributes form the Combined Primary Key ?

Richard Freggi

  • EA User
  • **
  • Posts: 306
  • Karma: +11/-5
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #1 on: September 02, 2020, 07:19:24 pm »
I just set the *package* type as data model and <<table>> as class stereotype.  Then on the attribute submenu (columns) you get to choose PK and FK separately, and if it's a foreign PK (identifying relationship) if will show as pfK in the diagram!

Modesto Vega

  • EA User
  • **
  • Posts: 527
  • Karma: +14/-7
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #2 on: September 03, 2020, 11:02:09 pm »
I just set the *package* type as data model and <<table>> as class stereotype.  Then on the attribute submenu (columns) you get to choose PK and FK separately, and if it's a foreign PK (identifying relationship) if will show as pfK in the diagram!
The problem with this approach is that it is not a logical data model any more, it is not technology neutral. As I mentioned several times in the forum <<table>> is intended for physical data models - i.e., technology centric data models.


Bruce, you could use an attribute stereotype in both cases. My suggestion is to modify your UML profile and extend the attribute by creating a Foreign Key stereotype and a Composite Key stereotype.

Richard Freggi

  • EA User
  • **
  • Posts: 306
  • Karma: +11/-5
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #3 on: September 04, 2020, 12:19:06 am »
You can just ignore the database type and column datatype and you can hide datatype in diagrams to get a perfectly good conceptual or logical level data model.  It's a small kludge but never created problems for me.

Modesto Vega

  • EA User
  • **
  • Posts: 527
  • Karma: +14/-7
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #4 on: September 04, 2020, 01:36:34 am »
You can just ignore the database type and column datatype and you can hide datatype in diagrams to get a perfectly good conceptual or logical level data model.  It's a small kludge but never created problems for me.
When you are a one man show, you may be able to ignore it. When you have a team of architects with strong personalities trying to collaborate, ignoring it becomes a policing activity.

The best way to police something is to prevent it and not to enforce it.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7418
  • Karma: +176/-120
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #5 on: September 04, 2020, 08:26:37 am »
Just to "muddy the waters".  We have done away with Logical Models.  We only have Conceptual and Physical models.  (Taking our lead from ISO 11179)

As Modesto has said, the physical (Database Design) data modelling items in EA are just that!  We have learned (see my previous posts) from Sparxian Eve that they are hardcoded.  Consequently, they can't be used meaningfully for anything other than physical design.

We took the view that the notion that conceptual models "don't have attributes" as totally specious and NOT in accord with what we see around us.  We took the view that the attribute may or may not be rendered as required by the audience for the diagram (view).

We have conceptual datatypes and we have a special relationship "«AssociationEnd»" that corresponds to a unary association.  This requires that the destination end (corresponding to the destination end of the FK association) attribute value be used to identify the origin end.  The semantics of the relationship is "<destination> associatively identifies <origin>".  This maps directly to an «FK» relationship in the physical model.

We haven't looked back since.

Interestingly, while we don't have logical models, we DO have logical datatypes!  These are used as supplemental properties on the attributes/columns to allow consistent mapping between the conceptual and physical datatypes.

Just some thoughts (that work).

Paolo
« Last Edit: September 04, 2020, 08:30:18 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: 10438
  • Karma: +343/-30
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #6 on: September 04, 2020, 02:33:00 pm »
Just to "muddy the waters".  We have done away with Logical Models.  We only have Conceptual and Physical models.  (Taking our lead from ISO 11179)
That's funny, at one of my clients they actually removed the conceptual data model and only kept the logical data model.

The main reason was that the the line separating the conceptual and logical data model had become too thin, and it was not worth maintaining two models that were this close to each other in terms of abstraction.

Nobody really feels the need here for a more abstract conceptual data model.

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7418
  • Karma: +176/-120
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML Class Notatation, Combined Primary Keys and Foreign Key Constraints
« Reply #7 on: September 04, 2020, 05:03:19 pm »
Just to "muddy the waters".  We have done away with Logical Models.  We only have Conceptual and Physical models.  (Taking our lead from ISO 11179)
That's funny, at one of my clients they actually removed the conceptual data model and only kept the logical data model.

The main reason was that the line separating the conceptual and logical data model had become too thin, and it was not worth maintaining two models that were this close to each other in terms of abstraction.

Nobody really feels the need here for a more abstract conceptual data model.

Geert
Well, it's really physical vs non-physical.  I agree the distinction becomes irrelevant.  However, we DID take the view that a "Concrete Conceptual Model"[1]  (An oxymoron?  ;) ) is closer to reality than a "classical Logical Model".  By retaining the logical datatypes, we still maintain the linkage between the models as I mentioned.

Paolo

[1] The Conceptual Model is concrete in the sense that it models real objects in the domain.   As you may recall, we have an Ontological model to deal with the meaning of things and terms etc.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Modesto Vega

  • EA User
  • **
  • Posts: 527
  • Karma: +14/-7
    • View Profile
Re: UML Class Notation, Combined Primary Keys and Foreign Key Constraints
« Reply #8 on: September 04, 2020, 06:02:30 pm »
Depending on the "business needs", I have done any combination of the  following with Sparx:

Conceptual data models (without attributes)Using class notation
Conceptual data models (with attributes)[1]Using a) class notation, b) a canonical language[2], and c) solving many-to-many relationships
Logical Data Models[3]Using a) class notation, and b) a canonical language[2]
Physical Data ModelsUsing <<table>> - i.e, Sparx physical data modelling capability

[1]Typically this has being a way of 1) adding to detail to data requirements expressed through Conceptual Data Models or 2) addressing a very specific and peculiar need expressed by the development team. When the later, as Paolo described, the models were rendered with out without attributes depending of the audience and conceptual data models without attributes were not done.
[2]The canonical language is created using Sparx and set as the default package language.
[3]When done in conjuction with conceptual data models with attributes, they tended to be the output of a bottom up approach - i.e., transformed physical data models.