0% found this document useful (0 votes)
77 views

60-415 ASSIGNMENT # 1 Solution (Database Design, RA and SQL)

This document contains the solutions to various database design, relational algebra, and SQL questions. It includes: 1) The functional dependency diagram and normal forms for an INVOICE table. 2) Identifying update anomalies and normalizing a FastCabs database relation into third normal form. 3) Twenty SQL queries on the EMPLOYEES database including aggregation, subqueries, joins, set operations, and more.

Uploaded by

Utkarsh Yadav
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
77 views

60-415 ASSIGNMENT # 1 Solution (Database Design, RA and SQL)

This document contains the solutions to various database design, relational algebra, and SQL questions. It includes: 1) The functional dependency diagram and normal forms for an INVOICE table. 2) Identifying update anomalies and normalizing a FastCabs database relation into third normal form. 3) Twenty SQL queries on the EMPLOYEES database including aggregation, subqueries, joins, set operations, and more.

Uploaded by

Utkarsh Yadav
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

60-415 ASSIGNMENT # 1 Solution (Database design, RA and SQL )

1. Solution to Question 1 and 2 are with your GA (Naseer) . Please see him in his office hr
or email him to see the solution.

2. a. Using the following INVOICE table structure, draw its functional dependency
diagram and identify all dependencies (including all partial and transitive dependencies).
You can assume that the table does not contain repeating groups and that any invoice
number may reference more than one product. (Hint: This table uses a composite
primary key.). You can assume that any given product is supplied by a single vendor, but
a vendor can supply many products.

Attribute name Sample value

INV_NUM 211347
PROD_NUM AA_E3422QW
SALE_DATE 06/25/1999
PROD_DESCRIPTION B&D Rotary sander, 6 in. disk
VEND_CODE 211
VEND_NAME NeverFail, Inc.
NUMBER_SOLD 2
PROD_PRICE $49.95
b. Using the initial dependency diagram drawn in problem 2a., remove all partial and
transitive dependencies, draw the new dependency diagrams, and identify the normal
forms for each table structure you created.

Solution:
3. FastCabs database has the following structure. Each attribute’s name is self-descriptive.

jobID pickupDateTime driverID dFName dLName clientID cFName cLName cAddress


D
1001 25/07/00.10.00 I456 Jane Watt C034 Anne Way 111 Storrie Road, Paisley
1102 29/07/00.10.00 I456 Jane Watt C034 Anne Way 111 Storrie Road, Paisley

1203 30/07/00.11.00 I344 Tom Jones C034 Anne Way 111 Storrie Road, Paisley

1334 2/08/00.13.00 I666 Karen Black C089 Mark Fields 120 Lady Lane, Paisley
1455 2/08/00.13.00 I957 Steven Smith C019 John Brown 13 Renfrew Road, Paisley

1676 25/08/00.10.00 I344 Tom Jones C039 Karen Worth 34 High Street, Paisley

a. Identify any update anomalies in this database .

b. Identify the functional dependencies represented in this relation and


demonstrate the process of normalizing this relation into 3NF relations.

Primary Key : jobID

a. Examples of update anomalies :


Insertion anomaly : A client with an ID= C999, fname=Harry, lname=Smith,
Address=401 Sunset Avenue, Windsor - this information cannot be inserted in this table
because jobID cannot be left NULL (jobID is the PK). => the design above does not
allow a relevant piece of information (client details) to be inserted unless a job gets
associated with the client (Irrelevant) !

Deletion anomaly: Let’s say driver Tom Jones doesn’t work here anymore. If we delete
his information from the database, we also loose information on client C039.

Modification anomaly: If Anne Way changes her address, it has to be changed in several
places. It could lead to inconsistent information otherwise.
b. FD : pickupDateTime
jobID
driverID

dFName

dLName

clientID

cFName

cLName

cAddress

FastCabs is in 2NF as the PK is a simple key => there is no non-full FD.

FastCabs is not in 3NF as there are a few transitive dependencies.

jobID -> driverID


driverID -> dFName
driverID -> dLName

jobID-> clientID
clientID -> cFName
clientID -> cLName
clientID -> cAddress

To normalize FastCabs into 3NF, decompose into 3 realtions eliminating the TDs .

=> FastCabs (jobID, pickupDateTime, driverID, clientID)

Driver(driverID, dFName, dLName)

Client(clientID, cFName, cLName, cAddress)

FastCabs ∩ Driver = driverID , driverID is a key of Driver


FastCabs ∩ Client = clientID , clientID is a key of Client

And no FDs are lost !

=> the decomposition is a non-loss decomposition


4. ----Query 1
SELECT *
FROM EMPLOYEES
WHERE job_id = 'ST_CLERK'
AND hire_date > '31-DEC-1997';

----Query 2
SELECT last_name, job_id, salary, commission_pct
FROM employees
WHERE commission_pct IS NOT NULL
ORDER BY salary DESC;

----Query 3
SELECT 'The salary of ' || last_name || 'after a 10% raise is ' || ROUND(salary*1.10) "New salary"
FROM employees
WHERE commission_pct IS NULL;

----Query 4
SELECT COUNT(*)
FROM employees
WHERE last_name LIKE '%n';

----Query 5
SELECT employee_id, job_id
FROM employees
UNION
SELECT employee_id, job_id
FROM job_history;

----Query 6
SELECT employee_id, job_id
FROM employees
MINUS
SELECT employee_id, job_id
FROM job_history;

----Query 7
SELECT department_name, location_id, last_name, job_id, salary
FROM employees e, departments d
WHERE e.department_id = d.department_id
AND location_id = 1800;

----Query 8
SELECT department_id
FROM departments
MINUS
SELECT department_id
FROM employees
WHERE job_id = 'ST_CLERK';
----Query 9
SELECT employee_id, job_id
FROM employees
INTERSECT
SELECT employee_id, job_id
FROM job_history;

----Query 10
SELECT last_name, department_id, salary
FROM employees
WHERE (salary, department_id) IN
(SELECT salary, department_id
FROM employees
WHERE commission_pct IS NOT NULL);

----Query 11
SELECT last_name
FROM employees outer
WHERE outer.salary < (SELECT AVG(inner.salary)
FROM employees inner
WHERE inner.department_id = outer.department_id);

----Query 12
SELECT e.last_name, e.department_id, d.department_id
FROM employees e , departments d
WHERE e.department_id = d.department_id;

----Query 13
SELECT e.last_name , e.job_id, e.department_id, d.department_name
FROM employees e, departments d, locations l
WHERE e.department_id = d.department_id
AND d.location_id = l.location_id
AND l.city='Toronto';

----Query 14
SELECT w.last_name, w.hire_date, m.last_name, m.hire_date
FROM employees w, employees m
WHERE w.manager_id = m.employee_id
AND w.hire_date < m.hire_date;

----Query 15
SELECT job_id, COUNT(*)
FROM employees
GROUP BY job_id;

----Query 16
SELECT manager_id, min(salary)
FROM employees
WHERE manager_id IS NOT NULL
GROUP BY manager_id
HAVING MIN(salary) > 6000
ORDER BY MIN(salary) DESC;
----Query 17
SELECT last_name, hire_date
FROM employees
WHERE department_id = (SELECT department_id
FROM employees
WHERE last_name = 'Zlotkey')
AND last_name <> 'Zlotkey';

----Query 18
SELECT employee_id, last_name
FROM employees
WHERE salary > (SELECT AVG(salary)
FROM employees)
ORDER BY salary;

----Query 19
SELECT department_id, last_name, job_id
FROM employees
WHERE department_id IN (SELECT department_id
FROM departments
WHERE department_name = 'Executive');

----Query 20
SELECT last_name, salary
FROM employees
WHERE manager_id IN (SELECT employee_id
FROM employees
WHERE last_name = 'King');

You might also like