From the point of view of readability and maintainability, your plan of putting everything into its own class and having the class query the database sounds great. A couple suggestions/comments however:
Consider some sort of abstraction for getting a database handle and connecting, something like $dbh = get_db_handle(). This way you can build some sort of system where the first call creates and opens the handle and caches it and then it just gets returned each additional time the function is called.
The other thing to thing about is whether it will really work well to have everything enapsulated in its own class. For some applications this works well, but for others you may find that you will be needing to build complex queries that might involve data not in that particular class or some sort of complex join or something. (Well, it is almost always possible to do everything you need without doing anything complex and outside the class, but you will sacrafice a great deal of speed, and make the Perl code a lot more complex).
To figure out how best to model the data with your classes think about this simple example:
A patients table and a visit table.
If you want information about a particular visit of a particular patient, you create a single patient object and a single visit object. Simple enough.
What do you do if you want all of the visits on a particular day?
What do you do if you want all of visits belonging to a single patient?
What do you do if you want to join the two tables and see all patients visits?