0% found this document useful (0 votes)
8 views17 pages

Dbms Question Bank Answers

The document provides an overview of various database concepts including selection and projection in relational algebra, set operations, join operations, tuple and domain relational calculus, SQL data types and constraints, and SQL commands for creating and manipulating tables. It also covers aggregate functions, normalization, and functional dependencies with examples. Additionally, it explains SQL queries such as SELECT with WHERE and ORDER BY, GROUP BY with HAVING, and nested queries.

Uploaded by

vikas.rs453
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views17 pages

Dbms Question Bank Answers

The document provides an overview of various database concepts including selection and projection in relational algebra, set operations, join operations, tuple and domain relational calculus, SQL data types and constraints, and SQL commands for creating and manipulating tables. It also covers aggregate functions, normalization, and functional dependencies with examples. Additionally, it explains SQL queries such as SELECT with WHERE and ORDER BY, GROUP BY with HAVING, and nested queries.

Uploaded by

vikas.rs453
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

MODULE 2 QUESTION BANK ANSWERS

1) Explain selection and projection with examples


1. Selection(σ)
The Selection Operation is basically used to filter out rows from a given table based
on certain given condition. It basically allows us to retrieve only those rows that
match the condition as per condition passed during SQL Query.
Example: If we have a relation R with attributes A, B, and C, and we want to select
tuples where C > 3, we write:
A B C
1 2 4
2 2 3
3 2 3
4 3 4
σ(c>3)(R) will select the tuples which have c more than 3.
Output:
A B C
1 2 4
4 3 4
Explanation: The selection operation only filters rows but does not display or change
their order. The projection operator is used for displaying specific columns.
2. Projection(π)
While Selection operation works on rows, similarly projection operation of relational
algebra works on columns. It basically allows us to pick specific columns from a given
relational table based on the given condition and ignoring all the other remaining
columns.
Example: Suppose we want columns B and C from Relation R.
π(B,C)(R) will show following columns.
Output:
B C
2 4
2 3
3 4
Explanation: By Default, projection operation removes duplicate values.

2) Explain set operations in relational algebra.

1) Union ( ∪ )

Combines tuples from two relations.


Removes duplicate tuples.

Result contains all tuples present in either relation.

Example:
R ∪ S gives all records that are in R or in S.

2) Intersection ( ∩ )

Returns only the tuples that are common to both relations.

Result contains tuples present in both relations.

Example:
R ∩ S gives records common to R and S.

3) Set Difference ( − )

Returns tuples that are in one relation but not in the other.

Order matters.

Example:
R − S gives tuples present in R but not in S.

4) Cartesian Product ( × )

Combines every tuple of one relation with every tuple of another relation.

Result has all possible combinations.

Example:
R × S pairs each record of R with each record of S.

3) Explain join operations with examples.


1) Cartesian Join (×)

Combines every tuple of one relation with every tuple of another relation.

No condition is applied.
Example:
Student × Course
Each student is paired with every course.

2) Theta Join ( ⨝θ )

A join with a condition using operators like <, >, =, ≤, ≥.

Example:
Student ⨝ ([Link] = [Link]) Course
Joins records where student ID matches.

3) Equi Join

A special type of theta join using only equality (=).

Duplicate join columns are shown.

Example:
Student ⨝ [Link] = [Link] Course

4) Natural Join ( ⨝ )
Automatically joins relations on common attributes.
Removes duplicate columns.
Example:
Student ⨝ Course
Joins tables using common attribute like id.

5) Outer Join
Returns matched records and also unmatched records.
Left Outer Join: All records from left table
Right Outer Join: All records from right table
Full Outer Join: All records from both tables
Example:
Student ⟕ Course (Left outer join)

4) Explain division operation with suitable example.

Division (÷)
The Division Operator is used to find tuples in one relation that are related to all
tuples in another relation. It’s typically used for "for all" queries.
Student_Course (Dividend Table):
Student_ID Course_ID
101 C1
101 C2
102 C1
103 C1
103 C2

5) Explain tuple relational calculus with example.

Tuple Relational Calculus (TRC)


Tuple Relational Calculus in DBMS uses a tuple variable (t) that goes to each row of
the table and checks if the predicate is true or false for the given row. Depending on
the given predicate condition, it returns the row or part of the row.
The Tuple Relational Calculus expression Syntax
{t \| P(t)}
Where t is the tuple variable that runs over every Row, and P(t) is the predicate logic
expression or condition.
Let's take an example of a Customer Database and try to see how TRC expressions
work.
Customer Table
Zip
Customer_id Name
code
1 Rohit 12345
2 Rahul 13245
3 Rohit 56789
4 Amit 12345.
Example 1: Write a TRC query to get all the data of customers whose zip code is
12345.
TRC Query: {t \| t ∈ Customer ∧ [Link] = 12345} or TRC Query: {t \| Customer(t)
∧ t[Zipcode] = 12345 }
Workflow of query - The tuple variable "t" will go through every tuple of the
Customer table. Each row will check whether the Cust_Zipcode is 12345 or not and
only return those rows that satisfies the Predicate expression condition.
The TRC expression above can be read as "Return all the tuple which belongs to the
Customer Table and whose Zipcode is equal to 12345."
Result of the TRC expression above:
Zip
Customer_id Name
code
1 Rohit 12345
Zip
Customer_id Name
code
4. Amit 12345
Example 2: Write a TRC query to get the customer id of all the Customers.
TRC query: { t \| ∃s (s ∈ Customer ∧ s.Customer_id = t.customer_id) }
Result of the TRC Query:
Customer_id
1
2
3
4

6) Explain domain relational calculus with example.


Domain Relational Calculus (DRC)
Domain Relational Calculus uses domain Variables to get the column values required
from the database based on the predicate expression or condition.
The Domain realtional calculus expression syntax:
{<x1,x2,x3,x4...> \| P(x1,x2,x3,x4...)}
where,
<x1,x2,x3,x4...> are domain variables used to get the column values required,
and P(x1,x2,x3...) is predicate expression or condition.
Let's take the example of Customer Database and try to understand DRC queries with
some examples.
Customer Table
Zip
Customer_id Name
code
1 Rohit 12345
2 Rahul 13245
3 Rohit 56789
4 Amit 12345
Example 1: Write a DRC query to get the data of all customers with Zip code 12345.
DRC query: {<x1,x2,x3> \| <x1,x2> ∈ Customer ∧ x3 = 12345 }
Workflow of Query: In the above query x1,x2,x3 (ordered) refers to the attribute or
column which we need in the result, and the predicate condition is that the first two
domain variables x1 and x2 should be present while matching the condition for each
row and the third domain variable x3 should be equal to 12345.
Result of the DRC query will be:
Zip
Customer_id Name
code
1 Rohit 12345
4 Amit 12345

7) Explain SQL data types and constraints.

SQL Data Types

a) Numeric Data Types


Used to store numbers.
INT – Stores whole numbers
FLOAT / DOUBLE – Stores decimal values
Example:
age INT

b) Character / String Data Types


Used to store text.
CHAR(n) – Fixed-length string
VARCHAR(n) – Variable-length string
Example:
name VARCHAR(50)

c) Date and Time Data Types


Used to store date and time values.
DATE – Stores date
TIME – Stores time
DATETIME – Stores date and time
Example:
dob DATE

d) Boolean Data Type


BOOLEAN – Stores TRUE or FALSE
Example:
is_active BOOLEAN

Constraints in Relational Model


Relational models make use of some rules to ensure the accuracy and accessibility of
the data. These rules or constraints are known as Relational Integrity Constraints.
These constraints are checked before performing any operation like insertion,
deletion, or updation on the data present in a relational database. These constraints
include:
• Domain Constraint: It specifies that every attribute is bound to have a value that lies
inside a specific range of values. It is implemented with the help of the Attribute
Domain concept.
• Key Constraint: It states that every relation must contain an attribute or a set of
attributes (Primary Key) that can uniquely identify a tuple in that relation. This key
can never be NULL or contain the same value for two different tuples.
• Referential Integrity Constraint: It is defined between two interrelated tables. It
states that if a given relation refers to a key attribute of a different or same table,
then that key must exist in the given relation.

8) Explain SELECT query with WHERE and ORDER BY.


(Write your own explanation)
SELECT Query with WHERE:
SELECT name, marks FROM Student WHERE marks >= 60 ORDER BY marks ASC;

ORDER BY:
Sorts the result set by one or more columns
Syntax: SELECT column1 FROM table_name ORDER BY column1 [ASC | DESC];

9) Explain GROUP BY and HAVING with example.

GROUP BY Clause
GROUP BY groups rows that have the same values in specified columns.
It is commonly used with aggregate functions like COUNT, SUM, AVG, MAX, and MIN.
Example:
SELECT department, COUNT(*)
FROM Employee
GROUP BY department;

Explanation:
This query counts the number of employees in each department.

2) HAVING Clause
HAVING is used to apply conditions on grouped data.
It is used with GROUP BY.

WHERE cannot be used with aggregate functions, so HAVING is required.


Example:
SELECT department, COUNT(*) FROM Employee GROUP BY department HAVING
COUNT(*) > 5;

10) Explain nested queries with example


Nested Queries in SQL
In SQL, a nested query (also called a subquery) is a query written inside another SQL
query.
The result of the inner query is used by the outer query.
Types of Nested Queries
Single-row subquery
Multiple-row subquery
Example:
SELECT name
FROM Student
WHERE marks > (
SELECT AVG(marks)
FROM Student
);

11) Explain views in SQL.

In SQL, a view is a virtual table created using a SELECT query.


A view does not store data physically; it displays data from one or more tables.

Purpose of Views
Simplifies complex queries
Provides data security
Hides unnecessary columns
Shows customized data to users
CREATE VIEW Student_View AS
SELECT name, marks
FROM Student;
SELECT * FROM Student_View;

Advantages of Views
Security
Users can access only selected columns through a view.
Simplicity
Complex queries are saved as views and reused easily.
Data Abstraction
Underlying table structure is hidden from users.
Consistency
Same logic is used every time the view is accessed.

12) Triggers(Not explained in class)

13) Explain relational algebra operations with suitable examples.


Same answer as for 2nd question

14) Explain relational calculus (TRC and DRC) with examples.


Same as 5th and 6th answer

15) Explain SQL commands for creating and manipulating tables.


1) Commands for Creating Tables (DDL – Data Definition Language)
a) CREATE
b) ALTER
c) DROP
d) TRUNCATE
Commands for Manipulating Tables (DML – Data Manipulation Language)
a) INSERT
b) UPDATE
c) DELETE

16) Explain aggregate functions and set operations in SQL.

Aggregate Functions in SQL


Below are the most frequently used aggregate functions in SQL.

1. Count()
It is used to count the number of rows in a table. It helps summarize data by giving
the total number of entries. It can be used in different ways depending on what you
want to count:
COUNT(*): Counts all rows.
COUNT(column_name): Counts non-NULL values in the specified column.
COUNT(DISTINCT column_name): Counts unique non-NULL values in the column.
Query:
-- Total number of records in the table
SELECT COUNT(*) AS TotalRecords FROM Employee;

-- Count of non-NULL salaries


SELECT COUNT(Salary) AS NonNullSalaries FROM Employee;
-- Count of unique non-NULL salaries
SELECT COUNT(DISTINCT Salary) AS UniqueSalaries FROM Employee;

COUNT(*) returns the total number of rows in the table, including rows with NULL
values.
COUNT(Salary) counts only the rows where Salary is not NULL.
COUNT(DISTINCT Salary) counts unique non-NULL salary values, ignoring
duplicates.

2. SUM()
It is used to calculate the total of a numeric column. It adds up all non-NULL values
in that column for Example, SUM(column_name) returns sum of all non-NULL
values in the specified column.

Query:
-- Calculate the total salary
SELECT SUM(Salary) AS TotalSalary FROM Employee;
-- Calculate the sum of unique salaries
SELECT SUM(DISTINCT Salary) AS DistinctSalarySum FROM Employee;

SUM(Salary) adds all non-NULL salary values to get the total salary amount.
SUM(DISTINCT Salary) adds only unique non-NULL salary values, avoiding
duplicates.
NULL values are ignored in both SUM calculations.

3. AVG()
It is used to calculate average value of a numeric column. It divides sum of all non-
NULL values by the number of non-NULL rows for Example, AVG(column_name)
returns average of all non-NULL values in the specified column.

Query:
-- Calculate the average salary
SELECT AVG(Salary) AS AverageSalary FROM Employee;
-- Average of distinct salaries
SELECT AVG(DISTINCT Salary) AS DistinctAvgSalary FROM Employee;
AVG(Salary) calculates the average of all non-NULL salary values.
AVG(DISTINCT Salary) computes the average only from unique non-NULL salary
values.
Both ignore NULL values when performing the calculation.

4. MIN() and MAX()


The MIN() and MAX() functions return the smallest and largest values, respectively,
from a column.

Query:
-- Find the highest salary
SELECT MAX(Salary) AS HighestSalary FROM Employee;
-- Find the lowest salary
SELECT MIN(Salary) AS LowestSalary FROM Employee;
Output:

MAX(Salary) returns the highest non-NULL salary value from the Employee table.
MIN(Salary) returns the lowest non-NULL salary value from the Employee table.
Both functions ignore NULL values while determining the result.
MODULE 3

1) Explain the need for normalization.


As we have discussed above, normalization is used to reduce data redundancy.
It provides a method to remove the following anomalies from the database and
bring it to a more consistent state:
A database anomaly is a flaw in the database that occurs because of poor
planning and redundancy.
[Link] anomalies: This occurs when we are not able to insert data into a
database because some attributes may be missing at the time of insertion.
[Link] anomalies: This occurs when the same data items are repeated
with the same values and are not linked to each other.
[Link] anomalies: This occurs when deleting one part of the data deletes
the other necessary information from the database.

2) Explain functional dependencies with examples.


Functional Dependencies (FDs)
A Functional Dependency is a concept used in Database Management
Systems (DBMS) to describe the relationship between attributes in a relation
(table). It helps in designing databases efficiently and in the normalization
process to remove redundancy and anomalies.

Definition
In a relation R, an attribute Y is said to be functionally dependent on attribute
X if for each value of X, there is only one corresponding value of Y.
It is denoted as:
X→Y
This means X uniquely determines Y.

Example
Consider a Student table:
Student_ID Student_Name Department
101 Ravi CSE
102 Anu ECE
103 Kiran CSE
Here:
• Student_ID → Student_Name
• Student_ID → Department
This means that if we know the Student_ID, we can uniquely determine the
Student_Name and Department.

Types of Functional Dependencies


1. Trivial Functional Dependency
A functional dependency X → Y is trivial if Y is a subset of X.
Example:
{Student_ID, Student_Name} → Student_ID
This is always true and does not provide useful information.

2. Non-Trivial Functional Dependency


A functional dependency X → Y is non-trivial if Y is not a subset of X.
Example:
Student_ID → Student_Name
This dependency provides meaningful information.

3. Completely Non-Trivial Functional Dependency


A functional dependency is completely non-trivial if X ∩ Y = ∅.
Example:
Student_ID → Department

4. Partial Dependency
A dependency where a non-prime attribute depends on part of a composite
primary key.
Example:
Consider a table Marks(Student_ID, Subject, Marks)
Primary Key = {Student_ID, Subject}
• Student_ID → Student_Name
This is a partial dependency because Student_Name depends only on part of
the primary key.

5. Transitive Dependency
If X → Y and Y → Z, then X → Z is a transitive dependency.
Example:
• Student_ID → Department
• Department → HOD
So, Student_ID → HOD

Importance of Functional Dependencies


• Helps in database normalization
• Reduces data redundancy
• Avoids update, insertion, and deletion anomalies
• Ensures data integrity

5) Explain 1NF with example.


First Normal Form (1NF)
A relation is in 1NF if every attribute is a single-valued attribute or it does not contain
any multi-valued or composite attribute, i.e., every attribute is an atomic attribute. If
there is a composite or multi-valued attribute, it violates the 1NF. To solve this, we can
create a new row for each of the values of the multi-valued attribute to convert the
table into the 1NF.
Let’s take an example of a relational table <EmployeeDetail> that contains the details
of the employees of the company.
<EmployeeDetail>
Employee Code Employee Name Employee Phone Number
101 John 98765623,998234123
101 John 89023467
102 Ryan 76213908
103 Stephanie 98132452
Here, the Employee Phone Number is a multi-valued attribute. So, this relation is not
in 1NF.
To convert this table into 1NF, we make new rows with each Employee Phone Number
as a new row as shown below:
<EmployeeDetail>
Employee Code Employee Name Employee Phone Number
101 John 998234123
101 John 98765623
101 John 89023467
102 Ryan 76213908
103 Stephanie 98132452

6) Explain 2NF with example.


Second Normal Form (2NF)
The normalization of 1NF relations to 2NF involves the elimination of partial
dependencies. A partial dependency in DBMS exists when any non-prime attributes,
i.e., an attribute not a part of the candidate key, is not fully functionally dependent on
one of the candidate keys.
For a relational table to be in second normal form, it must satisfy the following rules:
1. The table must be in first normal form.
2. It must not contain any partial dependency, i.e., all non-prime attributes are fully
functionally dependent on the primary key.
If a partial dependency exists, we can divide the table to remove the partially
dependent attributes and move them to some other table where they fit in well.
Let us take an example of the following <EmployeeProjectDetail> table to understand
what is partial dependency and how to normalize the table to the second normal form:
<EmployeeProjectDetail>
Employee Code Project ID Employee Name Project Name
101 P03 John Project103
101 P01 John Project101
102 P04 Ryan Project104
103 P02 Stephanie Project102
In the above table, the prime attributes of the table are Employee Code and Project
ID. We have partial dependencies in this table because Employee Name can be
determined by Employee Code and Project Name can be determined by Project ID.
Thus, the above relational table violates the rule of 2NF.
The prime attributes in DBMS are those which are part of one or more candidate keys.
To remove partial dependencies from this table and normalize it into second normal
form, we can decompose the <EmployeeProjectDetail> table into the following three
tables:
<EmployeeDetail>
Employee Code Employee Name
101 John
101 John
102 Ryan
103 Stephanie

7) Explain 3NF with example.


Third Normal Form (3NF)
The normalization of 2NF relations to 3NF involves the elimination of transitive
dependencies in DBMS.
A functional dependency X -> Z is said to be transitive if the following three functional
dependencies hold:
• X -> Y
• Y does not -> X
• Y -> Z
For a relational table to be in third normal form, it must satisfy the following rules:
1. The table must be in the second normal form.
2. No non-prime attribute is transitively dependent on the primary key.
3. For each functional dependency X -> Z at least one of the following conditions hold:
• X is a super key of the table.
• Z is a prime attribute of the table.
If a transitive dependency exists, we can divide the table to remove the transitively
dependent attributes and place them to a new table along with a copy of the
determinant.
Let us take an example of the following <EmployeeDetail> table to understand what is
transitive dependency and how to normalize the table to the third normal form:
<EmployeeDetail>
Employee Employee Employee Employee
Code Name Zipcode City
101 John 110033 Model Town
101 John 110044 Badarpur
102 Ryan 110028 Naraina
103 Stephanie 110064 Hari Nagar
The above table is not in 3NF because it has Employee Code -> Employee City transitive
dependency because:
• Employee Code -> Employee Zipcode
• Employee Zipcode -> Employee City
Also, Employee Zipcode is not a super key and Employee City is not a prime attribute.
To remove transitive dependency from this table and normalize it into the third normal
form, we can decompose the <EmployeeDetail> table into the following two tables:
<EmployeeDetail>
Employee Code Employee Name Employee Zipcode
101 John 110033
101 John 110044
102 Ryan 110028
103 Stephanie 110064

8) Explain BCNF with example.


Boyce-Codd Normal Form (BCNF)
Boyce-Codd Normal Form(BCNF) is an advanced version of 3NF as it contains
additional constraints compared to 3NF.
For a relational table to be in Boyce-Codd normal form, it must satisfy the following
rules:
1. The table must be in the third normal form.
2. For every non-trivial functional dependency X -> Y, X is the superkey of the table. That
means X cannot be a non-prime attribute if Y is a prime attribute.
A superkey is a set of one or more attributes that can uniquely identify a row in a
database table.
Let us take an example of the following <EmployeeProjectLead> table to understand
how to normalize the table to the BCNF:
<EmployeeProjectLead>
Employee Code Project ID Project Leader
101 P03 Grey
101 P01 Christian
102 P04 Hudson
103 P02 Petro
The above table satisfies all the normal forms till 3NF, but it violates the rules of BCNF
because the candidate key of the above table is {Employee Code, Project ID}. For the
non-trivial functional dependency, Project Leader -> Project ID, Project ID is a prime
attribute but Project Leader is a non-prime attribute. This is not allowed in BCNF.
To convert the given table into BCNF, we decompose it into three tables:
<EmployeeProject>
Employee Code Project ID
101 P03
101 P01
102 P04
103 P02
<ProjectLead>
Project Leader Project ID
Grey P03
Christian P01
Hudson P04
Petro P02
Thus, we’ve converted the <EmployeeProjectLead> table into BCNF by decomposing it
into <EmployeeProject> and <ProjectLead> tables.

You might also like