Skip to content

Commit

Permalink
Update Chapter 3 - Solutions.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@Nivedita123
Nivedita123 authored Nov 30, 2018
1 parent 974eefe commit 6b89605
Showing 1 changed file with 252 additions and 0 deletions.
252 changes: 252 additions & 0 deletions Chapter 3 - Solutions.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,30 @@ Define the following terms: relation schema, relational database schema, domain,

### `Answer`

A relation schema can be thought of as the basic information describing
a table or relation. This includes a set of column names, the data types associated
with each column, and the name associated with the entire table. For example, a
relation schema for the relation called Students could be expressed using the following
representation:

Students(sid: string, name: string, login: string,
age: integer, gpa: real)

There are five fields or columns, with names and types as shown above.

A relational database schema is a collection of relation schemas, describing one or more
relations.

Domain is synonymous with data type. Attributes can be thought of as columns in a
table. Therefore, an attribute domain refers to the data type associated with a column.

A relation instance is a set of tuples (also known as rows or records) that each conform
to the schema of the relation.

The relation cardinality is the number of tuples in the relation.

The relation degree is the number of fields (or columns) in the relation.

***
### Exercise 3.2
How many distinct tuples are in a relation instance with cardinality 22?
Expand All @@ -16,6 +40,11 @@ How many distinct tuples are in a relation instance with cardinality 22?
Does the relational model, as seen by an SQL query writer, provide physical and logical data independence? Explain.

### `Answer`
The user of SQL has no idea how the data is physically represented in the
machine. He or she relies entirely on the relation abstraction for querying. Physical
data independence is therefore assured. Since a user can define views, logical data
independence can also be achieved by using view definitions to hide changes in the
conceptual schema.

***
### Exercise 3.4
Expand All @@ -32,6 +61,17 @@ Consider the instance of the Students relation shown in Figure 3.1.

### `Answer`

Examples of non-candidate keys include the following: {name}, {age}.
(Note that {gpa} can not be declared as a non-candidate key from this evidence alone
even though common sense tells us that clearly more than one student could have the
same grade point average.)
You cannot determine a key of a relation given only one instance of the relation. The
fact that the instance is “legal” is immaterial. A candidate key, as defined here, is a
key, not something that only might be a key. The instance shown is just one possible
“snapshot” of the relation. At other times, the same relation may have an instance (or
snapshot) that contains a totally different set of tuples, and we cannot make predictions
about those instances based only upon the instance that we are given.

***
### Exercise 3.6
What is a foreign key constraint? Why are such constraints important? What is referential integrity?
Expand All @@ -46,6 +86,19 @@ Consider the relations Students, Faculty, Courses, Rooms, Enrolled, Teaches, and

### `Answer`

There is no reason for a foreign key constraint (FKC) on the Students,
Faculty, Courses, or Rooms relations. These are the most basic relations and must be
free-standing. Special care must be given to entering data into these base relations.
In the Enrolled relation, sid and cid should both have FKCs placed on them. (Real
students must be enrolled in real courses.) Also, since real teachers must teach real
courses, both the f id and the cid fields in the Teaches relation should have FKCs.
Finally, Meets In should place FKCs on both the cid and rno fields.
It would probably be wise to enforce a few other constraints on this DBMS: the length
of sid, cid, and f id could be standardized; checksums could be added to these identification
numbers; limits could be placed on the size of the numbers entered into the
credits, capacity, and salary fields; an enumerated type should be assigned to the grade
field (preventing a student from receiving a grade of G, among other things); etc.

***
### Exercise 3.8
Answer each of the following questions briefly. The questions are based On the following relational schema:
Expand All @@ -70,6 +123,14 @@ Consider the SQL query whose answer is shown in Figure 3.6.

### `Answer`

1. Only login is included in the answer:

SELECT S.login
FROM Students S
WHERE S.age < 18

2. The answer tuple for Madayan is omitted then.

***
### Exercise 3.10
Explain why the addition of NOT NULL constraints to the SQL definition of the Manages relation (in Section 3.5.3) would not enforce the constraint that each department must have a manager. What, if anything, is achieved by requiring that the S8n field of Manages be non-null?
Expand All @@ -85,6 +146,25 @@ you cannot capture some constraint, explain why.

### `Answer`

The following SQL statements create the corresponding relations.
CREATE TABLE A ( a1 CHAR(10),
a2 CHAR(10),
b1 CHAR(10),
c1 CHAR(10),
PRIMARY KEY (a1),
UNIQUE (b1),
FOREIGN KEY (b1) REFERENCES B,
FOREIGN KEY (c1) REFERENCES C )
CREATE TABLE B ( b1 CHAR(10),
b2 CHAR(10),
PRIMARY KEY (b1) )
CREATE TABLE C ( b1 CHAR(10),
c2 CHAR(10),
PRIMARY KEY (c1) )

The first SQL statement folds the relationship R into table A and thereby guarantees
the participation constraint.

***
### Exercise 3.12
Consider the scenario from Exercise 2.2, where you designed an ER diagram for a university database. Write SQL statements to create the corresponding relations and capture as many of the constraints as possible. If you cannot, capture some constraints, explain
Expand All @@ -98,6 +178,72 @@ Consider the university database from Exercise 2.3 and the ER diagram you design

### `Answer`

The following SQL statements create the corresponding relations.
1. CREATE TABLE Professors ( prof ssn CHAR(10),
name CHAR(64),
age INTEGER,
rank INTEGER,
speciality CHAR(64),
PRIMARY KEY (prof ssn) )
2. CREATE TABLE Depts ( dno INTEGER,
dname CHAR(64),
office CHAR(10),
PRIMARY KEY (dno) )
3. CREATE TABLE Runs ( dno INTEGER,
prof ssn CHAR(10),
PRIMARY KEY ( dno, prof ssn),
FOREIGN KEY (prof ssn) REFERENCES Professors,
FOREIGN KEY (dno) REFERENCES Depts )
4. CREATE TABLE Work Dept ( dno INTEGER,
prof ssn CHAR(10),
pc time INTEGER,
PRIMARY KEY (dno, prof ssn),
FOREIGN KEY (prof ssn) REFERENCES Professors,
FOREIGN KEY (dno) REFERENCES Depts )
Observe that we would need check constraints or assertions in SQL to enforce the
rule that Professors work in at least one department.
5. CREATE TABLE Project ( pid INTEGER,
sponsor CHAR(32),
start date DATE,
end date DATE,
budget FLOAT,
PRIMARY KEY (pid) )
6. CREATE TABLE Graduates ( grad ssn CHAR(10),
age INTEGER,
name CHAR(64),
deg prog CHAR(32),
major INTEGER,
PRIMARY KEY (grad ssn),
FOREIGN KEY (major) REFERENCES Depts )
Note that the Major table is not necessary since each Graduate has only one major
and so this can be an attribute in the Graduates table.
7. CREATE TABLE Advisor ( senior ssn CHAR(10),
grad ssn CHAR(10),
PRIMARY KEY (senior ssn, grad ssn),
FOREIGN KEY (senior ssn)
REFERENCES Graduates (grad ssn),
FOREIGN KEY (grad ssn) REFERENCES Graduates )
8. CREATE TABLE Manages ( pid INTEGER,
prof ssn CHAR(10),
PRIMARY KEY (pid, prof ssn),
FOREIGN KEY (prof ssn) REFERENCES Professors,
FOREIGN KEY (pid) REFERENCES Projects )
9. CREATE TABLE Work In ( pid INTEGER,
prof ssn CHAR(10),
PRIMARY KEY (pid, prof ssn),
FOREIGN KEY (prof ssn) REFERENCES Professors,
FOREIGN KEY (pid) REFERENCES Projects )
Observe that we cannot enforce the participation constraint for Projects in the
Work In table without check constraints or assertions in SQL.
CREATE TABLE Supervises ( prof ssn CHAR(10),
grad ssn CHAR(10),
pid INTEGER,
PRIMARY KEY (prof ssn, grad ssn, pid),
FOREIGN KEY (prof ssn) REFERENCES Professors,
FOREIGN KEY (grad ssn) REFERENCES Graduates,
FOREIGN KEY (pid) REFERENCES Projects )
Note that we do not need an explicit table for the Work Proj relation since every
time a Graduate works on a Project, he or she must have a Supervisor.
***
### Exercise 3.14
Consider the scenario from Exercise 2.4, where you designed am ER diagram for a company database. Write SQL statements to create the corresponding relations and capture as many of the constraints as possible. If you cannot capture some constraints, explain why.
Expand All @@ -111,6 +257,50 @@ the SQL statements and briefly explain why you could not express them.

### `Answer`

1. CREATE TABLE Musicians ( ssn CHAR(10),
name CHAR(30),
PRIMARY KEY (ssn))
2. CREATE TABLE Instruments ( instrId CHAR(10),
dname CHAR(30),
key CHAR(5),
PRIMARY KEY (instrId))
3. CREATE TABLE Plays ( ssn CHAR(10),
instrId INTEGER,
PRIMARY KEY (ssn, instrId),
FOREIGN KEY (ssn) REFERENCES Musicians,
FOREIGN KEY (instrId) REFERENCES Instruments )
4. CREATE TABLE Songs Appears ( songId INTEGER,
author CHAR(30),
title CHAR(30),
albumIdentifier INTEGER NOT NULL,
PRIMARY KEY (songId),
FOREIGN KEY (albumIdentifier)
References Album Producer,
5. CREATE TABLE Telephone Home ( phone CHAR(11),
address CHAR(30),
PRIMARY KEY (phone),
FOREIGN KEY (address) REFERENCES Place,
6. CREATE TABLE Lives ( ssn CHAR(10),
phone CHAR(11),
address CHAR(30),
PRIMARY KEY (ssn, address),
FOREIGN KEY (phone, address)
References Telephone Home,
FOREIGN KEY (ssn) REFERENCES Musicians )
7. CREATE TABLE Place ( address CHAR(30) )
8. CREATE TABLE Perform ( songId INTEGER,
ssn CHAR(10),
PRIMARY KEY (ssn, songId),
FOREIGN KEY (songId) REFERENCES Songs,
FOREIGN KEY (ssn) REFERENCES Musicians )
9. CREATE TABLE Album Producer ( albumIdentifier INTEGER,
ssn CHAR(10),
copyrightDate DATE,
speed INTEGER,
title CHAR(30),
PRIMARY KEY (albumIdentifier),
FOREIGN KEY (ssn) REFERENCES Musicians )

***
### Exercise 3.16
Translate your ER diagram from Exercise 2.6 into a relational schema, and show the SQL statements needed to create the relations, using only key and null constraints. If your translation cannot capture any constraints in the ER diagram, explain why.
Expand All @@ -125,6 +315,48 @@ Consider the ER diagram that you designed for the Prescriptions-R-X chain of pha

### `Answer`

The statements to create tables corresponding to entity sets Doctor,
Pharmacy, and Pharm co are straightforward and omitted. The other required tables
can be created as follows:
1. CREATE TABLE Pri Phy Patient ( ssn CHAR(11),
name CHAR(20),
age INTEGER,
address CHAR(20),
phy ssn CHAR(11),
PRIMARY KEY (ssn),
FOREIGN KEY (phy ssn) REFERENCES Doctor )
2. CREATE TABLE Prescription ( ssn CHAR(11),
phy ssn CHAR(11),
date CHAR(11),
quantity INTEGER,
trade name CHAR(20),
pharm id CHAR(11),
PRIMARY KEY (ssn, phy ssn),
FOREIGN KEY (ssn) REFERENCES Patient,
FOREIGN KEY (phy ssn) REFERENCES Doctor,
FOREIGN KEY (trade name, pharm id)
References Make Drug)
3. CREATE TABLE Make Drug (trade name CHAR(20),
pharm id CHAR(11),
PRIMARY KEY (trade name, pharm id),
FOREIGN KEY (trade name) REFERENCES Drug,
FOREIGN KEY (pharm id) REFERENCES Pharm co)
4. CREATE TABLE Sell ( price INTEGER,
name CHAR(10),
trade name CHAR(10),
PRIMARY KEY (name, trade name),
FOREIGN KEY (name) REFERENCES Pharmacy,
FOREIGN KEY (trade name) REFERENCES Drug)
5. CREATE TABLE Contract ( name CHAR(20),
pharm id CHAR(11),
start date CHAR(11),
end date CHAR(11),
text CHAR(10000),
supervisor CHAR(20),
PRIMARY KEY (name, pharm id),
FOREIGN KEY (name) REFERENCES Pharmacy,
FOREIGN KEY (pharm id) REFERENCES Pharm co)

***
### Exercise 3.18
Write SQL statements to create the corresponding relations to the ER diagram you designed for Exercise 2.8. If your translation cannot capture any constraints in the ER diagram, explain why.
Expand All @@ -151,6 +383,8 @@ WHERE S.salary > 100,000

### `Answer`



***
### Exercise 3.20
Consider the following schema:
Expand All @@ -166,4 +400,22 @@ The Catalog relation lists the prices charged for parts by Suppliers. Answer the

### `Answer`

1. The system will do the following:
SELECT S.name
FROM ( SELECT E.ename AS name, E.age, E.salary
FROM Emp E
WHERE E.age > 50 ) AS S
WHERE S.salary > 100000
2. The following view on Emp can be updated automatically by updating Emp:
CREATE VIEW SeniorEmp (eid, name, age, salary)
AS SELECT E.eid, E.ename, E.age, E.salary
FROM Emp E
WHERE E.age > 50
3. The following view cannot be updated automatically because it is not clear which
employee records will be affected by a given update:
CREATE VIEW AvgSalaryByAge (age, avgSalary)
AS SELECT E.eid, AVG (E.salary)
FROM Emp E
GROUP BY E.age

***

0 comments on commit 6b89605

Please sign in to comment.