Re: Representing Key Constraints in UML based Conceptual Data Models



Re: Representing Key Constraints in UML based Conceptual Data Models

From: Jack Ring <jring_at_amug.org>
Date: Mon, 4 May 2009 08:18:45 -0700
Message-ID: <DE5BDB2299B84DB88421399E32E72C1A@OfficeDell>
It appears that the options for modeling a system are constrained by the 
presumption of a relational data base and SQL.  Why such constraint?
Jack Ring
----- Original Message ----- 
From: "Pieter Van Gorp" <pietervangorp@gmail.com>
To: <puml-list@cs.york.ac.uk>
Sent: Monday, May 04, 2009 2:06 AM
Subject: Re: Representing Key Constraints in UML based Conceptual Data 
Models


> 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
>
>
>
> To remove yourself from this list please mail 
> puml-list-request@cs.york.ac.uk
> with a message containing the word "unsubscribe".
> 
Received on Mon 04 May 2009 - 16:19:10 BST