The Database Approach

As the information system field developed during the late 1960s and early 1970s, the
concept of the database (the information to be stored) and the database
management system (the software used to manage the database) were developed.
Today, sophisticated database management systems (DBMS) are used to handle
enormous databases.

A database is essentially a collection of information about things and there

relationships. For example, a database may consists of names and addresses, land
– quality, uses, ownership, etc information. The items stored in a database may also
include processes, for example, the process of erosion, water pollution and
agricultural development may be related to “rain forest clear-cutting”.

A database is therefore formally defined as “an organized collection of related sets of

data, managed in such a way as to enable the user(s) or the application program(s)
to view the complete collection or a logical subset of the collection as a single unit”
(Oxbrow, 1986).

Early database systems, like other computer software, were developed to provide a
well-defined set of functions using a specified set of data. The data were stored as
one or more computer files that were accessed by special purpose database
software. This file processing approach to database management is illustrated in
Figure 3.3 below showing a university administration application.

Figure 3.3 Sharing data files among applications in the File Processing Environment

The file processing approach has some serious drawbacks. First, since each
application program/user must directly access each data file that it/he/she uses, the
program/user must know how the data in each file are stored. This can create
considerable redundancy.

Secondly, if modifications are made to the data file, access instructions must be
modified too.

Another problem arises when data are used by different application programs/users
who can access and modify data and access information i.e. lack of central control
which jeopardises data integrity/quality.
It can thus be seen that a database system is essentially nothing more than a
computerized record keeping system, whereas the database itself can be regarded
as an electronic filling cabinet of some kind i.e. a repository for a collection of
computerized data files (Date, 1986:1). The user of a database system has the
facilities to perform a variety of operations on such files, including the following
among others:
• Adding new files to the database
• Inserting new data into existing files
• Retrieving data from existing files
• Updating data in existing files
• Deleting data from existing files
• Removing existing files from the database

To facilitate this, a database management system (DBMS) is used. A DBMS is a set

of computer programmes that control data input, storage, retrieval/output from a
digital database (Burrough, 1986:15). The DBMS concept is an important
improvement over the file processing approach. The DBMS acts as a central control
over all interactions between the database and the application programs/users as
shown below.

Figure 3.4 Sharing data files among applications in a Data Base Management System Environment
(Aronoff, 1989)

The database approach provides organizations with centralized control of its

operational data. Such a situation contrasts sharply with that found in an
organization without a database system, where typically each application (section)
has its own private files – quite often its own private diskettes and PCs too – so that
operational data is widely dispersed and is therefore quite difficult to control in any
systematic way (Date, 1986:12).

Advantages
This concept of centralized data implies that there will be some identifiable person
who has control responsibility for the operational data. Several advantages arise
from this notion of centralized control. Among others these include:

1. Redundancy can be reduced or controlled.

In non-database systems each application/user has its own files. This often leads to
considerable redundancy in stored data with the resultant waste in storage and
executing time.

This problem is solved in a database system by integrating the various files for
example a) in a university database the academic vs the administration files, b) in a
business organization creditors vs debtors files, etc.

2. Inconsistencies can be avoided (to some extent).

This occurs particularly during updates when one user or department updates their
files and others don’t then there arises some inconsistencies.

When redundancy is controlled/eliminated by files integration in a database such

inconsistencies will not occur since data update is entirely controlled – in a process
referred to as propagating updates, where update is taken to include all the
operations of insertion, deletion and modification.

3. Data can be shared more easily/efficiently.

Sharing means not only that existing users/applications sharing the data in the
database, but also that new applications/users can be developed or incorporated to
use the same stored data.

This means that it is possible to satisfy the data requirements of new

users/applications without having to create any additional stored data.

4. Standards can be enforced.

With central control of the database approach it is easy to ensure that all applicable
data standards (organizational, national, regional or international) are observed in
the representation and coding of data.

Standardizing stored data is particularly desirable and can aid data interchange or
migration between systems.

Likewise, data naming (coding) and documentation standards are also very desirable
as an aid to data sharing and understandability.

5. Security restrictions can be applied.

This implies
a) ensuring that access to the database is through proper channels – use
of passwords,
b) impose security checks whenever access to sensitive data is
attempted,
c) updates are controlled and streamlined.
To ensure smooth running/sharing, different security checks can be established for
each type of access (retrieve, update, modify, delete, etc). Since without such
checks the security and integrity of the data is actually at a higher risk than in a
traditional filing system.

6. Ensures data independence.

One of the primary functions of a database management system is to free the user
and/or programmes from the responsibility of knowing the physical details (length,
location and arrangement) of the data stored. This leaves the user with the chance to
concentrate with the logical or informational aspects of the data.

DBMS separate the data from programmes that access it thus reducing access
barriers and hence enhancing horizontal and vertical integration.

Disadvantages
There are some disadvantages associated with the database approach including:

1. Complexity

Inevitably, the DBMS is a complex piece of software and requires database experts
both to look after it and also design and develop the database and applications.

2. Cost

Comprehensive DMBS are expensive to purchase and give rise to additional

overheads when in operation – overheads in terms of processing and storage space.

3. Inefficiencies in processing

Unexpected changes in usage patterns or changes in users may give rise to

inefficiencies in processing data request, it is essential to monitor the use of the
database to detect such inefficiencies and if necessary re-structure the database

4. Rigidity

Most DBMS’s were designed to manage particular type of data; fixed format records;
until recently, other types of data such as text and graphics have had to be excluded
from databases and even not the ability to include them are still quite restrictive.

In addition to the above disadvantages, the creation of a single database containing

all the organizations data is not always feasible. Some large organizations are too
complex to be modelled in a single database and multiple databases have to be
accepted.

A DBMS organises data from the same source into information suitable for different
users/uses, each of these referred to a database view. Figure below illustrates this
concept using database comprising of client names, addresses, purchases and
inventory information. These data are presented using to views one for accounts
executive, showing sales accounts and for inventory manager, showing items
available.

Figure

By providing different views, the DBMS tailors the data base to each user – a very
valuable function – without storing multiple copies of the same data.

DATABASE MODELS

The conceptual organization of a database is referred to as a database model, which

can be described as the style of describing and manipulating the data in a database.
Several database models with varying complexities, each with its own inherent
advantages and disadvantages have been developed.
In this chapter we shall look at four classical database models which have found
wide applications in both business organizations and GIS, these are the hierarchical,
network, relational and object-oriented database models.

As we saw in the data organization section, the contents of a data file can be
described using records and fields. A record is a group of related data items stored
together, which can be thought of as one row in a table as shown below.

Profile ID SERIES pH DEPTH DRAINAGE TEXTURE EROSION

1 A 4 Deep Good Sandy Severe
2 B 5 Shallow Good Clay Moderate
3 C 6 Shallow Poor Sandy Moderate
4 D 7 Deep Good Clay Non
5 E 4 Deep Poor Clay Moderate
 6 F 5 Shallow Poor Clay Non

Here the first record contains information for the soil profile number 1. The records
represents the information pertaining to a particular entity/element, soil profile. A
record is divided into fields, each of which contains an item of data. A field defines
where a particular type of data can be found in the record, for example the data
fields in the table above include profile id, series name, pH, depth, texture and
erosion.

We introduce another concept, the key, which is a label comprised of one or more
fields by means of which a record can be identified/retrieved from the database. In
our example the profile Id could be designated the key. Fields which are not
designated as key fields are referred to as attribute fields.

We start by looking at the simplest model which is known as the hierarchal database
model.

The Hierarchical Database Model

When the data have a parent-child or one-to-many relation such as soil series within
a soil family or an academic department within a university, hierarchical methods
provide quick and convenient means of data access. Hierarchical systems of data
organization are well–known in environmental science, being the methods used for
animal and plant taxonomies, soil classification, land cover classification, etc.

In the hierarchical database model the data are organized in a tree structure as
shown in part A of Figure below. The relations among the five entities (university,
departments, lecturers and courses) are defined by the organization of the hierarchy,
which is encoded in the data records for each entity as shown in part B. The field
names are shown in the top half of each box and a sample data record is shown in
the lower half. There is one key that is designated as the key field that is used to
organize the hierarchy, which is represented by the arrows connecting the key field
(bolded) in each data record.

Figure 3.5 Organization of a Database Using the Hierarchical Database

Model (Adapted from Aronoff, 1989)
It is assumed that each part of the hierarchy can be reached using the key since it is
assumed that there is a good correlation between the key attributes and the
associated attributes that entities may posses.

The top of the hierarchy is referred to as the root and is composed of one entity, in
our example the University. The root may be represented by a record containing a
single data field (as our case) or by a record containing many fields.

Except for the root, every element has one higher level element related to it, termed
as its parent, and one or more subordinate elements termed children. An element
can have only one parent but can have multiple children (one-to-many relationship).

Advantages
Hierarchical systems are easy to understand and are also easy to update and
expand.

Disadvantages
To retrieve information one has to traverse the tree structure. Retrieving information
of all students or all lecturers (key fields) from a specific department is very easy
since there is a direct link between student or lecturer with the departments.
However, to find all course (non-key field) offered by a specific department requires
a two stage search (search of all lecturers and then all courses associated to each
lecturer), making the process inefficient.

Searches cannot be done on attribute fields. For example we cannot search for all
second year students in the database above since the Year of Study field is not a
key field.

Consequently, hierarchical database models are only good for data retrieval if the
structure of all possible queries are known before hand so as to guide in the
selection of key fields. In most geographical analyses, the data searches are often
exploratory and cannot be predicted in advance like in the case of bibliographic
systems.

The Network Database Model

Some of the inflexibilities of the hierarchical database model can be overcome by the
network database model by allowing multiple parents as well as multiple children and
by doing away with the root. This allows searching of data records directly without
traversing the entire hierarchy above that record. The university database used
above is shown below using the network database model.
The Course entity can now have two parents i.e. Department and Lecturers entities.
A search of all courses in a specified department can now be done more directly.

The Student-Course is a many-to-many relation, i.e. each student can be enrolled in

many courses and each course can have many students. Although the network
model does not allow many-t-many relations, such relations can be handled using an
intermediate relation - an intersection record as shown in Figure above. In this
example the intersection records represent the Student-Course combinations, i.e.
the registration of students in courses. Each Student-Course combination is unique.

Network models tend to have less redundant data storage than corresponding
hierarchical model. However more extensive linkage information is must be stored,
adding to the size and complexity of the data files.

The Relational Database Model

In its simplest form, the relational database model consists of data stored in simple
records known as tuples which contain an ordered set of attribute values that are
grouped together in two-dimensional tables known as relations. Each table is
usually a separate file.

1. Course Information 2. Registration Information

Prof. Course Course Course Course Course Student

ID Dept. Name Code Time Code ID

3. Student Information

Studen Last First Yr GPA Dept 4. Department Information

ID Name Name

Dept No. of Other Grad

Name Profs staff students

5. Professor Information

Prof Last First Experience Department

 Figure 3.8 Organization of a Database Using the Relational Database
Model (Adapted from Aronoff, 1989)

In the relational database model there is no hierarchy of data fields within a record;
every data field can be used as a key. A search can be made of any of any single
table using any of the attribute fields, singly or together. For example the Student
Information table can be used to search for all students in year 4 just as easily as it
would be to search for all students with last Koech.

Searches of related attributes that are stored in different tables can be done by
linking two or more tables using any attribute they share in common using a join
operation. The shared attribute need not itself be part of the relation being analysed.

Figure 3.9 The Relational Join Operation

The figure above illustrates how the database in Figure 3.8 could be searched to
generate a student list for a specific course. Tables 1,2 and 3 are joined by means of
the Course-ID and Student-ID attributes. In effect Table 1 is joined to Table 2 by
Course-ID which they have in common, while Tables 2 and 3 are linked by the
Student-ID attribute. A new table, Table 6 is created from this relational join
operation.
Table 6 is in fact a “virtual table”, i.e. it does not physically exist although it can be
queried.

This logical join operation gives the relational database model tremendous flexibility.
It is able to accommodate diverse queries for which it was not specifically designed.
This flexibility has made this model one of the most commonly used for storing
attribute information in GIS.