Scribd
Upload
63 views

Hierarchical Data Model

The hierarchical data model is the oldest model, dating back to the 1960s. It uses a tree structure to organize data, with parent-child relationships allowing one-to-many relationships. Queries can easily follow links from parent to child but not from child to parent. The object-oriented model builds on hierarchical structures, allowing for complex objects, type hierarchies where subtypes specialize types, and methods to encapsulate behavior. Objects have identity and can be composed from other objects using records and sets.

Uploaded by

AlainGarGa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
63 views

Hierarchical Data Model

The hierarchical data model is the oldest model, dating back to the 1960s. It uses a tree structure to organize data, with parent-child relationships allowing one-to-many relationships. Queries can easily follow links from parent to child but not from child to parent. The object-oriented model builds on hierarchical structures, allowing for complex objects, type hierarchies where subtypes specialize types, and methods to encapsulate behavior. Objects have identity and can be composed from other objects using records and sets.

Uploaded by

AlainGarGa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

HIERARCHICAL

DATA
MODEL
Hierarchical Data Model
History:
• The oldest of the three models, dating from 1960’s
• “Ad Hoc” solution to immediate needs of real applications
• The oldest hierarchical database system, IBM’s IMS, was
developed to organize and store information needed by the space
program for the Apollo Landing Project.
• The first hierarchical DBMS is “IMS” and it was released in 1968.
• “IMS” is still the dominant DBMS. The relational DB2 is rapidly
gaining ground.
• Process data efficiently.
• It uses a structure familiar to program.
• Provides predictable performance since all paths are known.
• However not as flexible or as easy to understand as relational
system.
Hierarchical Data Model
Hierarchy
1. Networks that are forests(Collection Trees)
2. All links are from Parent to Child.
Æ ONE-TO-MANY relation.
3. In the previous Data Models Relational & Networks
relationships could be followed easily by operation of the
model, Joins and Link following.
ÆCan not follow links from child to parent.
4. Networks can be converted to hierarchies by Splitting.
5. Hierarchies are easy to store.
- Preserve hierarchy through pointers
- Using Preorder Traversal to get a flat representation of the tree.
SIMPLY EXAMPLE
• Lets assume the following relationships
– Faculty-Class ONE-MANY
– Class-Student ONE-MANY (Instead of n-n)
Simplify Example
• Instate of “Database Record”

• Possible Storage schema:


- Preorder Traversal to get flat representation of the above
instance.
Operations in the Hierarchical Model
• Top Down queries are easy to ask.
“Find all courses taught by Peter in CS”

• Bottom up queries not that easy.


“Find the class in room 63”

• Navigation between different occurrence of the


record difficult.
“Find all courses enrolled by ‘Dave’ “
Problems
1. Repeated data.
2. Potential inconsistencies.
3. Navigation between different occurrences of the
same record difficult.
4. Bottom Up queries inefficient.

Solution
1. Different structure for our tree.
2. Virtual record types.
Example
• Using the “Simplify Example” if the query type:
“Find information about student Y”
• Is more frequent than:
“Find information about all classes taught by Prof. X”
• Then change structure:
Most common way “Virtual Records”

Two directional navigation is possible.


(For one-many Rel.)
Representing many-many
Relationships
• The “Virtual Record” feature provides us with great
flexibility.
Alternative Designs
• Combined record types
- Fields of records can hold pointers(Virtual Fields).

- We are able to record course grade.


(as in the original design)

Query:
“Find all the grades issued in CS101”
• If too inefficient several other schemes can be used,
i.e.

Query:
“Find all the grades issued in CS101”
Object Oriented Model
• Features:
1. Object Identity:
Æ The elements with which they deal are
objects(entities) with unique addresses.
2. Complex Objects:
Æ Higher level objects composed by lower level
objects using record formation and set
formation.(This is a basic set of constructors)
3. Type Hierarchy:
Æ Types can have subtypes with special properties.
The notion of Class-Subclass.
Object Types:
1. Elementary types: integer, real, char, string, ...

2. If T is an object type then: SETOF(T) is an object


type.
- An object of type SETOF(T) is a collection of objects
of type T.

3. If T1, T2, …, Tk are objects types, then


RECORDOF(T1, T2, …, Tk) is an object type.

Thus,
Records of SETS, sets of RECORDS, etc are possible.
Example:
• A relation is an object type:
- Set of records constraining primitive values
- An actual table is an instance of the object type relation.
Faculty

Department
Course

Student
• Easy to get from DEPARTMENT to COURSES but
not vice versa.
– Can be achieved by defining new object types.
• Declare:
TYPE HIERARCHY
• Subtypes
– Structural: more attributes in the subtype.
Example:

– Behavioral: some operations can be applied only to the subtype.


Example:
– The method “rank” or “getDegree” can be only applied to the
subtype FACULTY.
OBJECT DDL

• Object Behavior:
– Methods
– Abstract Data Type Operations
• Very Limited Extensions of the Underlying host
Language (C++, Objective-C, Smalltalk)
– Add Data Persistence.
• Easy Direct Manipulation: Browsing.
• Need for a Higher-Level Language e.g. like SQL
(Relation Algebra).

You might also like