Hi Bartek,
Thanks for the reply.
I have some more questions :-)
>From the spec I gathered that a dependent object is
one whose life cycle and access is controlled by some
other object.
If we share dependent objects the way I discussed
early (Order having shipping address and billing
address, and customer and employee sharing address
object), isnt that the lifecycle and access is
controlled by more than one entity ??? Is it in
compliance with the true spirit of dependent object ?
Regards,
Thik
> [mailto:[EMAIL PROTECTED]]On Behalf Of thik
hai
>
> 1. The spec says that dependent object can be shared
> accross relationships. In section 9.4.6.2 example is
> given for an Address dependent object which is
shared
> by two relationships, billing address and shipping
> address form an Order Bean. Both these relationships
> are one to one.
> For such a scenario I was trying to do a database
> design. I will have two tables, one for Order bean
and
> one for storing addresses. Since address is a
> dependent, I will have PK of order table as Foreign
> key in address table.
>
> But for the above two relationship discussed, a
> possible database design will be :
>
> Order table having two Foreign Keys to address
table.
> One foreign key in order table will be for shipping
> address, and other foriegn key in order table for
> billing address.
>
> Order Table : orderID, billingAddressId,
> shippingAddressId.
>
> Address Table : AddressId.
>
> I think that at the database level it is rather a
poor
> design. If address is a dependent entity, it should
> contain the foregn key(OrderId) pointing to the PK
of
> order table.
>
> Can anyone suggest me where I am going wrong ????
The issue is, what is a cardinality of the
relationship
between the EJB and your dependent. In your example
you
have, as you have said, two one-to-one relationships
between order and address.
Clearly then relationship between order and address
is not one-to-one, it is actually "many-to-many", or
more precisely "two-to-two".
(i.e. one order can reference more than one address,
when billing and shipping addresses are different and
one address can be referenced by more than one
order, when for example it is used as a shipping
address
on order 1 and billing address on order 2)
For your database design you should then use the
guidelines for many-to-many relationship, not
one-to-one.
In this case you have two options - the first one is
what you have just indicated. The second would involve
a third table storing the relationships.
Regs, Bartek
----------
Bartek Kiepuszewski
Technology Architect
Mincom Limited
--
This transmission is for the intended addressee only
and is confidential
information. If you have received this
transmission in error, please
delete it and notify the sender. The contents of
this e-mail are the
opinion of the writer only and are not endorsed by
Mincom Limited unless
expressly stated otherwise.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED]
and include in the body
of the message "signoff EJB-INTEREST". For general
help, send email to
[EMAIL PROTECTED] and include in the body of the
message "help".
__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
