Module 1

❖ Concept & Overview of Database Management Systems (DBMS) - Characteristics

of Database system, Database Users, structured, semi-structured and unstructured
data. Data Models and Schema - Three Schema architecture. Database Languages,
Database architectures and classification.

❖ ER model - Basic concepts, entity set & attributes, notations, Relationships and
constraints, cardinality, participation, notations, weak entities, relationships of
degree 3.
Introduction
• Data
– known facts that can be recorded and that have implicit meaning
– For example, consider the names, telephone numbers, and addresses of
the people you know
• A database
– is a collection of related data
– Is a centralized and structured set of data stored on a computer system
– Provides facilities for retrieving, adding, modifying, and deleting the
data when required retrieved data into useful information
Database- Implicit properties

• A database has the following implicit properties:

– A database represents some aspect of the real world, sometimes called
the miniworld or the universe of discourse (UoD).
– A database is a logically coherent collection of data with some inherent
meaning. A random assortment of data cannot correctly be referred to
as a database.
– A database is designed, built, and populated with data for a specific
purpose.
Database Management Systems (DBMS)

• A database management system (DBMS) is a collection of programs that

enables users to create and maintain a database.

• The DBMS is a general-purpose software system that facilitates the processes

of defining, constructing, manipulating, and sharing databases among various
users and applications.
Functions of DBMS

• Defining a database involves specifying the data types, structures, and

constraints of the data to be stored in the database. The database definition
or descriptive information is also stored by the DBMS in the form of a
database catalog or dictionary, it is called meta-data.
• Constructing the database is the process of storing the data on some storage
medium that is controlled by the DBMS.
• Manipulating a database includes functions such as querying the database
to retrieve specific data, updating the database to reflect changes in the
miniworld, and generating reports from the data.
• Sharing a database allows multiple users and programs to access the
database simultaneously.
• Other important functions provided by the DBMS include protecting the
database and maintaining it over a long period of time.
• Protection includes system protection against hardware or software
malfunction (or crashes) and security protection against unauthorized or
malicious access.
• A typical large database may have a life cycle of many years, so the DBMS
must be able to maintain the database system by allowing the system to
evolve as requirements change over time.
Example of a Simple Database
Database System =DATABASE+DBMS
ARCHITECTURE

• The database and the DBMS

softeare together is called a
database system
Characteristics of the Database Approach

• Older approach – Programing with files

– For example, one user, the grade reporting office, may keep files on
students and their grades. Programs to print a student’s transcript and to
enter new grades are implemented as part of the application.
– A second user, the accounting office, may keep track of students’ fees
and their payments.
– Although both users are interested in data about students, each user
maintains separate files and programs to manipulate these files—
because each requires some data not available from the other user’s
files.
– This redundancy in defining and storing data results in wasted storage
space and in redundant efforts to maintain common up-to-date data.
Characteristics of the Database Approach

• Database approach SINGLE STORAGE PLACE avoid redundancy

– The main characteristics of database approach are

• Self-describing nature of a database system
• Insulation between programs and data and data abstraction
• Support of multiple views of the data
• Sharing of data and multi-user transaction processing:
Sharing of data and multi-user transaction processing:
Allowing a set of concurrent users to retrieve from and to update the
database.
Concurrency control within the DBMS guarantees that each transaction is
correctly executed or aborted
Recovery subsystem ensures each completed transaction has its effect
permanently recorded in the database
OLTP (Online Transaction Processing) is a major part of database
applications; allows hundreds of concurrent transactions to execute per
second.
OLTP is a type of data processing that consists of executing a number of
transactions occurring concurrentl
• Self-describing nature of a database system
• A database system is referred to as self-
describing because it not only contains the
database itself, but also the complete
definition or description of the database
structure and constraints
• This information is stored in dbms catalog
and is called meta-data
• Metadata contains information such as the
structure of each file, type and data format
of each item, and various constraints on the
data
• Catalog is used by DBMS software and by
the users who need information about the
database structure
 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.

change on structures without affecting accessing programs

• Insulation between programs and data, and data abstraction
– In file-based system, the structure of the data files is defined in the programs,
so if a user wants to change the structure of a file, all the programs that access
that file might need to be changed as well.
– In contrast, in the database approach, the data structure is stored in the system
catalog and not in the programs. so such changes in programs need not be
requited in most cases
– This insulation between the programs and the data is also called program-
data independence, and the characteristics that allows program- data
independence is called data abstraction
– Data abstraction :
• A data model is used to hide storage details and present the users with a
external view of the database.
• Data Abstraction is a process of hiding unwanted or irrelevant details
from the end user
File System Vs DBMS
Basis File system DBMS
DIRECTLY STORED TO STORAGE MEDIUM
Structure Manages and organises the file Software used for
in a storage medium within a managing the database
computer
Data Redundancy Redundant data can be present in Redundant data can’t be
a file system present in DBMS

Backup and It doesn’t provide backup and It provides backup and

Recovery recovery of data if it is lost recovery of data even if it
is lost

Query processing There is no efficient query Efficient query processing

processing

Security Constraints Provides less security in Provides more security

comparison to DBMS mechanisms
 2nd pdf

Database Users Database administrators, Database designers,

End-users
System analysts and application developers

• Users may be divided into

– Those who actually use and control the database content, and those
who design, develop and maintain database applications (called “Actors
on the Scene”)
– Those who design and develop the DBMS software and related tools,
and the computer systems operators (called “Workers Behind the
Scene”)

System designers and implementers,

Tool developers
Operators and maintenance personne
Actors on the scene - Database Administrators

• Chief administrator to oversee and manages the database system

• The Database Administrator (DBA) is responsible for authorizing access to
the database, coordinating and monitoring its use, and acquiring software
and hardware resources as needed.
• The DBA is accountable for problems such as security breaches and poor
system response time.
• In large organizations, the DBA is assisted by a staff that carries out these
functions.
 Actors on the scene - Database Designers

• responsible for identifying the data to be stored in the database

• responsible for choosing appropriate structures to represent and store the
data
• responsible to communicate with all prospective database users in order to
understand their requirements and to create a design that meets these
requirements
• interact with each potential group of users and develop views of the
database
Actors on the scene - End Users
• People whose jobs require access to the database for querying, updating, and
generating reports
• There are several categories of end users:
– Casual end users
• occasionally access the database, but they may need different
information each time.
• Use a sophisticated database query language to specify their requests
middle- or high-level managers or other occasional browsers.
• Casual users learn only a few facilities that they may use repeatedly.
– Naive or parametric end users
• Their main job function revolves around constantly querying and
updating the database, using standard types of queries and updates—
called canned transactions
• need to learn very little about the facilities provided by the DBMS
• Users of mobile apps mostly fall in this category
• Bank tellers, Reservation agents for airlines, hotels and car rental
companies
Actors on the scene - End Users

- Sophisticated end users

• Sophisticated end users include engineers, scientists, business analysts
• thoroughly familiarize themselves with the facilities of the DBMS in order
to implement their own applications to meet their complex requirements.
• Sophisticated users try to learn most of the DBMS facilities in order to
achieve their complex requirements.
– Standalone users
• maintain personal databases by using ready-made program packages
• Standalone users typically become very proficient in using a specific
software package
• An example is the user of a tax program that creates its own internal
database.
• Another example is a user that maintains a database of personal photos and
videos.
Actors on the scene - System Analysts and Application Programmers
(Software Engineers)

• System analysts
– determine the requirements of end users, especially naive and
parametric end users
– develop specifications for standard canned transactions that meet these
requirements.
• Application programmers
– implement these specifications as programs, then they test, debug,
document, and maintain these canned transactions.
• Such analysts and programmers—commonly referred to as software
developers or software engineers
Workers behind the Scene

• DBMS system designers and implementers

– design and implement the DBMS modules and interfaces as a software

package

• Tool developers

– design and implement tools—the software packages that facilitate database

modeling and design, database system design, and improved performance

• Operators and maintenance personnel (system administration personnel)

– are responsible for the actual running and maintenance of the hardware and
software environment for the database system.
Advantages of Using the DBMS Approach

• Controlling Redundancy
– Storing same data multiple times leads to duplication of effort,
wastage of storage space and inconsistency.
– Usually database stores a data only at one place which ensures
consistency and saves storage space
• Restricting Unauthorized Access
– DBMS provides security and authorization subsystem, which the
DBA uses to create accounts and to specify account restriction.
– Providing Persistent Storage for Program Objects
• Providing Persistent Storage for Program Objects
• Databases can be used to provide persistent storage for program
objects and data structures. This is one of the main reasons for object-
oriented database systems, which offers data structure compatability
with different object-oriented programming languages.
• Providing Storage Structures and Search Techniques for Efficient Query
Processing
• Must provide capabilities for efficiently executing queries and
updates.
• Auxiliary files called indexes are used for speeding up disk accesses.
• The query processing and optimization module of the DBMS is
responsible for choosing an efficient query execution plan for each
query based on the existing storage structures
• Providing Backup and Recovery
– The backup and recovery subsystem of the DBMS is responsible for
recovering from hardware or software failures.
• Representing Complex Relationships among Data
– A DBMS must have the capability to represent a variety of complex
relationships among the data, to define new relationships as they arise,
and to retrieve and update related data easily and efficiently.
• Enforcing Integrity Constraints
– Most database applications have certain integrity constraints that must
hold for the data.
– A DBMS should provide capabilities for defining and enforcing these
constraints.
• Permitting Inferencing and Actions Using Rules
– Some database systems provide capabilities for defining deduction
rules for inferencing new information from the stored database facts.
Such systems are called deductive database systems.
• Potential for Enforcing Standards.
– The database approach permits the DBA to define and enforce
standards among database users
• Reduced Application Development Time. based on database data
– Developing a new application for to work on top of database takes very
less time
• Flexibility.
– DBMS allows to make changes to the structure of the database without
affecting the stored data and the existing application programs.
• Availability of Up-to-Date Information.
– As soon as one user’s update is applied to the database, all other users
can immediately see this update.
 Disdvantages of Using the DBMS Approach

• Cost of hardware and software

• Cost of Data Conversion

• Complex Design

• Cost of Staff training

Types of Data
matte pdf

• There are three types of data

– Structured Data

– Semi structured Data

– Unstructured Data
Structured Data
• Data whose elements are addressable for effective analysis

• Structured data is generally tabular data that is represented by columns

and rows in a database.

• Databases that hold tables in this form are called relational databases.
• The mathematical term “relation” specify to a formed set of data held
as a table.

• In structured data, all row in a table has the same set of columns, stored
in RDBMS
• SQL (Structured Query Language) programming language used for
structured data.
• Semi- structured data
– It falls between structured and unstructured data
– Semi-structured data is information that doesn’t consist of
Structured data (relational database) but still has some structure
to it.
– Semi-structured data consist of documents held in JavaScript
Object Notation (JSON) format.
– It also includes key-value stores and graph databases.
– Examples : E-mail, HTML Files
• Unstructured Data
– Data which is not organized in a
predefined manner
– Does not have a predifined data
model
– Not a good fit for a mainstream
relational database
– Example : Word, PDF, Text, Media
logs
Properties Structured Data Semi-structured Data Unstructured Data

Technology Based on Relational Based on XML/RDF Based on character

database table (Resource Description and binary data
Framework)

Transaction Matured transaction and Transaction is adapted from No transaction

management various concurrency DBMS not matured management and no
techniques concurrency

Version Versionining over rows, Versionining over tuples or Versioned as a whole

management tables graph is possible

Flexibility Less flexible More flexible than More flexible

structured data

Query Structured Query allow Queries over anonymous Only textual queries
performance complex joining nodes are possible are possible
Data Models

• A data model—a collection of concepts that can be used to describe

the structure of a database
• It provides the necessary means to achieve abstraction.
• Data Model gives us an idea that how the final system will look like
after its complete implementation.
• Data model is an abstract model, that organizes the elements of data
in a certain format.
• Most data models also include a set of basic operations for
specifying retrievals and updates on the database.
Why Data Model?
• The primary goal of using data model are:
– Ensures that all data objects required by the database are accurately
represented. Omission of data will lead to creation of faulty reports and
produce incorrect results.
different level
– A data model helps to design the database at the conceptual, physical
and logical levels.
– Data Model structure helps to define the relational tables, primary and
foreign keys and stored procedures.
– It provides a clear picture of the base data and can be used by database
developers to create a physical database.
– It is also helpful to identify missing and redundant data.
Categories of Data Models
conceptual logical physical

• High-level or conceptual data models

– High-level or conceptual data models provide concepts that are
close to the way many users perceive data

– This Data Model defines WHAT the system contains.

– Conceptual Data Model use concepts such as entities, attributes

and relationships
 Categories of Data Models -High-level or conceptual data models

– Entity: A real-world thing (table/relation)

– Attribute: Characteristics or properties of an

entity(fields of a table)

– Relationship: Dependency or association between two

entities

• Data model example:

– Customer and Product are two entities. Customer

number and name are attributes of the Customer entity

– Product name and price are attributes of product entity

– Sale is the relationship between the customer and

product
 Categories of Data Models- Representational Data Model
use records
• Representational
0 (or implementation or logical )Data Model
– Representational (or implementation) data models, which provide
concepts that may be easily understood by end users but that are
not too far removed from the way data is organized in computer
storage.
– Representational data models hide many details of data storage on
disk but can be implemented on a computer system directly.
– It is used most frequently in commercial DBMSs
– It includes relational model, network model and hierarchical
model
– They represent data by using record structure, hence are
sometimes called record- based data model.
Categories of Data Models - Physical Data Model

• Physical Data Model (Low level)

– low-level or physical data models
provide concepts that describe the
details of how data is stored on the
computer storage media
– Concepts provided by low-level data
models are generally meant for
computer specialists
– Describes how data is stored in the
computer by representing information
such as record formats, record orderings
and access paths
– An access path is a structure that makes
the search for particular database
records efficient
Schemas, Instances, and Database State

• The description of a database is called the database schema

• It is specified during database design and is not expected to change
frequently.
illustruction
• A displayed schema is called a schema diagram
• Each object in the schema is called a schema construct e.g. STUDENT,
COURSE.

• A schema diagram displays only some aspects of a schema, such as the

names of record types and data items, and some types of constraints.
Schema - Example
Schemas, Instances, and Database State
• The data in the database at a particular moment in time is called a database
state or snapshot.
• It is also called the current set of occurrences or instances in the database.
• The database state changes every time the database is updated.
• Initial Database State:
– Refers to the database state when it is initially loaded into the system.
• Valid State:
– A state that satisfies the structure and constraints of the database.
• Schema is also called intension.
• Data base State is called an extension of the schema.
Example of a database state
Three-Schema Architecture
The goal of three-schema architecture is to seperate the user application
and the physical database
 Three-Schema Architecture

• Defines DBMS schemas at three levels

– The internal level has an internal schema, which describes the physical
storage structure of the database. The internal schema uses a physical data
model and describes the complete details of data storage and access paths for
the database.

– The conceptual level has a conceptual schema, which describes the structure
of the whole database for a community of users. The conceptual schema
hides the details of physical storage structures and concentrates on
describing entities, data types, relationships, user operations, and constraints.
Usually, a representational data model is used to describe the conceptual
schema
Three-Schema Architecture

• The external or view level includes a number of external schemas or

user views. Each external schema describes the part of the database that
a particular user group is interested in and hides the rest of the database
from that user group. Each external schema is typically implemented
using a representational data model
 Three-Schema Architecture
• The DBMS must transform a request
specified on an external schema into a
request against the conceptual schema,
and then into a request on the internal
schema for processing over the stored
database.
• If the request is a database retrieval, the
data extracted from the stored database
must be reformatted to match the user’s
external view.
• The processes of transforming requests
and results between levels are called
mappings.
Three-Schema Architecture – Data Independence

• Data independence, which can be defined as the capacity to change the

schema at one level of a database system without having to change the
schema at the next higher level

• Two types of data independence:

– Logical data independence

– Physical data independence

Three-Schema Architecture – Data Independence

• Logical Data Independence:

– The capacity to change the conceptual schema without having to
change the external schemas or application programs.
– Only mapping need to be changed
– Due to Logical independence, any of the below change will not affect
the external layer.
• Add/Modify/Delete a new attribute, entity or relationship is
possible without a rewrite of existing application programs
• Merging two records into one
• Breaking an existing record into two or more records
 Three-Schema Architecture – Data Independence
• Physical Data Independence:

– The capacity to change the internal schema without having to change the
conceptual schema.

– Due to Physical independence, any of the below change will not affect the
conceptual layer.
• Modifying the file organization technique in the Database

• Switching to different data structures.

• Changing the access method.

• Modifying indexes.

• Changes to compression techniques or hashing algorithms.

• Change of Location of Database from say C drive to D Drive

Three-Schema Architecture – Data Independence
Database Languages

• A DBMS has an appropriate languages and interfaces to express

database queries and updates.

• Database languages can be used to read, store and update the data in
the database.
Database Languages- DDL
• Data Definition Language (DDL)
– used to define database structure or pattern
– used to define the internal and conceptual schema
– used by the DBA and database designers
– Here are the lists of tasks that come under DDL
• CREATE - used to create objects in the database
• ALTER - used to alters the structure of the database
• DROP - used to delete objects from the database
• TRUNCATE - used to remove all records from a table, including
all spaces allocated for the records are removed
• COMMENT - used to add comments to the data dictionary
• RENAME - used to rename an object
Database Languages- SDL
• Storage Definition Language (SDL)
– In DBMSs where a clear separation is maintained between the
conceptual and internal levels, the DDL is used to specify the
conceptual schema only.
– Storage definition language (SDL), is used to specify the internal
schema.
– The mappings between the two schemas may be specified in either one
of these languages.
– In most relational DBMSs today, there is no specific language that
performs the role of SDL.
– Instead, the internal schema is specified by a combination of functions,
parameters, and specifications related to storage of files.
– These permit the DBA staff to control indexing choices and mapping of
data to storage.
Database Languages- VDL
• View Definition Language (VDL)
– To specify user views and their mappings to the conceptual schema, but
in most DBMSs the DDL is used to define both conceptual and external
schemas.
– In relational DBMSs, SQL is used in the role of VDL to define user or
application views as results of predefined queries
• Taking an example CREATE TABLE f (x int, y varchar(25));.
• SDL: the storage for the row int, varchar(25).
• DDL: the schema: f(x,y) a relational tuple with two slots.
• VDL: the "view" into it, which is just a relationship by the same
name as the table.
 Database Languages- DML
• Data Manipulation Language (DML)
– Data Manipulation Language (DML) statements are used to manage data within
schema objects.
– Used to manipulate the database.
– Typical manipulations include retrieval, insertion, deletion, and modification of
the data.
– Here are the lists of tasks that come under DML:
• SELECT - It retrieves data from a database
• INSERT - It inserts data into a table
• UPDATE - It updates existing data within a table
• DELETE - It deletes all records from a table, the space for the records remain
• MERGE - UPSERT operation (insert or update)
• CALL - It calls a PL/SQL or Java subprogram
• EXPLAIN PLAN - It explains the access path to data
• LOCK TABLE - It controls concurrency
Database Languages- DML
• There are two main types of DMLs.
– A high-level or nonprocedural DML can be used on its own to specify
complex database operations concisely.
– High level DMLs can specify and retrieve many records in a single
DML statement, therefore, they are called set-at-a-time or set-oriented
DMLs.
– A query in a high-level DML often specifies which data to retrieve
rather than how to retrieve it, therefore, such languages are also called
declarative
– Example: SQL
Database Languages- DML
• A low level or procedural DML must be embedded in a general-purpose
programming language.
• This type of DML typically retrieves individual records or objects from the
database and processes each separately.
• Therefore, it needs to use programming language constructs, such as
looping, to retrieve and process each record from a set of records.
• Low-level DMLs are also called record-at-a-time
Database Languages- DCL
• Data Control Language (DCL)
– DCL (Data Control Language) includes commands like GRANT and
REVOKE, which are useful to give "rights & permissions."
– Using DCL command, it allows or restricts the user from accessing
data in database schema.
– Commands that come under DCL:
► Grant: This command is use to ► Revoke: It is useful to back
give user access privileges to a permissions from the user.
database. ► Syntax:
► Syntax:
► REVOKE privilege_name ON
► GRANT SELECT, UPDATE ON object_name FROM {user_name
MY_TABLE TO SOME_USER, |PUBLIC |role_name}
ANOTHER_USER; ► For example: REVOKE
► For example: GRANT SELECT SELECT, UPDATE ON student
ON Users TO 'Tom'@'localhost; FROM BCA, MCA;
 Database Languages- TCL
• Transaction Control Language (TCL)
– Transaction Control statements are used to run the changes
made by DML statements.
– It allows statements to be grouped into logical transactions.
– Commands that come under TCL:

► COMMIT - It saves the work done

► SAVEPOINT - It identifies a point in a transaction to which you can
later roll back
► SET TRANSACTION - It changes the transaction options like
isolation level and what rollback segment to use
► ROLLBACK - It restores the database to original since the last
COMMIT
DBMS Interfaces

• A database management system (DBMS) interface is a user interface which

allows for the ability to input queries to a database without using the query
language itself.
– Menu-Based Interfaces for Web Clients or Browsing
– Forms-Based Interfaces
– Graphical User Interface
– Natural language Interfaces
– Speech Input and Output
– Interfaces for parametric users
– Interfaces for DBA
• Menu-Based Interfaces for Web Clients or Browsing.
• These interfaces present the user with lists of options (called
menus) .
• Pull-down menus are a very popular technique in Web-based user
int
• Forms-Based Interfaces
• A forms-based interface displays a form to each user.
• Users can fill out all of the form entries to insert new data, or they
can fill out only certain entries, in which case the DBMS will
retrieve matching data for the remaining entries.
• Forms are usually designed and programmed for naive users
• Natural Language Interfaces
• These interfaces accept requests written in English or some other language
and attempt to understand them.
• A natural language interface usually has its own schema, which is similar to
the database conceptual schema, as well as a dictionary of important words.
• The natural language interface refers to the words in its schema, as well as
to the set of standard words in its dictionary, to interpret the request.
• Today, we see search engines that accept strings of natural language (like
English or Spanish) words and match them with documents at specific sites
(for local search engines) or Web pages on the Web at large (for engines
like Google or Ask).
• They use predefined indexes on words and use ranking functions to retrieve
and present resulting documents in a decreasing degree of match
• Speech Input and Output
• Limited use of speech as an input query and speech as an answer to a question
or result of a request is becoming commonplace.
• Applications with limited vocabularies such as inquiries for telephone
directory, flight arrival/departure, and credit card account information are
allowing speech for input and output to enable customers to access this
information.
• The speech input is detected using a library of predefined words and used to set
up the parameters that are supplied to the queries.
• For output, a similar conversion from text or numbers into speech takes place.
• Interfaces for Parametric Users
• Parametric users, such as bank tellers, often have a small set of operations that
they must perform repeatedly.
• For example, a teller is able to use single function keys to invoke routine and
repetitive transactions such as account deposits or withdrawals, or balance
inquiries.
• Systems analysts and programmers design and implement a special interface
• Interfaces for the DBA
• Most database systems contain privileged commands that can be used only
by the DBA staff.
• These include commands for creating accounts, setting system parameters,
granting account authorization, changing a schema, and reorganizing the
storage structures of a database.
• Graphical User Interfaces
• A GUI typically displays a schema to the user in diagrammatic form.
• In many cases, GUIs utilize both menus and forms.
• Most GUIs use a pointing device, such as a mouse, to select certain parts of
the displayed schema diagram.
 DBMS Architectures
• Design of DBMS depends on its architecture
• It mainly focus on : Design, development , implementation and maintenance of a
database.
• It helps in storing and organize information for business agencies .
• It allows dividing database systems into individual component that can be
independently modified , changed , replaced and altered
• DBMS Architecture depends on
I. The underlying computer system on which database system runs
II. How users are connected to the database to get their request done.
3 types of DBMS Architectures
• One Tier Architecture

• Two Tier Architecture

• Three Tier Architecture

 One Tier Architecture
• One Tier Architecture in DBMS is the simplest architecture of Database in which
the client, server, and Database all reside on the same machine.
• Example-Anytime you install a Database in your system and access it to practice
SQL queries.
• But such architecture is rarely used in production
• In single or one tier architecture, the database is directly available to the user.
• Any changes done here will be directly done on the database itself.
• No network connection is required to perform the action
on the database.
• This architecture is used where data does not change
frequently and where multiple users are not accessing
the system..
Two Tier Architecture
• A 2 Tier Architecture in DBMS is a Database architecture where the presentation
layer runs on a client like PC, Mobile, Tablet, etc.
• Data is stored on a server called the second tier.
• Two tier architecture provides added security to the DBMS as it is not exposed to
the end-user directly.
• It provides direct and faster communication
• It is same as client-server architecture
• Applications on the client end can directly
communicate on the database at the server side.
• API’s like ODBC &JDBC are used by the client
side program to call the DBMS.
Two Tier Architecture
– The user interfaces and application programs are run on the client side.
– To communicate with the DBMS,client side applications establishes a
connection with the server side.
– The server is responsible to provide the functionality like query processing and
transaction management.
– Network connection is needed in two tier architecture
– It is used inside any application, where multiple accessing the database server
directly.
– Ex. Railway reservation system.
– Advantages
• Direct and faster communication
• Maintenance and understanding is easier
• Compatible with existing system.
Three Tier Architecture

– A 3 Tier Architecture in DBMS contains an Application server in between the

client & database.
– In DBMS the development and maintenance of functional processes, logic,
data access, data storage, and user interface is done independently as separate
modules.
– Three Tier architecture contains a presentation layer, an application layer, and a
database server.
– The Application layer resides between the user and the DBMS, which is
responsible for communicating the user’s request to the DBMS system and
send the response from the DBMS to the user.
Three Tier Architecture
– The application on the client –end interacts with
the application server which further
communicates with the database systems and then
query processing and transaction management
takes place.
– The intermediate layer of application server acts
as a medium for exchange of partially processed
data between server and client.
– End user has no idea about the existence of the
database beyond the application server.
– The database also has no idea about any other
user beyond the applications.
– Multiple-tier database architecture is highly
modifiable, as almost all its components are
independent and can be changed independently.
DBMS Classification

▪ Database management systems can be classified based on several

criteria

▪ Classification Based on

• Data Model
• Number of users

• Database distribution
• Based on cost

• Acess path
DBMS Classification
Classification Based on Data Model
• The most popular data model in use today is the relational data model.
• Well-known DBMSs like Oracle, MS SQL Server, DB2 and MySQL
support this model.
• Hierarchical data models and network data models,are the other traditional
models
• These are all referred to as traditional models because they preceded the
relational model.
• In recent years, the newer object-oriented data models were introduced.
• Object-oriented database management systems (OODBMS) combine
database capabilities with object-oriented programming language
capabilities.
Relational data model
• Relational Model is the most
widely used model.
• In this model, the data is
maintained in the form of a two-
dimensional table.
• Every table has the number of
attributes (columns) with unique
names.
• All the information is stored in the
form of row and columns.
• A DBMS that is based on
relational model is called as
RDBMS
Hierarchical Model
– Hierarchical Model was the first
DBMS model.
– This model organizes the data in the
hierarchical tree structure.
– It is useful where the following two
conditions are met:
• The data should be in a
hierarchical pattern i.e. parent-
child relationship must be present.
• The data in a hierarchical pattern
must be accessed through a single
path only.
Network Model
• This model is an extension of the
hierarchical model.
• It has graphs and links
• the relationship can be defined in the
form of link and it handles many to
many relations.
• This model is the same as the
hierarchical model, the only difference
is that a record can have more than one
parent.
Entity-Relationship Model
► ER diagram has the following three components:

► Entities: Entity is a real-world thing. It can be a person, place, or even a

concept.
► Example: Teachers, Students, Course, Building, Department, etc are
some of the entities of a School Management System.
► Attributes: An entity contains a real-world property called attribute. This
is the characteristics of that attribute.
► Example: The entity teacher has the property like teacher id, salary,
age, etc.
► Relationship: Relationship tells how two attributes are related.

► Example: Teacher works for a department.

Entity-Relationship Model
Object-Oriented Data Model
• The real-world problems are more
closely represented through the
object-oriented data model.

• In this model, both the data and

relationship are present in a single
structure known as an object.
DBMS Classification

Classification Based on User Numbers

• The second criterion used to classify DBMSs is the number of users
supported by the system.
• Single-user systems support only one user at a time and are mostly used
with PCs.
– Example Personal Computers
• Multiuser systems, which include the majority of DBMSs, support
concurrent multiple users.
– Example: Databases of Banks, insurance agencies, stock exchanges,
supermarkets, etc.
DBMS Classification

Classification Based on Database Distribution

• The third criterion is the number of sites over
which the database is distributed.

• A DBMS is centralized if the data is stored at a

single computer site.

• A centralized DBMS can support multiple

users, but the DBMS and the database reside
totally at a single computer site.
• A distributed DBMS (DDBMS) can
have the actual database and DBMS
software distributed over many sites,
connected by a computer network.
• Distributed DBMS can be of two types

– Homogeneous

– Heterogeneous
• Homogeneous DDBMSs use the same DBMS software at all the sites
– For example, library information systems by the same vendor, such as
Geac Computer Corporation, use the same DBMS software which
allows easy data exchange between the various Geac library sites.

• Heterogeneous DDBMSs can use different DBMS software at each site

– For example, the various library database systems use the same
machine-readable cataloguing (MARC) format to support library record
data exchange.
Classification Based on Cost
• Low cost DBMS - The cost of these systems vary from $100 to $300.
• Medium cost DBMS- The cost of these systems vary from $500 to $3000.
• High cost DBMS- Cost of these systems are usually more than $100000.
ER model
• ER model stands for an Entity- Relationship model.

• It is a high level data model.

• An Entity- Relationship model (ER model) describes the structure of

a database with the help of a diagram, which is known as Entity-
Relationship Diagram (ER Diagram).

• An ER model is a design or blueprint of a database that can later be

implemented as a database.
What is ER Diagram?
• ER Diagram stands for Entity Relationship Diagram, also known as ERD

• Diagram that displays the relationship of entity sets stored in a database.

• ER diagrams help to explain the logical structure of databases.

• ER diagrams are created based on three basic concepts: entities, attributes

and relationships.
Components of the ER Diagram
Components of the ER Diagram – Entity

– An entity is an object that exist and is distinguishable from other

objects
– An entity may be any object , class, person or place.
– In the ER diagram, an entity can be represented as rectangles.
– Some examples of entities might include the following:
• PERSON: Agent, employee, customer
• PLACE: State, country, municipality
• THING: Inventory item, vehicle, product
• CONCEPT: Policy, risk, coverage, job
• ORGANIZATION: Agency, department ERD Notation for Entity
• EVENT: Service request, claim, election
Components of the ER Diagram – Entity

• Tangible Entity: Tangible Entities are those entities which exist in the real
world physically. Example: Person, car, etc.

• Intangible Entity: Intangible Entities are those entities which exist only
logically and have no physical existence. Example: Bank Account, etc.
Entity Type, Entity set

• An entity type defines a collection (or set) of entities that have the same
attributes.
• Each entity type in the database is described by its name and attributes.
• The collection of all entities of a particular entity type in the database at
any point in time is called an entity set. It is also called the extension of the
entity type.
• Entity type is a superset of the entity set as all the entities are included in
the entity type.
• For example, a company have many employees and these employees are
defined as entities and all these entities having same attribute are defined
under entity type EMPLOYEE and set is called entity set.
Entity Type, Entity set
Components of the ER Diagram – Entity

• Two types of entities

– Strong entity
– Weak entity
• Strong entity
– An entity that can be uniquely identified by its own attribute.
– It is represented by a single rectangle
– It is also known as parent entity or dominant entity.
• Weak entity
– An entity that depends on another entity
ERD Notation for weak entity
– It doesn’t contain any key attribute of its own
– It is represented by a double rectangle
– It contains a partial key called as discriminator which helps in identifying a
group of entities from the entity set
Components of the ER Diagram – Attribute

• A real-world property of an entity type is called an attribute. This is the

characteristics of an entity.
• All attributes have values
• Each attribute can take only a set of permitted values. This is called the
domain of that attribute.
– For example, we define the roll_no of the ‘Student’ by a numeric value.
So, the permitted values are only integers and hence, ‘integer’ is the
domain of attribute ‘roll_no’.
• Each attribute is represented by a separate column in a relational table.
• Example- a student entity may have name, class, and age as attributes

ERD Notation for attribute

Components of the ER Diagram – Attribute

❖ Various oval symbols represent various types of the attribute .

Components of the ER Diagram – Attribute

• There are many types of attributes which are as follows:

– Simple Attribute & Composite Attribute

– Single Valued Attribute & Multi-valued Attribute

– Stored Attribute & Derived Attribute

– Key Attribute & Non-key Attribute

Simple Attribute & Composite Attribute

• A simple attribute contains an atomic value which cannot be further

divided.

• It is simply represented by an oval.

– For example, Roll_no of Student, Age of Student. It is represented in

the E-R diagram as:
Simple Attribute & Composite Attribute

• Composite Attribute - can be further divided into other attributes.

• We represent this in E-R diagram by connecting an oval with oval
• In the table, we will have three columns i.e. First_name, Middle_name, and
Last_name.
Single Valued Attribute & Multi-valued Attribute

• Single-valued Attribute has only one value.

• It is represented by a simple oval.

• Some simple attribute can also be a single-valued attribute.

– For example, the Section of ‘Student’ is a simple attribute as it can’t be

further divided. Also, it is a single-valued attribute because a student

can't study in more than one section.

For example, section of a student

Single Valued Attribute & Multi-valued Attribute

• Multi-valued Attribute has more than one value

• It is represented by a double oval.
• Some Composite keys can also be a multi-valued attribute.
– For example, the address attribute of a student can further be divided
into ‘Locality’, ‘Town’ and ‘PIN’. So, we call it a composite attribute.
• Also, the address of a student can have more than one value.
– A Student can have more than one Address i.e Permanent Address and
Temporary Address. So, it can also be called a multi-valued attribute.

For example, a student can have more than one email address
Stored Attribute & Derived Attribute

• Stored Attribute - The value of this attribute should be provided by the user.
• This attribute is stored and can be used for finding the value of other
attributes.
• It cannot be derived from any other attribute.
• It is also represented by an oval.
• For Example, The Date of Birth of ‘Student’ has to be provided by the
student.

For example, Date of Birth of a student

Stored Attribute & Derived Attribute

• Derived Attribute- The value of this attribute is derived from some other
attributes.
• We know the value of some other attribute(stored attribute)and from stored
attribute, we are deriving the value of this attribute(derived attribute).
• This is done mainly because the value for such attribute keeps on changing.
• It is represented by a dashed oval.

For example, The value of age attribute is derived from

the DOB(date of birth) attribute.
Key Attribute & Non-key Attribute

• A key attribute is used to uniquely identify the entities of an entity type.

• In a relational table, it represents the primary key of the table.

• It is represented by oval and the text in it is underlined.

• Even if all the other attributes of an entity are the same but the key attribute
will always be different.

Example: We have Roll_no as the key attribute of the ‘Student’

because two students can never has same roll number.
Key Attribute & Non-key Attribute

• All the other attributes other than the key attribute are the non-key
attributes.

• Two or more entities can have the same value for this attribute.

– For example, the Class attribute would have the same value for all
those students who are studying in the same class.

Example: Class, Section, Age, Name etc, are the non-key attributes.
Null Valued Attributes

• The attributes which can have a null value called null valued attributes.
• Example: Mobile_no attributes of a person may not be having mobile

phones.
Relationship Type and Relationship Set

• A relationship type represents the association between entity types.

• For example, ‘Enrolled in’ is a relationship type that exists between entity
type Student and Course.
• In ER diagram, relationship type is represented by a diamond and
connecting the entities with lines.
• Each relationship has
– Name
– Degree
– Cardinality ratio
• A set of relationships of same type is known as relationship set.
– For example, consider a relationship type WORKS_FOR between the
two entity types EMPLOYEE and DEPARTMENT
– which associates each employee with the department for which the
employee works in the corresponding entity set.
– Each relationship instance in the relationship set WORKS_FOR
associates one EMPLOYEE entity and one DEPARTMENT entity.
Degree of Relationship

• The degree of a relationship is the number of entity types that

participate(associate) in a relationship.

• Based on the number of entity types that are connected we have the
following degree of relationships:

– Unary

– Binary

– Ternary

– N-ary
Degree of Relationship - Unary (degree 1)

• A unary relationship exists when both the participating entity type are the
same.
– For example, Suppose in a classroom, we have many students who
belong to a particular club-like dance club, basketball club etc. and
some of them are club leads.
– So, a particular group of student is managed by their respective club
lead.
– Here, the group is formed from students and also, the club leads are
chosen from students.
– So, the ‘Student’ is the only entity participating here.
– We can represent this relationship using the E-R diagram as follows:
Degree of Relationship - Binary (degree 2)

• A binary relationship exists when exactly two entity type participates.

• This is the most common degree of relationship.

• It is easy to deal with such relationship as these can be easily converted into
relational tables.
Degree of Relationship - Ternary(degree 3)

• A ternary relationship exists when exactly three entity type participates.

• As the number of entity increases in the relationship, it becomes complex
to convert them into relational tables.
Degree of Relationship - N-ary (n degree)

• An N-ary relationship exists when ‘n’ number of entities are participating.

• So, any number of entities can participate in a relationship.

• There is no limitation to the maximum number of entities that can

participate.
• But, relations with a higher degree are not common.

• This is because the conversion of higher degree relations to relational tables

gets complex

• We are making an E-R model because it can be easily be converted into any
other model for implementing the database.

• But, this benefit is not available if we use higher degree relations.

Degree of Relationship - N-ary (n degree)
Constraints on Binary Relationship Types

• Relationship typc-es usually have certain constraints that limit the possible
combinations of entities that may participate in the corresponding
relationship set.
– For example, if the company has a rule that each employee must work
for exactly one department, then we would like to describe this
constraint in the schema.
• We can distinguish two main types of binary relationship constraints
– Cardinality ratio or Mapping cardinality
– Participation constraints
Cardinality Ratio

• A relationship where two entities are participating is called a binary

relationship.
• The cardinality ratio for a binary relationship specifies the maximum
number of relationship instances that an entity can participate in.
• Cardinality is the number of instance of an entity from a relation that can be
associated with the relation.
• There are four types Cardinality
– One to One
– One to Many
– Many to One
– Many to Many
Cardinality Ratio - One to One (1:1)

• When a single instance of an entity is associated with a single instance of

another entity then it is called One to One relationship
• Such a relationship exists when each record of one table is related to only
one record of the other table.
– For example, If there are two entities ‘Person’ (Id, Name, Age,
Address) and ‘Passport’(Passport_id, Passport_no).
– So, each person can have only one passport and each passport belongs
to only one person.
Cardinality Ratio - One to One(1:1) Examples
Cardinality Ratio - One to Many

• When a single instance of an entity is associated with more than one

instance of another entity then it is called One to Many relationship
• Such a relationship exists when each record of one table can be related to
one or more than one record of the other table.
• A one-to-many relationship can also be said as a many-to-one relationship
depending upon the way we view it.
• For example, If there are two entity type ‘Customer’ and ‘Account’ then
each ‘Customer’ can have more than one ‘Account’

1 N
Customer has Account
Cardinality Ratio - One to Many Examples
Cardinality Ratio - Many to One

• When more than one instance of an entity is associated with a single

instance of another entity then it is called Many to One relationship

• For example, many students can study in a single college but a student
cannot study in many colleges at the same time.
Cardinality Ratio - Many to One Examples
Cardinality Ratio - Many-to-Many Relationship

• Such a relationship exists when each record of the first table can be
related to one or more than one record of the second table and a
single record of the second table can be related to one or more than
one record of the first table.
• Example: If there are two entity type ‘Customer’ and ‘Product’ then
each customer can buy more than one product and a product can be
bought by many different customers.
Cardinality Ratio - Many-to-Many Example
Participation Constraints

• The participation constraint specifies whether the existence of an entity

depends on its being related to another entity via the relationship type.
• This constraint specifies the minimum number of relationship instances that
each entity can participate in, and is sometimes called the minimum
cardinality constraint
• The relationship can be between two strong entity or a strong entity and a
weak entity.
• Depending upon the type of entity participating in the relationship, the
participation can be partial or total.
Participation Constraints - Partial Participation

• Partial Participation: Partial Participation exists when all the entity of an

entity type is not associated with one or the other entity of another entity
type.
• This is represented by joining the relationship with the entity type with the
help of one line.
– Example: We have two entity type ‘Customer’ and ‘Order’. Then there
can be ‘Customer’ who have not done any order. So, here there is
partial participation of the entity in the relationship.
Participation Constraints - Total Participation

• Total Participation exists when all the entity of an entity type is associated
with one or the other entity of another entity type.
• Total participation is also called existence dependency.
• This is represented by joining the relationship with the entity type with the
help of a double parallel line.
• Such a relationship usually exist between a strong entity and a weak entity.
dependent exist only when there is
employye
 department exist only when there is emoployee

– Example : If a company policy states that every employee must work

for a department, then an employee entity can exist only if it
participates in at least one WORKS_FOR relationship instance .
– Thus, the participation of EMPLOYEE in WORKS_FOR is called total
participation, meaning that every entity in the total set of employee
entities must be related to a department entity via WORKS_FOR.

❖cardinality ratio and participation constraints, taken

together, as the structural constraints of a relationship
type.
Role Names and Recursive Relationships

• Each entity type that participates in a relationship type plays a particular

role in the relationship.
• The role name signifies the role that a participating entity from the entity
type plays in each relationship instance, and helps to explain what the
relationship means.
• For example, in the WORKS_FOR relationship type, EMPLOYEE plays
the role of employee or worker and DEPARTMENT plays the role of
department or employer
• The same entity type participates more than once in a relationship type in
different roles. In such cases the role name becomes essential for
distinguishing the meaning of the role that each participating entity plays.
Such relationship types are called recursive relationships.
 Example: The SUPERVISION relationship type relates an employee to a
supervisor, where both employee and supervisor entities are members of the
same EMPLOYEE entity set. Hence, the EMPLOYEE entity type participates
twice in SUPERVISION: once in the role of supervisor (or boss), and once in
the role of supervisee (or subordinate)
Steps to Build an ERD
Problem Definition

The company datadase keeps tracks of company’s employee, department and

projects. We store Employee’s name,ssn,address,salary,gender,date of birth,age.
An employee is assigned to one department, but may work on several projects
which are not necessarily controlled by the same department. A particular
employee manages the depatment. Each department has a unique name, unique
number and a several location. The department controls number of projects each
of which has unique name, unique number and a single location . We want to
keep track of the dependents of each employee for insurance purpose. We keep
each dependent’s first name,sex, birth date and relationship to employee
Problem Definition

A company has the following scenario: There are a set of salespersons. some
of them manage other salespersons. However, a salesperson cannot have more
than one manager. A salesperson can be an agent for many customers. A
customer is managed by exactly one salesperson. A customer can place any
number of orders. An order can be placed by exactly one customer. Each order
lists one or more items. An item may be listed in many orders. An item is
assembled from different parts and parts can be common for many items. one
or more employees assemble an item from parts. A supplier can supply
different parts in certain quantities. A part may be supplied by different
suppliers.
ER Model Case Studies

• The company organized into departments and departments have employees

working in it.
• Attributes of Department are dno, dname. Attributes of Employee include eno,
name, dob,gender, doj, designation, basic_pay, panno, skills. Skills are multi-
valued attribute.
• The Department has a manager managing it. There are also supervisors in
Department who supervises a set of employees.
• Each Department enrolls a number of projects. Attributes of Project are pcode,
pname. A project is enrolled by a department. An employee can work on any
number of projects on a given day. The Date of employee work in-time and out-
time has to keep track.
• The Company also maintains details of the dependents of each employees.
Attributes of dependent include dname, dob, gender and relationship with the
employee.
• Model an entity-relationship diagram for the above scenario.
ER Model Case Studies

• Suppose you are given the following requirements for a simple database for the
National Hockey League (NHL):
– the NHL has many teams,
– each team has a name, a city, a coach, a captain, and a set of players,
– each player belongs to only one team,
– each player has a name, a position (such as left wing or goalie), a skill
level, and a set of injury records,
– a team captain is also a player,
– a game is played between two teams (referred to as host_team and
guest_team) and has a date (such as May 11th, 2017) and a score (such as 4
to 2).
Construct a clean and concise ER diagram for the NHL database using the
Chen notation as in your textbook. List your assumptions and clearly indicate
the cardinality mappings as well as any role indicators in your ER diagram.
ER Model Case Studies

• Construct an ER diagram for a car insurance company whose customers

own one or more cars. Each car has associated with zero to any number of
recurred accidents. State any assumptions you make.
ER Model Case Studies

• Construct an E-R diagram for a hospital with a set of patients and a set of
medical doctors. Associate with each patient a log of the various tests and
examinations.
ER Model Case Studies

• A university registrar’s office maintains data about the following entities:

(a) courses, including number, title, credits, syllabus, and prerequisites;
(b) course offerings, including course number, year, semester, section number,
instructor(s), timings, and classroom;
(c) students, including student-id, name, and program; and
(d) instructors, including identification number, name, department, and title.
Further, the enrollment of students in courses and grades awarded to students
in each course they are enrolled for must be appropriately modeled.
Construct an E- R diagram for the registrar’s office. Document all
assumptions that you make about the mapping course.