MODULE 1

DATABASE MANAGEMENT SYSTEM

INTRODUCTION
Data represents unorganized and unprocessed facts. Data means known facts that can be recorded and
that have implicit meaning.
Database is a collection of related data.
A database has the following implicit properties:
- A database represents a part of the real world (mini world) and reflects changes in it.
- It is a logically organized collection of meaningful data, not random data.
- Databases are created for a specific purpose, with intended users and applications.
Database management system (DBMS) is a collection of programs that enables users to create and
maintain a database. The DBMS is hence a general-purpose software system that facilitates the
processes of
● defining,
● constructing,
● manipulating,
● Sharing databases among various users and applications.
Defining a database involves specifying the data types, structures, and constraints for the data to be
stored in the database.
Constructing the database is the process of storing the data itself on some storage medium that is
controlled by the DBMS.
Manipulating a database includes such functions as querying the database to retrieve specific data,
updating the database to reflect changes in the mini world, and generating reports from the data.
Sharing a database allows multiple users and programs to access the database concurrently. Other
important functions provided by the DBMS include
● protecting the database and
● Maintaining it over a long period of time.
Protection includes both 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.
Database System Environment

 The database and DBMS software are together called a database system.

 An application program accesses the database by sending queries or requests for data to the
DBMS.
 A query typically causes some data to be retrieved.
 A transaction may cause some data to be read and some data to be written into the database.
 A simple Example of a database that stores student and course information.

CHARACTERISTICS OF DATABASE APPROACH

1. Self-Describing Nature:

- A database includes not just the data but also a description of its structure and rules (called meta-
data).

- This information is stored in the DBMS catalog, making it flexible for different users and
applications.

- In traditional file processing, data definition is part of the application, limiting it to specific files.

2. Insulation between Programs and Data (Program-Data Independence):

In traditional file systems, the structure of data is tied to the application programs, so changing the data
structure often requires updating all programs that use it. In contrast, in a Database Management
System (DBMS), the data structure is stored separately in a catalog, allowing access programs to work
without needing changes when the structure is updated. This is called program-data independence.
In advanced systems like object-oriented databases, users can define operations on data within the
database. Application programs can use these operations without knowing how they are implemented.
This is called program-operation independence.

Both of these features are part of data abstraction, which hides the complex details of data storage and
operation implementation from the users.

Data Abstraction: DBMS provides a high-level view of data, hiding details about storage and
operation implementations. This allows users to work with data without worrying about how it’s stored
or processed.

3. Support for Multiple Views:

 A database can provide different views for different users, allowing each user to see only the
data they need. Some views are derived from the main data but not stored directly.

4. Data Sharing and Multiuser Transaction Processing:

 A DBMS allows multiple users to access and update data simultaneously. It includes
mechanisms to ensure data is correctly updated, especially in applications like online
transaction processing (OLTP). Concurrency control ensures that updates are done in an orderly
manner (e.g., preventing multiple agents from booking the same flight seat).

DATABASE USERS

Actors on the scene : The people whose jobs involve the day-to-day use of a large database are
called as the actors on the scene. They are:-
• Database administrators:
In a database environment, the primary resource is the database itself, and the
secondary resource is the DBMS and related software. Administering these resources
is the responsibility of the database administrator (DBA). The DBA is responsible for
authorizing access to the database, for coordinating and monitoring its use, and for
acquiring software and hardware resources as needed. The DBA is accountable for
problems such as breach of security or poor system response time.
• Database designers:
Database designers are responsible for identifying the data to be stored in the database
and for choosing appropriate structures to represent and store this data. It is the
responsibility of database designers to communicate with all prospective database
users in order to understand their requirements, and to come up with a design that
meets these requirements.

• End users
End users are the people whose jobs require access to the database for querying,
updating, and generating reports, the database primarily exists for their use.
There are several categories of end users:-

• Casual end users occasionally access the database, but they may need different
information each time.
• Naive or parametric end users make up a sizable portion of database end users. Their
main job function revolves around constantly querying and updating the database, using
standard types of queries and updates-called canned transactions-that have been
carefully programmed and tested.
• Sophisticated end users include engineers, scientists, business analysts, and others
who thoroughly familiarize themselves with the facilities of the DBMS so as to
implement their applications to meet their complex requirements.
• Stand-alone users maintain personal databases by using ready-made program
packages that provide easy-to-use menu-based or graphics-based interfaces.

• System analysts determine the requirements of end users, especially naive and
parametric end users, and develop specifications for canned transactions that meet
these requirements.

• Application programmers implement these specifications as programs; then they test,

debug, document, and maintain these canned transactions.

Workers behind the scene : The people who work to maintain the database system environment.
They are associated with the design, development, and operation of the DBMS software and
system environment. They are:

● DBMS system designers and implementers are persons who design and implement
the DBMS modules and interfaces as a software package.

● Tool developers include persons who design and implement tools-the software packages that
facilitate database system design and use and that help improve performance.

● Operators and maintenance personnel are the system administration personnel who
are responsible for the actual running and maintenance of the hardware and software
environment for the database system.
ADVANTAGES AND DISADVANTAGES OF DBMS

The advantages of using DBMS:

1. Data Integrity: Ensures accuracy and consistency of data through constraints and rules.

2. Data Security: Restricts unauthorized access to sensitive data.

3. Data Redundancy Control: Eliminates duplication of data by centralizing storage.

4. Data Independence: Changes in data structure do not affect application programs.

5. Concurrent Access: Multiple users can access data simultaneously without interference.

6. Backup and Recovery: Automatic tools to recover data in case of failure.

Disadvantages of DBMS:

1. Complexity: Setting up and managing a DBMS requires specialized knowledge.

2. Cost: Licensing, hardware, and maintenance can be expensive.

3. Performance Overhead: DBMS may have slower performance due to its abstraction layers
and additional processing.

4. Size: DBMS software and its required resources can take up significant storage.

5. Vulnerability: Centralized data storage makes it a target for cyber-attacks.

Structured, Semi-structured and Unstructured data

Structured data

• Represented in a strict format

• It has been organized into a formatted repository that is typically a database.
• It concerns all data which can be stored in database SQL in a table with rows and columns
• Example: Relational data

Semi-Structured data

• Information that does not reside in a relational database but that has some organizational properties
that make it easier to analyze
• Data is organized using tags or labels.
• Example: XML data
Unstructured data

• Data which is not organized in a predefined manner or does not have a predefined data model, thus it
is not a good fit for a mainstream relational database
• Data is irregular and ambiguous
• Example: Word, PDF, Text, Media logs.
DATA MODELS, SCHEMAS AND INSTANCES
DATA MODELS
Database model defines the logical design and structure of a database and defines how data will be
stored, accessed and updated in a database management system.
While the Relational Model is the most widely used database model, there are other models too:
Hierarchical Model
Network Model
Entity-relationship Model
Relational Model
Hierarchical 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 organized 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.

Network Model
This is an extension of the Hierarchical model. In this model data is organized 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

Entity-relationship 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.
Entity − An entity in an ER Model is a real-world entity having properties called attributes. Every
attribute is defined by its set of values called domain. For example, in a school database, a student is
considered as an entity. Student has various attributes like name, age, class, etc.
 Relationship − The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of association between
two entities.
Mapping cardinalities − one to one , one to many, o many to one, many to many
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

Relational Model
In this model, data is organized 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, in fact, 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. In the
coming tutorials we will learn how to design tables, normalize them to reduce data redundancy and
how to use Structured Query language to access data from tables.

DBMS schema
Definition of schema: Design of a database is called the schema.
Schema is of three types
1. Physical schema/ Internal schema
2. Logical schema/ Conceptual schema
3. View schema/ External schema
• The design of a database at physical level is called physical schema, how the data stored in blocks of
storage is described at this level.
• Design of database at logical level is called logical schema, programmers and database
administrators work at this level, at this level data can be described as certain types of data records
gets stored in data structures, however the internal details such as implementation of data structure is
hidden at this level (available at physical level).
• Design of database at view level is called view schema. This generally describes end user interaction
with database systems.
DBMS Instance
• Definition of instance: The data stored in database at a particular moment of time is called
instance of database. Database schema defines the variable declarations in tables that belong to a
particular database; the value of these variables at a moment of time is called the instance of that
database.
• For example, let’s say we have a single table student in the database, today the table has 100
records, and so today the instance of the database has 100 records. Let’s say we are going to add
another 100 records in this table by tomorrow so the instance of database tomorrow will have 200
records in table. In short, at a particular moment the data stored in database is called the instance
that changes over time when we add or delete data from the database.

THREE SCHEMA ARCHITECTURE AND DATA INDEPENDENCE

The three level architecture describes how data is viewed or represented by user in database. The three
levels of DBMS are explained separately below:
A) External level B) Conceptual level, and C) Physical level

Figure: Three schema architecture

External level/View level: The external level is also called the view level. In the external level there
are the ‘n’ numbers of external end users who can view the data from the database shown above in the
figure. In this level the required data is provided to the end users because there is no need to know
about the all data structure from the database. The users need only that data which is required. The data
can be viewed uniquely or separately by the users or viewers.
The external level is at the top level in architecture of dbms.
Conceptual /logical level: The conceptual level is also called the logical level. In this level it ensures
what data can be stored and also express the relationship among the given data shown above in the
figure. It contains the constraints that are needed to apply on the stored data. The constraints may be
the information related to security etc. The conceptual level holds all the logical structure of entire
database. The entire database in this level is maintained by the DBA.
The conceptual level is at the middle level in architecture of dbms.
Internal/physical level: The internal level is also named as physical level. The internal level express
how data is stored in the files, indices .etc. on the storage devices i.e. secondary storage. It also defines
the data types of the data. The most important task of the internal level is to allocate the space. So, the
space is allocated for the data and indexes in this level. It is at the bottom level of architecture of dbms.
Although the internal level and the physical level is a single level but there is minimal difference
between the physical level and internal level that is the physical level is maintained by the operating
system under the guidance or instructions of the DBMS whereas the internal level is maintained by the
DBMSdirectly
Data Independence:
The three-schema architecture can be used to explain the concept of 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.
1. Logical data independence is the capacity to change the conceptual schema without having to
change external schemas or application programs. We may change the conceptual schema to expand
the database (by adding a record type or data item), to change constraints, or to reduce the database
(by removing a record type or data item). In the last case, external schemas that refer only to the
remaining data should not be affected. Only the view definition and the mappings need be changed in
a DBMS that supports logical data independence.
2. Physical data independence is the capacity to change the internal schema without having to
change the conceptual schema. Hence, the external schemas need not be changed as well.
Changes to the internal schema may be needed because some physical files had to be reorganized-for
example, by creating additional access structures-to improve the performance of retrieval or update. If
the same data as before remains in the database, we should not have to change the conceptual schema.

DBMS LANGUAGES
Database languages are used to read, update and store data in a database. There are several such
languages that can be used for this purpose; one of them is SQL (Structured Query Language).
Mainly has two parts:
Data Definition Language (DDL) and Data Manipulation Language (DML).
The Data Definition Language is used for specifying the database schema, and the Data Manipulation
Language is used for both reading and updating the database. These languages are called data sub-
languages as they do not include constructs for all computational requirements.
Data Definition Language
Data Definition Language (DDL) statements are used to classify the database structure or schema. It is
a type of language that allows the DBA or user to depict and name those entities, attributes, and
relationships that are required for the application along with any associated integrity and security
constraints. 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
Data Manipulation Language
A language that offers a set of operations to support the fundamental data manipulation operations on
the data held in the database. Data Manipulation Language (DML) statements are used to manage data
within schema objects. 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 access path to data
LOCK TABLE - It controls concurrency
Data Control Language
There are another two forms of database sub-languages. The Data Control Language (DCL) is used to
control privilege in Database. To perform any operation in the database, such as for creating tables,
sequences or views we need privileges. Privileges are of two types,
System - creating a session, table, etc. are all types of system privilege.
Object - any command or query to work on tables comes under object privilege. DCL is used to
define two commands. These are:
Grant - It gives user access privileges to a database. Revoke - It takes back permissions from the
user
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.
COMMIT - It saves the work done
SAVEPOINT - It identifies a point in a transaction to which you can later roll back
ROLLBACK - It restores the database to original since the last COMMIT
SET TRANSACTION - It changes the transaction options like isolation level and what rollback
segment to use
DBMS – ARCHITECTURE
The design of a DBMS depends on its architecture. It can be centralized or decentralized or
hierarchical. The architecture of a DBMS can be seen as either single tier or multi-tier. An n-tier
architecture divides the whole system into related but independent n modules, which can be
independently modified, altered, changed, or replaced.
In 1-tier architecture, the DBMS is the only entity where the user directly sits on the DBMS and uses it.
Any changes done here will directly be done on the DBMS itself. It does not provide handy tools for
end-users. Database designers and programmers normally prefer to use single-tier architecture.
If the architecture of DBMS is 2-tier, then it must have an application through which the DBMS can be
accessed. Programmers use 2-tier architecture where they access the DBMS by means of an
application. Here the application tier is entirely independent of the database in terms of operation,
design, and programming.

3-tier Architecture
3-tier architecture separates its tiers from each other based on the complexity of the users and how they
use the data present in the database. It is the most widely used architecture to design a DBMS.
Database (Data) Tier − at this tier, the database resides along with its query processing languages.
We also have the relations that define the data and their constraints at this level.
Application (Middle) Tier − at this tier reside the application server and the programs that access
the database. For a user, this application tier presents an abstracted view of the database. End-users are
unaware of any existence of the database beyond the application. At the other end, the database tier is
not aware of any other user beyond the application tier. Hence, the application layer sits in the middle
and acts as a mediator between the end-user and the database.
User (Presentation) Tier − End-users operate on this tier and they know nothing about any
existence of the database beyond this layer. At this layer, multiple views of the database can be
provided by the application. All views are generated by applications that reside in the application tier.
CLASSIFICATION OF DATABASE MANAGEMENT SYSTEM
Several criteria are normally used to classify DBMSs.
1. The data model on which the DBMS is based: The main data model used in many
current commercial DBMSs is the relational data model. The object data model
was implemented in some commercial systems but has not had widespread use. Many
legacy (older) applications still run on database systems based on the hierarchical
and network data models. The relational DBMSs are evolving continuously, and, in
particular, have been incorporating many of the concepts that were developed in
object databases. This has led to a new class of DBMSs called object-relational
DBMSs. We can hence categorize DBMSs based on the data model: relational, object,
object-relational, hierarchical, network, and other .

2. The number of users supported by the system: Single-user systems support only
one user at a time and are mostly used with personal computers. Multiuser systems,
which include the majority of DBMSs, support multiple users concurrently.
3. 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 themselves 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.
Homogeneous DDBMS use the same DBMS software at multiple sites. A recent
trend is to develop software to access several autonomous pre-existing databases
stored under heterogeneous DBMS. This leads to a federated DBMS (or multi
database system), in which the participating DBMSs are loosely coupled and have a
degree of local autonomy. Many DBMSs use client-server architecture.

4. The cost of the DBMS: The majority of DBMS packages cost between $10,000 and
$100,000. Single-user low-end systems that work with microcomputers cost between
$100 and $3000. At the other end of the scale, a few elaborate packages cost more
than $100,000.
5. We can classify a DBMS on the basis of the types of access path options for storing
files. One well-known family of DBMSs is based on inverted file structures.
6. DBMS can be general purpose or special purpose: When performance is a primary
consideration, a special-purpose DBMS can be designed and built for a specific
application such a system cannot be used for other applications without major
changes. Many airline reservations and telephone directory systems developed in the
past are special purpose DBMSs. These fall into the category of online transaction
processing (OLTP) systems, which must support a large number of concurrent
transactions without imposing excessive delays.
ER MODEL
The Entity Relationship Model is a model for identifying entities to be represented in the database and
representation of how those entities are related. The ER data model specifies enterprise schema that represents
the overall logical structure of a database graphically. Peter Chen developed the ER diagram in 1976. The ER
model was created to provide a simple and understandable model for representing the structure and logic of
databases.
Collection of entities and their properties called attributes and relationship between them
ER diagram is diagrammatic representation and easy to understand for non-technical users.
Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.

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.
Entity Set
An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example, E1 is an
entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram, Entity Type
is represented as:

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because entity is row
and column in the relation and ER Diagram is graphical representation of data.
Types of Entity
There are two types of entity:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other Entity in
the Schema. It has a primary key that helps in identifying it uniquely and it is represented by a rectangle.
These are called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity type
exists for which key attributes can’t be defined. These are called Weak Entity types.
For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can’t exist without the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type for Dependent, which means it is Strong Entity Type .
A weak entity type is represented by a Double Rectangle. The participation of weak entity types is always
total. The relationship between the weak entity type and its identifying strong entity type is called identifying
relationship and it is represented by a double diamond.
Attributes
Attributes are the properties that define the entity type. For example, Roll No, Name, DOB, Age, Address, and
Mobile No are the attributes that define entity type Student. In ER diagram, the attribute is represented by an
oval.

NOTATIONS USED IN E-R DIAGRAM

Types of Attributes
• Simple attribute vs. Composite attribute
• Single valued vs. Multivalued attributes
• Stored vs. Derived attributes
Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute. For example,
Roll_No will be unique for each student. In ER diagram, the key attribute is represented by an oval with
underlying lines. Key attribute will never be a null valued attribute. Any composite attribute can also be a key
attribute. • There could be more than one key attributes for an entity type. Example: roll_no, enrollment _no

Simple attributes ▫ Attributes which are not divisible that is they cannot be divided ▫ Eg: City, State, etc,

Composite Attribute
Composite Attribute ▫ Attributes that can be divided into smaller sub parts ▫ Example: Name attribute can be
divided into First Name, Middle Name, and Last Name
Single Valued Attributes ▫ Attributes which are having single values ▫ Example: Age

Here all the attributes are single valued attributes, so they can take only one specific value for each entity.

Multi Valued Attributes ▫ Multi valued attributes are those attributes which can take more than one
value for a given entity from an entity set. ▫ Represented by double oval

Here the mob_no. and email_id are multi valued attributes, so they can take more than one values for a
given entity.

Stored vs. Derived Attribute - In some cases, two (or more) attribute values are related, for example,
the Age and Birthdate attributes of a person.
For a particular person entity, the value of Age can be determined from the current (today’s) date and
the value of that person’s birthdate. The Age attribute is hence called a derived attribute and is said
to be derivable from the birthdate attribute, which is called a stored attribute.
Complex Attribute - Complex attribute is a combination of composite and multi-valued attributes.
Complex attributes are represented by { } and composite attributes are represented by ( ).
Example: Address_phone attribute will hold both the address and phone_no of any person.
Example: {(2-A, St-5, Sec-4, Bhilai), 2398124}
Null Valued Attributes - Null value is a value which is not inserted but it does not hold zero value.
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.
Domain of value set of an attribute - Domain of an attribute is the allowed set of values of that
attribute.
Example: if attribute is ‘grade’, then its allowed values are A,B,C,F. • Grade ={A, B,C,F}

RELATIONSHIP
• Relates two or more distinct entities with a specific meaning. It is an association between two or
more entities of same or different entity set
For example, EMPLOYEE John works on the ProductX PROJECT or EMPLOYEE Franklin
manages the Research DEPARTMENT.
• Terms used: ▫ Relationship type, ▫ Relationship set, ▫ Relationship instances.
Relationship type
• A set of similar types of relationship

Relationship Set
• A relationship set is a set of relationships of the same type.
Graphical Representation of Relationship Sets

CONSTRAINTS
• Relationship types usually have certain constraints. Two main types of relationship constraints:
1. Mapping cardinalities 2. Participation constraints
Degree of a relationship
• It is the number of entity set which are participating in a relationship
▫ Unary relationship ▫ Binary Relationship ▫ Ternary Relationship
Each relationship has  ▫ Name ▫ Degree ▫ Cardinality ratio
Cardinality Ratio
• The cardinality ratio for a binary relationship specifies the maximum number of relationship instances
to which an entity can take part in it. It also specifies number of entities to which other entity can be
related by a relationship.
Types:-
▫ One-to-one (1:1)
▫ One-to-many (1: N)
▫ Many-to-one (N: 1)
▫ Many-to-many (M: N)
We express cardinality ratio by drawing
• directed line (→), signifying “one,” or an • undirected line (—), signifying “many,”
One to One (1:1)
When only a single instance of an entity is associated with single instance of other entity by a
relationship • When every entity of one entity set is related to maximum one entity of other entity set

One to Many (1:M)

• When every entity of first entity set is related to at most (max) n entities of other entity set then it is
one to many

In the one-to-many relationship a customer is associated with several loans via borrower
Many to One

Many to One (M:1)

• When many entities of first entity set is related to 1 entity of other entity set then it is many to
one

In a many-to-one relationship a loan is associated with several customers via borrower.

Many to Many (M: N)

• When many occurrences of one entity is related to many occurrences of another entity
Participation constraints
• It specifies whether the existence of an entity depends on being related to another entity through
relationship types
• These constraints defines max and min number of relationship instance that each entity can
participate in
• Maximum cardinality ▫ It defines maximum number of times an entity can participate in a
relationship
• Minimum Cardinality ▫ It defines minimum number of times an entity can participate in a
relationship
There are two types of participation constraints 1. Total Participation 2. Partial Participation
Total participation
• Every entity in the entity type participates in at least one relationship in the relationship type
E.g. participation of loan in borrower is total every loan must have a customer associated to it via
borrower
• Represented by double lines
• Minimum and maximum cardinality represented inside parentheses(m,n)

Partial participation
• Some entities may not participate in any relationship in the relationship type
Example: participation of customer in borrower is partial
• Represented by single line
 TYPES OF ENTITY TYPES
• Strong entity type
Entity types that have at least one key attribute. A strong entity is not dependent of any other
entity in the schema. A strong entity will always have a primary key. Strong entities are
represented by a single rectangle.
The relationship of two strong entities is represented by a single diamond.Various strong entities,
when combined together, create a strong entity set.
 Weak entity type
Entity type that does not have any key attribute. A weak entity is dependent on a strong entity
to ensure the existence. Unlike a strong entity, a weak entity does not have any primary key. It
instead has a partial discriminator key. A weak entity is represented by a double rectangle. The
relation between one strong and one weak entity is represented by a double diamond.

Identifying Relationship
• It links the strong and weak entity and is represented by a double diamond sign.
• Let us see with an example to link both the entities using Identifying Relationships:
Let us take an example of Professor entity, which is our Strong Entity, Professor_ID as a Primary Key
.The weak entity is Professor_Dependents entity:
• Here Dependent is a weak entity and has no primary key .Professor has a primary key so is the strong
entity
Relationship of degree 3
In Ternary relationship three different Entities takes part in a Relationship.Relationship Degree = 3
For Example: Consider a Mobile manufacture company. Three different entities involved:
Mobile - Manufactured by company.
Part - Mobile part which company get from Supplier.
Supplier - Supplier supplies Mobile parts to Company.
Mobile, Part and Supplier will participate simultaneously in a relationship. Because of this fact when
we consider cardinality we need to consider it in the context of two entities simultaneously relative to
third entity.

Cardinality in Ternary Relationship

Say for a given instance of Supplier and an Instance of Part, can that supplier supply that particular part
for multiple Mobile models.
Example − Consider a Supplier S1 that supplies a Processor P1 to the company and the uses the
Processor P1 supplied by Supplier S1 in its multiple Models in that case the cardinality of Mobile
relative to Supplier and Part is N (many).
In case of Supplier’s cardinality we can say for a given instance of Mobile one of its Part can be
supplied by multiple Suppliers.
Example − Consider a Mobile M1 that has a Part P1 and it is being supplied by multiple Suppliers in
that case the cardinality of Supplier relative to Mobile and Part is M (many).
Similarly, for a given instance of Supplier and an instance for Mobile do the Supplier supply multiple
Parts.
Example − Consider a Supplier S1 supplying parts for Mobile M1 like screen, Processor etc. in that
case the cardinality of Part relative to Supplier and Mobile is P (many).
Construct an E-R diagram for a car-insurance company whose customers own one or more cars each.
Each car has associated with it zero to any number of recorded accidents

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 conducted

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