THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

The requirements analysis process, as described in most methodologies' system development life cycles, typically addresses both rows 2 (the owner's view) and 3 (the data architect's view) of the Zachman Framework.

Harking back to the days of Chris Gane and Trish Sarson and their Structured Systems Analysis ^[1], the approach was to begin with a view of the "Current Physical" system and then move to the "Current Logical" system. The idea was to take as your starting place a view of the world as it is, warts and all, and then attempt to rationalize it and determine the underlying structures that made it the way it was. Subsequently Stephan McMenamin and John Palmer refined this idea, coming up with a specific procedure for identifying "Essential Processes" in a physical data flow diagram. ^[2] These essential process were the appropriate targets of system design.

Gane and Sarson were addressing the function column of the Zachman Framework, however. There has not been an equivalent discussion in the literature about the appropriate way to address the same ideas in the data column. What exactly are the contents of the "owner's view" of data vis a vis the "architect's view"? This article will attempt to advance some ideas about what these should look like.

Zachman rows 2 & 3

Row 2: Business owner's view

The owner's view of data consists of "business entities" ^[3] This implies several characteristics of this view.

• The entities in an entity/relationship model will be exactly those described by and perceived by the business people. They will tend to be very concrete.
• Relationships may not all be binary. There may be three-way and greater degree ("n-ary") relationships.
• There may be some many to many relationships.
• The data entities are not necessarily in third normal form. A user, for example, might perceive an "order" as comprising the vendor description, the order header, the line items and the product descriptions. To him, that's one entity or object class.
• Business relationships describe the connections between entities in the world. They should be expressed as ordinary English sentences.

Note that this produces data models that describe the structure of things as seen by users at the present time. While such a model should be readily understood by the people who provided the information, any system developed from it will be vulnerable to changes in the business. It will also be as complex as the owner's view of the business, with a large number of entities.

Row 3: Architect's view

By contrast, the information architect's view sees entities and relationships as representing the essential things in the business. That means:

• The entities portrayed are inherent entities. That is, they represent those things that are fundamental to the business, of which the entities perceived by business users are but examples. For example, where one business user sees a "vendor" and another sees a "customer", the architect sees a "party" which may be either a person or an organization that has, respectively, "buyer in" or "seller in" relationships to "orders".
• Relationships are all resolved into binary relationships.
• Many to many relationships are all resolved with intersect entities.
• All entities are defined so as to be in third normal form (fifth normal form, actually).
• Relationships between entities are statements of referential integrity only. Note that this means that the architect's view, strictly speaking does not need relationship names.

This perspective tends to be more abstract than the row two perspective, but it tends to produce models that are smaller, more general, and more robust, by virtue of the fact that they can accommodate not only what was described specifically, but other situations that may come up in the future. Modeling from this perspective has revealed that enterprises in many different industries in fact have similar underlying data structures. ^[4]

Note that in practice, most analysts produce data models that are combinations of these views. Some produce models that are more concrete and closer to the user's view, and others try to find the more fundamental architect's view. Followers of both approaches, however, often include elements of the others. Your author, for example models entities primarily from the architect's view, but relationships (subject to the binary and many-to-many restrictions) from the owner's perspective. This is primarily (in your author's view) because we have not adequately defined how the two perspectives interact.

In 1994, your author published an article in Database Programming and Design on the concept of data model views. ^[5] The idea was that it should be possible to define "virtual entities", analogous to SQL views, that would, in an e/r model, present whatever the viewer wanted to see. These would, however, be rigorously translatable into the architectural row 3 model.

Specifically, what is needed is the ability to document in detail the following translations:

• A business entity may be derived from one or more fundamental entities. This addresses two issues:

  User views may be more concrete than architectural views, addressing the specific terminology of a particular situation.

  User views may be "de-normalized", grouping different kinds of attributes together that an architect would define separately.

• N-ary relationships are specified combinations of binary relationships.
• Many to many relationships are resolved into specified intersect entities.
• Business relationships reflect referential integrity issues.

Alas, no CASE tool currently provides the ability to document these translations directly. The best any do is to provide lots of places for annotation. It would be wonderful to be able to draw an e/r diagram consisting of virtual entities, rigorously defined as combinations of real entities and relationships shown on other e/r diagrams. It would be nice to be able to show a user a many to many relationship that is logically equivalent to the use of an intersect entity shown to a designer - with both described in the CASE repository. Similarly, it would be nice to be able to draw a three-way relationship and have the tool keep track of the fact that this is equivalent to three binary relationships and an intersect entity.

Enter Object Oriented Analysis

Your author has long been troubled by the invasion of object-oriented aficionados into the world of systems analysis. You heard it here first: There is no such thing as "object oriented analysis". There is only "analysis". That the object-oriented crowd have figured out that it is useful to do analysis in terms of data structures is gratifying - since the information engineering folks figured that out a long time ago. But the proliferation of new techniques for drawing "object models" has done nothing but clutter a field that already had too many drawing techniques. Rumbaugh's object models ^[6], for example, are nothing but e/r diagrams with behavior added.

Don't get me wrong. Adding behavior to e/r diagrams is a good and valid thing to do. The most rigorous way to do this that I know of is a technique called "Entity Life Histories", ^[7] although in the absence of CASE tools that support this technique, it is brutally difficult to do.

Recently it has become clear, however, that the attitude of object-oriented analysts is positive in one respect: They tend to focus on "objects" that are perceived by the users. "Use cases" are specifically designed to capture the actual business flow of activities, as represented by the behavior of the objects seen by users. Since they tend not to be bothered by such issues as normalization, object-oriented analysts can more directly speak the users' languages.

The only problem with this is that (in your author's experience), the object-oriented analysts are too quick to jump from row two to row four. The object-oriented programming paradigm allows for objects to contain other objects, for them to have multi-valued attributes, and to quietly bypass the disciplines of normalization and data management that have grown up over the years.

("Normalization? We don't do no stinkin' normalization…")

The effect of this is that the resulting systems suffer from the same shortcomings that systems used to have before normalization came along. They have complex data structures that do not lend themselves to changes or to dealing with unanticipated circumstances. If you implement an "order" object that includes within it line item objects and product objects, you will be hard pressed to answer the query "Show me all the customers that have ordered this product from me."

Implication

So what does all this mean? It means that we (where "we" means the entire community of systems developers - object-oriented and relational both) certainly should be better at identifying the entities/object classes/things that are of interest to the business community. Similarly, we (same definition) should be as disciplined as we can at developing the true underlying architecture of those e/o/t's. The entities in this architectural model may then be readily converted to object classes for an object-oriented implementation or tables and columns for a relational implementation.

Ideally, a CASE vendor will read this article and immediately go out and develop the tools that will allow us to freely translate from one view to the other.

References:

[1] - Chris Gane, Trish Sarson, Structured Systems Analysis: Tools and Techniques, (Englewood Cliffs, NJ: Prentice Hall) 1979.
[2] - Stephen M. McMenamin, John F. Palmer, Essential Systems Analysis, (Englewood Cliffs, NJ: Yourdon Press) 1984.
[3] - John Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, Vol. 26, No. 3, 1987, p.286.
[4] - David C. Hay, Data Model Patterns: Conventions of Thought, (New York: Dorset House Publishing Co., Inc.) 1996.
[5] - David C. Hay, "Visualizing Database Structures", Database Programming and Design, June, 1994.
[6] - James Rumbaugh, Michael Blaha, William Premerlani, Fredrick Eddy, William Lorensen, Object-Oriented Modeling and Design, (Englewood Cliffs, NJ: Prentice Hall), 1991.
[7] - www.essentialstrategies.com/publications/elh.html.

Dave Hay is Founder and President of Essential Strategies, Inc., a firm specializing in computer-aided systems and information engineering, business process re-engineering, modeling, and the management of systems implementation efforts. He has over twenty-five years experience in the information processing industry, with the last ten of that focused on using CASE for strategic information planning and systems analysis. He is the author of the book, Data Model Patterns: Conventions of Thought, from Dorset House.