Scribd
Upload
108 views

BD2 Text and Sol Draft

1. The document describes a database for a bike sharing service with tables for bikes, users, pickup requests, returns, and rentals. It outlines rules for pickup requests, returns, and charging users. 2. Triggers are designed to implement the rules for pickup requests, returns, and charging users. The triggers check for active rentals on pickup, update bikes and rentals on return, and charge users based on rental duration and bike costs. 3. The log of a distributed transactional system is analyzed to show the behavior of the warm restart protocol. Transactions are identified for undo and redo based on prepare, commit, and abort records in the log.

Uploaded by

SaladSlayer
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
108 views

BD2 Text and Sol Draft

1. The document describes a database for a bike sharing service with tables for bikes, users, pickup requests, returns, and rentals. It outlines rules for pickup requests, returns, and charging users. 2. Triggers are designed to implement the rules for pickup requests, returns, and charging users. The triggers check for active rentals on pickup, update bikes and rentals on return, and charge users based on rental duration and bike costs. 3. The log of a distributed transactional system is analyzed to show the behavior of the warm restart protocol. Transactions are identified for undo and redo based on prepare, commit, and abort records in the log.

Uploaded by

SaladSlayer
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
You are on page 1/ 4

DATA BASES 2 – SEPTEMBER 11TH, 2019 – DURATION: 2H 15M

PROF. SARA COMAI, PROF. DANIELE M. BRAGA


A. Active Databases (10 p.)
Consider the following database for a bike-sharing service (some data are replicated to simplify triggers/queries). Each
rental requires a pick up request and a return operation, identified by the same RentalID.
BIKE (BikeNumber, Type, CostPerHour, CurrentStationID)
USER (UserID, Name, Address, ChargedAmount)
PICKUPREQUEST (RentalID, UserID, BikeNumber, PickUpStationID)
RETURN (RentalID, BikeNumber, ReturnStationID)
RENTAL (RentalID, UserID, BikeNumber, StartingTimeStamp, ReturnTimeStamp)
A) Users can pick up bikes at any station, but they can have at most 3 active rentals at the same time. If a bike request
violates this rule, an application error is reported. Otherwise, the rental starts: a new record is inserted into the RENTAL
table with the pickup data and the CurrentStationID for that bike is set to null. B) When the user returns the bike, the
RENTAL record is completed with the restitution timestamp; also the CurrentStationID of the bike is updated. C) The
current amount of the user is decreased for the hours of use, according to the cost per hour of the rented bicycle. However,
if the bicycle presents some problems and is replaced in the same station within 3 minutes, no charges apply.
Design a set of triggers implementing the above rules. Suppose the existence of a function INT Difference(TS Time1, TS
Time2) returning the number of minutes between two timestamps. SYSDATE() returns the current timestamp.

B. Reliability Control of Distributed Systems (5 p.)


Given the following log found on a node of a distributed transactional system (with the following abbreviations for the
records relative to the distributed recovery protocol: p = prepare; r = ready; lc: local commit; la: local abort):
Dump, b(t1), u(t1,o1,a1,b1), d(t1,o2,b2), b(t2), b(t3), r(t1), i(t3,o3,a3), c(t3), ckpt(t1,t2), b(t4), b(t5), b(t6),
u(t4,o4,a4,b4), p(t4), la(t1), u(t2,o2,b5,a5), r(t2), lc(t2), c(t4), i(t5,o6,a6), d(t6,o6,b6), r(t5), failure
show the behavior of the warm restart protocol, knowing that the global decision returned by the TM is “commit”.

C. XML (9 p.)
<!ELEMENT Kindergarten ( Dish+, Child+ )>
<!ELEMENT Dish ( Name, Ingredient+, EthicalIndications, NutritionFacts … )>
<!ELEMENT Child ( Name, BirthDate, EatenFood*, Classroom… )>
<!ELEMENT EatenFood ( Ingredient, DateOfFirstIngestion )>
The DTD above describes the composition of the dishes served to the youngest babies in the nursery of a kindergarten and
the list of the ingredients that each baby has already eaten at least once at home, based on its parents’ indications. The
purpose of this data structure is to avoid that a baby eats any food for the first time at school rather than under parental
supervision. Unspecified elements only contain PCData or are immaterial to the assignment. Extract in XQuery:
(3 p.) 1. The baby who tasted broccoli at the youngest age (expressed in days). For readability and simplicity of notation, an
expression like xf:get-days-from-dayTimeDuration(op:subtract-dates(xs:date($d1),xs:date($d2))) can be implied by a simple $d1 – $d2 .
(6 p.) 2. For each dish in the menu, list the names of the children who are not allowed to eat it (yet).

D. Physical Databases (6 p.)


A table T (IDT, A, B, J, C) stores 2M tuples on 125K blocks in a primary B+ select * i/o ops
tree built on attribute J, with 3 levels and average F=50. A table S (IDS, X, Y, from T natural join S
J, Z) has 1.5M tuples in 75K blocks in a storage sequentially ordered by where A between a1 and a2
attribute J. There are also a B+ index on T built on attribute A (4 levels, 50K and Z <> 42 σ
leaf nodes) and a hash index built on J for table S, with no overflow chains.
We know that val(A)=val(Z)=10K, that J is unique in S, and that the interval condition on A has a selectivity equal to σ (a
parameter that depends on a1 and a2). Consider the following two query plans for the query boxed above:
p1) merge scan the two primary storages
p2) access the relevant tuples of T via the B+ secondary index (built on A) and perform a lookup on S via the hash index.
Plot on a Cartesian plane the cost of the two plans as functions of σ varying in [0%,100%] and indicate which plan is the
best for each σ. Approximate plots are OK, if readable enough to identify break-evens and the better plan in each case.
SOLUTIONS
A

CREATE TRIGGER RequestPickUpFailure


AFTER INSERT ON PICKUPREQUEST
FOR EACH ROW
WHEN (SELECT count(*)
FROM RENTAL WHERE UserID=new.UserID and ReturnTimeStamp IS NULL) >= 3 //not yet returned
BEGIN
Raise_application_error(-1000, “Too many requests”);
END;

Remark: it could be specified also as a BEFORE TRIGGER. In such a case the WHEN condition can be omitted in the next
trigger. In the above case the row is inserted in the table, otherwise no data are stored for invalid requests. The choice
depends on the application requirements.
It could be combined also with the next trigger, using an IF command.

CREATE TRIGGER RequestPickUp // possibly in a single trigger with an IF clause


A FTER INSERT ON PICKUPREQUEST
FOR EACH ROW
WHEN (SELECT count(*)
FROM RENTAL WHERE UserID=new.UserID and ReturnTimeStamp IS NULL) < 3
BEGIN
INSERT INTO RENTAL (new.RentalID, new.UserID, new.BikeNumber, Sysdate(), NULL);
UPDATE BIKE
SET CurrentStationID=”NULL”
WHERE BikeNumber = new.BikeNumber;
END;

CREATE TRIGGER RequestPickUp


AFTER INSERT ON RETURN
FOR EACH ROW
BEGIN
UPDATE RENTAL
SET ReturnTimeStamp=SYSDATE()
WHERE RentalID =new. RentalID;
UPDATE BIKE
SET CurrentStationID=new.ReturnStationID
WHERE BikeNumber=new.BikeNumber;
END;

CREATE TRIGGER RequestPickUp


AFTER UPDATE OF ReturnTimeStamp ON RENTAL
FOR EACH ROW
WHEN not (new.PickupStationID=new.ReturnStationID AND //in alternative apply De Morgan
Difference(new.ReturnTimeStamp, new.StartingTimeStamp)<4)
BEGIN
UPDATE USER
SET ChargedAmount = ChargedAmount - Difference(new.ReturnTimeStamp, new.StartingTimeStamp) *
(SELECT CostPerHour FROM BIKE WHERE BikeNumber=new.BikeNumber));
WHERE UserID=new.UserID;
END;

Dump, b(t1), u(t1,o1,a1,b1), d(t1,o2,b2), b(t2), b(t3), r(t1), i(t3,o3,a3), c(t3), ckpt(t1,t2), b(t4), b(t5), b(t6),
u(t4,o4,a4,b4), p(t4), la(t1), u(t2,o2,b5,a5), r(t2), lc(t2), c(t4), i(t5,o6,a6), d(t6,o6,b6), r(t5), failure

Step 1: go back to the last checkpoint ckpt(t1,t2)


UNDO={ t1,t2 } REDO={ }

Step 2: update UNDO/REDO according to the begin/commit/abort commands after the checkpoint
b(t4), b(t5), b(t6)  These three transactions need to be UNDONE UNDO={ t1,t2,t4,t5,t6 } REDO={ }
la(t1)  t1 remains in the UNDONE set
r(t2)  t2 is inserted in the READY set UNDO={ t1,t4,t5,t6 } REDO={ } READY={ t2 }
lc(t2)  t2 needs to be REDONE UNDO={ t1,t4,t5,t6 } REDO={ t2 } READY={ }
c(t4)  t4 needs to be REDONE UNDO={ t1,t5,t6 } REDO={ t2,t4 } READY={ }
r(t5)  t5 is inserted in the READY set UNDO={ t1,t6 } REDO={ t2,t4 } READY={ t5 }

t5 is in doubt – it will receive a COMMIT answer from the TM, so it needs to be REDONE
UNDO={ t1,t6 } REDO={ t2,t4,t5 }
Notice that t3 commited before the CKPT and therefore does not need to be redone/undone

Step 3: Perform UNDO (backward) and then REDO (forward)

UNDO: operations in the log to be undone u(t1,o1,a1,b1), d(t1,o2,b2), d(t6,o6,b6) 


Insert(o6,b6)
Insert (o2,b2)
Update (o1,b1)

REDO: operations in the log to be redone u(t4,o4,a4,b4), u(t2,o2,b5,a5), i(t5,o6,a6) 


Update(o4,a4)
Update(o2,a5)
Insert(o6,a6)

LET $MinDays := min (FOR $c IN doc(..)/Kindergarten/Child


LET $d := $c/EatenFood[Ingredient=”broccoli”]/DateOfFirstIngestion
WHERE count($d) > 0
RETURN {$d - $c/Birthdate})
FOR $c IN doc(..)/Kindergarten/Child
LET $d := $c/EatenFood[Ingredient=”broccoli”]/DateOfFirstIngestion
WHERE count($d) > 0 and ($d - $c/Birthdate)=$MinDaysn
RETURN <BROCCOLIEXPERT>{$c/Name, $c/BirthDate, $MinDays}</ BROCCOLIEXPERT>

FOR $d in doc(..)/Kindergarten/Dish
LET $i := $d/Ingredient
RETURN
<DISH> {$d/name/text()} </DISH>
<LISTCHILDRENNOTALLOWED>
{FOR $c in doc(..)/Kindergarten/Child
WHERE count($i) <> count (FOR $j in $i RETURN $c/EatenFood[Ingredient=$j])
RETURN <CHILD>{$c/name}</CHILD>}
</LISTCHILDRENNOTALLOWED>
D
The merge-scan apploach is trivially linear in the size of the joined tables and constant w.r.t. the value of σ:
p1: 125K + 75K = 200K

p2: The minimum cost (if σ = 0%) is 4 (a simple descent in the B+ index).
Otherwise the tuples in the interval are 2M ∙ σ
4 + blocks in the index + #ofTuples ∙ ( 1 the pointer + 1 the lookup + 1 the block of S ) =
4 + 2M ∙ σ / ( 2M / 50K ) + 2M ∙ σ ∙ 3 = 4 + σ ∙ ( 50K + 6M ) ~= σ ∙ 6.05 M
One break even for σ = 30,25 %

You might also like