Read an Excerpt
DEVELOPING HIGH QUALITY DATA MODELS
By MATTHEW WEST MORGAN KAUFMANN
Copyright © 2011 Elsevier Inc.
All right reserved. ISBN: 978-0-12-375107-2
Chapter One
INTRODUCTION CHAPTER OUTLINE
1.1 Some Questions about Data Models 3 1.2 Purpose 4 1.3 Target Audience 5 1.4 What Is a Data Model? 5 1.5 Why Do We Do Data Models? 5 1.6 Approach to Data Modeling 7 1.7 Structure of This Book 7
In this Chapter I set out what I am trying to achieve with this book, describe who the target audience is, and look at some challenges in data modeling that I will address.
1.1 Some Questions about Data Models
What is a data model for? Once upon a time a data model was simply an abstraction of the table and column structure of a database that showed how the tables related to each other. (Today we would probably call this a physical data model.) It was not long before the logical data model was introduced, which would be described as "fully normalized." However this type of data model would still be related to the contents of a single database. Another popular sort of data model is the conceptual data model. There are various thoughts about what this type of model is but typically it includes no or few attributes and might be described as being about the things the data represents, rather than about the data contained in it.
Initially these were all data models associated with a single application. But what about integrating data across applications? Enterprise and other sorts of integration data models have been produced to give a single view of an enterprise's data or to support supply chain processes between enterprises in a business sector. Some have said that enterprise data models are either impossible to construct, or not worth it—or is it just that those who have said so do not know how to do it?
Then there are packages. Many said that these would be the death of data modeling. Were they right? How did they design the packages? How do you judge whether an application's data model is fit for purpose? In many cases applications need to be configured; how does this affect whether information requirements are being met, now, and in the future?
Then along comes enterprise architecture. What does this mean for data modeling? What sorts of data models do you need in an enterprise architecture? What other elements do they relate to? How does this affect change management?
Data modeling is a challenging task. It is often seen as a black art that some people seem to have a facility for. So how can you evaluate a data model that you are presented with? If you find some problems, how do you change the data model so that you remove the problem without introducing new ones? Why is it that if you look at the data models produced by different data modelers for the same requirements, it is unlikely that any two of them will be essentially the same, i.e., the same structure and meaning, and only the names of entity types and relationship types differing? How can this be? Are some of the data models wrong? If not, what chance is there for developing data models with overlapping scope that will fit together afterward? What would you need to do to ensure that this is the case?
Possibly you have read books like David Hay's "Data Model Patterns" and thought that these look like great data models, but how do you produce data models like that for other areas?
1.2 Purpose
If some of these are questions you have, then you are reading the right book because I hope to provide some answers. So the purpose of this book is to help data modelers understand the following:
• The purpose of data models in both developing an Enterprise Architecture and supporting Information Quality
• Common problems in developing data models, learning how to recognize them, and making improvements
• How to develop high quality data models, in particular conceptual, integration, and enterprise data models
* How to achieve a consistent approach to data modeling
* How to establish a consistent view of the world
• Some generic data model templates that are reusable in many applications and can be used to develop more specific templates
1.3 Target Audience
This book is for a range of modelers: from those who understand the data modeling basics but who are just starting to learn about data modeling in practice and who want to get on the fast track to developing good data models, through to experienced data modelers who want to expand their knowledge and skills and solve some of the more challenging problems that data modeling introduces.
1.4 What Is a Data Model?
A data model defines the structure and intended meaning of data. However, it should also be noted that a data model is restrictive rather than permissive.
Let me illustrate this with an old joke (well I've been telling it for a long time) about the differences between different European cultures. It goes like this:
"What is the difference between the British, the Germans, and the Italians?" "I don't know, what is the difference?" "Well, for the British it is allowed unless it is forbidden, for the Germans it is forbidden unless it is allowed, and for the Italians it is allowed especially if it is forbidden."
Well data models are like the Germans. It is forbidden unless it is allowed. So if you have not provided the necessary entity types, relationship types, and attributes, then the data cannot be held.
1.5 Why Do We Do Data Models?
Things can go wrong with data modeling; we can forget why we are doing it or not know why in the first place. The results are damaging: resources are wasted and the reputation of data models and those that create them is diminished.
So, what are data models about? In almost any enterprise, the answer is that data models are about improving the quality of information used in making decisions. The key thing here is to understand that quality does not mean ever more accurate. Quality means fit for purpose. So once it is accurate enough, or timely enough, then making it more accurate or available sooner is unnecessary and will probably increase costs without increasing benefits—and the net value of information is another property that is critical to its quality.
The good news here is that this message resonates well with management. They understand that getting decisions right is important and that good quality information is a vital input to decision making, even if they have little awareness of data models themselves. So as long as we can identify how what we are doing contributes to information quality, then we can justify what is being done. The corollary is of course that if we cannot show how what we are doing contributes to information quality, then we should not be doing it—and that is useful to know too.
Figure 1-1 shows the critical properties of information and identifies those that data models support. You will see that clarity—the meaning of data—and consistency—data having the same meaning for different parts of the enterprise—are critical contributions that data models make.
In addition, as you shall see, data models play a key role in the information lifecycle through their role in the design of databases and interfaces, and their subsequent maintenance, so
physical data models have a big impact on the accessibility of information.
1.6 Approach to Data Modeling
It is worth noting at this early stage that the approach I take to data modeling is not the traditional normalization approach, but an ontological one, which rather than looking at and eliminating the repeating groups in data, looks at what the data is about and uses that as a structuring basis for data.
1.7 Structure of This Book
This book is divided into three parts:
• Part 1, Motivations and Notations, covers
* Some basics of data model notation and introduces EXPRESS, the notation I use for the framework in Part 3 and Part 4.
* Some types and uses of data models. Data models are used for a variety of different purposes. In this part, I identify some different types of data models, explore how data models are used in data integration, and look at enterprise data models and determine when to develop them.
* Data models and enterprise architecture. I present an information-centric view of enterprise architecture that shows the place of data models in enterprise architecture. I then introduce an approach to process modeling that incorporates identifying the information requirements of the processes as a starting point for data modeling.
* Some observations on data models and data modeling. Data models have a number of inherent limitations, and it is worth being aware of these so that you can make good choices on how to best support the requirements of a particular data model. There are also some key challenges that data modelers face, which I indentify, and finally, I explain the ontological approach to data modeling and explain the difference between this and a normalization approach.
• Part 2 introduces some general principles for data models:
* Introduces the principles for developing ontologically based data models
* Looks at the application of the principles for attributes
* Looks at the application of the principles for relationship types
* Looks at the application of the principles for entity types
• Part 3 presents an ontological framework for developing consistent data models:
* Develops an ontological foundation including key ontological commitments
* Develops a high level data model for individuals
* Develops a high level data model for classes
* Develops a high level data model for intentionally constructed objects, and works out more detailed data models for organization, person, agreements, and representation
* Develops a detailed data model for systems and system components
• Part 4 provides a more formal representation of the ontological framework in Part 3.
Chapter Two
ENTITY RELATIONSHIP MODEL BASICS CHAPTER OUTLINE
2.1 Oh, It's Boxes and Lines Again ... 9 2.2 Graphical or Lexical 10 2.3 Graphical Notations: Complexity vs. Understandability vs. Capability 11 2.4 Language and Notation Elements 12 2.4.1 Nodes 12 2.4.2 Links 12 2.4.3 Rules and Constraints 13 2.5 Express-G 13 2.5.1 Notation 13 2.5.2 Attributes and Relationships 14 2.5.3 Reading Relationships and Cardinalities 15 2.5.4 Redeclared Types 16 2.5.5 Representing a Many-to-Many Relationship as an Entity Type 16 2.5.6 Subtype/Supertype Relationships 17 2.5.7 Off-Page Connectors 18 2.6 Notation for Instances and Classes 20 2.7 Layout of Data Models 21 2.7.1 Subject Areas for Presentation and Definition 21 2.7.2 The Layout of the Page 21 2.8 Reflections 22
This chapter introduces a number of notations for representing data and data models and considers some of the basic limitations and choices that have to be made in developing data models.
2.1 Oh, It's Boxes and Lines Again ...
There are a plethora of different notations for data models, and in addition to that, we sometimes need to model data instances to get the true picture of what is going on (indeed, this is one of the secrets of successfully modeling complex domains). One of my friends and colleagues, Jan Sullivan, has been around long enough that when presented with a new diagramming convention for data models, he studies it earnestly, asks some pertinent questions, and then allows a look of comprehension to pass across his face as he exclaims, "Oh, you mean its boxes and lines again!"
I will not be using just one set of data modeling diagramming conventions and will certainly not be using all the ones I have come across, but rest assured, they are all boxes and lines! In this chapter, I shall be setting out some of the things to look for in diagramming conventions and explaining the particular ones I shall use in this book.
(Continues...)
Excerpted from DEVELOPING HIGH QUALITY DATA MODELS by MATTHEW WEST Copyright © 2011 by Elsevier Inc.. Excerpted by permission of MORGAN KAUFMANN. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
