How to Read a Schema Diagram
Each box on the diagram represents an entity, and the arrows drawn
between the boxes represent relations. For example, from a Vendor
(a chip foundry) we might commission several Runs, so Vendors have
a one-many relationship with Runs, and the Runs table contains
the unique Vendor ID as a foreign key. The arrowhead always points
to the "many" side of a one-many relation.
Slitmask Production Schema Diagram (Figure 9.2.7)
If we start with a Field (the unit of sky that the observer wishes to observe), the field consists of a list of objects with canonical (catalog) coordinates. There is a one-many relationship between the Field and the objects in the Catalog. Many instantiations of this Field are possible, distinguished by the geographical location of the observer and the date and time of the observation, so there is a one-many relationship between Fields and their Instantiations.
If we apply a suitable refraction methodology to the Field which we believe will yield corrected sky coordinates for the Catalog, we produce a Refracted Catalog. You might think there is a one-one relationship between the refracted catalog and the field instantiation, but one could always try several different refraction methodologies and generate slightly different refracted catalogs for the same location/date/time of the same field.
Now, starting with the inventory of metal blanks used to make slit masks, each has a barcode which is its uniqe ID. If we apply a distortion correction methodology to the refracted catalog, we get a set of positions for slits to be cut in the slit mask. Since it makes no real-world sense to cut more than one field's worth of slits in one mask, we can safely assume that only one distortion methodology can apply to any finished slitmask -- therefore we associate the methodology with the piece of metal.
The Mask plus MaskSlit tables give us the physical description of a finished slitmask; the SlitID links the list of slits to the refracted catalog, which in turn refers back to the original field and catalog objects which the observer wanted to observe. All relevant attributes of a slit mask should be representable within this schema.
CCD Production Schema Diagram (Figure 9.2.10)
Most of the left-hand side of the drawing is fairly obvious: Runs consist of many Wafers, and each Wafer can contain many CCD devices. A CCD on a Wafer is also an exemplar of a Design.
As we move rightwards, we begin to encounter less comprehensible entities; these are processing and testing events or chip properties rather than physical objects. For example, each CCD has potentially many "experiences" or "events" as it passes through the fabrication facility; it might be thinned, flattened, coated, flooded, mounted, bonded, or even dropped on the floor. The list of all these events constitutes a History of that CCD. The list of possible events that happen to CCDs is finite, hence it is easier to maintain that list (Events) and to reference it from the History table, rather than having to type in very similar descriptions over and over.
Defect documentation is fairly obvious; each CCD may have many defects, but defects can be only one of a finite list of defect types (dead pixel, bright pixel, poor response, etc).
There is a finite list of standard functions in CCD chip design (clocks, control lines, etc). If we define these in the FunctionType table, then for any given chip design we have only to specify which pin each function occupies in that design. Thus, the PinFunction table.
CCD chips have onboard amplifiers; these amplifiers are of a finite list of possible amplifier types, and on each chip some number of these amplifier types are instantiated at certain X/Y locations. The AmpType and Amplifier tables describe this attribute of CCDs.
The setup for testing a CCD can be described as "this CCD, using this controller (and this dewar, etc) at this ambient temperature, and applying the following control voltages or clocks to the following pin/function inputs of the chip". This is what the Setup and Setting tables describe.
A Test, however, is the application of one or more setups to the measurement of one or more attributes of a chip. "We set the chip up like this and measured X, then like this and measured Y. This test was intended to reveal Z." The list of attributes that can be measured is finite for all chips, and can be kept independent of chip ID in the TestAttrib table; then the Measurement table brings everything together: "this chip, set up like so, was tested for A, B, C, D, and E attributes, and their values were..."
This schema diagram is incomplete; it does not include all of the tables originally developed for the UCO/Lick CCD Lab schema. Additional tables describe Dewars, Controllers, Waveforms, CCD design attributes, etc. However, several attributes of interest to DEIMOS users are shown here. (When the schema design is complete, all relevant attributes of CCDs should be representable within the schema.)
The most obvious application of this information is the defect list for each chip. The defect map can be overlaid on the image in a graphical layer of the image display tool; or it could be printed out as a reference for the observer; or it could be automatically used in the data reduction pipeline, suppressing information from the defective pixels which might otherwise warp the reduction results.
Other information may also be of use, however. This schema permits us to ask questions about the provenance and history of CCD detectors, should one detector perform differently from an apparently similar detector. We can find out everything from where the silicon was masked and fabricated, to the detailed results of its qualification testing in the lab. The defect list, of course, would be updateable so that new defects would be added as they appeared.