Re: Changing Object Type in OODB

> [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.

I don't see how my example above requires more than one Manager role per Employee or per Person, for that matter.

Isn't it a common occurence in business for a Manager to leave a position, and for another Person to assume the newly vacated position? Doesn't that mean the reference to the Manager role moves from one Person object to a different Person object? That certainly seems much more concise than a deep copy followed by a deletion.

If one models an inheritance relationship between Employee and Manager, one cannot simply change the references because the reference would also include Employee-level contractual data -- such as Salary -- not directly associated with the Manager role. After all, doesn't moving the role object from one person to another more closely model the real world in this situation?

Of course, moving the role won't handle situations where a Manager's department is split up after the departure, and it won't handle situations where the department is folded into another after the departure. The inheritance relationship provides no advantage in either of these situations, though; at best, it doesn't hurt either.

> If not - agreed, inheritance is inappropriate

The above example does not necessarily assume multiple Manager roles per person. Even if there can only be one Manager role per Employee, I still question the practicality of an inheritance relationship between Employee and Manager. It means you have to create a new Manager role, copy over all of the Employee information and destroy the original Employee role every time an Employee becomes a Manager.

> a Manager is not an Employee, but an Employee takes a Manager role.

I would say that a Person assumes a Manager role. I have worked for Managers who were not Employee's.

> That's the reason I wrote: 'Inheritance between the Employee and
> Manager role will be perfectly acceptable in many cases.'

I think those cases are quite limited. Roles would have to be quite static to make the relationship acceptable unless one can change the type of the object.

> | > 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.

Assumption 4. is not a requirement -- I only proposed it as a reasonable assumption to further limit the range of discussion. We can relax the assumption entirely if you prefer. I don't think it changes much -- it's just a cardinality constraint.

> > 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.

I cannot see how a Company can manage a department or how a group of employees can report to a Company without reporting to a Person. At least, I have never seen that in my career, and I would question the practicality if I did.

> > 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.

I will restate my question: Is the inheritance hierarchy the only way to declare the constraint? Are there no direct means? Wouldn't it be simpler to declare the constraint directly without requiring further changes to the logical model that all users must then contend with?

> > 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:

Modelling the database to satisfy the needs of all applications will always be an additional task over modelling the object classes for a single application. Forcing all applications to use exactly the same logical model forces much more work onto the users of the DBMS. Each application must compromise it's design to the arbitrary demands of other users.

> You have to build an OO
> model and map it to a relational database. Unfortunately this
> is quite tedious in most cases.

Please, prove the latter statement; I find it incredible.

> [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.

Conversion? Who said anything about conversion? Applications have to share live data without necessarily wanting to share the same object schema.

> Build your DB model for the requirements of
> three applications and the fourth will break it.

No, it won't. The DBMS must support considerable physical and logical independence so that it can accomodate the fourth without disrupting the prior three: logical independence to accomodate multiple logical views of the data and physical independence to balance the performance requirements of all applications.

> I think this is
> a point for schema evolution rather than database-centric
> application design.

Precisely my point. The DBMS must accomodate the fourth application without disrupting the prior three. If each application's object classes demand a subtly different schema, the DBMS must reconcile the differences. If the DBMS looks to an application's object classes to infer a schema, the second application will break everything.

> > 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.

Why should physical performance issues affect the logical model? If the user's have utility in accessing the set of all managers, why shouldn't the logical model allow it -- even if slowly?

> 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.

Why? Won't users approach the DBMS with problems like: "Who are all the people who live near Chicago? We want to invite people to the golf outing in August.", "Who are all the employees who have been with the company more than 35 years? We want to recognize them at our annual kick-off meeting.", "Who are all the managers with fewer than 2 reporting employees? We want to restructure."

> > >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.

It doesn't require a liberal interpretation at all. The physical storage considerations are simply separated from the logical presentation in the relational model. Otherwise, one can contrive an exact relational equivalent to every possible OOAD model -- both physical and logical.

You and your colleaque seem to assume that the logical model and physical model are inherently tied, and the assumption is incorrect.

> Second, maybe
> from a persistence point of view, seen from application
> programming I think this 'redundancy' has proven quite helpful.

Application programming is inherently physical. That doesn't make redundancy in the DB language helpful -- only more complex. If you want to call a relation a Bag or a Set or an Array or a Collection, why not do so in the application while still calling it a relation in the database?

> Third, why not, given an appropriate formalism.

Why not what? Given an appropriate formalism of what?

> 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.

Good object class designs construct their instance values by combining many object instances of diverse type. This fact requires one to construct an object from diverse logical entities. Normalization really does apply to objects.

> This would free you from the burden of having to
> prove that design needs requirements and the like.

Demonstrating your colleague's absurdity doesn't burden me much -- absurdities are absurd, after all. Of course, if he refrained from trying to cloud issues with them, even that small burden would go away.

> > >> 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.

Good. At least, we can agree on one basic principle. It would be nice if you applied it more consistently.

> 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.

Yes, thank you for helping to clear that issue up.

> 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.

The relational solution handles the subtype/supertype relationship exactly the same way that it handles the role relationship, so it's not an issue relational users have to consider at all. After all, we don't want our logical data models cluttered with physical issues, do we? <g,d&r>

> 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. =;)

Why should you care how many newsgroups are crossposted if the discussion relates to each of them? Doesn't your newsreader filter out the messages you have already read on other groups? Mine does.

I haven't heard from any of the users of any of the newsgroups complaining that the thread is off-topic for the group. Have you? Received on Sun Jul 22 2001 - 01:29:47 CEST