translate an entitiy relationship model to oo
hello,
i have a question concerning the translation of an entity relationship model to an object orientated model:
when i have two tables, e.g. "customer" and "contract", where the contract table has a foreign key "customerid" to take the 1:n relationship into account - how do i have to design my oo-classes?
usually i model two classes named identically giving them all the attributes the two database tables have. but what happens with the foreign key? which type has it? i thougt it must have a complex type, means the contract class gets something like this:
private Contract contract;
now i just read some topics in the j2ee tutorial where they take anotother way:
private String customerid;
which is the right way in good object orientated design? or is it that i can approch both ways?
thanks for help
olli
[875 byte] By [
Soopa] at [2007-9-28 15:30:56]
The approach you take will depend on the domain to some extent and the directionality of the relationship as well.
You can use an entity-Collection to represent a 1-many relationship:
// Many
public interface Customer
{
public Set getContracts();
}
// One
public interface Contract
{
public Customer getCustomer();
public void setCustomer(Customer customer);
}
where the Set would contain instances of Contract. Mutation of the collection may or may not be permitted depending on how clever you wanted your implementation to be - this would then have to update the Contract's customer field accordingly (and perhaps even remove the contract from its previous owner's collection!).
This is logically quite robust but can also be slightly heavyweight. Related entities need to be lazily loaded otherwise you could end up loading in an entire network of related entities at once.
If navigating across related entities isn't all that important to you then you could adapt this to store the primary keys of the related entities instead.
However, simplicity is usually a good idea so I would recommend opting for using an EJB container's object-relational mapping tools to provide you with a standard EJB (CMR) implementation from your schema.
Hope this helps.
First thing - bear in mind that you are dealing with two completely different paradigms. Mapping an ER diagram directly into a Class diagram is a recipe for disaster as far as OO design is concerned.
Case and point - your customerID example. In the DB world, FK references keep the tables linked together. But in the OO world you actually have object references. For example:
public class Customer {
private List contracts;
}
Or, alternatively:
public class Contract {
private Customer buyer;
}
In either case you would rely on a layer to translate the DB data into the related objects. Tools like this are called O/R mappers.
What you don't ever want to do is represent relationships between objects as attributes that identify the key for those objects. In those cases you will always have to 1) get the key for the related object, and then 2) go and get the related object. And once you have the related object, what do you do with it? How about if you change the related object (change the customer associated with a contract)? Do you update both the related object and the key value attribute?
There is a definite disconnect between the DB world and the OO world. If you try to impose one paradigm on the other you always pay a price. I'd recommend that you take a look at Scott Ambler's white paper on DB persistence. Here is the link:
http://www.ambysoft.com/persistenceLayer.html
thanks a lot..
well, the way you describe it is exactly the one I usualley take, it's just that I was wondering about the bmp examples in the sun j2ee tutorial, but I think there are lot's of things that are a bit differnt in the ejb world...
I'll take a look at the ambysoft side.
Soopa at 2007-7-12 12:22:59 >
