Am 27.03.2007, 11:29 Uhr, schrieb nett .by <[EMAIL PROTECTED]>:
Hi!
Thanks Kai for correction but some points:
When designing a n:m-relation this approach doesn't work. You need
a third table between the two that have been modelled.
Yes, i know it, but it is just a problem of realization. For example, for
this case after defining
Many-to-many relation, the user can define in properties a table, which
can
be a "third table", or leave the
name which will be suggest by the application.
I think a better way would be an association class for n:m-relations. Then
you cannot just say "build a table C between A and B" but you can say
"build
a table C with attributes C1 INTEGER NOT NULL, C2 VARCHAR(100) ... with
primary key PK1(C1, ...) between A and B". So you would have much more
control over it. Of course there can be a "standard" table which will be
generated by the application if no association class exists.
And one more time about ERD. I see it like a graphical representation of
a
data model of an application. Having the possibility
of creating ERD, the user can see the db structure of the application.
And
having special stereotype in a class diagram, the user can
see what classes are entities.
The data model of an application is a class diagram. Everything that can be
modelled whith an entity relationsip diagram can also be modelled by a
class
diagramm - with special stereotypes for classes and attributes and
whatever.
An entity relationship diagram is not describing the structure of the
under-
lying database very well. For this purpose the relational model (if it is a
relational database) which can be created out of an ERD (with some basic
rules) really fits better.
Having only special stereotype in a class diagram can make many problems
and
can be not very flexible to use because imagine you
have an entity which has fields, that are not storing in the db, so you
need
to have an ability to define columns, and you will do it in a Class
diagram.
I think it is a wrong way.
I'm not sure if I understood you correct. If you have fields in an entity
that should NOT be stored in the database - why do you have them modelled
anyway?
By having ERD you just connect classes in Class Diagram to Entities in
ERD,
and in ERD you define everything you need for db.
IMHO it is more flexible and appear to be a better solution.
What do you think about it?
I think it is a good idea of having one model that the application is
based on (the domain model) and another one the database is based on.
One problem of this approach is of course the synchronization between
them.
Perhaps you can have a look at
http://argouml-sql.tigris.org/
and at the profile from Scott W. Ambler (is linked on the mapping page).
My documentation is quite poor at the moment, but perhaps you get an
idea of what I'm doing. Currently argouml-sql generates DDL statements
out of a relational model (but is not finished yet - so only the sources
can be downloaded).
Kai
On 3/27/07, Kai Drahmann <[EMAIL PROTECTED]> wrote:
Hi,
I'm currently working on argouml-sql. Since I had the same ideas (and
made some mistakes) when beginning I think I need to correct some
points: (see below)
Am 25.03.2007, 14:10 Uhr, schrieb nett .by <[EMAIL PROTECTED]>:
> Hi Linus!
>
> I will try to describe my idea with more particular:
>
> Entity Relationship Diagram (ERD) is a type of diagram, where you
> describe
> the db structure:
> -Every entity in this diagram is a separate table in db
When designing a n:m-relation this approach doesn't work. You need
a third table between the two that have been modelled.
> -In every entity you can specify columns and types of columns
> -You can define primary keys and foreign keys
Foreign keys are not part of an entity relationship diagram. They
occur in relational models.
> -You also can specify One-to-One, One-to-Many or Many-to-Many
> Relationships between entities
When modelling an ERD you can do it. When modelling a relational
model n:m-relations simply don't exist.
There are three types of data models:
1. Conceptual model - entity relationship diagram for example
2. Logical model - relational model or network model for example
3. Physical model - model used by DBMS for data storage - contains
indices for example
As Tom Morris stated in another post an UML class diagramm corresponds
to an entity relationship diagram - the only difference is that another
notation is used.
Kai
> -etc.
>
> After creating Entity Relationship Diagram you can generate db by
> choosing
> db type (additionally indicate or load driver for this db).
> You also can reverse existing db into ERD by connecting to db,
choosing
> db
> tables and represent them in ERD.
>
> One more very good feature, i think, will be the generation of class
> diagram
> from ERD, or generating ERD from class diagram.
> This will help to accelerate the application development which use
data
> bases.
--
Müritz COMP Greifswald Computersystemhaus GmbH
An der Jungfernwiese 2
17489 Greifswald
Registergericht: Amtsgericht Stralsund
Registernummer: HRB 4035
Geschäftsführer: Alexander Lang, Torsten Marx
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Müritz COMP Greifswald Computersystemhaus GmbH
An der Jungfernwiese 2
17489 Greifswald
Registergericht: Amtsgericht Stralsund
Registernummer: HRB 4035
Geschäftsführer: Alexander Lang, Torsten Marx
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
