Hierarchical database model

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Spiritia (talk | contribs) at 19:45, 14 May 2009 (+bg:Йерархични бази данни). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Hierarchical model redirects here. For the statistics usage, see hierarchical linear modeling.

A hierarchical data model is a data model in which the data is organized into a tree-like structure. The structure allows repeating information using parent/child relationships: each parent can have many children but each child only has one parent. All attributes of a specific record are listed under an entity type.

Example of a Hierarchical Model.

In a database, an entity type is the equivalent of a table; each individual record is represented as a row and an attribute as a column. Entity types are related to each other using 1: N mapping, also known as one-to-many relationships.

A hierarchical database expects the hierarchical tables to be defined at design-time and does not expect them to be changed during run-time. The most recognized and used hierarchical database is IMS developed by IBM.

History

Prior to the development of the first database management system (DBMS), access to data was provided by application programs that accessed flat files. Data integrity problems and the inability of such file processing systems to represent logical data relationships lead to the first data model: the hierarchical data model. This model, which was implemented primarily by IBM's Information Management System (IMS) only allows one-to-one or one-to-many relationships between entities. Any entity at the many end of the relationship can be related only to one entity at the one end.[1]

A relational database implementation of this type of data model was first discussed in publication form in 1992[2] (see also nested set model).

Example

An example of a hierarchical data model would be if an organization had records of employees in a table (entity type) called "Employees". In the table there would be attributes/columns such as First Name, Last Name, Job Name and Wage. The company also has data about the employee’s children in a separate table called "Children" with attributes such as First Name, Last Name, and date of birth. The Employee table represents a parent segment and the Children table represents a Child segment. These two segments form a hierarchy where an employee may have many children, but each child may only have one parent.

Consider the following structure:

EmpNo Designation ReportsTo
10 Director
20 Senior Manager 10
30 Typist 20
40 Programmer 20

In this, the "child" is the same type as the "parent". The hierarchy stating EmpNo 10 is boss of 20, and 30 and 40 each report to 20 is represented by the "ReportsTo" column. In Relational database terms, the ReportsTo column is a foreign key referencing the EmpNo column. If the "child" data type were different, it would be in a different table, but there would still be a foreign key referencing the EmpNo column of the employees table.

This simple model is commonly known as the adjacency list model, and was introduced by Dr. Edgar F. Codd after initial criticisms surfaced that the relational model could not model hierarchical data.

References

  1. ^ Jan L. Harrington (2000). Object-oriented Database Design Clearly Explained. p.4
  2. ^ Michael J. Kamfonas/Recursive Hierarchies: The Relational Taboo!—The Relation Journal, October/November 1992

External links