Re: Changing Object Type in OODB

>However, I don't know how dynamic behavior would be handled in
>relational modelling and I have only looked into a small subset
>of OOAD approaches.

Dynamism results from changing the values of variables. While effective data modelling facilitates appropriate changes and discourages or prevents inappropriate changes, the DBMS should never initiate changes to application-defined data on its own (changes to system-defined data are a different matter, of course). In this sense, behaviour is equally beyond the scope of data modelling for both relational and OO DBMSs. Behaviour is really part of the application domain -- even if the application code resides on the DBMS and even if the DBMS enacts the application code.

>> You proposed modelling Employee and Manager as roles of Person object
>> instances for one possible design, and I would like to explore that
 design a
>> little further. (Ignoring your Party object class for simplicity.)
>>
>> I assume:
>>
>> 1. The Employee and Manager roles are modelled as two additional object
>> classes whose instances have identity separate from the object assuming
 the
>> role.
>
>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.

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.

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?

>> 2. The Person object class defines some method or property for
 identifying
>> its associated roles.
>
>Probably.
>
>> 3. The associated role object instances have some method or property that
>> refers back to the Person object instance assuming the role.
>
>Yes.
>
>> 4. A Person object instance can assume multiple Employee roles and/or
>> multiple Manager roles.
>
>Not necessarily, but possibly.

In other words, it is not a necessary assumption but not an unfair assumption either. In the end, it boils down to a data integrity constraint that possibly applies -- depending on the full set of requirements.

>> When it comes to describing this model in an OODBMS, am I correct in
>> identifying the following additional criteria that designers might ask
>> themselves:
>>
>> Will users need to identify the set of all Employees?
>> Will users need to identify the set of all Managers?
>
>That depends on the requirements, but probably yes.

Isn't one simply evaluating the requirements by answering the above design criteria? In other words, isn't it the answers that depend on the requirements rather than the questions?

>But I
>wouldn't describe this model in an OODBMS but as an OO model,

In comparing relational and OODBMS methods, I am interested in the process as an OODBMS process more than as an application development process.

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.

That other person presented an inheritance hierarchy as an obvious no-brainer to support his claims, and our discussion here seems to reveal that it was anything but an obvious no-brainer.

>would put it into code and then expect an OODBMS to simply make
>it persistent. Perhaps splicing hairs now...

Isnt't this is just the mechanism you want to use to communicate the OO data model to the OODBMS? The mechanism makes the model no less a model of the data in the OODBMS.

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?

>> Or do we further assume that all object classes define an implicit
>> collection of all their instances?
>
>In other environments you may have the implicit notion of the
>extent of a class, but in Java as a language you don't. (I think
>that JDO supports this concept, but I may be wrong.)

Paraphrasing: Some languages dictate logical constructs whereas others do not. Regardless, I assume one can revoke access to those automatically created extents through the security mechanism, so the the designer is left with the same decision in the end: To have global collections of the role object instances or not.

Wouldn't you agree?

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

>There
>also might only be a global collection of Employees and a
>filtering method that produces only the subset of Managers

In a relational system, there might be a global relation of objects that implement all of the Employee operators. One could filter using an operator that identifies Managers or one could filter using a system-defined operator that identifies objects that the DBMS can up-caste to Manager.

I doubt if I would choose such a design very often, but isn't it equivalent?

>or no
>global collections at all but a visitor collecting Employees from
>the department hierarchy or...

The OODB must have at least one globally accessible object or collection to gain access to the data. Is this not true?

In a relational system, we could have a relation representing the Departments with a relation-valued attribute of Employees. Is this not equivalent?

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

>My point simply was that the example you presented IMO doesn't
>work for most imaginable domains where you can expect to find
>persons, employees and managers. I don't expect my objects to
>change their type in-memory at runtime, I don't expect them to do
>so in the database.

Neither do I. A relational modeller only has to grapple with this issue when contriving domains and their operators. Since the DBMS does not make arbitrary distinctions between different kinds of references among relations, it does not apply at that level of the design.

>To cope with such behavior I like to view
>this as one object playing different roles. And I still don't see
>why it should make a difference if I want to make my objects
>persistent or not.

Because persistence alters the behaviour and scope of your variables. ?

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

Regards,
Bob Received on Sun Jul 22 2001 - 01:29:36 CEST