What exactly is a data model? In his book “Data Modelling Made Simple”, Steve Hoberman defines a data model as “a diagram that uses text and symbols to represent groupings of data so that the reader can understand the actual data better.” Behind that diagram will usually be much more information about the data, telling us what it means, what dependencies it has with other data, who owns it, and much more. For every database, there is a data model – what form it takes, and the rigour used to develop it, will vary considerably. A well-developed data model will achieve the requirements of the application being built, without compromising the organisation by introducing unmanaged data duplication, homonyms or synonyms.
I’ve identified four Ds of data modelling, to describe the main reasons why we do data modellling. Different objectives require different types of data model. To find out more about the kinds of data model, see my page on the Pyramid.
- discover what data you have, where it came from, and how you use it
- may result in the creation of Enterprise, Conceptual or Logical Data models, as well as additional metadata
- describe what you already know about your data, where it exists, where it came from, and where you use it; such models are likely to be very detailed, and reflect the physical implementation (databases, XML Schemas, etc)
- describe the data you would like to manage, in a way that reflects the terminology and understanding of the business; such models could be developed at any level of the data modelling pyramid, perhaps reusing or providing mappings to externally-supplied data models
- construct models that describe the structure of new IT artefacts, such as databases or messages
- ensure that these models reflect and map to any preferred data structures
- create real IT artefacts from a data model, such as databases or XML schemas; manage changes to those artefacts; enable impact analysis