Database Management System

(KCS-501)
Instructor: Md shahid
Unit-01

Syllabus— Introduction: Overview, Database System vs File System,

Database System Concept and Architecture, Data Models, Schema and
Instances, Data Independence and Database Language and Interface,
Data Definition Language, DML, Overall Database Structure, Data
Modeling Using the Entity Relationship Model: ER model concepts,
Notations for ER Diagrams, Mapping Constraints, keys, Concept of super
key, candidate key, primary key, Generalization, Aggregation, Reduction
of an ER Diagram to Tables, Extended ER Model, Relationship of Higher
Degree.

Overview of database systems

Data— It refers to any piece of information or fact that can be recorded. It includes
various forms such as text, images, audio, videos, and more.

Database— It is a collection of related data.

DBMS— It is a set of programs that provides an interface for users to define,
construct and manipulate databases. Examples include MySQL, Oracle database,
Microsoft SQL Server, PostgreSQL, IBM Db2, etc.

RDBMS— A Relational Database Management System (RDBMS) is a type of

Database Management System (DBMS) that is based on the relational model
introduced by E.F. Codd. In an RDBMS, data is stored in tables (relations), which
consist of rows and columns.

Database System— Database + DBMS

 File System

File System— A file system is a method used by operating systems to store,

organize, and manage files on storage devices such as hard drives, solid-state drives
(SSDs), and optical discs. It provides a structured way to access and manipulate data
stored on these devices.

Disadvantages of File System over Database Approach—

1. Data Redundancy
2. Data Inconsistency
3. Data Integrity
4. Concurrency Issues
5. Security Risks

Q. List any five disadvantages of file system over database approach.

Q. How do data redundancy and inconsistency issues differ between a traditional
file system and a modern database management system?
Answer—
Data Redundancy:
Traditional File System:
Issue: In a traditional file system, data redundancy is common because the same
data might be stored in multiple files. For example, customer information might be
duplicated in several departmental files (e.g., sales, billing, and support).
Impact: This redundancy leads to inefficient use of storage space and can make
data management difficult. Updating data in one file doesn’t automatically update
it in other files, leading to increased chances of outdated or duplicated data.
Modern Database Management System (DBMS):
Solution: A DBMS is designed to minimize data redundancy through
normalization—a process that organizes data into tables to reduce duplication and
ensure that each piece of data is stored in one place.
Impact: By reducing redundancy, a DBMS improves storage efficiency and simplifies
data management. Changes made to data in one place are reflected across the
database, maintaining consistency and reducing the likelihood of outdated or
conflicting information.

Data Inconsistency:
Traditional File System:
Issue: Data inconsistency arises when redundant data in multiple files diverges due
to discrepancies in updates. For example, if customer addresses are updated in one
file but not in another, different files might contain conflicting information about
the same customer.
Impact: This inconsistency can lead to incorrect reporting, errors in decision-
making, and difficulties in maintaining accurate records.

Modern Database Management System (DBMS):

Solution: DBMSs enforce data integrity constraints and provide mechanisms like
foreign keys, unique constraints, and transaction management to ensure
consistency across the database. When a change is made, the DBMS automatically
updates related records, maintaining data integrity.
Q. What are the key differences between a traditional file system and a modern
database management system?

Answer—
File System Database Approach (DBMS)
It is an integral part of the operating system It is a separate software application that
(OS). Examples include NTFS, FAT32, and ext4. provides an interface for users to interact with
databases. Examples include MySQL,
PostgreSQL, and Oracle.
It provides the foundational storage It builds on top of this foundation (provided by
capabilities. the file system) to offer comprehensive and
advanced data management solutions.

Redundant data is often found, leading to Redundancy is controlled and consistency is

inconsistencies. maintained through normalization.

Limited data sharing is possible; data is Facilitates data sharing among multiple users.
scattered.

Provides minimal security; data is not well- Provides robust security measures to protect
protected. data.

Backup and recovery mechanisms are not Provides efficient and automated backup and
efficient. recovery mechanisms.

Maintaining data integrity is challenging and Enforces data integrity constraints

requires additional programming. automatically.

Does not handle concurrent access Manages concurrent access using transaction
effectively, leading to conflicts. management and locking mechanisms.
 Three-Schema Architecture of DBMS
The three-schema architecture, also known as the ANSI/SPARC architecture, is a
framework for database management systems that separates the database system
into three distinct levels of abstraction: the internal schema, the conceptual
schema, and the external schema. This architecture aims to separate the user
applications and the physical database to provide data independence.

1. External Schema (User View):

This schema represents how the data appears to the end users or applications
interacting with the database. It defines various user views or subsets of the
database tailored to specific user groups or applications. Each external
schema provides a simplified and customized view of the data, hiding
unnecessary details and complexity.
2. Conceptual Schema (Logical Schema):

The conceptual schema represents the entire logical structure of the

database, including all entities, relationships, and constraints. It serves as an
intermediary layer between the external and internal schemas, providing a
unified and abstract view of the data that is independent of any specific
implementation or storage details.

3.Internal Schema (Physical Schema):

The internal schema describes how the data is physically stored and organized
within the database system. It includes details such as data storage structures,
indexing mechanisms, and access methods. The internal schema is optimized
for efficient storage and retrieval of data, considering factors such as
performance, scalability, and resource utilization.

Note— The ANSI/SPARC DBMS Model, also known as the ANSI/SPARC three-
level architecture, is a conceptual framework proposed by the American
National Standards Institute (ANSI) and the Standards Planning and
Requirements Committee (SPARC) in the late 1970s. It provides a high-level
conceptual view of database systems and serves as a foundation for
understanding and designing modern database management systems
(DBMS).

Data Independence

It refers to the ability to modify the database schema at one level without
affecting the schema at higher levels. The three-schema architecture
promotes data independence by separating the external, conceptual, and
internal schemas:
 1. Logical Data Independence:

Logical data independence allows changes to the conceptual schema without

affecting the external schemas or applications that rely on it. For example,
adding a new entity or modifying relationships between existing entities in the
conceptual schema should not require changes to the external schemas or
application programs.

2. Physical Data Independence:

Physical data independence allows changes to the internal schema without

affecting the conceptual schema or external schemas. For example,
reorganizing the storage structures or changing indexing strategies in the
internal schema should not impact the logical structure of the database or the
views presented to users.

Database Administrator (DBA)

One of the primary reasons for using a DBMS is to establish central control over
both the data and the programs that access that data. This central control ensures
consistency, integrity, and security across the system. The individual responsible
for maintaining this control and managing the overall operation of the database
system is known as the Database Administrator (DBA).
Functions of a DBA:
1. Schema Definition
Task: The DBA is responsible for defining the database schema, which
includes the creation of tables, views, indexes, and relationships. The schema
is a logical structure that defines how data is organized and how the
relationships between data are managed.
Purpose: This forms the blueprint of the database, ensuring that it accurately
represents the business requirements and supports data integrity.
2. Storage Structure and Access-Method Definition
 Task: The DBA defines the storage structures for the database, such as how
data files, indexes, and logs are organized on disk. This includes deciding on
access methods, which determine how data is retrieved and modified (e.g.,
B-trees, hash indexes).
Purpose: Efficient storage and access methods are crucial for optimizing
database performance and ensuring quick data retrieval and updates.
3. Schema and Physical-Organization Modification
Task: Over time, the DBA may need to modify the database schema to
accommodate new requirements, such as adding new tables or altering
existing ones. Physical organization modifications involve changing how data
is stored or accessed, such as reorganizing tables or rebuilding indexes.
Purpose: These modifications ensure that the database can adapt to
changing business needs while maintaining performance and data integrity.
4. Granting of Authorization
Task: The DBA manages database security by granting or revoking access
permissions to users or roles. This includes defining who can read, modify, or
delete data and who can execute specific database operations.
Purpose: Authorization management is critical for protecting sensitive data
and ensuring that only authorized users can perform certain operations.
5. Routine Maintenance
Task: Routine maintenance involves regular tasks such as backing up the
database, monitoring performance, and ensuring that the database is
running smoothly. It also includes tasks like updating statistics,
defragmenting tables, and applying patches.
Purpose: Routine maintenance ensures that the database remains reliable,
performs optimally, and is protected against data loss or corruption.
 Database System Architecture
It refers to the arrangement of components within a database system and how
they interact to store, manage, and retrieve data. The architecture can be
classified into various tiers based on the number of layers or tiers involved in
the system. The most common classifications are one-tier, two-tier, and
three-tier architectures:

1. One-Tier Architecture – In a one-tier architecture, also known as a single-

tier architecture, all components of the database system are installed and
run on a single machine. Both the database management system (DBMS)
software and the application software (user-interface software that allows
users to interact with the database.) reside on the same machine. This
architecture is typically used for small-scale applications where the entire
system, including the database and the user interface, can be managed on a
single computer. For example, Microsoft Access, SQLite, etc.

2. Two-Tier Architecture (Client-Server Architecture)— In a two-tier

architecture, the database system is divided into two layers: the client layer
and the server layer. The client layer consists of user interfaces or
applications that interact directly with the database. The server layer
includes the database management system (DBMS) and the database itself.
Client applications communicate with the server to retrieve or manipulate
data, but the data processing and storage tasks are handled by the server.
This architecture allows for better scalability and separation of concerns
compared to a one-tier architecture, making it suitable for medium-scale
applications.
3. Three-Tier Architecture— In a three-tier architecture, the database
system is divided into three layers: the presentation layer, the application layer
(also known as the middle tier), and the data layer. The presentation layer is
responsible for presenting the user interface to the end user and capturing user
inputs. The application layer contains the business logic and application
functionality, including data processing and application logic. The data layer
consists of the database management system (DBMS) and the database itself,
handling data storage and retrieval tasks. This architecture provides better
scalability, flexibility, and maintainability compared to two-tier architectures. It
allows for separation of concerns, enabling changes in one layer without
affecting the others. Three-tier architectures are commonly used in large-scale
enterprise applications and web-based systems.
Q. Draw the overall structure (architecture) of DBMS and explain its various
components.

Answer—

A database system can be divided into three main components: Query Processor,
Storage Manager, and Disk Storage. Each of these components plays a crucial role
in the overall functioning of the database system. Here’s a brief explanation of
each:
1. Query Processor: The query processor handles high-level database operations
and transforms user queries into a series of low-level instructions that can be
executed by the storage manager.
Components:
 Compiler and Linker: Converts application programs into executable object
code.
 DML Queries: Data Manipulation Language (DML) queries are used by
sophisticated users to retrieve and manipulate data.
 DDL Interpreter: Interprets Data Definition Language (DDL) statements to
define and manage the database schema.
 Application Program Object Code: Object code resulting from the
compilation of application programs, ready for execution.
 DML Compiler and Organizer: Compiles DML queries into an executable form
and organizes them for efficient processing.
 Query Evaluation Engine: Executes the compiled queries and interacts with
the storage manager to access or modify data.
2. Storage Manager: The storage manager is responsible for the efficient storage,
retrieval, and update of data in the database.
Components:
 Buffer Manager: Manages memory buffers that temporarily store data
during processing to improve performance.
 File Manager: Handles the storage, retrieval, and management of data files
on disk.
 Authorization and Integrity Manager: Ensures that all database operations
comply with security and integrity constraints.
 Transaction Manager: Manages transactions to ensure the ACID properties
(Atomicity, Consistency, Isolation, Durability) are maintained.

3. Disk Storage: Disk storage is where the actual data is stored. This includes not
only the data itself but also indices, metadata, and statistical data.
Components:
 Data: The actual data stored in the database.
 Indices: Data structures that improve the speed of data retrieval operations.
 Data Dictionary: Metadata repository containing information about the
database schema, structure, and constraints.
 Statistical Data: Statistical information used to optimize query processing
and execution plans.

Schema and Instance

Database Schema— It is the logical design of the database. It is prepared from

an ER diagram and is the final step before the database is implemented on a
machine.

For example
A database schema for the representation of students, courses, and their
enrollments in a relational database, tracking student information, course details,
and enrollment records within the university database system.
Student
Student_id (primary key) First_Name Last_Name DOB Email Ph.no

Course
Course_id (primary key) Course_name Department Credits

Enrollment
Enrollment_id Student_id (Foreign Course_id Enrollment_date Grade
(primary key) key referencing (Foreign key
Student table) referencing
Course table)
Database Instance— It is a snapshot of the data in the database at a given
instance of time.

Data Models
A data model is a collection of concepts and rules that are used to describe the
structure of a database, including the data types, relationships, and constraints
that apply to the data.

Types of Data Models

1. Relational Data Model (representational or implementation data model)
2. Entity-Relationship Model (high level or conceptual data model)
3. Semi-structured Data Model
4. Object-based Data Model

1. Relational Data Model— This model organizes data into tables (relations),
where each table consists of rows and columns. Relationships between
tables are established through keys. It's the most widely used in modern
database management systems (DBMS) and is based on relational algebra
and calculus.

2. Entity-Relationship Model— The ER model is used to describe the

conceptual structure of a database. It is used in the database design phase
to create a blueprint of the database.

3. Semi-structured Data Model— This model is designed to handle data that

doesn't fit neatly into the rows and columns of a relational database.
Semi-structured data often lacks a fixed schema and can have varying
structures. Examples include XML, JSON, and key-value pairs. NoSQL
databases often use semi-structured data models.

4. Object-Based Data Model— In this model, data is represented as objects,

similar to the objects in object-oriented programming (OOP). Each object contains
data (attributes) and methods (functions) that operate on the data. Object-
 oriented databases (OODBs) and object-relational databases (ORDBs) use this
model, providing a way to directly represent real-world objects in the database.

Note— The network and hierarchical models are legacy data models that were
widely used in the past. These models played a significant role in the early
development of database systems but have largely been replaced by the more
flexible and powerful relational model.

Database Languages

DDL (Data Definition Language) and DML (Data Manipulation Language) are the
core languages provided by a database system. In practice, the DDL and DML are
not two separate languages; instead they simply form parts of a single database
language, such as the SQL language. Almost all RDBMS employ the SQL language.

Data Definition Language (DDL)— We specify a database schema by a set of

definitions expressed by a special language called a data-definition language. The
DDL is also used to specify additional properties of the data, such as constraints,
defaults, and data types. These properties ensure data integrity, enforce business
rules, and maintain consistency within the database.

We specify the storage structure and access methods used by the database system
by a set of statements in a special type of DDL called a data storage and definition
language (DSDL). These statements define the implementation details of the
database schemas, which are usually hidden from the users.

By using DDL, database administrators and developers can effectively manage the
structure and properties of the database, ensuring data consistency, integrity, and
usability.
Here are some common tasks accomplished using DDL:

 Creating Tables: Define the structure of database tables, including

column names, data types, constraints, and indexes.

 Altering Tables: Modify the structure of existing tables by adding,

modifying, or dropping columns, constraints, or indexes.

 Dropping Tables: Remove existing tables from the database schema.

 Creating Indexes: Define indexes on tables to improve query

performance by enabling faster data retrieval.

 Creating Views: Define virtual tables that present data from one or
more tables in a predefined manner.

 Defining Constraints: Specify rules and conditions that data must

adhere to, such as primary keys, foreign keys, unique constraints, and
check constraints.

 Defining Defaults: Specify default values for columns that are

automatically assigned when a new row is inserted into the table.

Data Manipulation Language (DML)— DML provides users with the tools to
retrieve, insert, update, and delete data within a database, enabling them to
interact with the data stored according to the defined data model.

functions of DML:

 Retrieving Data: DML allows users to query the database to retrieve

specific data based on defined criteria. The SELECT statement is the
primary DML command used for data retrieval.
  Inserting Data: DML enables users to add new records or rows of data to
database tables. The INSERT statement is used to insert new data into the
database.

 Updating Data: DML provides mechanisms for modifying existing data

within the database. The UPDATE statement is used to change the values
of one or more columns in existing rows.

 Deleting Data: DML allows users to remove records or rows of data from
database tables. The DELETE statement is used to delete data from the
database.

Data Manipulation Languages (DMLs) can be broadly categorized into two types
based on their approach to specifying data manipulation operations:

a. Procedural DMLs: Procedural DMLs require users to specify the step-by-step

procedure or algorithm for performing data manipulation operations. Users
need to explicitly define the sequence of actions to retrieve, insert, update,
or delete data from the database. Examples of procedural DMLs include
languages like PL/SQL (Procedural Language/Structured Query Language) for
Oracle databases and T-SQL (Transact-SQL) for Microsoft SQL Server.

b. Declarative (nonprocedural) DMLs: Declarative DMLs allow users to specify

what data they want to manipulate, rather than how to manipulate it. Users
specify their data manipulation requirements using high-level statements or
queries, and the database system determines the most efficient way to
execute those operations. The focus is on the desired outcome rather than
the specific steps to achieve it. SQL (Structured Query Language) is a prime
example of a declarative DML, where users write queries to retrieve, insert,
update, or delete data, and the database system handles the optimization
and execution of those queries.
Here's how SQL incorporates both DDL and DML functionalities:

DDL (Data Definition Language): SQL includes DDL commands for defining
and modifying the structure of the database schema. These commands allow
users to create, alter, and drop database objects such as tables, views,
indexes, and constraints.

Examples of DDL commands in SQL include CREATE TABLE, ALTER TABLE, and
DROP TABLE.

DML (Data Manipulation Language): SQL provides DML commands for

retrieving, inserting, updating, and deleting data from the database. These
commands allow users to interact with the data stored in the database
tables.
Examples of DML commands in SQL include SELECT, INSERT, UPDATE, and
DELETE.
Q, State the procedural DML and nonprocedural DML with their differences.
Answer—
 Entity-Relationship (ER) Model

 It is a high-level conceptual data model used in database design to represent the

data and its relationships. It provides a clear way to visualize data and how entities
in a system interact with each other.

 The ER model utilizes concepts from set theory to represent entities as sets,
attributes as sets of values, and relationships as sets of tuples.

 The ER model describes data as entities, relationships, and attributes.

 An ER diagram is a graphical representation of the ER model.

 The Entity-Relationship (ER) model is independent of any specific Database

Management System (DBMS).

Entity
Entity— It is an individual instance of a real-world object or concept that
has a distinct and independent existence.

Entities can be categorized into:

 Real-World Objects: Tangible items that exist physically and can be
uniquely identified. Examples include Employee1, Employee2,
Department1, and Department2.
 Real-World Concepts: Abstract ideas or categories. Examples include
Project1, Project2, and RoleA.
 Entity Type
It is a class of similar entities with common attributes. For example, employee,
project, and department are entity types.
 An entity type defines a set of entities that have the same attributes.
 Each entity type has attributes that describe the characteristics of the
entities. For instance, the Employee entity type might have attributes like
EmployeeID, Name, and Position.

Entity Set
An entity set is a collection of all individual entities of a particular entity type that
exist within the database at a given point in time. It is the actual data or instances
that correspond to the entity type; the entity set is usually referred to using the
same name as the entity type.

Strong Entity Type

A strong entity type is an entity type whose instances (entities) can be uniquely
identified by their own attributes alone, without needing any other entity types to
establish their uniqueness. It has a set of attributes that collectively provide a
unique identifier for each instance. For example, a Student entity type might have
attributes like StudentID, Name, and DateOfBirth and StudentID as the key
attribute.

Name DateOfBirth
StudentID

Student
 Fig: A Strong Entity Type “Student”

Student (StudentID, Name, DateOfBirth)

StudentID Name DateOfBirth

220000000001 Rahul 2002

220000000002 Raj 2001
220000000003 Sahil 2000
220000000004 Raghav 2001
220000000005 Meharban 2000

Fig: A table (relation) for Strong Entity Type “Student” containing 5 entities

Weak Entity Type

A weak entity type cannot be uniquely identified by its own attributes alone. It
relies on a strong entity, known as the owner or parent entity type, for its
identification. A weak entity is represented by a double rectangle, and the
relationship between the weak entity and its strong entity is indicated by a
double diamond.

Note— “Entity” is a broader term that can refer to both the general concept (entity
type) and specific instances depending on the context.
 Attribute
It is a property that describes an entity. For example, employee_id, name, and
salary are attributes of entities such as "employee1" and "employee2." Attributes
are represented by ovals and are connected to an entity type and relationship type.

Simple Attributes vs Composite Attributes

Simple Attributes— Attributes that cannot be divided are called simple or atomic
attributes. Examples include employee_id, sex and salary. Each of these attributes
contains a single piece of information.
Composite Attributes— Attributes that can be divided into smaller subparts are
called composite attributes. Each subpart represents a more specific piece of
information. For example, an employee name attribute might be composite,
consisting of first name, middle name and last name.
First_name Middle_name Last_name

Sex

DOB
Emp_id
Emp_name

Employee

Single-Valued Attributes vs Multi-Valued Attributes

Single-Valued Attributes— Attributes that hold a single value for each entity
instance are called single-valued attributes.
Multi-Valued Attributes— Attributes that hold multiple values for each entity
instance are called multi-valued attributes and represented by double ovals.

Stored Attributes vs Derived Attributes

Stored Attributes— Values that are directly stored in the database are called
stored attributes.
Derived Attributes— Values that are derived from the values of stored attributes
are called derived attributes. For example, in an employee database, the age of an
employee can be a derived attribute if it is calculated from the stored attribute
DOB. Another example is the total_price of an order, which can be derived from
the stored attributes unit_price and quantity. Derived attributes are represented
by dashed ovals in ER diagrams.
 Key Attribute of an Entity Type

Key Attributes— key attributes refer to one or more attributes that together
uniquely identify each instance of an entity type. When an entity type has multiple
attributes that, when combined, uniquely identify an entity, they are collectively
known as a composite key or composite key attribute. For example, in an employee
database, the attribute employee_id can be a key attribute because it uniquely
identifies each employee in the database. Key attributes are represented by
underlining them in ER diagrams.

Name Address

Emp_id

oEmployee

Key attribute
 Relationship Type

A relationship type is a blueprint that defines a specific kind of association between

two or more entity types. It describes the general nature of the association,
including the entities involved and the possible cardinalities. For example, the
relationship type "Works For" defines a general association between the Employee
entity type and the Department entity type. It describes the fact that employees
are assigned to departments within an organization.

 Relationship type is depicted as a diamond shape.

Relationship
A relationship refers to an actual instance or occurrence of a relationship type
between specific entities. It is the specific connection between particular instances
of the involved entity types. In ER diagrams, individual relationships are usually not
explicitly shown; rather, the focus is on the relationship type that defines the
general association. For example, If Employee1 works for the Marketing
department, this is an actual instance of the "Works For" relationship type.

Employee Works for Department

e1 r1

e2 r2 d1
e3 r3 d2
e4 r4 d3
e5
The relationship instance r1 is associating e1, of entity type Employee, with d1 of
entity type Department.
 A relationship instance in a relationship set R is an association of entities
where the association includes exactly one entry from each participating
entity type. This means that a relationship instance represents a specific
connection between one instance of each participating entity type in the
relationship.

Degree of a Relationship Type

The degree of a relationship type refers to the number of entity types that
participate in that relationship. It indicates how many entities are involved in the
relationship.
Types of Degrees:
1. Unary (Degree 1): A relationship type involving only one entity type is said
to have degree 1. This is also known as a recursive relationship.

Recursive Relationship— If the same entity type participates more than once in a
relationship type in different roles, it is called a recursive relationship. For example,
an employee supervises other employees within the same entity type.
Supervises
e1
Employee r1 role1 = supervisor (in black)
e2 r2 role2 = supervisee (in blue)
e3
r3
e4

e5

e
 2. Binary (Degree 2): A relationship type involving two different entity types is
said to have degree 2. Binary relationships are the most common. For
example, The "Works For" relationship type between the Employee and
Department entity types.

3. Ternary (Degree 3): A relationship type involving three different entity types
is said to have degree 3.
For Example, A "Supplies" relationship type might involve the Supplier,
Product, and Store entity types, indicating that a supplier supplies products
to stores.

Cardinality and participation are two fundamental constraints that describe the
nature of a relationship between entities in an Entity-Relationship Diagram (ERD).
These constraints help define how entities are associated with each other within a
relationship. The participation constraint is often referred to as the minimum
cardinality of a relationship. The cardinality constraint is also referred to as the
cardinality ratio. Cardinality and participation are collectively referred to as the
structural constraints.

Cardinality Ratio of a Binary Relationship

 The cardinality ratio of a binary relationship specifies the maximum number

of relationship instances that an entity can participate in, and it is
determined by examining the constraints mentioned in the requirements.
Types of Cardinality Ratio:
1. 1: 1 (one to one)
2. 1: N (one to many)
3. N: 1 (many to one)
4. M: N (many to many)

1. One to one (1:1) – The maximum number of relationship instances that an

entity can participate in is one.

Constraints (as per requirements) : Every department should have a

manager, and one employee can manage only one department.
 Employee Manages Department

e1 r1
d1
e2 r2
d2
e3 r3
d3
e4 r4
d4
e5

Cardinality Ratio in ER diagram

1 1
Employee Department
Manages

2. 1: N (one to many)—
Constraints: Every employee works for a department, and a department can
have many employees. New departments need not have any employee.
 Employee Works for Department

e1 r1
d1
e2 r2
d2
e3 r3
d3
e4 r4

Cardinality Ratio in ER diagram for One-TO-Many

Employee N 1
Works for Department
 OR

Employee Department
Works for

Note— The cardinality ratio in an ERD is mentioned on the opposite side. For
example, for a 1: N relationship, 'N' is mentioned on the left side of the relation and
'1' is mentioned on the right side.
3. N: 1 (many to one)
In a one-to-many relationship, we look at it from the perspective of the
"one" side. In a many-to-one relationship, we look at it from the perspective
of the "many" side. Essentially, they describe the same relationship but from
different angles.

4. M: N (many to many)
Constraints: Every employee should work on at least one project,
and a project should have at least one employee.

Employee Works on Project

E1
r1
E2 P1
r2
E3 p2
r3
E4 p3
r4

r5

r6

Fig: 5
Cardinality Ratio in ER diagram for Many -to-Many

Employee N M
Works on Project

OR

Employee Project
Works on

Participation Constraint
The participation of a binary relationship specifies the minimum number of
relationship instances that an entity can participate in, and it is determined by
examining the constraints mentioned in the requirements.
Types of Participation
1. Partial Participation: Only some instances of an entity type
participate in the relationship. A single line is used to indicate it.
2. Full Participation: All instances of an entity type participate in the
relationship. Double lines are used to indicate it.
Mapping Participation in ER diagram: From figure 5, we can observe that Employee
to Project and Project to Employee participations are full participation.

Employee Project
Works on
 Identifying the “Entity Types” and “Attributes” from the
Requirements

Requirements:
The company is organized into departments. Each department has a unique name,
a unique number, and a particular employee who manages the department. We
keep track of the start date when that employee began managing the department.
A department may have several locations. A department controls a number of
projects, each of which has a unique name, a unique number, and a single location.
The database will store each employee’s name, Social Security number, address,
salary, gender, and birth date. An employee is assigned to one department, but
may work on several projects, which are not necessarily controlled by the same
department. It is required to keep track of the current number of hours per week
that an employee works on each project, as well as the direct supervisor of each
employee (who is another employee).
The database will keep track of the dependents of each employee for insurance
purposes, including each dependent’s first name, gender, birth date, and
relationship to the employee.

Answer—
The company is organized into departments. Each department has a unique name,
a unique number, and a particular employee who manages the department. We
keep track of the start date when that employee began managing the department.
A department may have several locations.

Manager Manager_Start_Date
Name Locations

Dept.number

Department
 A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.

Number Location Controlling_Dept

Name

Project

The database will store each employee’s name, Social Security number, address,
salary, gender, and birth date. An employee is assigned to one department, but
may work on several projects, which are not necessarily controlled by the same
department. It is required to keep track of the current number of hours per week
that an employee works on each project, as well as the direct supervisor of each
employee (who is another employee).

L_name
F_name
M_nam Supervisor Hours Project
e
Dept.
SSN
DOB Gende Salary
r Works
Works on
on
Name Salary

Address

Employee
The database will keep track of the dependents of each employee for insurance
purposes, including each dependent’s first name, gender, birth date, and
relationship to the employee.

Gender DOB
Depen_name

Employee
Relationship

Dependent

Identifying the “Relationship Type” between the Entity Types

 When an attribute of one entity type refers to another entity type, it usually
indicates that there is a relationship between those entities. The relationship
type is indicated by a diamond in an ER diagram.

Works for

We can clearly observe that the attribute "Dept" of entity type "Employee" refers
to another entity type "Department", leading to a relationship type "Works for".
Therefore, we remove the attribute "Dept" from the "Employee" entity type and
represent this relationship explicitly.

Identifying another Relationship Type

Manages

We can clearly observe that the “manager” attribute of the entity type Department
refers to another entity type, Employee. Therefore, the manager attribute will be
converted into a relationship type, and the attribute will be deleted from the
Department entity type.
 Attributes of a Relationship Type
Attributes from the entity type that are closely related to a relationship type
become attributes of the relationship type and are then deleted from the entity
type.

Manager_start_date
Q. Given the following constraints:
 Every employee works for a department.
 A department can have many employees.
 New departments do not need to have any employees.
Determine the following:
A. The Relationship Type
B. The Cardinality Ratio
C. The Participation Constraints
Also represent cardinality and participation in an ERD
Answer—

Employee Works for Department

e1 r1
d1
e2 r2
d2
e3 r3
d3
e4 r4

A. Binary as two entity types are participating in the relationship.

B. 1: N
C. Full participation of entity type Employee and partial participation of entity
type Department.
 Employee N 1
Works for Department

Fig: Cardinality ration single Line / double line representation of ERD

Employee Department
Works for

1, 1 0, N

Fig: Cardinality ration (min, max) representation of ERD

Now, we are in a position to design the final ER diagram for the given requirements.
 ER Model to Relational Model
Relation, Attributes and Tuples in Relational Database Model
Relation— The relational model represents the database as a collection of
relations. A relation is informally known as a table of values.
Attributes— An attribute is a column in a table (relation), representing a specific
property or characteristic of the data. Each attribute has a name.
Tuples— A tuple is a single row in a table (relation), representing a single record in
the database. Unlike an attribute, it does not have a name but consists of a set of
values corresponding to the attributes.

Age DOB SSN Salary

Name

Employee

Relation (table) Name Attributes

Tuples Employee
Name Age DOB SSN Salary

Raj 20 2004 1295 1,00,000

Sahil 30 1994 2751 20,00,000
Meharban 40 1984 3565 50,000
Ravi 20 2004 4725 20,000
 Domain, Relation Schema and Relation State in Relational Database Model

Domain— A domain is the data type that defines the type of values that can appear
in each column of a table. It specifies the permissible values for an attribute,
including constraints such as data type, format, and range. For every attribute, its
domain must be declared to ensure that the values stored in that attribute adhere
to the defined constraints. For example, for the name attribute, it is character
string.
Relation Schema— A relation schema R, denoted by R (A1, a2, ..., A n), is made up
of a relation name R and a list of attributes. The degree of a relation is the number
of attributes. For example, if we consider the above Employee relation then
relation schema will be:
Employee (Name, Age, DOB, SSN, Salary)

OR
Employee
Name Age DOB SSN Salary

Note— Database Schema: The logical structure and constraints of the entire
database, including multiple relations (tables) and their relationships.
Relation Schema: The logical structure and constraints of a single relation (table)
within the database.
Relation State (Relation Instance)— This refers to the actual data present in a
relation (or table) at a specific point in time. It consists of all the tuples (rows) that
are currently stored in the table.
Now, we are in a position to design a relational database schema from a given ER
diagram.

To understand it better, we are going to consider only the entity type 'Employee',
the relationship type 'works for', and the entity type 'Department' for converting
into a database schema. By doing it, we will also come to know how we can
translate many-to-one relationship into database schema.
 An entity type represents a relation (table) in RDBMS.
 Attributes of an entity type are represented as the columns in a relation.
 Every attribute (column) in a table (relation) should be simple attribute
(atomic). It means composite and multivalued attributes are not allowed in
a table.

Employee
F_name M_name L_name DOB SSN Add Salary Sex
 Department
D_name D_number Locations

As it is a multi-valued
attribute, it is not allowed to
become a column name, but
for now, we will consider it as
a simple attribute. Later, we
will learn how we can
convert it into relation
schema.

Now, we need to take care of “works for”, which is a relationship type. We already
know every relation in ERD is an attribute of another entity type; therefore, this
relation (WORKS FOR) is again converted into an attribute of the entity type
“Employee”.
Note— In a many-to-one (M:1) relationship, the relationship is effectively
represented in the entity that is on the "many" side of the relationship.
Employee

F_name M_name L_name DOB SSN Add Salary Sex D_num

Department
D_name D_num Locations
Whenever the values of a key attribute (D_num from the Department table) are
represented into another table (D_num in Employee table), it means there exists a
relationship between these two tables, which is represented by an arrow from
referencing attribute to referenced attribute.

Now, we have designed a schema diagram for a small part of the original ER
diagram. Therefore, before converting the entire ERD into a database schema, we
will first see how we implement this small schema diagram using SQL, without
establishing the relation between the two tables.

CREATE TABLE Command in SQL

 Each relation schema is converted into a table.

Create Table tablename (columnname datatype(size) otherattributes,

columnname datatype(size) otherattributes, columnname datatype(size)
otherattributes);
Creating Empty Employee Table:
Create Table Employee (F_name varchar (20) NOT NULL, M_name varchar (10),
L_name varchar (15) NOT NULL, DOB date, SSN varchar (10) NOT NULL, Address
varchar (30), Sex varchar (1), Salary float, D_num int NOT NULL, PRIMARY KEY
(SSN));

Creating Empty Department Table:

CREATE TABLE Department( D_name varchar(20) NOT NULL, D_num int NOT NULL
PRIMARY KEY, Locations varchar(20) NOT NULL);
Now, we will insert values into empty tables (Employee and Department)
 INSERT INTO Command in SQL

INSERT INTO Employee(F_name, M_name, L_name, DOB, SSN, Address, Sex, Salary,
D_num) VALUES('MD', 'S', 'KHAN', TO_DATE('12-Nov-1989', 'DD-Mon-YYYY'),
'1234', 'MIET', 'M', 10000, 1);
One row is inserted into Employee table.

INSERT INTO Department(D_name, D_num, Locations) VALUES('CSE', 1, 'Meerut');

One row is inserted into Department table.

One-to-One Relationships in ER Diagram to Database Schema

From the ERD, we will consider “Manages” relationship, which is 1 : 1, between

Employee and Department.

Note— When translating a one-to-one (1:1) relationship into tables, the

relationship type can be merged with either of the entity types involved, and
attributes of the relationship are shifted to the entity having full participation.
Employee
F_name M_name L_name DOB SSN Add Salary Sex D_num

Department
D_name D_num Locations Mgr_SSN Mgr_start_date

One-to-Many Relationships to Database Schema

From the ERD, we will consider “Controls” relationship, which is 1: M, between
Department and Project.
Note— In a ONE-to-MANY (1:M) relationship in an Entity-Relationship (ER)
diagram, the relationship type is effectively represented in the entity that is on the
"many" side of the relationship.
Department
D_name D_num Locations Mgr_SSN Mgr_start_date

Project
P_name P_num P_Location D_num

Note— For many-to-many relationship, kindly refer GATE problems given later
in this PDF.
 Multivalued Attributes to Database Schema
When translating multivalued attributes from an Entity-Relationship (ER) diagram
into a relational database schema, the multivalued attribute is represented by
creating a separate table. This new table will store the values of the multivalued
attribute, with a foreign key linking back to the original entity.

We will consider the Department entity to illustrate this concept as it has a multi-
valued attribute named locations.

D_name D_num Locations Mgr_SSN Mgr_start_date

It will be removed from the Department table to

form a new table containing the primary key of this table and this multi-valued
attribute.

D_name D_num Locations Mgr_ Mgr_start_date

SSN
A 1 Delhi, Pune 20 Jan-01
B 2 Meerut, Noida 18 Feb-02
C 3 Hyderabad, Delhi 16 Dec-20
D 4 Kolkata, Mumbai 14 Jul-22
Dept_Location
D_num D_Location
1 Delhi
1 Pune
2 Meerut
2 Noida
3 Hyderabad
3 Delhi
4 Kolkata
4 Mumbai

Department
D_name D_num Mgr_SSN Mgr_start_date

Dept_Location
D_name D_num

Conclusion: Translating different cardinality ratios from an Entity-Relationship

(ER) diagram into relational tables involves creating appropriate tables and foreign
keys based on the nature of the relationships between the entities.
Q. A database is being constructed to keep track of the teams and games in a
sports league. Each team has a number of players, though not all of them
participate in every game. The database aims to track the players participating in
each game for each team, the positions they played, and the game's result. Design
an ER schema diagram for this application, stating any assumptions you make.

Note— This question is taken from Navathe’s book, Chapter Three, and has also
been asked in the AKTU exam.

Answer—
Step-01: Identify Entity Types
Based on the requirements provided, the following entity types can be identified
for the ER schema diagram:
A. Team
B. Game
C. Player
Step-02: Identify Relationship Types
Relationships connect entities and represent how these entities interact with each
other. In this case, we have three relationships: Team to Player ('has'), Team to
Game ('plays') and Player to Game ('participates in').

Team Game
Plays

Participates in
Has

Player
 Cardinality Constraint

Cardinality Constraint or Ratio— The maximum number of relationship instances

that an entity can participate in, and it is determined by examining the constraints
mentioned in the requirements.

The 'has' and 'plays' relationships are one-to-many relationships, as a team has
many players and plays many games but each player and game belong to one team.
The 'participates in' relationship is many-to-many, as many players can participate
in many games.

Team M 1 Game
Plays

M M

Has 1 M Participates in

Player
Step-03: Identify Attributes for each Entity Type
A. Entity Type “Team”
Attributes: TeamID and TeamName

TeamID TeamName

Team

B. Entity Type “Player”

Attributes: PlayerID, PlayerName
C. Entity Type “Game”
Attributes: GameID, GameDate, Result

Step-03: If we draw all the entities (Team, Player, Game), their relationships ('has',
'participates in', 'plays') and attributes together, it will lead to the formation of the
complete ER diagram.
 Q. Consider the following ER diagram and find out the minimum number of tables
needed to represent this ERD in the relational database.

M P R2
R2 NN
R1

M3 P1 P2
M1 N1 N2
M2

Note— For Cardinality ratio is 1 and cardinality ratio is M.

Answer—
Note— If no specific attributes are mentioned for a relationship type in an ER (Entity-
Relationship) diagram, the key attributes from both participating entity types are
typically considered to be the attributes for the relationship type.
Note— In a many-to-one (M:1) relationship in an Entity-Relationship (ER) diagram, the
relationship is effectively represented in the entity that is on the "many" side of
the relationship.

MR1 with attributes: M1, M2, M3, P1

NR2 with attributes: N1, N2, P1 and C.K =N1P1
P with attributes: P1, P2

3 tables are required.

Q. Consider an ER diagram with two entities, E1 and E2, both having simple single-
valued attributes. There are two relationships, R1 and R2, between these entities.
R1 is a one-to-many relationship from E1 to E2, and R2 is a many-to-many
relationship between E1 and E2. Neither R1 nor R2 have any attributes. What is the
minimum number of tables required to represent this scenario in the relational
model?
Answer—
R1

E2
E1

R2

R1E2
E1
R2
There are minimum three tables required.

Note— When we have a many-to-many relationship in an Entity-Relationship (ER)

diagram, the relationship is not merged into either of the entities involved. Instead,
a separate table (often called a junction or associative table) is created to
represent the relationship.
 Keys
A key is a set of one or more attributes that uniquely identifies a tuple (row) in a
relation (table). Each tuple in the relation must have a unique value for the
attributes that constitute the key, ensuring no two tuples have the same values for
these attributes. A key can consist of a single attribute or a combination of multiple
attributes.
Types of Keys in the Relational Model:
1. Super Key
2. Candidate Key
3. Primary Key
4. Foreign Key
5. Composite Key
6. Alternate Key

Super Key
A super key is a set of one or more attributes that, taken collectively, can uniquely
identify a tuple (row) in a relation (table). This means that no two distinct tuples in
the relation can have the same values for the attributes in the super key.
Characteristics of a Super Key:
 Uniqueness: A super key ensures that each tuple in the table is uniquely
identified by the combination of attributes.
 Superset of Keys: Super keys are a superset of other keys (primary key,
candidate key and unique key) in a relational database.
 NULL Values: A super key does not have a strict requirement that all its
attributes must be non-null. As long as the combination of values in the super
key uniquely identifies each tuple, NULL values can be present in some
attributes.
 Extraneous Attributes: Super keys may contain extraneous attributes that
are not necessary for uniqueness. These attributes can be removed to form
a candidate key, which is a minimal super key.
 Let’s try to under super keys with a suitable example.

Employee
Name Age DOB SSN Salary
Rahul 30 1990 660911228333 20,000
Rawat 30 1992 650911228333 40,000
Rahul 40 1990 640911228333 20,000

Identify the Key Attributes—

Examine Uniqueness:
Name: Not unique (e.g., there are distinct employees with the same names).
Age: Not unique (multiple employees have the same age).
DOB: Not unique (multiple employees have the same date of birth).
Salary: Not unique (multiple employees have the same salary).
SSN: Unique (each employee has a different SSN).

Determine Key Attributes:

SSN is unique for each employee and can be used to identify each row uniquely.

Conclusion:
Key Attribute: SSN is the key attribute because it uniquely identifies each
employee.
Not Key Attributes: Name, Age, DOB, and Salary cannot be used alone as keys since
they are not unique.
Since SSN is a unique identifier and minimal as well, any combination of attributes
that includes SSN will be a super key. Let’s identify all possible super keys:
 List of all Possible Super Keys
Single Attribute Super Key:
1. {SSN}: As SSN is unique, it alone can uniquely identify each row.
Combination of SSN with Other Attributes:
2. {SSN, Name}
3. {SSN, Age}
4. {SSN, DOB}
5. {SSN, Salary}
6. {SSN, Name, Age}
7. {SSN, Name, DOB}
8. {SSN, Name, Salary}
9. {SSN, Age, DOB}
10. {SSN, Age, Salary}
11. {SSN, DOB, Salary}
12. {SSN, Name, Age, DOB}
13. {SSN, Name, Age, Salary}
14. {SSN, Name, DOB, Salary}
15. {SSN, Age, DOB, Salary}
16. {SSN, Name, Age, DOB, Salary}

Candidate Keys

It is a minimal super key. This means it is a super key with no unnecessary

attributes. Each candidate key is a super key, but not all super keys are
candidate keys.

 Minimality: For a super key to be a candidate key, it must be minimal. This

means that if we remove any attribute from it, it should no longer be a super
key (i.e., it should not uniquely identify tuples in the relation any longer).

 A candidate key is a super key with no proper subset that can also be a key.
 Employee
id name salary SSN email mob.
123 Rahul 10,000 4321 [email protected] 9910669313
321 Vivek 20,000 5432 [email protected] 9910669313
432 Rahul 10,000 3456 [email protected] 1910669310

All Possible Minimal Super Keys (Candidate Keys):

{SSN}: unique for each row.
{id}: unique for each row.
{email}: unique for each row
{name, mob}: unique for each row
{salary, mob} unique for each row

Note— The values of the attribute 'name' alone are not unique, but when
combined with 'mob', they are unique.

Let’s check a few other combinations:

{SSN, id}: Proper subsets {SSN} and {id} are already keys, so it cannot be a
candidate key.
{salary, email}: Proper subset {email} is already a key, so it cannot be a
candidate key.
{salary}: The values of the attribute 'salary' are not unique, so it cannot be a
candidate key.

Primary Key
A primary key is a candidate key chosen to uniquely identify each tuple (row) in a
table. It ensures that each record within the table is unique and non-null. A primary
key must have unique values and cannot contain NULL values for any tuple. Each
table can have only one primary key, which may consist of one or multiple
attributes (a composite key).
 id name salary SSN email mob.
123 Rahul 10,000 4321 [email protected] 9910669313
321 Vivek 20,000 5432 [email protected] 9910669313
432 Rahul 10,000 3456 [email protected] 9910669310

Primary key: One among {id}, {SSN}, {email} and {name, mob}

Composite Key
A composite key is a combination of two or more attributes that together uniquely
identify a tuple (row) in a relation (table). None of the individual attributes can
uniquely identify the tuple on their own, but when combined, they ensure
uniqueness. Composite keys are used when a single attribute is not sufficient to
ensure the uniqueness of a record. For example, the key {name, mob} in the
Employee table is a composite key and can be used a primary key.

Alternate Keys

An alternate key is a candidate key that was not chosen as the primary key for a
table. It can uniquely identify tuples in the table, similar to the primary key.
However, it is not used as the primary key. A table may have multiple alternate
keys, each of which can potentially serve as a unique identifier for the records.

Employee
id name salary SSN email mob.
123 Rahul 10,000 4321 [email protected] 9910669313
321 Vivek 20,000 5432 [email protected] 9910669313
432 Rahul 10,000 3456 [email protected] 9910669310

Primary Key: {id}

Alternate keys: {SSN}, {email} and {name, mob}
 Foreign Keys

A foreign key is an attribute (or set of attributes) in one table that establishes a link
to the primary key of another table. It is used to enforce referential integrity by
ensuring that the values in the foreign key column(s) correspond to valid values in
the primary key column(s) of the referenced table. Foreign keys can contain
duplicate values and NULLs. A table can contain multiple foreign keys, each
referencing a primary key in a different table or even in the same table (self-
referencing).
Foreign Key
Primary key Primary key
Employee Department
Name Gender SSN Salary D_num D_name D_number Location

Rahul M 123 10000 10 CSE 10 Meerut

Raj M 321 20000 2 IoT 2 Noida

Alice F 312 30000 2

 Relational Model Constraints
Relational model constraints are restrictions on the values and structure within a
database to ensure data integrity and consistency.
Types of Constraints:
1. Domain constraint
2. Key constraint
3. Entity integrity constraint
4. Referential integrity constraint

1. Domain Constraint— It specifies that the value of each attribute within a

tuple must be an atomic value from a predefined domain (data type of the
attribute). For example, in the Employee table, the type of F_name is
VARCHAR2(20), so we cannot insert more than one name or a name
containing more than 20 characters.

2. Key Constraint— It specifies that every tuple in a table must be uniquely

identified by a key. This key can be a single attribute or a combination of
attributes that ensure the uniqueness of each tuple in the table. For example,
in the Employee table, the SSN (Social Security Number) attribute can be
designated as the primary key because it uniquely identifies each employee.
Thus, no two employees can have the same SSN.

3. Entity Integrity constraint— It is specifically focused on the primary key to

guarantee that each row in a table is a unique and valid entity.

4. Referential Integrity Constraint— This constraint is specified between two

relations (tables) to maintain consistency among the tuples in the two
relations. It ensures that a foreign key in one table corresponds to a primary
key in another table, thereby maintaining the logical relationship between
the tables.
 Foreign Key
Primary key Primary key
Employee Department
Name Gender SSN Salary D_num D_name D_number Locations

Rahul M 123 10000 10 CSE 10 Meerut

Raj M 321 20000 2 IoT 2 Noida

Alice F 312 30000 2

maintain consistency among the tuples in the two relations, how?

If we attempt to insert a new row into the Employee table, for example, (Sahil, M,
111, 40000, 3), we cannot do so if D_num 3 does not exist in the Department table.
This is because the referential integrity constraint ensures that the D_num in the
Employee table must correspond to a valid D_number in the Department table.
Therefore, a row with a D_num that does not have a corresponding department in
the Department table cannot be inserted.
 Implementation of Referential Integrity Constraint Using Foreign keys

Employee

F_name M_name L_name DOB SSN Add Salary Sex D_num

Department
D_name D_num Locations

Creating Empty Table Department:

Create Table Department (D_name varchar (20), D_number int NOT NULL PRIMARY
KEY, Locations varchar (20));
Inserting values into Department Table:
INSERT INTO Department (D_name, D_num, Locations)VALUES ('CSE',10, 'Meerut');
INSERT INTO Department (D_name, D_num, Locations) VALUES ('IoT', 2, 'Noida');
Two rows have been inserted into the Dept. D_name D_number Locations
table.
CSE 10 Meerut
IoT 2 Noida

Create Table Employee (F_name varchar (20) NOT NULL, M_name varchar (10),
L_name varchar (15) NOT NULL, DOB date, SSN varchar (10) NOT NULL, Address
varchar (30), Sex varchar (1), Salary float, D_num int NOT NULL, PRIMARY KEY (SSN),
FOREIGN KEY(D_num) REFRENCES Department(D_num));
 Actions upon Constraints Violation

When a constraint is violated, different actions or responses are triggered

depending on the type of constraint and how it's defined.

1. Domain Constraints:
Actions upon Violation:
Error Message: The database system raises an error indicating that the value does
not conform to the domain constraints.

Operation Rejected: The operation (e.g., INSERT or UPDATE) is rejected until the
value is corrected to meet the domain constraints.

2. Key Constraint Violation

Primary Key Violation:
Action:
Reject the Operation: If a duplicate value is inserted into a primary key column, or
if a NULL value is attempted, the DBMS will reject the operation and return an
error.
Unique Key Violation:
Action:
Reject the Operation: If a duplicate value is inserted into a unique key column, the
DBMS will reject the operation and issue an error.

3. Entity Integrity Constraint Violation

Action:
Reject the Operation: If an operation attempts to insert a NULL value into a primary
key column or violates the uniqueness of the primary key, the DBMS will reject the
operation and return an error.
4. Referential Integrity Constraint Violation
Actions:
Reject the Operation: If an attempt is made to insert a row that violates the
referential integrity constraint (e.g., inserting a foreign key that does not exist in
the referenced table), the DBMS will reject the operation.

Cascade: This action automatically propagates the change (delete or update) to

the referenced rows in the child table.

 ON DELETE CASCADE: If the parent record is deleted, all related child records
are also deleted.
 ON UPDATE CASCADE: If the parent record’s primary key is updated, all
related foreign keys in the child table are also updated.

Set Null: This action sets the foreign key in the child table to NULL if the
corresponding parent record is deleted or updated.
 ON DELETE SET NULL: If the parent record is deleted, the foreign key in the
child table is set to NULL.
 ON UPDATE SET NULL: If the parent record’s primary key is updated, the
foreign key in the child table is set to NULL.

Set Default: This action sets the foreign key to a default value if the
corresponding parent record is deleted or updated.
 ON DELETE SET DEFAULT: Sets the foreign key in the child table to a default
value if the parent is deleted.
 ON UPDATE SET DEFAULT: Sets the foreign key to a default value if the
parent record is updated.

Note— You will learn about the three actions associated with referential integrity
upon violation in the DBMS lab.
Q. The following table has two attributes A and C where A is the primary key and
C is the foreign key referencing A with on-delete cascade.

A C
-----
2 4
3 4
4 3
5 2
7 2
9 5
6 4
The set of all tuples that must be additionally deleted to preserve referential
integrity when the tuple (2,4) is deleted is?

Answer— (5,2), (7,2) and (9,5)

 Counting the Number of Super Keys

Q1. Given a relation R (A1, A2, ..., An) with {A1} as the candidate key, determine the
number of super keys.

Answer— We know that the superset of a candidate key is also a super key. This
means that any set of attributes that contains a candidate key (or is equal to the
candidate key) can uniquely identify tuples in a relation, making it a super key.

Let’s solve this question with three attributes to understand it.

R (A1, A2, A3) with {A1} as the candidate key.

Possible super keys are:
 {A1}
 {A1, A2}
 {A1, A3}
 {A1, A2, A3}

With the three attributes, one being candidate key, we have 22 super keys. So,
the correct formula to find the number of super keys when there are “n”
attributes and one candidate key is 2(n-1).

Q2. Given a relation R (A1, A2, ..., An) with {A1A2A3} as the candidate key,
determine the number of super keys.

Answer— 2(n-3) It is a single C.K with three attributes

 Q3. Given a relation R (A1, A2, ..., An) with {A1} and {A2} as the candidate keys,
determine the number of super keys.

Answer—

Number of super keys possible because of A1 + Number of super keys possible

because of A2 - Number of super keys possible because of A 1A2

(n-1)
2 + 2(n-1) - 2(n-2)

Q4. Given a relation R (A1, A2, ..., An) with {A1, A2} and {A3, A4} as the candidate
keys, determine the number of super keys.
Answer— 2(n-2) + 2(n-2) - 2(n-4)

Q5. Given a relation R (A1, A2, ..., An) with {A1, A2} and {A1, A3} as the candidate
keys, determine the number of super keys.
Answer— 2(n-2) + 2(n-2) - 2(n-3)

Q6. Given a relation R (A1, A2, ..., An) with {A1}, {A2} and {A3} as the candidate
keys, determine the number of super keys.
Answer— [ Use this ∣A∪B∪C∣=∣A∣+∣B∣+∣C∣−∣A∩B∣−∣B∩C∣−∣C∩A∣+∣A∩B∩C∣]

2(n-1) + 2(n-1) + 2(n-1) - 2(n-2) - 2(n-2) - 2(n-2) + 2(n-3)

Q7. Given a relation R (A, B, C, D) with {A} and {B, C} as the candidate keys,
determine the number of super keys.
Answer— 2(n-1) + 2(n-2) - 2(n-3) = 23 + 22 - 21 =10

1. {A} 6. {A, B, D}
2. {A, B} 7. {A, C, D}
3. {A, C} 8. {A, B, C, D}
4. {A, D} 9. {B, C}
5. {A, B, C} 10. {B, C, D}

Extended Entity-Relationship (EER) Model

The Extended Entity-Relationship (EER) Model is an enhancement of the traditional

ER (Entity-Relationship) Model used in database design. It introduces advanced
modeling concepts to address more complex data requirements, such as the need
for hierarchies, inheritance, and handling of relationships between entities at
multiple levels. The EER model is an extension designed to better capture real-
world scenarios and relationships that the basic ER model cannot fully represent.
Generalization: A process of abstracting common characteristics from multiple
entities and creating a generalized or higher-level entity.
Aggregation: It treats relationships as higher-level entities. It allows modeling of
relationships between relationships and entities.