While storage of data determines much about how best it is used, there are other measures of the usefulness of data. One of these measures is how the data is structured. The structure of the data refers to the view the programmer or user has of the data, as data is inserted, retrieved or deleted from the system. Of course, the structure of the data is ultimately embodied at the basic physical level. This means that, at a lower level, data structures, however they a/e presented, consist of records, blocks, addresses etc. To illustrate the usefulness of a data structure, consider the simple relationship between a book and a distributor as shown in the following figure.

A relationship

A relationship

A relationship

There are several ways to depict this relationship. One way is for the relationship to exist from the book to the distributor (l:n relationship). In this case, given a book the distributors of that particular book can be determined. Another relationship is from the distributor's point of view (n:1 relationship). What books does the distributor supply? These two relationships are shown in the following figure.

1:n and n:l Relationships

1:n and n:l Relationships

Still a third view combines both the book and the distributor views, so that the relationship may be viewed from either perspectives (n:n relationship).

n:n Relationship

n:n Relationship

Thus the relationships between the data elements can be expressed in many different ways. A DBMS can take any one of the several approaches to manage the data. Each approach constitutes a database model. A database model is an organizing principle that specifies particular mechanisms for data storage and retrieval. The model explains, in terms of services available to an interfacing application, how to access a data element when other related data elements are known.

Regardless of the underlying database model, a specific DBMS manages information from some real-world application. From the application viewpoint, the different database models share a common goal—to facilitate the storage and retrieval of information. The primary difference between the different database models lie in the methods of expressing relationships and constraints among the data elements. In this chapter we will discuss in some detail four database models:

  • Hierarchical
  • Network
  • Relational
  • Object-Oriented

We will also see an overview of two other database models:

  • Object-relational
  • Deductive

The systematic development of databases started with the hierarchical and network models, which were popular in the 1960s and 1970s. The Relational model is the current favorite while the object-oriented and deductive models are slowly emerging and point the way to the future.

When relational model came into the scene its superiority over the existing models (hierarchical and network) was very striking. After the infancy and a series of refinements and enhancements, the relational model matured to become so successful that it rendered its predecessors obsolete. The newer models (object-oriented and deductive) do offer some advantages over the relational model, but their evolution has not been as dramatic as that of the relational model. Also from the industrial trends it seems unlikely that these newer models will quickly replace the relational model, especially because extended relational products (for example object-relational models) continue to appear.

Hierarchical Model

Hierarchical Database model is one of the oldest database models, dating from late 1950s. One of the first hierarchical databases—Information Management System (IMS)—was developed jointly by North American Rockwell Company and IBM. IMS became the world's leading mainframe hierarchical database system in the 1970s and early 1980s. The hierarchical model assumes that a tree structure is the most frequently occurring relationship. This assumption is recognized today as misleading. In fact many of the limitations and shortcomings of the hierarchical model result from this overly restrictive view of relationships. The hierarchical model organizes data elements as tabular rows, one for each instance of an entity. Consider a company's organizational structure. At the top we have a General Manager (GM). Under him we have several Deputy General Managers (DGMs). Each DGM looks after a couple of departments and each department will have a manager and many employees. When represented in hierarchical model, there will be separate rows for representing the GM, each DGM, each department, each Manager and each Employee. The row position implies a relationship to other rows. A given employee belongs to the department that is closest above it in the list and the department belongs to the manager that is immediately above it in the list and so on.

The hierarchical model represents relationships with the notion of 'logical adjacency' or more accurately with 'logical proximity', in a linearized tree. You can locate a set of employees working for say, Manager X by first locating Manager X and then including every employee in the list after X and before the next occurrence of a manager or the end of the list. Because linearized tree is an abstraction, the term logical proximity is more appropriate for hierarchical model.


The hierarchical model had many advantages over the file systems it replaced. It can be said that the advantages and features of the hierarchical database systems was the reason for the development of the database models that followed it. The main advantages of this database model are:

  • Simplicity - Since the database is based on the hierarchical structure, the relationship between the various layers is logically (conceptually) simple. Thus the design of a hierarchical database is simple.
  • Data Security - Hierarchical model was the first database model that offered the data security that is provided and enforced by the DBMS.
  • Data Integrity - Sine* the hierarchical model is based on the parent/child relationship, there is always a link between the parent segment and the child segments under it. The child segments are always automatically referenced to its parent, this model promotes data integrity.
  • Efficiency - The hierarchical database model is a very efficient one when the database contains a large number of 1:n relationships (one-to-many relationships) and when the users require large number of transactions, using data whose relationships are fixed.


The main disadvantages of the hierarchical database model are:

  • Implementation Complexity - Although the hierarchical database model is conceptually simple and easy to design it is quite complex to implement. The database designers should have very good knowledge of the physical data storage characteristics.
  • Database Management Problems - If you make any changes in the database structure of a hierarchical database, then you need to make the necessary changes in all the application programs that access the database. Thus maintaining the database and the applications can become very difficult.
  • Lack of structural independence - Structural independence exists when the changes to the database structure does not affect the DBMS's ability to access data. Hierarchical database systems use physical storage paths to navigate to the different data segments. So the application programmer should have a good knowledge of the relevant access paths to access the data. So if the physical structure is changed the applications will also have to be modified. Thus in a hierarchical database the benefits of data independence is limited by structural dependence.
  • Programming Complexity - Due to the structural dependence and the navigational structure, the application programmers and the end users must know precisely how the data is distributed physically in the database in order to access data. This requires knowledge of complex pointer systems, which is often beyond the grasp of ordinary users (users who have little or no programming knowledge).
  • Implementation Limitation - Many of the common relationships do not conform to the l:n format required by the hierarchical model. The many-to-many (n:n) relationships, which are more common in real life are very difficult to implement in a hierarchical model.

Network Model

The Network Model replaces the hierarchical tree with a graph thus allowing more general connections among the nodes. The main difference of the network model from the hierarchical model is its ability to handle many-to-many (n:n) relationships. Or in other words, it allows a record to have more than one parent. Suppose an employee works for two departments. The strict hierarchical arrangement is not possible here and the tree becomes a more generalized graph—a network. Logical proximity fails because you cannot place a data item simultaneously in two locations in the list. Although it is possible to handle such situations in a hierarchical model, it becomes more complicated and difficult to comprehend. The network model was evolved to specifically handle non-hierarchical relationships. In network database terminology, a relationship is a set. Each set is made of at least two types of records: an owner record (equivalent to the parent in the hierarchical model) and a member record (similar to the child record in the hierarchical model). The difference between the hierarchical model and the network model is that the network model allows a record to appear as a member in more than a set thus facilitating many-to-many relationships.


The network model retains almost all the advantages of the hierarchical model while eliminating some of its shortcomings. The main advantages of the network model are:

  • Conceptual simplicity - Just like the hierarchical model, the network model is also conceptually simple and easy to design.
  • Capability to handle more relationship types - The network model can handle the one-to-many (l:n) and many-to-many (n:n) relationships, which is a real help in modeling the real life situations.
  • Ease of data access - The data access is easier than and flexible than in the hierarchical model. An application can access an owner record and all the member records within a set and if one member in the set has two owners (like the employee working for two departments), then one can move from one owner to another.
  • Data integrity - The network model does not allow a member to exist without an owner. Thus a user must first define the owner record and then the member record. This ensures the data integrity.
  • Data independence - The network model is better than the hierarchical model in isolating (at least partially if not fully) the programs from the complex physical storage details. This, to a certain extent, ensures that the changes in data characteristics do not require changes to the application programs.
  • Database Standards - One of the major drawbacks of the hierarchical model was the availability of universal standards for database design and modeling. The network model is based on the standards formulated by the DBTG (Database Task Group of CODASYL Committee) and augmented by ANSI/SPARC (American National Standards Institute / Standards Planning and Requirements Committee) in the 1970s. All the network database management systems conformed to these standards. These standards included a data definition language (DDL) and a data manipulation language (DML), thus greatly enhancing database administration and portability.


Even though the network database model was significantly better than the hierarchical database model, it also had many drawbacks. Some of them are:

  • System complexity - Like the hierarchical model, the network model also provides a navigational access to the data in which the data are accessed one record at a time. This navigational data access mechanism makes the system implementation very complex and consequently the database administrators, database designers, programmers and even the end users should be familiar with the internal data structures in order to access the data. In other words, the network database model cannot be used to create a user-friendly database management system.
  • Absence of structural independence - Since the data access method in the network database model is a navigational system, making structural changes to the database is very difficult in most cases and impossible in some cases. If changes are made to the database structure then all the application programs need to be modified before they can access data. Thus, even though the network database model succeeds in achieving data independence, it still fails to achieve structural independence.

Because of the disadvantages mentioned and the implementation and administration complexities, both the hierarchical and network database models were replaced by the relational database model in the 1980s. The evolution of the relational database model is considered as one of the greatest events—a major breakthrough—in the history of database management.

Relational Model

Relational model stores data in the form of a table. Relational databases are powerful because they require few assumptions about how data is related or how it will be extracted from the database. As a result, the same database can be viewed in different ways. Another feature of relational systems is that a single database can be spread across several tables. This differs from flat-file databases, in which each database is self-contained in a single table.

The relational model uses tables to organize data elements. Each table corresponds to an application entity, and each row represents an instance of that entity. For example, the book entity in an application corresponds to a book table in the database. Each row in the table represents a different book. Relationships link rows from two tables by embedding row identifiers (keys) from one table as attribute values in the other table. For example, the Distributor Name, which is the row identifier in the Distributor table, is embedded as an attribute in the book table and for each book there will be a distributor name thus associating the book with a distributor. Structured Query Language (SQL) serves as a uniform interface for users providing a collection of standard expressions for storing and retrieving data.

Although the relational model is currently the most popular database model, two other models—the object-oriented and deductive database models—which claim to be more flexible in data representation, at least for specialized applications are emerging into the commercial arena. Each offers an alternative to the table for maintaining relationships between elements.


The major advantages of the relational model are:

  • Structural independence - The relational model does not depend on the navigational data access system thus freeing the database designers, programmers and end users from learning the details of data storage. Changes in the database structure do not affect the data access. When it is possible to make change to the database structure without affecting the DBMS's capability to access data, we can say that structural independence have been achieved. So relational database model has structural independence.
  • Conceptual simplicity - We have seen that both the hierarchical and the network database model were conceptually simple. But the relational database model is even simpler at the conceptual level. Since the relational data model frees the designer from the physical data storage details, "the designers can concentrate on the logical view of the database.
  • Design, implementation, maintenance and usage ease - The relational database model achieves both data independence and structural independence making the database design, maintenance, administration and usage much easier than the other models.
  • Ad hoc query capability - The presence of very powerful, flexible and easy-to-use query capability is one of the main reasons for the immense popularity of the relational database model. The query language of the relational database models—structured query language or SQL—makes ad hoc queries a reality. SQL is a fourth generation language (4GL). A 4GL allows the user to specify what must be done without specifying how it must be done. So using SQL, the users can specify what information they want and leave the details of how to get the information to the database. The relational database will perform the task of translating the user queries (specified as SQL statements) into the technical code required to retrieve the requested information.


The relational model's disadvantages are very minor compared to the advantages and their capabilities far outweigh the shortcomings. Also the drawbacks of the relational database systems could be avoided if proper corrective measures are taken. The drawbacks are not because of the shortcomings in the database model, but in the way it is being implemented. Some of the disadvantages are:

  • Hardware overheads - Relational database systems hides the implementation complexities and the physical data storage details from the users. For doing this, i.e. for making things easier for the users, the relational database systems need more powerful hardware—computers and data storage devices. So the RDBMS needs powerful machines to run smoothly. But as the processing power of modern computers is increasing at an exponential rate and in today's scenario, the need for more processing power is no longer a very big issue.
  • Ease of design can lead to bad design - The relational database is an easy-to-design and use system. The users need not know the complex details of physical data storage. They need not know how the data is actually stored to access it. This ease of design and use can lead to the development and implementation of very poorly designed database management systems. Since the database is efficient, these design inefficiencies will not come to light when the database is designed and when there is only a small amount of data. As the database grows, the poorly designed databases will slow the system down and will result in performance degradation and data corruption.
  • 'Information island' phenomenon - As we have said before, the relational database systems are easy to implement and use. This will create a situation where too many people or departments will create their on databases and applications. These information islands will prevent the information integration that is essential for the smooth and efficient functioning of the organization. These individual databases will also create problems like data inconsistency. data duplication, data redundancy and so on.

But as we have said all these issues are minor when compared to the advantages and all these issues could be avoided if the organization has a properly designed database and has enforced good database standards.

Object-Oriented Model

Relational database technology has failed to handle the needs of complex information systems. The problem with relational database systems is that they require the application developer to force an information model into tables where relationships between entities are defined by values. Relational database design is really a process of trying to figure out how to represent real-world objects within the confines of tables in such a way that good performance results and preserving data integrity is possible. Object database design is quite different. For the most part, object database design is a fundamental part of the overall application design process. The object classes used by the programming language are the classes used by the ODBMS. Because their models are consistent, there is no need to transform the program's object model to something unique for the database manager.

A data model is a collection of mathematically well-defined concepts that help one to consider and express the static and dynamic properties of data intensive applications. A data model consists of:

  • Static properties such as objects, attributes and relationships
  • Integrity rules over objects and operations
  • Dynamic properties such as operations or rules defining new database states based on applied state changes.

Object-oriented databases have the ability to model all three of these components directly within the database supporting a complete problem/solution modeling capability. Prior to object-oriented databases, databases were capable of directly supporting points 1 and 2 above and relied on applications for defining the dynamic properties of the model. The disadvantage of delegating the dynamic properties to applications is that these dynamic properties could not be applied uniformly in all database usage scenarios since they were defined outside the database in autonomous applications. Object-oriented databases provide a unifying paradigm that allows one to integrate all three aspects of data modeling and to apply them uniformly to all users of the database.

Object-Oriented model represents an entity as a class. A class represents both object attributes as well as the behavior of the entity. For example a book class will have not only the book attributes such as ISBN, Title, Author, Publisher, Year of Publishing, Distributor, Price, etc. but also procedures that imitate actions expected of a book such as Update Price (updating the price). Instances of the class-object correspond to individual books. Within an object the class attributes takes specific values, which distinguish one book (object) from another. However the behavior patterns of the class is shared by all the objects belonging to the class.

The object-oriented model does not restrict attribute values to the small set of native data types usually associated with databases and programming languages, such as integer, numeric, character, etc. Instead the values can be other objects. For example, one of the attributes of a book can be distributor and the value of that attribute can be a distributor object corresponding to the distributor who is distributing the book. The object-oriented model maintains relationships through logical containment'. Consider the book-distributor example. You will find the distributor of a particular book in the book as one of its attributes. Since distributor is an object in its own right, you can recursively examine its attributes. The distributor object can have a title attribute, which can be a book object (assuming for the moment, that the distributor has only one book). But the book is the same book in which you originally found the distributor. So book 'B' contains distributor 'BD' which contains book 'B*. This is logical containment and this is how the object- oriented model maintains relationships.

Object-oriented databases manage objects (abstract data types). An object-oriented DBMS, or OODBMS, is suited for multimedia applications as well as data with complex relationships that are difficult to model and process in a relational DBMS. Because any type of data can be stored, an OODBMS allows for fully, integrated databases that hold data, text, pictures, voice and video.


The object-oriented database model has many advantages over the other database models:

  • Capability to handle Iarge number of different data types - Traditional database models— hierarchical, network and relational database—are limited in their capability to store the different types of data. For example one cannot store pictures, voices and video in these databases. But the object-oriented database can store any type of data including text, numbers, pictures, voice and video.
  • Marriage of object-oriented programming and database technology - Perhaps the most significant characteristic of object-oriented database technology is that it combines object-oriented programming with database technology to provide an integrated application development system. There are many advantages to including the definition of operations with the definition of data. First, the defined operations apply ubiquitously and are not dependent on the particular database application running at the moment. Second, the data types can be extended to support complex data such as multimedia by defining new object classes that have operations to support the new kinds of information.
  • Object-oriented features improve productivity - Inheritance allows one to develop solutions to complex problems incrementally by defining new objects in terms of previously defined objects. Polymorphism and dynamic binding allow one to define operations for one object and then to share the specification of the operation with other objects. These objects can further extend this operation to provide behaviors that are unique to those objects. Dynamic binding determines at runtime, which of these operations is actually executed, depending on the class of the object requested to perform the operation. Polymorphism and dynamic binding are powerful object-oriented features that allow one to compose objects to provide solutions without having to write code that is specific to each object. All of these capabilities come together synergistically to provide significant productivity advantages to database application developers.
  • Data access Object-oriented databases represent relationships explicitly, supporting both navigational and associative access to information. As the complexity of interrelationships between information within the database increases, the greater the advantages of representing relationships explicitly. Another benefit of using explicit relationships is the improvement in data access performance over relational value-based relationships.


The following are some of the disadvantages of object-oriented database model:

  • Difficult to maintain - In the real world, the data model is not static and will change as organizational information needs change and as missing information is identified. Consequently, the definition of objects must be changed periodically and existing databases migrated to conform to the new object definitions. Object-oriented databases are semantically rich introducing a number of challenges when changing object definitions and migrating databases. Object-oriented databases have a greater challenge handling schema migration because it's not sufficient to simply migrate the data representation to conform to the changes in class specifications. One must also update the behavioral code associated with each object.
  • Not suited for all applications - Object-oriented database systems are not suited for all applications. If it is used in situations where it is not required, then it will result in performance degradation and high processing requirements. OODBMS' have established themselves in niches such as e-commerce, engineering product data management, and special purpose databases in areas such as securities and medicine. The strength of the object model is in applications where there is an underlying need to manage complex relationships among data objects.

Today, it's unlikely that OODBMS' are a threat to the stronghold that relational database vendors have in the market place. Clearly, there is a partitioning of the market into databases that are best suited for handling high volume low, complexity data and databases that are suited for high complexity, reasonable volume, with OODBMS filling the need for the latter.

Object-Relational Model

Relational database management is one of the most successful technologies in computer science. A lot of money is spent each year on relational database systems and applications, and much of the world's business data is stored in relational form. Until recently, most of the individual data items stored in relational databases were relatively small and simple. For storing these simple data items, database systems supported a set of predefined data types such as integers, real numbers, and character strings. The operations defined over these data types, such as arithmetic and comparison, were also simple and predefined.

Increasingly, modern database applications need to store and manipulate objects that are neither small nor simple, and to perform operations on these objects that are not predefined. For example, the planning department of a city might need to store maps, photographs, written documents with diagrams, and audio and video recordings. A planner might need to find all the parcels of property that intersect a proposed highway route or to find the minutes of all meetings in which construction of new schools was discussed. Multimedia applications such as this one are among the fastest-growing segments of the database industry, and because of the very large amounts of data that they require, we can expect the requirements of these applications to become increasingly important.

Clearly, the traditional data types and search capabilities of SQL are not sufficient for the new generation of multimedia database applications. But it is also clear that the requirements of these applications are so diverse that they cannot be satisfied by any set of predefined language extensions. What we need is not a collection of new data types and functions, but a facility that lets users define new data types and functions of their own. Another requirement of modern applications is databases that not only st6re data but also record and enforce business rules that apply to the data. Associating rules with data makes the data more "active," enabling the database system to perform automatic validity checks and to automate many business procedures. Making data active increases its value because it enables applications to share not only the data itself but also the behavior of the data. Rules are stored^ in the database rather than being encoded in each application, so redundancy is eliminated and the integrity of the data is protected.

Allowing users to define their own data types and functions, and allowing users to define rules that govern the behavior of active data, are both ways of increasing the value of stored data by increasing its semantic content. The trend toward increasing the semantic content of stored data is the most important trend in database management today. In order to accommodate and facilitate this trend, relational database systems are being enhanced in two ways:

  • By adding an "object infrastructure" to the database system itself, in the form of support for user-defined data types, functions, and rules
  • By building "relational extenders" on top of this infrastructure that support specialized applications such as image retrieval, advanced text searching, and geographic applications.

A system that includes both object infrastructure and a set of relational extenders that exploit it is called an "object-relational" database system. Object-relational systems combine the advantages of modern object-oriented programming languages with relational database features such as multiple views of data and a high-level, non-procedural query language. An object-relational system is a good long-term investment, because its extenders provide the capabilities you need to manage today's specialized objects, and its object infrastructure gives you the ability to define new types, functions, and rules to deal with the evolving needs of your business. Some of the object-relational systems available in the market are IBM's DB2 Universal Servers, Oracle Corporations Oracle8, Microsoft Corporations SQL Server 7 and so on.

Deductive/Inference Model

Deductive model also known as inferential model, stores as little data as possible but compensates by maintaining rules that allow new data combinations to be created when needed. Suppose the database stores the facts of the form DistBook(D, B), meaning that distributor 'D' is distributing the book 'B For example, DistBook(MindMart, Countdown 2000) can appear in the database meaning that the book 'Countdown 2000' is being distributed by the distributor with name 'MindMart'. A distributor can distribute more than one book and one book can be distributed by many distributors. So you can form another relationship where two books distributed by the same distributor and which can be represented as SameDist(X, Y), meaning books X and Y are distributed by the same distributor. Although the database explicitly stores the DistBook(D, B) facts, it does not store the SameDist(X, Y) facts. Instead it stores a rule stating that SameDist(X.Y) fact, say SameDist(Countdown 2000, SQL Handbook), can be deduced from the existing facts say DistBook(MindMart, Countdown 2000) and DistBook(MindMart, SQL Handbook). Such inference rules indirectly capture relationship groupings. The database thus stores certain elementary facts—axioms—from which other facts can be derived as and when needed using the rules.

Comparison Between the Various Database Models

The following table summarizes the characteristics of the five database models. The first column gives the name of the model, the second specifies how the data elements are physically organized in the database and the third column specifies how the relationships between the data elements are established.

Comparison between the Database Models

Comparison between the Database Models

Within the database an application object or relationship appears as a data element or grouping of data elements. For example, suppose we are describing a man and the attributes that we have included are name, age, height, weight, and eye color. This we have represented as (Ravi, 31, 180, 90, Blue) which means that the man's name is Ravi, he is 31 years old and his height is 180 centimeters and weight 90 Kilograms and the color of his eyes are blue. Suppose a year later Ravi fell ill and lost his weight. So the data structure changes to (Ravi, 32„ 180, 70, Blue). But the real Ravi is the same person as before and therefore the data structure has not changed its identity, but only its values. But the question is how many values can change before a new person emerges. If Ravi changes his name, becomes very lean and reduces weight, does plastic surgery, undergoes a sex transition! Will he (or shall we say she) become a new person? From the database standpoint the question is simpler—if all the attributes of the data structure change, has a new entity been created? The object-oriented, network and hierarchical models assume that the object survives the changes of all its attributes. These systems are record-based. A record of the real world item appears in the database and even though the record contents may change completely the record itself represents the application entity. As long as the record remains in the database, the object's identity has not changed.

In contrast the relational, object-relational and deductive models are value-based. They assume that the real world item has not identity independent of the attribute values. So if Ravi changes his attributes sufficiently to represent a woman, then he is a she! With this representation, the content of the database record, rather than its existence, determines the identity of the object represented.

The last column of the table is the Access Language. Each model uses a particular style of access language to manipulate the database contents. Some models employ a procedural language, precisely a sequence of operations to compute the desired results. Other use non-procedural languages, stating only the desired results and leaving the specific computation to the DBMS. The relational and deductive database models use non-procedural languages while the object-oriented, hierarchical and network models use procedural languages.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics