If you work in digital, you have met them. The data people. You know, the ones who can see level upon level of digital data unfolding in their mind’s eye? The Beautiful Mind types who have the ability to create an almost three-dimensional Excel spreadsheet? Perhaps you are one of these people, and this stuff comes naturally to you. For the rest of us non-data thinkers, creating a digital map on paper is a skill. It’s known as data modeling.
The idea of a data model is to create an overview of a digital project that all invested parties can access, understand, and use to do their jobs. Whether you are a data specialist, an agile whiz, or just a content strategist who studied James Joyce in college and doesn’t inherently think in data bytes, if you work in digital, you will probably have to create a model.
What is a data model?
Think of data modeling is a visual blueprint for a digital design. As the blueprint expands and becomes more of a reality, it goes from being a conceptual model, like a sketch on a napkin, to a logical model, which includes all potential details, to a physical model, or guideline for implementation.
Data flow diagrams
Most models are data flow diagrams (DFD), pictures of how data moves through the system. Where does the information originate? What happens to it? Where does it come out? It may be very simple or quite complex, but you should be able to answer these questions looking at a DFD.
A data model helps coordinate the team, encourage everyone to speak a common language and have a shared view of the project. Your model will include information that is unique to your product (character limits, numeric, naming conventions, errors). Early on, modelers developed some commonly accepted guidelines for creating a data model. For example, an external entity that can’t be analyzed is usually represented by a square, a process was a rounded rectangle, lines and arrows represent the relationships and information flows between entities and processes. These lines should always be named.
Models seem to have evolved somewhat, to include ovals as attributes, clouds to represent aggregation, diamonds for relationships, and all manner of other shapes to add to the complexity of data models. Whatever standards your model adopts must be consistent or logical within the given model.
Data modeling from the beginning: the napkin model
The simplest model to understand is the conceptual model. It could also be called the high-level plan, the kind you might write on a napkin at a bar or coffeehouse. I call it the napkin model. It’s as simple as A + B will lead to C, which one hopes will lead to profits.
Logical model: thinking through the kinks
In a logical model, the visuals help you try to think through the experience. You start with certain entities. These are the A, B and C in your napkin model: customers, users, players, products. Then come attributes, the things that define the entities, such as name, address, order, code, date, item.
There are the processes. Where do the entities go? What are you bringing to them? Then you create relationships. Show how data moves through the system, as well as the checks in the process, the exceptions, the constants? These are the arrows that flow from data field to data field, demonstrating the movement of the data.
Physical model: getting real
Then it gets written in tech speak. With data types and IDs named in a systematic way. This is the physical model. Sometimes called an object-oriented model when all of the code is in place.
At every stage, the model becomes more developed, layered, and complete. It helps staff consider next steps and anticipate road blocks. If you don’t have one of those beautiful minds for data, visuals can work wonders.
Take your model to the next level. Become an expert in Data Science with an 11-week course from General Assembly.