This section
discusses how attribute data are stored in a GIS and issues of representing
characteristics of features in vector and raster data structures. Databases
are used to link spatial data to attribute data in a GIS.

DBMS -
Database Management System

Database system
employed by most GIS software applications used to store, organize and manipulate
data attributes

Entity/object
- in GIS terminology this is a specific feature (usually in vector data
structures) such as a single point representing a tree/well/city. In DBMS
terminology this is a type of feature - e.g. roads, rivers,
parcels. Each individual occurence of an object (again following Database
terminology) is an instance. Make sure you understand the difference
between how the GIS community uses the term object vs. how the Database
community uses the term. I'll primarily use the GIS usage, the Bolstad book
mostly uses the Database usage.

Record -
Data are stored in relational tables that organize attribute data for objects.
A record stores the attribute data for one feature object in a vector
dataset. Records are also sometimes called tuples

key - used to
relate tables together. In a GIS keys are used to link spatial and attribute
data together, and to link attribute tables to other attribute tables.

primary key
- for most GIS usages, a field/attribute used to uniquely identify an
object (note slight deviation from defintion used on Bolstad). In a vector
dataset a primary key must have one and only one instance of each value (e.g.
parcel id's, county FIPS codes). An example of these are the two digit county
codes used on Indiana license plates.

Example - database
of landowners and databse of land parcels

Attributes in
vector data structures vs. raster data structures

Look-up tables,
one-to-one vs. one-to-many links

Joining attributes
tables

Permanent
joins

Temporary
joins

Why are DBMS
used?

"Desktop"
GIS vs. server GIS

Personal
Geodatabase vs. ArcSDE database

shared access
and versioning

Some GIS
datasets require acess by multiple users

Access
can be concurrent. Alternatively data can be "checked out"
by one user and then can't be accessed by another user until the data
has been "checked in"