Department of Computer

Science & Engineering

DATABASE MANAGEMENT SYSTEM (DBMS)

Ms. Mandakini Ingle

Assistant Professor
CSE
 UNIT–I
Introduction: Concept & Overview of DBMS, Purpose of DBMS, Architecture of
DBMS, Data Models and its Types, Schema and Instances, Data Independence,
DBA,Functions of DBA .

Entity-Relationship Model: Basic concepts,Entity,Attribute and its types,Mapping

cardinalities, Keys, Entity-Relationship Diagram, Weak Entity Sets ,Strong Entity
Sets and Extended E-R features[Generalization,Specialization and Aggrigation] , ER
Diagram o Relational Table conversion.
 Basics of DBMS
• Data : Known facts/raw material that can be recorded and have
an implicit meaning. Form numbers, text, audio, video, pictures,
images etc.
• Example: flipkart,OLA

• Database : A collection of related data that represents some real

world entities or objects. Database Should be used to solve our
problems.
• Age=25,car price =60000, software name=TCS,IBM
• Example:University website, hospital data,enterprise
data,Government organization etc.
 Basics of DBMS..........
• Information: Meaningful/Processed data. We can extract
information from meaningful data. It is a useful thing.
Information is depends on a particular requirement of that
person.
• Example: YouTube, Railway IRCTC
 DBMS [Database Management System ]
• A database management system (DBMS) is a software package
designed to create, manipulate, retrieve and manage data in a
database.
• A DBMS generally manipulates the data itself, the data format,
field names, record structure, and file structure. It provides users
and programmers with a systematic way to create, retrieve,
update and manage data.
• DataBase Management Systems (DBMS) USER
• Hide
USER
• Redundancy DBMS
• Inconsistency
DATABASE
DATABASE
 What is a Database?

• A set of information stored in a computer in a

specific manner”

• “It is a collection of data arranged for ease and

speed of search and retrieval”

• Database System : The DBMS software together with the

data itself. Sometimes, the applications are also included.
 Database System
A database system = combination of a database, a DBMS,
and application programs

Because of the advantages offered by a DBMS, businesses

and organizations prefer the database approach to the file-
based approach
 The Database System
Limitations of file-based approach tell us that:
• Parameters defining data should be separately stored

• There should be a way to control and manipulate data in

isolation of the application program

A database management system (DBMS) is a piece of software

that allows a user to define, create, and manage access to a
database
Decouples application programs from data
The database stores all its data in one location, thereby limiting
data duplication
 Evolution of Database System
❖ Two approaches to convert data to information:
– File-based

▪ Developed in 1980’s

▪ Stores, manipulates, retrieves data from large flat files

– Database (relational systems)

▪ Developed by E. F. Codd of IBM in the early 1980's

▪ Widely used today

 History of DBMS
• 1960 – First DBMS designed by Charles Bachman at GE.
Integrated Data source(IBS).

• 1970 – Codd introduced IMS. IBMs Information Management

System (IMS)

• 1980 – Relational model became popular and accepted as the

main database paradigm. SQL, ANSI SQL, etc.

• 1980 to 1990 – New data models, powerful query languages, etc.

Popular vendors are Oracle, SQL Server, IBMs DB2, Informix, etc
 File-Based Approach
• A file is a collection of related
information
• A system of files and
collection of application
programs manipulating them
is a file-based system

A File-Based System
 Limitations of File-Based Approach
Efforts for query answering:
• What is the average grade for BE students?
• List the activities for all students enrolled in 2019.
• Which personnel are students as well as staff?
Other limitations:
• Data redundancy:Duplication of data
• Data Isolation:Data dependency
• Data inconsistency:No data updation at all places
• Data Security:
• Slow development, high maintenance and fixed queries
 Purpose of Database Systems
In the early days, database applications were built
directly on top of file systems, which leads to:
• Data redundancy and inconsistency: data is stored in multiple file
formats resulting induplication 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
 Purpose of Database Systems (Cont.)

• 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
• Ex: 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
 Advantage of DBMS over file system

• No redundant data
• Data Consistency and Integrity
• Data Security
• Privacy
• Easy access to data
• Easy recovery
• Flexible
 Database Applications Examples
• Enterprise Information
– Sales: customers, products, purchases
– Accounting: payments, receipts, assets
– Human Resources: Information about employees, salaries, payroll taxes.
• Banking and finance
– customer information, accounts, loans, and banking transactions.
– Credit card transactions
– Finance: sales and purchases of financial instruments (e.g., stocks and bonds; storing real-time market
data
• Airlines: reservations, schedules
• Telecommunication: records of calls, texts, and data usage, generating monthly bills, maintaining balances
on prepaid calling cards
• Universities: registration, grades, students record
 Application of Database.....

• Web indexes • Train timetables

• Library catalogues • Airline bookings
• Medical records • Credit card details
• Bank accounts • Student records
• Stock control • Customer histories
• Personnel systems • Stock market prices
• Product catalogues • Discussion boards
• Telephone directories • and so on…
 Database Management System Functions

• Data Definition: DDL processor and compiler to deal with DDL

• Data Manipulation: DML processor and compiler to deal with DML
• Optimization and execution
• Data Dictionary Management,
• Data Storage Management,
• Data Transformation and Presentation,
• Data Security & Integrity
• Multi-User Access Control,
• Recovery Management and concurrency
 DDL and DML in DBMS

DDL:

DDL is Data Definition Language which is used to define data

structures.
For example: create table, alter table are instructions in SQL.
DML:

DML is Data Manipulation Language which is used to manipulate

data itself.
For example: insert, update, delete are instructions in SQL.
 Data Dictionary

A data dictionary contains metadata i.e data about the database.

It contains information like:

• what is in the database,

• who can access it
• where is the database physically stored etc.

The users of the database normally don't interact with the data
dictionary, it is only handled by the database administrators.
The data dictionary holds information about the following −

• Names of all the database tables and their schemas.

• Detailsabout all the tables in the database, such as their

owners, their security constraints, when they were created etc.

• Physical information: where tables are stored and how.

• Table constraints: primary key attributes, foreign key

information etc.

• Information about the database views that are visible.

 Database Systems
• A database system consists of
• Data (the database)
• Hardware
• Software
• Users

• Database systems allow users to

• Store

• Update

• Retrieve

• Organise

• Protect

their data.
 Architecture of Database Management System :
• A database system is partitioned into modules that deal
with each of the responsibilities of the overall system.
• The functional components of a database system can be
divided into
• The Disk Storage,
• The storage manager,
• The query processor component,
• The Users and its interaction.
Architecture
of Database
Management
System
 1. The disk Storage
• The disk storage or physical storage is use for storing the data. In many big
enterprises,the database range in size from hundred of gigabytes to
terabytes of data. The main memory is not so largeer that it holds that much
information and data. so we needed a larger disk storage for the database.

• It contains DATA , Statistical Dta,Data Dictionary and Indices.

 The Disk Storage(Cont.)
• The storage manager implements several data structures as part of the
physical system implementation:

– Data files -- store the database itself

– Data dictionary -- stores metadata about the structure of the

database, in particular the schema of the database.

– Indices -- can provide fast access to data items. A database index

provides pointers to those data items that hold a particular value.
 2. Storage Manager
• A program module that provides the interface between the low-level
data stored in the database and the application programs and queries
submitted to the system.
• The storage manager is responsible to the following tasks:
– Interaction with the OS file manager
– Efficient storing, retrieving and updating of data
• The storage manager components include:
_Buffer manager
– File manager
– Authorization and integrity manager
– Transaction manager
 2. Storage Manager
• The storage manager components include:

• Authorization and integrity manager, which tests for the satisfaction of integrity constraints
and checks the authority of users to access data.

• Transaction manager, which ensures that the database remains in a consistent (correct)
state despite system failures, and that concurrent transaction executions proceed without
conflicting.

• File manager, which manages the allocation of space on disk storage and the data
structures used to represent information stored on disk.

• Buffer manager, which is responsible for fetching data from disk storage into main memory,
and deciding what data to cache in main memory. The buffer manager is a critical part of the
database system, since it enables the database to handle data sizes that are much larger
than the size of main memory.
 3. Query Processor
• The query processor components include:
– DDL interpreter -- interprets DDL statements and records the
definitions in the data dictionary.
– DML compiler -- translates DML statements in a query language
into an evaluation plan consisting of low-level instructions that the
query evaluation engine understands.
• The DML compiler performs query optimization; that is, it picks
the lowest cost evaluation plan from among the various
alternatives.
– Query evaluation engine -- executes low-level instructions
generated by the DML compiler.
 Query Processing
1. Parsing and translation
2. Optimization
3. Evaluation
 Transaction Management
• A transaction is a collection of operations that performs a single logical function in a
database application

• Transaction-management component ensures that the database remains in a

consistent (correct) state despite system failures (e.g., power failures and operating
system crashes) and transaction failures.

• Concurrency-control manager controls the interaction among the concurrent

transactions, to ensure the consistency of the database.
 Database Architecture
• Centralized databases
– One to a few cores, shared memory
• Client-server,
– One server machine executes work on behalf of multiple client machines.
• Parallel databases
– Many core shared memory
– Shared disk
– Shared nothing
• Distributed databases
– Geographical distribution
– Schema/data heterogeneity
DBMS Architecture (Centralized/Shared-Memory)
Database Users
 Difference between DBMS and Traditional File System
• DBMS is very expensive but, the traditional file system is cheap.

• DBMS is good for the large system but, the traditional file system is good for a small system
having a small number of items.

• DBMS required lots of effort for designing but, the traditional file system is very low design
efforts.

• DBMS is highly secured but, the traditional file system is not secure.

• DBMS is data sharable but, the traditional file system is isolated data sharable.

• DBMS is flexible but, the traditional file system has a lack of flexibility and has many limitations.

• DBMS has no integrity but, the traditional file system has an integrity problem.

• DBMS has a complex backup system but, the traditional file system has a simple backup system.

• DBMS removed data redundancy but, the traditional file system has data redundancy.
 Instances and Schemas
• A collection of information stored in the database at a particular
moment is called an instance of database. And the overall
design/structure of database is called the database schema.

• Similar to types and variables in programming languages

• Logical Schema – the overall logical structure of the database
– Example: The database consists of information about a set of
customers and accounts in a bank and the relationship between
them
• Analogous to type information of a variable in a program
• Physical schema – the overall physical structure of the database
• Instance – the actual content of the database at a particular point in
time
– Analogous to the value of a variable
Three Level Schema Architecture of Database
Three Level Schema Architecture of Database

External/Conceptual
mapping

Conceptual/Internal
mapping
 Three Level Schema Architecture of Database.....
1. External level:- It is also called view level. The reason this level is called “view” is
because several users can view their desired data from this level which is internally
fetched from database with the help of conceptual and internal level mapping.

The view schema describes the end user interaction with database systems.

2. Conceptual level:-It is also called logical level. The whole design of the database such as
relationship among data, schema of data etc. are described in this level.

Programmers and database administrators work at this level.

3. Internal level:- This level is also known as physical level. This level describes how the
data is actually stored in the storage devices. This level is also responsible for allocating
space to the data. This is the lowest level of the architecture.

The physical level is used to describe complex low-level data structures in detail.
 Database Applications
Database applications are usually partitioned into three parts
• One-tier architecture --Sinle layer architecture,in which database
and application resides in single machine/system.use only DBA
while designing a database.

• Two-tier architecture -- the application resides at the client

machine, where it invokes database system functionality at the
server machine.

• Three-tier architecture -- the client machine acts as a front end and

does not contain any direct database calls.
– The client end communicates with an application server, usually
through a forms interface.
– The application server in turn communicates with a database
system to access data.
DBMS architectures One-tier architecture

1-tier architecture
Two-tier architecture Three-tier Architectures
Client Machine Client Machine

USER USER

Client Application
Application Program Layer Application Program

Network Network

Business Layer
Application Server
Database Server
Database Server
Data Server Layer

Server Machine Server Machine

• Data Independence:

• Data independence can be explained using the three-schema

architecture.
• Data independence refers characteristic of being able to modify the
schema at one level of the database system without altering the
schema at the next higher level.
• Data independence helps you to keep data separated from all
programs that make use of it.
• There are two types of data independence:
 1. Physical Data Independence
• – the ability to modify the physical/internal schemas without changing the
logical/conceptual schema
– Applications depend on the logical schema
• In general, the interfaces between the various levels and components should be
well defined so that changes in some parts do not seriously influence others.
– Physical data independence can be defined as the capacity to change the
internal schema without having to change the conceptual schema.
– If we do any changes in the storage size of the database system server, then
the Conceptual structure of the database will not be affected.
– Physical data independence is used to separate conceptual levels from the
internal levels.
– Physical data independence occurs at the logical interface level.
2.Logical Data Independence
– the ability to modify the conceptual schema without changing the external/physical
schemas or application programs.
– Applications depend on the logical schema
– In general, the interfaces between the various levels and components should be well
defined so that changes in some parts do not seriously influence others.
– Logical data independence refers characteristic of being able to change the conceptual
schema without having to change the external schema.
– Logical data independence is used to separate the external level from the conceptual
view.
– If we do any changes in the conceptual view of the data, then the user view of the data
would not be affected.
– Logical data independence occurs at the user interface level.
 Database Administrator (DBA)
• A Database Administrator (DBA) in Database Management System (DBMS) is an IT
professional who works on creating, maintaining, querying, and tuning the database
of the organization.It is a person in the organization who controls the design and the
use of the database refers as DBA,who has central control over the system .

• Role and Duties of Database Administrator (DBA) :

• Decides hardware
• Database design
• Manages data integrity and security
• Database implementation
• Query processing performance
 Database Administrator Functions
Functions of a DBA include:

• Schema definition
• Storage structure and access-method definition
• Schema and physical-organization modification
• Granting of authorization for data access
• Routine maintenance
• Periodically backing up the database
• Ensuring that enough free disk space is available for normal operations, and upgrading disk
space as required
• Monitoring jobs running on the database
Functions of a DBA.............
• 1. Schema Definition:
• The DBA definition the logical Schema of the database.A Schema refers to the
overall logical structure of the database.
• According to this schema, database will be developed to store required data for an
organization.
• 2. Storage Structure and Access Method Definition:
• The DBA decides how the data is to be represented in the stored database.
• 3. Assisting Application Programmers:
• The DBA provides assistance to application programmers to develop application
programs.
• 4. Physical Organization Modification:
• The DBA modifies the physical organization of the database to reflext the changing
needs of the organization or to improve performance.
Functions of a DBA ...
• 5. Approving Data Access:
• The DBA determines which user needs access to which part of the database.
• According to this,various types of authorizations are granted to different users.
• 6. Monitoring Performance:
• The DBA monitors performance of the system.The DBA ensures that better
performance is maintained by making changes in physical or logical schema if
required.
• 7. Backup and Recovery:
• Database should not be lost or damaged.
• The DBA ensures this periodically backing up the database on magnetic tapes or
remote servers.
• In case of failure, such as virus attack database is recovered from this backup.
 Data Models

A data model is a collection of concepts for describing data, its

relationships, and its constraints
• Provides a clearer and more accurate description and
representation of data
• Standard platform that enables database designers and end-
users to communicate
 Components of Data Models
1. Structure Part: Consisting of set of rules according to which
databases can be constructed.

2. Manipulative Part: Define the types of operation that are allowed

on the data.

3. Set of Integrity Rules: Which ensures that data is accurate.

 Types of Data Models

Come in three varieties:

• Object-based models (conceptual schema)

• Record-based models (external schema)

• Physical data models (internal schema)

 1. Object-Based Data Models
Object-based data models use entities, attributes, and relationships to present
information.Describe data at the conceptual and view levels.

An entity is a living or non-living object in the real world

Examples: Person, place, event
An attribute is a property of an entity
Examples: Name, address of a person
A relationship is an association between entities
Example: Register is a relationship between student and courses
Some common types of object-based data models include:
Entity-relationship data model Functional data model Object-oriented data model
 1. Object-Based Data Models........
• In this both data and their relationship are organised or contained in a single structure known
as object.
• Object includes information about relationship between the facts within the object,as well as
information about relationship with other objects.
• It is also said to be semantic data model.
• An object is the abstraction of the real world entity and an object represents only one occurrence
of entity.
• Attributes: It describes the property of an object.
• For example:-
• Shape, Circle, Rectangle and Triangle are all objects in this model. Circle has the attributes Center
and Radius.Rectangle has the attributes Length and Breath. Triangle has the attributes Base and
Height . The objects Circle, Rectangle and Triangle inherit from the object Shape.
 Types of Object Based Data Models

a) Entity Relationship
b) Object Oriented
c) Semantic
d) Functional
 a. Entity-Relationship Data Model

The entity-relationship model has emerged as one of the most

popular and widely used techniques in today's databases
Describes data in the form of an E-R diagram:
• Entities are rectangles (“Student” and “Department”)

• Relationships are diamonds (“Belongs to”)

• Attributes are ovals (“SSN”, “Name”)

• Cardinalities are constraints on relationships (“>” and “|”)

 ER DATA MODEL
• In this database model, relationships are created by dividing object
of interest into entity and its characteristics into attributes.
• Different entities are related using relationships.
• E-R Models are defined to represent the relationships into pictorial
form to make it easier for different stakeholders to understand.
• This model is good to design a database, which can then be turned
into tables in relational model.
• Let's take an example, If we have to design a School Database,
then Student will be an entity with attributes name, age, address
etc. As Address is generally complex, it can be
another entity with attributes street name, pincode, city etc, and
there will be a relationship between them.
• Relationships can also be of different types.
ER DATA MODEL
Entity
Attribute
 ER DATA MODEL...........
Advantages of ER Model
• Simple: Conceptually ER Model is very easy to build. If we know the relationship between the
attributes and the entities we can easily build the ER Diagram for the model.
• Effective Communication Tool: This model is used widely by the database designers for
communicating their ideas.
• Easy Conversion to any Model: This model maps well to the relational model and can be easily
converted relational model by converting the ER model to the table. This model can also be
converted to any other model like network model, hierarchical model etc.

Disadvantages of ER Model
• No industry standard for notation: There is no industry standard for developing an ER model. So
one developer might use notations which are not understood by other developers.
• Hidden information: Some information might be lost or hidden in the ER model. As it is a high-
level view so there are chances that some details of information might be hidden.
b. 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.

• We can store audio, video, images, etc in the database which was not
possible in the relational model .

• In this model, two are more objects are connected through links. We
use this link to relate one object to other objects.
Object-Oriented Data Model
 Object-Oriented Data Model........

• In the above example, we have two objects Employee and

Department. All the data and relationships of each object are
contained as a single unit. The attributes like Name, Job_title of the
employee and the methods which will be performed by that object are
stored as a single object. The two objects are connected through a
common attribute i.e the Department_id and the communication
between these two will be done with the help of this common id.
 2. Record-Based Data Models
• Record-based data models use records to present data.
• A record is a structure that contains a fixed number of fields to hold a piece of
information.
• It is used to specify the overall logical structure of the database and to provide a
higher-level description of the implementation. Structured database in fixed formats.

There are three main types of record-based data models:

1. Relational data models
2. Network data models
3. Hierarchical data models
 a. Relational Data Model
• In this model, data is organised in two-dimensional tables and the relationship

is maintained by storing a common field.

• This model was introduced by E.F Codd in 1970, and since then it has been

the most widely used database model, infact, we can say the only database
model used around the world.

• The basic structure of data in the relational model is tables. All the information

related to a particular type is stored in rows of that table.

• Hence, tables are also known as relations in relational model.

 a. Relational Data Models......
Each table consists of a fixed number of named columns
(attributes) and an arbitrary number of unnamed rows (records)
Relational Data Model
 Relational Data Model.......
Advnatages of Relational Model
• Simple: This model is more simple as compared to the network and hierarchical model.
• Scalable: This model can be easily scaled as we can add as many rows and columns we want.
• Structural Independence: We can make changes in database structure without changing the way to
access the data. When we can make changes to the database structure without affecting the
capability to DBMS to access the data we can say that structural independence has been achieved.

Disadvantages of Relational Model

• Hardware Overheads: For hiding the complexities and making things easier for the user this model
requires more powerful hardware computers and data storage devices.
• Bad Design: As the relational model is very easy to design and use. So the users don't need to know
how the data is stored in order to access it. This ease of design can lead to the development of a poor
database which would slow down if the database grows.
 b. NETWORK DATA MODEL
• This is an extension of the Hierarchical model. In this model data is
organised more like a graph, and are allowed to have more than one parent
node.

• In this database model data is more related as more relationships are

established in this database model. Also, as the data is more related, hence
accessing the data is also easier and fast. This database model was used
to map many-to-many data relationships.

• This was the most widely used database model, before Relational Model
was introduced.
NETWORK DATA MODEL....
 NETWORK DATA MODEL
Advantages of Network Model

• The data can be accessed faster as compared to the hierarchical model. This is because
the data is more related in the network model and there can be more than one path to
reach a particular node. So the data can be accessed in many ways.

• As there is a parent-child relationship so data integrity is present. Any change in parent

record is reflected in the child record.

Disadvantages of Network Model

• As more and more relationships need to be handled the system might get complex. So, a
user must be having detailed knowledge of the model to work with the model.

• Any change like updation, deletion, insertion is very complex.

 C. Hierarchical Data Model
• This database model organizes data into a tree-like-structure, with a single root,
to which all the other data is linked. The hierarchy starts from the Root data, and
expands like a tree, adding child nodes to the parent nodes.

• In this model, a child node will only have a single parent node.

• This model efficiently describes many real-world relationships like index of a

book, recipes etc.

• In hierarchical model, data is organised into tree-like structure with one one-to-
many relationship between two different types of data, for example, one
department can have many courses, many professors and of-course many
students.
Hierarchical Data Model
 Hierarchical Data Model
Advantages of Hierarchical Model
• It is very simple and fast to traverse through a tree-like structure.

• Any change in the parent node is automatically reflected in the child

node so, the integrity of data is maintained.

Disadvantages of Hierarchical Model

• Complex relationships are not supported.

• As it does not support more than one parent of the child node so if we
have some complex relationship where a child node needs to have
two parent node then that can't be represented using this model.
• If a parent node is deleted then the child node is automatically
deleted.
 3. Physical Data Models
• It describe how data is stored in the computer, representing information such
as record structures, record ordering and access paths.

• It describe the data at lowest level.

• tto describe the behaviour of data at disk level, the way is data and data
relationships are maintained while storing them on the disk.

• Decide the way the DBMS is gi=oing to use sec0ndary storage devoice for
storing and accessing database.

• Less no. of models are there.

a.Unifying model

b.Frame memory model

 Entity–Relationship 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. The main components of E-R
model are: entity set and relationship set.
• In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students however
a student cannot study in multiple colleges at the same time. Student entity has attributes such as
Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as Col_ID & Col_Name.
 Entity
• An Entity may be an object with a physical existence – a particular person, car, house,
or employee – or it may be an object with a conceptual existence – a company, a job,
or a university course.
• Representation:- Rectangle
• An Entity is an object of Entity Type and set of all entities is called as entity set. e.g.;
E1 is an entity having Entity Type Student and set of all students is called Entity Set.
In ER diagram, Entity Type is represented as
 Attribute
• Attributes are the properties which define the entity type. For example, Roll_No, Name, DOB, Age,
Address, Mobile_No are the attributes which defines entity type Student.
• Representation:- oval

• Key Attribute –
The attribute which uniquely identifies each entity in the entity set is called key attribute. For example,
Roll_No will be unique for each student.
• Representation:- oval with underlying lines.

• Multivalued Attribute –
An attribute consisting more than one value for a given entity. For example, Phone_No (can be more
than one for a given student)
• Representation:- double oval
• Composite Attribute –
An attribute composed of many other attribute is called as composite attribute. For example, Address
attribute of student Entity type consists of Street, City, State, and Country.
• Representation:- oval comprising of ovals

• Derived Attribute –
An attribute which can be derived from other attributes of the entity type is known as derived attribute. e.g.;
Age (can be derived from DOB).
• Representation:- dashed oval.
• The complete entity type Student with its attributes can be represented as:
 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.
• represented :- diamond and connecting the entities with lines.

• A set of relationships of same type is known as relationship set. The following relationship set
depicts S1 is enrolled in C2, S2 is enrolled in C1 and S3 is enrolled in C3.
 Degree of a relationship set
• The number of different entity sets participating in a relationship set is called as degree of a
relationship set.
• Unary Relationship –
When there is only ONE entity set participating in a relation, the relationship is called as
unary relationship. For example, one person is married to only one person.

• Binary Relationship –
When there are TWO entities set participating in a relation, the relationship is called as
binary relationship.For example, Student is enrolled in Course.
 Cardinality:
• The number of times an entity of an entity set participates in a relationship set is known as cardinality.
Cardinality can be of different types:
• One to one – When each entity in each entity set can take part only once in the relationship, the
cardinality is one to one. Let us assume that a male can marry to one female and a female can married to
one male. So the relationship will be one to one.

• Many to one – When entities in one entity set can take part only once in the relationship set and
entities in other entity set can take part more than once in the relationship set, cardinality is many to
one. Let us assume that a student can take only one course but one course can be taken by many students.
So the cardinality will be n to 1. It means that for one course there can be n students but for one student,
there will be only one course.

• Many to many – When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can take more than one course and
one course can be taken by many students. So the relationship will be many to many.
 Weak Entity Type and Identifying Relationship:
• As discussed before, an entity type has a key attribute which uniquely identifies each entity in
the entity set. But there exists some entity type for which key attribute can’t be defined.
These are called Weak Entity type.
• For example, A company may store the information of dependants (Parents, Children, Spouse)
of an Employee. But the dependents don’t have existence without the employee. So
Dependent will be weak entity type and Employee will be Identifying Entity type for Dependant.
• A weak entity type is represented by a double rectangle. The participation of weak entity type
is always total. The relationship between weak entity type and its identifying strong entity type
is called identifying relationship and it is represented by double diamond.
 ER examples
• The music database is designed to store details of a music collection, including the albums in the
collection, the artists who made them, the tracks on the albums, and when each track was last
played.
• The university database captures the details of students, courses, and grades for a university.
• The flight database stores an airline timetable of flight routes, times, and the plane types.
 Converting ER Diagrams to Tables-
• Following rules are used for converting an ER diagram into the tables-
Rule-01: For Strong Entity Set With Only Simple Attributes-
• A strong entity set with only simple attributes will require only one table in relational model.
• Attributes of the table will be the attributes of the entity set.
• The primary key of the table will be the key attribute of the entity set.
•
• Rule-02: For Strong Entity Set With Composite Attributes-
• A strong entity set with any number of composite attributes will require only one table in
relational model.
• While conversion, simple attributes of the composite attributes are taken into account and
not the composite attribute itself.
• Rule-03: For Strong Entity Set With Multi Valued Attributes-
• A strong entity set with any number of multi valued attributes will require two tables in
relational model.
• One table will contain all the simple attributes with the primary key.
• Other table will contain the primary key and all the multi valued attributes.
• Rule-04: Translating Relationship Set into a Table-
• A relationship set will require one table in the relational model.
• Attributes of the table are-
• Primary key attributes of the participating entity sets
• Its own descriptive attributes if any.
• Set of non-descriptive attributes will be the primary key.
• NOTE-
• If we consider the overall ER diagram, three tables will be required in relational model-
• One table for the entity set “Employee”
• One table for the entity set “Department”
• One table for the relationship set “Works in”
• Rule-05: For Binary Relationships With Cardinality Ratios-
• The following four cases are possible-
• Case-01: Binary relationship with cardinality ratio m:n
• Case-02: Binary relationship with cardinality ratio 1:n
• Case-03: Binary relationship with cardinality ratio m:1
• Case-04: Binary relationship with cardinality ratio 1:1
• Case-01: For Binary Relationship With Cardinality Ratio m:n
• Here, three tables will be required-
• A ( a1 , a2 )
• R ( a1 , b1 )
• B ( b1 , b2 )

• Case-02: For Binary Relationship With Cardinality Ratio 1:n

• Here, two tables will be required-
• A ( a1 , a2 )
• BR ( a1 , b1 , b2 )
• NOTE- Here, combined table will be drawn for the entity set B and relationship set R.
• Case-03: For Binary Relationship With Cardinality Ratio m:1
• Here, two tables will be required-
• AR ( a1 , a2 , b1 )
• B ( b1 , b2 )
• NOTE- Here, combined table will be drawn for the entity set A and relationship set R.

• Case-04: For Binary Relationship With Cardinality Ratio 1:1

• Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’
• Way-01:
• AR ( a1 , a2 , b1 )
• B ( b1 , b2 )
• Way-02:
• A ( a1 , a2 )
• BR ( a1 , b1 , b2 )
• Rule-06: For Binary Relationship With Both Cardinality Constraints and Participation
Constraints-
• Cardinality constraints will be implemented as discussed in Rule-05.
• Because of the total participation constraint, foreign key acquires NOT NULL constraint i.e. now foreign
key can not be null.
• Case-01: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From One Side-
• Because cardinality ratio = 1 : n , so we will combine the entity set B and relationship set R.
• Then, two tables will be required-
• A ( a1 , a2 )
• BR ( a1 , b1 , b2 )
• Because of total participation, foreign key a1 has acquired NOT NULL constraint, so it can’t
be null now.
• Case-02: For Binary Relationship With Cardinality Constraint and Total Participation Constraint
From Both Sides-
•
• If there is a key constraint from both the sides of an entity set with total participation, then that binary
relationship is represented using only single table.
• Here, Only one table is required.
• ARB ( a1 , a2 , b1 , b2 )
• Rule-07: For Binary Relationship With Weak Entity Set-
• Weak entity set always appears in association with identifying relationship with total
participation constraint.
• Here, two tables will be required-
• A ( a1 , a2 )
• BR ( a1 , b1 , b2 )