Basic Methodology Common to Both Hierarchical and Network Models

In both Hierarchical and Network models, relationships must be predefined-and therefore fully anticipated before implementing the database. These relationships are represented by means of separate data structures, such as indexes or linked lists. By contrast, in the Relational model, as we will see, relationships are established through data values.

Interestingly, transaction processing systems actually have two specific advantages over systems that rely on storing relationships within their data. The first advantage relates to performance efficiency. When relationships are predefined, data structures can be selected and fine-tuned according to an anticipated workload, thereby optimizing performance. The second advantage relates to control. By control we mean that different users (or applications) can be assigned different, limited tasks. For example, an order-entry program need not access the accounts-payable data. A particular user (or program) is therefore given a restricted view of the data, a feature leading in this one respect to a greater central control.

Hierarchical Database Model

As the name suggests, the Hierarchical database employs a hierarchical structure. The effects of such a structure include:

• All data relationships are assimilated into hierarchies;
  
• Files are arranged in tiers, or layers, of relationships;
  
• Relationships are analogous to the parent-child relationship, though, as we will see, it is significant that in the Hierarchical model, while the parent may have more than one child, the child may have only one parent;
  
• Data access may occur only through predefined relationships, a feature rendering the Hierarchical database model relatively rigid. Just as you cannot create a subfolder without having a main, or parent, folder in Windows Explorer, so you cannot have information about a child in a Hierarchical database without having the corresponding information about the parent.
  
• Repetition of data is required within the database, an inevitable redundancy making the Hierarchical database model very inefficient.

The most common example of the Hierarchical database model is Data Language I (DL/I), implemented on the IMS (Information Management System), and developed by IBM.

Network Database Model

This model is based upon the networking of data relationships and was developed to overcome the inefficiency of the Hierarchical database model. In a Network data model, multiple computers are connected, enabling them to share information and to communicate. Although there have been several kinds of Network models, the major one is the CODASYL DBTG model, named after the committee that developed it. It was the DBTG model that introduced the terms Data Definition Language (DDL) and Data Manipulation Language (DML). The Hierarchical model did not include a DDL, so the CODASYL model was an immediate improvement over the Hierarchical model and over earlier database systems that had only data manipulation capabilities.

Program and Data View Relationship

The Network database model provides for two alternative views of the database:

• Schema-complete logical view of the database (the entire database)
  
• Subschema-a subordinate view of the database, the limited perspective an application program sees; a subset of the database.

Users interact with the database exclusively by means of an application program (no independent interactive query language exists). Moreover, applications view the database through a subschema, as shown below:

Various programs might share subschemas, or each may have its own.

The fundamental building blocks for such a database include:

• Data items-Data items make up a field equivalent to a column in a table.
• Record-A record is a collection of data items.
• Set-A set is a One-to-Many relationship between records. Sets have owners and members. The owner of a set is the parent and the members are the children.

In the Network model, children are allowed to have multiple parents, a feature providing for improved relationships and resulting in a reduction in data redundancy.