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.
Table 1. The aliases 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 http://somedomain.org/packages/myprinter.package, then using the text-based web browser lynx like this:
should download the package and place it into the /tmp directory.
Table 2. The locations Table
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.
Table 3. The geo_preferences Table
Table 4. The geography Table
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.
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:
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.
|