Principles of

Geographic
Information
System
Dr. Zubeida Ali B. Aladwan

Dr. ZubeidaAli Aladwan, Albayt University

Lecture 7_ Attribute Data and Tables
-Database Components and Characteristics,
-Selection Based on Attributes,
-Joining (or Relating) Tables
 Attribute data
GIS are often split into two components, the coordinate information that describes
object geometry, and the attribute information that describes the nonspatial
properties of objects.
Because these nonspatial data are frequently presented to the user in tables,they are
often referred to as tabular data.
Tabular data summarize the most important nonspatial characteristics of each
cartographic object, Ex.

Data in a GIS include both

spatial (left) and attribute
(right) components.
 Attribute data
Attribute information in a GIS are typically entered, analyzed, and reported using a database
management system (DBMS), a specialized computer program for organizing and
manipulating data.
The DBMS stores the properties of geographic objects and the relationships among the
objects.
A DBMS incorporates software tools for managing tabular data, including those for efficient
data storage, retrieval, indexing, and reporting.

Note that the terms DBMS and database

are sometimes used interchangeably.
In most cases this is incorrect and in all cases
imprecise.
A DBMS is a computer program that allows you
to work with data. A database is an organized
collection of data, often created or manipulated
with the help of a DBMS.
The database may have a specific form dictated
by a DBMS, but it is not the system.
Database Components and Characteristics,
oThe basic components of a
traditional database are data
items or attributes
oThese items can be identifiers,
sizes, areas, coordinates, colors,
or any other suitable
characteristic used to describe
the features of interest.
oAttributes may be simple, for
example, one word or number,
or they may be compound, for
example, an address data item
that consists of a house
number, a street name, a city,
and a zip code.
 Database Components and Characteristics,
•Items have a type and a
domain that restrict the
values they may take.
•Types define essential characteristics of an
item.
Common types include real numbers,
integer numbers, both of various lengths,
hexadecimal numbers, text fields,
hyperlinks, and binary large objects (blobs)
Domains define the acceptable values an
item may take,
for example, integers may be restricted to
be larger than 0 but smaller than 10, or
there may be a type name “color” that can
only take on the values “red”, “green”,
“blue”,“yellow”, “cyan”, or “magenta.”
You should note that the concept of an
entity, when referred to in a database, may
be slightly different than an entity in a GIS
data model.
-This difference stems from two different groups,
geographers and computer
scientists, using a word for different but
related concepts;
An entity in a geographic data model is often used
for the real-world item or phenomenon we are trying to
represent with a cartographic object. Ex. a lake, city, or
building, but they may also be a conceptual
phenomenon, such as a property boundary.
In contrast, computer scientists and database
managers often define an entity as the principal data
objects about which information will be collected. In
the DBMS literature, the entity is the data object that
denotes a physical thing, and not the thing itself.
 Database Components and Characteristics,
•DBMS typically supports complex structures,
primarily to provide data security, to maintain
stability, and to allow multiple users or programs to
access the same data simultaneously.

• Database users often demand shared access, that is,

multiple users or programs may be allowed to open,
view, or modify a data set simultaneously.

•The DBMS is sometimes referred to as a database

server, and the applications programs as clients.
 Database Components and Characteristics,
The separation of data and functions into multiple levels is often referred to as a multi-tiered architecture

•Data are primarily stored at the lowest tier. These data may be of diverse types, including coordinate data,
attributes, text, images, sound, video recordings, or other important, persistent data.

•Data sets at the lowest tier may be managed by an individual database system. The system or programs that
access the first tier, at the bottom of a multitier system is often called a transaction manager. This
transaction manager typically takes requests from higher tiers and searches the relevant portions of the
database to identify the requested data, or perform the requested operation.

•The next tier in the multitier architecture is often referred to as an applications server. The use of the term
server may be a bit confusing, because server is also used to describe a computer on which data are stored,
and also to describe the database management program in two-tier systems. In the context of a multi-
tiered database architecture, an applications server is software that passes requests from higher-level tiers
to the transaction manager.
 Database Components and Characteristics,

Multitier architecture, and common software alternatives. Data are stored and accessed from
databases on the bottom tier, and data viewed requests made at the upper tier. Applications servers act upon the request and translate/process information passed between upper and bottom
tiers. In wellbehaved systems that adhere to defined standards, the components may be mixed, e.g., you may access data in ArcSDE from QGIS, or data stored in PostGIS from ArcMap
(adapted from Boundless).
 Selection Based on Attributes
The Restrict Operator: Table Queries
-Queries are among the most common
operations in a DBMS. A query may be
viewed as the selection of a subset of
records based on the values of
specified attributes.
-Queries may be simple, using one
variable, or they may be compound,
using conditions on more than one
variable, or using multiple conditions
on one variable.

Many GIS softwares provide a query

builder, a graphical user interface (GUI) that
helps in applying selection operations.
Most GUIs include a list of available
Selection Based on Attributes
The Restrict Operator: Table Queries; Simple vs Compound (AND, OR, NOT) Queries
Selection Based on Attributes
The Restrict Operator: Table Queries; Complex Query
 Joining/Relating Tables
Relational databases are so powerful in part
because we can structure out data in ways that
reduce duplication, are easier to maintain, and
are flexible; much of this flexibility is because
we can join tables. A join, also known as a
relate, uses columns in one table to match rows
based on columns in other tables.
Joins are based on joint items, or join fields. In
their simplest form, a single column in one
table is matched to a column in another table,
and a new table “created” by combining rows
for matched values.

“copying”
the values from
the matching row
in the
source table
This figure illustrates a simple join. Table B is joined to Table A, matching the Code_B values
to corresponding Code_A values, to create Out Table.
 Primary Key and Join
keys are “key” to relational databases, and as such they have certain special characteristics, which we’ll describe here. There are several kinds of
keys, but the most important is the primary key, an item (or sometimes multiple items) that uniquely dentifies each row in a table. We often
create and generate these unique numbers to keep track of things, for example, a social security number is unique to a person; a parts ID number
is often uniquely assigned by a manufacturer; and SKU numbers are unique to items in a store.
ID_A is a primary key for Table A because the values uniquely identify the rows. Table B in that figure has three columns that could serve as
primary keys, Type_B, Code_B, or Size_B. These are all candidate keys, because each could serve as a primary key. Typically, when this happens,
one of the columns is designated and used as a primary key.
Most joins should involve a one-to-one or a one-to-many relationship between the source and the target join items. This is why we usually use a
primary key in our source table as the column for a join, or we use an item that could serve as a primary key. This avoids a many-to-one
relationship between source and target columns, which often results in problems.

An example of a one-to-
one and one-to-many
relationships between
tables
Primary Key and Join

An example of a many-to-many table join

Multitable Joins

An example of a multi-table join, based on

different keys. Here, County and District
tables are joined to the School Table, to create
an Output Table.