Slideshow Don’t Make These Data Modeling Mistakes

  • April 02 2012, 5:47pm EDT

Forgetting that Enterprise Architecture is Alive

Many project plans arrive with a start and end date for the data modeling effort, where the logical model ends one day and the physical model starts the next, with no tasks or resources assigned for refinements. Every phase of a project can lead to refining previous decisions, understandings and changes due to external influences. Traceability is also key to realizing the benefits of an enterprise data management program.

Keeping Data Models Invisible

Models need to be available in an easily searchable manner, including definitions. A model without definitions is just a diagram that could be interpreted in many ways, so it is important to supply the entire model with definitions and appropriate metadata. It makes sense that the more available models are, the more likely they will be used by a wide variety of IT and business professionals. Implementing things like an enterprise data dictionary can ensure data definitions are consistently used and understood across an enterprise. Social media-based features are also emerging in data modeling to encourage more sharing and collaboration.

Content Continues Below

Assuming that Business Users Can’t Understand Models

Business users will resist reviewing models if they do not have the proper training, or if presenters have unclear and inconsistent methods for presenting the models. Most business users can understand and review models if they are given proper training, if they are guided through a structured review process and if they have regular access to the models. One or two days of user-targeted training can expose these valuable team members to the issues a modeler faces in creating and maintaining a model, as well as the goals and benefits of an enterprise approach to modeling.

Thinking Models are Only About Databases

Logical models, with their technology independence, organize data requirements in a manner that no text-based document alone could do. Physical models allow team members to see how business concepts are implemented without having to provide access to production systems. Data models should be made available to team members who are developing related models, such as UML Class Models and XML schemas. Allowing team members to import and export metadata contributes to a model-driven design environment and establishes integration of model metadata with other platforms.

Throwing Models Over the Wall

A modeler should be involved in how the requirements are captured as well as how they are implemented. They should understand where they are implemented, and what changes, if any, have been made due to technical constraints or performance requirements. A data modeler is the mediator between business requirements and physical implementations. A “throwing over the wall” approach will lead to round-trip modeling, which is almost always going to be a manual process that is prone to errors and will slow down the benefits inherent in enterprise DM. Synchronized models and denormalization mapping are features that help avoid this mistake.

Content Continues Below

Leaving Out the Sizzle

Model diagrams should include guides so the non-modeler can follow the intent and meaning of modeling objects. They should be easy to read and well commented. Models should be interesting, and the successful data modeler must never underestimate the value of sizzle. By simply jazzing up models with color and by diagramming objects, it not only customizes the models for an enterprise, but it also makes the user review process more engaging and enjoyable.

Defining Them as Your Models

The models should be presented as belonging to the business and tended to by the modelers. That means sharing them openly, providing access to those who want it, keeping extra printouts available, offering training on how to read them and making every effort to make them clear and understandable. Models and their underlying metadata should be seen as corporate assets to be managed by a partnership of modelers and the business. If they are portrayed as just technical specifications that can be understood only by developers and database administrators, they will not provide the benefits of an enterprise data architecture.

Additional links on data modeling ...

For a full article exploring enterprise data modeling mistakes by Karen Lopez and Kamille Nixon, click here. For more, visit’s page geared toward data modeling thought leadership and news.