Database

Management
Systems (DBMS)

1
What is database?
• A DATABASE IS A COLLECTION OF
RELATED DATA OR FACTS. A database
management system (DBMS) is a
software tool that allows people to
store, access, and process data or
facts into useful information.

2
 DBMS Benefits
• Though a relational database is more complicated than a
list, it protects us from data anomalies (insert, update, and
delete)

• Furthermore, a relational database provides a solid

foundation for user forms and reports
Components of a Database System
Figure 14-1

DBMS
• A database management system (DBMS)
defines, creates, and maintains a
database.
DBMS components
DBMS components
• Hardware
• The physical computer system that allows physical access to data
• Software
• The actual program that allows users to access, maintain, and
update physical data
• Data: stored physically on the storage devices
• User: include end users and application programs
• Procedure
• A set of procedures (rules) that should be clearly defined and
followed by the users of the database
• A data model is a collection of concepts for describing
data.

• A schema is a description of a particular collection of

data, using a given data model.

• The relational model of data is the most widely used

model today.
• Main concept: relation, basically a table with rows and
columns.
• Every relation has a schema, which describes the
columns, or fields.
Database models
• Hierarchical model: obsolete

• Network model: obsolete

• Relational model

• In a relational model, data are organized in

two-dimensional tables called relations
Figure 14-3

Hierarchical model
Figure 14-4

Network model: graph

Figure 14-5
Relational model
RDBMS

• RDBMS is a Relational Data Base

Management System.
• This adds the additional condition that the
system supports a tabular structure for the
data, with enforced relationships between
the tables.
• The relational model was first proposed by
IBM’s Dr. E.F. Codd in 1970.
• Dr. Codd in 1985 laid out the “12 Rules”
for relational databases.
• Codd’s 12 rules, as listed below have since
become a semi-official definition of a
relational database.
Codd's 12 rules:

• Rule 1: The information rule:

All information in the database is to
be represented in one and only one
way, namely by values in column
positions within rows of tables.
• Rule 2: The guaranteed access rule:
All data must be accessible with no ambiguity.
This rule is essentially a restatement of the
fundamental requirement for Primary Key.
It says that every individual scalar value in the
database must be logically addressable by
specifying the name of the containing table, the
name of the containing column and the primary
key value of the containing row .
• Rule 3: Systematic treatment of null
values:
The DBMS must allow each field to
remain null (or empty). Specifically,
it must support a representation of
"missing information and
inapplicable information"
Rule 4: Active online catalog based on the relational
model:

The system must support an online, inline, relational

catalog that is accessible to authorized users by means
of their regular query language . That is, users must be
able to access the database's structure (catalog) using
the same query language that they use to access the
database's data.
 Rule 5: The comprehensive data
sublanguage rule:

• The system must support at least one

relational language that has…..
Rule 5 contd…
• Has a linear syntax
• Can be used both interactively and within
application programs,
• Supports data definition operations
(including view definitions), data
manipulation operations (update as well as
retrieval), security and integrity constraints,
and transaction management operations
(begin, commit, and rollback).
• Rule 6: The view updating rule:
All views that are theoretically
updatable must be updatable by the
system.
• Rule 7: High-level insert, update, and
delete:
The system must support set-at-a-time
insert, update, and delete operators. This
means that data can be retrieved from a
relational database in sets constructed of
data from multiple rows and/or multiple
tables
• Rule 8: Physical data independence:

Changes to the physical level (how the

data is stored, whether in arrays or linked
lists etc.) must not require a change to an
application based on the structure.
• Rule 9: Logical data independence:
Changes to the logical level (tables,
columns, rows, and so on) must not
require a change to an application
based on the structure. Logical data
independence is more difficult to
achieve than physical data
independence.
• Rule 10: Integrity independence:
Integrity constraints must be specified
separately from application programs and
stored in the catalog. It must be possible
to change such constraints as and when
appropriate without unnecessarily
affecting existing applications.
• Rule 11: Distribution independence:
The distribution of portions of the database
to various locations should be invisible to
users of the database
Existing applications should continue to
operate successfully 
• Rule 12: The non-subversion rule:
If the system provides a low-level (record-
at-a-time) interface, then that interface
cannot be used to subvert the system, for
example, bypassing a relational security or
integrity constraint.
Structure of Relational Databases

• The relational model is based on the concepts

that the data is organized and stored in two-
dimensional tables called relations.
• One can think of a relation as a file, of each row in
the relation as a record and each column as a
field.
• A row is called a tuple and a column is called as an
attribute.
Sample data :
Tuple # Attribute 1 Attribute 2 Attribute 3 Attribute 4
Name Age Sex Emp_No.
Tuple 1 John 34 M 9807
Tuple 2 Ravi 45 M 7876
Tuple 3 Rani 23 F 6775
Tuple 4 Ethil 54 M 7650
Tuple 5 Bobby 35 F 8987
Tuple 6 James 43 M 5679
Tuple 7 Havard 34 M 4563
• The terms relation, tuple and attribute have
been derived from the field of mathematics
and are alien to most people. The equivalent
terms used by different sets of people are as
below :-
Relational Model Programmer User
Relation File Table
Tuple Record Row
AttributeField Column
Some differences : DBMS vs RDBMS
• RDBMS=DBMS+Refrential Integrity
• An RDBMS ia one that follows 12 rules of
codd.
• RDBMS is based on the concepts of
Relational Set Theory in mathematics.
They implement the project, restrict, union,
intersect, difference, product, divide and
join in the queries. DBMS's on the other
hand, supports two or more, but not all of
the concepts.
• Collection of interrelated data
• Set of programs to access the data
• DMBS contains information about a
particular enterprise
• DBMS provides an environment that
it both convenient and efficient to use
31
Purpose of Database Systems
Database management systems were
developed to handle the following difficulties
of typical file-processing systems supported
by conventional operating systems:

CIS-552
Introduction
• Data redundancy and inconsistency
• Difficulty in accessing data
• Data isolation – multiple files and formats
• Integrity problems
• Atomicity of updates
• Concurrent access by multiple users
• Security problems 32
Data Independence
• Ability to modify a schema definition in one
level without affecting a schema definition

CIS-552
in the other levels.
• The interfaces between the various levels

Introduction
and components should be well defined so
that changes in some parts do not seriously
influence others.
• Two levels of data independence
• Physical data independence
33
• Logical data independence
Data Models
• A collection of tools for describing:
• Data
• Data relationships
• Data semantics

CIS-552
• Data constraints
• Object-based logical models

Introduction
• Entity-relationship model
• Object-oriented model
• Semantic model
• Functional model
• Record-based logical models
• Relational model (e.g., SQL/DS, DB2)
• Network model
• Hierarchical model (e.g., IMS) 34
Entity-Relationship Model
Example of entity-relationship model

CIS-552
social-security customer-street
account-number

Introduction
customer-name customer-city balance

customer depositor account

35
Relational Model
Example of tabular data in the relational model:
name ssn street city account-number

CIS-552
Johnson 192-83-7465 Alma Palo Alto A-101
Smith 019-28-3746 North Rye A-215

Introduction
Johnson 192-83-7465 Alma Palo Alto A-201
Jones 321-12-3123 Main Harrison A-217
Smith 019-28-3746 North Rye A-201

account-number balance
A-101 500
A-201 900
A-215 700
A-217 750
36
Data Definition Language
(DDL)
• Specification notation for defining the database
schema

CIS-552
• DDL compiler generates a set of tables stored in
a data dictionary

Introduction
• Data dictionary contains metadata (data about
data)
• Data storage and definition language – special
type of DDL in which the storage structure and
access methods used by the database system are
specified
37
Data Manipulation Language (DML)

• Language for accessing and manipulating

the data organized by the appropriate data

CIS-552
model
• Two classes of languages

Introduction
• 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 38
Transaction Management
• A transaction is a collection of operations that
performs a single logical function in a database

CIS-552
application.
• Transaction-management component ensures

Introduction
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. 39
Storage Management
• A storage manager is a program module that
provides the interface between the low-level

CIS-552
data stored in the database and the application
programs and queries submitted to the system.

Introduction
• The storage manager is responsible for the
following tasks:
• Interaction with the file manager
• Efficient storing, retrieving, and updating of
data 40
Database Administrator
• Coordinates all the activities of the database system; the
database administrator has a good understanding of the
enterprise’s information resources and needs:

CIS-552
• Database administrator’s duties include:
• Schema definition

Introduction
• Storage structure and access method definition
• Schema and physical organization modification
• Granting user authority to access the database
• Specifying integrity constraints
• Acting as liaison with users
• Monitoring performance and responding to changes in
requirements 41
Database Users
• Users are differentiated by the way they expect to interact
with the system.
• Application programmers: interact with system
through DML calls.

CIS-552
• Specialized users: write specialized database

Introduction
applications that do not fit into the traditional
data processing framework
• Sophisticated users: form requests in a database
query language.
• Naive users: invoke one of the permanent
application programs that have been written
previously
42
Figure 14-6

RDBMS
• RDBMS: the relational database management
system (RDBMS)
• Relation: a relation is a 2D table has the following
features:
• Name
• Attributes
• Tuples
Operations on relations
• Insert : unary operation
• Delete : unary operation
• Update : unary operation
• Select : unary operation
• Project : unary operation
• Join : binary operation
• Union : binary operation
• Intersection : binary operation
• Difference : binary operation
Figure 14-7
Figure 14-8

Insert operation

Delete operation
Figure 14-9
Figure 14-10

Update operation

Select operation
Figure 14-12

Join operation
Figure 14-13

Union operation
Figure 14-14

Intersection operation
Figure 14-15

Difference operation
Other database models
• Distributed databases
• The data are stored on several computers that
communicate through the Internet.
• Fragmented distributed databases
• Replicated distributed databases

• Object-oriented databases
• An object-oriented database tries to keep the
advantages of the relational model and at the
same time allows applications to access
structured data.
 Problems with Lists: Redundancy
• In a list, each row is intended to stand on its own. As a
result, the same information may be entered several times
(i.e., redundancy)

SALES_ORDERS
SO_Number Item_Number Item_Name Qty_Ordered Cust_Code Cust_Name
1010 2010-0050 Formed Handlebar 2 WHEEL Wheelaway Cycle Center
1000-1 20 in. Bicycle 5 WHEEL Wheelaway Cycle Center
1011 1002-1 24 in. Bicycle 5 ETC Bikes Et Cetera
1001-1 26 in. Bicycle 10 ETC Bikes Et Cetera
1012 1003-1 20 in. Bicycle 5 WHEEL Wheelaway Cycle Center
1001-1 26 in. Bicycle 10 WHEEL Wheelaway Cycle Center
1013 1001-1 26 in. Bicycle 50 IBS Inter. Bicycle Sales
1014 1003-1 20 in. Bicycle 25 ETC Bikes Et Cetera
1015 1003-1 20 in. Bicycle 25 WHEEL Wheelaway Cycle Center
1016 3961-1041 Tire Tube, 26 in. 5 ETC Bikes Et Cetera
3965-1050 Spoke Reflector 50 ETC Bikes Et Cetera
1003-1 20 in. Bicycle 5 ETC Bikes Et Cetera
1000-1 20 in. Bicycle 4 ETC Bikes Et Cetera
 Problems with Lists: Multiple Themes
• In a list, each row may contain information on more than one “theme”.
As a result, needed information may appear in the lists only if
information on other themes is also present

S ALES _ORDERS
SO_Num be r Ite m _Num be r Ite m _Na m e Qty_Orde re d Cus t_Code Cus t_Na m e
1010 2010-0050 Form e d Ha ndle ba r 2 WHEEL Whe e la wa y Cycle Ce nte r
1000-1 20 in. Bicycle 5 WHEEL Whe e la wa y Cycle Ce nte r
1011 1002-1 24 in. Bicycle 5 ETC Bike s Et Ce te ra
1001-1 26 in. Bicycle 10 ETC Bike s Et Ce te ra
1012 1003-1 20 in. Bicycle 5 WHEEL Whe e la wa y Cycle Ce nte r
1001-1 26 in. Bicycle 10 WHEEL Whe e la wa y Cycle Ce nte r
1013 1001-1 26 in. Bic yc le 50 IBS Inte r. Bic yc le S ale s
1014 1003-1 20 in. Bicycle 25 ETC Bike s Et Ce te ra
1015 1003-1 20 in. Bicycle 25 WHEEL Whe e la wa y Cycle Ce nte r
1016 3961-1041 Tire Tube , 26 in. 5 ETC Bike s Et Ce te ra
3965-1050 Spoke Re fle ctor 50 ETC Bike s Et Ce te ra
1003-1 20 in. Bicycle 5 ETC Bike s Et Ce te ra
1000-1 20 in. Bicycle 4 ETC Bike s Et Ce te ra
 List Modification Issues
• Redundancy and multiple themes create modification problems
Deletion problems
• If we delete SO #1013 we lose our customer IBS

Update problems
• If customer “Bikes Et Cetera” changes its name we have to make sure we
change it in every single row.

Insertion problems
• If we want to add a new customer, we must either wait until they place an order
or (worse) make up a bogus sales order
 List Modification Issues
S ALES_ORDERS DELETE
S O_Num be r Ite m _Num be r Ite m _Na m e Qty_Orde re d Cus t_Code Cus t_Na m e No SO
1010 2010-0050 Form e d Ha ndle ba r 2 WHEEL Whe e la wa y Cycle Ce nte r #1013,
1000-1 20 in. Bicycle 5 WHEEL Whe e la wa y Cycle Ce nte r
1011 1002-1 24 in. Bicycle 5 ETC Bike s Et Ce te ra
no IBS
1001-1 26 in. Bicycle 10 ETC Bike s Et Ce te ra
1012 1003-1 20 in. Bicycle 5 WHEEL Whe e la wa y Cycle Ce nte r
1001-1 26 in. Bicycle 10 WHEEL Whe e la wa y Cycle Ce nte r UPDATE
1013 1001-1 26 in. Bic yc le 50 IBS Inte r. Bic yc le S ale s Need to
1014 1003-1 20 in. Bicycle 25 ETC Bike s Et Ce te ra change Et
1015 1003-1 20 in. Bicycle 25 WHEEL Whe e la wa y Cycle Ce nte r Cetera to
1016 3961-1041 Tire Tube , 26 in. 5 ETC Bike s e tc. etc.
3965-1050 S poke Re fle ctor 50 ETC Bike s e tc.
1003-1 20 in. Bicycle 5 ETC Bike s e tc.
1000-1 20 in. Bicycle 4 ETC Bike s e tc.
Ne w (& ric h) Cus tome r INSERT
Blank fields
may cause
problems
later
 Relational Databases
• A relational database stores information in tables. Each
informational theme is stored in its own table
• In essence, a relational database will break-up a list into several
parts. One part for each theme in the list
• This is similar to a Web page

– Rather than paste the information from another source into

our page, it can be linked instead.
– The updates are done on the linked page. We just need to
make sure that our link to it is valid
“Key” terms
• An entity is something of importance to a user that
needs to be represented in a database
• An entity represents one theme or topic and is
represented by a table.
• The table dimensions, like a matrix, consist of rows
(tuples) and columns (attributes)
 A Key
• A (primary) key is one (or more) columns of a relation that
is (are) used to identify a row

• A composite key is a key that contains two or more

attributes

– For a key to be unique, it is sometimes necessary to

use a composite key

– Can also generate a set of unique values to serve as

the key (for example University ID numbers)
A Foreign Key
• A table may be related to other tables (i.e., a
relationship)
• To create relationships, you may need to create a foreign
key
• A foreign key is a primary key from one table placed into
another table
• Referential integrity - every value of a foreign key must
match a value of an existing primary key
 Foreign Key Example
Project Manager

Proj_Num MgrID Primary Key

s hip
ti on
Proj_Name e la MgrName
R
MgrID
Foreign Key
 Functional Dependency
• A relationship between attributes in which one or more
attributes determines the value of another attribute(s) in
the same table

• The Proj_Num “determines” the Proj_Name