Imprints Database Design
version 0.1 - Mark Pruett

The Imprints Database

Client programs query the Imprints Retrieval Server for information about the location of a Windows Driver Package for a specific model printer. This document describes the database tables used by the Imprints Retrieval Server.

This document does not intend to imply the use of any specific database package. Any relational database package with rudimentary relational features will be sufficient to implement this design.

The aliases Table

The aliases table serves as a cross-reference between any of the variety of names by which a printer might be identified. Different printer detection methods may yield different text string identifiers, and this table is an attempt to turn one of many names into a single unique identifier. We refer to this unique identifier as the printer's canonical name.

Field Name Field Type Field Description
alias char One of many possible identifiers for a specific printer model.
canonical_name char The unique identifier for this specific printer model.

Table 1. The aliases Table

The locations Table

The locations table is the primary table in the Imprints database. It contains the Windows Printer Driver Package locations. This is the information passed back to the client program when a query is made. The location_url contains a full URL of the package file. With this URL, a client should be able to obtain the package with no further interaction (such as passwords) required.

For example, if the database contains a location_url of, then using the text-based web browser lynx like this:

lynx -source > /tmp/myprinter.package

should download the package and place it into the /tmp directory.

Field Name Field Type Field Description
printer_id char The unique identifier for a printer model.
package_name char The file name of the Windows Printer Driver package for this printer.
location_url char A URL from which this package can be obtained (downloaded). The URL contains the full download path and file name.

Table 2. The locations Table

The geography and geo_preferences Tables

While the Imprints database server is assumed to be at one location, the actual driver packages may be distributed across multiple servers across the globe. It's also possible for the same package to be mirrored at several locations.

The geography and geo_preferences tables are intended to allow the client application to request a URL from a specific geographic location. (The tables may also be used in the future to let the server automatically pick a site close to the client.) A server implementation may choose not to use these tables.

Field Name Field Type Field Description
geo_preference integer A number (related to the geography table), indicating the preferred location of the download site.
table_name char A locations table containing URLs that best match the geographic preference.

Table 3. The geo_preferences Table

Field Name Field Type Field Description
geo_code integer A number (related to the geography table), indicating the preferred location of the download site.
geo_description char A name describing a geographical location (usually a country or other region, but within an intranet this could simply be another server location.

Table 4. The geography Table

How the Database is Used

A client makes a request to the retrieval server by sending it a printer identifier and (optionally) a geography code.

The server first attempts to match the printer identifier against the alias field in the aliases table. If an exact alias match is found, then the record's corresponding canonical_name is retrieved.

If the geography code was specified in the query, then the server may search the geo_preferences table for a matching geo_code. If one is found, then the server may choose to use the corresponding table_name as the target for the next query.

Once the server has decided upon the proper locations table, that table is searched for an exact match between the printer_id field and the previously retrieved canonical_name. If a match is found, then the retrieval server returns this information to the client. For more information on the server, consult the Retrieval Server Design document.

Figure 1. Imprints Database Entity-Relationship Diagram

Table 1 shows the Imprints database tables and their relationship to each other. Relationally, the two geography-related tables could be combined into a single table. We are keeping them separate because there is a possibility there may be a need to have a one-to-many relationship between the geography table and the geo_preferences table. (It's possible that, in practice, the database administrators may want to have several locations tables for a single geographic region. For example, there may be 6 servers across the U.S. "geo_code".)

An Example

Consider these trivial Imprints tables:

aliases Table:
alias          canonical_name
HP4050TN       HP Laserjet 4050TN
HP 4050TN      HP Laserjet 4050TN
HPLJ4          HP Laserjet 4

locations_1 Table:
printer_id           package_name           location_url
HP Laserjet 4050TN   hp4050tn-v1.0.package
HP Laserjet 4        hp4-v1.0.package

geography Table:

geo_code  geo_description
1         United States
2         Canada

geo_preferences Table:
geo_code   table_name
1          locations_1.rdb
2          locations_2.rdb

A client application makes a request for printer "HP 4050TN", and prefers to download it from a site in the United States (geo_code "1" in our example).

The server would first access the aliases table and find a match in the second record. Note that the first record also points to the same canonical name.

Next, the server may choose to look up a table name in the geo_preferences table. (The server may also choose to ignore geographical information entirely, in which case it will default to a generic locations table.) In our example, it looks up geo_code "1" in the table and finds a match to table_name locations_1.rdb.

Finally, the server searches the locations_1 table, looking for a match to the canonical_name "HP Laserjet 4050TN" in the printer_id field. It finds a match on the first record, and sends that information back to the client program.