Read the following scenario carefully: Banyon Corporation currently keeps track of employee data in a spreadsheet table. However, they see that the single-table approach is not working well since there is duplication of data and various anomalies arise as new rows are inserted, old rows deleted, and current rows updated. Here are the current column headers for Banyon’s spreadsheet table,
Employees. EMPLOYEES (Emp_id, Emp_name, Emp_phone, Dept_name, Dept_phone, Dept_manager, Skill_id, Skill_name, Skill_date, Skill_level)
Banyon has decided to use a database rather than a single-table spreadsheet. They conducted the following analysis. Each employee is identified by a unique emp_id. Knowing an emp_id, you can determine the corresponding employee name, phone and department in which the employee works. Department names are also unique. Knowing a dept_name you can determine the department’s phone and manager. Each employee possesses a set of skills. Employees must periodically update each skill by passing a test that certifies a certain skill level at a given point in time (skill_date). A skill can be identified by a unique skill_id. However, skill_level and skill_date are associated with a specific employee’s certification on a given skill.
1) Imagine several rows of data in the existing Employees table. a) Give an example of an insertion anomaly b) Give an example of a deletion anomaly. c) Give an example of an update anomaly.
2) List any multivalued dependencies you have identified. Quote a specific line or phrase from the Banyon scenario to justify each MV dependency
3) List any functional dependencies you have identified. Quote a specific line or phrase from the Banyon scenario to justify each functional dependency.
4) Refer to Figure 3-19. Use the process defined in Figure 3-19 to put the Employees table into BCNF. Document each step you take by referring to the appropriate step in Figure 3-19
|Process for Putting a Relation into BCNF|
|Identify all functional dependencies in the relation|
|Identify every candidate key in the relation.|
|If there is a functional dependency that has a determinant that is not a candidate key:
Move the columns of the functional dependency of the determinant that is not a candidate key to a new relation.
Make the determinant of that functional dependency the primary key of the new relation.
Leave a copy of the determinant in the original relation as a foreign key.
Create a referential integrity constraint between the relations.
|Repeat step 3 until every determinant of every relation is a candidate key|