For instance, you might create a class that manages student enrolments. This class would have a method for inserting a new enrolment, accepting the student ID and subject ID as parameters. If the application was using MySQL 4 or PostgreSQL, for instance, it might default to using a SQL INSERT statement, which is then passed to the PEAR DB abstraction class. If, however, the application is configured to use stored procedures in MS SQL or MySQL 5, it would instead pass an EXEC or CALL command to invoke the relevant procedure, still using the PEAR DB class.

With this extra level of abstraction, you can build SQL interfaces for the PEAR classes that use vendor-specific syntaxes or features. If the physical database shares an identical structure with the logical data model, you may want to investigate the PEAR DB_DATAOBJECT library. This library automatically creates classes from a database with a 1:1 relationship between tables, classes, columns and properties. Although this library will create a complete SQL abstraction layer, it won't cater to class structures that differ from the way they are represented in the database.

Step 4 - Object-Oriented Application Libraries
In situations where your physical database model coincides with your logical data model, you can build class libraries that reflect the database tables perfectly or use the DB_DATAOBJECT library to automate this process. This makes for easy interfacing between the database and application layers. For instance, the example subjects table may have a corresponding application class written in PHP as follows:

class trainingsubject
{
   var $id;
   var $name;
   var $teacherId;                           

   function select($theid){
     //...
   }
   function insert($newname, $newteacherid){
     //...
   }
   function delete($newname, $newteacherid){
     //...
   }
   function update($newname, $newteacherid){
     //...
   }

}