# Data Modelling: The Thin Model

About a third of the way through Mastering Data Modeling the authors describe common data modelling mistakes and one in particular resonated with me - '**Thin LDS, Lost Users**'.

LDS stands for 'Logical Data Structure' which is a diagram depicting what kinds of data some person or group wants to remember. In other words, a tool to help derive the conceptual model for our domain.

They describe the problem that a thin model can cause as follows:

[...] within 30 minutes [of the modelling session] the users were lost...we determined that the model was too thin. That is, many entities had just identifying descriptors. While this is syntactically okay, when we revisited those entities asking,What else is memorable here?the users had lots to say. When there was flesh on the bones, the uncertainty abated and the session took a positive course.

I found myself making the same mistake a couple of weeks ago during a graph modelling session. I tend to spend the majority of the time focused on the relationships between the bits of data and treat the meta data or attributes almost as an after thought.

The nice thing about the graph model is that it encourages an iterative approach so I was quickly able to bring the model to life and the domain experts back onside.

We can see a simple example of adding flesh to a model with a subset of the movies graph.

We might start out with the model on the right hand side which just describes the structure of the graph but doesn't give us very much information about the entities.

I tend to sketch out the structure of all the data before adding any attributes but I think some people find it easier to follow if you add at least some flesh before moving on to the next part of the model.

In our next iteration of the movie graph we can add attributes to the actor and movie:

We can then go on to evolve the model further but the lesson for me is **value the attributes more**, it's not all about the structure.

##### About the author

Mark Needham is a Developer Relations Engineer for Neo4j, the world's leading graph database.