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 20:09:15 +0200
Message-ID: <15af5f050905041109o3c609acbna5b1acfd3588506c@mail.gmail.com>
Dear Jack,
my intention is not to make models that are only useful in a
relational database context.  In fact, the fragment that I presented
is part of a larger conceptual model that is mapped to CPN-ML models
as well.  Since the model is *also* mapped to a relational database
implementation, I can:
 - leave all key details hidden in the SQL implementation, or
 - represent the key constraints in a "non-UML based database model", or
 - enrich my UML models with some key information.  I think the latter
often makes sense, especially when only small annotations are required
to general purpose models (class diagram without key constraints).
Also note that since I am applying stereotypes and tagged values, I
can very easily slice away the database related annotations.

At what point do you find the modeling style I presented too
constrained to be mapped to a *non*-relational database?

Perhaps you are referring specifically to the remark about SQL92?  I
just mentioned that to bring in some established database concepts and
I am very interested in counter-examples:
>> In the example that I presented it
>> also would not make sense to allow null values.  Does anybody have a
>> convincing counter-example?

Thanks for your input,
and kind regards,
Pieter

On Mon, May 4, 2009 at 5:18 PM, Jack Ring <jring@amug.org> wrote:
> 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
Received on Mon 04 May 2009 - 19:09:21 BST