Module 2
Module 2
Super Key
• A set of attributes that uniquely identifies a tuple.
Example:
{USN}, {USN, Name}
Candidate Key
• A minimal super key.
Example:
USN
Primary Key
• One candidate key chosen to identify tuples uniquely.
• Cannot contain duplicate or NULL values.
Example:
Student(USN, Name, Age)
Example:
Name VARCHAR(30) NOT NULL
3. Application-Based (Semantic)
Constraints
• Business rules that cannot be specified directly in the schema.
• Implemented using application programs, Triggers, or Assertions.
Examples:
• Employee salary should not exceed manager's salary.
• Maximum working hours per week should not exceed 56.
Example:
USN → Student_Name
Summary
Constraint Purpose Example
Inherent Constraint Built into relational model No duplicate tuples
Domain Constraint Valid values Age = Integer
Key Constraint Unique tuples USN
NULL Constraint Restricts NULL values Name NOT NULL
Entity Integrity Primary Key cannot be NULL USN
Foreign Key must reference a valid Primary
Referential Integrity DeptID
Key
Semantic Constraint Business rules Salary ≤ Manager's Salary
Functional Dependency Attribute dependency USN → Name
State Constraint Valid database state Salary > 0
Transition Constraint Valid state changes Controlled salary updates
Conclusion
Relational model constraints ensure data accuracy, consistency, and integrity by
enforcing rules such as domain constraints, key constraints, entity integrity,
referential integrity, and business rules, thereby maintaining a reliable database.
Example
STUDENT
USN (PK) Name Age
1TJ21IS001 Alice 20
❌
1TJ21IS002 Bob 21
NULL Carol 22
The third record violates Entity Integrity because the Primary Key (USN) is
NULL.
Importance
• Uniquely identifies every record.
• Prevents duplicate or unidentified tuples.
• Maintains data integrity.
• Allows other tables to reference records correctly.
• Be NULL.
✔
EmpID Name DeptID (FK)
✔
101 Alice 10
❌
102 Bob 20
103 Carol 40
The third record violates Referential Integrity because DeptID = 40 does not exist
in the DEPARTMENT table.
Importance
• Maintains consistency between related tables.
• Prevents invalid foreign key values.
• Avoids orphan records.
• Ensures every foreign key references a valid primary key.
Conclusion
• Entity Integrity ensures that every record has a valid, non-NULL Primary
Key, so each tuple can be uniquely identified.
• Referential Integrity ensures that every Foreign Key correctly references an
existing Primary Key, maintaining consistency between related tables. Both
constraints are essential for maintaining a reliable and error-free database.
1. Insert Operation
Definition
The INSERT operation adds one or more new tuples (rows) into a relation.
Constraint Violations
a) Domain Constraint
• Occurs when a value is outside its domain or has an invalid data type.
❌
Example:
Age = 'ABC'
b) Key Constraint
• Occurs when the primary key value already exists.
Example:
USN (PK) Name
❌
101 Alice
101 Bob
Duplicate primary key is not allowed.
❌
USN (PK) Name
NULL Alice
DeptID
10
20
Employee
❌
EmpID DeptID
101 30
DeptID 30 does not exist.
Handling
• Reject the insertion (default action).
• Display an appropriate error message.
• Correct the invalid values before inserting.
2. Delete Operation
Definition
The DELETE operation removes tuples from a relation.
Constraint Violation
Deletion may violate Referential Integrity if other tables reference the deleted tuple.
Example
Department
DeptID
10
Employee
EmpID DeptID
101 10
Deleting DeptID = 10 causes a referential integrity violation because Employee refers to it.
Handling Methods
1. Restrict
• Reject the delete operation.
2. Cascade
• Delete all related tuples automatically.
3. Set NULL / Set DEFAULT
• Change foreign key values to NULL or a default value.
Possible Violations
a) Domain Constraint
• Invalid data type or value.
❌
Example:
Salary = 'ABC'
b) Key Constraint
• Duplicate primary key.
Example:
Changing USN 102 → 101 when 101 already exists.
Handling
• Reject the update.
• Cascade the update to related tables (if allowed).
• Set foreign key to NULL or DEFAULT.
Summary Table
Operation Possible Constraint Violations Handling
Domain, Key, Entity Integrity, Referential
Insert Reject, correct values
Integrity
Restrict, Cascade, Set NULL, Set
Delete Referential Integrity
DEFAULT
Reject, Cascade, Set NULL, Set
Update Domain, Key, Referential Integrity
DEFAULT
Conclusion
The three update operations—Insert, Delete, and Update—modify the database state. During these
operations, the DBMS enforces Domain, Key, Entity Integrity, and Referential Integrity
constraints. If a violation occurs, it is handled using methods such as Reject (Restrict), Cascade,
Set NULL, or Set DEFAULT, ensuring that the database remains accurate, consistent, and
reliable.
Example
USN Name
101 Alice
102 Bob
or
USN Name
102 Bob
101 Alice
Both tables represent the same relation.
Example
USN Name Age
is equivalent to
USN Phone
101 9876543210
Incorrect:
❌
USN Phone
101 9876543210, 8765432109
NULL Values
• NULL represents:
• Unknown value
• Value not available
• Value not applicable
Example
Example
STUDENT(USN, Name, Age)
Summary Table
Property Description Example
Ordering of Tuples Row order does not matter Rows can be rearranged
Ordering of Attributes Column order does not matter USN, Name = Name, USN
Atomic & NULL Values Each cell has one value; NULL allowed Phone = NULL
Interpretation of Relation Each tuple represents one real-world entity Student record
Conclusion
The main characteristics of a relation are:
1. No ordering of tuples
2. No ordering of attributes
3. Atomic values with NULL allowed
4. Each tuple represents a real-world fact or entity
These properties ensure that relations remain consistent, flexible, and easy to manage in a
relational database.
This question is almost the same as "Explain the characteristics (properties) of relations."
However, if VTU asks "Discuss the characteristics of relations that make them different from
ordinary tables and files", you should emphasize the differences.
1. No Ordering of Tuples
• A relation is defined as a set of tuples.
• Since a set has no order, tuples in a relation do not have any particular order.
• Tuple ordering is not part of the relation definition, whereas records in ordinary files may
have a fixed order.
Example: Rearranging employee records does not change the relation.
2. No Ordering of Attributes
• The order of attributes and their values is not important as long as the correspondence
between attributes and values is maintained.
• A tuple can be considered as a set of (Attribute, Value) pairs.
• In ordinary tables, column positions are often significant.
Example: STUDENT(USN, Name, Age) and STUDENT(Age, Name, USN) represent the same
relation.
4. No Duplicate Tuples
• A relation cannot contain duplicate tuples.
• Every tuple must be unique.
• Ordinary tables or files may contain duplicate records.
Example:
USN Name
❌
101 Alice
101 Alice
Duplicate tuples are not allowed in a relation.
Yes. Based on your reference notes, here is a VTU-style answer that keeps the textbook wording,
converts paragraphs into points, and includes examples.
General Form
σ<selection condition>(R)
Where:
• σ → Select operator
• R → Relation
• Selection condition → Boolean expression
Selection Condition
A condition may be of the form:
Attribute Comparison_Operator Constant
or
Attribute Comparison_Operator Attribute
Examples
1. Select employees working in Department 4
σDno = 4 (EMPLOYEE)
Properties of SELECT
• It is a Unary Operation (operates on one relation).
• Degree (number of attributes) remains unchanged.
• Number of tuples is less than or equal to the original relation.
• It is commutative, i.e., multiple SELECT operations can be applied in any order.
SQL Equivalent
Relational Algebra
σDno=4 AND Salary>25000 (EMPLOYEE)
SQL
SELECT *
FROM EMPLOYEE
WHERE Dno=4 AND Salary>25000;
General Form
π<attribute list>(R)
Where:
• π → Project operator
• Attribute List → Required columns
• R → Relation
Example
Display only Last Name, First Name and Salary.
πLname, Fname, Salary (EMPLOYEE)
Duplicate Elimination
• If only non-key attributes are projected, duplicate tuples may occur.
• PROJECT automatically removes duplicate tuples because the result must be a valid
relation.
Example
πGender, Salary (EMPLOYEE)
If two employees have the same Gender and Salary, only one tuple appears in the result.
Properties of PROJECT
• It is a Unary Operation.
• It reduces the degree (number of attributes).
• Number of tuples is less than or equal to the original relation.
• Duplicate tuples are eliminated automatically.
• PROJECT is not commutative.
SQL Equivalent
Relational Algebra
πGender, Salary (EMPLOYEE)
SQL
SELECT DISTINCT Gender, Salary
FROM EMPLOYEE;
Conclusion
• SELECT (σ) retrieves required rows based on a condition (horizontal partition).
• PROJECT (π) retrieves required columns and removes duplicate tuples (vertical
partition).
• Both are unary relational algebra operations and form the foundation of query processing
in relational databases.
RENAME (ρ) Operation
Definition
• The RENAME (ρ) operation is used to rename a relation or its attributes.
• It is useful when the same relation is used more than once in a query or when meaningful
names are required.
General Form
Rename a relation:
ρNewRelation(R)
Rename attributes:
ρNewRelation(A1, A2, ..., An)(R)
Example
Rename relation EMPLOYEE as EMP.
ρEMP(EMPLOYEE)
Rename attributes:
ρEMP(Eid, Ename, Salary)(EMPLOYEE)
Properties
• Unary operation.
• Changes only the name of the relation or attributes.
• Does not change the data.
• Useful in complex relational algebra expressions.
For VTU 10 Marks, keep the important textbook points and add examples.
1. Equijoin
Definition
• The most common use of JOIN involves equality comparisons (=) only.
• Such a JOIN is called an EQUIJOIN.
• In the result of an EQUIJOIN, the join attributes from both relations are retained, resulting
in duplicate columns having the same values.
General Form
R ⋈R.A=S.B S
or
σR.A=S.B(R × S)
Example
EMPLOYEE
Dnumber Dname
10 HR
20 IT
Find employee details along with department details.
Relational Algebra
EMPLOYEE ⋈[Link] = [Link] DEPARTMENT
Result
Ssn Name Dno Dnumber Dname
101 Alice 10 10 HR
102 Bob 20 20 IT
Here, Dno and Dnumber both appear in the result because Equijoin keeps both join attributes.
Characteristics of Equijoin
• Uses only the equality (=) operator.
• Both join attributes are retained.
• Duplicate join columns may appear.
• Combines related tuples from two relations.
2. Natural Join
Definition
• A NATURAL JOIN is an Equijoin in which the join attributes have the same name in both
relations.
• If attribute names are different, a RENAME (ρ) operation is applied first.
• Duplicate join attributes are eliminated from the result.
General Form
R ⋈ S
Example
Suppose both relations have the attribute Dnumber.
EMPLOYEE
Dnumber Dname
10 HR
20 IT
Relational Algebra
EMPLOYEE ⋈ DEPARTMENT
Result
Ssn Name Dnumber Dname
101 Alice 10 HR
Ssn Name Dnumber Dname
102 Bob 20 IT
Here, only one Dnumber column appears because Natural Join removes duplicate join attributes.
Conclusion
• Equijoin combines tuples using the equality operator (=) and retains both join attributes in
the result.
• Natural Join is a special type of Equijoin that joins attributes with the same name and
automatically removes duplicate join columns, producing a cleaner relation.
Yes! For VTU, remembering the story is much easier than memorizing definitions. Here's a simple
10-mark answer.
Discuss Equijoin and Natural Join with
Suitable Examples
JOIN
Story
• JOIN means merging two tables to get related information.
• It combines rows from two tables based on a common attribute.
1. Equijoin
Simple Story
• Equijoin means merging two tables using the equality (=) operator.
• The joining attributes may have different names or the same names.
• Both joining columns are kept in the result, so duplicate columns appear.
Syntax
R ⋈R.A = S.B S
or
σR.A=S.B(R × S)
Example
EMPLOYEE
Dnumber Dname
10 HR
20 IT
Join Condition
[Link] = [Link]
Relational Algebra
EMPLOYEE ⋈[Link]=[Link] DEPARTMENT
Result
EmpID Name Dno Dnumber Dname
101 Alice 10 10 HR
👉
102 Bob 20 20 IT
Notice:
• Dno and Dnumber are both shown.
• Duplicate join columns are not removed.
Key Points
• Uses = operator.
• Joins two tables.
• Join attribute names may be different.
• Duplicate join columns remain.
2. Natural Join
Simple Story
• Natural Join means merging two tables automatically using attributes having the same
name.
• Duplicate join columns are removed.
• If attribute names are different, first use RENAME (ρ).
Syntax
R ⋈ S
Example
EMPLOYEE
Dnumber Dname
10 HR
20 IT
Relational Algebra
EMPLOYEE ⋈ DEPARTMENT
Result
EmpID Name Dnumber Dname
101 Alice 10 HR
👉
102 Bob 20 IT
Notice:
• Only one Dnumber column appears.
• Duplicate column is removed automatically.
Key Points
• Uses attributes with the same name.
• Removes duplicate join columns.
• Cleaner result than Equijoin.
• If names differ → use RENAME first.
➡️
Dno = Dnumber
Result contains both Dno and Dnumber.
Natural Join
"Same name, Same column, Duplicate removed."
Example:
➡️
Dnumber
Result contains only one Dnumber.
This "story + syntax + example + key points + difference" format is ideal for a VTU 10-mark
answer and is much easier to remember during exams.
For VTU 10 Marks, here's an easy story + points + syntax + example answer.
Examples
Find the total salary of all employees.
ℱSUM Salary (EMPLOYEE)
Grouping
Simple Story
• Grouping means dividing tuples into groups based on the value of an attribute.
• After grouping, an aggregate function is applied separately to each group.
Example:
Group employees by Department Number (Dno) and calculate the average salary of each
department.
General Syntax
ℱ<grouping attributes>
<function list>(R)
Where:
• Grouping attributes → Attributes used to form groups.
• Function list → Aggregate functions like SUM, AVG, MAX, MIN, COUNT.
• R → Relation.
Example
Retrieve:
• Department Number
• Number of Employees
• Average Salary
Relational Algebra
ℱDno
COUNT(Ssn), AVERAGE(Salary)(EMPLOYEE)
Result
Dno No_of_Employees Average_Salary
1 5 35000
2 3 42000
3 4 39000
Key Points
• Aggregation functions summarize data.
• Grouping divides tuples into groups based on an attribute.
• Aggregate functions are applied independently to each group.
• Common functions are SUM, AVG, MAX, MIN, and COUNT.
Applications
• Finding department-wise average salary.
• Counting employees in each department.
• Finding the highest or lowest salary.
• Generating summary reports.
Conclusion
Aggregation functions summarize data using SUM, AVG, MAX, MIN, and COUNT, while
grouping divides tuples based on an attribute and applies these functions separately to each
group. They are widely used for statistical analysis and report generation in relational databases.
For VTU 10 Marks, this is the easiest way to remember. The answer is simply the ER-to-
Relational Mapping Algorithm.
Explain the Steps to Convert the Basic ER
Model into a Relational Database Schema
Definition
ER-to-Relational Mapping is the process of converting an Entity-Relationship (ER) model into a
Relational Database Schema (Tables).
Example
ER Entity
EMPLOYEE(EmpID, Name, Salary)
Relation
EMPLOYEE(EmpID, Name, Salary)
PK → EmpID
PK → (EmpID, Dependent_Name)
FK → EmpID references EMPLOYEE
Example
EMPLOYEE(EmpID, Name, DeptID)
Example
Department → Employee
DEPARTMENT(DeptID, Dname)
DeptID → FK
Example
Employee works on Project
WORKS_ON(EmpID, ProjectID, Hours)
PK → (EmpID, ProjectID)
Example
Employee has multiple phone numbers.
EMP_PHONE(EmpID, PhoneNo)
PK → (EmpID, PhoneNo)
Summary Table
ER Component Relational Mapping
Strong Entity Create one relation
Weak Entity Create relation + owner's PK as FK
1:1 Relationship Add FK to one relation
1:N Relationship Add PK of "1" side as FK in "N" side
M:N Relationship Create new relation
Multivalued Attribute Create new relation
N-ary Relationship Create new relation with all PKs
Example
ER Model
EMPLOYEE ── Works For ── DEPARTMENT
\
\ Works On
\
PROJECT
Relational Schema
EMPLOYEE(EmpID, Name, DeptID)
DEPARTMENT(DeptID, Dname)
PROJECT(ProjectID, Pname)
Conclusion
The ER-to-Relational Mapping process converts an ER model into tables by mapping entities,
relationships, weak entities, multivalued attributes, and constraints into relational schemas.
This process forms the foundation for designing relational databases.