The type of structure a developer uses for a database will depend on the platform they are working through. For instance, a RDMS (relational database management system) will require different logic than a cube structure.
RDMS is still a dominant resource for many systems, and I will answer from that perspective.
When building the tables, a developer must consider a few things, including: 1) the normal form they are working in, 2) primary keys of a table, 3) foreign keys of a table, 4) table attributes, and 5) the relationships between the tables (one to many, etc).
These tenants are important to bear in mind, is it will alter the quantity of tables needed, and consequently how the tables operate. For instance, a table containing customer orders will likely pull in the primary key of another table that contains inventory. In doing so, someone looking up an order would retrieve order date and quantity information from the orders table, and would join in the inventory cost, description, etc from the inventory table. Using this method maintains standardization of inventory data. If instead, the database is built in a way that has the orders table populating inventory information, this standardization is lost, as manual entries for each record may vary from one to another.
The concept you ask about goes far deeper than my example here, and I would be happy to chat further, but hopefully this helps jog the idea of the concept.