GLA University, Mathura

DATABASE MANAGEMENT SYSTEM

Course Code: BCSC1003

Dr. Varun Mishra

Asst. Professor CSE

1
 Introduction to DBMS
 Collection of interrelated data
 Set of programs to access the data
 DBMS contains information about a particular enterprise
 DBMS provides an environment that it both convenient and
 Efficient to use

2
 more
Another definition (know these):
• A database is a collection of organized, interrelated data, typically relating to
a particular enterprise.
• A Database Management System (DBMS) is a set of programs for managing
and accessing databases.

3
 Database Applications
• Anywhere there is data, there could be a database:

 Banking - accounts, loans, customers

 Airlines - reservations, schedules
 Universities - registration, grades
 Sales - customers, products, purchases
 Manufacturing - production, inventory, orders, supply chain
 Human resources- employee records, salaries, tax deductions
 Credit card transactions - purchases on credit cards, generation of
monthly statements
 Telecommunication - keeping records of calls made

4
 University Database Example
 Application program examples
 Add new students, instructors, and courses
 Register students for courses, and generate class rosters
 Assign grades to students, compute grade point averages (GPA)
and generate transcripts

 In the early days, database applications were built directly on top of

file systems i.e. Traditional 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

6
 more
 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 access needed for performance
 Uncontrolled concurrent accesses can lead to inconsistencies
– Example: Two people reading a balance (say 100) and updating it by
withdrawing money (say 50 each) 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

7
 Purpose of Database System
• Database Management Systems were developed to
handle the following difficulties of typical file-
processing systems supported by conventional
operating systems.

8
 Purpose & Goals of DBMS
Benefits of the database approach:

1. The data can be shared.

2. Redundancy can be reduced.
3. Inconsistency can be avoided (to some extent).
4. Transaction support can be provided.
5. Integrity can be maintained.
6. Security can be enforced.
7. Conflicting requirements can be balanced.
8. Standards can be enforced.

9
Database Languages

10
 DBMS Languages
• Data Definition Language (DDL)
• Data Manipulation Language (DML)
• Data Control Language (DCL)
• Transaction Control Language (TCL)

11
 Data Definition Language (DDL) :
Statements are used to define the database structure or schema.

Some examples:

CREATE - to create objects in the database

ALTER - alters the structure of the database
DROP - delete objects from the database
TRUNCATE - remove all records from a table, including all spaces
allocated for the records are removed
COMMENT - add comments to the data dictionary
RENAME - rename an object

12
Data Manipulation Language (DML)
Language for accessing and manipulating the data organized by the
appropriate data model.

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

13
• Some examples:
more
SELECT - Retrieve data from the a database
• INSERT - Insert data into a table
• UPDATE - Updates existing data within a table
• DELETE - deletes all records from a table, the space for the records remain
• MERGE - UPSERT operation (insert or update)
• CALL - Call a PL/SQL or Java subprogram
• EXPLAIN PLAN - explain access path to data
• LOCK TABLE - control concurrency

14
 Data Control Language (DCL)
Some examples:

GRANT - gives user's access privileges to database

REVOKE - withdraw access privileges given with the GRANT

command

15
 Transaction Control (TCL)
Statements are used to manage the changes made by DML statements. It
allows statements to be grouped together into logical transactions.

Some examples:

COMMIT - save work done

SAVEPOINT - identify a point in a transaction to which you can later roll back
ROLLBACK - restore database to original since the last COMMIT
SET TRANSACTION - Change transaction options like isolation level and what
rollback segment to use

16
DBMS Users and Abstraction

17
 Database Users
Users are differentiated by the way they expect to interact with the system.

Application programmers – interact with system through DML calls

Sophisticated users – form requests in a database query language

Specialized users – write specialized database applications that do not fit into the
traditional data processing framework

Naive users – invoke one of the permanent application programs that have been
written previously

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

Database administrator’s duties include:

– Schema definition
– 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

19
 View of Data
• An architecture for a database system
View level

View 1 View 2 ..... View n

Logical level

Physical level

21
 Levels of Abstraction
 Physical level - defines low-level details about how data item is
stored on disk.

 Logical level - describes data stored in a database, and the

relationships among the data (usually conveyed as
a data model, e.g., an ER diagram).

 View level - defines how information is presented to users.

Views can also hide details of data types, and
information (e.g., salary) for security purposes.

22
 Data Independence
• Ability to modify a schema definition in one level without
affecting a schema definition in the next higher level.

• The interfaces between the various levels and components

should be well defined so that changes in some parts do not
seriously influence others.

23
 Data independence

1.Physical data independence

is the ability to modify the physical
schema without causing application programs to be rewritten.

2.Logical data independence

is the ability to modify the logical schema
without causing application programs to be rewritten.

24
 Instances and Schemas
Similar to types and variables in programming languages
Schema –
• The logical structure of the database (e.g., set of customers and accounts and
the relationship between them)
• The overall design of the database is called the database schema.
• 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.
• The collection of information stored in the database at a particular
moment is called an instance of the database.

25
26
DBMS Models

27
 Data Models

 The phrase “data model” is used in a couple of different ways.

 Frequently used (use #1) to refer to an overall approach or philosophy for

database design and development.
 For those individuals, groups and corporations that subscribe to a specific
data model, that model permeates all aspects of database design,
development, implementation, etc.

28
• The purpose of developing the data model is to define:
– Data
– Relationships between data items
– Semantics of data items
– Constraints on data items

In other words, a data model defines the logical schema, i.e., the logical level of design of a
database.

• A data model is typically conveyed as one or more diagrams (e.g., ER or

UML diagrams).
• This early phase in database development is referred to as data modeling.

29
 DBMS Data Models
• The entity-relationship model
• The object oriented model
• Relational model
• Network model
• Hierarchical model

30
The Entity Relationship Model
or
E-R Model

31
 History of E-R Model
• E-R Model was proposed by Dr.
Peter Chen (currently professor
at Louisiana State University)

• Chen’s original paper on E-R

Model is the 35th most sited
paper in computer science

• Chen has written papers

interconnecting E-R model and
linguistics
 Entity Relationship Model
 Models an enterprise as a collection of entities and
relationships
 Entity: a “thing” or “object” in the enterprise that is
distinguishable from other objects
 Described by a set of attributes
 Relationship: an association among several entities

 Represented diagrammatically by an entity-relationship

diagram.

33
 Entity
• Entity - distinguishable “thing” in the real world
For example,
– in a school database, students, teachers, classes, and courses
offered can be considered as entities. All these entities have some
attributes or properties that give them their identity.
Entities are represented by: Rectangle

E n tity Na m etype name

Entity
(singular, no spaces,
capital letter at start of each word)

space for attributes

34
 Entity & Entity Sets
• An Entity is an object that exists and is distinguishable from other objects.
For instance, John Harris with S.I.N. 890-12-3456 is an entity, as he can be
uniquely identified as one particular person in the universe.

• 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).

• Entity sets need not be disjoint. For example, the entity set employee (all
employees of a bank) and the entity set customer (all customers of the
bank) may have members in common.

35
 Strong vs. Weak Entity
Strong (or regular) entity -
1. An entity set that has a primary key is termed as strong entity set.
2. Entities have an independent existence

Weak entity
3. An entity set that does not have sufficient attributes to form a primary
key is termed as a weak entity set.
4. Weak entity is an entity that depends on another entity.
5. Weak entity doesn't have key attribute of their own. Double rectangle
represents weak entity.
6. Existence dependent on some other entity

36
 Example
• Say, for example, we have a statement
“A Student lives in a Home.”

• STUDENT is obviously a strong entity having a primary key Roll.

• But HOME may not have a unique primary key, as its only attribute
Address may be shared by many homes (what if it is a housing estate?).
HOME is a weak entity in this case.

• The ERD of this statement would be like the following

37
 Attributes
• An Attribute describes a property or characteristic of an entity.
For example, Name, Age, Address etc can be attributes of a
Student.
• An attribute is represented using eclipse.

38
 Types of Attributes
Attributes can be

• simple (atomic) e.g. Surname; date of birth

• composite e.g. address (street, town, postcode)
• multi-valued e.g. phone number
• complex nested multi-valued and composite
• base or derived e.g. D.O.B. ; age
• Key

Relationship types can also have attributes! (see later)

39
 Notation for attributes
Primary Key
marked {PK} EntityName
ke yAttribute {PK}
composite Attribute Composite
attribute
partOne
partTwo
Derived
/ de riv e dAttribu te
Attribute
multiValue d [min ..max]
{PPK}
Partial Key Multi-Valued
- part of composite PK Attribute
- or of a weak entity (number of
values in [ ]
brackets)
40
 Definition: Types of Attributes
• Simple attribute − Simple attributes are atomic values, which cannot be
divided further. For example, a student's phone number is an atomic value of
10 digits.

• Composite attribute − Composite attributes are made of more than one simple
attribute. For example, a student's complete name may have first_name and
last_name.

• Derived attribute − Derived attributes are the attributes that do not exist in the
physical database, but their values are derived from other attributes present in
the database. For example, average_salary in a department should not be
saved directly in the database, instead it can be derived. For another example,
age can be derived from data_of_birth.

41
 more
• Single-value attribute − Single-value attributes contain single value. For
example − Social_Security_Number.

• Multi-value attribute − Multi-value attributes may contain more than one

values. For example, a person can have more than one phone number,
email_address, etc.

42
Summary of
Notation

43
 Keys
Key is an attribute or collection of attributes that uniquely identifies an entity
among entity set.

For example, the roll_number of a student makes him/her identifiable among

students.

• Super Key − A set of attributes (one or more) that collectively identifies an

entity in an entity set.

• Candidate Key − A minimal super key is called a candidate key. An entity set
may have more than one candidate key.

• Primary Key − A primary key is one of the candidate keys chosen by the
database designer to uniquely identify the entity set.

44
 Keys: more
• Alternate Key: This is the candidate key which is not chosen as the primary key of the
table. They are named so because although not the primary key, they can still identify
a row.

• Composite Key: Sometimes one key is not enough to uniquely identify a row. E.g. in a
single class Roll is enough to find a student, but in the entire school, merely searching
by the Roll is not enough, because there could be 10 classes in the school and each
one of them may contain a certain roll no 5. To uniquely identify the student we have
to say something like “class VII, roll no 5”. So, a combination of two or more attributes
is combined to create a unique combination of values, such as Class + Roll.

• Foreign Key: Sometimes we may have to work with an attribute that does not have a
primary key of its own. To identify its rows, we have to use the primary attribute of a
related table. Such a copy of another related table’s primary key is called foreign key

45
 Keys
• A key is a set of one or more column
whose combined values are unique
among all occurrences in a given
table.
• A key is the relation of specifying
uniqueness based on the property of
Uniqueness.
46
 Types of Keys
1. Primary Key
2. Candidate key
3. Super Key
4. Composite Key
5. Foreign Key

47
 Candidate Key
• When more than one or grouped
attributes serve as a unique
identifier, they are each called as
Candidate Key.
• Candidate key are those attributes of
a relation which posses the property
of uniqueness and irreducibility.
48
 Candidate Key
Suppose that ‘K’ is a set of attributes of
relation ‘R’, it is represented as R(K),
then, ‘K’ is the candidate key of relation R
if and only if it possess both of the
following properties:
1. Uniqueness
2. Irreducibility

49
 Candidate Key
Uniqueness Property:
It states that no legal value of relation ‘R’
ever contains two distinct tuples with the
same value of ‘K’.
Irreducibility Property:
It states that no proper subset of K has
the uniqueness property.

50
For example,
If (name, class) is unique that it can be
identify as the candidate key if and only if name &
class individually are not unique.
i.e.
name != unique
class != unique
throughout the table. In this relation, name and
class collectively known as COMPOSITE KEY also.

51
 Super Key
• The Super Key is defined as an
attribute or a set of attributes that
uniquely identify a tuple within a
relation.
• A Super key has the uniqueness
property but not necessarily the
irreducibility property.
52
 More
• A candidate key is a special case of
Super key.
• All attributes in a relation taken
together are Super key because only
one row in a relation has a given
value for all relation attributes.

53
 More
• Consider a following relation:
R student (Roll no, Name, Class)

Here, if roll no is unique in the relation

student then set of attributes (Roll no,
Name, Class) is a super key for this student
relation.

54
 More
These set of attributes are also unique
but this combination of keys is not
having irreducibility property.
Because, roll no which is one
subset of Super key is also unique
itself. Super key is not followed by
irreducibility property.
55
 More
Hence,

Candidate key =
Super key – Primary key

56
 Primary Key
It is defined as the candidate key that
is selected to identify tuples
uniquely within the relation. The
primary key is an attribute that
uniquely identify a specific instance
of an activity.

57
 Primary Key
The primary key can not contain
any NULL values because it
cannot uniquely identify multiple
NULL values.

58
 Foreign Key
As, we have already studied the
concept of parent and child table,
we say that
Column in the child table that
references the primary key of parent
table is called as FOREIGN KEY.

59
 Foreign Key
They are used to link together two or
more different tables which have
some form of relationships with
each other.

RDBMS = DBMS + Referential integrity

(Foreign key)
60
 Foreign Key
For example, Consider a relation:
student(roll no, name and address)
Another relation
Studentinfo(marks, subject, class, roll no)
In this relation, studentinfo, the
attribute roll no is considered as foreign key
for the parent table student.
61
 Relationships
• A relationship is
“.. An association among entities (the participants)..”
• Represented by Diamonds.
• Relationships link entities with each other

Entity1 Entity2
HasLinkWith

Name: verb, capital start letter,

arrow indicates direction in which
verb makes sense

62
 Relationship sets

• A set of relationships of similar type is called a relationship

set.
• Entity-relationship diagrams don't show single entities or
single instances of relations.
• Rather, they show entity sets and relationship sets.

• Example:
 a particular song is an entity.
 The collection of all songs in a database is an entity set.
 The eaten relationship between a child and her lunch is a single relationship.
 The set of all such child-lunch relationships in a database is a relationship set.

63
 Relationships: constraints
• The degree of a relationship type
– binary (connects 2 entity types) Degree
– unary/ recursive (connects 1 entity type with itself)
– complex (connects 3 or more entity types)
• Ternary (connects 3)

• Relationship constraints - cardinality

– one to one (1:1)
– one to many (1:m)
– many to many (m:n)
• Relationship constraints – participation
– full/mandatory Multiplicity
– or partial/optional

64
 Relationships: Degree
Entity1 Entity2
HasLinkWith
Binary relationship

S u p e rv is o r Supe rv ise s

Entity1
Staff Recursive (Unary) relationship
- example
S u p e rv is e e

Entity1 Entity3
Te rnaryRe lationship

Complex relationship
–
here ternary Entity2

65
Relationships: Mapping Cardinalities

Cardinality defines the number of entities in one entity set,

which can be associated with the number of entities of other
set via relationship set.

These are of four types:

1. One to One
2. One to Many
3. Many to One
4. Many to Many
66
 One to One
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-one relation

E.g. A teacher teaches a student. Only one

teacher is teaching only one student.

67
 One to Many
One-to-many − One entity from entity set A can be associated
with more than one entities of entity set B however an entity
from entity set B, can be associated with at most one entity.

One-to-many relation

E.g. A teacher teaches students.

Only one teacher is teaching many students.

68
 Many to One
Many-to-one − More than one entities from entity set A can
be associated with at most one entity of entity set B, however
an entity from entity set B can be associated with more than
one entity from entity set A.

Many-to-one relation

E.g. Teachers teach a student. Many teachers

are teaching only one student.

69
 Many to Many
Many-to-many − One entity from A can be associated with
more than one entity from B and vice versa.

Many-to-many relation

E.g. Teachers teach students.

In any school or college many teachers are teaching
many students. This can be considered as a two way
one-to-many relationship.

70
 Relationships: Participation
Participation Constraints
•Total Participation − Each entity is involved in
the relationship. Total participation is represented
by double lines.
•Partial participation − Not all entities are
involved in the relationship. Partial participation is
represented by single lines.

71
 Entity Relationship(E-R) Diagram in DBMS

• A graphical representation of the entities and the relationships between

them.

• Entity relationship diagrams are a useful medium to achieve a common

understanding of data among users and application developers.

• In data modeling, an entity-relationship model (ERM) is a representation

of structured data; entity-relationship modeling is the process of
generating these models. The end-product of the modeling process is an
entity-relationship diagram (ERD), a type of Conceptual Data Model or
Semantic Data Model.

72
 ER Diagram
Represented diagrammatically by an entity-relationship diagram:

73
Design of E-R Model

74
 Exercise
To design an Entity Relationship (ER) model for a
college database

75
Say we have the following statements.
• A college contains many departments
• Each department can offer any number of courses
• Many instructors can work in a department
• An instructor can work only in one department
• For each department there is a Head
• An instructor can be head of only one department
• Each instructor can take any number of courses
• A course can be taken by only one instructor
• A student can enroll for any number of courses
• Each course can have any number of students

76
 Let's start our design
Step 1 : Identify the Entities
• What are the entities here?

• From the statements given, the entities are

1. Department
2. Course
3. Instructor
4. Student

77
Step 2 : Identify the relationships

1. One department offers many courses. But one particular course can be
offered by only one department. hence the cardinality between
department and course is One to Many (1:N)
2. One department has multiple instructors . But instructor belongs to only
one department. Hence the cardinality between department and
instructor is One to Many (1:N)
3. One department has only one head and one head can be the head of
only one department. Hence the cardinality is one to one. (1:1)
4. One course can be enrolled by many students and one student can enroll
for many courses. Hence the cardinality between course and student is
Many to Many (M:N)
5. One course is taught by only one instructor. But one instructor teaches
many courses. Hence the cardinality between course and instructor is
Many to One (N :1)

78
Step 3: Identify the key attributes

• "Department_Name" can identify a department

uniquely. Hence Department_Name is the key
attribute for the Entity "Department".
• Course_ID is the key attribute for "Course" Entity.
• Student_ID is the key attribute for "Student"
Entity.
• Instructor_ID is the key attribute for "Instructor"
Entity.

79
Step 4: Identify other relevant attributes

• For the department entity, other attributes

are location
• For course entity, other attributes are
course_name,duration
• For instructor entity, other attributes are
first_name, last_name, phone
• For student entity, first_name, last_name,
phone

80
Step 5: Draw complete ER diagram

• By connecting all these details, we can now

draw ER diagram as shown in next slide.

81
82
Advantages and Disadvantages of ER Modeling
( Merits and Demerits of ER Modeling )

83
• Advantages

1. ER Modeling is simple and easily understandable.

It is represented in business users language and
it can be understood by non-technical specialist.
2. Intuitive and helps in Physical Database creation.
3. Can be generalized and specialized based on
needs.
4. Can help in database design.
5. Gives a higher level description of the system.

84
• Disadvantages

1.Physical design derived from E-R Model

may have some amount of ambiguities or
inconsistency.
2.Sometime diagrams may lead to
misinterpretations

85
 Generalization
• Generalization is a bottom-up approach in which two lower level entities
combine to form a higher level entity. In generalization, the higher level
entity can also combine with other lower level entity to make further
higher level entity.

86
 Specialization
• Specialization is opposite to Generalization. It is a top-down approach in
which one higher level entity can be broken down into two lower level
entity. In specialization, some higher level entities may not have lower-
level entity sets at all.

87
 Aggregation
• Aggregation is a process when relation between two entity is treated as a
single entity. Here the relation between Center and Course, is acting as an
Entity in relation with Visitor.

88
 The Network Model
• Created to
– Represent complex data relationships more
effectively
– Improve database performance
– Impose a database standard
• Conference on Data Systems Languages
(CODASYL)
• Database Task Group (DBTG)
 The Network Model (continued)
• Schema
– Conceptual organization of entire database as viewed
by the database administrator
• Subschema
– Defines database portion “seen” by the application
programs that actually produce the desired
information from data contained within the database
• Data Management Language (DML)
– Defines the environment in which data can be
managed
The Network Model (continued)
• Schema Data Definition Language (DDL)
– Enables database administrator to define
schema components
• Subschema DDL
– Allows application programs to define database
components that will be used
• DML
– Works with the data in the database
The Network Model (continued)
• Resembles hierarchical model
• Collection of records in 1:M relationships
• Set
– Relationship
– Composed of at least two record types
• Owner
– Equivalent to the hierarchical model’s parent
• Member
– Equivalent to the hierarchical model’s child
The Network Model (continued)

93
The Network Model (continued)
• Disadvantages
– Too cumbersome
– The lack of ad hoc query capability put heavy
pressure on programmers
– Any structural change in the database could
produce havoc in all application programs that
drew data from the database
– Many database old-timers can recall the
interminable information delays
Network model
 Network data model
Class
Relationships:
• one-to-one
• one-to-many Student Instructor
• many-to-one
• many-to-many
Grade ID Department
 Network data model

• Advantages
– flexible, fast, efficient
• Disadvantages
– Complex
– Restructuring can be difficult because of
changing all the pointers
 Summary
• Hierarchical and network data models have
generally been replaced by the relational data
model
• Relational databases dominate the database
market
– Oracle
– Informix
– SQL Server
– DB2
– ……..
 Object Oriented Model in DBMS
• Object DBMSs add database functionality to object
programming languages.

• They bring much more than persistent storage of

programming language objects.

• A major benefit of this approach is the unification of the

application and database development into a seamless data
model and language environment. As a result, applications
require less code, use more natural data modeling, and code
bases are easier to maintain.

99
 Relationship Model in DBMS
• A branch of set theory that deals with logical relationships between sets.
The Relational Model underlies OOA/D Class Models.

• This is a more general model than the Relational Data Model.

• In an OOA/D context explicate identity and referential attributes are not

required.

• In an OOA/D context relationships are much more abstract than in the

Relational Data Model.

• In addition, the logical properties include behaviors as well as data.

100
 Relational Model
Example of tabular data in the relational model

101
A Sample Relational Database

102
 Network Model in DBMS
• The popularity of the network data model coincided with the popularity of
the hierarchical data model.

• Some data were more naturally modeled with more than one parent per
child.

• So, the network model permitted the modeling of many-to-many

relationships in data.

• The basic data modeling construct in the network model is the set
construct.

• A set consists of an owner record type, a set name, and a member record
type.
103
 DBMS Hierarchical Model
• The hierarchical data model organizes data in a tree structure.

• There is a hierarchy of parent and child data segments.

• This structure implies that a record can have repeating information,

generally in the child data segments.

• Data in a series of records, which have a set of field values attached to it.

• It collects all the instances of a specific record together as a record type.

104
Overall System
Architecture

105
106
 More
The following components of a DBMS are of interest to us:

• transaction manager
• buffer manager
• file manager
• authorization and integrity manager
• query optimizer

107
 Transaction Management
 A transaction is a collection of operations that performs a single logical
function in a database application

 The transaction manager performs two primary functions:

 backup and recovery
 concurrency control

 Backup and recovery ensures that the database remains in a consistent

(correct) state despite failures:
 system, power, network failures
 operating system crashes
 transaction failures.

 Concurrency-control involves managing the interactions among concurrent

transactions.

108
 Storage Management

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.

The storage manager is responsible for the following tasks:

– interaction with the file manager
 The file manager is responsible for managing the files that store data.
 formatting the data files
 managing free and used space in the data files
 defragmenting the data files
 inserting and deleting specific data from the files

– efficient storing, retrieving, and updating of data

109
Authorization and Integrity management

 The authorization & integrity manager performs two primary functions:

 data security
 data integrity

 Data security:
 ensure that unauthorized users can’t access the database
 ensure that authorized users can only access appropriate data

 Data integrity:
 in general, maintains & enforces integrity constraints
 maintains data relationships in the presence of data modifications
 prevents modifications that would corrupt established data relationships

110
 Query Optimization
 A given query can be implemented by a DBMS in many different ways.

 The query optimizer attempts to determine the most efficient strategy for
executing a given query.

 The strategy for implementing a given query is referred to as a query plan.

111
Data Model

112
 The Importance of Data Models
• Data models
– Relatively simple representations, usually graphical,
of complex real-world data structures
– Facilitate interaction among the designer, the
applications programmer, and the end user
• End-users have different views and needs for
data
• Data model organizes data for various users
113
 History of Data Models
• Relational Model: proposed in 1970 by E.F. Codd (IBM), first
commercial system in 1981-82. (DB2, ORACLE, SQL Server,
SYBASE, INFORMIX).

• Network Model: Adopted heavily due to the support by

CODASYL (CODASYL - DBTG report of 1971), IDMS (Cullinet -
now CA), DMS 1100 (Unisys), IMAGE (H.P.), VAX -DBMS
(Digital Equipment Corp.).

• Hierarchical Data Model:.Resulted in the IMS family of

systems. The most popular model.
 History of Data Models
• Object-oriented Data Model(s): several models have
been proposed for implementing in a database
system.

• Object-Relational Models: Most Recent Trend.

Started with Informix Universal Server. Exemplified in
the latest versions of Oracle-10i, DB2, and SQL Server
etc. systems.
 Data Model Basic Building Blocks
• Entity - anything about which data are to be collected
and stored
• Attribute - a characteristic of an entity
• Relationship - describes an association among
entities
– One-to-many (1:M) relationship
– Many-to-many (M:N or M:M) relationship
– One-to-one (1:1) relationship
• Constraint - a restriction placed on the data

116
 The Evolution of Data Models (continued)

• Hierarchical
• Network
• Relational
• Entity relationship
• Object oriented (OO)
 The Hierarchical Model
• Developed in the 1960s to manage large
amounts of data for complex manufacturing
projects
• Basic logical structure is represented by an
upside-down “tree”
The Hierarchical Model (continued)
The Hierarchical Model (continued)
• The hierarchical structure contains levels, or
segments
• Depicts a set of one-to-many (1:M)
relationships between a parent and its
children segments
– Each parent can have many children
– each child has only one parent
Hierarchical database model
 Hierarchical data model
Class
• Parent-child
relationship:
– one-to-one Student Instructor
– one-to-many

Grade ID Department
The Hierarchical Model (continued)

• Advantages
– easy to search
– add new branches easily
The Hierarchical Model (continued)

• Disadvantages
– Complex to implement
– Difficult to manage
– Lacks structural independence
– Implementation limitations
– Lack of standards
 Closure of Attribute Sets

• Given a set  of attributes of R and a set of

functional dependencies F, we need a way to
find all of the attributes of R that are
functionally determined by .
This set of attributes is called the closure
of  under F and is denoted +

125
 Closure of Attribute Sets

Finding + is useful because:

• if + = R, then  is a super key for R
• if we find + for all  R, we've computed F+
(except that we'd need to use decomposition
to get all of it).

126
 Algorithm
result := 
repeat
temp := result
for each functional dependency
   in F do
if   result then
result := result  
until temp = result

127
 Example
• Compute the closure for relational schema
R={A,B,C,D,E}
A-->BC
CD-->E
B-->D
E-->A
List candidate keys of R.

128
 Solution
Solution:
R={A,B,C,D,E}
F, the set of functional dependencies A-->BC, CD-->E, B--
>D, E-->A
Compute the closure for each  in    in F
Closure for A
A+ = ABCDE, Hence A is a super key
Iteration result using

1 A

2 ABC A-->BC

3 ABCD B-->D

4 ABCDE CD-->E

5 ABCDE
129
 Solution

Closure for CD
CD+ = ABCDE, Hence CD is a super key

Iteration result using

1 CD
2 CDE CD-->E
3 ACDE E-->A
4 ABCDE A-->BC
5 ABCDE
130
 Solution
Closure for B
B+ = BD, Hence B is NOT a super key
Iteration result Using
1 B
2 BD B-->D
3 BD

131
 Solution
Try applying Armstrong axioms, to find alternate keys.
B-->D
BC-->CD (by Armstrong’s augmentation rule)
Closure for BC
BC+ = ABCDE, , Hence BC is a super key

Iteration result using

1 BC
2 BCD BC-->CD
3 BCDE CD-->E
4 ABCDE E-->A
132
 Solution
Closure for E
E+ = ABCDE
Iteration result using
1 E
2 AE E-->A
3 ABCE A-->BC
4 ABCDE B-->D
5 ABCDE

133
 Solution
A and E are minimal super keys.
To see whether CD is a minimal super key, check whether its subsets
are super keys.
C+ = C
D+ = D
Since C and D are not super keys, CD is a minimal super key.
To see whether BC is a minimal super key, check whether its subsets
are super keys.
B+ = BD
C+ = C
Since B and C are not super keys, BC is a minimal super key.
Since A, BC, CD, E are minimal super keys, they are
the candidate keys.
A, BC, CD, E
134
 Object Oriented Model in DBMS
• Object DBMSs add database functionality to object
programming languages.

• They bring much more than persistent storage of

programming language objects.

• A major benefit of this approach is the unification of the

application and database development into a seamless data
model and language environment. As a result, applications
require less code, use more natural data modeling, and code
bases are easier to maintain.

135
 Relationship Model in DBMS
• A branch of set theory that deals with logical relationships between sets.
The Relational Model underlies OOA/D Class Models.

• This is a more general model than the Relational Data Model.

• In an OOA/D context explicate identity and referential attributes are not

required.

• In an OOA/D context relationships are much more abstract than in the

Relational Data Model.

• In addition, the logical properties include behaviors as well as data.

136
 Relational Model
Example of tabular data in the relational model

137
A Sample Relational Database

138
 Network Model in DBMS
• The popularity of the network data model coincided with the popularity of
the hierarchical data model.

• Some data were more naturally modeled with more than one parent per
child.

• So, the network model permitted the modeling of many-to-many

relationships in data.

• The basic data modeling construct in the network model is the set
construct.

• A set consists of an owner record type, a set name, and a member record
type.
139
 DBMS Hierarchical Model
• The hierarchical data model organizes data in a tree structure.

• There is a hierarchy of parent and child data segments.

• This structure implies that a record can have repeating information,

generally in the child data segments.

• Data in a series of records, which have a set of field values attached to it.

• It collects all the instances of a specific record together as a record type.

140
Overall System
Architecture

141
142
 More
The following components of a DBMS are of interest to us:

• transaction manager
• buffer manager
• file manager
• authorization and integrity manager
• query optimizer

143
 Transaction Management
 A transaction is a collection of operations that performs a single logical
function in a database application

 The transaction manager performs two primary functions:

 backup and recovery
 concurrency control

 Backup and recovery ensures that the database remains in a consistent

(correct) state despite failures:
 system, power, network failures
 operating system crashes
 transaction failures.

 Concurrency-control involves managing the interactions among concurrent

transactions.

144
 Storage Management

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.

The storage manager is responsible for the following tasks:

– interaction with the file manager
 The file manager is responsible for managing the files that store data.
 formatting the data files
 managing free and used space in the data files
 defragmenting the data files
 inserting and deleting specific data from the files

– efficient storing, retrieving, and updating of data

145
Authorization and Integrity management

 The authorization & integrity manager performs two primary functions:

 data security
 data integrity

 Data security:
 ensure that unauthorized users can’t access the database
 ensure that authorized users can only access appropriate data

 Data integrity:
 in general, maintains & enforces integrity constraints
 maintains data relationships in the presence of data modifications
 prevents modifications that would corrupt established data relationships

146
 Query Optimization
 A given query can be implemented by a DBMS in many different ways.

 The query optimizer attempts to determine the most efficient strategy for
executing a given query.

 The strategy for implementing a given query is referred to as a query plan.

147
 Objectives
• Some common uses of database systems.
• File-based systems.
• Typical functions of a DBMS.
• Major components of the DBMS
environment.
• History of the development of DBMSs.
• Advantages and disadvantages of DBMSs
• Three-level architecture
 Examples of Database Applications

• Purchases from the supermarket

• Purchases using your credit card
• Booking a holiday at the travel agents
• Using the local library
• Taking out insurance
• Using the Internet
• Studying at university
• Many more …….
 Types of Databases and Database
Applications

• Numeric and Textual Databases

• Multimedia Databases
• Geographic Information Systems (GIS)
• Data Warehouses
• Real-time and Active Databases
A number of these databases and applications are described
later in the book (see Chapters 24,28,29)
 File-Based Systems
• Collection of application programs that
perform services for the end users (e.g.
reports).
• Each program defines and manages its own
data.
Limitations of File-Based Approach

• Separation and isolation of data

– Each program maintains its own set of data.
– Users of one program may be unaware of potentially
useful data held by other programs.

• Duplication of data
– Same data is held by different programs.
– Wasted space and potentially different values and/or
different formats for the same item.
 Basic Definitions
• Database: A collection of related data.
• Database Management System (DBMS): A
software package/ system to facilitate the
creation and maintenance of a computerized
database.
• Database System: The DBMS software
together with the data itself. Sometimes, the
applications are also included.
Database Management System (DBMS)
 Typical DBMS Functionality
• 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
• Concurrent Processing and Sharing by a set of
users and programs – yet, keeping all data valid
and consistent
 Typical DBMS Functionality
Other features:
– Protection or Security measures to
prevent unauthorized access
– “Active” processing to take internal
actions on data
– Presentation and Visualization of data
Components of DBMS Environment
• Hardware
– PC, workstation, mainframe, a network of computers.
• Software
– DBMS, operating system, network software (if
necessary) and also the application programs.
• Data
– Used by the organization and a description of this data
called the schema.
• Procedures
– Instructions and rules that should be applied to the
design and use of the database and DBMS.
• People
Roles in the Database Environment

• Data Administrator (DA)

• Database Administrator (DBA)
• Database Designers (Logical and Physical)
• Application Programmers
• End Users (naive and sophisticated)
 Example of a Database
(with a Conceptual Data Model)

• Mini-world for the example: Part of a UNIVERSITY

environment.
• Some mini-world entities:
– STUDENTs
– COURSEs
– SECTIONs (of COURSEs)
– (academic) DEPARTMENTs
– INSTRUCTORs
Note: The above could be expressed in the ENTITY-
RELATIONSHIP data model.
 Example of a Database
(with a Conceptual Data Model)
• Some mini-world relationships:
– SECTIONs are of specific COURSEs
– STUDENTs take SECTIONs
– COURSEs have prerequisite COURSEs
– INSTRUCTORs teach SECTIONs
– COURSEs are offered by DEPARTMENTs
– STUDENTs major in DEPARTMENTs

Note: The above could be expressed in the ENTITY-

RELATIONSHIP data model.
 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: 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
Approach
• Controlling redundancy in data storage and in
development and maintenance efforts.
• Sharing of data among multiple users.
• Restricting unauthorized access to data.
• Providing persistent storage for program Objects (in
Object-oriented DBMS’s )
• Providing Storage Structures for efficient Query
Processing
 Advantages of Using the Database
Approach

• Providing backup and recovery services.

• Providing multiple interfaces to different classes
of users.
• Enforcing integrity constraints on the database.
• Drawing Inferences and Actions using rules
 Disadvantages of DBMSs
• Complexity
• Size
• Cost of DBMS
• Additional hardware costs
• Cost of conversion
• Performance
• Higher impact of a failure
 Historical Development of Database
Technology
• Early Database Applications: The Hierarchical and
Network Models were introduced in mid 1960’s and
dominated during the seventies. A bulk of the worldwide
database processing still occurs using these models.
• Relational Model based Systems: The model that was
originally introduced in 1970 was heavily researched and
experimented with in IBM and the universities. Relational
DBMS Products emerged in the 1980’s.
 Historical Development of Database
Technology
• Object-oriented applications: OODBMSs were introduced in
late 1980’s and early 1990’s to cater to the need of complex
data processing in CAD and other applications. Their use has
not taken off much.
• Data on the Web and E-commerce Applications: Web
contains data in HTML (Hypertext markup language) with
links among pages. This has given rise to a new set of
applications and E-commerce is using new standards like
XML (eXtended Markup Language).
Extending Database Capabilities
• New functionality is being added to DBMSs in
the following areas:
– Scientific Applications
– Image Storage and Management
– Audio and Video data management
– Data Mining
– Spatial data management
– Time Series and Historical Data Management
The above gives rise to new research and development in incorporating
new data types, complex data structures, new operations and
storage and indexing schemes in database systems.
 When not to use a DBMS
• Main inhibitors (costs) of using a DBMS:
– High initial investment and possible need for additional
hardware.
– Overhead for providing generality, security, concurrency
control, recovery, and integrity functions.
• When a DBMS may be unnecessary:
– If the database and applications are simple, well
defined, and not expected to change.
– If there are stringent real-time requirements that may
not be met because of DBMS overhead.
– If access to data by multiple users is not required.
 When not to use a DBMS
• When no DBMS may suffice:
– If the database system is not able to handle the
complexity of data because of modeling
limitations
– If the database users need special operations not
supported by the DBMS.
Hierarchical & Network Model

Advantages and Disadvantages

172
 Hierarchical Model
The Hierarchical Data Model is a way of organizing a database
with multiple one to many relationships.

Was developed in the 1960s.

The Hierarchical model was essentially born from the first

mainframe database management system. It uses an upside-down
tree to structure data. The top of the tree is the parent and the
branches are children. Each child can only have one parent but a
parent can have many children.

173
 Hierarchical Model
The structure is based on the rule that one parent can have
many children but children are allowed only one parent.
This structure allows information to be repeated through
the parent child relations created by IBM and was
implemented mainly in their Information Management
System. (IMF), the precursor to the DBMS.

174
Hierarchical Model

175
• Advantages

• Have many different structures and forms.

• Structures data in an upside-down tree. (Simplifies data overview)
• Manages large amounts of data.
• Express the relationships between information.
• Many children per parent.
• Distribute data in terms of relationships.
• Improve data sharing.

176
• Disadvantages

• One parent per child.

• Complex (users require physical representation of database)
• Navigation system is complex.
• Data must be organized in a hierarchical way without compromising the
information.
• Lack structural independence.
• Many too many relationships not supported.
• Data independence.

177
 Network Model
• In 1965 C.W. Bachman developed the first network data model to present
complex data relationships more effectively than the hierarchical model.
He tried to impose a database standard with his model and also wanted to
improve database performance.

• It was in 1971 that the Conference on Data System Languages or CODASYL

officially or formally defined the Network model. The network databases
arrange its data as a directed graph and have a standard navigational
language.

178
 Network Model
• The network model is a database model conceived as a flexible way of
representing objects and their relationships. Its distinguishing feature is
that the schema, viewed as a graph in which object types are nodes and
relationship types are arcs, is not restricted to being a hierarchy or lattice.

• The network model replaces the hierarchical model with a graph thus
allowing more general connections among the nodes.

• The main difference of the network model from the hierarchical model is
its ability to handle many to many relationship. In other words it allow a
record to have more than one parent.

179
Network Model

180
• Advantages

• 1.) Conceptual simplicity-Just like the hierarchical model, the network model is
also conceptually simple and easy to design.
• 2.) Capability to handle more relationship types-The network model can handle
the one to many and many to many relationships which is real help in modelling
the real life situations.
• 3.) Ease of data access-The data access is easier and flexible than the
hierarchical model.
• 4.) Data integrity- The network model does not allow a member to exist without
an owner.
• 5.) Data independence- The network model is better than the hierarchical
model in isolating the programs from the complex physical storage details.
• 6.) Database standards

181
• Disadvantages

• 1.) System complexity- All the records are maintained using pointers and
hence the whole database structure becomes very complex.
•
2.) Operational Anomalies- The insertion,deletion and updating
operations of any record require large number of pointers adjustments.

• 3.) Absence of structural independence-structural changes to the

database is very difficult.

182
 Hierarchical Model

Data definition and implementation

183
 Data Definition in the Hierarchical Model
- Hierarchical data definition language (HDDL)
•record type
data item of a record type
key clause
parent
•virtual record type
virtual parent
•CHILD NUMBER clause (the left-to-right order)
•ORDER BY clause
(the order of individual records of the same record
type)
sequence key
- Example

SCHEMA NAME = COMPANY

HIERARCHIES = HIERARCHY1, HIERARCHY2

RECORD
NAME = EMPLOYEE
TYPE = ROOT OF HIERARCHY2
DATA ITEMS =
FNAME CHARACTER 15
MINIT CHARACTER 1
LNAME CHARACTER 15
SSN CHARACTER 9
BDATE CHARACTER 9
ADDRESS CHARACTER 30
- Example

SEX CHARACTER 1
SALARY CHARACTER 10
KEY = SSN CHARACTER 10
ORDER BY LNAME, FNAME

RECORD
NAME = DEPARTMENT
TYPE = ROOT OF HIERARCHY1
DATAITEMS =
DNAME CHARACTER 15
DNUMBER INTEGER
KEY = DNAME
KEY = DNUMBER
ORDER BY DNAME
- Example

RECORD
NAME = DLOCATION
PARENT = DEPARTMENT
CHILD NUMBER = 1
DATA ITEMS =
LOCATION CHARACTER 15

RECORD
NAME = DMANAGER
PARENT = DEPARTMENT
CHILD NUMBER = 3
DATA ITEMS =
MGRSTARTDATE CHARACTER 9
MPTR POINTER WITH VIRTUAL PARENT = EMPLOYEE
- Example

RECORD
NAME = PROJECT
PARENT = DEPARTMENT
CHILD NUMBER = 4
DATA ITEMS =
PNAME CHARACTER 15
PNUMBER INTEGER
PLOCATION CHARACTER 15
KEY = PNAME
KEY = PNUMBER
ORDER BY PNAME
- Example

RECORD
NAME = PWORKER
PARENT = PROJECT
CHILD NUMBER = 1
DATA ITEMS =
HOURS CHARACTER 4
WPTR POINTER WITH VIRTUAL PARENT = EMLPOYEE

RECORD
NAME = DEMPLOYEES
PARENT = DEPARTMENT
CHILD NUMBER = 2
DATA ITEM =
EPTR POINTER WITH VIRTUAL PARENT = EMPLOYEE
- Example

RECORD
NAME = DEPENDENT
PARENT = EMPLOYEE
CHILD NUMBER = 2
DATA ITEMS =
DEPNAME CHARACTER 15
SEX CHARACTER 1
BIRTHDATE CHARACTER 9
RELATIONSHIP CHARACTER 10
ORDER BY DESC BIRTHDATE
- Example

RECORD
NAME = ESUPERVISEE
PARENT = EMPLOYEE
CHILD NUMBER = 1
DATA ITEMS =
DEPNAME POINTER WITH VIRTUAL PARENT = EMLPOYEE
Data Manipulation in the Hierarchical Model
- Hierarchical data manipulation language (HDML)
•a record-at-a-time
•HDML must be embedded in a host language such as COBOL, PL/1,
Pascal, ...
user-work-area - programs
•currency indicators
- current of database: a single hierarchical schema and its
current
database records
- current of hierarchy for each hierarchical schema
- current of record type for each record type
•command classification
- retrieval: GET
- record update: INSERT, DELETE, REPLACE
- current record: GET HOLD
- GET
•GET FIRST <record type name> [WHERE <condition>]
•GET NEXT <record type name> [WHERE <condition>]

$GET FIRST EMPLOYEE WHERE SALARY < ‘20000.00’;

while DB_STATUS = 0 do
begin
writeln (P_EMPLOYEE.FNAME,
P_EMPLOYEE.LNMAE);
$GET NEXT EMPLOYEE WHERE SALARY <
‘20000.00’
end
-GET

• GET (FIRST | NEXT) PATH

<hierarchical path> [WHERE <condition>]

$GET FIRST PATH EMPLOYEE, DEPENDENT

WHERE EMPLOYEE.FNAME=‘John’ AND
DEPENDENT.DEPNAME=‘John’;
while DB_STATUS = 0 do
begin
writeln (P_EMPLOYEE.LNAME,
P_EMPLOYEE.BDATE,
P_DEPENDENT.BIRTHDATE);
$GET NEXT PATH EMPLOYEE, DEPENDENT
WHERE EMPLOYEE.FNAME=‘John’
AND

DEPENDENT.DEPNAME=‘John’
-GET

• GET NEXT <child record type name>

WITHIN [VIRTUAL] PARENT [<parent record type
name]
[WHERE <condition>]

$GET FIRST PATH DEPARTMENT, PROJECT

WHERE DEPARTMENT.DNAME=‘Research’;
while DB_STATUS = 0 do
begin
writeln (P_PROJECT.PNAME);
$GET NEXT PROJECT WITHIN PARENT
end;
- Calculating aggregate functions: COUNT, AVERAGE, ...

$GET FIRST PATH DEPARTMENT, DEMPLOYEE;

while DB_STATUS = 0 do
begin
total_sal :=0; no_of_emps :=0;
writeln (P_DEPARTMENT.DNAME);
while DB_STATUS = 0 do
begin
$GET VIRTUAL PARENT EMPLOYEE;
total_sal := total_sal +
conv_sal(P_EMPLOYEE.SALARY);
no_of_emps := no_of_emps +1;
$GET NEXT DEMPLOYEES WITHIN PARENT
DEPARTMENT
end
writeln (‘no of emps =’, no_of_emps, ‘avg sal of
emps =’,
total_sal/no_of_emps);
$GET NEXT PATH DEPARTMENT, DEMPLOYEES
- Update: INSERT, DELETE, REPLACE
P_EMPLOYEE.FNAME := ‘John’;
P_EMPLOYEE.LNAME := ‘Smith’;
P_EMPLOYEE.MINIT := ‘F’;
P_EMPLOYEE.SSN := ‘567875432’;
P_EMPLOYEE.ADDRESS := ‘40 N.W. 80TH ...’;
P_EMPLOYEE.BDATE := ‘10-Jan-55’;
P_EMPLOYEE.SEX := ‘M’;
P_EMPLOYEE.SALARY := ‘30000.00’;
$INSERT EMPLOYEE FROM P_EMPLOYEE;
- Update: INSERT, DELETE, REPLACE
$GET HOLD FIRST EMPLOYEE WHERE SEX = ‘M’;
while DB_STATUS = 0 do
begin
writeln (P_EMPLOYEE.LNAME,
P_EMPLOYEE.FNAME);
$DELETE EMPLOYEE
$GET HOLD NEXT EMPLOYEE WHERE SEX = ‘M’
end;
- Update: INSERT, DELETE, REPLACE
$GET FIRST PATH DEPARTMENT, DEMPLOYEE
WHERE DNAME = ‘Reseach’;
while DB_STATUS = 0 do
begin
$GET HOLD VIRTUAL PARENT EMPLOYEE OF
DEMPLOYEES
P_EMPLOYEE.SALARY := P_EMPLOYEE.SALARY * 1.1;
$REPLACE EMPLOYEE FROM P_EMPLOYEE
$GET NEXT DEMPLOYEES WHERE PARENT
DEPARTMENT
end;
 Parent/child relationships
department
dname dnumber mgrname mgrstartdate

employee project
name ssn bdate address pname pnumber plocation

Two parent/child relationships are in the above schema:

• department/employee
• department/project
 Parent/child instances
department
dname dnumber mgrname mgrstartdate

employee project
name ssn bdate address pname pnumber plocation

Using the data we had previously seen in Ch 7, we can depict the following 3 instances of
department/employee:

Headquarters

Research
Administration
Borg

Smith Wong Narayan English

Zelaya Wallace Jabbar
 department
dname dnumber mgrname mgrstartdate

employee project
name ssn bdate address pname pnumber plocation

Using the data we had previously seen in Ch 7, we can depict the following 3 instances of
department/project:

Headquarters
Research
Administration
Reorganization

ProductX ProductY ProductZ

Computerization Newbenefits
Navigational - not set-oriented - you retrieve one record
at a time
Data Manipulation
Retrieval
GU, Get unique
GU, GN, GNP, ISRT, DLET, REPL ar
command names

GN, Get next retrieve a specific record

GNP, Get next within parent using your current position, get the next
Updating record in the database
ISRT, Insert using your current
position, get the next child
DLET, Delete
record for that parent
REPL, Replace
e IMS
 Navigating through the database
Consider the database
Headquarters
Research

Borg Reorganization
Smith ProductX
Wong ProductY Administration
Narayan ProductZ
English

Zelaya Computerization
Wallace Newbenefits
Jabbar
GU Department (dname=headquarters)
Loop Program would retrieve the
GNP
Department record and all of its
exit when status code = ????
End Loop dependents
Relational & E-R Model

Advantages and Disadvantages

205
 Relational Model
• The relational data model was introduced in 1970 by Edgar F.
Codd. He worked for IBM. All data is represented as simple
tabular data structures which the user can access through a
high-level non-procedural language. In 1974 IBM proposed a
new high-level non-procedural language - SEQUEL (renamed
into SQL in 1990).

206
• Advantages

• Structured independence is promoted.

• Users do not have to know the physical representation of the database.
• Use of SQL language to access data.
• Easier database design.
• Tabular view improves simplicity.
• Support large amounts of data.
• Data independence.
• Multi-level relationships between data sets
• No need to predefined data relationships.

207
• Disadvantages

• Data anomalies.

• People need training if they want to use the system effectively and
efficiently.

208
 E-R Model

• Dr. Peter Pin-Shan Chen introduced the entity

relationship data model in 1976. It is a graphical
representation of entities that became popular very
quickly because it complemented the relational
database model concepts.

209
• Advantages

• A very important data modelling tool.

• An extended Entity-Relationship diagram allows more details.
• Multi-valued attributes.
• Structured independence.
• Organize the data into categories defining entities & the relationships
between them.
• Visual representation.
• Data independence.

210
• Disadvantages

• Limited relationship representation.

• Loss of information (when attributes are removed from entities).
• No data manipulation language.
• Limited constraint representation.

211
 Transactions concepts

Collection of operations that form

a single logical unit of work are
called transactions.

212
 Transactions concepts
• A database system must ensure
proper execution of transactions
despite failures.
• It must manage concurrent
execution of transactions to avoid
inconsistency.

213
 Transactions concepts
• A transaction is a unit of program
execution that accesses and possibly
updates various data items.
• A program contains statements of
the form begin transaction and end
transaction.

214
 Transactions concepts
• The transaction consists of all
operations executed between the
begin transaction and end
transaction.

215
 ACID PROPERTIES

To ensure integrity of the data the

database system should maintain
following transaction properties.
1. Atomicity
2. Consistency
3. Isolation
4. Durability
216
• Atomicity: Either all operations of
the transaction are reflected
properly in the database or none are.
• Consistency: Execution of a
transaction in isolation preserves the
consistency of the database.

217
• Isolation:
Even though multiple
transactions execute concurrently
each transaction is unaware of other
transactions executing concurrently
in the system.

218
• Durability:
After a transaction completes
successfully the changes it has made to the
database persist even if there are system
failures.

All acid properties must executed properly for any

transaction.

219
 Transaction Operations
• It has two basic operations.
1. Read(x) ,
which transfers the data
item x from the database to a
local buffer belonging to the
transaction that executed the
read operation.
220
 Transaction Operations
2. Write(x) ,
which transfers the data
item x from the local buffer to the
transaction that executed the Write
back to the database.

221
 Example
Let T(i) be a transaction that transfers Rs. 50 from
account A to account B. This transaction can be
defined as:
T(i): read (A)
A:= A-50
write(A)
read(B)
B:= B+50
write(B) 222
Structured Query
Language (SQL)
commands

DDL, DML, DCL and TCL

223
 SQL
• Language for describing database
schema and operations on tables

• DDL, DML, DCL and TCL are

considered sublanguages of SQL

224
 SQL
• The four main categories of SQL
statements are as follows:
1. DML (Data Manipulation Language)
2. DDL (Data Definition Language)
3. DCL (Data Control Language)
4. TCL (Transaction Control Language)

225
SQL language statements

226
 DML
• DML is abbreviation of Data
Manipulation Language.
• It is used to retrieve, store, modify,
delete, insert and update data in
database.
• DML statements affect records in a
table.
227
 DML Operations
• SELECT – Retrieves data from a
table
• INSERT – Inserts data into a table
• UPDATE – Updates existing data
into a table
• DELETE – Deletes all records from
a table
228
 DDL
• DDL is abbreviation of Data
Definition Language.
• It is used to create and modify the
structure of database objects in
database.
• It handles the design and storage of
database objects.
229
 DDL Operations
• CREATE – Creates objects in the
database
• ALTER – Alters objects of the
database
• DROP – Deletes objects of the
database
• TRUNCATE – Deletes all records from
a table and resets table
identity to initial value. 230
 DCL
• DCL is abbreviation of Data Control
Language.
• It is used to create roles,
permissions, and referential
integrity as well it is used to control
access to database by securing it.

231
 DCL Operations
• GRANT –
– Gives user’s access privileges to database.
– It allows users to read/write on certain database
objects
• REVOKE –
– Withdraws user’s access privileges to
database given with the GRANT command
– keeps users from read/write permission on
database objects
232
 TCL
• TCL is an abbreviation of Transactional
Control Language.
• It is used to control and manage different
transactions occurring within a database
and to maintain integrity of data within
SQL statements.

233
 TCL Operations
• BEGIN Transaction – opens a
transaction
• COMMIT Transaction – commits a
transaction
• ROLLBACK Transaction –
ROLLBACK a
transaction in case of any error

234
 Distributed Systems
and
Distributed Databases

235
 Distributed System
• A distributed system is a model in which
components located on networked
computers communicate and coordinate
their actions by passing messages.
• They help in sharing different resources
and capabilities to provide users with a
single and integrated coherent network.

236
237
 Features of Distributed System
• A distributed system allows resource
sharing, including software by systems
connected to the network at the same
time.
• Components in the system are
concurrent. The components could be
multiple but will generally be
autonomous in nature.
238
 Features of Distributed System
• A global clock is not required in a
distributed system. The systems can be
spread across different geographies.
• Compared to other network models,
there is greater fault tolerance in a
distributed model.

239
 Goals of Distributed System
• Transparency:
Achieving the image of a
single system image without concealing the
details of the location, access, migration,
concurrency, failure, relocation, persistence
and resources to the users.
• Openness:
Making the network
easier to configure and modify.
240
 Goals of Distributed System
• Reliability:
Compared to a single
system, a distributed system should be
highly capable of being secure,
consistent and have a high capability of
masking errors.

241
 Goals of Distributed System
• Performance:
Compared to other models,
distributed models are expected to give a
much-wanted boost to performance.
• Scalability:
Distributed systems should
be scalable with respect to geography,
administration or size.
242
 Challenges of Distributed System

• Security is a big challenge in a distributed

environment, especially when using public
networks.
• Fault tolerance could be tough when the
distributed model is built based on
unreliable components.

243
 More Challenges of Distributed
System

• Coordination and resource sharing can be

difficult if proper protocols or policies are
not in place.
• Process knowledge should be put in place
for the administrators and users of the
distributed model.

244
 Distributed system examples
• telecommunication networks:
– Telephone and cellular networks,
– Computer networks as Internet,
– Wireless sensor networks,
– Routing algorithms,

245
 Distributed system examples
• Network applications:
– World Wide Web,
– Multiplayer Online games
– Virtual Reality communities,
– Network file systems
– distributed information processing systems
such as banking systems and airline reservation
systems;
246
 Distributed system examples

• Real time process control:

– aircraft control systems,
– Industrial control systems

247
 Distributed Database

A single logical database that is spread

physically across computers in multiple
locations that are connected by a data
communications link

248
249
 Applications of Distributed
Database
• Business unit autonomy and distribution
• Data sharing
• Data communication costs
• Data communication reliability and costs
• Multiple application vendors
• Database recovery
• Transaction and analytic processing 250
DD Environments

251
 Types of Distributed database
• Homogeneous DD –
If the data is distributed but all servers
run the same DBMS software.
• Heterogeneous DD –
If different sites run under the control
of different DBMS, essentially
autonomously, are connected to enable
access to data from multiple sites.
252
• Homogeneous –
Same DBMS at each node

– Autonomous - Independent DBMSs

– Non-autonomous - Central,
coordinating DBMS
– Easy to manage, difficult to enforce

253
• Heterogeneous –
Different DBMSs at different nodes

– Systems – With full or partial DBMS

functionality
– Gateways - Simple paths are created to
other databases without the benefits of one
logical database
– Difficult to manage, preferred by
independent organizations
254
• Systems - Supports some or all
functionality of one logical database
– Full DBMS Functionality - All distributed DB
functions
– Partial-Multi database- Some distributed DB
functions

255
Partial Multi-database:

Federated - Supports local databases for

unique data requests
– Loose Integration - Local dbs have their own
schemas
– Tight Integration - Local dbs use common schema
Unfederated - Requires all access to go through a
central, coordinating module

256
 Advantages of Distributed
Database over Centralised
Database
• Increased reliability/availability
• Local control over data
• Modular growth
• Lower communication costs
• Faster response for certain queries

257
 Disadvantages of Distributed
Database compared to Centralised
Database

• Software cost and complexity

• Processing overhead
• Data integrity exposure
• Slower response for certain queries

258
End of Today’s Lecture

259