Attribute Data in GIS Data in GIS are stored as features AND tabular info

1. Attribute Data in GIS • Data in GIS are stored as features AND tabular info • Tabular information can be associated with features OR • Tabular data may NOT be associated with any specific feature • “Tabular” means stored in a table with rows and columns • Rows are called “RECORDS” in GIS • Columns are called “ATTRIBUTE FIELDS” or “FIELDS”

2. Tables • Tables are classified as being “Attribute” or “Stand Alone” • Attribute table- a table that contains data about a specific features in a set of geographic data • ONLY 1 record for each feature; can and typically does have multiple fields for specific features • Depending on the type of model, the table contains different types of information • Georelational- each record relates to a feature in a separate file through an FID • Feature Identification • Object-oriented model - the feature’s attributes and geographical location (x,y coordinates) are stored in the same table and has OID (object Identification numbers

4. Tables • Tables are classified as being “Attribute” or “Stand Alone” • Stand alone table- a table that contains information about about an object or objects • They are independent of the geographical data in the map and has OID (Object Identification numbers) • The data may come from a text file, global positioning software (GPS), Excel spreadsheet, or database file building software. • Sometimes the relationship between a stand alone table and the geographic data is only incidental

5. Database Management • GIS uses a management system similar to those used by nearly all large institutions • e.g., the state and federal government, BMV, universities, hospitals, etc. • Three types of database management systems • flat file database- stores rows of information as text or binary coded data in text strings • Simple but not efficient • Hierarchical- multiple tables stored as separate files, each of which has multiple records and fields. Each table has a hard linked relationship to other tables • e.g., courses, with students, linked by course ID number • Relational- multiple tables stored as separate files but they are NOT hard-linked. • shared fields (columns) become the joining key

6. Queries on tabular data • Information may need to be subdivided into desired packages • e.g., parcels of land zoned commercial in a county • Queries use a language of logical expressions to delineate wanted data from larger data files into a “selected set” • SQL (Standard Query Language) • e.g.,SELECT*FROM landuse WHERE[ZONE]=492 • “landuse” is the table name; “ZONE” is the Field to search; 492 is the numeric code designating property as commercial

7. Joining tables • Tables can be related to each other or joined by using a common field (column) • Joining a table has a DIRECTION • Direction is important because of what he resulting data table might be used to complete • Because there is a direction, there is a SOURCE table and a DESTINATION table

8. Joining and relating tables Joining in this way yields a table capable of being mapped; reversing the source and destination labels yields only a stand alone table. Why?

9. Cardinality • simply put, cardinality means how data relate to each other • 2 main designations • 1 to 1 relationship - each record (row) in the destination table has a match in the source table • Many to 1 - each record in the destination has multiple matches in the source tables • 1 to Many - each record in the destination table match a single record in the source table

10. Examples of cardinality

11. Cardinality • When determining cardinality, direction is important and it must not violate the rule of joining • i.e., 1 and only 1 record in the output table (destination) for each record in the input table (source)

12. One linked to Many table violates the rule of joining