Introduction to Data Model Patterns: Conventions of Thought
- Data Modeling's Promise?and Failure
- About Modeling Conventions
- These Models and Your Organization
- Who Should Read this Book?
This chapter is from the book
This chapter is from the book
This chapter is from the book
A data model is a representation of the things of significance to an enterprise and the relationships among those things. It portrays the underlying structure of the enterprise’s data, so this can then be reflected in the structure of databases built to support it.
This book takes the position that the underlying structures of many businesses and government agencies are very similar, and that it should therefore be possible to model these similar structures in similar ways. Using common shapes for common situations makes the models easier to read, and it guides the modeler closer to identifying truly fundamental things.
Data Modeling’s Promise—and Failure
Data modeling* serves two purposes in the systems analysis process: First, as a graphic technique, it aids in communication between analysts and the ultimate users of the systems they will specify, and between analysts and those who will design and build systems for those users. Second, as a rigorous technique, it imposes discipline on the specification of problems, ensuring due consideration of logical implications.
Creation of a data model is supposed to focus the user’s, the analyst’s, and the designer’s attention on things that are most fundamental to the nature of the business. The technique promises to lead to the development of stable, robust, and reliable information systems, so that normal changes in the business will not affect them. Moreover, data models promise to be useful as the basis for discussions among all three sets of players (users, analysts, and designers) about the future of information systems development in the organization. A data model can show, for example, the effect that a change to the organization will have on its information systems.
Alas, data modeling has not always kept these promises. If it is not used effectively, the technique neither improves communication nor imposes discipline.
Data modeling as currently practiced suffers from two problems:
- Diagrams are often difficult to read.
- Diagrams do not represent the fundamental nature of the organizations they are supposed to describe.
Herein lies the purpose of this book. It describes an approach to data modeling that can restore those promises by producing models that are both clearer than those produced without using this approach, and more likely to address fundamental issues.
Clarity
As typically produced, data model diagrams can be less than inviting. While the use of graphics is supposed to make the ideas presented more accessible, the use of graphics without regard to aesthetic principles has the opposite effect. A mass of boxes and lines with no identifiable shape or organization aids in neither the understanding of an organization nor the planning of its future systems development efforts. A common reaction to the typical data model is: There are so many symbols! Where do I start? What is really going on here? How can I use this?
Defining a set of symbols to represent data structures is not enough. It is necessary to add a method for organizing those symbols, so that the reader of the model can deal with the drawing as a whole. It is also necessary to apply some aesthetic standards, in order to ensure that meaning encoded in the symbols can be accessible to the viewer.
Fundamentals of the Business
If you choose to build a new system, you want it to reflect the true requirements of your business—not simply to reproduce the techniques and technology now in use. The reason for making the investment in the first place is that you want to change the way things are done, without necessarily changing the nature of your enterprise.
A data model can help change the way things are done without affecting the nature of your business if it presents what is unchanging in an organization. It is intended to portray the things of significance, about which the company wishes to hold information. If the model succeeds, the things represented are unlikely to change significantly, either with the application of new technology (computer or other) or with the making of routine changes to the business of the organization. Technology whose architecture is based on what is fundamental will improve the operational aspects of an organization while remaining robust, stable, and flexible.
Unfortunately, what most people see in the course of their work (and consequently tell systems analysts about) is not this unchanging nature at all, but merely examples of it. They see only today’s problems, and the particular technology they must use to do their jobs—to the point that the technology becomes their job. Since the information an analyst gathers, therefore, is usually expressed in terms of current practices, distinguishing between what is essential to a business and what is merely an accident of current technology is not always easy. The essential facts are the things that “go without saying”—so they don’t get said. These facts don’t get described or explained—or reflected in new systems. Instead, new systems are often built on superficial views of today’s problems.
A plant that makes carbon black for printing ink and tires spent many weeks discussing the best ways to determine production rates and yields. The discussions concerned the best ways of predicting yield from the grade of natural gas that was used, but clearly something was not getting across. Finally, the manager let slip the fact that yield is also a function of the production unit used. The yield varies from unit to unit. This was obvious to him, so he didn’t mention it. Because it was not so obvious to the analyst, the original database design had not taken this into account and had to be substantially redone.
The elements of a business that are typically portrayed in data models reflect this difficulty. Instead of these essential facts about a business, model diagrams are often dominated by references to the objects that represent the particular way things are done now. A careless analyst may interpret transient things to be things of importance. The resulting model will reflect only those things that are important to current business practices.
A purchasing agent, for example, might describe the company’s purchasing system, giving special emphasis to its shortcomings (such as the fact that there may not be enough room on a purchase order for notes), while neglecting to describe the essential facts about a purchase order (such as the fact that “terms of sale” must appear). To build a new system based solely on the structure (and failings) of an existing system is to fail to take advantage of technological opportunities. Suppose, for example, purchasing were to do away with paper forms altogether and dial directly into vendors’ computers. What would remain essential to the transaction?
How Standards Can Help
Both communications and discipline can be improved. Moreover, we can make better use of each other’s work. What is needed is standardization of our approach to the modeling process. This does not mean simply using a common system of notation, although that would certainly help. What it means, rather, is using a common approach to the way we think about business situations, and to the way we organize our presentations of them. This book is about these “conventions of thought.” It identifies common situations that are present in a variety of businesses and government agencies, and which can be modeled in a standardized way. This standardization can make models both easier to read and more descriptive of what is fundamental to an enterprise.
The modeling conventions presented here are an attempt to establish that common approach to modeling. They do not represent the final models of any real company or agency. Rather, they are starting points, showing ways of looking at a business situation that should allow an analyst quickly to come to terms with the most important aspects of it. Having done so, the analyst is expected to apply creativity and imagination to adapt technology to those aspects.
Each chapter of the book presents concepts fundamental to a topic. It describes a typical business situation, provides basic models for portraying the situation, and enumerates variations that can be expected across different organizations.