Introduction to Database System Concepts

Data
Data can be facts related to any object inconsideration. For example your name, age, height,
weight, etc are related to you. A picture, image, file, PDF etc can also be considered data.

Database
A database is a systematic collection of data that is organized so that it can easily be accessed,
managed, and updated.

DBMS
A database-management system (DBMS) is a collection of interrelated data and a set of
programs to access those data.
Goals of a database
1. The primary goal of a DBMS is to provide a way to store and retrieve database
information that is both convenient and efficient.
2. The database system must ensure the safety of the information stored, despite system
crashes or attempts at unauthorized access.
3. If data are to be shared among several users, the system must avoid possible anomalous
results.
Database System Applications
Banking: For customer information, accounts, and loans, and banking transactions.
Airlines: For reservations and schedule information.
Universities: For student information, course registrations, and grades
Credit card transactions: For purchases on credit cards and generation of monthly statements.
Telecommunication: For keeping records of calls made, generating monthly bills, maintaining
balances on prepaid calling cards, and storing information about the communication networks.
Finance: For storing information about holdings, sales, and purchases of financial instruments
such as stocks and bonds.
Sales: For customer, product, and purchase information.
Manufacturing: For management of supply chain and for tracking production of items in
factories, inventories of items in warehouses/stores, and orders for items.
Human resources: For information about employees, salaries, payroll taxes and benefits, and
for generation of paychecks.

Database Systems versus File Systems

Consider part of a savings-bank enterprise that keeps information about all customers and
savings accounts. One way to keep the information on a computer is to store it in operating
system files. To allow users to manipulate the information, the system has a number of
application programs that manipulate the files, including
• A program to debit or credit an account
• A program to add a new account
• A program to find the balance of an account

Page 1 of 12 Database Systems, Lecture -2, 3, & 4

• A program to generate monthly statements
System programmers wrote these application programs to meet the needs of the bank.
New application programs are added to the system as the need arises. For example, suppose that
the savings bank decides to offer checking accounts. As a result, the bank creates new permanent
files that contain information about all the checking accounts maintained in the bank, and it may
have to write new application programs to deal with situations that do not arise in savings
accounts, such as overdrafts. Thus, as time goes by, the system acquires more files and more
application programs.
Data redundancy and inconsistency
Since different programmers create the files and application programs over a long period, the
various files are likely to have different formats and the programs may be written in several
programming languages. Moreover, the same information may be duplicated in several places
(files). For example, the address and telephone number of a particular customer may appear in a
file that consists of savings-account records and in a file that consists of checking-account
records. This redundancy leads to higher storage and access cost. In addition, it may lead to data
inconsistency; that is, the various copies of the same data may no longer agree. For example, a
changed customer address may be reflected in savings-account records but not elsewhere in the
system.
Difficulty in accessing data
Suppose that one of the bank officers needs to find out the names of all customers who live
within a particular postal-code area. The officer asks the data-processing department to generate
such a list. Because the designers of the original system did not anticipate this request, there is no
application program on hand to meet it. There is, however, an application program to generate
the list of all customers. The bank officer has now two choices: either obtain the list of all
customers and extract the needed information manually or ask a system programmer to write the
necessary application program. Both alternatives are obviously unsatisfactory. Suppose that such
a program is written, and that, several days later, the same officer needs to trim that list to
include only those customers who have an account balance of $10,000 or more. As expected, a
program to generate such a list does not exist. Again, the officer has the preceding two options,
neither of which is satisfactory. The point here is that conventional file-processing environments
do not allow needed data to be retrieved in a convenient and efficient manner. More responsive
data-retrieval systems are required for general use.
Data isolation
Because data are scattered in various files, and files may be in different formats, writing new
application programs to retrieve the appropriate data is difficult.
Integrity problems
The data values stored in the database must satisfy certain types of consistency constraints. For
example, the balance of a bank account may never fall below a prescribed amount (say, $25).
Developers enforce these constraints in the system by adding appropriate code in the various
application programs. However, when new constraints are added, it is difficult to change the
programs to enforce them. The problem is compounded when constraints involve several data
items from different files.

Page 2 of 12 Database Systems, Lecture -2, 3, & 4

Atomicity problems
A computer system, like any other mechanical or electrical device, is subject to failure. In many
applications, it is crucial that, if a failure occurs, the data be restored to the consistent state that
existed prior to the failure. Consider a program to transfer $50 from account A to account B. If a
system failure occurs during the execution of the program, it is possible that the $50 was
removed from account A but was not credited to account B, resulting in an inconsistent database
state. Clearly, it is essential to database consistency that either both the credit and debit occur, or
that neither occur. That is, the funds transfer must be atomic—it must happen in its entirety or
not at all. It is difficult to ensure atomicity in a conventional file-processing system.
Concurrent-access anomalies.
For the sake of overall performance of the system and faster response, many systems allow
multiple users to update the data simultaneously. In such an environment, interaction of
concurrent updates may result in inconsistent data. Consider bank account A, containing $500. If
two customers withdraw funds (say $50 and $100 respectively) from account A at about the same
time, the result of the concurrent executions may leave the account in an incorrect (or
inconsistent) state. Suppose that the programs executing on behalf of each withdrawal read the
old balance, reduce that value by the amount being withdrawn, and write the result back. If the
two programs run concurrently, they may both read the value $500, and write back $450 and
$400, respectively. Depending on which one writes the value last, the account may contain either
$450 or $400, rather than the correct value of $350. To guard against this possibility, the system
must maintain some form of supervision. But supervision is difficult to provide because data
may be accessed by many different application programs that have not been coordinated
previously
Security problems
Not every user of the database system should be able to access all the data. For example, in a
banking system, payroll personnel need to see only that part of the database that has information
about the various bank employees. They do not need access to information about customer
accounts. But, since application programs are added to the system in an ad hoc manner,
enforcing such security constraints is difficult.
Durability
In database systems, durability is the ACID property which guarantees that transactions that have
committed will survive permanently. For example, if a flight booking reports that a seat has
successfully been booked, then the seat will remain booked even if the system crashes.
Durability can be achieved by flushing the transaction's log records to non-volatile storage before
acknowledging commitment.

View of Data
A database system is a collection of interrelated files and a set of programs that allow users to
access and modify these files. A major purpose of a database system is to provide users with an
abstract view of the data. That is, the system hides certain details of how the data are stored and
maintained.
1. Physical level. The lowest level of abstraction describes how the data are actually stored.
The physical level describes complex low-level data structures in detail.

Page 3 of 12 Database Systems, Lecture -2, 3, & 4

 2. Logical level. The next-higher level of abstraction describes what data are stored in the
database, and what relationships exist among those data.
3. View level. The highest level of abstraction describes only part of the entire database.
Even though the logical level uses simpler structures, complexity remains because of the
variety of information stored in a large database. Many users of the database system do
not need all this information; instead, they need to access only a part of the database.

Instances and Schemas

The collection of information stored in the database at a particular moment is called an instance
of the database. The overall design of the database is called the database schema. Schemas are
changed infrequently, if at all. There are three types of database schemas: physical schema and
logical schema.

The physical schema describes the database design at the physical level, while the logical
schema describes the database design at the logical level. A database may also have several
schemas at the view level, sometimes called sub schemas that describe different views of the
database.

Of these, the logical schema is by far the most important, in terms of its effect on application
programs, since programmers construct applications by using the logical schema. The physical
schema is hidden beneath the logical schema, and can usually be changed easily without
affecting application programs. Application programs are said to exhibit physical data
independence if they do not depend on the physical schema, and thus need not be rewritten if
the physical schema changes.
Data Models
Underlying the structure of a database is the data model: a collection of conceptual tools for
describing data, data relationships, data semantics, and consistency constraints.
A data model is a collection of tools for describing
✓ Data
✓ Data relationships
✓ Data semantics
✓ Data constraints
List of different types of Data Model
1. Relational model
2. Entity-Relationship data model (mainly for database design)
3. Object-based data models (Object-oriented and Object-relational)

Page 4 of 12 Database Systems, Lecture -2, 3, & 4

 4. Semi structured data model (XML)
Other older models:
5. Network model
6. Hierarchical model

The Entity-Relationship Model

The entity-relationship (E-R) data model is based on a perception of a real world that consists of
a collection of basic objects, called entities, and of relationships among these objects. An entity
is a “thing” or “object” in the real world that is distinguishable from other objects. For example,
each person is an entity, and bank accounts can be considered as entities.
Entities are described in a database by a set of attributes. For example, the attributes account-
number and balance may describe one particular account in a bank, and they form attributes of
the account entity set. Similarly, attributes customer-name, customer-street address and
customer-city may describe a customer entity.
An extra attribute customer-id is used to uniquely identify customers (since it may be possible to
have two customers with the same name, street address, and city). A unique customer identifier
must be assigned to each customer. In the United States, many enterprises use the social-security
number of a person (a unique number the U.S. government assigns to every person in the United
States) as a customer identifier.
A relationship is an association among several entities. For example, a depositor relationship
associates a customer with each account that she has. The set of all entities of the same type and
the set of all relationships of the same type are termed an entity set and relationship set,
respectively.
The overall logical structure (schema) of a database can be expressed graphically by an E-R
diagram, which is built up from the following components:
• Rectangles, which represent entity sets
• Ellipses, which represent attributes
• Diamonds, which represent relationships among entity sets
• Lines, which link attributes to entity sets and entity sets to relationships
Each component is labeled with the entity or relationship that it represents. As an illustration,
consider part of a database banking system consisting of customers and of the accounts that these
customers have. Figure 1.2 shows the corresponding E-R diagram. The E-R diagram indicates
that there are two entity sets, customer and account, with attributes as outlined earlier. The
diagram also shows a relationship depositor between customer and account. In addition to
entities and relationships, the E-R model represents certain constraints to which the contents of a
database must conform. One important constraint is mapping cardinalities, which express the
number of entities to which another entity can be associated via a relationship set. For example,
if each account must belong to only one customer, the E-R model can express that constraint.
The entity-relationship model is widely used in database design, and Chapter 2 explores it in
detail.

Page 5 of 12 Database Systems, Lecture -2, 3, & 4

Relational Model
The relational model uses a collection of tables to represent both data and the relationships
among those data. Each table has multiple columns, and each column has a unique name.
The first table, the customer table, shows, for example, that the customer identified by customer-
id 192-83-7465 is named Johnson and lives at 12 Alma St. in Palo Alto. The second table,
account, shows, for example, that account A-101 has a balance of $500, and A-201 has a balance
of $900. The third table shows which accounts belong to which customers. For example, account
number A-101 belongs to the customer whose customer-id is 192-83-7465, namely Johnson, and
customers 192-83-7465 (Johnson) and 019-28-3746 (Smith) share account number A-201 (they
may share a business venture).

Database Languages
A database system provides a data definition language to specify the database schema and a
data manipulation language to express database queries and updates. In practice, the data
definition and data manipulation languages are not two separate languages; instead they simply
form parts of a single database language, such as the widely used SQL language.
Data-Definition Language
We specify a database schema by a set of definitions expressed by a special language called a
data-definition language (DDL). For instance, the following statement in the SQL language
defines the account table:

Page 6 of 12 Database Systems, Lecture -2, 3, & 4

 create table account
(account-number varchar2(10),
balance number(9,2))

Execution of the above DDL statement creates the account table. In addition, it updates a special
set of tables called the data dictionary or data directory. A data dictionary contains
metadata—that is, data about data. The schema of a table is an example of metadata. A database
system consults the data dictionary before reading or modifying actual data.
We specify the storage structure and access methods used by the database system by a set of
statements in a special type of DDL called a data storage and definition language. These
statements define the implementation details of the database schemas, which are usually hidden
from the users.
The data values stored in the database must satisfy certain consistency constraints.
For example, suppose the balance on an account should not fall below $100. The DDL provides
facilities to specify such constraints. The database systems check these constraints every time the
database is updated.
Data-Manipulation Language
Data manipulation is
• The retrieval of information stored in the database
• The insertion of new information into the database
• The deletion of information from the database
• The modification of information stored in the database
A data-manipulation language (DML) is a language that enables users to access or manipulate
data as organized by the appropriate data model. It requires a user to specify what data are
needed without specifying how to get those data.
However, since a user does not have to specify how to get the data, the database system has to
figure out an efficient means of accessing data. The DML component of the SQL language is
nonprocedural.
This query in the SQL language finds the name of the customer whose customer-id is 192-83-
7465:
select customer.customer-name
from customer
where customer.customer-id = 192-83-7465
The query specifies that those rows from the table customer where the customer-id is 192-83-
7465 must be retrieved, and the customer-name attribute of these rows must be displayed. If the
query were run on the table in Figure 1.3, the name Johnson would be displayed.
Queries may involve information from more than one table. For instance, the following query
finds the balance of all accounts owned by the customer with customerid 192-83-7465.
select account.balance
from depositor, account
where depositor.customer-id = 192-83-7465 and
depositor.account-number = account.account-number

Database Users and Administrators

A primary goal of a database system is to retrieve information from and store new information in
the database. People who work with a database can be categorized as database users or database

Page 7 of 12 Database Systems, Lecture -2, 3, & 4

administrators. There are four different types of database-system users, differentiated by the way
they expect to interact with the system. Different types of user interfaces have been designed for
the different types of users.
• Naive users are unsophisticated users who interact with the system by invoking one of the
application programs that have been written previously. For example, a bank teller who needs to
transfer $50 from account A to account B invokes a program called transfer. This program asks
the teller for the amount of money to be transferred, the account from which the money is to be
transferred, and the account to which the money is to be transferred. As another example,
consider a user who wishes to find her account balance over the World Wide Web. Such a user
may access a form, where she enters her account number. An application program at the Web
server then retrieves the account balance, using the given account number, and passes this
information back to the user. The typical user interface for naive users is a forms interface, where
the user can fill in appropriate fields of the form. Naive users may also simply read reports
generated from the database.
• Application programmers are computer professionals who write application programs.
Application programmers can choose from many tools to develop user interfaces. Rapid
application development (RAD) tools are tools that enable an application programmer to
construct forms and reports without writing a program. There are also special types of
programming languages that combine imperative control structures (for example, for loops,
while loops and if-then-else statements) with statements of the data manipulation language.
These languages, sometimes called fourth-generation languages, often include special features to
facilitate the generation of forms and the display of data on the screen. Most major commercial
database systems include a fourth generation language.
• Sophisticated users interact with the system without writing programs. Instead, they form their
requests in a database query language. They submit each such query to a query processor, whose
function is to break down DML statements into instructions that the storage manager
understands. Analysts who submit queries to explore data in the database fall in this category.
Online analytical processing (OLAP) tools simplify analysts’ tasks by letting them view
summaries of data in different ways. For instance, an analyst can see total sales by region (for
example, North, South, East, and West), or by product, or by a combination of region and
product (that is, total sales of each product in each region). The tools also permit the analyst to
select specific regions, look at data in more detail (for example, sales by city within a region) or
look at the data in less detail (for example, aggregate products together by category). Another
class of tools for analysts is data mining tools, which help them find certain kinds of patterns in
data.
• Specialized users are sophisticated users who write specialized database applications that do
not fit into the traditional data-processing framework. Among these applications are computer-
aided design systems, knowledge base and expert systems, systems that store data with complex
data types (for example, graphics data and audio data), and environment-modeling systems.

Transaction Management
Transaction Management Often, several operations on the database form a single logical unit of work.
An example is a funds transfer, in which one account (say A) is debited and another account (say B) is
credited. Clearly, it is essential that either both the credit and debit occur, or that neither occur. That is,
the funds transfer must happen in its entirety or not at all. This all-or-none requirement is called
atomicity. In addition, it is essential that the execution of the funds transfer preserve the consistency of
the database. That is, the value of the sum A + B must be preserved. This correctness requirement is

Page 8 of 12 Database Systems, Lecture -2, 3, & 4

called consistency. Finally, after the successful execution of a funds transfer, the new values of accounts
A and B must persist, despite the possibility of system failure. This persistence requirement is called
durability. A transaction is a collection of operations that performs a single logical function in a database
application. Each transaction is a unit of both atomicity and consistency. Thus, we require that
transactions do not violate any database-consistency constraints. That is, if the database was consistent
when a transaction started, the database must be consistent when the transaction successfully
terminates. However, during the execution of a transaction, it may be necessary temporarily to allow
inconsistency, since either the debit of A or the credit of B must be done before the other. This
temporary inconsistency, although necessary, may lead to difficulty if a failure occurs. It is the
programmer’s responsibility to define properly the various transactions, so that each preserves the
consistency of the database. For example, the transaction to transfer funds from account A to account B
could be defined to be composed of two separate programs: one that debits account A, and another
that credits account B. The execution of these two programs one after the other will indeed preserve
consistency. However, each program by itself does not transform the database from a consistent state
to a new consistent state. Thus, those programs are not transactions. Ensuring the atomicity and
durability properties is the responsibility of the database system itself—specifically, of the transaction-
management component. In the absence of failures, all transactions complete successfully, and
atomicity is achieved easily. However, because of various types of failure, a transaction may not always
complete its execution successfully. If we are to ensure the atomicity property, a failed transaction must
have no effect on the state of the database. Thus, the database must be restored to the state in which it
was before the transaction in question started executing. The database system must therefore perform
failure recovery, that is, detect system failures and restore the database to the state that existed prior to
the occurrence of the failure. Finally, when several transactions update the database concurrently, the
consistency of data may no longer be preserved, even though each individual transaction is correct. It is
the responsibility of the concurrency-control manager to control the interaction among the concurrent
transactions, to ensure the consistency of the database. Database systems designed for use on small
personal computers may not have all these features. For example, many small systems allow only one
user to access the database at a time. Others do not offer backup and recovery, leaving that to the user.
These restrictions allow for a smaller data manager, with fewer requirements for physical resources—
especially main memory. Although such a low-cost, low-feature approach is adequate for small personal
databases, it is inadequate for a medium- to large-scale enterprise

Application Architectures
Most users of a database system today are not present at the site of the database system, but
connect to it through a network. We can therefore differentiate between client machines, on
which remote database users work, and server machines, on which the database system runs.
Database applications are usually partitioned into two or three parts. In a two-tier architecture,
the application is partitioned into a component that resides at the client machine, which invokes
database system functionality at the server machine through query language statements.
Application program interface standards like ODBC and JDBC are used for interaction between
the client and the server. In contrast, in a three-tier architecture, the client machine acts as
merely a front end and does not contain any direct database calls. Instead, the client end
communicates with an application server, usually through a forms interface. The application
server in turn communicates with a database system to access data. The business logic of the
application, which says what actions to carry out under what conditions, is embedded in the

Page 9 of 12 Database Systems, Lecture -2, 3, & 4

application server, instead of being distributed across multiple clients. Three-tier applications are
more appropriate for large applications, and for applications that run on the World Wide Web.

Database Administrator
One of the main reasons for using DBMSs is to have central control of both the data and the
programs that access those data. A person who has such central control over the system is called
a database administrator (DBA). The functions of a DBA include:
• Schema definition. The DBA creates the original database schema by executing a set of data
definition statements in the DDL.
• Storage structure and access-method definition.
• Schema and physical-organization modification. The DBA carries out changes to the schema
and physical organization to reflect the changing needs of the organization, or to alter the
physical organization to improve performance.
• Granting of authorization for data access. By granting different types of authorization, the
database administrator can regulate which parts of the database various users can access. The
authorization information is kept in a special system structure that the database system consults
whenever someone attempts to access the data in the system.
• Routine maintenance. Examples of the database administrator’s routine maintenance activities
are: Periodically backing up the database, either onto tapes or onto remote servers, to prevent
loss of data in case of disasters such as flooding. Ensuring that enough free disk space is
available for normal operations, and upgrading disk space as required.
􀀀 Monitoring jobs running on the database and ensuring that performances not degraded by very
expensive tasks submitted by some users

History of Database Systems

Data processing drives the growth of computers, as it has from the earliest days of commercial
computers. In fact, automation of data processing tasks predates computers. Punched cards, invented
by Hollerith, were used at the very beginning of the twentieth century to record U.S. census data, and
mechanical systems were used to process the cards and tabulate results. Punched cards were later
widely used as a means of entering data into computers. Techniques for data storage and processing
have evolved over the years:
• 1950s and early 1960s: Magnetic tapes were developed for data storage. Data processing tasks such
as payroll were automated, with data stored on tapes. Processing of data consisted of reading data from
one or more tapes and writing data to a new tape. Data could also be input from punched card decks,
and output to printers. For example, salary raises were processed by entering the raises on punched

Page 10 of 12 Database Systems, Lecture -2, 3, & 4

cards and reading the punched card deck in synchronization with a tape containing the master salary
details. The records had to be in the same sorted order. The salary raises would be added to the salary
read from the master tape, and written to a new tape; the new tape would become the new master
tape. Tapes (and card decks) could be read only sequentially, and data sizes were much larger than main
memory; thus, data processing programs were forced to process data in a particular order, by reading
and merging data from tapes and card decks.
• Late 1960s and 1970s: Widespread use of hard disks in the late 1960s changed the scenario for data
processing greatly, since hard disks allowed direct access to data. The position of data on disk was
immaterial, since any location on disk could be accessed in just tens of milliseconds. Data were thus
freed from the tyranny of sequentiality. With disks, network and hierarchical databases could be created
that allowed data structures such as lists and trees to be stored on disk. Programmers could construct
and manipulate these data structures. A landmark paper by Codd [1970] defined the relational model,
and nonprocedural ways of querying data in the relational model, and relational databases were born.
The simplicity of the relational model and the possibility of hiding implementation details completely
from the programmer were enticing indeed. Codd later won the prestigious Association of Computing
Machinery Turing Award for his work.
• 1980s: Although academically interesting, the relational model was not used in practice initially,
because of its perceived performance disadvantages; relational databases could not match the
performance of existing network and hierarchical databases. That changed with System R, a
groundbreaking project at IBM Research that developed techniques for the construction of an efficient
relational database system. Excellent overviews of System R are provided by Astrahan et al. [1976] and
Chamberlin et al. [1981]. The fully functional System R prototype led to IBM’s first relational database
product, SQL/DS. Initial commercial relational database systems, such as IBM DB2, Oracle, Ingres, and
DEC Rdb, played a major role in advancing techniques for efficient processing of declarative queries. By
the early 1980s, relational databases had become competitive with network and hierarchical database
systems even in the area of performance. Relational databases were so easy to use that they eventually
replaced network/hierarchical databases; programmers using such databases were forced to deal with
many low-level implementation details, and had to code their queries in a procedural fashion. Most
importantly, they had to keep efficiency in mind when designing their programs, which involved a lot of
effort. In contrast, in a relational database, almost all these low-level tasks are carried out automatically
by the database, leaving the programmer free to work at a logical level. Since attaining dominance in the
1980s, the relational model has reigned supreme among data models. The 1980s also saw much
research on parallel and distributed databases, as well as initial work on object-oriented databases.
• Early 1990s: The SQL language was designed primarily for decision support applications, which are
query intensive, yet the mainstay of databases in the 1980s was transaction processing applications,
which are update intensive. Decision support and querying re-emerged as a major application area for
databases. Tools for analyzing large amounts of data saw large growths in usage. Many database
vendors introduced parallel database products in this period. Database vendors also began to add
object-relational support to their databases.
• Late 1990s: The major event was the explosive growth of the World Wide Web. Databases were
deployed much more extensively than ever before. Database systems now had to support very high
transaction processing rates, as well as very high reliability and 24×7 availability (availability 24 hours a
day, 7 days a week, meaning no downtime for scheduled maintenance activities). Database systems also
had to support Web interfaces to data.
• 2000s: The first half o the 2000s saw the emerging of XML and the associated query language XQuery
as a new database technology. This period saw a significant growth of open source database systems,
particularly PostgreSQL, MYSQL.

Page 11 of 12 Database Systems, Lecture -2, 3, & 4

• Late 2000s: The growth of specialized databases for data analysis. Parallel database system was
designed for analysis of very large data sets. Distributed database system had been built to handle large
Web sites such as Facebook, Google, Microsoft, and Yahoo. Streaming data for stock-market ticker was
developed in this period. Data-mining techniques were developed for Web-based product
recommendation systems and automated placement of advertisements of Web pages.
•2010s: Internet of Things (Iot), Big Data, Machine learning

Page 12 of 12 Database Systems, Lecture -2, 3, & 4