);
CREATE TABLE StarsIn (
movieTitle VARCHAR(255), movieYear INTEGER, starName CHAR(30) );
CREATE TABLE MovieExec ( name CHAR(30),
address VARCHAR(255),
cert# INTEGER PRIMARY KEY, netWorth INTEGER );
CREATE TABLE Studio (
name CHAR(50) PRIMARY KEY, address VARCHAR(255), presC# INTEGER );
We have chosen not to add
PRIMARY KEY (movieTitle, movieYear, starName)
to the declaration of StarsIn, although we could. Since that relation is likely to be used for going between movies and stars or vice versa, we think an index, which the DBMS might create for us were we to declare a primary key, will be of no use and may waste time.
Exercise 7.1.2(a)
We may add to the declaration of attribute producerC# the clause: REFERENCES MovieExec(cert#)
No policy needs to be specified, because rejecting violating modifications is the default action.
Exercise 7.1.3
Nope. A foreign key must refer to the primary key in some relation. But movieTitle and movieYear are not a key for StarsIn, even though title and year are the key for Movie.
Exercise 7.1.6(a)
CREATE TABLE Ships ( name CHAR(30),
class CHAR(30) REFERENCES Classes(class), launched INTEGER );
In addition to the above declaration, class must be declared the primary key for Classes.
Solutions for Section 7.2
Exercise 7.2.1(a)
CREATE TABLE Movie ( ...
year INTEGER CHECK (year >= 1895), ... )
Exercise 7.2.1(c)
revised 6/26/03
CREATE TABLE Movie ( ...
studioName CHAR(30) CHECK (studioName IN ('Disney', 'Fox', 'MGM', 'Paramount')), ... )
Exerci