1. Bottom Up Analysis Bottom-up Data Analysis An Example

2. Bottom Up Analysis Rigorous, bottom-up, data analysis Bottom-up data analysis is used as a method of database design when an enterprise already has an information system, but one which needs to be refined before it can be implemented as a relational database It uses the techniques we have met

3. Bottom Up Analysis Outline Systems analyst obtains a copy of every document screen display report record card... … or any other tangible information source relevant to the information system that is being designed These sources are processed according to a well defined procedure, to produce a suitable collection of relation schemas

4. Bottom Up Analysis The Procedure (to be followed for every information source) represent the source as an un-normalised structure normalise that structure splitting as necessary check that all relations are in normal form repeating as necessary optimise the whole set of normalised relations

5. Bottom Up Analysis Normalisation Remember... normalisation means a separation of concerns often eliminates redundancy in the relations there are various normal forms choose an acceptable one 3NF (BCNF)

6. Bottom Up Analysis Analysing a Document Suppose we are working with a registration card for Llandwp College Student_Registration

7. Bottom Up Analysis An Un-normalised Structure As an initial step, the document is represented as an un-normalised structure: Student Enrolment

8. Bottom Up Analysis Functional Dependencies and Enterprise Rules Next, functional dependencies between the data fields are recorded Functional dependencies are determined by enterprise rules for the data in question

9. Bottom Up Analysis Student no.  Student's Name, Course title, Year of Course, Tutor's Staff Code, Tutor's Name, Tutor's Extension Tutor's Staff Code  Tutor's Name, Tutor's Extension Student no., Unit Code  Unit Title, Mark Unit Code  Unit Title Functional Dependencies

10. Bottom Up Analysis Student no.  Student's Name, Course title, Year of Course, Tutor's Staff Code, Tutor's Name, Tutor's Extension Tutor's Staff Code  Tutor's Name, Tutor's Extension Student no., Unit Code  Unit Title, Mark Unit Code  Unit Title Functional Dependencies

11. Bottom Up Analysis First Normal Form The un-normalised structure is brought to first normal form by transferring repeating groups of items to separate relation schemes Each new scheme includes the key of the original un-normalised structure as part of its own key

12. Bottom Up Analysis First Normal Form Student Enrolment

13. Bottom Up Analysis STUDENT( Student no., Student’s Name, Year of Course, Tutor's Staff Code, Tutor’s Name, Tutor’s Extension ) ENROLMENT( Student no*, Unit Code, Unit Title, Mark ) FK Student no references STUDENT First Normal Form Student Enrolment

14. Bottom Up Analysis Second Normal Form The relation schemes are brought to second normal form by eliminating partial dependencies on keys Unit Title is only partially dependent on the key (Student no., Unit Code), since Unit Code alone is sufficient to determine its value for any unit

15. Bottom Up Analysis Second Normal Form Student Enrolment Unit

16. Bottom Up Analysis STUDENT( Student no., Student’s Name.Course Title, Year of Course, Tutor's Staff Code, Tutor’s Name, Tutor’s Extension ) UNIT( Unit Code, Unit Title ) ENROL( Student no.*, Unit Code*, Mark ) FK Student no references STUDENT FK Unit Code references UNIT Second Normal Form Student Enrolment Unit

17. Bottom Up Analysis Bringing Relation Schemes to Third Normal Form The relation schemes are brought to third normal form by eliminating transitive dependencies on keys Tutor's Name and Tutor's Extension are transitively dependent on the key, Student no

18. Bottom Up Analysis Third Normal Form Student Enrolment Unit Staff

19. Bottom Up Analysis STUDENT( Student no. {PK}, Student’s Name.Course Title, Year of Course, Tutor's Staff Code* ) FK Tutor’s Staff Code references TUTOR UNIT( Unit Code {PK}, Unit Title ) TUTOR( Tutor’s Staff Code {PK}, Tutor’s Name, Tutor’s Extension ) ENROL( Student no.*, Unit Code* {PK}, Mark ) FK Student no. references STUDENT, FK Unit Code references UNIT Third Normal Form Student Enrolment Unit Staff

20. Bottom Up Analysis Summary of the normalisation procedure Represent the source document (as an un- normalised structure) Identify functional dependencies between data items Construct first normal form schemes by eliminating repeating groups of data items Bring the schemes to second normal form by eliminating partial dependencies on key fields Bring the schemes to third normal form by eliminating transitive dependencies on key fields

21. Bottom Up Analysis More documents from the Llandwp College Also included are copies of a list of Course Units a list of Staff Teaching Duties a Timetable As a systems analyst, it is your job to analyse these documents like the Registration Card was analysed above

22. Bottom Up Analysis The List of Course Units Example data (document) C22Problem Solving C31Basic Compiler Design C66Computing Fundamentals C70Java coding C89Practical Business Computing …

23. Bottom Up Analysis The List of Course Units Representing the Course Units list as an "un-normalised" structure gives: Enterprise rule: Each unit has a unique unit code which determines its title The only functional dependency is: Unit Code  Unit Title

24. Bottom Up Analysis Analysing the List of Course Units In this case, the “un-normalised” structure is already in third normal form It contains no repeating groups of data items, no partial dependencies on key fields, and no transitive dependencies on keys. It needs no further analysis, and the resulting relation scheme is, as before:

25. Bottom Up Analysis Analysing the List of Course Units UNIT( Unit Code, Unit Title ) Unit

26. Bottom Up Analysis The List of Teaching Duties Example data csanoTony OtterC31, C70 csasdAmanda DolittleC89 cswasBill SmithC22, C66

27. Bottom Up Analysis The List of Teaching Duties Un-normalised Structure: Enterprise Rule: Each member of staff has a unique staff code. Functional dependency: Staff Code  Name Enterprise Rule: Each member of staff may teach many Units: {Staff Code, Unit Code}  { } Staff

28. Bottom Up Analysis These schemes are also in third normal form (and BCNF). Analysing the list of Teaching Duties First Normal Form Eliminate repeating groups of data items by moving the items in question to a new relation scheme, and including the key of the original scheme in that of the new scheme Staff Teach

29. Bottom Up Analysis Analysing the list of Teaching Duties STAFF( Staff Code, Name ) TEACH( Staff Code*, Unit Code ) FK Staff Code references STAFF Staff Teach

30. Bottom Up Analysis Analysing the Timetable Example Data the timetable is written as a list Monday 10:00C22321 12:00C66318 Tuesday 11:00C89317 11:00C70320...

31. Bottom Up Analysis Analysing the Timetable Un-normalised Structure:

32. Bottom Up Analysis Analysing the Timetable Enterprise Rules: At a given time and day of the week, a unit (module) can only take place in one room. Functional Dependency: Day of Week, Time, Unit Code  Room No. At a given time and day of the week, a room can only hold one unit (module). Functional Dependency: Day of Week, Time, Room No.  Unit Code (Captures that different units cannot co-exist at same time in same room)

33. Bottom Up Analysis Analysing the Timetable First Normal Form: These schemes are also in third normal form. CKs: {Day, Time, Unit} {Day, Time, Room}

34. Bottom Up Analysis Analysing the Timetable WEEK_DAY( Day of Week ) TIME_SLOT( Day of Week*, Time ) FK Day of Week references WEEK_DAY T_TABLE( Day of Week, Time*, Unit Code, Room No ) ALTERNATE KEY: ( Day of Week, Time, Room No.) FK {Day of Week, Time} references TIME_SLOT CK: {Day, Time, Room}

35. Bottom Up Analysis The Complete Set of Normalised Relation Schemes From the Student Registration Card: 4 relations From the Course Units List: 1 relation From the Teaching Duties List: 2 relations From the Timetable: 3 relations

36. Bottom Up Analysis The Normalised Relation Schema

37. Bottom Up Analysis Merging the Normalised Relation Schemes Check attribute names for consistency, renaming attributes where necessary Merge relations that have the same key if they represent the same real world entity Do not merge relations that have the same key if one represents a subset domain of the other Eliminate key-only relations unless they represent data that you want to store in tables

38. Bottom Up Analysis The Optimised Normalised Relation Schema Duplication? Same concept? Rename? Key only?

39. Bottom Up Analysis The Optimised Normalised Relation Schema Added Slide

40. Summary of Relation Schema STAFF( Staff Code, Name, Extension ) STUDENT( Student no., Course Title, Year of Course, Tutor's Staff Code* ) FK Tutor's Staff Code references STAFF UNIT( Unit Code, Unit Title ) ENROL( Student no.*, Unit Code*, Mark ) FK Student no. references STUDENT FK Unit Code references UNIT TEACH( Staff Code*, Unit Code* ) FK Staff Code references STAFF FK Unit Code references UNIT TIME_SLOT (Day of Week, Time ) T_TABLE( Day of Week*, Time*, Unit Code*, Room No. ) FK Time (Day of Week, Time) references TIME_SLOT FK Unit Code Code references UNIT Added Slide

41. Bottom Up Analysis Alternative Optimised Normalised Relation Schema

42. Summary of Relation Schema STAFF( Staff Code, Name, Extension ) STUDENT( Student no., Course Title, Year of Course, Tutor's Staff Code* ) FK Tutor's Staff Code references STAFF UNIT( Unit Code, Unit Title ) ENROL( Student no.*, Unit Code*, Mark ) FK Student no. references STUDENT FK Unit Code references UNIT TEACH( Staff Code*, Unit Code* ) FK Staff Code references STAFF FK Unit Code references UNIT TIME( Time Slot, Day of Week, Time ) ALTERNATE KEY: (Day of Week, Time) T_TABLE( Time Slot*, Unit Code*, Room No. ) ALTERNATE KEY: (Time Slot, Room No.) FK Time Slot references TIME FK Unit Code references UNIT

43. Bottom Up Analysis Summary Rigorous, bottom-up data analysis entails collecting source documents drawing up un-normalised structures normalising these - 3NF, BCNF, 4NF... optimising the resulting set of schemes The resulting set defines the structure of the database that is to be constructed

44. Bottom Up Analysis Review - concise First bring relation to 1NF: StuDetails( StuNo, StuName, Ctitle, Cyear, TSCode, Tname, TExt, UCode, UTitle, Mark) Document the FDs: StuNo  {StuName, CTitle, CYear, TSCode, TName, TExt} TSCode  {TName, TExt} {StuNo,UCode}  {UTitle, Mark} UCode  Utitle

45. Bottom Up Analysis Review - concise {StuNo,UCode} these attributes determine all others, and are minimal. So, the 1NF relation StuDetails( StuNo, StuName, Ctitle, Cyear, TSCode, Tname, TExt, UCode, UTitle, Mark) has key {StuNo, Ucode}

46. Bottom Up Analysis Bring to 2NF The attributes of the key { StuNo,UCode } satisfy FDs StuNo  {StuName, CTitle, CYear, TSCode, TName, TExt} UCode  Utitle These present partial dependencies on the key {StuNo,UCode}. Eliminate these for 2NF:

47. Bottom Up Analysis Bring to 2NF StuDetails( StuNo, StuName, CTitle, CYear, TSCode, Tname, TExt,) UnitDetails(UCode, UTitle) StuReg( StuNo*, Ucode*, Mark)

48. Bottom Up Analysis Bring to 3NF In StuDetails, we still have: StuNo  {StuName, CTitle, CYear,TSCode, TName, TExt} TSCode  {TName, TExt} So, StuNo  TSCode  {TName, TExt} Transitive dependency!

49. Bottom Up Analysis Bring to 3NF Eliminate the transitive dependency: StuDetails( StuNo, StuName, CTitle, CYear, TSCode*} TutorDetails(TScode, Tname, TExt,)

50. Bottom Up Analysis Complete Normalisation of Registration Table StuDetails( StuNo(PK), StuName, CTitle, CYear, TSCode*} TutorDetails(TScode (PK), Tname, TExt,) UnitDetails(UCode (PK), UTitle) Enrol( StuNo*, Ucode*, Mark) FK StudNo references StudDetails FK Ucode references UnitDetails

51. Bottom Up Analysis Other Sources Course Units UNIT( Unit Code, Unit Title ) Teaching Duties STAFF (Staff Code, Name ) TEACH (Staff Code*, Unit Code) FK Staff Code references STAFF Timetable WEEK_DAY( Day of Week ) TIME_SLOT( Day of Week*, Time ) FK Day of Week references WEEK_DAY T_TABLE( Day of Week, Time*, Unit Code, Room No ) ALTERNATE KEY: ( Day of Week, Time, Room No.) FK {Day of Week, Time} references TIME_SLOT Added Slide

52. Bottom Up Analysis Complete Normalisation of Llandwp Tables Carry out the normalisation of each source in turn Collate the different results, making mergers and renamings where appropriate Consider redundant relations for elimination Ensure every relation has a PK (and possible CKs) and indicate each FK with its referenced relation.

53. Summary of Relation Schema STAFF( Staff Code, Name, Extension ) STUDENT( Student no., Course Title, Year of Course, Tutor's Staff Code* ) FK Tutor's Staff Code references STAFF UNIT( Unit Code, Unit Title ) ENROL( Student no.*, Unit Code*, Mark ) FK Student no. references STUDENT FK Unit Code references UNIT TEACH( Staff Code*, Unit Code* ) FK Staff Code references STAFF FK Unit Code references UNIT TIME_SLOT (Day of Week, Time ) T_TABLE( Day of Week*, Time*, Unit Code*, Room No. ) FK Time (Day of Week, Time) references TIME_SLOT FK Unit Code Code references UNIT Added Slide