A flowchart-like diagram used to illustrate a framework for data relationships between your most critical database entities, aka the top-level things you want the database to describe and compare.
For example, a data model illustrating a framework for a streaming video service may have a different entry for each subscribing customer, each movie/TV show title and each company who has ownership of the streamed titles. The data model may show how customers can connect to titles for the purposes of showing which people streamed each title as well as an overview of the percentage of subscribers who accessed a title altogether. The model may also show a connection between titles and rights owners for the purposes of keeping track of distribution rights as well as individual royalties paid per view.
An idealized, extremely simplified data model for such a system may look like this:
CUSTOMERS ⟷ TITLES ⟷ RIGHTS OWNERS
The purpose of data models is to identify the most common and useful database queries and analyses early on so that the platform can later be coded to be as efficient and functional as possible.
Without data modeling, inefficient decisions may be made that hurt the usability of an application or platform as a whole. Going back to the streaming platform example, it may not make sense to connect customers to rights owners since the two do not have a definite relationship.
On the other hand, it may make sense for all three categories to interact with a “Revenues Earned” category so that the number of subscribers and their subsequent subscription fees can be compared to the amount of times a title was accessed and the royalty cost overall for hosting the title on the platform. Through this model, a company can rapidly determine the cost of hosting a title compared to its popularity, helping the streaming service determine if a title is costing more than it is worth.
Data models also help platform engineers determine elegant, useful workflows for data to enter and flow through a system, especially when combining data from entity types to analyze their relationship together. If every entity ends up being duplicated and processed through a central database, then that central database can end up becoming slow, cumbersome and disorganized.
However, if each entity is only connected to the most important entities it actually relates to, then a platform can use less resources, decrease latency and often add to user friendliness.
Note that a data model is just a conceptual example. Software engineers will later use the model as a blueprint when coding a system. This blueprint ensures that processes are as efficient as possible and that all typical queries/tasks can be handled logically by the typical user.
Data models also prevent “one-size-fits-none” situations where a platform is designed generically and without the needs and uses of a specific use case in mind.
Overall, data modeling is a key step in the software planning process to ensure that an end product will be useful and will not frustrate users.