It’s Always a Data Modeling Question…

When you have been a data modeler for [redacted] decades, you learn to see the world through data modeler eyes.  Everything seems to be a data modeling question.

I was with a client for lunch one day and we asked the server “What do you have on tap?”  She was gone quite a long time, but came back and said “Beer.”  It turned out she was right.  But her answer was not that helpful.

Why is an Expert Asking Us What a Data Model Is?

One of the odd parts of every new project I have to deal with is getting everyone to understand that the question “Can you help us with a data model” results in me asking. “What do you mean by data model?” That’s right, I have to ask team members what a data model is. You’d think experts would know better.

I have to do this because it seems like everyone has a different definition.  For most DBAs, they want a reverse-engineered image of a production database.  For a business user, data modeling that results in documentation about all the questions, answers and decisions were made. For a developer a specification of something they can build upon. An executive wants a high-level view of the data concepts a specific project will be addressing so she can approve scope and budgets.  A data scientist wants a consolidated view of both the physical data objects available to him and a logical definition of what they are. Finally, a data modeler wants a list of previously modeled entities so that she doesn’t have start from scratch on every project.

It’s likely that every role in the organization wants a different data model with a different set of metadata. It’s also why we need to have a discussion about conceptual, logical and physical data models.   Even that set of terms has differing definitions. That’s nearly unforgivable given that we data modelers preach that we should use consistent definitions. (Note from author: this one bit led to one of the longer threads on LinkedIn that has ever been discussed about one of my posts. Some of the comments are not fit for work.) Then to make this even more complex, we need to discuss the primitives in the Zachman Framework as well.

Simple Tools Don’t Work Well For Complex Data Model Questions

This is why using native database tools aren’t good enough to solve all those needs.  This is why a simple drawing tool isn’t enough.  What an enterprise needs are tools that can author, design, and present all those types of data models without creating duplicate copies of those data concepts. It’s also why a data modeler needs to ask the question: What do *you* mean by data model?  You need to ask your team members what they are expecting before you start working.  You may need to negotiate priorities or formats.  You may need to create separate views of your models. That’s wonderful, though, to deliver what they need from your data models. It’s all good.

It’s not that we modelers don’t know the 100+ possible answers to that question.  It’s that we know there are 100+ answers.

It’s not that we modelers don’t know the 100+ possible answers to that question.  It’s that we know there are 100+ answers. That’s what data modeling is after all: getting to the right answer for this requirement.

Note: This post is an updated version of one posted to community.embarcadero.com in 2015