What About Smaller Schemas? Suppose we had started with inst_dept.How would we know to split up (decompose)it into instructor and department? Write a rule"if there were a schema(dept_name,building,budget),then dept_name would be a candidate key" Denote as a functional dependency: dept_name->building,budget In inst_dept,because dept_name is not a candidate key,the building and budget of a department may have to be repeated. This indicates the need to decompose inst_dept Not all decompositions are good.Suppose we decompose employee(ID,name,street,city,salary)into employee1 (ID,name) employee2(name,street,city,salary) The next slide shows how we lose information--we cannot reconstruct the original employee relation--and so,this is a lossy decomposition. Database System Concepts-6th Edition 8.5 @Silberschatz,Korth and SudarshanDatabase System Concepts - 6 8.5 ©Silberschatz, Korth and Sudarshan th Edition What About Smaller Schemas? Suppose we had started with inst_dept. How would we know to split up (decompose) it into instructor and department? Write a rule “if there were a schema (dept_name, building, budget), then dept_name would be a candidate key” Denote as a functional dependency: dept_name → building, budget In inst_dept, because dept_name is not a candidate key, the building and budget of a department may have to be repeated. This indicates the need to decompose inst_dept Not all decompositions are good. Suppose we decompose employee(ID, name, street, city, salary) into employee1 (ID, name) employee2 (name, street, city, salary) The next slide shows how we lose information -- we cannot reconstruct the original employee relation -- and so, this is a lossy decomposition