Издательство Elsevier, 2011, -408 pp.
I would like to start by explaining how I came to write this book, and to acknowledge its influences and the help I have received along the way.
I have been extremely fortunate. I have a wonderful wife and two wonderful grown-up children, and I have had all but thirty years working for Shell, which provided an environment that had stimulating challenges and opportunities to look more deeply at problems than is often the case.
I first came across computers in 1971. My undergraduate course was in Chemical Engineering at Leeds University, and we all had to lea how to write basic Fortran programs in our first year. I went on to do a PhD, which involved mathematical modeling of chemical processes and led to my developing an automatic integrator for stiff ordinary differential equations. As a result I am probably among a relatively small group of people who have started a computer by loading the bootstrap program into memory from the switches to boot up the computer.
I joined Shell in 1978 at Shell Haven Refinery on the north bank of the Thames estuary, east of London. I was immediately thrown into the implementation of a computer supervision system for the Crude Distillation Unit, which monitored the hundreds of measurements taken around the unit and waed of deviations from target performance. I spent eight years at Shell Haven, and while I had a wide range of roles, computers and computing were a recurring theme. I was, for example, responsible for the purchase of the first IBM PC on the refinery, and one of the first in Shell for engineering calculations using a spreadsheet, and at the time I left the refinery I was responsible for all the mini-computer based systems on the refinery.
My next move was to London in 1986, where I was a business analyst on one of the first relational database (DB2) implementations in Shell, the Oil Management Project. This was an information system designed to produce an overview of the planned and actual production and sales of oil products by Shell in the UK. It was here where I first came across data models in the Shell UK Oil data architecture and Bruce Ottmann, who ran the data architecture team and who became a major enabler and encourager of much of the work I have done in data management. I immediately found data models fascinating. As a chemical engineer, I was very used to a process view of the world, and data models gave a completely different perspective. I was hooked.
I spent 1989 in The Hague working for Jan Sijbrand. He had a vision for a system’s and data architecture for refineries such that a common suite of systems could develop and evolve to support refinery operations. My part was to develop the data models, which was done through a series of workshops, led by Bruce Ottmann, by now leading the corporate data management group. Ken Self, later to be one of my bosses, was one of the attendees.
I retued to London in 1990 to work for Bruce in a project called the Data Management Key Thrust. Shell’s Committee of Managing Directors had noticed that IT costs were rising exponentially, but it was not clear why so much money was being spent, or whether it was delivering value. They issued an edict that IT costs were to be capped and instituted a number of Key Thrusts to improve matters. The Data Management Key Thrust was one of these.
The next few years were particularly fruitful. What we noticed was that many Shell companies were developing different computer systems to do the same thing, but that these systems were not suitable for other Shell companies. When we investigated why this was the case, we discovered that the data models contained constraints that did not always apply, or meant that historical data could not be held. We looked for and discovered data model pattes that were examples of the traps that data modelers fell into, and what you needed to do to improve those data models. From this we were able to work out principles for data modeling to avoid falling into those traps. We also included a Generic Entity Framework as a high-level data model to help create data models that were consistent with each other. These documents were Reviewing and Improving Data Models and Developing High Quality Data Models, and yes, that is where the title of this book comes from. This book aims to address some of the same issues as the original article, and while there is little if anything of the original documents that has not been updated, some of the same issues and principles are recognizable. Shell made a version of this publicly and freely available and I am pleased to have use of this and to significantly update and extend it.
There was much other work done by that group in information management around information quality and information management maturity that was significant in general, but I will limit myself to the data modeling story.
This book is a distillation and development of what I have leat about data modeling through these many experiences.
Part 1 Motivations and Notations
Introduction
Entity Relationship Model Basics
Some Types and Uses of Data Models
Data Models and Enterprise Architecture
Some Observations on Data Models and Data Modeling
Part 2 General Principles for Data Models
Some General Principles for Conceptual, Integration, and Enterprise Data Models
Applying the Principles for Attributes
General Principles for Relationships
General Principles for Entity Types
Part 3 An Ontological Framework for Consistent Data Models
Motivation and Overview for an Ontological Framework
Spatio-Temporal Extents
Classes
Intentionally Constructed Objects
Systems and System Components
Requirements Specification
Concluding Remarks
Part 4 The HQDM Framework Schema
HQDM_Framework
I would like to start by explaining how I came to write this book, and to acknowledge its influences and the help I have received along the way.
I have been extremely fortunate. I have a wonderful wife and two wonderful grown-up children, and I have had all but thirty years working for Shell, which provided an environment that had stimulating challenges and opportunities to look more deeply at problems than is often the case.
I first came across computers in 1971. My undergraduate course was in Chemical Engineering at Leeds University, and we all had to lea how to write basic Fortran programs in our first year. I went on to do a PhD, which involved mathematical modeling of chemical processes and led to my developing an automatic integrator for stiff ordinary differential equations. As a result I am probably among a relatively small group of people who have started a computer by loading the bootstrap program into memory from the switches to boot up the computer.
I joined Shell in 1978 at Shell Haven Refinery on the north bank of the Thames estuary, east of London. I was immediately thrown into the implementation of a computer supervision system for the Crude Distillation Unit, which monitored the hundreds of measurements taken around the unit and waed of deviations from target performance. I spent eight years at Shell Haven, and while I had a wide range of roles, computers and computing were a recurring theme. I was, for example, responsible for the purchase of the first IBM PC on the refinery, and one of the first in Shell for engineering calculations using a spreadsheet, and at the time I left the refinery I was responsible for all the mini-computer based systems on the refinery.
My next move was to London in 1986, where I was a business analyst on one of the first relational database (DB2) implementations in Shell, the Oil Management Project. This was an information system designed to produce an overview of the planned and actual production and sales of oil products by Shell in the UK. It was here where I first came across data models in the Shell UK Oil data architecture and Bruce Ottmann, who ran the data architecture team and who became a major enabler and encourager of much of the work I have done in data management. I immediately found data models fascinating. As a chemical engineer, I was very used to a process view of the world, and data models gave a completely different perspective. I was hooked.
I spent 1989 in The Hague working for Jan Sijbrand. He had a vision for a system’s and data architecture for refineries such that a common suite of systems could develop and evolve to support refinery operations. My part was to develop the data models, which was done through a series of workshops, led by Bruce Ottmann, by now leading the corporate data management group. Ken Self, later to be one of my bosses, was one of the attendees.
I retued to London in 1990 to work for Bruce in a project called the Data Management Key Thrust. Shell’s Committee of Managing Directors had noticed that IT costs were rising exponentially, but it was not clear why so much money was being spent, or whether it was delivering value. They issued an edict that IT costs were to be capped and instituted a number of Key Thrusts to improve matters. The Data Management Key Thrust was one of these.
The next few years were particularly fruitful. What we noticed was that many Shell companies were developing different computer systems to do the same thing, but that these systems were not suitable for other Shell companies. When we investigated why this was the case, we discovered that the data models contained constraints that did not always apply, or meant that historical data could not be held. We looked for and discovered data model pattes that were examples of the traps that data modelers fell into, and what you needed to do to improve those data models. From this we were able to work out principles for data modeling to avoid falling into those traps. We also included a Generic Entity Framework as a high-level data model to help create data models that were consistent with each other. These documents were Reviewing and Improving Data Models and Developing High Quality Data Models, and yes, that is where the title of this book comes from. This book aims to address some of the same issues as the original article, and while there is little if anything of the original documents that has not been updated, some of the same issues and principles are recognizable. Shell made a version of this publicly and freely available and I am pleased to have use of this and to significantly update and extend it.
There was much other work done by that group in information management around information quality and information management maturity that was significant in general, but I will limit myself to the data modeling story.
This book is a distillation and development of what I have leat about data modeling through these many experiences.
Part 1 Motivations and Notations
Introduction
Entity Relationship Model Basics
Some Types and Uses of Data Models
Data Models and Enterprise Architecture
Some Observations on Data Models and Data Modeling
Part 2 General Principles for Data Models
Some General Principles for Conceptual, Integration, and Enterprise Data Models
Applying the Principles for Attributes
General Principles for Relationships
General Principles for Entity Types
Part 3 An Ontological Framework for Consistent Data Models
Motivation and Overview for an Ontological Framework
Spatio-Temporal Extents
Classes
Intentionally Constructed Objects
Systems and System Components
Requirements Specification
Concluding Remarks
Part 4 The HQDM Framework Schema
HQDM_Framework