Define Domains, Attributes, Tuples, and Relations and also explain the characteristics of relation.

Ans:

In the context of relational databases and database management systems

(DBMS), let's define the following terms and explain the characteristics of
relations:

1. Domains:
 Domains are sets of possible values that an attribute (or field) in a
database can take.
 Each attribute in a relation belongs to a specific domain. Domains define
the data type and constraints for the attribute. For example, a domain
for the "age" attribute may specify that it can only contain positive
integers.
2. Attributes:
 Attributes are characteristics or properties of entities in a database. They
correspond to the columns in a table or relation.
 Each attribute is associated with a domain that defines the type of data
it can hold, such as integers, strings, dates, etc.
3. Tuples:
 Tuples are individual records or rows in a relation. They represent a
single entity or instance of the entity being modeled.
 Each tuple contains values for each attribute, and the values are
associated with the attributes based on the order of columns in the
relation.
4. Relations:
 A relation, in the context of a relational database, is a table that
organizes data into rows (tuples) and columns (attributes).
 Relations are the foundation of the relational model, and they are used
to store and manage structured data.
 Each relation has a unique name and consists of a set of attributes, each
with its domain, and a set of tuples that contain data.

Characteristics of Relations:
1. Uniqueness of Tuples:
 In a relation, each tuple (row) is unique, meaning there are no duplicate
rows. This ensures that each entity or instance is represented only once.
2. Atomic Values:
 Each attribute in a relation holds atomic (indivisible) values. This means
that an attribute cannot contain a nested structure or multiple values.
3. Fixed Schema:
 Relations have a fixed schema, which means that the set of attributes
and their domains are defined at the time the relation is created. This
schema remains constant throughout the existence of the relation.
4. Attribute Order:
 The order of attributes in a relation is not significant. Data can be
retrieved based on attribute names, not their positions.
5. No Duplicate Columns:
 A relation cannot have duplicate attribute names. Each attribute must
have a unique name within the relation.
6. No Specific Order of Tuples:
 There is no inherent order of tuples within a relation. The DBMS is
responsible for managing the physical storage and retrieval of data.
7. No Duplicate Tuples:
 As mentioned earlier, each tuple in a relation is unique. There can be no
duplicate rows.
8. NULL Values:
 Relations can contain NULL values, which represent missing or unknown
data for an attribute in a tuple.
9. Mathematical Set Operations:
 Relations support set operations like union, intersection, and difference,
which can be used to combine or compare data from different relations.

These characteristics make relations a fundamental concept in the relational

database model, providing a structured and efficient way to store, retrieve,
and manipulate data.

Q:2 Explain the select and project operation with syntax and examples.
Explain the select and project operation with syntax and examples.
ans:
Difference between Selection and Projection in DBMS

S.
No. Category Selection Projection
The selection The Project
operation is also operation is
1. Other Names known as also known as
horizontal vertical
partitioning. partitioning.

It is used to
It is used to
choose the
select certain
subset of tuples
required
from the relation
attributes,
2. Use that satisfies the
while
given condition
discarding
mentioned in
other
the syntax of
attributes.
selection.

It partitions the
It partitions the
3. Partitioning table
table vertically.
horizontally.

The selection The projection

operation is operation is
performed performed
Which used
4. before after selection
first
projection (if (if they are to
they are to be be used
used together). together).

Project
Select operator
operator is
Operator is used in
5. used in
Used Selection
Projection
Operation.
Operation.

Project
Select operator
Operator operator is
6. is denoted by
Symbol denoted by Pi
Sigma symbol.
symbol.
S.
No. Category Selection Projection
Projection is
Selection is
7. Commutative not
commutative.
commutative.

Select is used Project is used

Column to select all to select
8.
Selection columns of a specific
specific tuple. columns.

SQL
SELECT, SELECT,
9. Statements
FROM, WHERE FROM
used

Q:3:
Explain Union, intersection and minus operation with examples.
 Ans:

Q:4 Explain the different Relational Model Constraints on databases;

Ans:
In the relational database model, constraints are rules or conditions that are
applied to the data in a database to ensure data integrity, consistency, and
accuracy. These constraints help maintain the quality and reliability of the data
stored in the database. There are several types of constraints in the relational
model:

1. Entity Integrity Constraint:

 Primary Key Constraint:
  Ensures that each row in a table is uniquely identifiable by
specifying one or more attributes (columns) as a primary key.
 A primary key must contain unique values and cannot contain
NULL values.
 Example: In a "Students" table, the "StudentID" column can be
designated as the primary key.
2. Referential Integrity Constraints:
 Foreign Key Constraint:
 Ensures that relationships between tables are maintained.
 Specifies that values in one table's foreign key column must match
the values in another table's primary key column.
 Helps maintain consistency in data relationships.
 Example: In a "Orders" table, the "CustomerID" column can be a
foreign key referencing the "CustomerID" primary key in the
"Customers" table.
3. Domain Constraints:
 Check Constraint:
 Defines a condition that values in a column must meet.
 Restricts the range of allowable data for a column.
 Example: In an "Employees" table, a check constraint might ensure
that the "Salary" column contains only positive values.
4. Key Constraints:
 Unique Constraint:
 Ensures that values in a column or combination of columns are
unique within the table.
 Unlike the primary key, unique constraints allow NULL values.
 Example: Ensuring that email addresses in a "Users" table are
unique.
5. Integrity Constraints:
 Not Null Constraint:
 Specifies that a column cannot contain NULL values.
 Ensures that essential data is always provided.
 Example: In a "Product" table, the "ProductName" column cannot
be NULL.
6. Referential Actions:
  Cascade:
 Specifies that when a referenced record (in the parent table) is
deleted or updated, the corresponding records in the dependent
table (child table) should also be deleted or updated.
 Set Null:
 Specifies that when a referenced record is deleted or updated, the
foreign key columns in the dependent table should be set to
NULL.
 Set Default:
 Specifies that when a referenced record is deleted or updated, the
foreign key columns in the dependent table should be set to their
default values.
 No Action:
 Specifies that no automatic action should be taken when a
referenced record is deleted or updated. It's up to the user or
application to ensure referential integrity.

These constraints play a crucial role in maintaining data quality, enforcing

business rules, and preventing data anomalies in a relational database. By
adhering to these constraints, you can ensure that the data in your database
remains accurate, consistent, and reliable.

Q:5Explain different Relational Algebra Operations from Set Theory;

Ans:
1. Selection (σ - Sigma):
 Selection is used to retrieve rows from a relation (table) that satisfy a specified condition or predicate.
 It is similar to the WHERE clause in SQL.
 Syntax: σ<condition>(relation)
2. Projection (π - Pi):
 Projection is used to extract specific columns (attributes) from a relation while eliminating duplicate rows.
 It is similar to the SELECT clause in SQL.
 Syntax: π<attribute1, attribute2, ...>(relation)
3. Union (∪ - Union):
 Union combines the rows from two relations into a single result, removing duplicates.
 It is similar to the UNION operator in SQL.
 Syntax: relation1 ∪ relation2
4. Intersection (∩ - Intersection):
 Intersection returns the common rows that exist in both relations.
 It is similar to the INTERSECT operator in SQL.
 Syntax: relation1 ∩ relation2Students ∩ Alumni
5. Difference (- - Minus/Except):
  Difference returns the rows that are present in the first relation but not in the second relation.
 It is similar to the MINUS or EXCEPT operator in SQL.
 Syntax: relation1 - relation2
6. Cartesian Product (× - Cross Product):
 Cartesian product combines all possible pairs of rows from two relations, resulting in a new relation with many rows.
 It is similar to the Cartesian product operation in set theory.
 Syntax: relation1 × relation2

Q:6: What is binary relational operation? Explain different variation of join in Relational Algebra with
example

Ans:
A binary relational operation in relational algebra is an operation that takes two relations (tables) as input
and produces a new relation as its result. One of the most commonly used binary operations in relational
algebra is the "JOIN" operation. The JOIN operation combines rows from two relations based on a
specified condition, creating a new relation that represents the combined data. There are several
variations of the JOIN operation in relational algebra, including INNER JOIN, LEFT JOIN, RIGHT JOIN,
and FULL JOIN. Let's explain each variation with examples:

Assuming two relations:

- `Students` with columns: StudentID, FirstName, LastName

- `Courses` with columns: CourseID, CourseName, StudentID

1. **INNER JOIN**:

- An INNER JOIN returns rows from both relations where the specified condition is met.

- Rows that do not satisfy the condition are excluded from the result.

- Syntax: `relation1 ⨝condition relation2`

Example:

```

Students ⨝ Students.StudentID = Courses.StudentID Courses

```

This INNER JOIN combines the "Students" and "Courses" relations based on the "StudentID" column,
returning only rows where there is a match in both relations.

2. **LEFT JOIN (or LEFT OUTER JOIN)**:

 - A LEFT JOIN returns all rows from the left (first) relation and the matching rows from the right (second)
relation.

- If there is no match in the right relation, NULL values are returned for columns from the right relation.

- Syntax: `relation1 ⟕condition relation2`

Example:

```

Students ⟕ Students.StudentID = Courses.StudentID Courses

```

This LEFT JOIN returns all rows from the "Students" relation and matching rows from the "Courses"
relation. If a student is not enrolled in any course, NULL values will be present in the columns from the
"Courses" relation.

3. **RIGHT JOIN (or RIGHT OUTER JOIN)**:

- A RIGHT JOIN is similar to a LEFT JOIN but returns all rows from the right (second) relation and the
matching rows from the left (first) relation.

- If there is no match in the left relation, NULL values are returned for columns from the left relation.

- Syntax: `relation1 ⟖condition relation2`

Example:

```

Students ⟖ Students.StudentID = Courses.StudentID Courses

```

This RIGHT JOIN returns all rows from the "Courses" relation and matching rows from the "Students"
relation. If a course has no enrolled students, NULL values will be present in the columns from the
"Students" relation.

4. **FULL JOIN (or FULL OUTER JOIN)**:

- A FULL JOIN returns all rows when there is a match in either the left or right relation.

- If there is no match in one of the relations, NULL values are returned for columns from the non-
matching relation.

- Syntax: `relation1 ⟗condition relation2`

 Example:

```

Students ⟗ Students.StudentID = Courses.StudentID Courses

```

This FULL JOIN returns all rows from both the "Students" and "Courses" relations. If a student is not
enrolled in any course or a course has no enrolled students, NULL values will be present in the respective
columns.

Q:7 Explain insert, delete and update operations with example.

Ans:
In a relational database management system (RDBMS), you can perform data manipulation using the
INSERT, DELETE, and UPDATE operations. These operations are essential for adding, removing, and
modifying data in database tables. Let's explain each operation with examples:

1. **INSERT Operation**:

The INSERT operation is used to add new rows (tuples) to a table in the database.

Syntax:

```

INSERT INTO table_name (column1, column2, ...) VALUES (value1, value2, ...);

```

Example:

Suppose you have a "Students" table with columns "StudentID," "FirstName," and "LastName," and you
want to insert a new student:

```sql

INSERT INTO Students (StudentID, FirstName, LastName) VALUES (101, 'John', 'Doe');

```

This command inserts a new row into the "Students" table with the specified values.
2. **DELETE Operation**:

The DELETE operation is used to remove one or more rows from a table based on a specified
condition.

Syntax:

```

DELETE FROM table_name WHERE condition;

```

Example:

To delete a student with a specific StudentID from the "Students" table:

```sql

DELETE FROM Students WHERE StudentID = 101;

```

This command deletes the row where the StudentID is equal to 101.

3. **UPDATE Operation**:

The UPDATE operation is used to modify existing data in one or more rows of a table based on a
specified condition.

Syntax:

```

UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition;

```

Example:

To update the last name of a student with a specific StudentID:

 ```sql

UPDATE Students SET LastName = 'Smith' WHERE StudentID = 101;

```

This command changes the last name of the student with StudentID 101 to "Smith."

Q:8 Explain in detail the relational integrity constraints.;

Ans:
1. **Entity Integrity Constraint**:

- **Primary Key Constraint**:

- Ensures that each row (tuple) in a table is uniquely identifiable.

- Requires that one or more columns (attributes) be designated as the primary key, and these columns
must contain unique and non-null values.

- Guarantees the uniqueness of rows in the table.

- Example: In a "Customers" table, the "CustomerID" column is typically the primary key.

2. **Referential Integrity Constraints**:

- **Foreign Key Constraint**:

- Ensures the consistency of relationships between tables.

- Specifies that values in one table's foreign key column must match the values in another table's
primary key column.

- Enforces referential integrity by preventing orphaned records.

- Example: In an "Orders" table, the "CustomerID" column can be a foreign key referencing the
"CustomerID" primary key in the "Customers" table.

3. **Domain Constraints**:

- **Check Constraint**:

- Defines conditions that data in a column must meet.

- Enforces constraints on the range or format of data values.

 - Helps ensure data accuracy and consistency.

- Example: In an "Employees" table, a check constraint might ensure that the "Salary" column contains
only positive values.

4. **Key Constraints**:

- **Unique Constraint**:

- Requires that values in a column or a combination of columns be unique within the table.

- Unlike primary keys, unique constraints allow null values.

- Helps maintain data quality by ensuring the uniqueness of certain attributes.

- Example: Ensuring that email addresses in a "Users" table are unique.

5. **Integrity Constraints**:

- **Not Null Constraint**:

- Specifies that a column cannot contain NULL values.

- Ensures that essential data is always provided.

- Helps prevent missing or incomplete information.

- Example: In a "Product" table, the "ProductName" column cannot be NULL.

6. **Referential Actions**:

- **Cascade**:

- Specifies that when a referenced record (in the parent table) is deleted or updated, the
corresponding records in the dependent table (child table) should also be deleted or updated.

- **Set Null**:

- Specifies that when a referenced record is deleted or updated, the foreign key columns in the
dependent table should be set to NULL.

- **Set Default**:

- Specifies that when a referenced record is deleted or updated, the foreign key columns in the
dependent table should be set to their default values.

- **No Action**:
 Q:9 Define Transaction. Discuss Transaction states with a neat diagram

Ans:

These are different types of Transaction States :

1. Active State –
When the instructions of the transaction are running then the transaction is in active state. If all the ‘read and write’ operations
are performed without any error then it goes to the “partially committed state”; if any instruction fails, it goes to the “failed
state”.

2. Partially Committed –
After completion of all the read and write operation the changes are made in main memory or local buffer. If the changes are
made permanent on the DataBase then the state will change to “committed state” and in case of failure it will go to the “fail ed
state”.

3. Failed State –
When any instruction of the transaction fails, it goes to the “failed state” or if failure occurs in making a permanent change of
data on Data Base.

4. Aborted State –
After having any type of failure the transaction goes from “failed state” to “aborted state” and since in previous states, th e
changes are only made to local buffer or main memory and hence these changes are deleted or rolled-back.

5. Committed State –
It is the state when the changes are made permanent on the Data Base and the transaction is complete and therefore
terminated in the “terminated state”.

6. Terminated State –
If there isn’t any roll-back or the transaction comes from the “committed state”, then the system is consistent and ready for new
transaction and the old transaction is terminated.

Q:10 Explain various types of failure that may occur in a system.

Ans:
 Transaction Failure:

If a transaction is not able to execute or it comes to a point from where the transaction becomes incapable of executing furt her
then it is termed as a failure in a transaction.
Reason for a transaction failure in DBMS:
1. Logical error: A logical error occurs if a transaction is unable to execute because of some mistakes in the code or due to the
presence of some internal faults.
2. System error: Where the termination of an active transaction is done by the database system itself du e to some system issue
or because the database management system is unable to proceed with the transaction. For example– The system ends an
operating transaction if it reaches a deadlock condition or if there is an unavailability of resources.

System Crash:

A system crash usually occurs when there is some sort of hardware or software breakdown. Some other problems which are
external to the system and cause the system to abruptly stop or eventually crash include failure of the transaction, operatin g
system errors, power cuts, main memory crash, etc.

Data-transfer Failure:

When a disk failure occurs amid data-transfer operation resulting in loss of content from disk storage then such failures are
categorized as data-transfer failures. Some other reason for disk failures includes disk head crash, disk unreachability, formation
of bad sectors, read-write errors on the disk, etc.
In order to quickly recover from a disk failure caused amid a data-transfer operation, the backup copy of the data stored on other
tapes or disks can be used. Thus it’s a good practice to backup your data frequently.

Q:11: Explain ACID properties of a transaction in detail (or) What the desirable properties of transaction
?

Ans:
Q:12 Explain the different phases of two phase locking protocol and how it is used to prevent lost
update problem and uncommitted transaction dependency problems.

Or
 Q:13Write a brief note on 2PL with examples.

Ans:
Two Phase Locking
A transaction is said to follow the Two-Phase Locking protocol if Locking and Unlocking can be done in two phases.

 Growing Phase: New locks on data items may be acquired but none can be released.
 Shrinking Phase: Existing locks may be released but no new locks can be acquired.
Note: If lock conversion is allowed, then upgrading of lock( from S(a) to X(a) ) is allowed in the Growing Phase, and downgrading
of lock (from X(a) to S(a)) must be done in the shrinking phase.
Let’s see a transaction implementing 2-PL.

T1 T2

1 lock-S(A)

2 lock-S(A)

3 lock-X(B)

4 ………. ……….

5 Unlock(A)

6 Lock-X(C)

7 Unlock(B)

8 Unlock(A)

9 Unlock(C)

10 ………. ……….

This is just a skeleton transaction that shows how unlocking and locking work with 2-PL. Note for:
Transaction T1
 The growing Phase is from steps 1-3
 The shrinking Phase is from steps 5-7
 Lock Point at 3
Transaction T2
 The growing Phase is from steps 2-6
 The shrinking Phase is from steps 8-9
 Lock Point at 6
Lock Point
The Point at which the growing phase ends, i.e., when a transaction takes the final lock it needs to carry on its work. Now look at
the schedule, you’ll surely understand. I have said that 2-PL ensures serializability, but there are still some drawbacks of 2-PL.
Let’s glance at the drawbacks.
 Cascading Rollback is possible under 2-PL.
 Deadlocks and Starvation are possible.
Cascading Rollbacks in 2-PL
Let’s see the following Schedule

Cascading Roll-Back

Take a moment to analyze the schedule. Yes, you’re correct, because of Dirty Read in T2 and T3 in lines 8 and 12 respectively,
when T1 failed we have to roll back others also. Hence, Cascading Rollbacks are possible in 2-PL. I have taken skeleton
schedules as examples because it’s easy to understand when it’s kept simple. When explained with real-time transaction
problems with many variables, it becomes very complex.
Deadlock in 2-PL
Consider this simple example, it will be easy to understand. Say we have two transactions T1 and T2.
Schedule: Lock-X1(A) Lock-X2 (B) Lock-X1 (B) Lock-X2(A)
Drawing the precedence graph, you may detect the loop. So Deadlock is also possible in 2-PL.
Two-phase locking may also limit the amount of concurrency that occurs in a schedule because a Transaction may not be able to
release an item after it has used it. This may be because of the protocols and other restrictions we may put on the schedule to
ensure serializability, deadlock freedom, and other factors. This is the price we have to pay to ensure serializability and other
factors, hence it can be considered as a bargain between concurrency and maintaining the ACID properties.
The above-mentioned type of 2-PL is called Basic 2PL. To sum it up it ensures Conflict Serializability but does not prevent
Cascading Rollback and Deadlock. Further, we will study three other types of 2PL, Strict 2PL, Conservative 2PL, and Rigorous
2PL.
Problem with Two-Phase Locking
 It does not insure recoverability which can be solved by strict two-phase locking and rigorous two-phase locking.
 It does not ensure a cascade-less schedule which can be solved by strict two-phase locking and rigorous two-phase locking.
 It may suffer from deadlock which can be solved by conservative two-phase locking.
GATE-Related Questions
1. GATE CS 2016-2 | Question 61
2. GATE CS 1999 | Question 31
Frequently Asked Questions
1. What is 2-Phase Locking Protocol?
Answer:
2-Phase Locking Protocol is a concurrency protocol that helps in serializability.
2. What are the types of the 2-Phase Locking Protocol?
Answer:
There are basically three types of 2-Phase Locking Protocol:
 Strict 2PL
 Conservative 2PL
 Rigorous 2PL

Q:14 Why concurrency control and recovery are needed in DBMS? Explain types of problems that may
occur when two simple transaction run concurrently with examples.
Ans:
Q:15 Write a short note on System log and commit point of transactions.
ans **System Log**:

A system log, often referred to as a transaction log or simply a log, is a critical component of database
management systems (DBMS). It serves as a record of all transactions and changes made to a database.
The primary purposes of a system log are as follows:

1. **Recovery**: The system log is crucial for database recovery in the event of a system failure, such as
a crash or power outage. It allows the DBMS to recreate the database's state up to the point of the
failure by replaying or undoing transactions recorded in the log.

2. **Durability**: The log ensures data durability, one of the ACID properties, by recording committed
transactions and their changes before confirming them as permanent in the database. This guarantees
that committed changes can be recovered even if the system crashes.

3. **Concurrency Control**: The log is used in conjunction with concurrency control mechanisms like
locking to track the order in which transactions acquire locks and make changes. It helps ensure that
transactions are executed in a serializable manner.

4. **Auditing and Monitoring**: The log can be used for auditing purposes to track who performed
what actions on the database. It can also aid in monitoring database activity and performance analysis.
**Commit Point of Transactions**:

The commit point of a transaction is a critical moment in the life cycle of a transaction when it is
considered complete and its changes become permanent in the database. It signifies that the
transaction has successfully executed and met the ACID properties. Here's how the commit point works:

1. **Transaction Execution**: During its execution, a transaction may perform various operations, such
as reading, updating, or inserting data into the database.

2. **Commit Request**: When a transaction intends to commit its changes, it sends a commit request
to the DBMS. This signals that the transaction has finished its work and is ready to make its changes
permanent.

3. **Logging**: Before confirming the commit, the DBMS records the transaction's changes in the
system log. This step is crucial for data durability and recovery. The log entry contains information about
the changes made by the transaction.

4. **Commit Confirmation**: Once the changes are safely logged, the DBMS confirms the commit,
making the changes permanent in the database. This is the commit point of the transaction.

5. **Release of Locks**: After successful commit, any locks held by the transaction are released,
allowing other transactions to access the affected data.

6. **Durability**: At this point, the changes are considered durable, meaning they will survive system
failures, crashes, or power outages. They are guaranteed to be in the database even if the system
encounters problems.