Characteristics of the Database Approach multiuser DBMS software is to ensure that concurrent transactions operate

In traditional file processing, each user defines and implements the files correctly.
needed for a specific application as part of programming the application. In
the database approach, a single repository of data is maintained that is
Actors on the Scene
defined once and then is accessed by various users. Characteristics are
1. Self-Describing Nature of a Database System 1. Database Administrators - In a database environment, the primary
2. Insulation between Programs and Data, and Data Abstraction resource is the database itself and the secondary resource is the DBMS and
3. Support of Multiple Views of the Data related software. Administering these resources is the responsibility of the
4. Sharing of Data and Multiuser Transaction Processing database administrator (DBA).
1. Self – Describing nature of a database system 2. Database Designers - Database designers are responsible for identifying
Database system contains not only the database itself but also a complete the data to be stored in the database and for choosing appropriate
definition or description of the database structure and constraints. This structures to represent and store this data
definition is stored in the system catalog, which contains information such 3. End Users - End users are the people whose jobs require access to the
as the structure of each file, the type and storage format of each data item, database for querying, updating, and generating reports; the database
and various constraints on the data. The information stored in the catalog is primarily exists for their use
called meta-data, and it describes the structure of the primary database. 4. System Analysts and Application Programmers (Software Engineers)-
The catalog is used by the DBMS software and also by database users determine the requirements of end users, especially naive and parametric
who need information about the database structure. A general purpose end users. , Sophisticated end users and Stand-alone
DBMS software package is not written for a specific database application,
and hence it must refer to the catalog to know the structure of the files in a Workers behind the Scene
specific database, such as the type and format of data it will access. The In addition to those who design, use, and administer a database, others are
DBMS software must work equally well with any number of database associated with the design, development, and operation of the DBMS
application. software and system environment. These persons are typically not
In traditional file processing, data definition is typically part of the interested in the database itself. We call them the "workers behind the
application programs themselves. Hence, these programs are constrained scene," and they include the following categories.
to work with only one specific database, whose structure is declared in the • DBMS system designers and implementers are persons who design and
application programs. implement the DBMS modules and interfaces as a software package. A
DBMS is a complex software system that consists of many components or
modules, including modules for implementing the catalog, query language,
2. Insulation between Programs and Data, and Data Abstraction
interface processors, data access, concurrency control, recovery, and
In traditional file processing, the structure of data files is embedded in the security. The DBMS must interface with other system software, such as the
access programs, so any changes to the structure of a file may require operating system and compilers for various programming languages.
changing all programs that access this file. By contrast, DBMS access • Tool developers include persons who design and implement tools—the
programs do not require such changes in most cases. The structure of data software packages that facilitate database system design and use, and help
files is stored in the DBMS catalog separately from the access programs. We improve performance. Tools are optional packages that are often
call this property program-data independence. purchased separately. They include packages for database design,
performance monitoring, natural language or graphical interfaces,
prototyping, simulation, and test data generation. In many cases,
In object-oriented and object-relational databases (see Part III), users can
independent software vendors develop and market these tools.
define operations on data as part of the database definitions. An operation
• Operators and maintenance personnel are the system administration
(also called a function) is specified in two parts. The interface (or signature)
of an operation includes the operation name and the data types of its personnel who are responsible for the actual running and maintenance of
arguments (or parameters). The implementation (or method) of the operation the hardware and software environment for the database system.
is specified separately and can be changed without affecting the interface.
User application programs can operate on the data by invoking these Advantages of Using a DBMS
operations through their names and arguments, regardless of how the 1. Controlling Redundancy
operations are implemented. This may be termed program-operation 2. Restricting Unauthorized Access
independence. 3. Providing Persistent Storage for Program Objects and Data
The characteristic that allows program-data independence and program- Structures
operation independence is called data abstraction. A DBMS provides users 4. Permitting Inferencing and Actions Using Rules
with a conceptual representation of data that does not include many of the 5. Providing Multiple User Interfaces
details of how the data is stored or how the operations are implemented. 6. Representing Complex Relationships Among Data
7. Enforcing Integrity Constraints
8. Providing Backup and Recovery
3. Support of Multiple Views of the Data
A database typically has many users, each of whom may require a different
perspective or view of the database. A view may be a subset of the
database or it may contain virtual data that is derived from the database
files but is not explicitly stored. Some users may not need to be aware of
whether the data they refer to is stored or derived. A multiuser DBMS
whose users have a variety of applications must provide facilities for
defining multiple views.

4.Sharing of Data and Multiuser Transaction Processing

A multiuser DBMS, as its name implies, must allow multiple users to access
the database at the same time. This is essential if data for multiple
applications is to be integrated and maintained in a single database. The
DBMS must include concurrency control software to ensure that several
users trying to update the same data do so in a controlled manner so that
the result of the updates is correct. For example, when several reservation
clerks try to assign a seat on an airline flight, the DBMS should ensure that
each seat can be accessed by only one clerk at a time for assignment to a
passenger. These types of applications are generally called on-line
transaction processing (OLTP) applications. A fundamental role of
One fundamental characteristic of the database approach is that it provides for the database shown in Figure 01.02; the diagram displays the structure
some level of data abstraction by hiding details of data storage that are not of each record type but not the actual instances of records. We call each
needed by most database users. A data model—a collection of concepts object in the schema—such as STUDENT or COURSE—a schema construct.
that can be used to describe the structure of a database—provides the A schema diagram displays only some aspects of a schema, such as the
necessary means to achieve this abstraction (Note 1). By structure of a names of record types and data items, and some types of constraints.
database we mean the data types, relationships, and constraints that Other aspects are not specified in the schema diagram; for example, Figure
should hold on the data. Most data models also include a set of basic 02.01 shows neither the data type of each data item nor the relationships
operations for specifying retrievals and updates on the database. among the various files. Many types of constraints are not represented in
In addition to the basic operations provided by the data model, it is schema diagrams; for example, a constraint such as "students majoring in
becoming more common to include concepts in the data model to specify computer science must take CS1310 before the end of their sophomore
the dynamic aspect or behavior of a database application. This allows the year" is quite difficult to represent.
database designer to specify a set of valid user-defined operations that are The actual data in a database may change quite frequently; for example,
allowed on the database objects (Note 2). An example of a user-defined the database shown in Figure 01.02 changes every time we add a student
operation could be COMPUTE_GPA, which can be applied to a STUDENT or enter a new grade for a student. The data in the database at a particular
object. On the other hand, generic operations to insert, delete, modify, or moment in time is called a database state or snapshot. It is also called the
retrieve any kind of object are often included in the basic data model current set of occurrences or instances in the database. In a given database
operations. Concepts to specify behavior are fundamental to object- state, each schema construct has its own current set of instances; for
oriented data models (see Chapter 11 and Chapter12) but are also being example, the STUDENT construct will contain the set of individual student
incorporated in more traditional data models by extending these models. entities (records) as its instances. Many database states can be constructed
For example, object-relational models (see Chapter 13) extend the to correspond to a particular database schema. Every time we insert or
traditional relational model to include such concepts, among others. delete a record, or change the value of a data item in a record, we change
2.1.1 Categories of Data Models one state of the database into another state.
Many data models have been proposed, and we can categorize them The distinction between database schema and database state is very
according to the types of concepts they use to describe the database important. When we define a new database, we specify its database
structure. High-level or conceptual data models provide concepts that are schema only to the DBMS. At this point, the corresponding database state
close to the way many users perceive data, whereas low-level or physical is the empty state with no data. We get the initial state of the database
data models provide concepts that describe the details of how data is when the database is first populated or loaded with the initial data. From
stored in the computer. Concepts provided by low-level data models are then on, every time an update operation is applied to the database, we get
generally meant for computer specialists, not for typical end users. another database state. At any point in time, the database has a current
Between these two extremes is a class of representational (or state (Note
implementation) data models, which provide concepts that may be 1 Page 40 of 893
understood by end users but that are not too far removed from the way 6). The DBMS is partly responsible for ensuring that every state of the
data is organized within the computer. Representational data models hide database is a valid state—that is, a state that satisfies the structure and
some details of data storage but can be implemented on a computer constraints specified in the schema. Hence, specifying a correct schema to
system in a direct way. the DBMS is extremely important, and the schema must be designed with
Conceptual data models use concepts such as entities, attributes, and the utmost care. The DBMS stores the descriptions of the schema
relationships. An entity represents a real-world object or concept, such as constructs and constraints—also called the meta-data—in the DBMS
an employee or a project, that is described in the database. An attribute catalog so that DBMS software can refer to the schema whenever it needs
represents some property of interest that further describes an entity, such to. The schema is sometimes called the intension, and a database state an
as the employee’s name or salary. A relationship among two or more extension of the schema.
entities represents an interaction among the entities; for example, a works- Although, as mentioned earlier, the schema is not supposed to change
on relationship between an employee and a project. In Chapter 3, we will frequently, it is not uncommon that changes need to be applied to the
present the Entity-Relationship model—a popular high-level conceptual schema once in a while as the application requirements change. For
data model. Chapter 4 describes additional data modeling concepts, such as example, we may decide that another data item needs to be stored for
generalization, specialization, and categories. each record in a file, such as adding the DateOfBirth to the STUDENT
Representational or implementation data models are the models used most schema in Figure 02.01. This is known as schema evolution. Most modern
frequently in traditional commercial DBMSs, and they include the widely- DBMSs include some operations for schema evolution that can be applied
used relational data model, as well as the so-called while the database is operational.
1 Page 39 of 893 2.2 DBMS Architecture and Data Independence
legacy data models—the network and hierarchical models—that have 2.2.1 The Three-Schema Architecture 2.2.2 Data Independence
been widely used in the past. Part II of this book is devoted to the relational Three important characteristics of the database approach, listed in Section
data model, its operations and languages, and also includes an overview of 1.3, are (1) insulation of programs and data (program-data and program-
two relational systems (Note 3). The SQL standard for relational databases operation independence); (2) support of multiple user views; and (3) use of
is described in Chapter 8. Representational data models represent data by a catalog to store the database description (schema). In this section we
using record structures and hence are sometimes called record-based data specify an architecture for database systems, called the three-schema
models. architecture (Note 7), which was proposed to help achieve and visualize
We can regard object data models as a new family of higher-level these characteristics. We then discuss the concept of data independence.
implementation data models that are closer to conceptual data models. We 2.2.1 The Three-Schema Architecture
describe the general characteristics of object databases, together with an The goal of the three-schema architecture, illustrated in Figure 02.02, is to
overview of two object DBMSs, in Part III of this book. The ODMG proposed separate the user applications and the physical database. In this
standard for object databases is described in Chapter 12. Object data architecture, schemas can be defined at the following three levels:
models are also frequently utilized as high-level conceptual models, 1. The internal level has an internal schema, which describes the physical
particularly in the software engineering domain. storage structure of the database. The internal schema uses a physical data
Physical data models describe how data is stored in the computer by model and describes the complete details of data storage and access paths
representing information such as record formats, record orderings, and for the database.
access paths. An access path is a structure that makes the search for 2. The conceptual level has a conceptual schema, which describes the
particular database records efficient. We discuss physical storage structure of the whole database for a community of users. The conceptual
techniques and access structures in Chapter 5 and Chapter 6. schema hides the details of physical storage structures and concentrates on
2.1.2 Schemas, Instances, and Database State describing entities, data types, relationships, user operations, and
In any data model it is important to distinguish between the description of constraints. A high-level data model or an implementation data model can
the database and the database itself. The description of a database is called be used at this level.
the database schema, which is specified during database design and is not 3. The external or view level includes a number of external schemas or
expected to change frequently (Note 4). Most data models have certain user views. Each external schema describes the part of the database that a
conventions for displaying the schemas as diagrams (Note 5). A displayed particular user group is interested in and hides the rest of the database
schema is called a schema diagram. Figure 02.01 shows a schema diagram
from that user group. A high-level data model or an implementation data of users. In this section we discuss the types of languages and interfaces
model can be used at this level. provided by a DBMS and the user categories targeted by each interface.
2.3.1 DBMS Languages
The three-schema architecture is a convenient tool for the user to visualize Once the design of a database is completed and a DBMS is chosen to
the schema levels in a database system. Most DBMSs do not separate the implement the database, the first order of the day is to specify conceptual
three levels completely, but support the three- and internal schemas for the database and any mappings between the two.
1 Page 41 of 893 In many DBMSs where no strict separation of levels is maintained, one
schema architecture to some extent. Some DBMSs may include physical- language, called the data definition language (DDL), is used by the DBA and
level details in the conceptual schema. In most DBMSs that support user by database designers to define both schemas. The DBMS will have a DDL
views, external schemas are specified in the same data model that compiler whose function is to process DDL statements in order to identify
describes the conceptual-level information. Some DBMSs allow different descriptions of the schema constructs and to store the schema description
data models to be used at the conceptual and external levels. in the DBMS catalog.
Notice that the three schemas are only descriptions of data; the only data In DBMSs where a clear separation is maintained between the conceptual
that actually exists is at the physical level. In a DBMS based on the three- and internal levels, the DDL is used to specify the conceptual schema only.
schema architecture, each user group refers only to its own external Another language, the storage definition language (SDL), is used to specify
schema. Hence, the DBMS must transform a request specified on an the internal schema. The mappings between the two schemas may be
external schema into a request against the conceptual schema, and then specified in either one of these languages. For a true three-schema
into a request on the internal schema for processing over the stored architecture, we would need a third language, the view definition language
database. If the request is a database retrieval, the data extracted from the (VDL), to specify user views and their mappings to the conceptual schema,
stored database must be reformatted to match the user’s external view. but in most DBMSs the DDL is used to define both conceptual and external
The processes of transforming requests and results between levels are schemas.
called mappings. These mappings may be time-consuming, so some DBMSs Once the database schemas are compiled and the database is populated
—especially those that are meant to support small databases—do not with data, users must have some means to manipulate the database.
support external views. Even in such systems, however, a certain amount of Typical manipulations include retrieval, insertion, deletion, and
mapping is necessary to transform requests between the conceptual and modification of the data. The DBMS provides a data manipulation language
internal levels. (DML) for these purposes.
2.2.2 Data Independence In current DBMSs, the preceding types of languages are usually not
The three-schema architecture can be used to explain the concept of data considered distinct languages; rather, a comprehensive integrated language
independence, which can be defined as the capacity to change the schema is used that includes constructs for conceptual schema definition, view
at one level of a database system without having to change the schema at definition, and data manipulation. Storage definition is typically kept
the next higher level. We can define two types of data independence: separate, since it is used for defining physical storage structures to fine-
1. Logical data independence is the capacity to change the conceptual tune the performance of the database system, and it is usually utilized by
schema without having to change external schemas or application the DBA staff. A typical example of a comprehensive database language is
programs. We may change the conceptual schema to expand the database the SQL relational database language (see Chapter 8), which represents a
(by adding a record type or data item), or to reduce the database (by combination of DDL, VDL, and DML, as well as statements for constraint
removing a record type or data item). In the latter case, external schemas specification and schema evolution. The SDL was a component in earlier
that refer only to the remaining data should not be affected. For example, versions of SQL but has been removed from the language to keep it at the
the external schema of Figure 01.04(a) should not be affected by changing conceptual and external levels only.
the GRADE_REPORT file shown in Figure 01.02 into the one shown in Figure There are two main types of DMLs. A high-level or nonprocedural DML can
01.05(a). Only the view definition and the mappings need be changed in a be used on its own to specify complex database operations in a concise
DBMS that supports logical data independence. Application programs that manner. Many DBMSs allow high-level DML statements either to be
reference the external schema constructs must work as before, after the entered interactively from a terminal (or monitor) or to be embedded in a
conceptual schema undergoes a logical reorganization. Changes to general-purpose programming language. In the latter case, DML statements
constraints can be applied also to the conceptual schema without affecting must be identified within the program so that they can be extracted by a
the external schemas or application programs. pre-compiler and processed by the DBMS. A low-level or procedural DML
2. Physical data independence is the capacity to change the internal must be embedded in a general-purpose programming language. This type
schema without having to change the conceptual (or external) schemas. of DML typically retrieves individual records or objects from the database
Changes to the internal schema may be needed because some physical files and processes each separately. Hence, it needs to use programming
had to be reorganized—for example, by creating additional access language constructs, such as looping, to retrieve and process each record
structures—to improve the performance of retrieval or update. If the same from a set of records. Low-level DMLs are also called record-at-a-time
data as before remains in the database, we should not have to change the DMLs because of this property. High-level DMLs, such as SQL, can specify
conceptual schema. For example, providing an access path to improve and retrieve many records in a single DML
retrieval of SECTION records (Figure 01.02) by Semester and Year should 1 Page 43 of 893
not require a query such as "list all sections offered in fall 1998" to be statement and are hence called set-at-a-time or set-oriented DMLs. A
changed, although the query would be executed more efficiently by the query in a high-level DML often specifies which data to retrieve rather than
DBMS by utilizing the new access path. how to retrieve it; hence, such languages are also called declarative.
Whenever DML commands, whether high-level or low-level, are embedded
Whenever we have a multiple-level DBMS, its catalog must be expanded to in a general-purpose programming language, that language is called the
include information on how to map requests and data among the various host language and the DML is called the data sublanguage (Note 8). On the
levels. The DBMS uses additional software to accomplish these mappings by other hand, a high-level DML used in a stand-alone interactive manner is
referring to the mapping information in the catalog. Data independence is called a query language. In general, both retrieval and update commands
accomplished because, when the schema is changed at some level, the of a high-level DML may be used interactively and are hence considered
schema at the next higher level remains unchanged; only the mapping part of the query language (Note 9).
between the two levels is changed. Hence, application programs referring Casual end users typically use a high-level query language to specify their
to the higher-level schema need not be changed. requests, whereas programmers use the DML in its embedded form. For
The three-schema architecture can make it easier to achieve true data naive and parametric users, there usually are user-friendly interfaces for
independence, both physical and logical. However, the two levels of interacting with the database; these can also be used by casual users or
mappings create an overhead during compilation or execution of a query or others who do not want to learn the details of a high-level query language.
program, leading to inefficiencies in the DBMS. Because of this, few DBMSs We discuss these types of interfaces next.
have implemented the full three-schema architecture. 2.3.2 DBMS Interfaces
1 Page 42 of 893 Menu-Based Interfaces for Browsing Forms-Based Interfaces Graphical User
2.3 Database Languages and Interfaces Interfaces Natural Language Interfaces Interfaces for Parametric Users
2.3.1 DBMS Languages 2.3.2 DBMS Interfaces Interfaces for the DBA
In Section 1.4 we discussed the variety of users supported by a DBMS. The User-friendly interfaces provided by a DBMS may include the following.
DBMS must provide appropriate languages and interfaces for each category Menu-Based Interfaces for Browsing
These interfaces present the user with lists of options, called menus, that
lead the user through the formulation of a request. Menus do away with
the need to memorize the specific commands and syntax of a query
language; rather, the query is composed step by step by picking options
from a menu that is displayed by the system. Pull-down menus are
becoming a very popular technique in window-based user interfaces. They
are often used in browsing interfaces, which allow a user to look through
the contents of a database in an exploratory and unstructured manner.
Forms-Based Interfaces
A forms-based interface displays a form to each user. Users can fill out all of
the form entries to insert new data, or they fill out only certain entries, in
which case the DBMS will retrieve matching data for the remaining entries.
Forms are usually designed and programmed for naive users as interfaces
to canned transactions. Many DBMSs have forms specification languages,
special languages that help programmers specify such forms. Some systems
have utilities that define a form by letting the end user interactively
construct a sample form on the screen.
1 Page 44 of 893
Graphical User Interfaces
A graphical interface (GUI) typically displays a schema to the user in
diagrammatic form. The user can then specify a query by manipulating the
diagram. In many cases, GUIs utilize both menus and forms. Most GUIs use
a pointing device, such as a mouse, to pick certain parts of the displayed
schema diagram.
Natural Language Interfaces
These interfaces accept requests written in English or some other language
and attempt to "understand" them. A natural language interface usually has
its own "schema," which is similar to the database conceptual schema. The
natural language interface refers to the words in its schema, as well as to a
set of standard words, to interpret the request. If the interpretation is
successful, the interface generates a high-level query corresponding to the
natural language request and submits it to the DBMS for processing;
otherwise, a dialogue is started with the user to clarify the request.
Interfaces for Parametric Users
Parametric users, such as bank tellers, often have a small set of operations
that they must perform repeatedly. Systems analysts and programmers
design and implement a special interface for a known class of naive users.
Usually, a small set of abbreviated commands is included, with the goal of
minimizing the number of keystrokes required for each request. For
example, function keys in a terminal can be programmed to initiate the
various commands. This allows the parametric user to proceed with a
minimal number of keystrokes.
Interfaces for the DBA
Most database systems contain privileged commands that can be used only
by the DBA’s staff. These include commands for creating accounts, setting
system parameters, granting account authorization, changing a schema,
and reorganizing the storage structures of a database.