Introduction and manifesto for entity model patterns

This booklet is published under the terms of the licence summarized in footnote 1.


This is not the first book on entity modelling. This one begins by reviewing well-established principles. But it goes on to say many new things, and it ends up challenging the prevailing orthodoxies.


Is this a book on logical data modeling for analysts?

Yes. It is about ways to define a logical data model that specifies business rules.


Is this a book on physical data modeling for database designers?

Not really. It does have some relevance to defining a physical data model that becomes an efficient database structure, but this is not the main aim.


Is this a book on class diagramming for OO programmers?

Yes. It is meant to be about ways to define an OOP "class diagram" that can be implemented as Java classes on an app server.


This book takes a view of entity modelling that spans conventional relational data analysis and object-oriented software design for enterprise applications. It presents principles that apply to drawing database schemas and object-oriented class diagrams. It suggests object-oriented and relational paradigms are narrow views of a broader field.


The book presents a new knowledgebase of patterns for drawing an entity model. Entity model patterns are analysis patterns first and design patterns second. The analysis goal is to find out what the business rules are and specify them correctly. The design goal is to design a structure that meets performance requirements and can be readily maintained. The book presents a new knowledgebase of transformations between closely related patterns that help you to meet these goals.


Readers will range from analysts and designers working on enterprise applications, to students of computer science. For readers familiar with UML, an entity model is a kind of a class diagram; you may choose to stereotype the classes with <<entity>> under the class name.

Helping professional analysts and designers

It has been reported that 70% of the world’s programmers are writing code for enterprise client-server systems. An enterprise application supports a business by providing it with information about the real-world objects that the business seeks to monitor and perhaps control.


At the back end of an enterprise application are the layers of software that manage the stored data. Software that manages data about the real world is crucial. The enterprise has to invest a lot of time and money in specifying and coding business rules to ensure its stored data tells a true and consistent story about the business domain the enterprise operates in. Data integrity is the challenge for enterprise architects.


  • “If users don’t trust your data, your database is garbage” IT director of a major telecommunications company.
  • “Problems with data integrity at one company turned a 2 month exercise into an 18 month exercise.” Information Week May 19th 1997.


Almost every enterprise application is built on top of an entity model. Yet knowledge of how to build an entity model to capture business rules and ensure data integrity is thinly distributed. This book is immediately help to anybody working on an entity model.


Your time is at a premium. Patterns save you time. You can apply many of the patterns immediately. They help you

  • adopt modern analysis techniques that work with new technologies
  • extend database development methods with object-oriented analysis
  • understand and address the limitations of object-oriented analysis and design methods.


It is clear that many, perhaps most, applications have been written with little or no methodology. But most of our legacy systems only worked properly after a protracted process of iterative development, they contain redundant code and they are difficult to maintain.

A new angle for academics

The beginning of wisdom for an analyst or designer is to realise that a one-dimensional methodology, be it object-oriented or relational, is only part of what is needed.


This book describes the specification of business rules and constraints in a style that can be reconciled with formal specification. In doing so, I hope to break the stranglehold that the ‘object model’ ‘and relational theory’ and have over university teaching. Both theories make good servants and poor masters.


We need a broader theory that encompasses process structure as well as data structure, and event-orientation as well as object-orientation. This book also sheds light on various debates about object-oriented software design. E.g. it illuminates the difference between type-based and state-based theories of what a class it.

The place of an entity model within a logical model

Models are tools we use to analyse and define the requirements for software systems. A comprehensive model defines both structural things/features and behavioral things/features. I discuss the modeling of behavioral things/features in a companion volume, “The Event Modeler”, and only very briefly in this one. This book focuses on modelling structural things/features in the form of an entity model; see the What column in the table below.


Models are drawn at various levels of abstraction, from models of code in a specific programming language, through specifications for such code, to specifications of an enterprise regardless of any software that might be written. This book focuses on the specification of an enterprise application; on the middle row in the table below.


The table below is the RAP group modelling framework.



Structural model

Behavioural Models




Conceptual model

Real world entities

Business processes

Real world events

Logical model

Data entities

Entity life histories

Data events

Physical model

Entity objects and database tables

State constraints on procedures

Control objects and services


David Hay (ref 99), who draws entity models for the purpose of enterprise modeling, has given me permission to copy substantial chunks of my email dialogues with him.

In ordinary conversation, entity can mean an entity instance (an object) or an entity type (a class of objects). Similarly, model can mean a live model (a running enterprise application models the real world) or a dead model (a specification for a live model). I started writing this book with careful attention to such distinctions. This pedantry made the text unreadable. I believe you will find it is easier to interpret the words entity and model according to their context, as you do in conversation.

An entity model lies at the heart any enterprise application. An entity model shows a structure of entities, attributes and relationships, annotated with business rules. Entity models are used by software engineers working on enterprise applications to:

  • refine a higher-level enterprise model for a specific project
  • facilitate discussions with business people and clarify requirements
  • specify the business rules and processing constraints for developers
  • specify an object-oriented class structure from which business services are coded
  • specify a database structure against which data services are coded


Trying to meet all of these goals in one model creates some tensions that are reviewed in this book.

Helping the Agile Modeller

The Modeller traditionally takes the view that specification and design up front are important.

The Agilist tends to the view that design up front is a waste of time, that models are a distraction from real work, that success depends mostly coding, testing and verbal communication.

The Agile Modeller knows a variety of approaches and embraces the philosophy of a well-known guru.


  • “It is important not to be dogmatic. Every approach has its advantages and limitations. You must use a mixture of approaches in the real world and not mistake any one of them for truth”. James Rumbaugh


The Agile Modeller keeps an entity model simple, is aware of different modeling options, understands trade offs between them, and introduces complexity only when and where it is needed.


Getting the entity model "right" is less straightforward than a course in either object-oriented design or relational data analysis might lead you to believe. Entity modelers face awkward questions to be explored later. When should I include a class hierarchy in an entity model? When should I build constraints into an entity model and/or database structure? It helps to understand patterns and transformations in models.

Analysis patterns manifesto

It is increasingly apparent that analysis and design processes are not enough. There is more wisdom to be taught through patterns for analysis and design, and rules of thumb, than through the stages and steps of a process


The analysis patterns in this book are similar to object-oriented design patterns in some ways, and different in others. I will highlight a few points of correspondence, but the emphasis here is mostly on analysis and design questions for enterprise applications.


For more years than I care to remember, I have taught analysts and designers to recognise patterns in entity models (cf. class diagrams) and other kinds of model. As long ago as 1994, Grady Booch pointed out the kinship between my ‘analysis patterns’ and Coplien’s work on ‘generative patterns’ for object-oriented design. This prompted me to document my patterns more thoroughly. I ended up with many more patterns than one book can accommodate, so I have to publish the entity model patterns and event model patterns separately.


·        Patterns raise productivity. They speed up thinking and help you to avoid mistakes. They apply equally to rapid and slow development, to engineering of new systems and reengineering of legacy systems.

·        Patterns raise quality. They help you to elicit requirements. They prompt you to ask business analysis questions and quality assurance questions. Look out for the bad patterns as well as the good ones.

·        Patterns connect things. They are recognisable structures or templates that capture expert knowledge about connecting the components, classes and objects of a software system, via interfaces, relationships and events.

·        Patterns make wider connections. They enable you to link apparently distinct analysis and design techniques, coordinate different views of a system into one coherent specification, reconcile object-oriented and relational ways of thinking.

·        Analysis patterns help you to get things right, discover the relevant requirements and design so as to minimise redundancy. If one or two of the patterns and questions save you a few days effort, then this book will have paid its way.



Assenova P. and Johannesson P. [1996] Improving Quality in Conceptual Modelling by the Use of Model transformations Stockholm University

Boman M. et al. [1993] Conceptual Modelling Stockholm University

Booch G. [1994] Object-Oriented Analysis and Design. Benjamin Cummins

Darwin C. The Origin of Species J M Dent and Sons (1956 edition, pp 56 and 59)

Dawkins R. The Blind Watchmaker

Gamma E. et al. [1995] Design Patterns Addison Wesley

Graham I. [1993] Object-oriented Methods Addison Wesley

Halpin T. [1995] Conceptual Schema and Relational Database Design Prentice Hall

Hoare A. [1986] Communicating Sequential Processes Prentice Hall

Hay D. Data Model Patterns ISBN: 0-932633-29-3

Jackson M. [1975] Principles of Program Design Academic Press

Jackson M. [1994] Software Engineering Journal

Mellor S.J. & Shlaer S. [1988] Object-Oriented Analysis Prentice Hall

Meyer B. [1988] Object-Oriented Software Construction Prentice Hall

Ovum Evaluates: Workflow (1995) Ovum Ltd. London

Palmer J. [1993] ‘Anti-hype’ in Object Magazine. May-June issue.

Partridge C. [1996] Business Objects: Reengineering for Reuse Butterworth Heinemann

Robinson K. & Berrisford G. [1994] Object-Oriented SSADM. Prentice Hall

Berrisford G. [1995a] ‘How the fuzziness of the real world limits reuse by inheritance between business objects’ Proceedings of OOIS ‘95 conference, Dublin City University.

Berrisford G. [1995b] ‘A review of object-oriented for IS’ Proceedings of OOIS ‘95 conference, Dublin City University.

Berrisford G. [1996] Database Newsletter Vol. 24 No. 6 Database Research Group Inc.

Berrisford G. [1997] The Journal of Object-Oriented Programming SIGS publications New York

Berrisford G. & Burrows M. [1994] ‘Reconciling object-oriented with Turing Machines’ Computer Journal Vol. 37, No. 10

Berrisford G. Burrows M. and Willoughby A. [1997] paper for the OOPS group of the British Computer Society




Ref. 1:   Various papers in the Library at


Footnote 1: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it. For more information about the licence, see