DATABASE MANAGEMENT SYSTEM (DBMS)

Data?
collection of information, statistical values, could be facts and
figures, just numbers and any type of record.

Eg., Details of your friend – like name, address, DOB, email i.d
etc.,
Difference between Data and Datum.

Data – plural
Datum - singular
 DATABASE
Collection of related data.

DATABASE MANAGEMENT SYSTEM

Software to manage the database

Eg., SQL server, My SQL etc.,

Primary Goals of DBMS

To provide a convenient and efficient usage environment

To maintain data in a structured manner

Fast retrieval on demand

Easy access to the data stored

Capability to share
DBMS - Action

 Define
 Construct
 Manipulating

Define a database : in terms of data types, structures

and constraints

Construct or Load the Database on a secondary storage

medium

Manipulating the database : querying, generating reports,

insertions, deletions and modifications to its content
Purpose of Database System

•In the early days, database applications were built 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 part of
program code
Hard to add new constraints or change existing ones
Purpose of Database System(Cont.)

Drawbacks of using file systems

Atomicity of updates
Failures may leave database in an inconsistent state with partial
updates carried out
E.g. transfer of funds from one account to another should either
complete or not happen at all

Concurrent access by multiple users

Concurrent access is needed for performance
Uncontrolled concurrent accesses can lead to inconsistencies
E.g. two people reading a balance and updating it at the same time

Security problems
Not every user of the database system should be able to access all
the data.
E.g. In a banking system payroll personnel need to see only that part of the
data base that has information about the various bank employees. They do not need
access to information about customer accounts.
Database systems offer solutions to all the above
problems
Difference between DBMS and File processing system

DBMS File-processing Systems

1. Redundancies and 1. Redundancies and
inconsistencies in data are inconsistencies in data exist
reduced due to single file due to single file formats and
formats and duplication of duplication of data.
data is eliminated.
2. Data is easily accessed due 2. Data cannot be easily
to standard query procedures. accessed due to special
application programs needed
to access data.
Difference between DBMS and File processing system

DBMS File-processing Systems

3. Isolation/retrieval of 3. Data isolation is difficult
required data is possible due due to different file formats,
to common file format, and and also because new
there are provisions to easily application programs have to
retrieve data. be written.

4. Integrity constraints, 4. Introduction of integrity

whether new or old, can be constraints is tedious and
created or modified as per again new application
need. programs have to be written.
Difference between DBMS and File processing system
DBMS File-processing Systems
5. Several users can access 5. Concurrent accesses may
data at the same time i.e. cause problems such as
concurrently without inconsistencies.
problems.

6. Security features can be 6. It may be difficult to

enabled in DBMS very enforce security features.
easily.
Main Characteristics of the Database approach

Self-describing nature of a database system:

A DBMS catalog stores the description of the
database. The description is called meta-data).
This allows the DBMS software to work with
different databases.
Insulation between programs and data:
Also called program-data independence. Allows
changing data storage structures and operations
without having to change the DBMS access
programs.
Main Characteristics of the Database approach

Data Abstraction:
A data model is used to hide storage details and
present the users with a conceptual view of the
database.

Support of multiple views of the data:

Each user may see a different view of the database, which
describes only the data of interest to that user.
Main Characteristics of the Database approach

Sharing of data and multiuser transaction processing :

Allowing a set of concurrent users to retrieve and to update the

database. Concurrency control within the DBMS guarantees

that each transaction is correctly executed or completely

aborted. OLTP (Online Transaction Processing) is a major part

of database applications.
Advantages of Using the database

Controlling redundancy

Restricting unauthorized access to data.

Providing persistent storage for program

Objects
Advantages of Using the database

Providing backup and recovery services.

Providing multiple interfaces to different classes

of users.

Representing complex relationships among data.

Enforcing integrity constraints on the database.

Disadvantages of Using the database

Disadvantages
1. Database systems are complex, difficult, and
time-consuming to design
2. Substantial hardware and software start-up
costs
3. Damage to database affects virtually all
applications programs
4. Extensive conversion costs in moving form a
file-based system to a database system
5. Initial training required for all programmers
and users
When not to use a DBMS

DBMS may be unnecessary:

If the database and applications are simple, well

defined, and not expected to change.
 View of Data:

 A major purpose of a database system is to

provide users with an abstract view of the data.
 Data Abstraction
Since many database systems users are not
computer trained, Developers hide the complexity
through several layers of Abstraction, to simplify
users’ interactions with the system.
 Three are three levels of abstraction namely
Physical, Logical and view level
 View of Data:

 Physical level - The lowest level of abstraction

describes how the data are actually stored. At
physical level complex low-level data structures are
described in detail

Logical level – This is the next-higher level of

abstraction describes what data are stored in the
database, and what relationships exist among those
data.
View of Data:
An architecture for a
database system

 View level – Highest level of abstraction of the

data base describes only part of the entire database
here users needs to access only a part of the
database. So that their interaction with the system
is simplified. The stem may provide many views of
the same database
Data Independence

The ability to modify a schema definition in one level without

affecting a schema definition in the next higher level is
called Data Independence
There are two levels of Data independence
Physical data independence is the ability to modify the
physical schema without causing application programs to be
rewritten
Logical data independence is the ability to modify the logical
schema without causing application programs to be
rewritten.
Modifications at the logical level are necessary when ever
the logical structure of the data are is altered
 Instances and Schemas
• Similar to types and variables in programming languages
• Schema – the logical structure of the database
– e.g., the database consists of information about a set of customers and accounts and the
relationship between them)
– Analogous to type information of a variable in a program
– Physical schema: database design at the physical level
– Logical schema: database design at the logical level
• Instance – the actual content of the database at a particular point in time
– Analogous to the value of a variable
• Physical Data Independence – the ability to modify the physical schema without
changing the logical schema
– Applications depend on the logical schema
– In general, the interfaces between the various levels and components should be well
defined so that changes in some parts do not seriously influence others.
Data models are a collection of conceptual tools for describing data, data
relationships, data semantics and data constraints. There are three different
groups:
Object-based Logical Models.
Record-based Logical Models.
Physical Data Models.

Object-based Logical Models

Object-based logical models:
Describe data at the conceptual and view levels.
Provide fairly flexible structuring capabilities.
Allow one to specify data constraints explicitly.
E.g.: E-R Model, Object Oriented Model
Data Models
 A collection of tools for describing
data
data relationships
data semantics
data constraints
 Entity-Relationship model
 Relational model
 Other models:
object-oriented model
semi-structured data models
Older models: network model and hierarchical model
 Entity-Relationship Model
Example of schema in the entity-relationship model

The entity-relationship data model is based on a perception of real world that

consists of a collection of basic objects called entities, and of relationships among
these objects.
Overall logical structure of a database can be expressed graphically by an ER
diagram, which is built up from the following components
• Rectangles. which represent entity sets
• Eclipses. which represent attributes
• Diamonds. which represent relationships among entity sets
• Lines. which link attributes to entity sets and entity sets to relationships
• E-R model of real world
– Entities (objects)
• E.g. customers, accounts, bank branch
– Relationships between entities
• E.g. Account A-101 is held by customer Johnson
• Relationship set depositor associates customers with accounts
• Widely used for database design
– Database design in E-R model usually converted to design in the
relational model which is used for storage and processing
Relational Model
 Example of tabular data in the relational model Attributes

Customer-id customer- customer- customer- account-

name street city number
192-83-7465 Johnson Alma Palo Alto A-101
019-28-3746 Smith North Rye A-215
192-83-7465 Johnson Alma Palo Alto A-201
321-12-3123 Jones Main Harrison A-217
019-28-3746 Smith North Rye A-201
A Sample Relational Database
Data Definition Language (DDL)

 Specification notation for defining the database schema

 E.g.
create table account (
account-number char(10),
balance integer)
 DDL compiler generates a set of tables stored in a data dictionary
 Data dictionary contains metadata (i.e., data about data)
 database schema

 Data storage and definition language

 language in which the storage structure and access methods used

by the database system are specified
 Usually an extension of the data definition language
Data Manipulation Language (DML)

 Language for accessing and manipulating the data organized

by the appropriate data model
 DML also known as query language

 Two classes of languages

 Procedural – user specifies what data is required and
how to get those data
 Nonprocedural – user specifies what data is required
without specifying how to get those data
 SQL is the most widely used query language
SQL

 SQL: widely used non-procedural language

 E.g. find the name of the customer with customer-id 192-83-7465
select customer.customer-name
from customer
where customer.customer-id = ‘192-83-7465’
 E.g. find the balances of all accounts held by the customer with
customer-id 192-83-7465
select account.balance
from depositor, account
where depositor.customer-id = ‘192-83-7465’ and
depositor.account-number = account.account-number
 Application programs generally access databases through one of
 Language extensions to allow embedded SQL
 Application program interface (e.g. ODBC/JDBC) which allow SQL
queries to be sent to a database
Transaction Management

 A transaction is a collection of operations that performs a

single logical function in a database application
 Transaction-management component ensures that the
database remains in a consistent (correct) state despite
system failures (e.g., power failures and operating system
crashes) and transaction failures.
 Concurrency-control manager controls the interaction among
the concurrent transactions, to ensure the consistency of the
database.
Storage Management

 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.

 The storage manager is responsible to the following

tasks:
 interaction with the file manager
 efficient storing, retrieving and updating of data
Overall System Structure
 DDL DML DCL TCL
 https://www.tutorialcup.com/dbms/database-
languages.htm

 Note: from above tutorial you can read from

 https://www.tutorialcup.com/dbms
 To
 https://www.tutorialcup.com/dbms/cluster-file-
organization.htm
 Database modeling process
35
 Database Design
36

The database design can be divided into six steps,

and ER modeling is relevant for the first three.
1. Requirements analysis involves discussion with user
groups, study of current operating environment,
analysis of existing system/applications which the
database is expected to replace.
 Database Design
37

2. Conceptual database design involves a high level

description of the data to be stored in the DB. This
step uses ER model we discuss (or similar high level
data model)
3. Logical database design involves choosing a DBMS
to implement our DB, and convert the conceptual
design into a database schema. The ER schema is
converted into a relational schema.
 Database Design
38

4. Schema refinement involves analysis of the DB

schema for potential problems and refine it.

5. Physical DB design considers the expected

workloads and refines the design so that it meets
the required performance criteria. This involves
building indexes, clustering some tables or
substantial redesign of the schema.
 Database Design
39

6. Security design involving identifying different user

groups, the roles played by them, and the necessary
parts of the DB they need to access. DBMS provides
mechanisms to ensure the access is restricted
accordingly to different users/groups.
Entity Relational Data Model

ER-Model describes data as

Entities
Attributes
Relationships
Entities and Attributes
Entity is thing in the real world with an independent
existence.

Entity may be an object with a physical

existence for example person, car house or
employee

Entity may be an object with a conceptual

existence for example a company, a job, a
university course.
Attributes

Attribute is the particular properties that

describe entity.
The attribute values that describe each
entity become a major part of the data
stored in the database.

For example
Employee entity may describe by
 Name, Age, address, salary and job.
Attribute & Attribute Value

Attribute
Student

ID Name Faculty Major

475020126-3 Kamonphon Science IT

465020100-0 PiyathiDa Science Comp SC.

Attribute Value
 Attribute Type
 Atomic Attribute
 Composite Attributes
 Single-Valued
 Multi Valued
 Stored Attribute
 Derived Attribute
Atomic Attribute
 Atomic Attribute is an attribute that is not divisible.
 Called Atomic or Simple Attributes.
 Example

Student
Atomic Simple

First Name Last Name Age

Composite Attributes
 Composite Attributes can be divided into smaller
subparts, which represent more basic attributes with
independent meanings.
Composite
Attribute

Address

Street Address ZipCode

Tambol
Province
Composite District
Attribute? Atomic
Attribute
Single-Valued VS Multi Valued Attributes

 Single-Valued : attribute has a

single value for a particular entity

 Multi Value Attribute: has multiple

values
Example

Attribute

Age Degree

A : 24 Years A : B.Sc.
B : 27 Years B : B.Sc, M.Sc., Dr. Eng.

Attribute Value
Stored VS Derived Attributed

 Stored Attribute
 Derived Attribute: an attribute value
can be determined from another
attribute / related entity.
Example
Attribute

Age Birth Day Stored Attribute

A : 24 Years A : 13 July 1980

B : 40 Years B : 23 Dec 1964

Derived Attribute
Attribute Value
Key Attribute
 An attribute that whose values are distinct for each
individual entity in the entity set.
 Unique

 Not Null
Null Value

Some case a particular entity may not have an

applicable value for an attribute.

Example
Degree attribute applied only to a person with
collage degree.

For this situations, a special value called null is

create.
Entity Type
 Regular Entity Type
 Entity that do have a key attribute
 Weak Entity Type
 Entitythat do not have key of their own.
 Depend on other entities

 Other entities are called owner entity

 Relationship between Owner and Weak entities is

called “identifying relationship”
Example
 Entity
 Employee

 Department

 Project

 Dependent
Entity Type, Entity Sets, Keys, Value Set

 Entity type defines a collection (or set) of entity that

have same attributes.

 Each entity type in the database is described by its

name and attributes.

 Entity set is the collection of all entities of a particular

entity type in a database at any point in time.

 The entity set usually referred to using the same name

as the entity type.
Key attribute of Entity type

 Key or Uniqueness constraint

an attribute whose values are distinct for each
individual entity in entity set
 Entity Type CAR with two keys and a
corresponding Entity Set
58
 Example: Company Database
59

 Description of Data Requirements

1. The company is organized into departments. Each
department has a unique name, a unique number,
and a particular employee who manages the
department. We keep track of the start date
when that employee began managing the
department. A department may have several
locations.
2. A department controls a number of projects, each
of which has a unique name, a unique number, and
a single location.
 Example: Company Database
60

3. We store each employee's name, SSN, address,

salary, sex, and birth date. An employee is
assigned to one department but may work on
several projects, which are not necessarily
controlled by the same department. We keep
track of the number of hours per week that an
employee works on each project. We also keep
track of the direct supervisor of each employee.
4. We want to keep track of the dependents of each
employee: first name, sex, birth date, relationship
to the employee
 Initial E-R Design
61

 Preliminary Conceptual Design

• Defining the Entity Types & Attributes
• Relationships are not included
• Company Database:
1. An entity type DEPARTMENT with attributes Name, Number,
Locations, Manager, and ManagerStartDate. Locations is the
only multivalued attribute. We can specify that both Name
and Number are (separate) key attributes, because each
was specified to be unique
 Initial E-R Design
62

2. An entity type PROJECT with attributes Name,

Number, Location , ControllingDepartment. Both
Name and Number are (separate) key attributes.
3. An entity type EMPLOYEE with attributes Name,
SSN, Sex, Address, Salary, BirthDate, Department,
and Supervisor. Both Name and Address may be
composite attributes.
4. An entity type DEPENDENT with attributes
Employee, DependentName, Sex, BirthDate, and
Relationship (to the employee).
 Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
63
Relationship
 There are several relationship among the various
entity types.
 Relationship Type

 Relationship type R among n entity types E1,E2,…,En

defines a set of association or relationship set among
entities from these entity types.
 Mathematically,

 the relationship set R is a set of relationship instances

ri, where each ri associates n individual entities
(e1,e2,…, en) and each entity ej in ri is a member of
entity type Ej,
1 ≤ j ≤ n.
Relationship Degree
 Degree of a relationship type is the number of
participating entity types.
 For example
Degree of a Relationship among Teacher and
Student entities is two.

A relationship degree two and three are called

binary and ternary, respectively.
Constraint on Relationship Types

 Two main Type of relationship constraints

1. Cardinality ration
2. Participation
Cardinality Ratios

 Cardinality ratio specifies the maximum

number of relationship instances that an
entity can participate
1 to 1 Relationship (1:1)
 1 to many relationship (1:N)
 Many to Many relationship (N:M)
1:1 Relationship
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity E2
Entity E1
Relationship
1 to Many Relationship
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity D
Entity E
Relationship
Many to Many Relationship
E1

E2 R1
J1
E3
R2 J2
E4
J3
E5 R3
J4
E6
R4
E7

Entity J
Entity E
Relationship
Participation Constraints and Existence
Dependencies
 Participation Constraints specified whether the
existence of an entity depends on its being related
to another entity via the relationship type.
 It specifies the minimum number of relationship
instance that each entity can participate in, and is
sometimes called the minimum cardinality constraint.
Participation type

 Partial

 Total participation
(existence dependency)
Total participation
E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity D
Entity E
Relationship
Partial participation

E1

E2 R1
D1
E3
R2 D2
E4
D3
E5 R3
D4
E6
R4
E7

Entity E Entity D
Relationship
 Recursive Relationship
76

 In some cases, the

same entity type
participates more
than once in a
relationship type in
different roles
 Example Employee
and supervised
 Cardinality of a Relationship
77

 The cardinality ratio for a binary relationship

specifies the max number of relationship instances
that an entity can participate in.
 Cardinality of a Relationship
78

 Cardinality Ratio
• Specify the number of relationship instances that an
entity can participate in
• 1:1 (each entity can only participate once)
• 1:N (one entity can participate once, the other can
participate many times)
• M:N (each entity can participate many times)
• WORKS_ON (EMPLOYEE:PROJECT) = M:N
• WORKS_FOR (EMPLOYEE:DEPT) = N:1
 E-R Design Refined
79

 Defining Relationship Types

• Change the attributes that represent relationships into
relationship types: Manager from DEPT., Supervisor from
EMPLOYEE
• Determine cardinality ratio and participation constraints
 Company Database Example
• MANAGES (EMPOYEE:DEPARTMENT) = 1:1
(partial:total), has ‘StartDate’ attribute
 E-R Design Refined
80

 Company Database Example

• WORKS_FOR (EMPLOYEE:DEPT) = N:1 (t:t)
• CONTROLS (DEPT:PROJECT) = 1:N (p:t)
• SUPERVISION (EMPLOYEE_supervisor:
EMPLOYEE_supervisee) = 1:N (p:p)
• WORKS_ON(EMPOYEE:PROJECT) = M:N (t:t), has
‘Hours’ attribute
• DEPENDENTS_OF (EMPOYEE:DEPENDENT) = 1:N (p:t),
DEPENDENT as a weak entity type
E-R Diagram Notation

Entity

Weak Entity

Relationship
Weak Entity

Attribute

Key Attribute

Composite Attribute

Derived Attribute
 partial Total

E1 R E2

1 N
E1 R E2

Cardinality Ratio
84