Hierarchical Data Model

Session 05

Structure of the Model

A hierarchical data model organizes data

according to associations that are represented

as trees.
It has collection of records logically arranged

to create a tree structure.

The entity (record) type at the top of the tree

is usually known as the root.

The root may have any number of

dependents; each of these may have any

number of lower-level dependents, and so on,
to any number of levels.
Each upper layer is known as the parent of

the segment which directly beneath it, they

are the children of that parent.
Each parent can have many children. But

each child has only one parent.

The example used to illustrate the hierarchical

model is a database containing details of

programming work being carried out in a
software company.
Database must hold information about

software projects: name of project, date

started estimated cost etc.

Finally, it is necessary to hold information of

which programmers work (from time to time)

on which project and vice versa.
Together with a log showing for each

programmer how many hours he has worked

on each project with which he is concerned.
In the hierarchical model, as its name

suggests, we must choose one of the data

entities as superior and list the others as
subordinate to it.
One possibility is to have project at the top

level.

The tree structure with the attributes of the

entities is shown in Figure 5.3.

Figure 5.4 shows a few records to indicate

how user would think of the data when

accessing it via such a model.

Of course, it would be equally simple to

arrange the same data with programmers at

the top level as shown in Figure 5.5.

Characteristics of the model

The hierarchical database model's features

yielded many advantages over the file system

model.
Many of the hierarchical database model's

features helped to form the foundation for the

current database models.
Many of its database application advantages

are replicated, but in different form, in current

database environments.

Advantages
Conceptual simplicity
Given this database model's hierarchical structure,
the relationship between the various layers is
logically simple. Therefore, it becomes easier to
view the database conceptually, thus making its
design process simpler.

Database security
Database security is provided and enforced by the
DBMS that has been built for the hierarchical
database model.
Therefore, security is enforced uniformly
throughout the system, without having to rely on

Data independence
The DBMS creates an environment in which data
independence can be maintained, thereby
substantially decreasing programming effort and
program maintenance.
(Data independence exists when a change in a data
type will be automatically cascaded throughout the
database by the DBMS, thus eliminating the need to
make changes in the program segments that
reference the changed data type.)

Database integrity
Given the parent/child relationship, there is always a
link between the parent segment and its child
segment(s). Because the child segment is always

Efficiency
The hierarchical database model is very efficient
when a database contains a large volume of data
in 1:M relationships and when users require large
numbers of transactions, using data whose
relationships are fixed over time.

Disadvantages
Complex implementation
Although the hierarchical model's DBMS relieves
the designer and programmer of the datadependence problems, they still must have
detailed knowledge of the physical data storage
characteristics. Therefore, the implementation of

Difficult to manage
Any changes in the database structure, such as
the relocation of segments, require changes in all
application programs that access the database.
Therefore, database management has become a
difficult chore.
The hierarchical structure has database integrity,
this structure also makes it possible to perform a
deletion of one segment that leads to the
involuntary deletion of all the segments under it.

Lacks structural independence

The hierarchical database is known as a
navigational system because data access
requires that the physical storage path be used to

Within a navigational database system, the

programmer must know the access paths to relevant
segments (the parent record must be accessed first,
in order to access the child records) to retrieve data
from the database.
Modifications in the database structure can lead to
problems with application programs that were
operating correctly before the changes were made.

Applications programming and use

complexity
Because hierarchical model has a navigational
database system's structure, application
programmers and end users must have a thorough
knowledge about how the data are distributed

Implementation limitations
Many common relationships do not conform to
the 1:M standard required by the hierarchical
model.
Example
Consider a student enrolled at a university. Each
course can contain many students, and each
student can take many courses. Such a common
many-to-many (M:N) relationship is difficult to
implement in a hierarchical model.
In addition, quite a few real-world relationships
are based on a child with multiple parents are
also difficult to implement in a hierarchical
model.

Lack of standards
Although the basic hierarchical model is
incorporated in all hierarchical database software,
there is no precise set of standard concepts, nor
does the implementation of the model conform to
a specific standard.
This model neither had a standard data definition
language (DDL) to define the database
components, nor did it have a data manipulation
language (DML) to manipulate the database
contents.
Therefore, moving from one hierarchical DBMS to
another was difficult; that is, portability was
limited.