Topic 2.

4: The Evolution of Data Models

The quest for better data management has led to different models that attempt to
resolve the file system’s critical shortcomings. Because each data model evolved
from its predecessors, it is essential to examine the major data models in roughly
chronological order.

2.4.1 The Hierarchical Model

The first data model was developed by Rockwell and IBM in the 1970s. It is
known as the hierarchical model. The hierarchical database is a collection of
records that is logically organized to conform to the upside-down tree
(hierarchical) structure. Within the hierarchy, the top layer (the root) is perceived
as the parent of the segment directly beneath it. While this model represents
1:M relationships well, it does not represent M:N relationships.

Basic Structure
Given its manufacturing heritage, the hierarchical model’s best basic logical
structure is best understood when you examine a manufacturing process. For,
example, let’s examine a somewhat simplified production process that creates a
filing cabinet:

1. A filing cabinet has many components: a frame, a set of drawers, and

sliding bars for those drawers.
2. A component may be composed of many smaller assemblies. For
example, each drawer has a handle with a latching mechanism, a set of
rollers that fits into the frame’s sliding bars, and a divider blade.
3. An assembly may contain many parts. For instance, each roller is
composed of a small wheel, an axle, and a brace.
4. The production process is based on data relationships that remain fixed
over time. Whether a given filing cabinet model is produced today or
tomorrow, the same parts are put together in the same ways to produce
the same assemblies that are combined to produce the same components
that are assembled in the same way to create the filing cabinet.

Tracking the parts, the assemblies, and the components we have just described
is facilitated by understanding the logical process that is represented by the
upside-down “tree,” known as a hierarchical structure, shown in Figure 2.1. We
have labeled the structure’s components to help you understand the basic
hierarchical model’s vocabulary.

As you examine Figure 2.1, note that the user perceives the hierarchical
database as a hierarchy of segments. A segment is the equivalent of a file
system’s record type. In other words, the hierarchical database is a collection
of record segment structures that is logically organized to conform to the
upside-down tree (hierarchical) structure shown in Figure 2.1.Within the
hierarchy, the top layer (the root) is perceived as the parent of the segment
directly beneath it.

For example, in Figure 2.1, the root segment is the parent of level 1segments,
which in turn, are the parents of the level 2 segments, and so on. In turn the
segments below other segments are the children of the segment above them. In
short:

° Each parent can have many children

° Each child has only one parent
In this hierarchical structure, it is easy to trace both the database’s components
and the 1:M relationships among them.

Advantages
– Conceptual simplicity
– Database security
– Data independence (because the data characteristics of the database
structure are not defined in the programs accessing the database, instead
the database structure and its data characteristics are defined in the data
dictionary component of the DBMS. Therefore the programs accessing
the database become independent of the database)
– Database integrity (because data duplication or data redundancy is
minimized as a result of relating the segments or records)
– Efficiency (the hierarchical DBMS file storage organization and access
methods are based on the new hierarchal database structure which is
much faster than the file storage organization and access methods used in
 the old file system)

Disadvantages
– Complex implementation
– Difficult to manage
– Lacks structural independence (because the programmer still needs to
write instructions on how and where to find the data stored on the
computer disk, which depends on the database structure)
– Complex applications programming and use
– Implementation limitations (because the hierarchical data model does not
support entities or record segments having multiple parents which are
modeled in a M:M relationships between two or more entities)
– Lack of standards among the implementation software (DBMS) developed
by various software vendors

2.4.2 The Network Model

The network model was created to represent complex data more effectively than
the hierarchical model could, to improve database performance, and to impose a
database standard.

Basic Structure
In many respects the network model resembles the hierarchical model. For
example, as in the hierarchical model, the user perceives the network database
as a collection of records in 1:M relationships. However, unlike the hierarchical
model, the network model allows a record to have more than one parent or
multiple parents. This feature allows the network model to handle complex (M:M)
relationships between two or more entities, such the commonly encountered M:M
relationships depicted in Figure 2.2 can be handled easily by the network model.

In Figure 2.2, the M:M relationship between the ORDER and PART is resolved
by the introduction of the ORDER_LINE bridge entity.

In network database terminology, a relationship is called a set. Each set is

composed of at least two record types: an owner record and a member record.
The difference between the hierarchical model and the network model is that the
latter might include a condition in which a record can appear (as a member) in
more than one set. In other words, a member may have several owners. A set
represents a 1:M relationship between the owner and the member. An example
of such a relationship is depicted in Figure 2.3.

Advantages
– Conceptual simplicity
– Handles more relationship types
– Data access flexibility
– Promotes database integrity
– Data independence
– Conformance to standards

Disadvantages
– System complexity
– Lack of structural independence (because the programmer still needs to
write instructions on how and where to find the data stored on the
computer disk, which depends on the database structure)
2.4.3 The Relational Model
The basic building block of the relational model is the table, which is a matrix of
rows and columns. Tables are related to each other via a common entity
characteristic or attribute (primary key in the parent table is a foreign key in the
child table). The parent table is the table which maps to the entity of the “1” side
of the relationship and the child table maps to the entity of the “many” side of the
relationship between the two tables.

All three relationship types are easily represented in this model. One of the
disadvantages of the relational model is that it requires substantial system
overhead to run the Relational DBMS (RDBMS). However, with the currently
available advanced computer hardware and software, high requirements for
processing relational databases do not represent an overhead problem any
more.

Basic Structure
The relational data model is implemented through a very sophisticated relational
database management system (RDBMS). The RDBMS performs the same
basic functions provided by the hierarchical and network database systems, plus
a host of other functions that make the relational data model easier to understand
and to implement.

The most important advantage of the RDBMS is its ability to let the user/designer
operate in a human logical environment. The RDBMS manages all of the
complex physical details. Thus, the relational database is perceived by the user
to be a collection of tables in which data are stored.

Each table is a matrix consisting of series of row/column intersections. Tables,

also called relations, are related to each other by sharing a common entity
characteristic/attribute. For example, the CUSTOMER table in Figure 2.4 might
contain a sales agent’s number which maintains a common link to the agent
table.
The common link between the CUSTOMER and AGENT tables thus enables us
to match the customer to his/her sales agent, even though the customer data are
stored in another table. Although the tables are completely independent of one
another, we can easily connect the data between tables. The relational model
thus provides a minimum level of controlled redundancy to eliminate most of the
redundancies found in old file systems.
The relationship type (1:1, 1:M, or M:N) is often shown in a relational schema, an
example of which is depicted in Figure 2.5. A relational schema is a visual
representation of the relational database’s entities, the attributes within those
entities, and the relationship between those entities.

As you examine Figure 2.5, note that the relational schema shows the
connecting fields (in this case, AGENT_CODE) and the relationship type, 1:M.
MS Access DBMS software used to generate Figure 2.5, employs the ∞ symbol
to indicate the “many” side. In this example, the CUSTOMER represents the
“many” side because an AGENT can serve many CUSTOMERS. The AGENT
represents the “1” side, because each CUSTOMER is served by only one
AGENT.

Advantages
– Structural independence
– Improved conceptual simplicity
– Easier database design, implementation, management, and use
– Ad hoc query capability
– Powerful database management system

Disadvantages
– Substantial hardware and system software overhead (this is not an issue
any more because of the currently available hardware and software)
– Can facilitate poor design and implementation (Less experienced
database designers may develop poor database design)
– May promote “islands of information” problems (because various users in
different departments will be developing their own database applications)

2.4.4 The Entity Relationship Model

An alternate model is the Entity Relationship (ER) model. In this model, entities
are drawn by using diagrams with line connectors that depict their relationships.
This model has the advantage of visually depicting relationships. A disadvantage
is that there is no corresponding (data management language (DML).

The ER model or ERM is a widely accepted and adapted graphical tool for data
modeling. Peter Chen first introduced the ER data model in 1976 in his landmark
paper “The Entity Relationship Model: Toward a Unified View of Data”. The ERM
yielded a graphical representation that popularized the use of the ER diagrams
as a tool for conceptual-level data modeling. Better yet, the ER model
complemented the relational model concepts, thus providing the foundation for a
tightly structured database design environment to ensure the proper design of
relational databases.

Basic Structure

ER models are normally represented in an entity relationship diagram (ERD),

which uses graphical representations to model the database requirements.

° An entity is represented in the ERD model by a rectangle, also known as

an entity box. The name of the entity, a noun, is written in the center of the
rectangle. The name of the entity is generally written in capital letters and
is written in singular form: PAINTER rather than PAINTERS. Normally,
 when applying the ERD to the relational model, an entity is mapped to a
relational table. Each row in the relational table is known as an entity
instance or entity occurrence in the ER model. Each entity is described
by a set of attributes that describe particular characteristics of the entity.
For example, the entity EMPLOYEE will have attributes such as Social
Security number, a last name, and a first name.

° Relationships describe associations among data entities. Most

relationships describe associations between two entities. ERD modelers
use the term connectivity to label the types of relationships (1:M, M:N,
1:1). The entity connectivity is written next to each entity box.
Relationships are represented by a diamond connected to the related
entities through a relationship line. The name of the relationship, an active
or passive verb, is written inside the diamond. For example, each of the
company’s DEPARTMENTs has many EMPLOYEEs. And a PAINTER
paints many PAINTINGS.

Figure 2.6 shows some basic ERD models that illustrate these relationships and
connectivity type.

The ERD shown in Figure 2.6 is based on the so-called Chen model. Although
the entities and relationships are shown in a horizontal format in Figure 2.6, they
also may be oriented vertically. The entity location and the order in which the
entities are presented are immaterial – just remember to always read a 1:M
relationship from the “1” side to the “M” side.

A more current version of the ERD is the Crow’s Foot Model shown in Figure
2.7. The label “Crow’s Foot” is derived from the three-pronged symbol used to
represent the “many” side of the relationship. The Crow’s Foot model places the
relationship name in the relationship line.

As you examine the basic Crow’s Foot ERD in Figure 2.7, note that the
connectivity is represented by symbols. For example, the “1” is represented by a
short line segment and the “M” is represented by the three-pronged “crow’s foot.”
Like the Chen ERD, the entities and the relationships may be represented
horizontally or vertically. And again like the Chen ERD, the location and the order
in which the entities are presented in a Crow’s Foot ERD are immaterial.

Advantages
– Exceptional conceptual simplicity
– Visual representation
– Effective communication tool
– Integrated with the relational data model

Disadvantages
– Limited constraint representation
– Limited relationship representation (relationships between attributes can not
be modeled)
– No data manipulation language
– Loss of information content (limited space is available to draw large number
of entities in the Chen original notations of the ERD technique)
2.4.5 The Object Oriented Model
In the Object Oriented model entities are represented as objects that contain
both data and operations. An advantage of this model is the addition of semantic
content. A disadvantage is the steeper learning curve.

The semantic data model (SDM) modeled both data and their relationships in a
single structure known as an object. Because its basic modeling structure is an
object, the SDM is said to be an object oriented data model (OODM). In turn,
the OODM becomes the basis for the object oriented database management
system (OODBMS).

An OODM reflects a very different way to define and use entities. Like the
relational model’s entity, an object is described by its factual content. But, quite
unlike an entity, an object includes information about relationships between the
facts within the object, as well as information about relationships with other
objects. Therefore, the facts within the objects are given greater meaning.

Basic Structure

The object oriented data model is based on the following components:

° An object is an abstraction of a real-world thing. An object class is a

representation of a set of objects with shared attributes and behavior. For
example, an object class student is a model of all students in an
educational institution. An object class may be considered equivalent to
an ER model’s entity. More precisely, an object represents only one
individual occurrence of an entity.
° Attributes describe the properties of an object. For example, a PERSON
object class includes the attributes ID, Name, Social Security Number and
Date of Birth.
° Objects that share similar characteristics are grouped in classes. A class
is a collection of similar objects with shared structure (attributes) and
behavior (methods). In a general sense, a class resembles the ER
model’s entity set. However, a class is different from an entity in that it
contains a set of procedures known as methods. A class’s method
represents a real-world action such as finding a selected PERSON’s
name, changing a PERSON’s name, or printing a PERSON’s address. In
other words, methods are the equivalent of procedures in traditional
programming languages. In object oriented terms methods define an
object’s behavior.
° Classes are organized in class hierarchy. The class hierarchy resembles
an upside-down tree in which each class has only one parent. For
example, the CUSTOMER and EMPLOYEE class share a parent
PERSON class. However it is possible that one child class to have
 multiple parents.
° Inheritance is the ability of an object within the class hierarchy to inherit
the attributes and methods of the classes above it. For example, we can
create two classes, CUSTOMER and EMPLOYEE, as subclasses from
the class PERSON. In this case CUSTOMER and EMPLOYEE will inherit
all attributes and methods from PERSON.

To illustrate the difference between the OO model and the ER model, let’s
examine their graphic representations in the simple invoicing problem shown in
Figure 2.8.

As you examine Figure 2.8, note that:

° The OO data model represents an object class as a box; all of the object’s
attributes and relationships to other objects are included within the object
class box. The object class representation of the INVOICE includes all
related objects within the same object class box.
° The ER model uses three separate entities and two relationships to
represent an invoice transaction. Because customers can put more than
one item at a time, each invoice references one or more lines, one item
per line. And, because invoices are generated by customers, the data-
modeling requirements include a customer entity and a relationship
between the customer and the invoice.

Advantages
– Adds semantic content
– Visual presentation includes semantic content
– Database integrity
 – Both structural and data independence

Disadvantages
– Slow pace of OODM standards development
– Complex navigational data access
– Steep learning curve
– High system overhead slows transactions
– Lack of market penetration

2.4.6 Other Models

Another semantic data model was developed in response to the increasing
complexity of applications- the extended relational data model (ERDM). The
ERDM championed by many relational database researchers constitutes the
relational model’s response to the OODM challenge. This model includes many
of the OO model’s best features within an inherently simpler relational database
structural environment. That’s why a DBMS based on the ERDM is often
described as an object/relational database management system (O/RDBMS).

The OODM and ERDM are similar in the sense that each attempts to address the
demand for more semantic information to be incorporated into the model.
However, the OODM and the ERDM differ substantially both in underlying
philosophy and in the nature of the problem to be addressed.

Although the ERDM includes a strong semantic component, it is primarily based

on the relational data model’s concepts. In contrast, the OODM is wholly based
on the OO semantic data model concepts. The ERDM is primarily geared to
business applications, while the OODM tends to focus on very specialized
engineering and scientific applications. In the database arena, the most likely
scenario appears to be an ever-increasing merging of OO and relational data
model concepts and procedures.

2.4.7 Data Models: Summary

The evolution of database management systems has always been driven by the
search for new ways of modeling increasingly complex real-world data. A
summary of the most commonly recognized data models is shown in Figure 2.9.
Concept Check
What are major types of data models?

How does the hierarchical data model address the problem of data redundancy?

What are the features of relational data models?