Hi, i need some help with Object-Oriented DB. Im having trouble populating an object-relational database, which includes an inheritance relationship, much like the following:

Person
/ \
ISA / \ ISA
/ \
Employee Customer


Now, the problem is that all person's are employees, and some are also customers. By having an ISA relationship, does this mean that a Person can be either an Employee OR a Customer, but not both? If they are both, would this mean they inherit the superclass's properties twice??

If anyone can shed some light on this, it would be really appreciated, thanx

There are some serious problems with object-orientation, largely stemming from the vagueness of the term "inheritance."

Most models of inheritance regard a type as being a set of possible values. If we interpreted your graph as based on a typical single-inheritance model, we would probably assert that Person is an abstract type. We would also assert that no Employee can be a Customer and vice versa. Another way of saying that is that immediate subtypes are disjoint. That's the usual rule, but since everyone and his grandmother has an inheritance model, I'm sure someone's come up with a scheme that blurs even that.

As for inheriting properties, I don't want to go into detail. Chris Date does a pretty good job, and that's just one of a number of articles he's written on the subject. The short story: it doesn't work. Most OOP languages either don't allow it, or tell you not to do it. Date also argues that ODMBS's make a fundamental mistake in equating type with tables, and I'm inclined to agree with him.

Generally, I'd just argue that you're barking up the wrong tree trying to declare all these types and junk.

Design a table that contains logically true statements about the things you are trying to describe. I'd start with something like this:

table Persons: There exists a person named NAME born on DATE etc.
table Customers: The person named NAME represents client company COMPANY etc.
table Employees: The person named NAME works in DEPARTMENT and earns SALARY etc.

If you don't understand the semantics of your ODBMS's inheritance model, you can't expect your code to work reliably. And we can't explain how it works because while there may be commonalities between various models, they all have gotchas and inconsistencies.

(Actually, the latest versions of the SQL standard may have defined an inheritance model, but I haven't been following that very closely.)