Ask two engineers on the same team what an order total means and you can get two answers: one counts shipping, the other doesn't. That disagreement isn't a bug in anyone's code, it's a gap in the data model. Data modeling is the work of deciding what a system stores, how those things are identified and related, and what shape they take inside a chosen storage engine. It stops short of physical tuning and query execution. Which access patterns an index has to serve is a modeling question, and how a B-tree is built is not.

In a system design interview this arrives right after requirements gathering, usually as a flat "okay, let's talk about the data model." It gets five to ten minutes of explicit attention and then keeps coming back, because the model constrains every API, cache, and scaling decision you discuss afterwards.

At mid-level, the floor is a correct relational schema with the right keys and relationship shapes, plus a real reason each field lives where it does. A senior answer also owns the normalization decision with its cost on the write path, and describes a schema change that ships while the system is serving traffic.

Write the queries down before drawing anything, then use them to choose keys and cardinalities. For each tradeoff, state which side of the read-write split the workload favors and what that choice costs. Schema evolution comes after those foundations because it depends on the keys and data shapes already chosen.