This article continues the discussion of a central question about data modeling: Is it a descriptive or a creative (design1) process? In the first part, we looked at the data modeling environment, and data modeling problems. Here we cover two further dimensions: process and product, including the “one right answer” issue.

In this paper, Part 2 of a series, I will show you some of the techniques you can use to quickly review a data model for the most common mistakes made by data modelers. The list of mistakes is by no means exhaustive – it’s a list of mistakes that I have identified over the course of 20 years, by working with and reviewing models developed by everyone from novices to experts.

In spite of the issues and obstacles involved, I firmly believe that the use of views in databases affords the best hope of bringing developers and DBAs together, facilitating the application development process, and bridging the object-relational gap. I encourage developers and DBAs everywhere to seriously consider this approach.

This article represents Dave Hay's first public use of the term “essential data model”. This is equivalent to what he has always referred to as an “architectural data model”, serving Row Three of his version of the Zachman Framework.

This article explains an application development approach advocated by many proponents of agile application development that can cause future problems for developers, while potentially sacrificing the integrity and reusability of the data.

Many of today’s apps are built around a single data model, typically persisted to a data store via an object-relational mapper (ORM) tool. But sometimes—for several different reasons—you may need more flexibility, which requires multiple models. In this article, I’ll discuss some strategies you can use to handle these situations and develop more layered and robust applications.

Just as a transformation is required to convert an entity/relationship model into a relational database design, so is one required to convert an entity/relationship model into an object-oriented design. This may involve an automated process of attaching class names to role names, as well as manual efforts to add UML design adornments such as navigation and composition (and, of course, behavior). Because the meaning of the models is different, should the notations be different? There are strong arguments for making it so, but these articles attempted to show that this is not required for the models to make sense. Whatever notation is used, precise, semantically clear models can be produced. To do so is worthwhile, regardless of the particular experiences of the modeler.