Re: Representing Key Constraints in UML based Conceptual Data Models



Re: Representing Key Constraints in UML based Conceptual Data Models

From: Pieter Van Gorp <pietervangorp_at_gmail.com>
Date: Mon, 4 May 2009 11:06:40 +0200
Message-ID: <15af5f050905040206y1043cfebxc3c36f25bcfa7c6d@mail.gmail.com>
Hi Stefano,

2009/5/2 Stefano Merenda <merenda@in.tum.de>:
> From my point of view such a constraint make sense since this use case is
> often needed.
Thanks for your interest.

> Nevertheless, the case you mentioned is a very special one
> since the multiplicity of 'user' and 'host' is exactly 1. If we introduce
> such a construct we have to think about the other cases:
> 1. What happens if the multiplicity is 0..1. Thus, are multiple null-values
> allowed?
Interesting question.  On
http://www.tek-tips.com/viewthread.cfm?qid=357630&page=5 one argues
that primary key columns should never be null according to SQL92 so we
could adopt this restriction too.  In the example that I presented it
also would not make sense to allow null values.  Does anybody have a
convincing counter-example?

> 2. What, if the upper limit is greater than 1, like 1..* ?
Could you please give an application example?  I have the feeling I
would never include to-many association ends in a key definition
(probably due to some database normalization rules).

> 3. What, if the elements can be ordered or contain duplicates?
1) Ordered: also an interesting case, but it is already supported by
the UML 1.5 AssociationEnd property 'ordered'.
2) Duplicates: in the context of keys, you are obviously *not* allowed
to have different elements with the same key values.  In a broader
context, imagine an entity does not have a key (when mapping it to a
relational database, you would add an object ID column/key implicity).
 I have checked several times before, and as far as I understand the
UML 1.5 spec, it prohibits duplicates... *but* the UML 1.5 spec does
not state explicitly whether this relates to equality by value or by
reference...  I assume it applies to "equal by reference" so in
general UML 1.5 allows you to have two entities with exactly the same
values stored in the same association.  This is compatible with the
approach of giving the entities an object ID column/key at the
database level.

I have once considered the use of a <<bag>> stereotype on association
ends to allow the same object to be stored multiple times in an
association but I have never needed it in practice yet... Perhaps
others do apply such a stereotype or perhaps UML 2 is different here?

> An interesting question is also how to map these general cases to SQL or
> Alloy in an easy way...
For me, the conclusion is that the to-one case was already general
enough and it can be mapped to other languages easily.  Do you agree?

Kind regards,
Pieter
Received on Mon 04 May 2009 - 10:06:45 BST