DBMS Basic

Concepts

1
 DBMS
• Database Management System
• Term Database requires understanding of
data and information
• Data: It can be anything like name, place or
number, etc. Data usually refers to raw data, or
unprocessed data.

• Information: It is organized or classified data so

that it has some meaningful values to the receiver.
– Information is the processed data on which decisions
and actions are based.

2
Difference between Data
and Information?

3
 Data Information
Data is raw facts and figures Information is a processed form of data

For example: 12 is data For example: When 12 is stored in row

column form as shown it is information.
Age 12

Data are atomic level pieces of Information is a collection of data

information

Data does not help in decision making Information helps in decision making

4
 Database
• A database is a shared collection of logically
related data designed to meet the information
needs of an organization
• The related information when placed is an
organized form makes a database.
• The organization of data/information is
necessary because unorganized information
has no meaning.

5
Example
 Database Management System
• DBMS A database management system is the
software system that allows users to define,
create and maintain a database and provides
controlled access to the data.
• A database management system (DBMS) is
basically a collection of programs that enables
users to store, modify, and extract information
from a database as per the requirements.

12
 Operations on databases
• To add new information
• To view or retrieve the stored information
• To modify or edit the existing
• To remove or delete the
unwanted information
• Arranging the information in a desired
order etc.

14
 Components of Database
• Five major components in database system
environment:
– Hardware
– Software
– Data
– Users
– Procedures

15
 Components of Database System
• Hardware: It is the actual computer system
used for keeping and accessing the database.
DBMS hardware consists of secondary storage
devices like hard disks.
• Software: It is the actual DBMS. Between the
physical database itself and the users of
system is a layer of software, called DBMS.
• Data: Data acts as the bridge between the
machine components and user components.

16
 Components of Database System
• Users: There are number of users who can
access or retrieve data on demand using the
applications and the interfaces provided by
DBMS. The users can be:
– Naïve users
– Online users
– Application Programmers
– Sophisticated Users
– Data base Administrator ( DBA)

17
 Components of Database System
• Procedures: It refers to the instructions and
rules that govern the design and the use of
the database. The users of the system and the
staff that manage the database requires
documented procedures on how to use or run
the system.

18
 Applications of DBMS
• Banking: all transactions
• Airlines: reservations, schedules
• Universities: registration, grades
• Sales: customers, products, purchases
• Online retailers: order customized
tracking, recommendations
• Manufacturing: production, inventory,
orders, supply chain
• Human resources: employee records, salaries, tax
deductions
19
Schemas and Instances
• Data model:-A set of concepts to describe the
structure of a database, and certain
constraints that the database should obey.
• Schema:- The overall description of the
database is called the Database Schema.
– A schema is defined as an outline or a plan that
describes the records and relationships existing at
the particular level.
• Instance:- Data in the database at a particular
moment in time.
20
 Data abstraction
• A major purpose of database system is to
provide user with an abstract view of data.
That is, system hides certain details of how
the data are stored and maintained.

24
Levels of Abstraction(view of data)
• Physical level: describes how a record (e.g.,
customer) is stored.
• Logical level: describes what data stored in
database, and the relationships among the data.
DBA, who decides what information to keep in
the database, use the logical level of abstraction.
• View level: describe only part of database.
application programs hide details of data types.
Complexity remain due to variety of information
stored. Views can also hide information (such as
an employee’s salary) for security purposes.
25
View of Data

An architecture for a database system

27
 Data Independence
• Logical Data Independence: The capacity to
change the conceptual schema without having
to change the external schemas and their
application programs.
• Physical Data Independence: The capacity to
change the internal schema without having to
change the conceptual schema.

28
 Data Independence
• The processes of transforming requests and
results between the levels are called mappings.
• When a schema at a lower level is changed, only
the mappings between this schema and higher-
level schemas need to be changed in a DBMS that
fully supports data independence. The higher-
level schemas themselves are unchanged. Hence,
the application programs need not be changed
since they refer to the external schemas.

30
 Data Independence
• The processes of transforming requests and
results between the levels are called mappings.
• When a schema at a lower level is changed, only
the mappings between this schema and higher-
level schemas need to be changed in a DBMS that
fully supports data independence. The higher-
level schemas themselves are unchanged. Hence,
the application programs need not be changed
since they refer to the external schemas.

31
Database Architecture

32
Three-tier architecture

40
• External or View level: It is the users’ view of the
database. This level describes that part of the database
that is relevant to each user.
– For example, one user may view dates in the form (day,
month, year), while another may view dates as (year,
month, day).
• Conceptual or logical level: It is the community view of
the database. This level describes what data is stored
in the database and the relationships among the data.
• It represents:
– All entities, their attributes, and their relationships;
– The constraints on the data;
– Security and integrity information.
• Internal or storage level: It is the physical
representation of the database on the computer. This
level describes how the data is stored in the database.
41
 Database Languages
Database languages are used to create and maintain database
on computer.
• Data Definition Language(DDL): It is a language that allows user to
define data and their relationship to other types of data.
– CREATE
– ALTER
– DROP
– TRUNCATE
– RENAME
• Data Manipulation Language(DML):It provides a set of operations
to support the basic data manipulation operations on the data held
in databases. It allows user to insert, update, delete and retrieve
data from the database.
– DELETE
– INSERT
– SELECT
– UPDATE
44
 Database Languages
• Data Control Language(DCL): DCL statements control
access to data and the database
– GRANT
– REVOKE
– COMMENT
• Transaction Control Language(TCL): TCL statements
manage the change made by DML statements, and
group DML statements into transactions
– COMMIT
– ROLLBACK
– SAVEPOINT
– SET TRANSACTION

45
 Structure and
Components of DBMS

46
Data Models

54
Data Model

55
72
Why it is imp

73
74
75
76
77
78
79
80
81
82
83
84
85
An ER Diagram consists of the
following components:
1.Entity
2.Attributes
3.Relationships

86
Entity
An entity may be an object, place, person, or an event which stores
data in the database. In an entity-relationship diagram, an entity is
represented by a rectangle. Student, course, manager, employee,
patient, etc. are examples of an entity.
E-R Model:
Symbols and
notations
 Constraints
• Various types of constraints are:
1. Mapping cardinalities
2. Participation constraints
3. Keys

10
 Mapping Cardinalities
• Mapping cardinality or cardinality ratios ,
express the number of entities to which
another entity be associated via a
relationship
canset
• Mapping cardinalities:
– one to one
– one to many
– many to one
– many to many

10
• One-to-one: one entity from entity set A can be
associated with at most one entity of entity set B and
vice versa.

• One-to-many: One entity from entity set A can be

associated more than one entities of entity set B but
from entity set B one entity can be associated with at
most one entity.

10
• Many-to-one: More than one entities from entity set A
can be associated with at most one entity of entity set B
but one entity from entity set B can be associated with
more than one entity from entity set A.

• Many-to-many: one entity from A can be associated with

more than one entity from B and vice versa.

10
 Participation Constraints
• The participation of an entity set E in a
relationship set R is said to be total if every
entity in E participates in at least one
relationship in R.
• If only some entities in E participate in
relationships in R, the participation is said to
be partial.

10
 Example

Total participation of Loan entity

10
 Key
s
• The key is defined as the column or attribute
of the database table.
• They are used to establish and
identify relation between tables.
• They also ensure that each record within
a
table can be uniquely identified by
combination of one or more fields a
within table.

10
 Types of Keys
1. Superkey: An attribute (or combination of
attributes) that uniquely identifies each row in a
table. It is a super set of candidate key.
2. Candidate key : An attribute (or set of
attributes) that uniquely identifies a row. Let K
be a set of attributes of relation R. Then K is a
candidate key for R if it possess the following
properties:
1. Uniqueness – No legal value of R ever contains two
distinct tuples with the same value of K
2. Irreducibility- No proper subset of K has the
uniqueness property

10
 Types of Keys
3. Primary key : is the candidate key which is
selected as the principal unique identifier. It is a
key that uniquely identify each record in the
table. Cannot contain null entries.

10
 Types of Keys
4. Composite Key: Key that consist of two or
more attributes that uniquely identifies an
entity occurrence is called composite key.

Reg_no Crs_id subjects

11
 Types of Keys
5. Foreign Key: A foreign key is generally a
primary key from one table that appears as a
field in another where the first table has a
relationship to the second.
In other words, if we had a table A with a
primary key X that linked to a table B where X
was a field in B, then X would be a foreign key in
B.

11
Example

11
 Steps in designing E-R Diagram
• There are following steps:
– Identify the entities from the requirement sheets
– Find relationships among those entities
– Identify the key attributes for every entity
– Identify other relevant attributes
– Draw complete E-R diagram with all attributes
including Primary key
– Review your results with your Business users

11
Example: University Management
System

11
 Strong and Weak entity sets
• The entity set which does not have sufficient attributes
to form a primary key is called a Weak entity set.
• The entity set which has the primary key is called as
Strong entity set.
• A member of a strong entity set is called dominant
entity and member of a weak entity set is called
subordinate entity.
• Weak entity does not have a primary key but we need
a mean to distinguish among other entities. The
discriminator of a weak entity set is a set of attributes
that allows this distinction to be made. Ex:
payment_number.

11
Example

11
Example

11
E-R Diagram

11
 Roles
• Entity sets of a relationship need not be distinct
• The labels “manager” and “worker” are called roles; they specify
how employee entities interact via the works_for relationship set.
• Roles are indicated in E-R diagrams by labeling the lines
that connect diamonds to rectangles.
• Role labels are optional, and are used to clarify semantics of the
relationship

11
 Removing Redundant attributes in
entity set
• Once the entities and their corresponding attributes
are chosen, the relationship sets among the various
entities are formed.
• These relationship sets may result in a situation where
attributes in the various entity sets are redundant and
need to be removed .
• Consider the entity sets instructor and department
– Instructor includes the attributes ID, name,
dept_name, and salary with ID as primary key
– Department includes the attributes dept_name, building,
and budget with dept_name as primary key

12
 Removing Redundant attributes in
entity set
• Attribute dept_name appears in both entity sets. It is
primary key for entity department, it is redundant in
the entity set instructor and needs to be removed.
• If both entities have one to one relationship then we
can remove it from instructor table as it will get added
up in the relational schema of department.
• But if an instructor has more than one associated
department, the relationship between the entities is
recorded in a separate relation inst_dept

12
 Reduction to relational schema
• Both E-R model and relational database model
are abstract, logical representations of real-world
enterprises.
• Because the two models employ similar design
we can convert an E-R design to relational design
• E-R schema can be represented by relation
schema in following ways:
– Representin of strong entity sets with
g Attributes Simple
– Representin
g Attributes of strong entity sets with Complex
– Representation of weak entity sets
– Representation of relationship sets
12
Representing of strong entity sets with Simple
Attributes

• A strong entity set reduces to a table with the

same attributes as represented in E-R diagram

12
 Representing of strong entity sets with
Complex Attributes

• In order to convert an entity having composite

attributes, the composite attributes are
flattened out by creating a separate attribute
for each component attribute.

12
• Multivalued attributes are treated differently
from other attributes. New relation schemas
are created for these attributes.
• Derived attributes are not explicitly
represented in the relational model.

BOOK entity set with author_id as multi-value attribute

12
12
 Representation of weak entity sets

• For schemas derived from a weak entity set,

the combination of the primary key of the
strong entity set and the discriminator of the
weak entity set serves as primary key of the
schema.
payment = ( loan_number, payment_number,
payment_date, payment_amount )

12
12
 Representation of relationship sets

• There are different strategies used for each

type of relationship.
1. Conversion of many to many relationship to
relational model:
– A many to many relationship set is represented as
a table with columns for the primary keys of the
two participating entity sets, and the descriptive
attributes of the relationship set.

12
13
2. Conversion of one to many relationship to
relational model:
For one to many or many to one relationship,
there is no need to create the separate table for the
relationship. Copy the primary key of entity set on one
side of relationship into the entity set on “many” side
of relationship.

13
Customer and Loan relationship with 1:M type 74
133
3. Conversion of one to one relationship to
relational model:
• In case of 1:1 relationship, there is no need to
create a separate table for relationship and
the primary key of any entity set can be
moved to other side depending upon the
requirement. It is preferable to copy the
primary key of non-totally participated
entity set towards totally participated entity
set.
134
 Design Issues
• There are number of different ways to define
set of entities and relationship among them.
We examine basic issues in the design of an E-
R model. These are:
– Use of entity sets vs. attributes
– Use of entity sets vs. relationship sets
– Binary versus n-ary relationship sets
– Placement of relationship attributes

135
 Design Issues: Use of entity sets vs.
attributes
• Treating telephone as an attribute telephone-number implies that
employees have exactly one telephone number each
• Treating telephone as an entity permits employees to have several
telephone numbers associated with them.
• The distinctions to consider an object as attribute or entity
depends
on the structure of real-world enterprise being modeled.

136
Design Issues: Use of entity sets vs. relationship sets
• Each loan is represented by a relationship between a customer and
a branch, if every loan is associated with exactly one customer and
is associated with exactly one branch
• If several customers hold a joint loan then, loan should be
considered as an entity

137
The guideline in determining whether to use an entity set or
a relationship set is to designate a relationship set to
describe an action that occurs between entities
138
 Design Issues: Binary versus n-ary
relationship sets

• Although it is possible to replace any nonbinary (n-ary, for n >

2) relationship set by a number of distinct binary relationship
sets, a n-ary relationship set shows more clearly that several
entities participate in a single relationship.

139
• There is one advantage of using binary relationship, with this it is
possible to store partial information but in ternary relationship it
is not possible to represent it.
• But there are some relationships that are naturally non-binary.

140
 Design Issues: Placement of relationship
attributes
• The cardinality ratio of a relationship can affect the
placement of relationship attributes
• Example: Let us take two entities instructor and student
with relationship advisor, if we want to add attribute date
( which specifies when the instructor became advisor)
• If relationship is one to many then the date must be placed
to the entity set on the “many” side of relationship
• For one to one relationship, it could be placed on either
side
• For many to many relationship, the date must be placed as
the relationship attribute
141