- 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
These Models and Your Organization
It is important to recognize that this book does not claim to present a single definitive model that will apply to all businesses and government agencies. All company models should not be identical. Rather, these are patterns and structures that can provide a basis for examining a wide variety of situations.
Companies differ from each other. They provide different products and services, and they operate on different scales. They also differ significantly from one another in their operating procedures and organizational structures. Companies differ also in the emphasis placed on various aspects of the business. Where the model of one area of interest may be greatly detailed and sophisticated for one type of business, it may be simple for another. (Even in these cases, however, while the complexity of the models is not the same, the overall data organizations should be similar.)
While these variations dramatically color the appearance and experience of the company, they can be made to reside in the contents of data, rather than in the structure of those data and the systems built to manage them. For example, a data structure that explicitly records the relationships in terms of “divisions,” “companies,” “departments,” and so on would require database maintenance to change that structure. On the other hand, a data structure concerned only with “organizations” and “organization types” could be changed through maintenance of the data. (This example is described in more detail in Chapter Two.)
In any real organization, there will be numerous entities other than those described here. Moreover, a company’s entities may well have different names than those used in this book, and there will certainly be changes to the relationships. It will be the modeler’s job to translate the models here into his or her own organization’s terms. To help the modeler, however, this book will include references to possible variations on many of the models.
Models and Systems: A Word About Implementation
Data models are only of value if they can be used as the basis for designing real systems that will provide value to an organization. Data models are typically converted into relational databases by mapping each entity to a table, and each attribute to a column. Many-to-one relationships in the data model become foreign keys in the “many” table, pointing to rows in the “one” table. Supertypes, subtypes, and arcs (described in the next chapter) require some decisions to be made before they may be implemented. For the most part, however, conversion of a data model to a database design is a mechanical process, and most CASE tools will do it at the press of a button.
The models presented in this book, however, are more abstract than those typically used to develop real systems. This causes some developers to be uneasy about developing databases from them. Because of the peculiar nature of the models created using the approach described in this book, two assertions about the implications of these models on the systems that result from them are in order:
First, if these models are implemented as shown, the resulting systems will be much more robust and flexible than if they are not. The tables will be organized according to aspects of the enterprise that are unlikely to change soon. As mentioned above, the content of the tables will define much of what traditionally has been part of program code and table structure. The user will now specify the configuration of the business, rather than the programmer. This is not what we are used to, but it is not a bad thing.
Second, these models are expected to be produced during the strategic planning and requirements analysis phases of system development. They are not intended to represent the physical structure of databases that are finally implemented. In response to problems of processing time, system capacity, or other constraints, the designer may have to construct database structures that differ from these, in order to reflect the circumstances of the particular system being built.
Remember, however, that the technology and its limitations will change. An accommodation made today to relieve a particular bottleneck may be completely inappropriate three or five years from now.*
It is important for those who follow to be able to distinguish between the aspects of a design that were responses to implementation considerations and those aspects that represent the underlying problem. If the conceptual data model remains available for reference (ideally, along with documentation of the rationale behind each design decision), a subsequent designer will be able to make this distinction.