How to separate database from model and extending model over multiple tables

I currently use a home-spun ORM approach to models, ie, an object's methods map to the fields of a table. This seems to be a very workable and intuitive way to work with simple websites.

However...

As the complexity increases, this approach becomes cumbersome when I want to get data from joined tables. My database abstractions are aimed at single tables only, and to do queries with joins just doesn't fall into place naturally.

I've been investigating DMM, specifically at http://ift.tt/2uuQZ9J, but I'm getting lost somewhere in the details. I need some bigger-picture questions answered, if I can just figure out what my questions are :/

So to start, MVC has a nice delineated structure: Model, View, and Controller. You can separate out the directory structure to separate the concerns. But, as I'm learning, the model is not one monolithic class. You want to separate the storage from the business logic.

Question 1: Are there naming conventions and a directory hierarchy for these different model types?

The second question is related to the actual database access. According to the DMM pattern, you have an in-memory object that you would save by calling a ->save() method. This in-memory object does not necessarily map 1:1 with any database table. And this is where I get lost... The save method would probably inject the in-memory object into the data access object which would in turn persist the object in the database.

With a database abstraction, I can make a class with my own find, findall, insert, update, delete, etc. methods that can be extended for each database table. But DMM seems to be a completely different paradigm.

Question 2: How do you map an in-memory object to a data access object that spans multiple tables?

Question 3: How does that DAO deal with multiple tables?