PHP – What is Zend’s Relationship with PHP?

It looks like you are having a design issue here: Tables should not extend the Database Abstraction Layer. Instead the DAL should be injected into the table as a dependency.

abstract class Table {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    // whatever else all tables have in common
}

class Table_User extends Table {
    public function someMethod() {
        $this->dal->someOtherMethod();
    }
}

$table = new MyTable($dal);
$table->someMethod();

That way you will create a DAL at some upper scope and pass it down. This will also allow you to use multiple different database engines at the same time.

Additionally you obviously should not create your tables directly in your controller but let a specialized class do that. For example you could use a factory:

class TableFactory {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    public function createTable($name) {
        $className = 'Table_' . $name;
        return new $className($this->dal);
    }
}

That way you can create a table factory at some point with an injected DAL and pass that table factory around.

$table = $factory->createTable('User');

OOP isnt meant to just plain "seperate things". It's more about organization and intent and reusability (when appropriate). Take a look at Domain Driven Design (DDD). Specifically, identifying where your "Value Objects" are, your "Entities" are and which "Services / Factories / Repositories" are needed to support them to get you where you need to be.

In answer to your qeustion:

Would I create a class for building, level, room and item with the following structure

-Yes, it seems those would be your Models

building can have 1 or many level objects held in an array level can have 1 or many room objects held in an array room can have 1 or many item objects held in an array

-That sounds right, the Building then would be your Entity, because each building is unique and has a distinct existance, as opposed to an "item" or "room" which have a clearly defined value, but no distict existance other than it's uniqueness to who owns it.

and mappers for each class with higher level mappers using the child mappers to populate the arrays (either on request of the top level object or lazy load on request)

-This is where you're going to want expand a bit. Basically, you're going to want to create repositories / factories which will be able to fetch and load your "entities" with data. This might be what you are referring to as "Mappers", but when I hear mappers I think of "Active Record's". which are objects which save and load themselves and pretty much are 1-1 with the database. With that concept, breaking out the core "properties" per intent can become messy (it probably works for some).

Here are some good resources which should aid in your development.

Check out Domain Driven Design Concepts, there are a few Moguls out there which you'll come across very quickly which will offer you detailed insight into the theories at hand. Here are some links to get you started:

this is a pretty brief explanation: http://mattpeters.net/2009/03/24/domain-driven-design-part-1-introduction-and-entities/

this one has the cool domain name and turns out to be a great resource: http://domaindrivendesign.org/