IMS Database

Before the development of DBMSs, data was stored in individual files, or as flat files. With this system,

each file was stored in a separate data set in sequential or indexed format. To retrieve data from the

file, an application had to open the file and read through it to the location of the desired data. If the

data was scattered through a large number of files, data access required a lot of opening and closing

of files, creating additional I/O and processing overhead. To reduce the number of files accessed by an

application, programmers often stored the same data in many files. This practice created redundant

data and the related problems of ensuring update consistency across multiple files. To ensure data

consistency, special cross-file update programs had to be scheduled following the original file update.

The concept of a database system resolved many data integrity and data duplication issues

encountered in a file system. A database stores the data only once in one place and makes it available

to all application programs and users. At the same time, databases provide security by limiting access

to data. The user's ability to read, write, update, insert, or delete data can be restricted. Data can also

be backed up and recovered more easily in a single database than in a collection of flat files.

Database structures offer multiple strategies for data retrieval. Application programs can retrieve data

sequentially or (with certain access methods) go directly to the desired data, reducing I/O and

speeding data retrieval. Finally, an update performed on part of the database is immediately available

to other applications. Because the data exists in only one place, data integrity is more easily ensured.

The IMS database management system as it exists today represents the evolution of the hierarchical

database over many years of development and improvement. IMS is in use at a large number of

business and government installations throughout the world. IMS is recognized for providing excellent

performance for a wide variety of applications and for performing well with databases of moderate to

very large volumes of data and transactions.

DL/I
Because they are implemented and accessed through use of the Data Language I (DL/I), IMS

databases are sometimes referred to as DL/I databases. DL/I is a command-level language, not a

database management system. DL/I is used in batch and online programs to access data stored in

databases. Application programs use DL/I calls to request data. DL/I then uses system access

methods, such as Virtual Storage Access Method (VSAM), to handle the physical transfer of data to

and from the database.

IMS databases are often referred to by the access method they are designed for, such as HDAM,

PHDAM, HISAM, HIDAM, and PHIDAM. IMS makes provisions for nine types of access methods, and
you can design a database for any one of them. We discuss each of them in greater detail in Chapter

2, "IMS Structures and Functions." The point to remember is that they are all IMS databases, even

though they are referred to by access type.

Control Blocks
When you create an IMS database, you must define the database structure and how the data can be

accessed and used by application programs. These specifications are defined within the parameters

provided in two control blocks, also called DL/I control blocks:

 database description (DBD)

 program specification block (PSB)

In general, the DBD describes the physical structure of the database, and the PSB describes the

database as it will be seen by a particular application program. The PSB tells the application which

parts of the database it can access and the functions it can perform on the data.

Information from the DBD and PSB is merged into a third control block, the application control block

(ACB). The ACB is required for online processing but is optional for batch processing.

Data Communications
The IMS Transaction Manager (IMS TM) is a separate set of licensed programs that provide access to

the database in an online, real-time environment. Without the TM component, you would be able to

process data in the IMS database in a batch mode only. With the IMS TM component, you can access

the data and can perform update, delete, and insert functions online. As Figure 1-1 shows, the IMS TM

component provides the online communication between the user and DL/I, which, in turn,

communicates with the application programs and the operating system to access and process data

stored in the database.

Application Programs
The data in a database is of no practical use to you if it sits in the database untouched. Its value

comes in its use by application programs in the performance of business or organizational functions.

With IMS databases, application programs use DL/I calls embedded in the host language to access the

database. IMS supports batch and online application programs. IMS supports programs written in

ADA, assembler, C, COBOL, PL/I, VS PASCAL, and REXX.

top
Hierarchical versus Relational Databases
There are several types of database management systems, categorized generally by how they logically

store and retrieve data. The two most common types in use today are relational and hierarchical. Each

type has its advantages and disadvantages, and in many organizations both types are used. Whether

you choose a relational or hierarchical database management system depends largely on how you

intend to use the data being stored.

Relational Database
In a relational database, data is stored in a table made up of rows and columns. A separate table is

created for logically related data, and a relational database may consist of hundreds or thousands of

tables.

Within a table, each row is a unique entity (or record) and each column is an attribute common to the

entities being stored. In the example database described in Table 1-1 on page 1-9, Course No. has

been selected as the key for each row. It was chosen because each course number is unique and will

be listed only once in the table. Because it is unique for each row, it is chosen as the key field for that

row. For each row, a series of columns describe the attributes of each course. The columns include

data on title, description, instructor, and department, some of which may not be unique to the course.

An instructor, for instance, might teach more than one course, and a department may have any

number of courses. It is important early in design of a database to determine what will be the unique,

or key, data element.

Hierarchical Databases
Now let's look at the same data stored in a hierarchical format. This time the data is arranged logically

in a top-down format. In a hierarchical database, data is grouped in records, which are subdivided into

a series of segments. In the example Department database on Figure 1-2 on page 1-8, a record

consists of the segments Dept, Course, and Enroll.

In a hierarchical database, the structure of the database is designed to reflect logical dependencies-

certain data is dependent on the existence of certain other data. Enrollment is dependent on the

existence of a course, and, in this case, a course is dependent on the existence of a department. In a

hierarchical database, the data relationships are defined. The rules for queries are highly structured. It

is these fixed relationships that give IMS extremely fast access to data when compared to a relational

database. Speed of access and query flexibility are factors to consider when selecting a DBMS.

Strengths and Weaknesses

Hierarchical and relational systems have their strengths and weaknesses. The relational structure

makes it relatively easy to code requests for data. For that reason, relational databases are frequently

used for data searches that may be run only once or a few times and then changed. But the query-like

nature of the data request often makes the relational database search through an entire table or

series of tables and perform logical comparisons before retrieving the data. This makes searches

slower and more processing-intensive. In addition, because the row and column structure must be

maintained throughout the database, an entry must be made under each column for every row in

every table, even if the entry is only a place holder-a null entry. This requirement places additional

storage and processing burdens on the relational system.

With the hierarchical structure, data requests or segment search arguments (SSAs) may be more

complex to construct. Once written, however, they can be very efficient, allowing direct retrieval of the

data requested. The result is an extremely fast database system that can handle huge volumes of data

transactions and large numbers of simultaneous users. Likewise, there is no need to enter place

holders where data is not being stored. If a segment occurrence isn't needed, it isn't inserted.

The choice of which type of DBMS to use often revolves around how the data will be used and how

quickly it should be processed. In large databases containing millions of rows or segments and high

rates of access by users, the difference becomes important. A very active database, for example, may

experience 50 million updates in a single day. For this reason, many organizations use relational and

hierarchical DBMSs to support their data management goals.

Sample Hierarchical Database

To illustrate how the hierarchical structure looks, we'll design two very simple databases to store

information for the courses and students in a college. One database will store information on each

department in the college, and the second will contain information on each college student.

In a hierarchical database, an attempt is made to group data in a one-to-many relationship. An

attempt is also made to design the database so that data that is logically dependent on other data is

stored in segments that are hierarchically dependent on the data. For that reason, we have designated

Dept as the key, or root, segment for our record, because the other data would not exist without the

existence of a department. We list each department only once. We provide data on each course in

each department. We have a segment type Course, with an occurrence of that type of segment for

each course in the department. Data on the course title, description, and instructor is stored as fields

within the Course segment. Finally, we have added another segment type, Enroll, which will include
the student IDs of the students enrolled in each course.
In Figure 1-2, we also created a second database called Student. This database contains information

on all the students enrolled in the college. This database duplicates some of the data stored in the

Enroll segment of the Department database. Later, we will construct a larger database that eliminates

the duplicated data. The design we choose for our database depends on a number of factors; in this

case, we will focus on which data we will need to access most frequently,

The two sample databases, Department and Student, are shown in Figure 1-2. The two databases are

shown as they might be structured in relational form in Table 1-1, Table 1-2, and Table 1-3 on page

1-9.