Business rules document business meaning. They are based on data types that also carry business meaning. One of the prime ways to define data types is to perform business data modeling.

Two previously published books try to answer the question, “How often do we have to model the data for our business?” Both give the same answer, “Once, and a lot of it has already been done for you.”

Each book contains a set of basic, general models that can be used as a start for modeling the meaning of data for a specific business. However, there are some significant differences in the material that follows in each, the way the material is presented and the points of view of the authors.

No discussion that contains the word model can ignore the Zachman Framework for long. The Framework is a useful tool for describing almost anything about a business and is especially useful for classifying models about a business. Data models are one way to describe a business and business rules are, in their own way, models that describe a business. Unfortunately, neither book mentions the Framework.

For this review, the most relevant parts of the Framework are rows 2 and 3. Framework row 2 models are enterprise oriented and are created with an enterprise owner in mind as an audience. Row 2 data models are frequently called entity-relationship models. Row 3 data models are information system oriented with a systems designer in mind as an audience.

Both books offer many diagrams as patterns and structures to start an analysis effort. Once a starter diagram is presented to participants and then modified to fit a current business situation, the model should give a good view of a particular organization.

Patterns

David C. Hay, in Data Model Patterns: Conventions of Thought writes for a Framework row 2 audience of analysts dealing with business people. His view is at the business level, Framework rows 1 and 2, which Dan Tasker calls the problem space in his book of the same name (The Problem Space e-Book, 1993). These rows are concerned with defining the nature of a business.

Hay starts with a short, context-setting introductory chapter that makes a reader want to continue reading. Patterns then has a chapter on modeling conventions. While the text explains the conventions clearly, it omits explanation of the dashed and solid relationship lines used in the model diagrams. For a novice reader this may be a puzzle until the reader figures out that a solid line indicates a must be, or mandatory relationship, and that a dashed line is for a may be, or optional relationship.

Hay covers a wide range of topics. Patterns includes four chapters on the basic subject areas of people and organizations, products and inventory, procedures and activities, and accounting. Four other chapters cover additional subject areas of contracts, the laboratory, material planning, manufacturing, and documents.

The Hay text and model diagrams are on a generalized business level and appear to be adaptable to almost any appropriate business. In a final chapter Hay covers a few topics in more detail, such as categories, addresses, roles, and mathematical expressions. These too apply generally to any subject area.

Patterns also includes detailed footnotes and references, a useful bibliography, and a very detailed index that includes such minutia as an entry for “pipe Vs fluid path.” The table of contents includes a detailed listing of the many diagrams and an occasional sample data table.

The informal style writing style of Patterns includes frequent humor, e.g., a Universal Data Model that covers all things in the Universe (which Hay backs off from in a footnote), and not a single detectable spelling or grammar error. British spelling usage, e.g., modelling, rather than modeling, may amuse some American readers. For a technical book, it was fun to read.

Resource

Silverston et al., in The Data Model Resource Book: A Library of Logical Data Models and Data Warehouse Designs, write for a Framework row 3 audience of analysts dealing with systems. Their view is mostly at the information system level, Framework rows 3 and 4, which Dan Tasker calls the solution space in his e-book. These rows are concerned with defining business system problem solutions.

As in the Hay book, Silverston et al. offer a selection of starter diagrams for analysis. In addition they include material on creating a data warehouse from a corporate data model.

Resource starts with an introductory chapter that combines a call for an enterprise approach to systems development using universal data models, with a section on conventions and standards. The credibility of the expert introductory section is challenged by the following conventions section.

In the introductory chapter, Table 1.1 has multiple English mistakes, including the misuse of the word pneumonic (meaning of or affecting the lungs) for mnemonic (a memory device or short code), using pronoun instead of noun, and confusing the meaning of i.e. and e.g. Some of these mistakes occur in other parts of the book as do the correct usage of the same words, showing an understanding of the correct usage.

Silverston et al. could have used a good editor for consistency and a proofreader for typographical and table errors (databse on page 16, substituting much for many on page 216, an omitted with on page 264.) Since the book has multiple authors, it suggests a parceling out of the chapters without a coordinator.

In Resource Silverston et al. offer many diagrams as patterns and structures to start a business analysis effort. These are included in seven chapters covering the basic subject areas of people and organizations, products and inventory, product ordering, order delivery and invoicing, work orders and work tracking, accounting and budgeting, and human resources.

The Silverston et al. text and model diagrams are on a generalized information systems level and appear to be adaptable to any appropriate system.

The final five chapters in Resource explain how to derive a data warehouse data model and show some star schema designs for human resources. These are Framework row 4 and 5 activities.

Both books use Oracle CASE*Method notation, which includes business entities and business relationships. Hay includes an occasional attribute to clarify why certain entities are included, indicating a Framework row 2 viewpoint. Silverston et al. include a 17-page appendix with a detailed index for all attributes in their models, including sample data type, length and precision for each one, useful for a row 3 and 4 viewpoint.

Resource has no bibliography and no references, except for a passing mention of Peter Chen’s original entity-relationship modeling article. A reader might conclude that all the included material is original to the authors for this book. Some of the material in chapters 9 through 13 appears to be based on W. H. Inmon’s own books on data warehousing. Even though he is one of the three authors of this book, there is no reference to that work.

The table of contents does not list the diagrams and many excellent sample data tables. The index, however, seems comprehensive.

Business Rules

A common convention used at the time these books were published was to limit the definition of business rules to the relationships with the cardinalities and optionalities shown on data model diagrams. However, each book refers multiple times to business rules that are outside the scope of the models shown. To all the authors’ credit, this reinforces the notion that business rules are based on but not limited to the data models shown in these books.

Both of these books attempt to generalize their models to be used for as many businesses and systems as possible. They both assume that the general English words they use to name and define the business entities are clear enough for an analyst or business person to understand. Each book has many casual, sometimes vague definitions, and in some cases omits a definition that explicitly defines a business entity.

For one example, Resource generalizes the term container to refer to any unit of inventory storage location, such as a drawer or room, both of which typically do not move. What about barrel, or an ocean-going container that will be loaded and then moved from warehouse to truck and then to a vessel? For greater clarity, these might be split into two concepts: warehouse or storage location, and shipping container. The word container is both too specific and too general at the same time.

Business rules cannot be created effectively until the terms–the business entities–and the facts--the business relationships--are more explicitly defined. The industry awaits a good book on data meaning.

© Michael Eulenberg, 3/13/2000