The database layer of the data model consists of the classes and routines needed by a particular Access Module to transport data using a native database API. The details, which vary widely from one Access Module to another, are completely invisible to applications, but there are common themes.

One common theme is the use of early binding of data in each of the Access Modules. In designing the database layer of the data model, we examined two strategies: late binding and early binding. With late binding, data is retained in its database-dependent form until it is requested by a higher layer. With early binding, data is converted to a normalized form at the earliest possible moment.

Late binding offers potential efficiency advantages. In some scenarios it might be possible to avoid some type conversions; in a few cases, we might not need to touch the data at all. On the other hand, early binding allows us to localize all decisions about type conversion to a narrow layer, and to provide a simpler, more reusable interface to the rest of the library. By normalizing immediately, we are able to guarantee that data, once retrieved, is always available wherever it is required. In particular, no additional logic is required to allow data from one database to be combined with data from another. This was the deciding factor in our decision to use early binding in the database layer.