Project Management Report Project Code: PCO10 Project Title: Pensions System Project Manager: M Phillips Project Budget: £24,500 Employee Employee Department Department Hourly No. ‘Name Ne. Name Rate $10001 ASmith L004 Ir £22.00 510030 LJones L023 Pensions £18.50 $21010 PLewis L004 1T £21.00 $00232 RSmith L003 Programming £26.00 Total Staff on Project: 4 Average Hourly Rate: £21.88Title | manager | Budget | No. Meee’ || Me Name | Pensions | er ZAEOO | STOO a ae System | Philips Pensions | | 2asPst0033 — 1 tones Toss Teso-] Phitips pease Sze] Fas Toor a Prutips cS le Toor 1 zs] 7 TOO] | Daas 2550] Say] 78] Richaras Klews | 42250] Sa10v PT Gilbert | —Lozs—| Database] 2525-| [ Roewe ano sar0e Prams — coe} 750] a FE 530] UNF: unnormalised tableANF Tables: Repeating Attributes Removed Project Cade P00 Poss Project Title Pansens System Salaries System HR system Project Manager Philips H Maria K Lewis Project Code — Emplayce No. | Employee Name Pco1o peoto coo pooas pcos peoss peoas ose Pons Pcs ‘$1001, 10020 21010 10010 ‘510001 21002 12220 21002 21010 ‘10034 ‘ASmith Loones P Lewis B Jones ASmith Tolbert W Richards Toler P Lewis ames Department No. Department Name Looe Lox 008 L008 L008 Love L008 Lore Loe 008 2NF Tables: Partial Key Dependencies Removed Project Project Title Code ‘pco10 Pensions System iecoas Salaries system pco6s HR system Project Employee Hourly Code No. Rate ‘pco10 10001 22.00 pcoxa 10030 18.50 eco s21010 21.00 fpcoas_s10010 21.75 ‘pcos 10001 48.00 fpcoas 31002 25.50 eoas§13210 17.00 pcos 31002 23.25 fpcoss 21010 1750 ipcoss _s10034 1650 Project Manager 1M Philips Haren K Lewis Employee ‘s10002 's10030, 21010 10010 s31002 13210 ‘510034 Project Budget 24500 17400 12250 Employee Name Smith Lone PLewis Boones TGibert W Richards Blames Project Budget 24500 17400 12250 Hourly Rate a 2.00 Penstons 4850 7 21.00 7 2175 7 38.00 Database 25.50 salary 17.00 Databases 225 i 17.50 HR 36.50 Department Department No. Name Loo 7 Lon Pensions Love 1. Loo Ir Loe Database 008 Salary Love HR3NF Tables: Non-Key Dependencies Removed Project Code pono ows ove Project Code oo. Pon Poo ows poo Poms Poms 64 ove ove 10008 10030 21010 10010 31002, Gra) 10034 SEBE8 Project Title Pencons Sytem Salis Sistem HR System Employee No. sion 10030 sun0 sono S100 sam S120 sam sano 510034 Employee Name ‘Smith Lones fe Baines Téitet richards Blames Department Name T Pensions Database Salary HR Project Manager lls Matin K eis Hourly Rate 2200 1850 2.00 28 1800 B50 17.00 25 1750 1650 Department No. © BRR52 ‘os 0009 Project Budget 24800 17400 1250Example shit red be 1200 060) pola red. yelow (1200 080 T-shirt red be 1200 080 sweatstit [Dive back (25.00 1s Table is not in frst normal form because: ‘Multiple items in color fila » Duplicate records /no primary key Example shit ed 12.00 [oe rr shie tive 12.00 [oo pao ed 12.00 [oo pt yellow 12.00 [oo sweasshit [tive 25.00 [12s sweashit [lace 25.00 [has ‘Table is now in first normal form. Second Normal Form (2NF) © All non-key fields depend on all components of the primary key. +» Guaranteed when primary key is a single field.pice tax red 12.00 (060 blue 2.00 0.60 red 2.00 0.60 yelow 2.00 060 sweatshit [blue 3.00 1.25 sweatshirt [black B00 1.25 Table is not in second normal form because’ © price and tax depend on item, but not color Example shit [red Tshirt [1200 [060 rrshit [ue polo polo fed [sweatshit |2500 [1.25 polo yellow sweatshint [blue [sweatshin [black Tables are now in second normal form.Third Normal Form (3NF) + No non-key field depends upon another, * All non-key fields depend only on the primary key. Example f= [a T-shirt ted T-shirt 12.00 . shit [bbe pelo 1200 polo red sweatshirt [25.00 polo yellow sweatshirt | be [sweatshirt | black Tables are notin third normal form because: © tax depends on price, not itemExample price T-shirt red Tshirt [12.00 T-shirt blue pol 2.00 polo red sweatshirt [25.00 polo yellow sweatshirt | blue tax [sweatshirt | black 12.00 [0.60 2500 [Las Tables are now in third normal form. Another Example ————) : =——— | 7 asa 7 : z ‘ae 1 a i 3 : : ee i Hi a a I ere 508 Tables are in third normal form,Relationships in First Example price shit red 2.00 T-shirt the 2.0 polo ed 35.00 polo yellow # sweatshin [tue 4 sweatshie [black = — one to one 12.00 [0.50 ne to m Bon [15 Relationships in Second Example snarl [Dein 1 t 1 fi : asthe —_—— a z reasnar 3 acinar N Fratone 7 T z i 7 Bi any 3 ane many to manyProblem Without Normalization \Without Normalization, itbecomes diffcuitto handle and update the database, without facing data loss. Insertion, Updation and Deletion Anamolies are very frequent if Database is not Normalized. To understand these anomalies let us take an example of Student table suid S.Name S_Address Subject_opted 401 ‘Adam Noida Bio 402 Alex Panipat Maths 403 ‘Stuart Jammu Maths 404 Adam Noida Physics ‘+ Updation Anamoly : To update address of a student who occurs twice of more than twice in a table, we wall, have to update $_Address column in al the rows, else data will become inconsistent + Insertion Anamol Suppose for a new admission, we have a Student id(S_M), name and address ofa ‘student but if studenthas not opted for any subjects yet then we have to insert NULL there, leading to Insertion AnamoW. + Deletion Anamoly ; lf (_id) 401 has only one subject and temporarily he drops it, when we delete that ‘ow, entire student record willbe deleted along with it First Normal Form (INF) ronusa GErPAD ‘As per First Normal Form. no two Rows of data must contain repeating group of information e each set of column must have a unique value, such that mutiple columns cannct be used to fetch the same row. Each tee should be organized into rows, and each row should have a primary key that distinguishes it as unique. ‘The Primary key is usualy a single column, but sometimes more than one column can be combined to create a ‘ingle primary key. For example considera table whichis notin First normal form ‘Student Tab Student Age ‘Subject ‘Adam 18 Biology. Maths ‘Alex 14 Mains stuart 17 Maths:In First Normal Form, any row must not have @ column in which more than one value is saved, like separatec ‘with commas. Rather than that, we must separate such data into muttiple rows. Student Table following 1NF will be : Student Age Subject Adam 15 Biology Adam 15 Maths Alex 14 Maths Stuart 7 Maths Using the First Normal Form, data redundancy increases. as there will be many colurnns with same data in rmutiple rows but each row as a whole will be unique, secommende fot ‘Second Normal Form (2NF) cerPal ‘As per the Second Normal Form there must nt be any partial dependency of any column on primary key. It ‘means that for a table that has concatenated primary key, each column in the table that isnot part ofthe primary key must depend upon the entire concatenated key for its existence. Ifany column depends only on one part of the concatenated key, then the table falls Second normal form. In example of First Nocmal Form there are two rows for Adar, to include multiple subjects that he has opted fo. While this is searchable, and follows Fist normal form, it is an inefficient use of space. Also inthe above Table in First Normal Form, while the candidate key Is (Student, Subject), Age of Student only depends on Student column, which is incorrect as per Second Normal Form. To achieve second normal fom, it would be helpful to ‘pli out the subjects into an independent table, and match them up using the student names as foreign keys New Subject Table introduced for 2NF will be : student sunject Adam Biology Adam athe Alex Maths Stuart MathsNew Student Table following 2NF will be : Student Age Adam, 15 Alex 14 ‘Stuart 7 Third Normal Form (3NF) ‘Third Normal form applies that every non-orime attrioute of table must be dependent on primary key. The transitive functional dependency should be removed from the table. The table must be in Second Normal form, For example, consider a table with following fields. ‘Student_Detall Table : ‘Student_id ‘Student_name DOB Street city State Zip In this table Stucent_Id is Primary key, but street, city and state depends upon Zip. The dependency betvieen zip ‘and other fields is called transitive dependency. Hence to apply SNF, we need to move the street, city and state to new table, with Zip as primary key. New Student_Detail Table : ‘Student_d ‘Student_name Dos zip ‘Address Table : Zip Strost city state ‘The advantage of removing ranstve dependency is + Amount of data duplication Is reduced + Data integrity achieved. Boyce and Codd Normal Form (BCNF) Boyce and Codd Normal Form is higher version ofthe Thc Normal frm. This form dls with certain type of ‘anamly thats not hancled by 3NF. A 3NF table which does not have multiple overapping cancidate Keys is. ‘sald tobe in BONF.