a) For the staff-project database described and normalised earlier on in this practical, first draw its ER diagram, then draw its relation diagram. Highlight the pertinent keys in the diagrams. You can ignore participation multiplicities in these 2 diagrams.

b)Give a table of your own that is already in 1NF but not in 2NF, along with the functional dependencies among the attributes of the table drawn as a diagram. Illustrate the process of normalisation of your table to 2NF. Do not use any tables that already appeared in lecture notes or the practicals. Do not just rename the attributes of tables there.

Staff ID Staff Name Project ID Hours Project Project Project Name LocationID| Location FD1: Staftis, ProjectID - Hours FD2: StaftiD - StaftName FD3: ProjectID - ProjectName, Project LocationID, Project Location o FD4: Project LocationID - Project Location For the normalisation, we first observe that attributes StaffID and ProjectID together form the primary key. Since FD2 and FD3 are the partial dependencies on the primary key, they each have to form a separate relation table in terms of their own set of attributes, in order to achieve the 2NF. The original full relation thus shrinks to the 1st relation in the diagram below according to the procedure for the 2NF Hence the 2NF consistes of the following 3 relations Project Project Project Project ID Name LocationID Location Since FD4 implies Project Location transitively depends on ProjectID via Project LocationID, the attributes of FD4 have to form a separate relation in order to achieve the 3NF. The last relation in the above diagram thus shrinks to the bottom-left relation in the diagram below. Hence the 3NF consists of the following 4 relations Staff ID Project Hours Staff ID Staff Name ID Project Project Project Name LocationID Project Location Project Location ID TT