Course Code: CS404PC

Unit -2 Part-1
DATABASE MANAGEMENT
SYSTEMS
By B. Lokesh Joel
 Unit-2:
• Introduction to the Relational Model: • Relational Algebra,
• Integrity constraint over relations,
• Tuple relational Calculus,
• enforcing integrity constraints,

• querying relational data, • Domain relational calculus

• logical database design,

• Introduction to views,

• destroying/altering tables and views.

 Introduction to Views
▪ A view is a virtual table whose rows are computed dynamically based on a view
definition.
▪ Views do not store data explicitly but retrieve it dynamically from existing tables.

• The view B-Students selects students who received a grade B in

any course.
• Fields name, sid, and course in the view correspond to sname,
sid (Students table), and cid (Enrolled table).
 Introduction to Views
▪ Behavior of Views:
– A view behaves like a base table in queries.
– When used in a query, the database first evaluates the view definition to create
the virtual table before executing the main query.
• The query execution process:
• The view definition (SQL query that defines the view) is executed to retrieve the
relevant data.
• The result set of the view is treated as a temporary table.
• The main query operates on this temporary result set.
– Views help in data abstraction and security.
 Views, Data Independence, and Security
▪ Data Abstraction and Independence
– Physical Schema: Defines how data is stored (file structures, indexes).

– Conceptual Schema: Represents the logical structure of data in the database.

– External Schema: Provides user-specific views without exposing the underlying database structure.

– Logical Data Independence:

• Views help shield applications from schema changes.
• Example: If a table’s schema changes, a view with the old schema can be used to maintain compatibility for applications.

▪ Security and Access Control

– Views allow restricted access to data.

– Example:
• A view can show student names and ages but hide GPA.
• Users can access the view without permission to the underlying table.
 Updates on Views
▪ Purpose of Views in Querying
– Views allow users to access data without worrying about underlying table complexities.
– Queries on views function like queries on regular tables.
– However, users may also want to update views, leading to challenges.

▪ Updatable Views (SQL-92 Standard)

– SQL-92 allows updates only on views based on a single table.
– The view must use selection and projection only (no joins or aggregates).
– Views meeting these criteria are called updatable views.
 Updates on Views
▪ Views provide an abstraction over base tables, and in some cases, they
allow modifications.
– However, updates on views must be carefully managed to ensure they make sense
in the context of the underlying base table.

▪ Modifying GPA in GoodStudents Modifies it in Students

– The GoodStudents view is created as:
 Updates on Views
▪ If we update the gpa of a student in this view:

▪ This update directly affects the Students table, because:

– The view does not store data separately.
– It simply presents data from the base Students table.
– Any changes to the view update the base table accordingly.
Updates on Views
▪ Deleting a Row from GoodStudents Deletes it from Students
– If we delete a student from GoodStudents:

▪ Since the view does not store its own data, the corresponding row is
deleted from the Students table.
▪ This means that:
– The student 53832 is removed completely from the Students table.
– The student will also be removed from any other views that reference Students.
 Updates on Views
▪ The Issue with Views That Do Not Include a Key Column
– If a view does not include a primary key, multiple base table rows can map to a single row in the
view.
– This creates ambiguity when performing updates or deletions.
– Example:
• Suppose we define a view that includes student names but not IDs

• The name column is not unique (multiple students may have the same name).
Updates on Views

▪ Problem:
– There might be multiple students named 'Smith' in the Students table.
– The database does not know which ‘Smith’ to update.
– This makes the update ambiguous.
 Inserting Data into Views
▪ Inserting data into a view is possible only if the view has all the necessary
fields required by the base table.
– If the view omits essential columns, insertions might fail due to missing values.

▪ Insertions are Allowed if All Required Fields Exist in the Base Table
– Consider the following base table Students

Suppose we create the view GoodStudents

 Inserting Data into Views
▪ Since GoodStudents includes both sid and gpa, both required fields
for insertion are present.
▪ A valid insertion into the view:

– This will insert the record into the Students table.

– The student will also appear in GoodStudents because the condition gpa >
3.0 is satisfied.
 Inserting Data into Views
▪ Insertion is Rejected if the View Omits Required Fields
– If a view does not include all required fields of the base table (e.g., name and login), inserting data
will fail.

– Issue 1: The new row violates the gpa > 3.0 condition.
• The row will be added to Students but will not appear in GoodStudents.

– Issue 2: If name and login are NOT NULL columns in Students, the insertion will be rejected
because:
• The GoodStudents view does not include name or login.
• The database does not know what values to insert for these missing fields.
• Since name and login cannot be NULL, the insertion fails.
 Handling Invalid Updates
▪ When inserting or updating data in a view, the changes may violate the
view's conditions, causing inconsistencies.
– SQL-92 provides a solution using WITH CHECK OPTION to enforce the view’s
conditions.

▪ To ensure that only valid rows can be inserted or updated, we add WITH
CHECK OPTION:
 Need to Restrict View Updates
▪ Updating views is challenging because views do not store data.
– Instead, they retrieve data dynamically from base tables. This becomes
problematic when a view is based on multiple tables, as an update may require
modifying more than one table, leading to unintended consequences.
 Need to Restrict View Updates
▪ View Definition
– The ActiveStudents view is created as:

– This view combines data from Students and Clubs.

– Only students with GPA > 3 who are in a club are included.
 Why Are Updates Problematic?
▪ Deleting a Row from the View
– Suppose we want to delete:

– Issue:
• ActiveStudents does not store data; it retrieves from Students and Clubs.
• We must delete the record from either Students or Clubs:
• If we delete Smith from Students, we remove Smith from all clubs (Rowing too).
• If we delete Smith from Clubs, we remove him from Hiking but also from ActiveStudents.
– Solution: Disallow deletions in multi-table views.
 Need to Restrict View Updates
▪ Inserting Data into the View
– Suppose we insert:

• Issue:
• ActiveStudents is based on two tables:
• Students needs (name, login, gpa, age, etc.)
• Clubs needs (cname, jyear, mname)
• The database doesn’t know where to insert this data.
• Does John already exist in Students?
• Should a new row be added to Clubs or Students?
• Since there is no unique key, we cannot unambiguously insert this data.
• Solution: Disallow insertions into multi-table views.
 Need to Restrict View Updates
▪ Some simple views (based on a single table) can be updated. Example:

– Insertion works

• The Students table is updated.

– Deletion works:

• The Students table is updated.

▪ Multi-table views cannot be updated safely, so SQL-92 restricts updates to simple views.
Destroying/Altering Tables and Views
▪ Dropping (Deleting) Tables
– If a table is no longer needed, we can permanently delete it using:

– However, this deletes all data and removes the table definition
from the database.
 Destroying/Altering Tables and Views
▪ Using RESTRICT and CASCADE with DROP TABLE
– DROP TABLE Students RESTRICT
• Deletes the table only if no other views or constraints reference it.
• If dependencies exist, the command fails.

– DROP TABLE Students CASCADE

• Deletes the table and any dependent views or constraints.
• If other tables, views, or foreign keys reference Students, they will also be deleted recursively.

▪ Key Difference:
– RESTRICT prevents accidental deletion if dependencies exist.
– CASCADE forcefully removes the table along with all dependent objects.
 Destroying/Altering Tables and Views
▪ Dropping Views
– Views can be deleted using DROP VIEW, similar to dropping tables:

– This removes the view definition but does not affect the base tables.
 Destroying/Altering Tables and Views
▪ Altering Tables (ALTER TABLE)
– The ALTER TABLE command modifies an existing table’s structure without
deleting it.
– Example: Adding a new column maiden-name to Students:

– This adds the column to all existing rows.

– If no default value is specified, NULL values are inserted.
 Destroying/Altering Tables and Views
▪ Other Uses of ALTER TABLE
– The ALTER TABLE statement is used to modify the structure of an existing
table without deleting it. Apart from adding columns, it can be used to remove
columns, modify constraints, and manage integrity constraints.
 Destroying/Altering Tables and Views
▪ Other Uses of ALTER TABLE
– Removing a Column from a Table
– You can remove a column if it is no longer needed using:

– Effect:
• The maiden-name column is permanently removed.
• All data in this column is deleted.
• If any view or constraint depends on this column, the command may fail unless CASCADE is used.

– Key Considerations: Cannot drop a column if it’s part of a primary key (unless constraints are dropped first).
– Cannot drop a column if a foreign key depends on it.
– Use CASCADE to forcefully drop related constraints.
 Destroying/Altering Tables and Views
▪ Other Uses of ALTER TABLE
– Removing a Column from a Table
– You can remove a column if it is no longer needed using:

– Effect:
• The maiden-name column is permanently removed.
• All data in this column is deleted.
• If any view or constraint depends on this column, the command may fail unless CASCADE is used.

– Key Considerations: Cannot drop a column if it’s part of a primary key (unless constraints are dropped first).
– Cannot drop a column if a foreign key depends on it.
– Use CASCADE to forcefully drop related constraints.
 Destroying/Altering Tables and Views
▪ Modifying Column Constraints
– You can change constraints such as NOT NULL, DEFAULT, or UNIQUE on a column.
– Example: Making gpa a required field (NOT NULL):
• Now, the column must have a value in every row.

– Example: Changing the default value for gpa:

• Now, if a new student is added without specifying gpa, it defaults to 3.0.

▪ Key Considerations:
– You cannot apply NOT NULL if the column already has NULL values (unless you update them first).
– Altering constraints may require updating existing data to conform to the new rule.
 Destroying/Altering Tables and Views
▪ Adding or Removing Integrity Constraints
– Integrity constraints help maintain data consistency and validity. ALTER TABLE allows you to add
or remove primary keys, foreign keys, and unique constraints.

▪ Adding a Primary Key

▪ If a table doesn’t have a primary key, you can add one:

– This enforces uniqueness in sid (student ID).

– If sid contains duplicate or NULL values, this command will fail.
 Destroying/Altering Tables and Views
▪ Removing a Primary Key
– To remove the primary key:

• Now, sid can have duplicates or NULL values.

▪ Important Notes:
– Cannot drop a primary key if it's referenced by a foreign key in another table.
– To remove a primary key that has foreign key dependencies, drop the foreign key first.
 Destroying/Altering Tables and Views
▪ Adding a Foreign Key
– Foreign keys link two tables to maintain referential integrity.
– Example: Ensure that every student's department_id exists in the Departments
table:

• This prevents inserting a department_id in Students that does not exist in Departments.
 Destroying/Altering Tables and Views
▪ Removing a Foreign Key
– If the foreign key is no longer needed:

– Now, department_id can store any value, even if it doesn’t exist in Departments.

▪ Key Considerations:
– Foreign keys prevent deletion of referenced records unless CASCADE is used.
– Dropping a foreign key removes referential integrity, which might lead to
orphan records.
 Destroying/Altering Tables and Views
▪ Be Cautious with CASCADE
– Using CASCADE ensures that dependent constraints, columns, or tables are
automatically removed.
– Example: Dropping a column with dependent constraints:

• Effect: If department_id has a foreign key, it will also be removed.

▪ Key Risks:
– Using CASCADE can unintentionally delete important constraints.
– Always check dependencies before applying CASCADE to avoid data loss.
Relational Algebra
and Calculus
Topics
▪ Relational Algebra
– Selection and Projection
– Set Operations
– Renaming
– Joins
– Division
– More Examples of Relational Algebra Queries
▪ Relational Calculus
– Tuple Relational Calculus
– Domain Relational Calculus
 Relational Algebra and Calculus
▪ Query Languages: Specialized for asking questions (queries) about data in
a database.
– Two formal query languages:
• Relational Algebra (Operational Approach)
• Uses a collection of operators.
• Queries are written in a step-by-step operational manner.
• Relational Calculus (Declarative Approach)
• Queries specify what to retrieve without describing how to compute it.
• This is a declarative style of querying.
– Both have influenced commercial query languages like SQL.
 Introduction
▪ Relational Queries – Positional Notation Approach:
– Inputs and Outputs: • When working with complex
queries, there might be temporary
• Both are relations (tables).
tables (intermediate results).
• A query takes input relation instances and
produces an output relation instance. • Instead of giving names to all fields,
we can just refer to them by
– Evaluation Process: position.
• Queries are evaluated based on given instances
of input relations. • This makes the process simpler
and less confusing.
▪ Field Naming in Queries
– Field Names Approach:
• Makes queries more readable.
• Commonly used for clarity in relational
operations.
 Relational Algebra
▪ The language or set of operations used to manipulate data in the
relational model is called Relational Algebra.
– A formal query language used for retrieving and manipulating data in a relational
database.
– It consists of operations that take one or more relations (tables) as input and
produce a new relation (table) as output.

▪ Relational Algebra Expression:

– Defined recursively.
– Uses unary (one relation) and binary (two relations) operators.
 Relational Algebra
▪ Basic Operators in Relational Algebra
– Selection (σ) → Selects specific rows based on conditions.
– Projection (π) → Selects specific columns.
– Union (∪) → Combines two relations.
– Cross Product (×) → Combines tuples from two relations.
– Difference (-) → Finds tuples in one relation but not in the other.
– Rename (ρ) → Renames a relation or its attributes.
– Additional (Derived) Operations
• Intersection (∩) → Finds common tuples between two relations.
• Join (⋈) → Combines related tuples from different relations.
• Division (÷) → Retrieves tuples related to all values in another relation.
 Relational Algebra
▪ Unary Operators (Operate on a single relation)
– Selection (σ) → Filters rows.
– Projection (π) → Selects columns.
– Rename (ρ) → Renames a relation or attributes.

▪ Binary Operators (Operate on two relations)

– Union (∪) → Merges two relations.
– Set Difference (-) → Finds tuples present in one relation but not in the other.
– Cartesian Product (×) → Combines every tuple from two relations.
– Join (⋈) → Merges related tuples based on a common attribute.
 Relational Algebra
▪ Procedural Query Language:
– Requires step-by-step execution of operations.
– Can be considered as a recipe or plan for evaluating a query.
Selection and Projection
Selection (σ)
• Purpose: Selects specific rows (tuples) from a relation
based on a condition.
• Operator Symbol: σ (sigma)
 Selection and Projection
▪ Selection Condition:
– Can be a boolean combination (AND ∧, OR ∨).
– Example conditions:
• attribute op constant
• e.g., rating > 8
• attribute1 op attribute2
• e.g., age < rating
• Comparison Operators: <, <=, =, ≠, >=, >
– Attributes can be referred by name (e.g., .rating) or position (e.g., .i).
 Selection and Projection
▪ Projection (π)
– Purpose: Selects specific columns (attributes) from a relation.
– Operator Symbol: π (pi)
 Selection and Projection
▪ Projection (π)
– Projection Eliminates Columns:
• Only keeps the specified columns.
• Other columns are discarded.
– Duplicate Elimination in Projection:
• If multiple rows have the same value, only one is kept.
• Some databases omit duplicate elimination for
efficiency.
 Selection and Projection
▪ Combining Selection and Projection
– Since relational algebra expressions return relations, they can be nested.
– Example:

▪
– Step 1: Apply selection (σ_rating>8(S2)) → Filters sailors with rating > 8
– Step 2: Apply projection (π_sname, rating) → Keeps only sname and rating.
– Result
 Set Operations in Relational Algebra
▪ Relational algebra supports set operations, which work similarly to
set operations in mathematics. These include:
– Union (∪)
– Intersection (∩)
– Set Difference or Minus (−)
– Cross Product (×) (also called Cartesian Product)
 Set Operations in Relational Algebra
▪ Union (R ∪ S)
– Definition: Combines all tuples from R and S into a single relation.
– Condition: R and S must be union-compatible.
• Same number of fields (columns).
• Corresponding fields must have the same domain (data type).
 Set Operations in Relational Algebra
▪ Intersection (R ∩ S)
– Definition: Returns only the tuples that appear in both R and S.
– Condition: R and S must be union-compatible.
 Set Operations in Relational Algebra
▪ Set Difference (R - S)
– Definition: Returns all tuples in R that are NOT in S.
– Condition: R and S must be union-compatible.
 Set Operations in Relational Algebra
▪ Cross Product (R × S)
– Definition: Combines every tuple in R with every tuple in S.
– Result: A relation with all attributes of R followed by all attributes of S.
– Also called Cartesian Product.
• The resulting relation has more rows, as each row from S1 is combined with every row from R1.
• Fields with the same name (e.g., sid) are unnamed and referred by position.
 Renaming in Relational Algebra
▪ In relational algebra, results inherit field names from their input
relations whenever possible.
▪ However, name conflicts can occur, especially in operations like cross-
product (×).
– Example: S1 × R1 results in two sid fields, creating ambiguity.

▪ Renaming helps to explicitly name fields or relations, making expressions

easier to read and work with.
 Renaming in Relational Algebra
▪ Renaming Operator (ρ)
– Symbol: ρ (rho)

▪ Purpose:
– Assigns new names to attributes or the relation itself.
– Helps avoid naming conflicts in complex expressions.

▪ General Syntax:
• E → A relational algebra expression.
• R → The new relation name.
• F → A renaming list, specifying new field names.
 Renaming in Relational Algebra
▪ How Renaming Works
– Renaming the Relation Name:
• ρ(R, E) → Renames the result of E as R, keeping the same schema.
• Example: ρ(Seafarers,Sailors)
– Renaming Attributes:
• ρ(R(F), E) → Renames specific attributes using the renaming list (F).
• Example: ρ(Boats(boat_id,boat_name,color),Boats)
– Renaming by Position:
• The renaming list can use old names or positions to assign new names.
• ρ(ReservationPairs(1→sid1,2→bid1,3→day1,4→sid2,5→bid2,6→day2),Reserves×Reserves)
 Renaming in Relational Algebra
▪ Given: S1 × R1 (Cross-product of Sailors and Reserves)
▪ Issue: Both relations have a field named sid, causing ambiguity.
▪ Solution: Use ρ (renaming operator) to rename one sid to sid1 and
another sid2:
 Joins in Relational Algebra
▪ A join operation is used to combine information from two or
more relations.
▪ It is more efficient than using a cross-product followed by
selection and projection.
▪ Join is widely used in databases to retrieve related information from
multiple tables.
 Joins in Relational Algebra
▪ Condition Join (θ-Join)
– General form of a join where a join condition (θ) is specified.

▪ Definition:
– First, compute the cross-product (R × S).
– Then, apply a selection condition (σ_c) to filter the result.
 Joins in Relational Algebra

Operation Number of Tuples Number of Attributes

Cartesian Product (×) t1 × t2 a1 + a2

a1 + a2 (or fewer if
Join (⨝) Between 0 and t1 × t2
attributes are merged)
 Equijoin
▪ A special case of θ-join where the condition consists only of equalities.
▪ Form: R ⨝ S where R.name1 = S.name2
▪ Duplicates occur because both relations retain the common attribute.
▪ To avoid redundancy, one of the duplicate attributes is dropped using
projection.
Equijoin
 Natural Join (No Condition Needed)
▪ A special case of Equijoin where the condition includes all common
attributes between the relations.
▪ No need to specify a join condition explicitly.
▪ The result does not have duplicate attributes (common attributes
appear only once).
▪ Notation: R ⨝ S (if all common attributes are used).
 Natural Join
Difference Between Join and Natural Join

• Regular Join (θ-Join or Equijoin):

• Requires a specific condition to match tuples.
• Can be performed on attributes with different names, as long as they have the same domain
(data type).
• The result retains both matching attributes.

• Natural Join (⨝):

• Automatically matches attributes that have the same name in both tables.
• No need to specify the join condition.
• The duplicate attribute is removed from the result, keeping only one.
 How Natural Join Works
• Step 1: Perform Cartesian Product (Cross Product of both tables).
• Step 2: Filter out tuples where the values of the common attribute
(same name) do not match.
• Step 3: Remove one of the duplicate attributes.
Employee ⨝Employee_ID = ID Father
 Feature Regular Join (⨝ Condition) Natural Join (⨝)

Yes (must specify No (automatically matches

Condition Required?
condition) attributes with the same name)

Attributes Used for Any attributes with the same Only attributes with the same
Matching domain name

Yes, both matching No, one of the matching

Duplicate Columns?
attributes remain attributes is removed

Can join different-named Works only when common

Flexibility
attributes attributes have the same name

Note: If no common attribute exists, Natural Join acts as a Cartesian Product.

 Employee Table Department Table
EID Name Age EID Department
1 Ram 45 1 Accounts

2 Bob 43 2 HR

Cartesian Product Result

(Employee × Department) Employee ⨝Employee.EID = Department.EID Department

EID Name Age EID Department

1 Ram 45 1 Accounts EID Name Age EID Department

1 Ram 45 2 HR 1 Ram 45 1 Accounts

2 Bob 43 1 Accounts 2 Bob 43 2 HR
2 Bob 43 2 HR

EID Name Age Department

1 Ram 45 Accounts
(Employee ⨝ Department)
2 Bob 43 HR
 Inner Join (⨝)
• Definition: An Inner Join retrieves only the matching records from
both tables based on a join condition.
• Issue with Inner Join:
• Missing Data: It excludes records that do not have a match in the other
table.
• Example: If an employee is not assigned to any project, their record is not
included in the result.
• Example: If a project has no assigned manager, it won’t appear in the result.
Employee Table Projects Table
Employee_ID Employee_Name Age
Project_ID Manager_ID
1 Ram 45
1000 1
2 Bob 43
1001 2
3 Jack 46
1002 NULL
4 Sam 56

Employee ⨝Employee_ID = Manager_ID Projects

Employee_ID Employee_Name Age Project_ID Manager_ID

1 Ram 45 1000 1
2 Bob 43 1001 2
 Outer Joins
▪ Outer Joins solve the missing data issue by including unmatched records
and filling them with NULL values.
▪ Types:
1. Left Outer Join (⟕)
2. Right Outer Join (⟖)
3. Full Outer Join (⟗)
 Left Outer Join (⟕)
▪ Definition: Retrieves all records from the left table (Employee) and the
matching records from the right table (Projects).
▪ If no match is found, NULL is inserted in columns from the right table.

Employee ⟕ Employee_ID = Manager_ID Projects

Employee_ID Employee_Name Age Project_ID Manager_ID
1 Ram 45 1000 1
2 Bob 43 1001 2
3 Jack 46 NULL NULL
4 Sam 56 NULL NULL
 Right Outer Join (⟖)
▪ Retrieves all records from the right table (Projects) and the matching records from
the left table (Employee).
▪ If no match is found, NULL is inserted in columns from the left table.

Employee ⟖ Employee_ID = Manager_ID Projects

Employee_ID Employee_Name Age Project_ID Manager_ID

1 Ram 45 1000 1
2 Bob 43 1001 2
NULL NULL NULL 1002 NULL
 Full Outer Join (⟗)
▪ Retrieves all records from both tables, filling NULL where no match is
found.
▪ Combination of Left and Right Outer Joins.

Employee_ID Employee_Name Age Project_ID Manager_ID

1 Ram 45 1000 1
2 Bob 43 1001 2
3 Jack 46 NULL NULL
4 Sam 56 NULL NULL
NULL NULL NULL 1002 NULL
 Division operator
▪ The division operator (÷) is used for queries that involve "for all"
conditions.
– Example: "Find the sailors who have reserved all boats."
– It is less frequently used than other relational algebra operators like selection (σ)
or projection (π).
 Understanding Division with an Example
▪ Consider two relation instances A and B:
– A (x, y) → A relation with two attributes (e.g., a list of students and projects).
– B (y) → A relation with one attribute (a subset of values from A’s second
column).

▪ Definition:
– A ÷ B gives all x values from A where every y value in B is present for that x.
• It finds all x-values in relation A(x, y) such that for every y-value in B(y), there is a
corresponding (x, y) pair in A.
 Concept Explanation
▪ For each x value in A:
– Find all corresponding y values in A.
– If these y values contain all values in B, include x in the result.

▪ Analogy to Integer Division

– Integer division A ÷ B finds the largest number Q such that:

▪ In relational algebra: A ÷ B
– Gives the largest relation instance Q such that:
 Division Formula in Relational Algebra
▪ To compute A ÷ B:
1. Compute all x values in A:
2. Create a Cartesian Product of A’s x values and B:
3. Subtract tuples not present in A:
4. Get valid x values:
Student_ID Course_ID
Find students who have completed all required courses in B.
(sno) (cno)
S1 C1 Step 1: Identify All Students
S1 C2 • Get all students (sno) from A:
S1 C3 Student_ID (sno)
S2 C1 S1
S2 C3 S2 Student_ID Course_ID
S3 (sno) (cno)
S3 C1
S1 C1
S3 C2 Step 2: Create Cartesian Product S1 C2
S3 C3 (sno × B) S1 C3
• Form all possible combinations of S2 C1
Course_ID students and required courses: S2 C2
(cno)
S2 C3
C1
S3 C1
C2 S3 C2
C3 S3 C3
Student_ID Course_ID
Find students who have completed all required courses in B.
(sno) (cno)
S1 C1 Step 3: Subtract Non-Matching Tuples
S1 C2 • Remove tuples that are in the Cartesian Product but
S1 C3 not in A
S2 C1
S2 C3 Student_ID (sno) Course_ID (cno)
S3 C1 S2 C2
S3 C2 • Student S2 is missing C2, so S2 is disqualified.
S3 C3
Step 4: Get the Final Result
Course_ID • Extract students who are not disqualified:
(cno)
Student_ID
C1 (sno)
C2 S1
C3 S3
▪ (Q1) Find the names of sailors who have reserved boat 103.
– Relational Algebra Expression:

• Steps:
1. Select (σ) reservations where bid = 103.
2. Join the result with the Sailors table on sid.
3. Project (π) only the sname column. Final Projection
(Extracting
sname):
Intermediate Steps:
•Temp1: • Temp2 (Join with Sailors Table):

sid bid day sid sname rating age bid day

sname
22 103 10/8/98 22 Dustin 7 45.0 103 10/8/98 Dustin
31 103 11/6/98 31 Lubber 8 55.5 103 11/6/98 Lubber
Horatio
74 103 9/8/98 74 Horatio 9 35.0 103 9/8/98
 (Q2) Find the names of sailors who have reserved a red boat.

• Steps:
1. Select (σ) all boats where color = 'red' from the Boats table. Temp3 (Join with Sailors on sid):
2. Join (⨝) the result with Reserves using bid.
3. Join the result with Sailors using sid.
4. Project (π) only the sname column. sid sname rating age bid day

• Intermediate Steps: 11/6/9

Temp2 (Join with Reserves on 31 Lubber 8 55.5 102
8
• Temp1 (Red Boats Selection): bid):
9/8/9
64 Horatio 7 35.0 102
8

bid bname color sid bid day Final Projection

(Extracting sname):
102 Interlake red 29 102 10/10/98
sname
104 Marine red 31 102 11/6/98
Lubber
64 102 9/8/98
Horatio
31 104 11/12/98
(Q3) Find the colors of boats reserved by Lubber

• Steps:
1. Select (σ) the sailor with sname = 'Lubber'.
2. Join the result with Reserves on sid.
3. Join the result with Boats on bid.
4. Project (π) only the color column.

Final Answer:
• On instances B1, R2, and S3, the query returns green and red.
(Q4) Find the names of sailors who have reserved at least one boat

• Steps:
1. Join Sailors and Reserves on sid.
2. Project (π) only the sname column.

• Final Answer:
• On instances B1, R2, and S3, the sailors who have
reserved a boat are Dustin, Horatio, and Lubber.
• Since relations do not contain duplicates, Horatio
appears only once despite two sailors sharing that name.
(Q5) Find the names of sailors who have reserved a red or a green boat

• Steps:
1. Find boats that are either red or green.
2. Join with Reserves to get sid of sailors who
reserved these boats.
3. Join with Sailors to get their names.

• Final Answer:
• Sailors who reserved a red or green boat:
Dustin, Horatio, and Lubber.
 (Q6) Find the names of sailors who have reserved a red and a green boat

• Steps:
1. Find sailors who reserved a red boat (Tempred).
2. Find sailors who reserved a green boat
(Tempgreen).
3. Take the intersection (∩) of both sets.
4. Join with Sailors to get their names.

• Final Answer:
• On instances B1, R2, and S3, Dustin and Lubber
have reserved both red and green boats.
 (Q7) Find the names of sailors who have reserved at least two boats

• Steps:
1. Compute all reservations (join Sailors and
Reserves).
2. Find pairs of reservations made by the same sailor
but for different boats.
3. Project only sname.

• Final Answer:
• On instances B1, R2, and S3, the sailors who
reserved at least two boats are Dustin, Horatio, and
 (Q8) Find the sids of sailors with age over 20 who have not reserved a red boat

• Steps:
1. Find sailors older than 20 (σ on Sailors).
2. Find sailors who have reserved a red boat.
3. Use set difference (-) to exclude sailors from step 2.

• Final Answer:
• On instances B1, R2, and S3, the sid values of sailors
who have not reserved a red boat are 29, 32, 58, 74,
85, and 95.
 Q9) Find the names of sailors who have reserved all boats

• Steps:
1. Compute division: Find sailors who have reserved
every boat.
2. Join with Sailors to get names.

• Final Answer:
• Sailor Dustin (sid 22) has reserved all boats.
 (Q10) Find the names of sailors who have reserved all boats called "Interlake"

• Steps:
1. Select boats named "Interlake."
2. Compute division to find sailors who reserved all
"Interlake" boats.
3. Join with Sailors to get names.

• Final Answer:
• Dustin and Horatio reserved all "Interlake" boats.
Unit-3
Part-1 By B. Lokesh Joel

93