CSE594
Database Management Systems
Fall 1999
Learning Experience #33 (AKA Final Exam)
"Our life is frittered away by detail ... Simplify, simplify."
- Henry David Thoreau, on physical data independence
As stated earlier, you may use one sheet of paper (8.5" by 11") with anything written on it. If you have a question or need more paper, please raise your hand. You may use the backs of these sheets if necessary, but please clearly indicate where you answers reside. Read each question carefully and state any assumptions you make. Your answers, as always, should be clear, concise, and thorough. Good luck!
You may unstaple these sheets if you like.
class
Clothing inherit object public typetuple (color: string,
size: real)
end;
class Pants inherit Clothing public type
tuple (style: string,
goes_with: unique set (Shirt))
end;
class Shirt inherit Clothing public type
tuple (num_buttons: integer)
end;
/* Assume ‘init’ methods for Pants, Shirt that maintain the following extents */
name PantsExtent: unique set (Pants);
name ShirtExtent: unique set (Shirt);
Translate this O2 database into a relational database. You may wish to add identifier fields to serve as primary keys. Indicate all key constraints, foreign and primary.
Consider a relational database with information about students, classes, and computers. Each student is enrolled in 0 or more classes, each machine is assigned to 0 or more classes, and each student has an account for each class in which he or she is enrolled. Here is the schema:
Class (cno, title, mno)
Machine (mno, mname, manager)
Student (sno, name, year, phone)
HasAcct (sno, mno, login)
Enroll (cno, sno)
"Mno" always represents a machine number, "cno" a class number, etc. The "manager" field is the name of the manager. You should assume that student names are unique and that all managers are also students.
In English, what does the following query do, when run on the database from Question I?
from S in ShirtExtent
where not (S in (flatten (select P.goes_with
from P in PantsExtent)))
Recall that most relational optimizers only examine left-deep join execution plans and not bushy join execution plans ("bushy" here means anything that’s not either left-deep or right-deep). Give an example of a natural join of 4 relations A(a1, a2, b1), B(b1, b2, c1), C(c1, c2, d1), and D(d1, d2, d3) in which a bushy join execution plan would be better than any of the available linear (left-deep or right-deep) plans. Relevant information to include in your answer includes relation sizes (in pages), reduction factors, etc. Assume that no indexes are available, pipelining is available, and only the page-oriented nested-loops join method is being used. Assume that for this particular natural join, duplicate columns are not removed. There are no operations in this query other than the joins. Explain your answer and be specific.
T0 |
T1 |
READ (A) |
READ (B) |
READ (B) |
READ (A) |
IF A = 0 THEN B := B + 1 |
IF B = 0 THEN A := A + 1 |
WRITE (B) |
WRITE (A) |
The initial values are A = B = 0 and the consistency requirement in the database is
((A = 0) OR (B = 0)).
You wrote code at the File Manager and Relational Operator layers of the Minibase system.
What does ARIES (as in the recovery algorithm) stand for?
"It is also hoped that this paper can contribute to greater precision in work on formatted data systems."
- E.F. Codd, 1970