Your model represents whatever data your application works with. TurboGears models are typically represented using SQLObject objects. SQLObject provides a bridge between Python objects and a relational database. It's not designed to hide away the database 100%, but it does go a long way toward letting you write Python and not worry about SQL.
Before TurboGears can access your database, you need to tell it where to find the database. You do this in the dev.cfg file (for development) or the prod.cfg file (for production use). The config parameter "sqlobject.dburi" controls where the database is stored, and uses a typical URI scheme.
You can also provide options via "query parameters" on the connection URI. A couple of useful options are debug and debugOutput. If you add ?debug=1 to your URI, each query will be output as it is run. If you add &debugOutput=1, you'll also see the result of the query displayed.
You define your data model in the model.py module in your project's package. If you have more model code than will comfortably fit in one module, you can always break it up into multiple modules and import into the model module. SQLObject provides two different ways to define your database: you can define it in SQL directly in your database, or you can define it in Python. For clarity in your code, it is often easier to define your model in Python terms. If you do want your Python classes to be based on your database, you just do this:
Note that this only works with some databases. Check the SQLObject documentation to be certain this style of working.
Defining your model in Python requires more typing of Python code, but saves you from having to write SQL to create your database. Here's an extended book example written in Python code:
To create this database, you just need to run:
tg-admin sql create
This will create three tables in your database: one for books, one for authors, and a join table for the many-to-many relationship between them.
Though SQLObject cannot model every database, it does well against a wide variety of databases. Many aspects of how the database is used, such as column names, table names and join table names can be customized as needed to fit existing databases.
Your model objects need not (and should not!) be dumb data containers. They are full Python objects and can have methods of their own to perform more complex calculations and operations.
There is quite a bit more information about defining your data model with SQLObject in the SQLObject documentation.