Harrison

Garber
Assignment 2
Part A:

1. EMPLOYEE (EmpID, empName, empType)
2. SKILLS_OF_EMPLOYEE (Skills, EmpID)
FK (EmpID) ref EMPLOYEE
3. MANAGING_MAP (SuboordinateID, ManagerID)
FK (SuboordinateID) ref EMPLOYEE, (ManagerID) ref EMPLOYEE
4. COUNTRY_MANAGER (EmpID, phoneNumb)
FK (EmpID) ref EMPLOYEE
5. DEVELOPMENT_MANAGER (EmpID, hrlyRate)
FK (EmpID) ref EMPLOYEE
6. DEVELOPER (EmpID, primSkill)
FK (EmpID) ref EMPLOYEE
7. COUNTRY (CountryID, EmpID, countryName, RegionID)
FK (EmpID) ref EMPLOYEE, (RegionID) ref REGION
8. REGION (RegionID, EmpID, regName)
FK (EmpID) ref EMPLOYEE
9. PROJECTS (projID, EmpID,startDate, endDate)
FK (EmpID) ref EMPLOYEE
10. DEVELOPER_PROJECT_RECORDS (devprojID, EmpID, projID)
FK (EmpID) ref EMPLOYEE, (projID) ref PROJECTS

Part B:

1. a. The table is currently presented in 1NF, as there are no multivalued attributes. The
table is not in 2NF, as partial functional dependencies exist. The relation schema of the
table is as follows:

SUPPLIER_PRODUCT (SupplierNo, ProductID, supplierName, supplierComrate,
supplierYearhired, productName, productUnitprice, Manager)

FD: SupplierNo supplierName
SupplierNo supplierComrate
SupplierNo supplierYearhired
supplierName Manager
ProductID productName
ProductID productUnitprice


Because the above partial dependencies have been identified, it has been reaffirmed
that the table is not in 2NF. If the table is not in 2NF, it can definitely not be in 3NF.
Therefore, the table is indeed in 1NF.

b.
Insertion: We cant enter a repeat order for any product without duplicating an entire
row of data.
Deletion: If we remove the order of a CPU from John (bottom row), we will be unable to
tell that John sells CPUs at all.
Modification: If John changes his commission rate, multiple rows of the table will need
to be modified:

c. The table is already in 1NF, so we must now convert it to 2NF by removing all partial
functional dependencies.
1. SUPPLIER (SupplierNo, supplierName, supplierComrate, supplierYearhired, Manager)
2. PRODUCT (ProductID, productName, productUnitprice)

All partial dependencies have been removed, so the relation is now in 2NF. We must
now remove all transitive dependencies to achieve 3NF. The following transitive
dependency exists:

FD: SupplierNo supplierName Manager

1. SUPPLIER (SupplierNo, supplierComrate, supplierYearhired)
2. MANAGER (SupplierName, Manager)
3. SUPPLIER_MANAGER (SupplierNo, SupplierName)
FK (SupplierNo) ref SUPPLIER, (SupplierName) ref MANAGER
4. PRODUCT (ProductID, productName, productUnitprice)

All transitive dependencies have been removed, so 3NF has been achieved.

2. a. We can assume the relation is already in 1NF, as we cannot see the individual rows in
its table. There are partial dependencies, however, which means that it is not 2NF.
Therefore, we know the relation is in 1NF.

b. We know the relation is not in 2NF, as partial dependencies exist. CourseName and
Coursetype are dependent on the CourseID portion of the primary key, while InstName
is dependent on the InstID portion of the primary key. If the relation is not in 2NF, we
know it cannot be in 3NF either.

c. 1. COURSE (CourseID, CourseName, Coursetype)
2. INSTRUCTOR (InstID, InstName)

All partial dependencies have been removed, therefore 2NF has been achieved. Because
there are no transitive dependencies in the relation, 3NF has also been achieved.