The timer job is an object in the SPJobDefinition class. Timer jobs can be run on site collections, servers, content databases and services. Timer jobs can also be backed up, using methods from the IBackupRestore class. When you establish the target for a group of actions to perform as a timer job you will use the timer job that points to that target, for example 'SPContentDatabaseJobDefinition' to run the job on all selected content databases. Think of timer job as a service agent, or rather a whole staff of service agents with slightly different skills and assigned territories in which to work.
Additionally many SAs have associated databases in order to do their work more effectively, as in the case of a profile application that catalogues data from Active Directory. IT departments can even dedicate a farm to some of the services provided by the SAs and their respective databases.
A few SAs can be shared by not just more than one site or collection but more than one farm (cross-farm services). To accomplish this though, requires that you create a trust relationship via certificate exchange between the farms, the services and if the farms are in different domains, even the domains themselves. The consuming farm must create a connection to the service on the remote farm. Cross-farm services include User Profile, Managed Metadata, Secure Store Service, Web Analytics, Business Data Connectivity and Search.
Under SP Central Administration/Service Application Associations you can view the SAs that are in the application pool for your site. From within Web Application Management you can assign your SAs to the default or a custom group and assign the SAs to particular sites. The Central Administration ribbon (ala Office) provides quick access to tasks like setting properties (i.e. database name, group, proxy and so on) or publishing to other farms for the SA. Deploying SAs to a single default application pool enhances performance and is recommended but there may be factors, such as process isolation or allowing a team to manage its own service, that would require the creation of additional pools. Additionally specific business groups may require a custom set of SAs, the management of which would be simplified by adding a departmental application pool. Just as in database design, what you are really creating as you architect farms and assign SAs as well as other SP artifacts is a business process.