Re: simple trigger problem ?

From: Leonhard Zech <zech_at_knuut.de>
Date: 2000/05/08
Message-ID: <39171e1b$0$12359_at_personalnews.de.uu.net>#1/1


<rtproffitt_at_my-deja.com> schrieb im Newsbeitrag news:8f6ncn$cha$1_at_nnrp1.deja.com...
> Norab,
>
> It is not clear what your table relationship is....

I think, it is indeed not clear what the entity 'address' should express. An ADDRESS has in this context more than one role: - LOCATION (physical place)
- CONTACT (as a kind of relationship between the location and the customer).
Divide them iff both aspects are important enough to be part of the model world.
This results primary in a many-to-many-relation between the entity classes CUSTOMER and LOCATION.
The relationship between them (CONTACT) is a canditate for a entity because the relationship could be be fat (i.e. private contact vs. buisiness contact as a role of the contact). Transforming this to a database design leads to three tables: LOCATION: location_id, zip_code, city, ... CUSTOMER: customer_id, name, ...
CONTACT: customer_id, location_id, kind_of_contact ... What's left is an appropiate module design ...

> ...
> Weigh this against changing the design of the address table,
> and asking yourself...was there a good purpose in the
> beginning for the original design...

Denormalizing with a one-to-one-relationship between customer and address is an other possible solution if the location is not part of the model world.

Reverse the one-to-many-relationship (with an extra attribute expressing the role of the contact in the address), if the physical location is not part
of the model, but the role of the contact is.

With best regards:

Leonhard Zech
Software Engineer - IBM Certified Developer Hochsandstrasse 2a / D-67655 Kaiserslautern Received on Mon May 08 2000 - 00:00:00 CEST

Original text of this message