Extreme Programming - Object Inheritance---a must have feature..

Author

Object Inheritance---a must have feature..

camie_syrus@yahoo.com

2005-03-18, 8:56 am

As you already know, a very important aspect of object-oriented
programming is inheritance. However, relational databases do not
automatically provide inheritance in the relational model. Is there any
O/R mapping tools available which provide this facility?

....
Camie

Phlip

2005-03-18, 3:57 pm

camie_syrus wrote:

> As you already know, a very important aspect of object-oriented
> programming is inheritance. However, relational databases do not
> automatically provide inheritance in the relational model. Is there any
> O/R mapping tools available which provide this facility?

This newsgroup's topic is Extreme Programming. I suspect OR mapping layers
are out of fashion here.

But what behavior do you expect your database to provide if it could inherit
its records?

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Steve Jorgensen

2005-03-18, 3:57 pm

On 18 Mar 2005 03:08:22 -0800, camie_syrus@yahoo.com wrote:

>As you already know, a very important aspect of object-oriented
>programming is inheritance. However, relational databases do not
>automatically provide inheritance in the relational model. Is there any
>O/R mapping tools available which provide this facility?
>
>...
>Camie

Believe it or not, there is a concept in purely relational database modeling
called subclassing. The way subclassing is implemented is by having a base
class table with the common attributes, and one or more (usually at least 2)
other tables that have a 1-to-1 relationship to the base class table, plus
additional attributes that apply to the subclass. Sometimes, the base class
table has nothing more than an ID field, and perhaps, a type attribute to say
which subclass applies, because all the common aspects of the base class
belong to detail tables that work by pointing to the base class.

Anyway, I'm not yet any expert on O/R mapping, but at first glance, it looks
to me like Hibernate is quite capable of mapping an inheritance hierarchy to
an O/R subclassing hierarchy as described above.

Relational subclass hierarchy example:

party
* party_id (possibly auto-generated)
party_type (1=person, 2=organization)

person
* party_id (inherited from party - FK to party.party_id)
first_name
last_name

organization
* party_id (inherited from party - FK to party.party_id)
organization_name

address
* address_id
mailing_name
address1
address2
country_id
country_subdivision_id
city_id
postal_code

party_address
* party_id
* address_id

organization_member
* party_id_organization (FK to organization.party_id)
* party_id_person (FK to person.party_id)

jgrigg@mo.net

2005-03-20, 3:57 am

> --- camie_syrus@yahoo.com wrote:
any[color=darkred]

--- Steve Jorgensen wrote:[color=darkred]
> Believe it or not, there is a concept in purely relational database
modeling
> called subclassing. The way subclassing is implemented is by having
a base
> class table with the common attributes, and one or more (usually at
least 2)
> other tables that have a 1-to-1 relationship to the base class table,
plus
> additional attributes that apply to the subclass. [...]

There are three main ways to represent inheritance in relational
tables:
1. Put the union of all fields of all classes in one table.
2. Have one table for each class. Join a class' table with the tables
of all its parent classes to perform each query.
3. Have one table for each non-abstract class (typically the "leaf"
classes). Store all the attributes of each class (including all parent
attributes) in each table.

There are advantages and di

vantages to each approach.

I would guess that most O-R mapping tools should support all three
approaches. I know that TOPLink does.
_ _ _

A more "XP" approach might be to avoid using a database for as long as
possible. Initially, for prototyping, don't store the data. Later,
try primitive serialization. Later, an "Object Prevalence" approach
may be appropriate. See Prevayler for Java, Bamboo for .Net. Consider
object-oriented databases. Eventually, you may need to use a
relational database. By the time you get there, you'll probably have a
very good understanding of exactly what you need.

Sponsored Links