A database is a collection of data, typically describing the activities of one or more

related organizations. For example, a university database might contain information

about the following:
• Entities such as students, faculty, courses, and classrooms.
• Relationships between entities, such as students' enrollment in courses, faculty
teaching courses, and the use of rooms for courses.
A database management system, or DBMS, is software designed to assist in
maintaining and utilizing large collections of data. The alternative to using a DBMS is to
store the data in files and write application-specific code to manage it.

Overview of Database Systems

1. Database Design and Application Development: How can a user describe a real-
world enterprise (e.g., a university) in terms of the data stored in a DBMS? What factors
must be considered in deciding how to organize the stored data? How can ,we develop
applications that rely upon a DBMS?
2. Data Analysis: How can a user answer questions about the enterprise by posing
queries over the data in the DBMS?
3. Concurrency and Robustness: How does a DBMS allow many users to access data
concurrently, and how does it protect the data in the event of system failures?
Efficiency and Scalability: How does a DBMS store large datasets and answer
questions against this data efficiently?

FILE SYSTEMS VERSUS A DBMS

To understand the need for a DBMS, consider a motivating scenario: A company has a
large collection (say, 500 TB ) of data on employees, departments, products, sales, and
so on. This data is accessed concurrently by several employees. Questions about the
data must be answered quickly, changes made to the data by different users must be
applied consistently, and access to certain parts of the data (e.g., salaries) must be
restricted.
We can try to manage the data by storing it in operating system files. This approach has
many drawbacks, including the following:

1|Page
• We probably do not have 500 GB of main memory to hold all the data. We must
therefore store data in a storage device such as a disk or tape and bring relevant parts
into main memory for processing as needed.
• Even if we have 500 GB of main memory, on computer systems with 32-bit
addressing, we cannot refer directly to more than about 4 GB of data. We have to
program some method of identifying all data items.
• We have to write special programs to answer each question a user may want to ask
about the data. These programs are likely to be complex because of the large volume of
data to be searched.
• We must protect the data from inconsistent changes made by different users
accessing the data concurrently. If applications must address the details of such
concurrent access, this adds greatly to their complexity.
• We must ensure that data is restored to a consistent state if the system crac;hes while
changes are being made.
• Operating systems provide only a password mechanism for security. This is not
sufficiently flexible to enforce security policies in which different users have permission
to access different subsets of the data.
A DBMS is a piece of software designed to make the above tasks easier. By storing
data in.a DBMS rather than as a collection of operating system files, we can use the
DBMS's features to manage the data in a robust and efficient manner. As the volume of
data and the number of users grow hundreds of gigabytes of data and thousands of
users are common in current corporate databases DBMS support becomes
indispensable.

ADVANTAGES OF A DBMS
1.Data Independence: Application programs should not, ideally, be exposed to details of
data representation and storage, The DBJVIS provides an abstract view of the data that
hides such details.
2. Efficient Data Access: A DBMS utilizes a variety of sophisticated techniques to store
and retrieve data efficiently. This feature is especially important if the data is stored on
external storage devices.

2|Page
3. Data Integrity and Security: If data is always accessed through the DBMS, the DBMS
can enforce integrity constraints. For example, before inserting salary information for an
employee, the DBMS can check that the department budget is not exceeded. Also, it
can enforce access controls that govern what data is visible to different classes of
users.
4. Data Administration: When several users share the data, centralizing the
administration of data can offer significant improvements. Experienced professionals
who understand the nature of the data being managed, and how different groups of
users use it, can be responsible for organizing the data representation to minimize
redundancy and for fine-tuning the storage of the data to make retrieval efficient.
5. Concurrent Access and Crash Recovery: A DBMS schedules concurrent accesses to
the data in such a manner that users can think of the data as being accessed by only
one user at a time. Further, the DBMS protects users from the effects of system failures.
6. Reduced Application Development Time: Clearly, the DBMS supports important
functions that are common to many applications accessing data in the DBMS.

Disadvantages
Given all these advantages, is there ever a reason not to use a DBMS? Sometimes,
yes. A DBMS is a complex piece of software, optimized for certain kinds of workloads
(e.g., answering complex queries or handling many concurrent requests), and its
performance may not be adequate for certain specialized applications.

DESCRIBING AND STORING DATA IN A DBMS

The user of a DBMS is ultimately concerned with some real-world enterprise, and the
data to be stored describes various aspects of this enterprise. For example, there are
students, faculty, and courses in a university, and the data in a university database
describes these entities and their relationships.
A data model is a collection of high-level data description constructs that hide many
low-level storage details. A DBMS allows a user to define the data to be stored in terms
of a data model. Most database management systems today are based on the
relational data model.

3|Page
While the data model of the DBMS hides many details, it is nonetheless closer to how
the DBMS stores data than to how a user thinks about the underlying enterprise. A
semantic data model is a more abstract, high-level data model that makes it easier for
a user to come up with a good initial description of the data in an enterprise. These
models contain a wide variety of constructs that help describe a real application
scenario. A DBMS is not intended to support all these constructs directly; it is typically
built around a data model with just a few basic constructs, such as the relational model.
A database design in terms of a semantic model serves as a useful starting point and is
subsequently translated into a database design in terms of the data model the
DBMS actually supports. A widely used semantic data model called the entity-
relationship (ER) model allows us to pictorially denote entities and the relationships
among them.
An Example of Poor Design: The relational schema for Students illustrates a poor
design choice; you should never create a field such as age, whose value is constantly
changing. A better choice would be DOB (for date of birth); age can be computed from
this.
Introduction to the relational model.
 The central data description construct in this model is a relation, which can be
thought of as a set of records. A description of data in terms of a data model is
called a schema. In the relational model, the schema for a relation specifies its
name, the name of each field (or attribute or column), and the type of each field.
 As an example, student information in a university database may be stored in a
relation with the following schema:
Students( sid: string, name: string, login: string,
age: integer, gpa: real)
The preceding schema says that each record in the Students relation has five fields,
with field names and types as indicated.
An example instance of the
Students relation appears in above
I sid [ name IZogin
53666 Jones jones@cs 18 3.4

4|Page
53688 Smith smith@ee 18 3.2
53650 Smith smith@math 19 3.8
53831 Madayan madayan(gmusic 11 1.8
53832 Guldu guldui:Qhnusic 12 2.0
Above An Instance of the Students Relation

Each row in the Students relation is a record that describes a student. The description is
not complete for example, the student's height is not included—but is presumably
adequate for the intended applications in the university database. Every row follows the
schema of the Students relation.
The schema call therefore be regarded as a template for describing a student. We can
make the description of a collection of students more precise by specifying integrity
constraints, which are conditions that the records in a relation must satisfy. for example,
we could specify that every student has a unique sid value.

Other Data Models

Conceptual Schema
The conceptual schema (sometimes called the logical schema) describes the stored
data in terms of the data model of the DBMS. In a relational DBMS, the conceptual
schema describes all relations that are stored in the database.
In our sample university database, these relations contain information about entities,
such as students and faculty, and about relationships, such as students' enrollment in
courses. All student entities can be described using records in a Students relation, as
we saw earlier. In fact, each collection of entities and each collection of relationships
can be described as a relation, leading to the following conceptual schema:
Students(sid: string, name: string, login: string,
age: integer, gpa: real)
Faculty(fid: string, fname: string, sal: real)
Courses( cid: string, cname: string, credits: integer)
Rooms(nw: integer, address: string, capacity: integer)
Enrolled (sid: string, cid: string, grade: string)
Teaches(fid: string, cid: string)

5|Page
Meets_In( cid: string, rno: integer, ti'fne: string)
The choice of relations, and the choice of fields for each relation, is not always obvious,
and the process of arriving at a good conceptual schema is called conceptual database
design.

Physical Schema
The physical schema specifies additional storage details. Essentially, the physical
schema summarizes how the relations described in the conceptual schema are actually
stored on secondary storage devices such as disks and tapes.
We must decide what file organizations to use to store the relations and create auxiliary
data structures, called indexes, to speed up data retrieval operations.
A sample physical schema for the university database follows:
• Store all relations as unsorted files of records. (A file in a DBMS is either a collection of
records or a collection of pages, rather than a string of characters as in an operating
system.)
• Create indexes on the first column of the Students, Faculty, and Courses relations, the
sal column of Faculty, and the capacity column of Rooms.
Decisions about the physical schema are based on an understanding of how the data is
typically accessed. The process of arriving at a good physical schema is called physical
database design.
External Schema
External schemas, which usually are also in terms of the data model of the DBMS, allow
data access to be customized (and authorized) at the level of individual users or groups
of users. Any given database has exactly one conceptual schema and one physical
schema because it has just one set of stored relations, but it may have several external
schemas, each tailored to a particular group of users. Each external schema consists of
a collection of one or more views and relations from the conceptual schema.
Data Independence
A very important advantage of using a DBMS is that it offers data independence. That
is, application programs are insulated from changes in the way the data is structured
and stored. Data independence is achieved through use of the three levels of data

6|Page
abstraction; in particular, the conceptual schema and the external schema provide
distinct benefits in this area.

7|Page