Document data models are "Hierarchical models on steroids"

Early database systems modeled data as a hierarchy of records. They could maintain one-to-many relationships well but had difficulties representing many-to-one and many-to-many relationships and did not support joins.

Subsequent data models like relational and network databases tried to overcome these deficiencies. Between the two, network data models went out of vogue after the initial hype, but relational data models remain popular to this day.

But relational databases need awkward translation between object data structures and flat relational models. The onus falls on applications to bridge the gap and connect the object world to the relational world while maintaining readable code.

Document databases, supported by the NoSQL movement, have become popular because they avoid this unnatural translation required between object data structures and SQL. They reverted to the hierarchical model to store nested records within the parent record rather than as a separate table.

Document data models are fundamentally different from hierarchical models, though, when it comes to representing many-to-one and many-to-many relationships. They are closer to relational databases in this aspect and refer to a related item by a unique identifier. Foreign keys in relational models become document references in the document model.

The identifier is resolved at reading time by using a join or follow-up queries, depending on the database's capabilities in use. Many NoSQL databases now support a query language based on JSON-like syntax, bringing support to traditionally relational aspects like joins, transactions, and query optimization.