VLB JANAKIAMMAL COLLEGE OF ENGINEERING

AND TECHNOLOGY
 Course Objectives

• To introduce basic DBMS concepts

• To introduce basic RDBMS concepts
• To create familiarity with SQL
• To introduce the concept of transaction processing and
discuss certain issues in the same.
 Data Processing

• Data collection
• Recording
• Sorting
• Classifying
• Calculating
• Storing & retrieving
• Summarizing
• Communicating
 Data Processing modes

• Batch processing:
Transactions are collected in a group & processed
together.
• On-line (interactive) processing:
Transactions are processed as & when they appear.
• Real-time processing:
It is a parallel time relationship with on-going activity &
the information produced is useful in controlling the
current/dynamic activity.
 Traditional Method of Storage
• In the traditional approach, we used to store information in flat files which
are maintained by the file system under the operating system’s control.

• Application programs go through the file system to access these flat files

• Data used to be stored in the form of records in the files.

• Records consist of various fields which are delimited by a space ,

comma , tab etc.

• There used to be special characters to mark end of records and end of

files.
Problems in traditional approach
DATA
DEPENDENCY

LOSS OF
FLEXIBILITY MULTIPLE FILES

REDUNDANCY UPDATE PROBLEM

INCONSISTENCY
 The Database Technology
• Database
 Computer based record-keeping system
 Collection of interrelated (persistent) data
Database Management System
• Collection of files that contain related data Managed by
a specialized piece of software known as a Database
Management System (DBMS)

• Layer of abstraction between the application programs

and the file system

• Application programs request the DBMS to retrieve,

modify, insert or delete data for them
Three-layer Architecture
 Services provided by a DBMS

• Data management
• Data definition
• Transaction support
• Concurrency control
• Recovery
• Security & integrity
• Utilities- facilities like data import & export, user
management, backup, performance
analysis, logging & audit, physical storage
control
 Advantages of a DBMS

• Data independence
• Reduction in data redundancy
• Better security
• Better flexibility
• Effective data sharing
 Users of a DBMS

• Database Administrator (DBA)

 Managing information contents
 Liaison(link) with users
 Enforcing security and integrity rules
 Strategizing backup & recovery
 Monitoring performance
• Database designers
• Application Programmers
• End users
 Database Technologies

• Hierarchical Model
• Network Model
• Relational Model
• Object-Oriented
 Relational Model Basics
• Data is viewed as existing in two dimensional tables known as
relations

• A relation (table) consists of unique attributes (columns) and tuples

(rows)

• Tuples are unique

• Sometimes the value to be inserted into a particular cell may be

unknown, or it may have no value. This is represented by a null

• Null is not the same as zero, blank or an empty string

RDBMS
A DBMS that manages the relational database.

Relational Database
Any database whose logical organization is
based on relational data model.
 Keys

• Super key
An attribute, or group of attributes, that is sufficient to distinguish every
tuple in the relation from every other one.
• Candidate key
Each super key is called a candidate key
• Primary key
The candidate key that is chosen to perform the identification task is
called the primary key
• Foreign key
A foreign key is a “copy” of a primary key that has been exported from
one relation into another to represent the existence of a relationship
between them.
 Data modeling

• Study of basic properties and inter-relationships among

data items to properly represent them in the basic data
structures of a database

• Two popular techniques:

ER modeling and Normalization
Design levels of a database

Conceptual design

Logical design

Physical database design

Conceptual design – designed with the help
of requirements gathered and developed using
ER modeling
Logical design – designed based on the
implementations of databases & relations using
DBMS
Physical database design – building tables
and storing data fields
 ER modeling

• ER modeling :
A graphical technique for understanding and organizing the data
independent of the actual database implementation
• Entity:
Any thing that may have an independent existence and about
which we intend to collect data.
Also known as Entity type.
• Entity instance:
a particular member of the entity type e.g. a particular student
• Attributes:
Properties/characteristics that describe entities
• Relationships:
Associations between entities
 Attributes

• domain of the attribute

The set of possible values for an attribute is called the domain of
the attribute
• Example:
 The domain of attribute marital status is just the four values: single,
married, divorced, widowed
 The domain of the attribute month is the twelve values ranging from
January to December
• Key attribute:
 The attribute (or combination of attributes) that is unique for every
entity instance
 E.g the account number of an account, the employee id of an
employee etc.
• composite key
If the key consists of two or more attributes in combination, it is
called composite key
 Simple Vs composite attribute

• Simple attribute:
 cannot be divided into simpler components
 E.g age of an employee
• Composite attribute:
 can be split into components
 E.g Date of joining of the employee.
 Can be split into day, month and year
 Single Vs Multi-valued Attributes

• Single valued :
 can take on only a single value for each entity instance
 E.g. age of employee. There can be only one value for this
• Multi-valued:
 can take many values
 E.g. skill set of employee
 Stored Vs Derived attribute

• Stored Attribute:
 Attribute that need to be stored permanently.
 E.g. name of an employee
• Derived Attribute:
 Attribute that can be calculated based on other attributes
 E.g. : years of service of employee can be calculated from
date of joining and current date
 Regular Vs. Weak entity type

• Regular Entity:
 Entity that has its own key attribute.
 E.g.: Employee, student ,customer, policy holder etc.
• Weak entity:
 Entity that depends on other entity for its existence and
doesn’t have key attribute of its own
 E.g. : spouse of employee
 The spouse data is identified with the help of the employee
id to which it is related
 Relationships

• A relationship type between two entity types defines the set of all
associations between these entity types

• Each instance of the relationship between members of these entity

types is called a relationship instance

Example:
If Works-for is the relationship between the employee entity and the
department entity, then Ram works for Comp.sc department,
shyam works –for electrical department ..etc are relationship
instances of the relationship, works-for
 Degree of a Relationship

• Degree: the number of entity types involved

 One Unary
 Two Binary
 Three Ternary

E.g employee manager-of employee is unary

employee works-for department is binary
customer purchase item, shop keeper is a ternary
relationship
 Cardinality

• Relationships can have different connectivity

 one-to-one (1:1)
 one-to-many (1:N)
 many-to-many (M:N)

Example

 employee head-of department (1:1)

 student enrolls course (m:n)
 lecturer offers course (1:n) assuming a course is taught by a
single lecturer
The minimum and maximum values of this connectivity is called
the cardinality of the relationship
 Relationship Participation

• Total : Every entity instance must be connected through

the relationship to another instance of the other
participating entity types
• Partial: All instances need not participate
E.g Employee Head-of Department
Employee: partial
Department: total
Entity
Attributes
Key attribute
Multivalued Attribute
Composite attribute
Relationship
Unary Relationship
Role names
Binary Relationship
Ternary Relationship
1:1 relationship
1:m relationship
M:1 relationship
M:N relationship
Relationship participation
Attributes of a Relationship
Weak entity
 Logical database design

• Converting ER diagrams to relational schema

• Logical database design
Process of converting the conceptual model into an
equivalent representation in the implementation model
(relational/hierarchic/network etc.)
We will focus on the relational model
• Relational database design
Convert ER model into relational schema (a specification
of the table definitions and their foreign key links)
There are well defined rules for this conversion
 Converting
ER diagrams to relational schema
• Each entity type becomes a table
• Each single-valued attribute becomes a column
• Derived attributes are ignored
• Composite attributes are represented by components
• Multi-valued attributes are represented by a separate
table
• The key attribute of the entity type becomes the primary
key of the table
• Weak entity types are converted into a table of their own,
with the primary key of the strong entity acting as a
foreign key in the table
 Summary

• The file based approach has problems of redundancy, inconsistency

etc
• The Database model consists of three layers
• RDBMS handles data in the form of relations, tuples and fields
• Keys identify tuples uniquely
• ER modeling is a diagrammatic representation of the conceptual
design of a database
• Entity types represent things
• Entity type could be strong or weak
• Attributes represent characteristics.
• Attributes can be simple/composite, single valued/multivalued,
stored/derived
• Relationship types represent collaboration between entity types.
• Relationships could be unary/binary/ternary.
• Cardinality of relationships could be 1:1, 1:M, N:M
 Case study

A banking scenario
• Banks have customers.
• Customers are identified by name, custid, phone number and address.
• Customers can have one or more accounts
• Accounts are identified by an account number, account type (savings, current)
and a balance.
• Customers can avail loans.
• Loans are identified by loan id, loan type (car, home, personal)
• and an amount.
• Banks are identified by a name, code and the address of the main office.
• Banks have branches.
• Branches are identified by a branch number, branch name and an address.
• Accounts and loans are related to the banks’ branches.
• Create an ER diagram for a database to represent this application
Note: The solution that follows is just a sample and not the only solution