An object-relational mapper (ORM) lets application code work with database content as objects instead of directly manipulating database tables. In Django, a model class maps to a table, an object maps to a row, and object relationships represent links between stored data. The ORM is the bridge between a web application’s Python code and its relational database. section 1.1 section 1.1.2
Figure 1.7 ORM Models are data objects that map to underlying item and relationship tables
This comparison shows the central ORM mental model: model objects and their relationships correspond to item and relationship tables underneath. section 1.1.2
Relational databases store item data in tables and connect related items with keys. An ORM keeps those relationships available through objects: a Book can link to its Author and Publisher, while an Author can retrieve associated books through an automatically created reverse relationship. That replaces much table-focused thinking with class and object navigation. section 1.1.2
With Django’s ORM, a model defines how data is stored and supports the usual data operations:
- Create rows by creating objects and saving them. section 1.1.2
- Read stored content by querying for particular objects or related objects. section 1.1.2
- Update and delete stored data through the ORM rather than direct database commands. section 1.1.2
- Create, read, update, and delete both data and database tables as part of adding storage to a site. section 4.0
Books, authors, and publishers
Imagine a site storing books. Rather than treating Book, Author, and Publisher as disconnected tables, the ORM presents them as classes and their rows as objects. A specific Book object can expose its associated author and publisher; an Author object can be used to find that author’s books. The database still handles tables and keys, but application code works with the connected objects. section 1.1.2
In a Django request, a URL selects a view, and that view can use the ORM to load or change database content before forming a response. This makes the ORM especially useful for dynamic pages whose output depends on catalogs, articles, accounts, or other stored information. It belongs alongside routing, views, and template rendering rather than as an isolated database convenience. section 1.1 section 1.3
The ORM suits database-backed web projects such as blogs, commerce sites, content repositories, and document-management systems. It also works with Django Admin for inventory-style management. Django packages its ORM with routing, views, and templating, which avoids assembling those core pieces separately; using Django solely for its ORM is less suitable when no web application is being built. section 1.2.2 section 1.2.3
