1. Supplement 11 : Why Normalisation or ER Modelling 1 11 Supplement – Why Normalisation or ER Modelling And Franchise Colleges By MANSHA NAWAZ

2. Supplement 11 : Why Normalisation or ER Modelling 2 Why Normalisation or ER Modelling ? n ‘Boyce Codd’ identified 3 main problems to which data was problematic when maintaining or updating data. DELETIONINSERTION AMENDMENT Information is maintained about students, modules and lecturers in a university based on 3rd generation language (3GL) environment such as Pascal, Basic, Cobol, etc, or on a spreadsheet as follows. Module NameStaff#StaffNameStudent#StudentNameAssGradeAssType Systems Design234Nawaz M12345Smith SPcwk1 Systems Design234Nawaz M12345Smith SMcwk2 Systems Design234Nawaz M12346Jones SPcwk1 Systems Design234Nawaz M12347Patel PMcwk1 Systems Design234Nawaz M12347Patel PFcwk2 Systems Analysis234Nawaz M12345Smith SDcwk1 Systems Analysis234Nawaz M12345Smith SDcwk2 Databases345Capper G12300Smith JPcwk1

3. Supplement 11 : Why Normalisation or ER Modelling 3 u u DELETION What if we wish to delete student 12300 (BOLD) Lose information on Databases (ITALICS) This is the DELETION ANOMILY or deletion side-effect Deletion of old information without deletion of other related data. Information is maintained about students, modules and lecturers in a university on a spreadsheet as follows. Module NameStaff#StaffNameStudent#StudentNameAssGradeAssType Systems Design234Nawaz M12345Smith SPcwk1 Systems Design234Nawaz M12345Smith SMcwk2 Systems Design234Nawaz M12346Jones SPcwk1 Systems Design234Nawaz M12347Patel PMcwk1 Systems Design234Nawaz M12347Patel PFcwk2 Systems Analysis234Nawaz M12345Smith SDcwk1 Systems Analysis234Nawaz M12345Smith SDcwk2 Databases345Capper G12300Smith JPcwk1

4. Supplement 11 : Why Normalisation or ER Modelling 4 u INSERTION What if we admit a new student 12349 on to a module We cannot enter a student record until a student has had at least one assessment. This is the INSERTION ANOMILY or an insertion side-effect Insertion of new information without the existence of other related data. Module NameStaff#StaffNameStudent#StudentNameAssGradeAssType Systems Design234Nawaz M12345Smith SPcwk1 Systems Design234Nawaz M12345Smith SMcwk2 Systems Design234Nawaz M12346Jones SPcwk1 Systems Design234Nawaz M12347Patel PMcwk1 Systems Design234Nawaz M12347Patel PFcwk2 Systems Analysis234Nawaz M12345Smith SDcwk1 Systems Analysis234Nawaz M12345Smith SDcwk2 Databases345Capper G12300Smith JPcwk1 ? ? ? 12349 Green A ? ?

5. Supplement 11 : Why Normalisation or ER Modelling 5 u AMENDMENT What if we change the lecturer of Databases to Jones We would need to update both staffname & staff# This is the AMENDMENT ANOMILY or an update side-effect Anomalies and inefficiencies arising from numerous data items. Inconsistency amongst stored values of that data item. Amendment effort required when a value changes. Module NameStaff#StaffNameStudent#StudentNameAssGradeAssType Systems Design234Nawaz M12345Smith SPcwk1 Systems Design234Nawaz M12345Smith SMcwk2 Systems Design234Nawaz M12346Jones SPcwk1 Systems Design234Nawaz M12347Patel PMcwk1 Systems Design234Nawaz M12347Patel PFcwk2 Systems Analysis234Nawaz M12345Smith SDcwk1 Systems Analysis234Nawaz M12345Smith SDcwk2 Databases345Capper G12300Smith JPcwk1

6. Supplement 11 : Why Normalisation or ER Modelling 6 3GL FLAT FILE : all data recorded in one file. Example : A list of projects undertaken by companies in the region. P# PtitlePdescE# EnameEaddress p1 AccountsExcele4 MBCMiddlesbrough p1 ACCOUNTSEXCELe4 Middlesbrough CouncilM’Boro p1 AccountsExcele8 Teesside UniversityEston p2 Stock ControlDatabasee8 University of TeessideBorough Rd p3 ReservationRoomse8 University of TeessideBorough Rd p3 ReservationRoomse1 ICIWilton Rd p3 ReservationRoomse2 British SteelSouth Bank p4 SalesCobole2 British SteelSouth Bank Discuss the problems with the above data set in terms of : *DUPLICATION & REDUNDANCY *PHYSICAL SIZE & SPEED *INFORMATION RETRIVAL FURTHER CONSIDERATIONS :

7. Supplement 11 : Why Normalisation or ER Modelling 7 P# Ptitle Pdesc p1 Accounts Excel p2 Stock Control Database p3 Reservation Rooms p4 Sales Cobol SOLUTION : USE 4GL TOOLS & TECHNIQUES Example : A list of projects undertaken by companies in the region. PROJECTS(P#, Ptitle, Pdesc) PROJ_EMP(P#, E#) EMPLOYER(E#, Ename, Eaddress) PROJECTSPROJ_EMPEMPLOYER The above has no DUPLICATED, REDUNDENT or NULL data. E# Ename Eaddress e1 ICI Wilton Rd e2 British Steel South Bank e4 MBC Middlesbrough e8 University of Teesside Borough Rd P# E# p1 e4 p1 e8 p2 e8 p3 e8 p3 e1 p3 e2 p4 e2 n Normalisation or ER Modelling are tools used to derive such solutions. used to derive such solutions.

8. Supplement 11 : Why Normalisation or ER Modelling 8 Data Modelling Definitions. n ENTITY u Object being modelled. u Independent existence. u One Row Per Entity Occurrence. u Look for object name or thing. F eg INVOICE, ORDER, STUDENT, LECTURER u Look for things requiring a list of associated records or tabular list of data. u Each existence of an entity value requires a record. u Look for things with record keys. u eg stock code -> STOCK reg. no. -> CAR

9. Supplement 11 : Why Normalisation or ER Modelling 9 n TABLE u A class of entities (or objects) in the system F example : ‘stock’ ‘customer’ ‘employee’ n TABLE OCCURRENCE u tabular list of data associated with the entity F occurrence of table STOCK STOCK

10. Supplement 11 : Why Normalisation or ER Modelling 10 n TABLE TYPE u file structure u STOCK(part#, part-desc, qty) n ROW u occurrence of an entity n ATTRIBUTE u item of data u associated with each entity or object u example : An entity STOCK has F part#, part-desc & qty attributes

11. Supplement 11 : Why Normalisation or ER Modelling 11 n ATTRIBUTE VALUE u a particular occurrence’s characteristics F part-desc of attribute value ‘p3’ is ‘washer’ n KEYS u often one attribute of the entity will characterise or identify the individual occurrences F part# in STOCK u such an attribute is called a key attribute is underlined or identified by an @ symbol n COMPOUND KEYS u in some entities no such key value is present u may be able to find 2 or more attributes to fulfil task u pairings of such attributes is called compound key

12. Supplement 11 : Why Normalisation or ER Modelling 12 n FOREIGN KEYS u as keys but will be appear in other tables and is used to assist in linkage across tables F part# in ORDERS will identify the parts for an order F part# in PARTS will identify the part F order# in ORDERS will identify the order u only foreign keys should be duplicated in other tables. n RELATIONSHIP u Is an association or linkage between two or more entities via a common key value. u Common key values can F either be held in the adjoining TABLES F or can be held in a RELATIONSHIP TABLE

13. Supplement 11 : Why Normalisation or ER Modelling 13 P# Ptitle Pdesc p1 Accounts Excel p2 Stock Control Database p3 Reservation Rooms p4 Sales Cobol PROJECTS PROJ_EMP EMPLOYER E# Ename Eaddress e1 ICI Wilton Rd e2 British Steel South Bank e4 MBC Middlesbrough e8 University of Teesside Borough Rd P# E# p1 e4 p1 e8 p2 e8 p3 e8 p3 e1 p3 e2 p4 e2 PROJECT and EMPLOYER are linked via the relationship PROJ_EMP u Relationship is used to share attributes (data) between entities u Allows the linkage necessary to build a DATA MODEL u DATA MODEL for PROJECTS

14. Supplement 11 : Why Normalisation or ER Modelling 14 The 4 Rules for Normalised Tables No row order significance. No column order significance. No multiple values at row/column intersections. No duplicate rows. Snapshots of table occurrences. –When we look at a paper copy of a table remember that the data in a real database table can be expected to change all the time. –The COPIES table could have 5 rows the first time we look and on another day there could be hundreds or thousands. –Always assume a database table really has thousands of rows.

15. Supplement 11 : Why Normalisation or ER Modelling 15 The 4 rules for Normalised Tables broken No row order significance (Rule broken). If you swap the rows you lose information as copies are sometimes dependent on the row above for their ISBNX number.

16. Supplement 11 : Why Normalisation or ER Modelling 16 No Column Order Significance (Rule broken). The two columns with no attribute type shown are intended to indicate the date-purchased followed by the date-removed. –The date-removed column would contain a significant number of NULLS (explained later). The two columns are now dependent on the column order for their meaning. –If you move the first date column to the end of the table then the meaning is lost. Clearly having each column with its own attribute type is simpler and makes the columns order independent of each other.

17. Supplement 11 : Why Normalisation or ER Modelling 17 No Multiple Values at Row/column Intersections (Rule Broken). Or No Repeating Groups This is just too complicated – it makes searching and sorting difficult. Can you sort this into date order?? Can it be easily searched on access_no ??

18. Supplement 11 : Why Normalisation or ER Modelling 18 No Duplicate Rows (Rule broken). Why is this such a BAD idea? If you allow redundantly duplicated data in a real system, what will be the end result?