Personally, I would write a simple generic ORM layer and create aliases to the ORM layer.

The originial ORM layer would be a hook to the table columns and rows. However, a badly designed and implemented database can make deciphering those Table and column names a headache. So you write aliases that make more sense, from a programming stand-point, instead of hoping people will know the database schema.

Example, you have a table that looks like this,

Table: Agent

Columns
name_part_1 - a person's first name
name_part_2 - a person's last name
name_part_3 - a person's middle name

# Standard ORB

print "First Name: " . $agent->name_part_1 . "\n";
print "Last Name: " . $agent->name_part_2 . "\n";
print "Middle Name: " . $agent->name_part_3 . "\n";

sub get_first_name { my $self = shift; return $self->name_part_1;}
sub get_last_name { my $self = shift; return $self->name_part_2;}
sub get_middle_name { my $self = shift; return $self->name_part_3;}


# Using the Alias Layer

print "First Name: " . $agent->get_first_name . "\n";
print "Last Name: " . $agent->get_last_name . "\n";
print "Middle Name: " . $agent->get_middle_name . "\n";
[download]

While an alias layer is not as good a refactoring, it could make your database appear to be refactored.