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.
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
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).
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:
We will also see an overview of two other database models:
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 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:
The main disadvantages of the hierarchical database model are:
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:
Even though the network database model was significantly better than the hierarchical database model, it also had many drawbacks. Some of them are:
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 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:
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:
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.
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:
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:
The following are some of the disadvantages of object-oriented database model:
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.
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:
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 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
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.
IBM Mainframe Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM-CICS Interview Questions|
|COBOL Interview Questions||Linux Interview Questions|
|IBM-JCL Interview Questions||IBM Mainframe Interview Questions|
|IBM AIX Interview Questions||IBM WAS Administration Interview Questions|
|IBM Lotus Domino Interview Questions||IBM Integration Bus Interview Questions|
|Mainframe DB2 Interview Questions||Unix Production Support Interview Questions|
Ibm Mainframe Tutorial
Introduction To Software Development
Introduction To Ibm Mainframes
Tso And Ispf
Jes2, ]es3 And Sms
Introduction To Job Control Language (jcl)
The Job Statement
The Exec Statement
The Job And Exec Statements
The Dd Statement
Procedures And Symbolic Parameters
Generation Data Groups (gdg), Compile/link-edit And Run Jcls
Access Method Services (ams)
Additional Vsam Commands
Introduction To Rexx
Overview Of Rexx
Introduction To Cics
Exception Handling In Cics
Developing A Cics Application
Cics Programming Techniques
Basic Mapping Support (bms)
Transient Data Control
Temporary Storage Control
Interval And Task Control
Cics Application Design
Recovery And Restart
System Security And Intersystem Communication
Cics Debugging Facilities And Techniques
Bms Map Definition Macros And Copylib Members
Cics Response And Abend Codes
Data, Information And Information Processing
Introduction To Database Management Systems
Introduction To Relational Database Management Systems
Database Architecture And Data Modeling
Overview Of Db2
Structured Query Language (sql)
Data Security And Access
Db2 Application Development
Qmf And Db2i
Db2 Performance Monitoring, Utilities And Recovery/restart
Overview Of Information Management System (ims)
Introduction To Vs Cobol Ii
Overview Of Application Development In Vs Cobol Ii
Overview Of The Cobol Program
Sorting And Merging Files
Coding Cobol Programs That Run Under Cics. Ims, Db2 And Ispf
Compiling The Program
Link-editing The Program
Executing The Program
Improving Program Performance
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.