Suppose schema S has attributes A, B, and C. The attribute A uniquely determines B and C uniquely determines A. Suppose we decompose S into S1 and S2 such that S1 contains A and B, and S2 contains C and A.

(a) What are the keys of S, S1, and S2, respectively?
(b) Does the decomposition remove redundancy? Why?
(c) Is the decomposition lossless? Why?
(d) Is the decomposition dependency-preserving? Why?
(e) Does the decomposition lead to tables that are overall smaller? Why?
(f) Does the decomposition lead to tables for which it is easier to guarantee the given integrity
constraints? Why?
(g) Does the decomposition lead to tables for which it is easier to write query operations?
Why?
(h) Does the decomposition lead to tables that enable faster query and update operations?
Why?

(a) The keys are C, A, and C, respectively.
(b) Yes. There is redundancy in S, because all rows with same value of A have also the same value of B. There is no redundancy in S1 and S2.
(c) Yes. The intersection of S1 and S2 is A, which is a key of S1.
(d) Yes. The functional dependencies in S are equivalent to the union of the dependencies in S1 and S2.
(e) Yes and No. Yes if many rows in S have the same value of A, since for each value of A, the same value of B does not need to repeated that many times. Otherwise no, since A has to be duplicated in both S1 and S2.
(f) Yes. Maintaining the constraint that A uniquely determines B requires no additional work after decomposition.
(g) No. For queries that need both attributes B and C two tables must be joined rather than just using one table.
(h) Yes and No. Yes, if there are many records and there is much redundancy, and thus the table is much bigger before decomposition and may lead to more page faults and slower query evaluation. No for queries otherwise. Yes also for update operations that involve only attributes B and A.