As long as different instance of one class don't share the same address in
the same relationship, I would go with Bartek's suggestion.
To illustrate: if two instances of the Order class have a 'shipping address'
relationship with the same instance of the Address class then the Address
class definitely is not an example of a 'dependant object'. But if the
Address class only occurs in relationships where an instance of the
containing class never shares instances of the Address class, then you have
a text book 'dependant object'. In short: Look at all the relationships, but
look at them one by one to determine dependance.
But I understand your unease. I think the confusion is caused by the term
'dependant OBJECT'. How about 'dependant CLASS'? A dependant class would
then be a CLASS that only occurs in <UML>compositions</UML>, never in
<UML>shared aggregations</UML>.
Just to refresh you memeory, here is the quote from the spec, and it does
not use the term 'class' once!
"A dependent object can be characterized as follows. An object D is a
dependent object, if D is created
by another object, if D can only be accessed through another object (and not
remotely), and if D's exist-ence
or removal is dependent on some other object: in other words, if D's
lifecycle is managed by some
other object."
How's this for a definition:
"A dependent class can be characterized as follows. A class D is a dependent
class, if D only occurs in relationships where it
is instantiated by an instance of the containing class, if D can only be
accessed through the same instance of the containing class(and not
remotely), and if the lifecycle of an instance of D is always managed by the
same instance of some containing class."
Just an idea...
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Thik Hain
Sent: 13 November 2000 06:45
To: [EMAIL PROTECTED]
Subject:
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".
===========================================================================
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".
