Hierarchical DBMS

The hierarchical DBMS is based on the logic that we tend to view things as hierarchies. Consider how you have your files stored on your hard disk (I'm assuming):

Notice that a directory may have may subdirectories, but a subdirectory can only belong to one parent directory. This is a 1:M (one to many) relationship, and is one of the most (perhaps the most) common type of relationship. As we will see later, there are other types of relationships: 1:1 (One-to-one: e.g., you and your Social Security Number: You can have only one social security number, and a social security can only be associated with one person), and M:M (Many-to-many; A class can have many students, and each student may take many classes).

Now, let's consider your family tree, but viewed ONLY with respect to your grandmother and her offspring (Let's assume that it is your father).

!!! Wait a Minute !!!
??? What have you got against my Grandfather ???
??? Or my Mother ???
??? Do you want to meet, one-on-one ???

No, thanks. I used this example, because we will discuss some problems with the hierarchical approach later using the same example. Let's take a look at one final example, which is much more appropriate using the hierarchical model. 

In this case, we know that a University has many Colleges. Each College has many Departments. Each Department offers many Courses.

This is a good example of a hierarchical database. Each parent (e.g., University) can have many children (e.g., College of Engineering, College of Business, College of Arts and Sciences), each of whom can can have many other children (e.g., the College of Business has the Finance, Accounting, Information Systems, and Management Departments). The relationships can continue until there is no where else to go (i.e., there comes a time when there are no children).

There are some basic rules here:
 

1. A parent can have many children (e.g., A University has many Colleges; A College has many Departments)

2. A child can have only ONE parent (e.g., The Accounting department can ONLY belong to the College of Business, NOT to the College of Arts and Sciences)

Because this is a 'Tree-like' structure, we also tend to use some 'tree-like' terminology:
 

1. The 'Base' of the tree is the root. In this case it is the University.

2. A tree can have many branches. For example, the College of Business has a Finance Branch, an Accounting Branch, an Information Systems Branch, and a Management Branch.

3. Each Branch may have a Sub-branch. For example, the Information Systems Branch has as it's sub-branch the courses Database Management, Systems Analysis and Design, Business Programming, Telecommunications, and Information Resource Planning.

4. A Root, Branch, or Sub-branch may have many descendants. The university has each of the colleges and their descendants as a a descendant. The College of Business has each of its Departments as a descendant. The Information Systems Department has each of the Courses it offers as a Descendant.

5. Each child (obviously, aside from the root), has ancestors. The Courses offer by the Information Systems Department have as their ancestors the Department of Information Systems, The College of Business and the University; The Department of Information Systems has as its ancestors the College of Business and the University; The College of Business has as its ancestor the University.

6. A Leaf is a child which has no children.

7. A tree is bushy if it has a lot of leaves.

In the above illustration, we have also included such terminology as Level X children and Level Y segment. The terms are actually self explanatory, but if it doesn't make sense to you, well that is not the intent of this particular course.

The Hierarchical model of DBMS has many advantages, but also some disadvantages (life is a trade-off):