Solution

According to 2PL, if lock conversion is allowed, then upgrading of locks must be done during the expansion phase, and degrading of locks must be done in the shrinking phase. Hence, S₂ is true.

Lock upgradation is not allowed in the shrinking phase therefore S₁ is False.

Solution

The expression “σ _{age>20 AND age<30} (Person)” returns the persons whose age is above 20 and below 30.

Solution

Clustering index is created on data files whose file records are physically ordered on a non-key field which doesn’t have a distinct value for each record.

Solution

Given a query throws an error, because every column that is specified in the group by clause should also be present in the SELECT clause. Here dept_id which is there in GROUP BY clause is not present in select clause, therefore it throws an error.

Solution

Selection operator is used to filter rows and projection operator is used to filter columns.

Solution

Solution

BETWEEN, LIKE, IS NULL are not used between main query and subquery, only among given options EXIST can be used between main query & subquery.

Solution

Solution

An attribute whose value is computed from other attributes of the entity type is known as derived attribute

Solution

• For strong entities Student and Course 2 tables are required.
• The cardinality of the relationship “Enroll” is mamy-to-many. Hence, we need to create a separate table for Enroll.

Solution

When cardinality of the relationship is one-to-many, we need to create two separate tables for the entities. While creating the tables, the primary key of cardinality 1 side entity should be included into the entity of many sides.

Solution

The occurrences of relations are called instances. Hence, (15, RBR, 98) is an instance of a relation schema

Solution

• Selection operation is commutative that is,

σ _c1(σ _c2(R)) = σ _c2(σ _c1(R))

• The Project operation is not commutative, that is :

π _{Attribute List1}(π _{Attribute List2}(R)) != π_{Attribute List2}(π_{Attribute List1}(R))

Solution

In both conflict and view serializable schedules blind write may not appear every time. So, the answer is None of the above.

Solution

For example:

R(ABC), so A, B, C, AB, BC, AC, ABC = 7 = 2^3 – 1

It implies 2^n – 1 Super Keys.

Solution

When one transaction updates a database item and then the transaction fails for some reason, it is called Dirty Read problem or Transaction update problem.

Solution

Following are the default symbols which are used to represent different types of joins:

1. NATURAL JOIN - ⋈
2. LEFT OUTER JOIN - ⟕
3. RIGHT OUTER JOIN - ⟖
4. CARTESIAN PRODUCT – X

Solution

We can avoid cascading rollbacks in strict schedules. In these schedules, transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted). We know that strict 2PL and rigorous 2PL ensures strict schedules. Since, in strict 2PL, the transaction does not release any of its exclusive (write) locks until after it commits or aborts, and in rigorous 2PL, the transaction does not release any of its exclusive (write) locks or share (read) locks until after it commits or aborts.

Solution

Given relation R(A, B, C, D, E)

FD set: {A → BC, C → D, D → A}

Candidate keys for the given relation:{AE, DE, CE}

Total No. of super keys possible = Number of superkeys(AE) + number of super keys(DE) + Number of superkeys (CE) – Number of superkeys(ADE) – number of superkeys(CDE) – Number of superkeys(ACE) + Number of superkeys(ACDE)

Solution

• Candidate keys for R: {AC, AD}
• Prime attributes: {A, C, D}
• Non-prime attributes: {B, E}
• A ⟶ B is Partial dependency
• So, R is in 1NF

Solution

• I → 1, 10 will come if transactions are executed in order T1, T2, T3
• II → 2, 5 will come if transactions are executed in order T1, T3, T2
• III → 7, 0 will come if transactions are executed in order T3, T2, T1
• IV → 12, 0 will come if transactions are executed in order T3, T1, T2
• So, answer is (d)

Solution

The ORDER BY command sorts the result set in ascending order by default. Hence, all the queries are correct.

Solution

FETCH clause is used to limit the rows returned by a query. The OFFSET clause specifies the number of rows to skip before the row limiting starts.

Solution

1. (AF)+ = AFB. So, AF->DG is not implied.
2. (ACF)+ = ACFBDEG. Hence, ACF->DG is implied.
3. (AB)+ = AB. So, AB->G is not implied.

Hence, none of the given options are correct.

Solution

• The AC closure, (AC)+ =ACBD. Hence, the Candidate key is AC.
• The FDs, A->B and C->D are partial dependencies. Hence, R is not in 2NF.
• In the question, R(A, B, C, D) is decomposed into R1 (A, B) and R2(C, D) and there are only two FDs A -> B and C -> D. So, the decomposition is dependency preserving.
• In the question, R is decomposed into R1 (A, B) and R2(C, D), and R1 ∩ R2 is empty. So, the decomposition is not lossless.

Solution

• The attribute C is common in between the decomposed parts R1 and R2, and it is also a candidate key of R2. Hence, the decomposition is lossless.
• The dependency AB->C is not preserving on either R1 or R2. Hence, it is not dependency preserving

Solution

From the given instance, BC is uniquely identifying A values and B is uniquely identifying C values. Hence, BC->A and B->C are satisfying the given instance.

Solution

• The row sequence (1, 2) (2, 3) (3, 4) (4, 5) is wrong because, when we try to insert the tuple/row (1, 2) into the relation (A, B), it will through an error because attribute B is referring to attribute A and attribute A does not have the value 2. It will also throw an error when we try to insert the tuple/row (4,5) into the relation (A, B), because A does not has value 5.
  

• The row sequence (1, NULL) (2, NULL) (4, 3) (5, 4) is also wrong because, when we try to insert the tuple/row (4, 3) into the relation (A, B) it will through an error because attribute B having the value 3 is referring to attribute A and attribute A does not have the value 3.
• 
  

  The sequence (1, NULL) (2, 1) (3, 2) (4, 3) is correct as it does not throw any error while inserting tuples/rows into relation as it follows referential integrity constraint. For referential integrity to hold in relational database, any field in a table that is declared a foreign key can contain either a null value or only values from a parent table’s primary key or a candidate key.

Solution

Solution

∴ T1 commits before T3 commits.

Solution

Order = 24 * 0.69 = 16

Root (Level 0): 1 node 16 pointers 15 index records

Level 1: 16 16×16=256 pointers 16×15=240 index records

Level 2: 256 256×16=4096 pointers 256×15=3840 index records

Level 3: 4096 4096×16=65536 pointers 4096×15=61395 index records

Total index records = 65535

Solution

Solution

Delete 50:

The node contains more than min key then deletion of key do not require any modification.

Delete 40:

If the deletion of a key results in below the min no. then borrow the keys either from left sibling or right.

Delete 30:

If siblings do not have sufficient keys then borrow the key from the parent and merge with left sibling or right sibling.