Database Management Systems

UNIT-1

1
 Content
Introduction to Database And System Architecture:
• Database Systems and their Applications
• Database Vs File System
• View of Data
• Data Models
• Database Languages- DDL and DML
• Transaction Management
• Database users and Administrators
• Database System Structure
 Content
Introduction to Database Design:
• ER Diagrams
• Entities, Attributes and Entity sets
• Relationships and Relationship set
• Extended ER Features
• Conceptual Design with the ER Model
• Logical database Design
 Definition of Database
A database is an organized collection of data.
It is the collection of tables, queries, reports, views and other
objects.

4
 Definition of DBMS

A database management system

(DBMS) is a collection of programs
that enables you to store, modify,
and extract information from a
database.
It consists of a group of programs
which manipulate the database and
provide an interface between the
database.

It includes the user of the database

and other application programs.

5
Applications of Databases

6
Database vs File Systems

7
8
9
 Database System Applications
• DBMS contains information about a particular enterprise
– Collection of interrelated data
– Set of programs to access the data
– An environment that is both convenient and efficient to use
• Database Applications:
– Banking: all transactions
– Airlines: reservations, schedules
– Universities: registration, grades
– Sales: customers, products, purchases
– Online retailers: order tracking, customized recommendations
– Manufacturing: production, inventory, orders, supply chain
– Human resources: employee records, salaries, tax deductions
• Databases touch all aspects of our lives
 Purpose of Database Systems
• In the early days, database applications were built directly on top of
file systems
• Drawbacks of using file systems to store data:
– Data redundancy and inconsistency
• Multiple file formats, duplication of information in different
files
– Difficulty in accessing data
• Need to write a new program to carry out each new task
– Data isolation — multiple files and formats
– Integrity problems
• Integrity constraints (e.g. account balance > 0) become
“buried” in program code rather than being stated explicitly
• Hard to add new constraints or change existing ones
 Purpose of Database Systems (Cont.)

• Drawbacks of using file systems (cont.)

– Atomicity of updates
• Failures may leave database in an inconsistent state with partial
updates carried out
• Example: Transfer of funds from one account to another should
either complete or not happen at all
– Concurrent access by multiple users
• Concurrent accessed needed for performance
• Uncontrolled concurrent accesses can lead to inconsistencies
– Example: Two people reading a balance and updating it at the
same time
– Security problems
• Hard to provide user access to some, but not all, data
• Database systems offer solutions to all the above problems
 Data Abstraction

• Data abstraction is a process of hiding the implement details

(such as how the data are stored and maintained) and
representing only the essential features to simplify user's
interaction with the system.
• The major purpose of a database system is to provide users
with an abstract view of the system.
• To simplify user's interaction with the system, the complexity
is hidden from the database users through several levels of
abstraction.
Physical Level
Logical / Conceptual Level:
View Level

13
 Data Abstraction

• Physical Level:
– Lowest level of abstraction.
– Describes how the data are stored.
– Complex low-level data structures described in detail.
– Ex:- B-trees, Hashing, indexing
• Logical / Conceptual Level:
– Next highest level of abstraction.
– Describes what data are stored and what relationships exit among those
data.
– Database administrator level.
• View Level:
– Highest level of abstraction.
– Describes only part of the database for a particular group of users.
– Can be many different views of a database.

14
 Levels of Abstraction

• Physical level: describes how a record (e.g., customer) is stored.

• Logical level: describes data stored in database, and the relationships
among the data.
type customer = record
customer_id : string;
customer_name : string;
customer_street : string;
customer_city : string;
end;
• View level: application programs hide details of data types. Views can
also hide information (such as an employee’s salary) for security
purposes.
Data Abstraction

16
 Database Schema and Instance
• Schema is the complete design of database. The names of tables, columns
of each table, datatype, triggers, functions views packages and other objects
are included in the schema.
• Instance :The data stored in database at a particular moment of time is
called instance of database.

17
 Database Schema and Instance
• Schema is the complete design of database. The names of tables, columns
of each table, datatype, triggers, functions views packages and other objects
are included in the schema.
• Instance :The data stored in database at a particular moment of time is
called instance of database.

18
 Data Models

A Database model defines the logical design and structure of a

database and defines how data will be stored, accessed and
updated in a database management system.

Relational Model is the most widely used database model,

there are other models too:
•Hierarchical Model
•Network Model
•Entity-relationship Model
•Relational Model

19
 Data Models-Hierarchical Model
•This database model organises data into a tree-like-structure, with a single
root, to which all the other data is linked. The hierarchy starts from
the Root data, and expands like a tree, adding child nodes to the parent
nodes.
•In this model, a child node will only have a single parent node.
•The main drawback of this model is that, it can have only one to many
relationships between nodes.

20
 Data Models-Network Model
•This is an extension of the Hierarchical model. In this model data is
organised more like a graph, and are allowed to have more than one parent
node.
•In this database model data is more related as more relationships are
established in this database model. Accessing the data is also easier and
fast. This database model was used to map many-to-many data
relationships.
•This was the most widely used database model, before Relational Model
was introduced.

DBMS by V.Srilakshmi, Asst.Professor, CSE 21

 Data Models-Entity Relationship Model
• An Entity–relationship model (ER model) describes the structure of a
database with the help of Entity Relationship Diagram (ER Diagram).
• An ER model is a design or blueprint of a database that can later be
implemented as a database. An ER diagram has three main components:
1. Entity 2. Attribute 3. Relationship
• In the diagram shown below:
▪ Entities - Student and College.
▪ Relationship - many to one as a college can have many students
▪ Student entity has attributes - Stu_Id, Stu_Name & Stu_Addr
▪ College entity has attributes such as Col_ID &Col_Name.

DBMS by V.Srilakshmi, Asst.Professor, CSE 22

 Data Models-Relational Model
• In this model, data is organised in two-dimensional tables and the
relationship is maintained by storing a common key
• This model was introduced by E.F Codd in 1970, and since then it has
been the most widely used database model
• Each table is a group of column and rows, where column represents
attribute of an entity and rows represents records.
• Tables are also known as relations in relational model.

DBMS by V.Srilakshmi, Asst.Professor, CSE 23

 Database Languages
• A DBMS has appropriate languages and interfaces to express database
queries and updates.
• Database languages can be used to read, store and update the data in the
database.

24
 Data Definition Language
• DDL stands for Data Definition Language. It is used to define
database structure or pattern.
• It is used to create schema, tables, indexes, constraints etc. in
the database.
• Using the DDL statements, we can create the skeleton of the
database.
• Data definition language is used to store the information of
metadata like the number of tables and schemas, their names,
indexes, columns in each table, constraints, etc.
• Tasks that come under DDL:
• Create: It is used to create objects in the database.
• Alter: It is used to alter the structure of the database.
• Drop: It is used to delete objects from the database.
• Truncate: It is used to remove all records from a table.
• Rename: It is used to rename an object.
25
 Data Manipulation Language
• DML stands for Data Manipulation Language. It is used for
accessing and manipulating data in a database. It handles user
requests.
• Here are some tasks that come under DML:
• Select: It is used to retrieve data from a database.
• Insert: It is used to insert data into a table.
• Update: It is used to update existing data within a table.
• Delete: It is used to delete one or all records from a table.
• Merge: It performs UPSERT operation, i.e., insert or
update operations.
• Call: It is used to call a structured query language or a
Java subprogram.

• Lock Table: It controls concurrency.

26
 Data Control Language

• DCL stands for Data Control Language. It is used to retrieve the

stored or saved data.
• The DCL execution is transactional. It also has rollback
parameters.
• Here are some tasks that come under DCL:
• Grant: It is used to give user access privileges to a database.
• Revoke: It is used to take back permissions from the user.

27
 Transaction Control Language

• TCL is used to run the changes made by the DML statement.

TCL can be grouped into a logical transaction.
• Here are some tasks that come under TCL:
• Commit: It is used to save the transaction on the database.
• Rollback: Rollback command is used to undo transactions
that have not already been saved to the database..
• SAVEPOINT: It is used to roll the transaction back to a certain
point without rolling back the entire transaction.

28
Database Users and Administrators

29
 Database Users and Administrators
• Database users are the persons who interact with the database and take the
benefits of database. They are differentiated into different types based on the
way they expect to interact with the system.
• Naive users: They are the unsophisticated users who interact with the
system by using permanent applications that already exist. Example:
Online Library Management System, ATMs (Automated Teller
Machine), etc.
• Application programmers: They are the computer professionals who
interact with system through DML. They write application programs.
• Sophisticated users: They interact with the system by writing SQL
queries directly through the query processor without writing application
programs.
• Specialized users: They are also sophisticated users who write
specialized database applications that do not fit into the traditional data
processing framework. Example: Expert System, Knowledge Based
System, etc.

30
 Database Users and Administrators

Database Administrators coordinate all the activities of the database

system. They have all the permissions.
Tasks of DBA :
• Creating the schema
• Changing the schema
• Specifying integrity constraints
• Storage structure and access method definition
• Granting permission to other users.
• Monitoring performance
• Routine Maintenance 31
Database System Structure

32
 Database System Structure
• The functional components of a database system can be
broadly divided into storage manager and query processor
– Query Processor : The query processor components include
• DDL interpreter, which interprets DDL statements and records
the definitions in the data dictionary.
• DML compiler, which translates DML statements in a query
language into an evaluation plan consisting of low-level
instructions that the query evaluation engine understands. The
DML compiler also performs query optimization, that is, it picks
the lowest cost evaluation plan from among the alternatives.
• Query evaluation engine, which executes low-level instructions
generated by the DML compiler.

33
 Database System Structure
• The functional components of a database system can be
broadly divided into storage manager and query processor
Query Processor : The query processor components include
–DDL interpreter, which interprets DDL statements and
records the definitions in the data dictionary.
–DML compiler, which translates DML statements in a query
language into an evaluation plan consisting of low-level
instructions that the query evaluation engine understands. The
DML compiler also performs query optimization, that is, it
picks the lowest cost evaluation plan from among the
alternatives.
–Query evaluation engine, which executes low-level
instructions generated by the DML compiler.

34
 Database System Structure
• Storage Manager: A storage manager is a program module that provides
the interface between the low level data stored in the database and the
application programs and queries submitted to the system. It is responsible
for storing, retrieving, and updating data in the database.
• The storage manager components include:
– Authorization and integrity manager, which tests for the satisfaction
of integrity constraints and checks the authority of users to access data.
– Transaction manager, which ensures that the database remains in a
consistent (correct) state despite system failures, and that concurrent
transaction executions proceed without conflicting.
– File manager, which manages the allocation of space on disk storage
and the data structures used to represent information stored on disk.
– ·Buffer manager, which is responsible for fetching data from disk
storage into main memory, and deciding what data to cache in main
memory

35
 Transaction Management
•A DATABASE TRANSACTION is a logical unit of processing in a
DBMS which entails one or more database access operation.
•All types of database access operation which are held between the
beginning and end transaction statements are considered as a single logical
transaction.
•During the transaction the database is inconsistent. Only once the database
is committed the state is changed from one consistent state to another.

36
 Entity Relationship Diagrams
• ER Diagram is a visual representation of data that describes how data is
related to each other.
• In ER Model, we disintegrate data into entities, attributes and setup
relationships between entities, all this can be represented visually using the
ER diagram.

37
 Entity Relationship Diagrams
• ER diagram has three main components:
1. Entity
2. Attribute
3. Relationship
• An entity is an object that exists and is distinguishable from other objects.
• An entity may be concrete (a person or a book, for example)
or abstract (like a holiday or a concept).
• An entity set is a set of entities of the same type (e.g., all persons having an
account at a bank).
• Entities are represented by means of rectangles.
• Attributes are the properties of entities. Attributes are represented by means
of ellipses.
• Relationships are represented by diamond-shaped box. Name of the
relationship is written inside the diamond-box. All the entities (rectangles)
participating in a relationship, are connected to it by a line.
38
 Entity in ER diagram
• There are two types of Entities:
– Strong entity
– Weak entity
• The strong entity has a primary key. Strong Entity is represented by a
single rectangle
• Weak entity do not have a primary key and are dependent on the parent
entity. It mainly depends on other entities. Weak Entity is represented by
double rectangle

39
 Attribute in ER diagram
• Attributes are the properties of entities. Attributes are represented by means
of ellipses. Attributes are the properties which define the entity type.
❑ Key attribute:- The attribute which uniquely identifies each entity in the
entity set is called key attribute. For example, Roll_No will be unique for
each student. In ER diagram, key attribute is represented by an oval with
underlying lines.
❑ Composite attribute:- An attribute composed of many other attribute is
called as composite attribute. For example, Address attribute of student
Entity type consists of Street, City, State, and Country. In ER diagram,
composite attribute is represented by an oval comprising of ovals.
❑ Multivalued Attribute:- An attribute consisting more than one value for
an entity. For example, Phone_No (can be more than one for a student).
In ER diagram, multivalued attribute is represented by double oval.
❑ Derived Attribute:- An attribute which can be derived from other
attributes of the entity type is known as derived attribute. e.g.; Age (can be
derived from DOB). In ER diagram, derived attribute is represented by
dashed oval.
40
Attributes in ER diagram

41
 Relationship in ER diagram
• Relationship: It is the association among entities. For example, an
employee works_at a department, a student enrolls in a course. Here,
Works_at and Enrolls are called relationships.
• Relationship Set: A set of relationships of similar type is called a
relationship set. Like entities, a relationship too can have attributes.
These attributes are called descriptive attributes.
• Types of relationships:-

42
 Extended ER Diagrams
Relationship symbols in ER diagrams

43
 Extended ER features
• As the complexity of data increased in the late 1980s, difficult to
use the traditional ER Model for database modelling. Hence
some improvements are made to handle the complex
applications better.
• Hence, as part of the Enhanced ER Model, along with other
improvements, three new concepts were added to the existing
ER Model, they were:
– Generalization
– Specialization
– Aggregration

44
 Generalization
• Generalization is a bottom-up approach in which two lower level entities
combine to form a higher level entity. For Example, STUDENT and
FACULTY can be generalized to a higher level entity called PERSON.
Common attributes like P_NAME, P_ADD become part of higher entity
(PERSON) and specialized attributes like S_FEE become part of
specialized entity (STUDENT).

45
 Specialization
• In specialization, an entity is divided into sub-entities based on their
characteristics.It is a top-down approach. For Example, EMPLOYEE entity
can be specialized into DEVELOPER, TESTER etc. Common attributes
like E_NAME, E_SAL etc. become part of higher entity (EMPLOYEE)
and specialized attributes like TES_TYPE become part of specialized entity
(TESTER).

46
 Aggregation
• An ER diagram is not capable of representing relationship between an entity and a
relationship which may be required in some scenarios. In such cases, a relationship
with its corresponding entities is aggregated into a higher level entity.
• For Example, Employee working for a project may require some machinery. So,
REQUIRE relationship is needed between relationship WORKS_FOR and entity
MACHINERY. Using aggregation, WORKS_FOR relationship with its entities
EMPLOYEE and PROJECT is aggregated into single entity and relationship
REQUIRE is created between aggregated entity and MACHINERY

47
 Conceptual Design Using the ER Model
❖ Design choices:
– Should a concept be modelled as an entity or an attribute?
– Should a concept be modelled as an entity or a relationship?
– Identifying relationships: Binary or ternary? Aggregation?
❖ Constraints in the ER Model:
– A lot of data semantics can (and should) be captured.
– But some constraints cannot be captured in ER diagrams.
❖ Need for further refining the schema:
– Relational schema obtained from ER diagram is a good first step.
But ER design subjective & can’t express certain constraints; so
this relational schema may need refinement.
48
 Entity vs. Attribute
❖ Should address be an attribute of Employees or an entity
(connected to Employees by a relationship)?
❖ Depends upon the use we want to make of address
information, and the semantics of the data:
◆ If we have several addresses per employee, address must be an
entity (since attributes cannot be set-valued).
◆ If the structure (city, street, etc.) is important, e.g., we want to
retrieve employees in a given city, address must be modelled
as an entity (since attribute values are atomic).

49
 Entity vs. Attribute (Contd.)
from to
name dname
❖ Works_In2 does not ssn lot did budget
allow an employee to
Employees Works_In2 Departments
work in a department for
two or more periods.
❖ Similar to the problem of
wanting to record several
addresses for an employee:
name dname
we want to ssn lot did budget
record several values of the
Employees Works_In3 Departments
descriptive attributes for
each instance of this
from Duration to
relationship.
50
 Entity vs. Relationship
❖ First ER diagram OK if
since dbudget
a manager gets a separate name dname
ssn did budget
discretionary budget for lot

each dept. Employees Manages2 Departments

❖What if a manager gets a
discretionary budget that
covers all managed name dname
depts? ssn lot did budget
– Redundancy of dbudget,
Employees Manages3 Departments
which is stored for each dept
managed by the manager.
since
– apptnum Mgr_Appts
Misleading: suggests dbudget
dbudget
tied to managed dept. 51
 Binary vs. Ternary Relationships
name
ssn p name age
lot
❖ If each policy is Employees Dependents
Covers
owned by just 1
employee: Bad design Policies
– Key constraint on
policyid cost
Policies would mean
policy can only cover name pna m age
ssn lot e
1 dependent!
Dependents
❖ What are the Employees
additional
Purchaser
constraints in the Beneficiary

2nd diagram?
Better design
Policies

policyid cost
19
 Binary vs. Ternary Relationships (Contd.)
CREATE TABLE Policies (
❖ The key policyid INTEGER, cost REAL,
constraints allow ssn CHAR(11) NOT NULL,
us to combine PRIMARY KEY (policyid).
Purchaser with FOREIGN KEY (ssn) REFERENCES Employees,
Policies and ON DELETE CASCADE)
Beneficiary with CREATE TABLE Dependents (
Dependents.
❖ Participation pname CHAR(20),
constraints lead to
NOT NULL age INTEGER,
policyid INTEGER ,
constraints. PRIMARY KEY (pname, policyid).
❖What if Policies is FOREIGN KEY (policyid) REFERENCES Policies,
a weak entity set? ON DELETE CASCADE)
53
 Binary vs. Ternary Relationships (Contd.)

❖ Previous example illustrated a case when 2 binary

relationships were better than a ternary relationship.
❖ An example in the other direction: a ternary relation
Contracts relates entity sets Parts, Departments and
Suppliers, and has descriptive attribute qty. No
combination of binary relationships is an adequate
substitute:
– S ``can-supply’’ P, D ``needs’’ P, and D ``deals-with’’ S does
not imply that D has agreed to buy P from S.
– How do we record qty?
54
 Logical Data Design
Logical DB Design: ER to Relational

■ Entity sets to tables. ssn name lot

123-22-3666 Attishoo 48
231-31-5368 Smiley 22
name
ssn lot 131-24-3650 Smethurst 35

Employees
CREATE TABLE Employees (ssn
CHAR(11),
name CHAR(20), lot INTEGER,
PRIMARY KEY (ssn))

Relationship Sets to Tables

CREATE TABLE Works_In( ssn
■ In translating a many-to-many relationship set to CHAR(1),
a relation, attributes of the relation must include: did INTEGER,
✔ Keys for each participating entity set since DATE,
PRIMARY KEY (ssn, did),
(as foreign keys).
✔ This set of FOREIGN KEY (ssn)
attributes forms a superkey REFERENCES
ssn Employees,
did since
for the relation. FOREIGN KEY
123-22-3666 (did) 51 1/1/91
✔All descriptive attributes. 123-22-3666 Departments)
REFERENCES 56 3/3/93
231-31-5368 51 2/2/92

55
 Review: Key Constraints
since
most one manager,
■Each dept has at name dname
according to the ssn lot did budget
key constraint on
Employees Manages Departments
Manages.

Alternative notation:
(0,N) left, (0, 1) right

1-to-1 1-to-Many Many-to-1 Many-to-Many

Translation to relational
model?

Translating ER Diagrams with Key Constraints

CREATE TABLE Manages( ssn CHAR(11),
did INTEGER,
since DATE, PRIMARY KEY (did),
■Map relationship set to a table: FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)
✔ Note that did is the key now!
✔ Separate tables for Employees andDept_Mgr(
CREATE TABLE Departments.
did INTEGER,
dname CHAR(20), budget REAL,
■Since each department has a unique
ssn manager,
CHAR(11), we could instead combine Manages and
Departments. since DATE, PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)

56
 Review: Participation Constraints
■ Does every department have a manager?
✔ If so, this is a participation constraint: the participation of Departments in Manages is said to be total
(vs. partial).
✔ Every did value in Departments table must appear in a row of the Manages table (with a non-null
ssn value!)

since
name dname
ssn
lot did budget

Employees Departments
Manages
Works_In since

Review: Participation Constraints

■ Does every department have a manager?
✔ If so, this is a participation constraint: the participation of Departments in Manages is said to be total
(vs. partial).
✔ Every did value in Departments table must appear in a row of the Manages table (with a non-null
ssn value!)

since
Employees (0,N) name dname (1,1) Departments
Manages
ssn
(1,N) lot did budget
Works_In (1,N)

since

57
 Participation Constraints in SQL
■We can capture participation constraints involving one entity
set in a binary relationship, but little else (without resorting to
CHECK constraints).
CREATE TABLE Dept_Mgr( did INTEGER,
dname CHAR(20), budget REAL,
ssn CHAR(11) NOT NULL,
since DATE, PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
)

Review: Weak Entities

■A weak entity can be identified uniquely only by considering the primary key of
another (owner) entity.
✔ Owner entity set and weak entity set must participate in a one-to- many
relationship set (1 owner, many weak entities).
✔ Weak entity set must have total participation in this identifying
relationship set. name
ssn lot cost pname age

Employees Policy Dependents

58
 Translating Weak Entity Sets
■Weak entity set and identifying relationship set are translated into a
single table.
✔ When the owner entity is deleted, all owned weak entities must also be deleted.
CREATE TABLE Dep_Policy ( pname CHAR(20),
age INTEGER,
cost REAL,
ssn CHAR(11) NOT NULL,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)

Review: ISA Hierarchies ssn

name
lot

Attributes are inherited Employees

hourly_wages hours_worked
From superclass ISA
contractid

Hourly_Emps Contract_Emps

■ Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
■ Covering constraints: Does every Employees entity also have to be
an Hourly_Emps or a Contract_Emps entity? (Yes/no)

59
 Translating ISA Hierarchies to Relations

■General approach:
✔ 3 relations: Employees, Hourly_Emps and Contract_Emps.
✔ Hourly_Emps: Every employee is recorded in Employees. For
hourly emps, extra info recorded in Hourly_Emps (hourly_wages,
hours_worked, ssn); must delete Hourly_Emps tuple if referenced
Employees tuple is deleted).
✔ Queries involving all employees easy, those involving just
Hourly_Emps require a join to get some attributes.
■Alternative: Just Hourly_Emps and Contract_Emps.
✔ Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
✔ Each employee must be in one of these two subclasses.

Review: Binary vs.

■ If each policy is Employees
Ternary Rel’nships
Dependents
Covers
owned by just 1 Bad design Policies
name
✔ K e
employee: y policyidssn lot cost pname
age
constraint
P o l i c ione s ssn
name
lot
pname age
Dependents
would mean Employees
policy can only Purchaser Beneficiary
cover 1
Better design Policies
dependent!
policyid

60
Database Management Systems
Steps to create ER Diagram

61
Steps to create ER Diagram

62
 Example

In a university, a Student enrolls in Courses. A

student must be assigned to at least one or more
Courses. Each course is taught by a single
Professor. To maintain instruction quality, a
Professor can deliver only one course.

63
 Step-1
• Entity Identification
We have three entities
•Student
•Course
•Professor

64
 Step-2
Relationship Identification

We have the following two relationships

The student is assigned a course
Professor delivers a course

65
 Step-3
Cardinality Identification

A student can be assigned multiple courses

A Professor can deliver only one course

66
 Step-4
• Identify Attributes

Entity Primary Key Attribute

Student Student_ID StudentName

Professor Employee_ID ProfessorName

Course Course_ID CourseName

67
 Step-5
• Create the ERD

68