 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > A guide to conceptual data models for IT managers |
| |
|
|
|
|
| Book Chapter: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||
A conceptual data model Data modeling is arguably the most widely used technique in modern systems analysis and design, but it isn't always used well. Too often, technically oriented "modelers" jump straight into excruciating detail, dense jargon, and complex graphics, incomprehensible to process-oriented participants and other mere mortals. The root problem is a misconception—data modeling has been equated with database design. That's like equating architecture with the drafting of construction blueprints. Of course, the architect's work will eventually lead to precise, detailed blueprints, just as the data modeler's work will eventually lead to precise, detailed database designs, but…it can't start there, or the subject-matter experts will soon mentally "check out." Without their participation, the data model won't be a useful and accurate description of their business. And that's exactly how a data model should be regarded—not as a database design, but as a description of a business.
How do we gain more precision around hard-to-define concepts like Change or Configuration Item? One technique used for many years is an "entity relationship model." Other (not necessarily synonymous) terms used in this general area are "conceptual model," "logical model," "domain model," "ontology," and "class model." An entity relationship model helps clarify language by relating concepts together in certain ways:
Figure 3.1: Data modeling key
Some data modeling methodologists emphasize naming the relationships (typically with a verb phrase such as "is a part of"), but others do not see this as critical, and this book does not systematically do this. Using these tools, we can start to carefully structure the relationships between the various loosely used terms of IT governance (Figure 3.2). Pictures such as this only tell part of the story. They require a detailed discussion of each box (or entity), what it means, and how to interpret the lines (relationships) to the other boxes. Figure 3.2: IT enablement conceptual model
Figure 3.2 is a conceptual data model. It is primarily about refining language and concepts. The goal of this model is not technical precision but rather resonance with common industry usages, which overlap and are not well delineated. It's an attempt to push common usage toward more rigor and admittedly encounters a number of problems in this effort.
It also deliberately omits a number of details that would be necessary to realize a solution. Attributes obviously are not included (e.g., Serial Number on Machine or Date Signed on Contract). Omitted entities are generally intersection entities and dependent entities that elaborate on the core concepts. Some notes on possible approaches for elaborating this into a full logical data model are covered in the data definitions. Building a model such as this for an industry that is not yet mature in its process best practices and terminology is challenging. The relationships among entities such as Release, RFC, Service Request, Project, and Configuration Item might have many permutations. This is a reference model, presented as a starting point for your own analysis. Reasonable professionals may come to different conclusions about which entities should be related to which. This picture, technically speaking, is not the model. It is only one view on the model. One characteristic of a good conceptual data model is that its central concepts can be represented with a one-page view; there are always more details to add. Thus, in the subsequent sections other entities will appear, along with relationships not drawn in Figure 3.2.
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
