- Introduction
With the growing acceptance and use of Object Oriented designs and technology, it
is important for developers to know not only the advantages but also the limitations
of the technology. Andrew Girow covers the limitations of the OMG's Object Data Model,
complete with code examples to illustrate his points. The following lists a number of
points he covers with a brief synopsis of the problem.
- Homogeneity of Relevant Facts
Not all instances of an object will necessarily use all fields available to it.
This leads to wasted space in each instatiation, and over a large database with many fields,
this could add up to significate inefficiency.
Example: An Employee object will have a 'maiden name' field. As obviously only the female
employees will have this field set, you have wasted space.
- Homogeneity of Fact Type
For a specific field, one would expect that field to contain the same information
across all instantiations. Otherwise, it can be difficult to design intuitive queries, and
problems with data validation become a concern.
Example: If a car object has an 'assignedTo:' field and it can be assigned to both individuals and
entire departments. How does a user know which to expect, an individual or department? If a car can be assigned
to other things later, an entire redesign of the object may be necessary.
- Class Descriptions
Information about an object's instantiation is obtained by reading fields, or via methods that read those fields.
The user of a database has no way of always knowing what information is really available, and can be easily asked
for.
Example: Assume that the MaxEmployees variable is defined outside of a certain 'Department' class. There is no gaurantee
that the Department class can access that variable to determine how many employees are in the department.
Example: It may be trivial to ask a database "Who manages Accounting", yet impossible to ask "How is Bob related to
the Accounting department?"
- Fieldnames as Placeholders
Fieldnames only act to reserve space in a object. They can define a type, a relationship, or both. They are simply
aids to the programmer and do not define relations usable by the database.
Example: There is a class named 'Department', and the 'Employee' object has a field named 'dept'. There is no promise
that 'dept' relates to 'Department', and if that relationship is implied, the database is unable to make that inference.
- Entities
There can be a 1:1 correspondence between object and entities, but that may not always be the case.
Example: An instance exists of a specific Person. However, that Person may also be an Employee, Customer, StockHolder, etc.
How is this handles? Does this Person exist as two seperate instances, or as some sort of merged entity?
Example: A 'Building' class has an address field. Since there is a 1:1 correspondence between buildings and addresses,
the class could be said to be representing addresses as well as buildings.
- Conclusion
Data models can be ambiguous or inaccurate, leading to poorly constructed relationships amoung objects, and
inefficiency in their implementation. The choice of a correct model for the problem can reduce the hassles in creating
an optimum design. The author refers us in his paper to a discussion of other such models.
- The homepage for the author of this paper:
Visit http://tetragr.zaporizhzhe.ua/home/girow/homepage.html
Copyright © University of Colorado. All rights reserved.
Revised: October 16, 1998
