1.

6 Advantages of Using the DBMS Approach I 15

1.6 ADVANTAGES OF USING THE DBMS
ApPROACH
In this section we discuss some of the advantages of using a DBMS and the capabilities that
a good DBMS should possess. These capabilities are in addition to the four main character-
istics discussed in Section 1.3. The DBA must utilize these capabilities to accomplish a
variety of objectives related to the design, administration, and use of a large multiuser
database.

1.6.1 Controlling Redundancy

In traditional software development utilizing file processing, every user group maintains its
own files for handling its data-processing applications. For example, consider the UNIVERSITY
database example of Section 1.2; here, two groups of users might be the course registration
personnel and the accounting office. In the traditional approach, each group independently
keeps files on students. The accounting office also keeps data on registration and related
billing information, whereas the registration office keeps track of student courses and grades.
Much of the data is stored twice: once in the files of each user group. Additional user groups
may further duplicate some or all of the same data in their own files.
This redundancy in storing the same data multiple times leads to several problems.
First, there is the need to perform a single logical update-such as entering data on a new
student-multiple times: once for each file where student data is recorded. This leads to
duplication of effort. Second, storage space is wasted when the same data is stored repeatedly,
and this problem may be serious for large databases. Third, files that represent the same
data may become inconsistent. This may happen because an update is applied to some of
the files but not to others. Even if an update-such as adding a new student-is applied to
all the appropriate files, the data concerning the student may still be inconsistent because
the updates are applied independently by each user group. For example, one user group
may enter a student's birthdate erroneously as JAN-19-1984, whereas the other user groups
may enter the correct value of JAN-29-1984.
In the database approach, the views of different user groups are integrated during
database design. Ideally, we should have a database design that stores each logical data
item-such as a student's name or birth date-in only one place in the database. This
ensures consistency, and it saves storage space. However, in practice, it is sometimes
necessary to use controlled redundancy for improving the performance of queries. For
example, we may store Studentl-Jame and CourseN umber redundantly in a GRADE_REPORT
file (Figure 1.5a) because whenever we retrieve a GRADE_REPORT record, we want to
retrieve the student name and course number along with the grade, student number,
and section identifier. By placing all the data together, we do not have to search
multiple files to collect this data. In such cases, the DBMS should have the capability to
control this redundancy so as to prohibit inconsistencies among the files. This may be
done by automatically checking that the StudentName-StudentNumber values in any
GRADE_REPORT record in Figure 1.5a match one of the Name-StudentNumber values of a
STUDENT record (Figure 1.2). Similarly, the SectionIdentifier-CourseNumber values in
16 I Chapter 1 Databases and Database Users

"-_._--- -
ORT Stude ntN umber StudentName SectionldentifierL~<:)~~~-~Numbe; Grade
17 Smith 112 I MATH2410 B
I

._._-
17
8
8
Smith _.-
Brown
Brown
119
85
92
__ ~_CS1310
MATH2410
CS1310
tt, A
f---
8 I Brown 102 CS3320 B.~._._---

8 .,---
Brown 135 '--
CS3380 A

(b)
I
GRADE_REPORT StudentNumber StudentName Sectionldentifier CourseNumber Grade I I
17 Brown 112 -MATH2410 ' B I I
FIGURE 1.5 Redundant storage of StudentName and CourseNumber in GRADE_REPORT. (a) Consistent
data. (b) Inconsistent record.

GRADE_REPORT can be checked against SECTION records. Such checks can be specified to
the DBMS during database design and automatically enforced by the DBMS whenever the
GRADE_REPORT file is updated. Figure 1.5b shows a GRADE3EPORT record that is inconsistent
with the STUDENT file of Figure 1.2, which may be entered erroneously if the redundancy
is not controlled.

1.6.2 Restricting Unauthorized Access

When multiple users share a large database, it is likely that most users will not be autho-
rized to access all information in the database. For example, financial data is often consid-
ered confidential, and hence only authorized persons are allowed to access such data. In
addition, some users may be permitted only to retrieve data, whereas others are allowed
both to retrieve and to update. Hence, the type of access operation-retrieval or
update-must also be controlled. Typically, users or user groups are given account num-
bers protected by passwords, which they can use to gain access to the database. A DBMS
should provide a security and authorization subsystem, which the DBA uses to create
accounts and to specify account restrictions. The DBMS should then enforce these restric-
tions automatically. Notice that we can apply similar controls to the DBMS software. For
example, only the DBA's staff may be allowed to use certain privileged software, such as
the software for creating new accounts. Similarly, parametric users may be allowed to
access the database only through the canned transactions developed for their use.

1.6.3 Providing Persistent Storage for Program Objects

Databases can be used to provide persistent storage for program objects and data struc-
tures. This is one of the main reasons for object-oriented database systems. Programming
languages typically have complex data structures, such as record types in Pascal or class
 1.6 Advantages of Using the DBMS Approach I 17
definitions in c++ or Java. The values of program variables are discarded once a program
terminates, unless the programmer explicitly stores them in permanent files, which often
involves converting these complex structures into a format suitable for file storage. When
the need arises to read this data once more, the programmer must convert from the file
format to the program variable structure. Object-oriented database systems are compati-
ble with programming languages such as c++ and Java, and the DBMS software automati-
cally performs any necessary conversions. Hence, a complex object in c++ can be stored
permanently in an object-oriented DBMS. Such an object is said to be persistent, since it
survives the termination of program execution and can later be directly retrieved by
another c+ + program.
The persistent storage of program objects and data structures is an important
function of database systems. Traditional database systems often suffered from the so-
called impedance mismatch problem, since the data structures provided by the DBMS
were incompatible with the programming language's data structures. Object-oriented
database systems typically offer data structure compatibility with one or more object-
oriented programming languages.

1.6.4 Providing Storage Structures for Efficient Query

Processing
Database systems must provide capabilities for efficiently executing queries and updates.
Because the database is typically stored on disk, the DBMS must provide specialized data
structures to speed up disk search for the desired records. Auxiliary files called indexes are
used for this purpose. Indexes are typically based on tree data structures or hash data struc-
tures, suitably modified for disk search. In order to process the database records needed by a
particular query, those records must be copied from disk to memory. Hence, the DBMS often
has a buffering module that maintains parts of the database in main memory buffers. In
other cases, the DBMS may use the operating system to do the buffering of disk data.
The query processing and optimization module of the DBMS is responsible for
choosing an efficient query execution plan for each query based on the existing storage
structures. The choice of which indexes to create and maintain is part of physical database
design and tuning, which is one of the responsibilities of the DBA staff.

1.6.5 Providing Backup and Recovery

A DBMS must provide facilities for recovering from hardware or software failures. The
backup and recovery subsystem of the DBMS is responsible for recovery. For example, if
the computer system fails in the middle of a complex update transaction, the recovery
subsystem is responsible for making sure that the database is restored to the state it was in
before the transaction started executing. Alternatively, the recovery subsystem could
ensure that the transaction is resumed from the point at which it was interrupted so that
its full effect is recorded in the database.
18 I Chapter 1 Databases and Database Users

1.6.6 Providing Multiple User Interfaces

Because many types of users with varying levels of technical knowledge use a database, a
DBMS should provide a variety of user interfaces. These include query languages for casual
users, programming language interfaces for application programmers, forms and command
codes for parametric users, and menu-driven interfaces and natural language interfaces for
stand-alone users. Both forms-style interfaces and menu-driven interfaces are commonly
known as graphical user interfaces (GU Is). Many specialized languages and environ-
ments exist for specifying GUls. Capabilities for providing Web GUl interfaces to a data-
base-or Web-enabling a database-are also quite common.

1.6.7 Representing Complex Relationships among Data

A database may include numerous varieties of data that are interrelated in many ways.
Consider the example shown in Figure 1.2. The record for Brown in the STUDENT file is
related to four records in the GRADCREPDRT file. Similarly, each section record is related to
one course record as well as to a number of GRADE_REPDRT records-one for each student
who completed that section. A DBMS must have the capability to represent a variety of
complex relationships among the data as well as to retrieve and update related data easily
and efficiently.

1.6.8 Enforcing Integrity ~onstraints

Most database applications have certain integrity constraints that must hold for the data. A
DBMS should provide capabilities for defining and enforcing these constraints. The simplest
type of integrity constraint involves specifying a data type for each data item. For example,
in Figure 1.2, we may specify that the value of the Class data item within each STUDENT
record must be an integer between 1 and 5 and that the value of Name must be a string of
no more than 30 alphabetic characters. A more complex type of constraint that frequently
occurs involves specifying that a record in one file must be related to records in other files.
For example, in Figure 1.2, we can specify that "every section record must be related to a
course record." Another type of constraint specifies uniqueness on data item values, such as
"every course record must have a unique value for CourseN umber." These constraints are
derived from the meaning or semantics of the data and of the miniworld it represents. It is
the database designers' responsibility to identify integrity constraints during database
design. Some constraints can be specified to the DBMS and automatically enforced. Other
constraints may have to be checked by update programs or at the time of data entry.
A data item may be entered erroneously and still satisfy the specified integrity
constraints. For example, if a student receives a grade of A but a grade of C is entered in
the database, the DBMS cannot discover this error automatically, because C is a valid value
for the Grade data type. Such data entry errors can only be discovered manually (when
the student receives the grade and complains) and corrected later by updating the
database. However, a grade of Z can be rejected automatically by the DBMS, because Z is
not a valid value for the Grade data type.
 1.6 Advantages of Usi ng the DBMS Approach I 19

1.6.9 Permitting Inferencing and Actions Using Rules

Some database systems provide capabilities for defining deduction rules for inferencing new
information from the stored database facts. Such systems are called deductive database
systems. For example, there may be complex rules in the miniworld application for deter-
mining when a student is on probation. These can be specified declaratively as rules,
which when compiled and maintained by the DBMS can determine all students on proba-
tion. In a traditional DBMS, an explicit procedural prof-,Jmm code would have to be written
to support such applications. But if the mini world rules change, it is generally more con-
venient to change the declared deduction rules than to recode procedural programs. More
powerful functionality is provided by active database systems, which provide active rules
that can automatically initiate actions when certain events and conditions occur.

1.6.10 Additional Implications of Using the Database

Approach
This section discusses some additional implications of using the database approach that
can benefit most organizations.

Potential for Enforcing Standards. The database approach permits the DBA to
define and enforce standards among database users in a large organization. This facilitates
communication and cooperation among various departments, projects, and users within
the organization. Standards can be defined for names and formats of data elements,
display formats, report structures, terminology, and so on. The DBA can enforce standards
in a centralized database environment more easily than in an environment where each
user group has control of its own files and software.

Reduced Application Development Time. A prime selling feature of the

database approach is that developing a new application-such as the retrieval of certain data
from the database for printing a new report-takes very little time. Designing and
implementing a new database from scratch may take more time than writing a single
specialized file application. However, once a database is up and running, substantially less time
isgenerally required to create new applications using DBMS facilities. Development time using
a DBMS is estimated to be one-sixth to one-fourth of that for a traditional file system.

FIex i biii ty. It may be necessary to change the structure of a database as requirements
change. For example, a new user group may emerge that needs information not currently
in the database. In response, it may be necessary to add a file to the database or to extend
the data elements in an existing file. Modern DBMSs allow certain types of evolutionary
changes to the structure of the database without affecting the stored data and the existing
application programs.

Availability of Up-to-Date Information. A DBMS makes the database available

to all users. As soon as one user's update is applied to the database, all other users can
20 I Chapter 1 Databases and Database Users

immediately see this update. This availability of up-to-date information is essential for
many transaction-processing applications, such as reservation systems or banking databases,
and it is made possible by the concurrency control and recovery subsystems of a DBMS.

Economies of Scale. The DBMS approach permits consolidation of data and

applications, thus reducing the amount of wasteful overlap between activities of data-
processing personnel in different projects or departments. This enables the whole
organization to invest in more powerful processors, storage devices, or communication gear,
rather than having each department purchase its own (weaker) equipment. This reduces
overall costs of operation and management.

1.7 A BRIEF HISTORY OF DATABASE

ApPlICATIONS
We now give a brief historical overview of the applications that use DBMSs, and how these
applications provided the impetus for new types of database systems.

1.7.1 Early Database Applications Using Hierarchical

and Network Systems
Many early database applications maintained records in large organzations, such as corpo-
rations, universities, hospitals, and banks. In many of these applications, there were large
numbers of records of similar structure. For example, in a university application, similar
information would be kept for each student, each course, each grade record, and so on.
There were also many types of records and many interrelationships among them.
One of the main problems with early database systems was the intermixing of
conceptual relationships with the physical storage and placement of records on disk. For
example, the grade records of a particular student could be physically stored next to the
student record. Although this provided very efficient access for the original queries and
transactions that the database was designed to handle, it did not provide enough
flexibility to access records efficiently when new queries and transactions were identified.
In particular, new queries that required a different storage organization for efficient
processing were quite difficult to implement efficiently. It was also quite difficult to
reorganize the database when changes were made to the requirements of the application.
Another shortcoming of early systems was that they provided only programming
language interfaces. This made it time-consuming and expensive to implement new
queries and transactions, since new programs had to be written, tested, and debugged.
Most of these database systems were implemented on large and expensive mainframe
computers starting in the mid-1960s and through the 1970s and 1980s. The main types of
early systems were based on three main paradigms: hierarchical systems, network model
based systems, and inverted file systems.