The first part of this article appeared in the February 1999 issue of DM Review.

The data processing industry in the nineties is sitting at the confluence of several important trends. Information engineering represents the integration of the first three: 1) the development of structured system development techniques, 2) the change in orientation from program processes to data structure, and 3) the development of relational database systems. It remains to take full advantage of the insights gained from a fourth: object oriented programming and systems analysis.

Contrary to the publicity they have received, the techniques of object orientation do not represent as much of a departure from the way things have been done in the past as their proponents would suggest. As with many "revolutionary" changes in our industry, a large part of the changes have simply been in vocabulary. This article is a discussion of those object oriented concepts which represent simply renamed extensions of information engineering and relational database design, and those that represent radical departures from them.

Last month's article discussed the ways information engineering and the object oriented approach were similar. Now we'll discuss the differences.

New Concepts

While object orientation is like data modeling and information engineering in many ways, its differences are as important.

The most profound idea added by object orientation is the notion of encapsulating an object's behavior into the object itself. All of those functions information engineering had pushed to the side can be broken into pieces that are specific to each entity. This does not just mean "add," "change" and "delete," but behavior expressed in terms of business functions as well. At the business level where the object is defined, methods can be defined for each object, defining what the object does in response to specified events or messages. A business function responding to a message might be carried out via an operation that triggers methods for more than one object.

For example, {Receipt of a shipment} is a message to the entities LINE ITEM, INVENTORY, and others. The operation Receive shipment, which is in response to {Receipt of a shipment}, updates one or more line item objects and one or more inventory objects via the methods defined for each. The methods are, respectively, Receive shipment (INVENTORY) and Receive shipment (LINE ITEM). The calling of different methods by an operation, depending on its object, is called polymorphism.

The idea of methods contained in entities is called encapsulation. It can be carried further by making the attributes themselves into methods. They can be defined as functions for retrieving the data. That is, the attribute "first name" of PERSON is really a method which is Retrieve (PERSON, "first name"). This brings up a second feature of object orientation, namely that the actual data structure itself can be hidden behind object behaviors. This turns out to be useful. For example, version one of a model might be as shown in Figure 1. Each DEPARTMENT must be managed by one and only one EMPLOYEE.

Version two, however, might look as in Figure 2 where, over time, more than one employee may manage a department. MANAGEMENT becomes a separate entity, and to find the current manager you must retrieve the latest MANAGEMENT occurrence. The SQL for these two structures is quite different; but if "current manager" for the department were a function, it could be named the same way, regardless of the underlying structure and logic.

Encapsulating the processes in the entities turns out to be an excellent way to achieve true modularity and to have reusable code. If you define the procedure for retrieving (or updating) the manager once, any function that has to retrieve (or update) the manager can call that procedure. In the Receive shipment example above, the method for dealing with each object is contained in the class definition, so that if new objects are added to the operation, the code for dealing with those can be added to those entities, and the existing code for others need not be affected.

In information engineering, function/entity matrices are translated to module/table matrices when going from the analysis to the design phases of a project. The resulting module/table matrices, however, ought not to refer to a module's direct use of the table but to its invocation of the method for obtaining access to the table. All modules based on business functions that require a particular table, then, invoke the same module ­ the one which is responsible for correct access to that table.

Object orientation does more with the concept of attribute than simply turning attributes into functions. Among other things, relationships can become attributes as can other objects. To those who have converted many-to-one relationships into foreign key columns in a database, this should not seem remarkable. The other object, in the person of the foreign key, has just become an attribute of this entity.

Somewhat stranger is the idea of reversing first normal form to also make the objects at the other end of a "many" relationship into an attribute of this entity. In Figure 3, for example, an attribute of PURCHASE ORDER would be the set of LINE ITEMS. This doesn't change the normalization of the object model nor even its implementation. It is simply a different view presented to the user.

Figure 3

An interesting effect of all this is that relationships have to be specified within the object at each end. This means that the operating system or database manager must be constructed to guarantee that the references on both ends are consistent. "Purchase order" is an attribute of LINE ITEM, and "the ordered set of line items" is an attribute of PURCHASE ORDER. If a relationship is cut, both object classes have to be updated.

Just as attributes may be derived, relationships may be derived as well. The parent of this entity depends on the phase of the moon and the day of the week, an so on.


All the technical points aside, perhaps the biggest difference between information engineering and object orientation is the attitudes of their followers. Information engineering shows its structured heritage by placing a strong emphasis on planning and establishing structures early in the process. Its focus is the database. Object orientation, however, is derived from object oriented programming, and so it is more concerned with writing code to respond to each requirement. The strength of object oriented programming is that it has developed procedures which allow code to be written for small pieces of a problem, involving a few objects, with the assurance that when other parts of the problem are identified, what has been done won't interfere with solving them. Its weakness, on the other hand, has been its lack of addressing true database issues.

One reason object oriented programming is not constrained by the rules of relational databases is that it does not actually imply the existence of a database at all ­ only "persistent" data in whatever form seems appropriate. If sub-types or variable length records are deemed useful, then the object oriented program has that kind of data structure. The literature suggests that the problems created by trying to implement the concepts of multiple inheritance and so forth have been solved, but it is not clear that this is so. While products are beginning to call themselves object oriented database management systems (OODBMSs), none have addressed data management to the extent that relational products have, leaving open numerous questions as to what will replace the relational rules in the object oriented world.

All of this has affected the effort to create something called "Object Oriented Analysis." Requirements analysis is the effort to define a client's requirements for new systems and is not related to the particular technology that will be used to build them. Object oriented aficionados have taken their object orientation to mean that analysis should be object oriented as well. Since information engineering has been doing data models of the "things of significance to the business" for many years now, this object orientation contributes less to the dialogue than it first appears. Moreover, this absence of concern for the persistent data has affected the object analyst's thoroughness in doing the basic data analysis.1

The time is clearly ripe for a merging of the two ideas ­ drawing from object orientation its strength in organizing processing around objects and drawing from relational database theory its strength in organizing those objects in the first place.


Object orientation, especially as it applies to systems analysis, has taken off in the last decade. It promises to bring the world of functions and the world of data back together again in a systematic way. Unfortunately, there remains some confusion over its relationship to the analysis process and the techniques that have preceded it. Still, it is an exciting area from which great things will come.

Note that in the accompanying bibliography, only four of the 15 entries on object orientation were published before 1990. Unfortunately, there is no one book which is the definitive text on the subject, although all of them make significant contributions. Naturally, each has its own notation for object models. If you are just beginning to learn about this field, probably the best place to start would be David Taylor's Object Oriented Technology: A Manager's Guide or Meilir Page-Jones' What Every Programmer Should Know About Object Oriented Design.

1 Hay, D. "Object Orientation and Information Engineering: The Analysis Process." The Data Administration Newsletter. i007ht04.htm.


Information Engineering

  • Barker, Richard. CASE*Method: Entity Relationship Modelling. Harlow, England. Addison-Wesley. 1990.
  • Bruce, Thomas A. Designing Quality Databases with IDEF1X Information Models. New York. Dorset House. 1992.
  • Hall, John., Robinson, Keith. "Logical Data Modeling and Process Specification." Stamford, Connecticut. Model Systems, Inc. 1989. Photocopy.
  • Jackson, Michael. System Development. Englewood Cliffs, New Jersey. Prentice-Hall. 1983.
  • Martin, James. Information Engineering. Englewood Cliffs, New Jersey. Prentice-Hall. 1989.
  • Schmidt, Bob. Data Modeling for Information Professionals. Englewood Cliffs, New Jersey. Prentice Hall PTK. 1999.
Object Orientation
  • Booch, Grady. Object Oriented Analysis and Design, with Applications. Redwood City, California. Benjamin Cummings. 1994.
  • Cattell, R.G.G. Object Data Management: Object-Oriented and Extended Relational Database Systems. Reading, Massachussets. Addison-Wesley. 1991.
  • Coad, Peter., Yourdon, Edward. Object-Oriented Analysis. Englewood Cliffs, New Jersey. Prentice-Hall. 1990.
  • Embley, David W., Kurtz, Barry D., Woodfield, Scott N. Object-Oriented Systems Analysis: A Model-Driven Approach. Englewood Cliffs, New Jersey. Yourdon Press. 1992.
  • Entsminger, Gary. The Tao of Objects. Redwood City, California. M&T Books. 1990.
  • Fowler, Martin. UML Distilled: Applying the Standard Object Modeling Language. Reading, Massachusetts. Addison-Wesley Longman. 1997.
  • Hay, David. "UML Misses the Boat." http://www. modeling/uml.htm.
  • Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Upper Saddle River, New Jersey. Prentice-Hall PTR. 1998.
  • Longman, Cliff. "Object Orientation and Oracle CASE." Paper presented at the International Oracle User Week. 1992.
  • Meyer, Bertrand. Object-Oriented Software Construction. Englewood Cliffs, New Jersey. Prentice-Hall. 1988.
  • Page-Jones, Meilir. What Every Programmer Should Know About Object-Oriented Design. New York. Dorset House. 1995.
  • Rumbaugh, James., Blaha, Michael., Premerlani, William., Eddy, Frederick., and Lorensen, William. Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey. Prentice-Hall. 1991.
  • Shlaer, Sally., Mellor, Stephen. Object-Oriented Analysis: Modeling the World in Data. Englewood Cliffs, New Jersey. Prentice-Hall. 1988.
  • Shlaer, Sally., Mellor, Stephen. Object-Oriented Analysis: Modeling the World in States. Englewood Cliffs, New Jersey. Prentice Hall. 1991.
  • Taylor, David. Object-Oriented Technology: A Manager's Guide. Reading, Massachusetts. Addison-Wesley. 1990.
  • Taylor, David. Object-Oriented Information Systems: Planning and Implementation. New York. John Wiley and Sons. 1992.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access