Alastair JW Mayer, November 2000
Introduction
This is a brief guide to the base or core Cavor database schema. See the file "cv-schema.sql" in the sql subdirectory of the Cavor CVS repository for the actual SQL code.
The Cavor "document" is a single database or database user (different RDBMS packages use the terms somewhat interchangeably). A single system may of course hold multiple different such Cavor databases or documents. The user interface should make these implementation details invisible to the average user, who should just see a list of available "Cavor documents" in e.g. the "open" menu.
Standard ("Base") Tables
These are the tables present in every Cavor database. Other tables are application-dependent.
Drawing Table
For many Cavor databases, this will contain a single entry, e.g. "the map" for a simple GIS application, or "default drawing" for some non-geographic application. (The names are arbitrary.) However, some applications may require multiple drawings: a floorplan app might use different drawings for each floor in a house; an electronic CAD program might use different drawings, one for the circuit schematic and one for a PCB (printed circuit board) layout; a telephone utility app might have a main geographic map plus individual schematics of the cable layout within various manholes, etc.
An entry in the drawing table gives global data applicable to all entities in that drawing: the internal measurement units (e.g. feet or meters for a rectangular system, degrees for a latitude longitude system, etc.) which determines how coordinates are interpreted; the total extents of the drawing (the minimum and maximum possible coordinates of any entity), as well as a unique numeric ID and a name string.
Entity-code Table
An entity-code (or in GIS terms, a feature-code) is a name for a class of entities, for example "street" or "state-line" or (getting away from GIS codes) "task" (in a PERT chart) or "capacitor" (circuit diagram). Entries in this table give the "class properties" for entities, while the entity table gives the "instance properties" for each individual entity. These class properties include a textual description of the class or entity-code, the name of the attribute table (a user table implementing the specific properties of a given entity class), the entity type (a point feature,
a linear feature, a polygon, etc.) and (if applicable) the maximum number of points. It also includes references to the symbology entries describing how the entity is to be drawn, and the default layer and network for new entities of this class.
Entity Table
This contains the graphical information specific to each individual entity or feature in the database. A feature is specifically identified by its entity-id number, but since the same physical entity may be represented on different drawings (and may be drawn differently on each), there may be multiple rows in this table for a single entity. The tuple (entity-id, dwng-id) must be unique, however. This table contains the specific layer and network of the entity, the graphic extent (bounding box) of the entity, and also the first and last points. The latter are included for efficiency -- many entities may only have one or two points, and many operations may only concern themselves with these points. Keeping them in the entity record saves an additional access to the coordinate table to get them.
Entity-coords Table
This table contains the point data for the entities (except for first and last points, see above). Again to reduce database access overhead, these are stored as multiple points per row. (Currently the design is a row of 12 arbitrary coordinates which may be grouped (depending on the entity type) as either 6 sets of (x,y) coordinates or 4 sets of (x,y,z) coordinates. However, this may change to separate tables for 2d and 3d point sets.
Layer Table
This basically is just the numeric identifier, name, and description of the layer. In the application itself (specifically the Display List), layers have more attributes -- whether or not it is visible, displayed in full or fast symbology, whether items can be picked on it, etc. It may make sense to make these attributes persistent by adding them to this table.
Network Table
Similar to the Layer Table above, although adds attributes for the type of network and optional connectivity table. (A connectivity table lists the entities that are connected to each other. There may be different sorts of connectivity models, e.g. node-arc-node, arc-node-arc, node-node, etc.)
Label Point
This table is supplemental to the Entity Table. An entity may have optional "label points" which can be referenced by the symbology language when drawing the feature, e.g. to assist in placement of textual labels denoting certain entity attributes. This can help un-clutter the drawing when entities are close together and purely automatic symbology isn't good enough.
Attribute Tables
This is a generic term referring to the "other" tables that contain attribute or property data for the various entities. Entities of different classes (different entity-codes) will have different sorts of attributes and hence different attribute tables. (Note though that different entity codes may refer to the same table if they are of substantially the same class).
For example, in a GIS app the attribute table for "street" (name, number of lanes, road surface, etc.) would be different than that for, say, "river" (name, navigability, flow rate, whatever). In a circuit-design app you'd have different tables for "capacitor" (type (electrolytic, ceramic, etc), capacitance, tolerance, voltage, etc.) vs "resistor" (type (composite, thin-film, etc), resistance, wattage, etc.).
Other tables
TODO: Need further discussion here about connectivity tables and how they work, whether coordinate system definitions (particulary for GIS apps) should be stored in a table (and/or in a separate centrally-referenced database of their own). Also whether fast-symbology should be table-driven (probably) and if so, whether as a separate table or an extension to the entity-code table. (Note: "fast" symbology refers to the option of quickly drawing features from the database without going through the full symbology language processing exercise. This basically means picking default color and line thickness for line features, a default symbol for point entities, etc.)
Last updated 1 November 2000.