Re: erd to db

Hello,

First of all, thank to everyone to answer to my question.

for ERD from dia (http://www.lysator.liu.se/~alla/dia/) it support the following properties for which items is belong:

• Entity: 1- weak: true/false
• Relationship: 1- left_card: (string parameter so I can write everything I want: 1, 0, M, N, (1,0), etc.), I choose {1 or M or N} 2- right_card: same as left_card (see above) 3- identifying: true/false
• Participation 1- total: true/false
• Attributs: 1- key: true/false 2- weak_key: true/false 3- derived: true/false 4- multivalued: true/false

So, if it could help you to understand the formalism it will help you to answer to my question.

In advance thank you for your help

Yves

--
Yves Guerin
CUSM-MUHC
Groupe Interfaces
Montreal - Canada
"Jan Hidders" <hidders_at_uia.ua.ac.be> wrote in message
news:3c9f3132$1_at_news.uia.ac.be...


> "Yves Guerin" <yves.guerin_at_muhc.mcgill.ca> wrote in message


> news:nDGm8.10802$R8.275980_at_carnaval.risq.qc.ca...

> >

> > Thank you for your help.  In fact I am coding a software to do the

mapping


> > from Dia (ER) (http://www.lysator.liu.se/~alla/dia/) to postgreSQL (SQL

> > statement to create my tables) and I try to find out the method or the


> > concept behind the Dia ER plugin.

>

> Are you sure it exists? Usually drawing programs try to incorporate as

much


> concepts as possible to accomodate as many ER techniques as possible. If


you


> give a list of the concepts it supports then perhaps we can help you.


>

> >  I used to play with Merisse ER, and I try

> > to find on the Internet the concept of mapping ER to relational database

> > without a true success (the explanation depends of the writer, so I get

> many

> > different versions).

>

> That is only going to get worse if you are going to ask opinions here. :-)

> The problem is that this mapping involves certain implementation decisions

> and may depend upon details that are not in the diagram. In your case I

> would make the mapping as straightforward as possible so that the

> relationship between the ER model and the tables is as simple as possible.

> So I would choose to map every relationship (type) and every entity (type)

> to one table. That's easier for the user to understand, and easier for you

> to implement. :-)

>

> You asked for references. I have taught from Date, Elmasri/Navathe and

> Ullman/Widom ("A First Course in Database Systems") and liked all of those

> with a light preference for the last one. The basics are pretty

> straightfoward and the same everywhere:

> - entity type -> table

> - M:N relationship  -> table

>

> But then things get hairy:

> - 1:N relationship -> foreign key on N-side or separate table? What if the

> relationship has attributes?

> - ISA relationship -> ... several options here ...

> - weak entity types -> table for the weak relationship or foreign key in

> table for weak entity?

>

> et cetera ...

>

> Kind regards,

>

> -- Jan Hidders

>

>