The hierarchical and network models were part of the second generation of data models. The hierarchical model was one of the first widely used data models in the 1970s.
The logical structure of the hierarchical model looks like an upside-down tree, where the model contains levels or segments. A segment in the hierarchical model is similar to a file system’s record type. In a hierarchy, the higher layer is the "parent" of the "child," or the segment below it. The hierarchical model is basically a set of one-to-many relationships, where each parent segment can have many children, but each child segment can only have one parent.
The network model was also created in the 1970s to help deal with some of the issues of complex data relationships that could not be represented in the hierarchical model. The goals of the network model was to help improve performance in the database and create a database standard. Like the hierarchical model, the network model also used the one-to-many relationship, but a record in the network model was able to have more than one parent. Even though network data models are no longer used today, a lot of the key concepts that came from the network model are still used. These include the schema, subschema, data manipulation language, and data definition language.
The schema is considered to be the conceptual organization of the database. This includes the complete data model of the relationship. This is the view seen by a database administrator, who is able to see the complete database. The subschema, on the other hand, is the part of the database that the applications can see, rather than the entire database. Data manipulation language (DML) represents the commands that are used to work with the data. In current databases, this includes the SELECT, UPDATE, INSERT and DELETE statements. Data definition language (DDL) allows database administrators to create and remove the various schema components in the database, and include CREATE, ALTER and DROP statements.
As information needs grew, the network model became a bit too cumbersome, without having ad hoc query capabilities. This required programmers to create the code to run even the simplest reports. It was a lot more complex than the SQL commands that you've been using to query the data in our relational database. In addition, if there was any change in the database structure, this would create problems across all of the applications that accessed the data, as they heavily depended on the data model structure to match.
Source: Authored by Vincent Tran
