Concepts of Database Management Chapter 7 Alexamara Marina Group Case

For the following exercises, you will address problems and answer questions from the Alexamara Marina Group staff. You do not use the Alexamara database for any of these exercises. 1. The log shown in Figure 7-19 on page 256 includes four transactions that completed successfully. For each of the four transactions, list the transaction ID and the table(s) modified. Also list whether the modification to the table added, changed, or deleted a record. ID 1 2 3 4 Tables Modified Service Request Marina, Marina Slip Owner, Marina Slip Marina Slip, Owner Modification Added Both Changed Both Changed Both Changed

2. Suppose a catastrophe destroys the database just after 11:10. Which transactions in the sample log shown in Figure 7-19 would the recovery program use to update the restored database? Which transactions would have to be reentered by users? Transactions 1 and 3 would remain intact as changes were committed before the catastrophe. Using the before and after images, one change from transaction 2 could be recovered, though most of the changes to transaction 2 would have to be re-entered, and transaction 4 had no changes made to it prior to the catastrophe. 3. If two of the four transactions shown in Figure 7-19 started at different times, deadlock could have occurred. Adjust the log to create deadlock between these two transactions. If you switch the start times of transactions 1 and 4, you create a deadlock between transactions 3 and 4 on the Owner table. I decided to only show the part of the log that is affected by the change. ID Time Action Record Update 4 11:00 Start 4 11:02 Update MarinaSlip (2) 3 11:03 Start 3 11:05 Update Owner (el25) 4 11:06 Update Owner (el25) 1 11:07 Start

4. Two of the five tables in the Alexamara database are defined as follows: Owner (OwnerNum, LastName, FirstName, Address, City, State, Zip) MarinaSlip (SlipID, MarinaNum, SlipNum, Length, RentalFee, BoatName, BoatType, OwnerNum) Suppose a user accesses the database via the following view: CREATE VIEW OwnerBoat AS SELECT Owner. OwnerNum, LastName, FirstName, BoatName FROM Owner, MarinaSlip WHERE Owner. OwnerNum= MarinaSlip. OwnerNum; Suppose further that the database requirements have changed so that a boat can have multiple owners, just as owners can have more than one boat. Whats the new database design for the Owner and MarinaSlip tables, as well as any other table(s) needed to satisfy the new requirements? Does the new database design affect the OwnerBoat view? If so, whats the new defining query for the view? While it would not be the easiest, it would be better to split up the Marina Slip table into: Boats (BoatNum, Boat Name, Type, Length) BoatOwners (BoatNum, OwnerNum) Marina Slip (SlipID, MarinaNum, SlipNum, RentalFee, BoatNum) Yes, the view would be affected; it would not pull up the second owner if a boat were to have one. CREATE VIEW OwnerBoat AS SELECT Owner.OwnerNum, Owner.LastName, Owner.FirstName, Boats.BoatName FROM Owner JOIN BoatOwners ON Owner.OwnerNum = BoatOwners.OwnerNum JOIN Boats ON BoatOwners.BoatNum = Boats.BoatNum;