đ Hey there
đ€ If youâre new: Thank you for subscribing to the databeats newsletter where I publish guides for growth practitioners to use data to drive growth (data-powered growth).
đ If youâre not new, well, thank you for sticking around!
This is the most ambitious series Iâve worked on in my 4-year career as a data content creator. Itâs been in works for a long time and is part of my upcoming book as well.
The goal is simple: To simplify the heck out of the term âdata modelâ. If you work in data or intend to do so, you cannot ignore this term. If you try to understand what it really means by looking it up (or asking an AI bot), youâre sure to feel confused and overwhelmed. However, I can assure you that you will unlock data superpowers once you understand the two types of data models.
Ready, are we?
Permanent link to this post to bookmark and read later â
You donât need to know how to build a car to drive one. Similarly, you need not know how to build a data model to understand its purpose and use it in your data workflows.
Letâs start this chapter with a thought experiment:
What comes to mind when you hear the term customer? Surely, a customer is an individual who buys what youâre selling. However, in the B2B context, a customer is always an organization and not a person.Â
Now, what comes to mind when you hear the term user? An individual who uses your product or service, right? But once again, that person can be part of a free account, a paid account, or even multiple free and paid accounts.Â
Hereâs a typical conversation between a busy executive and a growth lead:Â
Busy Exec: How many users do we have as of today?
Growth Lead: We just crossed 10,000 users and weâre growing fast!Â
Busy Exec: Okay awesome! And how many of them are customers?
Growth Lead: Well, we have exactly 200 customers andâŠ
Busy Exec: Wait what?!?! Our free-to-paid conversion is what⊠2%? ThatâsâŠthatâsâŠ
Growth Lead: Oh no, thatâs not right, our free-to-paid conversion is 20% which is actually pretty good. We serve 10,000 users across 1000 workspaces out of which 200 are paid â the rest of the workspaces are either on the free plan or are trialing one of the paid plans. Â
Busy Exec: Umm, alright, yeah okay, thatâs good! 20% is good. Great! By the way, whatâs the difference between users and workspaces? Can you refresh my memory?
As a growth lead, you need to have concrete answers to these questions. You cannot blame busy execs for being confused between user, workspace, and customer, each of which can be defined differently by two similar-looking businesses. In fact, these terms are confusing for anyone who hasnât spent their days in the trenches of B2B SaaS, trying to define core metrics like active_users and activated_workspaces (which are different from active_workspaces and activated_users).Â
So, what is a customer and how is it different from a paid workspace? Â
Customer is an entity that needs to be defined and modeled. The definition helps inform a set of rules, which once applied to one or more tables in a database, results in a distinct table representing the Customer model â an analytical data model. Â
From there, it becomes easy to answer questions like how many customers did we acquire this quarter? Depending on the business, customer can be the equivalent of paid workspace, or customer can be a separate entity that, for instance, uses two workspaces, one of which is paid. Â
Previously, Iâve described application data modeling as the process of designing the foundation of a software application and analytical data modeling as the process of defining what data needs to be made available in what shape for analysis or activation purposes. By definition, application data modeling precedes analytical data modeling â the former is performed by software engineers before developing an app or a new feature whereas the latter is performed by data engineers and analysts much later â once the app or a feature has launched and has acquired real users. Â
But what exactly is an application data model? Whatâs an analytical data model? And how does the former impact the latter? The goal of this chapter is to simplify the concepts that arenât explained in simple terms on the open web (just look up âdata modelingâ and youâll know what I mean). And Iâll be doing that via definitions, diagrams, and examples â both B2B and B2C.Â
Itâs worth stating that I have intentionally chosen to skip some of the technicalities and have also taken the liberty to not adhere to the traditional definitions. Wish me luck!
The Fundamentals of Application Data Models
Schema
To understand what an application data model is, itâs important to first understand what a schema is.Â
A schema defines the relationship between all the entities in a database.Â
Each entity gets its own table in the database and a row is created in the table every time one more of that entity or thing is created.Â
User, Product, and Order are the basic entities in an ecommerce app. Similarly, entities like Workspace and Role are common to B2B SaaS apps.Â
The schema specifies, for example, how User is related to Product and Order or how User is related to Role and Workspace.Â
The first step when designing an app is to map out all the entities along with the relationships between those entities. The outcome is a conceptual schema of the app, enabling teams to visualize the structure of the app database.
The figure above represents part of the conceptual schema of an ecommerce app (leaving out other entities such as Brand, Category, Payment, Cart, etc).Â
As you can see, the figure depicts the following relationships between the entities â depicted by the symbols at the head and tail of the connecting lines:
One-to-Many between Customer and Order
Many-to-Many between Order and Product
Hereâs what it means:
A customer can place many orders,Â
An order can contain many products
A product can be ordered many times
Itâs worth noting that the what Iâm referring to as a conceptual schema is normally referred to as a conceptual data model but I think the distinction between a schema and a model is useful from a simplicity standpoint.Â
As mentioned earlier, a schema defines the relationship between all the entities in a database. In some ways, a schema is like a Google Sheet template with multiple sheets, each with column names and functions that reference each other, but without any data.
Application data model
An application data model defines the structure of a particular database entity.Â