Re: Changing Object Type in OODB

Hi,

Bob Badour wrote:

[Person/Employee/Manager model]
> >Yes. Manager inherits from Employee, maybe with a common Role
> >interface.
>
> I don't think the assumption of the inheritance relationship between
> Employee and Manager is a very realistic one, is it?
>
> One could take over another's Manager role without assuming all of the
> attributes of the Employee role, couldn't one? For instance, the salary
> might not be the same even though the job description, department and
> reporting employees would be.

It depends on whether there can be only one Manager role per Employee. If not - agreed, inheritance is inappropriate, then a Manager is not an Employee, but an Employee takes a Manager role. That's the reason I wrote: 'Inheritance between the Employee and Manager role will be perfectly acceptable in many cases.' In the other cases you may have the Manager refer to an Employee object or have a completely different design depending on the company's internal structures.

I'm aware that's not consistent with

| > 4. A Person object instance can assume multiple Employee roles and/or
| > multiple Manager roles.
|
| Not necessarily, but possibly.

but that's what I had in mind when I wrote this. Point for you, restating requirements: A Person usually is employed once but can have many responsibilities. In this case employment and responsibilities are not related closely enough to be modelled by inheritance.

> Also, I know of many actual situations where one person is managed by an
> employee of a different company or by someone who is not an employee at all.

See above. More complex case, different design. That's where the Party thing drops in, too - responsibilities may even be taken by Companies, not only by Persons.

> If a company requires all managers to be employees of the company, is that
> not simply an additional integrity constraint? Are there no means to enforce
> the constraint other than as an inheritance hierarchy?

If a constraint can be expressed by inheritance and is unlikely to change, this is one easy way to put it into effect.

> Somebody tried to claim that modelling relational databases is more
> difficult and complex than modelling OO databases. He even tried to point to
> my observation that the proper design will depend on the full requirements
> as a failing of the relational model. Yet, you seem to agree that the proper
> OO design will depend on them too.

I haven't heard of any modelling approach that doesn't start with some kind of requirements.

I simply dislike that modelling relational databases is an additional task when working with OO languages: You have to build an OO model and map it to a relational database. Unfortunately this is quite tedious in most cases.

[OO model -> code -> persistence]
> Incidentally, I think the mechanism you have chosen introduces significant
> risk. For instance, what happens when two applications each want to use a
> subtly different model for the same data? If one communicates the model to
> the OODBMS through the application code, how does one reconcile the
> differences?

The applications have to use the same model, at least for conversion purposes. Build your DB model for the requirements of three applications and the fourth will break it. I think this is a point for schema evolution rather than database-centric application design.

> >> In other words, could the role-based design have further flavours with and
> >> without independent collections of Employees and Managers? One design would
> >> have a single global collection of Persons who might or might not assume
> >> Employee or Manager roles, and another design would have global collections
> >> of Persons, Employees and Managers?
> >
> >Yes. Though I think the latter would be the most uncommon.
>
> Really? How would users answer questions of the form: Who are all the
> managers employed by our company who earn less than $90,000.00 ? Would they
> have to loop through all of the Persons in the database?

If the applications that use this data don't need this information frequently, maybe. Well, no, more likely through all the Employees or Managers. I'd just consider it more uncommon if there were globally available collections of all of those: Persons, Employees and Managers.

> >I am not quite sure what you would like to show here. If your
> >point is that OOAD modelling methods are not as mathematically
> >concise as relational modelling and (among other differences)
> >therefore may yield more possible resulting models
>
> Actually, I do not think that OOAD modelling methods can ever result in a
> design that has no exact relational equivalent. I think that OO introduces
> redundant names with different interfaces for the same concepts thereby
> complicating models without any added compensating value. I also think that
> normalization applies to and improves OO designs.

First, ok, given a liberal interpretation of exact. Second, maybe from a persistence point of view, seen from application programming I think this 'redundancy' has proven quite helpful. Third, why not, given an appropriate formalism. Fourth, it is quite interesting that you think this, but it might be even more interesting if you could boil it down to what point you'd like to make here. This would free you from the burden of having to prove that design needs requirements and the like.

> >> Does Coad, Fowler or anyone else provide any guidelines regarding
> >> duplicating data in the Employee or Manager role object instances that
> >> already exists in the Person object instances? Height or hair colour, for
> >> example?
> >
> >Why should you want to do that?
>
> Performance is the often cited reason.

OK, then I don't want to do this - this is the DBMS' task. When I have to handle performance issues this usually has to do with proxies, caching, etc., but I don't want to see my basic model cluttered with redundant data for performance purposes.

Back to the original question:

You started with a question concerning a given (Java) model and how a type transformation could be performed in an OODBMS on instances from this given model. My answer was that I consider this design inappropriate and it should be adjusted. This is even more true at the current state of discussion.

Among other reasons, I didn't want type transformations in the database because I don't have them at run-time. This is still my opinion as far as it concerns Java, but tonight I've had to learn that some other OO languages actually do support type transformations at run-time, so I'll have to think this over before making general statements on OODBMS.

I would really like you to choose one appropriate newsgroup, because I'm not going to carry on crossposting this meandering thread through five groups. Looks like a lack of normalization to me. =;)

Regards,
Patrick Received on Sun Jul 22 2001 - 01:29:41 CEST