About

Ranita works as an Assistant Professor at the Computer Science and Engineering Department at IIT Roorkee. She has completed her PhD from the Computer Science and Engineering Department at IIT Kharagpur. Before that, she has done her MTech from IIEST Shibpur, and got job offers from companies like Amazon, Samsung Labs etc. However, she preferred to pursue higher studies to stay in the field of academics and teaching. She believes in the motto of free education and contribution.

Role

Alma Mater:

PhD
IIT Kharagpur
2012 to 2016
Master of Engineering
Indian Institute of Engineering Science and Technology, Shibpur
2010 to 2012
Bachelor of Technology
Kalyani Government Engineering College
2005 to 2009

Experience:

Assistant Professor
Indian Institute of Technology Roorkee
2016
Project Linked Personnel
Indian Statistical Institute, Kolkata
2009 to 2010
Teacher
Answer
7 months 5 days ago

The correct answer is (b) remains same. To understand this, let us revise the informal algorithm for Timestamp based protocol for concurrency control (copied from Wikipedia, you can also refer to the formal version of the algorithm there):

1) If a transaction wants to read an object,

a) but the transaction started before the object's write timestamp it means that something changed the object's data after the transaction started. In this case, the transaction is canceled and must be restarted.
b) and the transaction started after the object's write timestamp, it means that it is safe to read the object. In this case, if the transaction timestamp is after the object's read timestamp, the read timestamp is set to the transaction timestamp.
2) If a transaction wants to write to an object,

a) but the transaction started before the object's read timestamp it means that something has had a look at the object, and we assume it took a copy of the object's data. So we can't write to the object as that would make any copied data invalid, so the transaction is aborted and must be restarted.
b) and the transaction started before the object's write timestamp it means that something has changed the object since we started our transaction. In this case, we use the Thomas write rule and simply skip our write operation and continue as normal; the transaction does not have to be aborted or restarted
c) otherwise, the transaction writes to the object, and the object's write timestamp is set to the transaction's timestamp.

Now consider the following example schedule:

T1      T2      T3      T4
                   R(A)
R(A)
                             R(A)
         W(A)

Consider that after the execution of the last R(A), T4 needs to rollback (as given in the question). So, RTS(A) was 4 and now we need to decide what should be the new RTS for A. Note that, the schedule at hand now is something like the following:

T1      T2      T3
                   R(A)
R(A)
         W(A)

Independent of T4, this schedule will have RTS(A) = 3 when T2 tries to write and hence T2 should be aborted by rule 2(a).

Now, after rollback of T4, consider option (a) i.e. changing the RTS(A) to 0. This will certainly allow W(A) by T2 to execute without any problem as it falls under rule 2(c) and hence violates concurrency by allowing T2 to write a data already read by T3.

Consider option (c) i.e. RTS(A) becomes equal to the timestamp of the transaction which read 'A' just before T4, in this example then RTS(A) becomes 1. And hence the same problem arises as choosing option (a).

Therefore, if we choose option (b) and keep the RTS(A) same as before i.e. 4, then W(A) by T2 will fall under rule 2(a) and hence will be aborted. So, option (b) is the correct answer.

This is why RTS is kept as the largest of the timestamps of the transactions which has read the data, and not the recent timestamp.

 
moreless
Teacher
Example text
8 months 3 weeks ago

This is an example of fan trap and chasm trap and how to resolve these scenarios. The following brief explanation may help you in understanding the concept which is usually found to be dubious across the web. This explanation is made in parity with the concept explained in Wikipedia (https://en.wikipedia.org/wiki/Entity–relationship_model#Model_usability_issues). You can also refer to https://db.grussell.org/section005.html to understand in detail.

moreless
Teacher
Example text
10 months 1 week ago

You are very close to the answer. But, there is one catch; the first row of pixels (at y = 0) and the last row of pixels (at y = 37) are not full length. You may try to modify the approach accordingly to get to the correct answer. Very good presentation, by the way.

moreless
Teacher
Example text
10 months 1 week ago

Consider the attribute set ABCDEG and the FD set
AB → C, AC → B, AD → E, B → D, BC → A, E → G
Is the following decomposition of R(ABCDEG)
(a) dependency-preserving?
(b) lossless-join?
1: AB, BC, ABDE, EG
2: ABC, ACDE, ADG
Give proper justification for your answer.

moreless
jayantachakr's picture
Jayanta Chakraborty
innovwelt's picture
Arul
arvind.rawat's picture
Arvind Rawat
pritam's picture
Pritam Prasun
techtud's picture
Techtud Admin
1
pritam's picture
Pritam Prasun
905
Rajeev
914
vivek14's picture
Vivek Vikram Singh
921
pashupati's picture
Pashupati Jha
922
priyesh's picture
Priyesh Priyatam
923
girraj's picture
GIRRAJ PAHARIYA
972
Himanshi
976
shreyans's picture
Shreyans Dhankhar
977
ribhu122's picture
Ribhu Ranjan
986
prafull's picture
Prafull Ranjan
1005
antonio's picture
Antonio Anastasio Bruto da Costa
1047
shabinmuhammed's picture
Shabin Muhammed
1065
shuvankarchakraborty's picture
SHUVANKAR CHAKRABORTY
1228

Pages

Suman, you are right. Separate table is needed for multi-valued attribute, but composite attribute does not necessarily need a separate table.

more less

Taken from wikipedia: "Starvation is similar to deadlock in that it causes a process to freeze. Two or more processes become deadlocked when each of them is doing nothing while waiting for a resource occupied by another program in the same set. On the other hand, a process is in starvation when it is waiting for a resource that is continuously given to other processes. Starvation-freedom is a stronger guarantee than the absence of deadlock: a mutual exclusion algorithm that must choose to let one of two processes into a critical section and picks one arbitrarily is deadlock-free, but not starvation-free."

Therefore, the situation described by you should be called deadlock. However, I am not sure about the active state and blocked state you are talking about. How are you deciding that after unsuccessful wait operation process goes into blocked state?

more less
2 Nov 2016 - 10:58am

For a relation to be in 3NF, in all FDs, left hand side should be a candidate key or right hand side should be a prime attribute. In the given relation, B is the only candidate key and C → D and C → A both violate the 3NF rule. So, we need to decompose it into R1(B, C) and R2(A, C, D). Now, candidate key for R2 is C; hence, both R1 and R2 are in 3NF. The decomposition is dependency preserving as well as lossless as intersection C can determine R2.

more less
26 Oct 2016 - 8:50pm

Yes, I understand now. It's actually called the chase algorithm (https://en.wikipedia.org/wiki/Chase_%28algorithm%29) which is used to check if a given decomposition is lossless or not.

So, let me try to solve the question; hope it will clear your doubt with the 'alpha' method you are using.
The given set of FDs for the relation R(ABCDEG) is: AB → C, AC → B, AD → E, B → D, BC → A, E → G. The decomposition to check is {R1(AB), R2(BC), R3(ABDE), R4(EG)}.
To form the initial table you will draw an n*m matrix where n is the number of decompositions (i.e. 4 here) and m is the number of attributes (i.e. 6 here). Now each attribute will get a proper value (attribute name alone) in a row if it exists in the corresponding decomposed table, otherwise we put a subscript of decomposed relation number with it.

The initial table will look like this:

Now, we apply the FDs to change the subscripted values for each row. So, as we have AB → C, we try to find out row pairs where AB has same values. Row 1 and Row 3 has same values in AB. So, their C value should also match and hence we change c3 to c1. There are no other pair of rows where AB value agrees. So, after applying AB → C, we get (changed value is shown in yellow background):

Our goal through applying this FDs is to reach a state where at least one row will contain all proper values (no subscripts), which will essentially mean that we are able to get back the original table R. So, in a same manner, applying B → D we get:

So, if we get a proper value for the RHS we will use that for replacing the other matching rows where same LHS is there. Moving forward,

Now, at this point, you can see that for all the FDs, if two rows have same values in the LHS attributes, they are having same values in the RHS attributes as well. And, none of the rows has all proper values in it. So, we are stuck and we cannot proceed any further. Hence, the given decomposition is not able to recover back the original table and it is lossy.

more less
26 Oct 2016 - 3:45pm

I am really not getting your question. What are you trying to achieve? What are these alphas? and how are they related with the functional dependency AB → C? I absolutely have no idea of some method like this. Can you please explain the problem in more detail?

more less

When there are multiple many sides in a more-than-binary relationship then all the many sides together only can determine the single sides. That's why Case 1 is PQ → ST which means {PQ → S, PQ → T}, but not necessarily {P → S, P → T, Q → S, Q → T}. Say, for example, the following should be a valid instance for the given ER diagram. But, as you can see here P ↛ S, P ↛ T, Q ↛ S, Q ↛ T.

P Q S T
P1 Q1 S1 T1
P1 Q2 S2 T2
P2 Q1 S2 T2
P2 Q2 S1 T1

 

more less

We know that cardinalty constraints on more-than-binary relationship with more than one arrow (1 sides) creates ambiguity in ER diagram. [For more info on this, please refer to the DBMS book by Korth]

The given ER diagram can mean any one of the following two cases:

Case 1: PQ → ST

Case 2: PQS → T and PQT → S

Now, going through the three instances, we can identify the FDs and non-FDs satisfied for the instances as follows:

Instance 1:
PQ ↛ T (so, case 1 isnot valid)
PQS ↛ T (so, case 2 is also not vaid)
So, the ER-diagram can NOT be a representation of Instance 1.

Instance 2:
PQ ↛ S and PQ ↛ T (so, case 1 is not valid)
However, PQS → T and PQT → S (so, case 2 is valid)
So, the ER-diagram can be a representation of Instance 2.

Instance 3:
PQ → S and PQ → T as well (so, case 1 is valid)
Validy of case 1 ensures validity of the FDs in case 2 as well.
So, the ER-diagram can also be a representation of Instance 3.

Therefore, correct answer is (A) I only.

more less

Column names in the resultant relation after union operation is usually taken as the column names of the first operand relation i.e. in this case it should be R3(a, b). However, it's a usual notion, and some compiler or version may differ.

more less

It's a tricky question. And, answer is indeed 0.

The given query is:

select S.name from Supplier S
   where not exists (select * from Catalog C
                               where S.sid = C.sid and exists (select count(*) from Parts where Partname = 'P5')
 

As there is no part with Partname = 'P5', "select count(*) from Parts where Partname = 'P5'" gives you 0, not 0 row, a single row, containing value 0. Now, as there is a row returned by it, "exists (select count(*) from Parts where Partname = 'P5')" gives you TRUE. So, our whole query basically turns out to be:

select S.name from Supplier S
   where not exists (select * from Catalog C
                               where S.sid = C.sid)

As you can see "select * from Catalog C where S.sid = C.sid" selects all the rows from Catalog table, "not exists(select * from Catalog C where S.sid = C.sid)" gives you FALSE.
Therefore, the final query returns 0 number of rows.

more less

Pages