Time to move on to something…better{1}

by Stephen O

When is it time for something new? When is a good time to trade up? Is it similar to buying a smart phone? Waiting for the new model later that year? Is it when the industry chooses a standard like Blue Ray or VHS? On the other hand, is it like buying a car and it no longer can perform reliably the duties we purchased it for? When is it time for us to transition to the next generation of Data Modeling?  In the article “Toward a Next Generation Data Modeling Facility: Neither the Entity-Relationship Model nor UML Meet the Need” the author went about explaining why perhaps it is time to move on towards the next generation of Data Modeling.  They defined five wanted characteristics of a Data model.

1. Sufficiently robust to readily express the users’ perceptions

2. As simple as possible

3. Independent of any physical database model

4. Utilize domains with inheritable properties

5. Readily support database migration

Of the five wanted characteristics, these are the most important

Sufficiently Robust
The features and functions of a data model must be powerful enough and varied enough to support the user’s perceptions of entities in their world.  In addition, the means to have additional features and functions that would allow for the modeling of semantic constructs.

“…suppose the user wants to keep track of customers and indicates that those customers have an Address that consists of Street, City, State, and Zip. Additionally, the user states that Address is not required, but that if any portion of the Address is provided, then all of the elements of address become required. Thus, in a data entry form, the user need not enter any part of address, but if the user enters a value for, say, City, then all of the attributes Street, State, and Zip become required.” (Kroenke & Gray, 2006)

As simple as possible

While it should be “Robust” enough for the user to create the users perceptions of entities in the real world it should be simple. Because the model is based on the user’s semantics, the users are the only ones that can verify that it is correct. The bigger the model the more complex it grows and reducing the complexity as much as possible is necessary. “When we worked on the Army CALS project, we developed a data model of the U.S. Army’s logistical data that involved some 1200 entities…The data model developed over eight months and entities that were defined in month one would turn out to have relationships to entities defined several months later. Managing the complexity of this project was the single most important factor for success. In such projects, any reduction in notational complexity pays huge dividends in cost reduction and quality improvement.” (Kroenke & Gray, 2006)

Independent of Any DBMS and Database Model

A data model is a representation of the user’s semantics and should not be limited by being forced to include characteristics of the current models, which make no sense in the user’s semantics. It should not be forced to include characteristics that are unnecessary by any model. In the simplest terms we should not have to change the user’s semantics to due limitations in the current data models available to us.

Then article goes on to talk about the Entity relationship Data Models, how they came about, and who created them. It goes on to discuss products like Visio, and how compared to some other ER Modeling products it is a poor choice due how it is poorly designed and its overwhelming complexity. “The Visio data modeling template was poorly designed, and clearly was constructed by engineers who knew little of data modeling. In truth, it is nothing more than a table representation tool. For example, it is impossible to express a N:M relationship in Visio. All such relationships must first be decomposed into two 1:N relationships using intersection tables. Such representation has nothing to do with modeling the users’ semantics – it is artifact of the relational model and properly belongs late in the database design process…It teaches too many bad habits, it is far too complex, and, because of its complexity, Visio data models are exceedingly difficult for users to validate.” (Kroenke & Gray, 2006)

Then it dives into why the Entity relationship Model is bad, that the whole way the data is modeled is not we humans naturally think. We do not think of relationships as things, it is a “burden” to ask users to think of the cardinalities of relationships that we naturally do not comprehend. “Based on years of data modeling experience, we are convinced that there is a fundamental conceptual problem with the E-R model: namely, it represents entity relationships! Most users do not think of relationships as things. Until we study data modeling, in fact, most human beings to do not think of relationships as things. We are forced to think that way as part of our database education..” (Kroenke & Gray, 2006)


It is when we look at the five characteristics of a desirable model and compare it to the models in use today that we see that Models like the Entity Relationship Model and UML fall short. They  are inherently flawed, flawed in how we teach them, how learn them, and ultimately how we have to alter our thinking to work with them. We are hindering ourselves in so many ways by not creating a next generation Data Model to use.

It is an obvious choice, think how much we are limiting ourselves by having to adapt to a system that doesn’t meet all the desirable characteristics of a data model.  When we encounter a wall we find a way around said wall, we do not lower our head’s and charge into the wall until something gives, but that is what we are currently doing! Do you not think we should be working with a model that is more comprehensive with how we think? Something that meets all the simple needs the users require without cumbersome restraints? Thoughts?

Kroenke, D. M., & Gray, C. D. (2006). Toward a next generation data modeling facility: Neither the entity-relationship model nor UML meet the need. Journal of Information Systems Education, 17(1), 29-29-37. Retrieved from http://search.proquest.com/docview/200135042?accountid=10357