You are confusing two different relationships here. Remember, order has two
relationships with adress:
'shipping address' and 'billing address'
I would have two 'relationship tables' joining Order to address:
OrderBillingAddressJoin and
OrderShippingAddressJoin
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Hemant Khandelwal
Sent: 13 November 2000 03:45
To: [EMAIL PROTECTED]
Subject: Re: EJB2.0 questions
I think considering billing address and shipping address relation of order
bean as "many to many" relationship at the database level is incorrect.
According to the proposed sheme of thing by Mr Bartek, the database schema
for Order bean and address will be like this :
Order Table : orderId + other fields
Address Table : addressId + other fields
OrderAddressJoin Table : fkOrderId, fkAddressId --> where fkOrderId and
fkAddressId are foreign keys to the two table.
Lets say orderId = o1 has billing address = ba1, and shipping address = sa1.
Accordingly database snapshot will be
Order Table
o1
Address Tbale
ba1
sa1
OrderAddressJoin Table
o1, ba1
o1, sa1
In such scenario, how will the persistence manager differentiate between a
shippingAddress (via getShippingAddress() ) and
billing address (via getBillingAddress) on the bean ?? There is no way to
differentiate the two type of address in any of the three tables .
A possible way is to have a type column in the address table to
differentiate between billing address and shipping address. But there is no
standard way to pass this information to the persistence manager.
But the question still remains....
What is the right way to model such a relation at the database level.
Regards,
Hemant
----- Original Message -----
From: "Bartek Kiepuszewski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 13, 2000 3:43 PM
Subject: Re: EJB2.0 questions
> [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".
===========================================================================
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".
===========================================================================
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".
