wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes parent/child Vs. component Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "parent/child Vs. component" Watch "parent/child Vs. component" New topic
Author

parent/child Vs. component

Sandeep Vaid
Ranch Hand

Joined: Feb 27, 2006
Posts: 390
In the book "Hibernate In Action"

They define Item -> Bid as one-to-many relationship WHILE
User -> Address as composition (component)

Why we can't make Bid as component of Item entity ?

What's the exact criteria for a class to become a component of other entity ?

As far as i have understood, the difference between a parent/child relationship and a component is that the in parent/child, child may be loaded individually or referenced directly by another entity while in component, it can't be shared (as it don't have its own identity).

Also on page 134 - It's mentioned :

A bid, for example, may be loaded and manipulated without retrieving the owning
item. It may be stored without storing the owning item at the same time. Furthermore,
we reference the same Bid instance in a second property of Item, the single
successfulBid (see figure 3.2, page 63).

In what scenario, Bid be loaded and manipulated without retrieving the owning item ?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Well the issue with bid, is that it is a many to one relationship with Item, so if can't be a component. Also, bid does have its own identity in its own database table. As a user I make bids, so bids is also related to User, but again not a part of User.

Also think of the distinction between Composition and Association in OO, it really is that same distinction.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Sandeep Vaid
Ranch Hand

Joined: Feb 27, 2006
Posts: 390
So Do you mean that we can have component(composition) when there is only one-to-one relationship. (User->Address)

and where there is one -> many relationship we need to use the collection of value-types instances.

Is my understanding correct ?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

No, composition is not a "one-to-one" relationship in the database, it most likely will be in the object world.

See, here is one of the mismatches that ORM tools try to resolve. In the object world we have associations and compositions (not even going to mention aggrevation er aggregation). There is no such concept in the database world, So we might have a database table that has user information including their address, but in the object world we want two seperate objects, a User object and an Address object, and Address is dependent on the User object being in existence, that is composition and what was being explained as a "component"

Hope that helps.

Mark
Sandeep Vaid
Ranch Hand

Joined: Feb 27, 2006
Posts: 390
Originally posted by Sandeep Vaid:
So Do you mean that we can have component(composition) when there is only one-to-one relationship. (User->Address)

and where there is one -> many relationship we need to use the collection of value-types instances.

Is my understanding correct ?


Mark, I know what you have explained. I think my original question didn't conveyed the meaning properly. I was talking in terms of Object Oriented terms only(and not database). Let me put my question in other words :

In OO, when we have 1-1 relationship between entities + one entity (User) is responsible for life-cycle of the other entity (Address) + The other entity(Address) is not shared, then this is the case of composition(component)
BUT
where there is one-to-many relationship between entities (e.q Item - Images) we can't use composition here (as entities don't have 1-1 relationship here), we need to use the collection of value-types instances.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Yep, that is eactly right, how you put it. For one-to-many it is a collection value-types.

Mark
 
 
subject: parent/child Vs. component