Presentation is loading. Please wait.

Presentation is loading. Please wait.

IT203 Unit 4: Normalization Normalization Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter5.1.

Similar presentations


Presentation on theme: "IT203 Unit 4: Normalization Normalization Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter5.1."— Presentation transcript:

1 IT203 Unit 4: Normalization Normalization Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter5.1

2 Anomalies Normalization is the process of removing potential anomalies from the database design. These anomalies include: – Insertion anomalies – Update anomalies – Deletion anomalies Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.2

3 Insertion Anomalies An insertion anomaly occurs when you cant enter a record because some data is missing. Consider a database with the rule that every employee must be assigned to a project, but a newly hired employee doesnt have a project yet. One solution is to create a dummy project, but this puts bad data into your database and is not a good idea. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.3

4 Entity and Table: Insertion Anomaly Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.4 EmployeeKeyEmployeeLastNameEmployeeFirstNameProjectNameProjectDescription 4123BrownRichardDB245New Employee Database 4124SandersonLisaDB134 Tune the point of sale database 4215LewisWallaceDB245New Employee Database

5 Update Anomalies Update anomalies occur when the same data is stored in more than one place. This means whenever you have to make a change to the data, you must do it in several places. The more times you have to edit the same data in multiple places, the more chances you have of making a mistake, causing inconsistent data. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.5

6 Deletion Anomalies Deletion anomalies occur when deleting a record accidently causes other data to be lost. Look again at the table from the slide about insertion anomalies. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.6

7 Deletion Anomaly Example EmployeeKeyEmployeeLastNameEmployeeFirstNameProjectNameProjectDescription 4123BrownRichardDB245 New Employee Database 4124SandersonLisaDB134 Tune the point of sale database 4215LewisWallaceDB245New Employee Database Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.7 If Lisa Sanderson were the only person on project DB134, deleting her from the database would also delete the project information.

8 Normal Forms Normal forms were developed over the years to address issues of these various anomalies. The next slide contains a complete list of normal forms. We will only address the first three directly. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.8

9 All Normal Forms First Normal Form Second Normal Form Third Normal Form Boyce Codd Normal Form Fourth Normal Form Fifth Normal Form Domain Key Normal Form Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.9

10 Two Examples We will use two examples in the discussion of Normal forms: – A list of albums – A contact list spreadsheet Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.10

11 Album Example AlbumTracksArtistArtistCountry Abby Road Here comes the Sun, Octopus's Garden, Something, etc. BeatlesUK Blond on BlondRainy Day Woman, Sad Eyed Lady of the Lowlands, Stuck in Memphis with the Mobile Blues Again Bob DylanUS Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.11

12 Contact List Example 1 LastName/D eptFirstNamePhone Building codeBuilding Building Address AbleSusan BEBroadway Edison 1700 Broadway Admissions BEBroadway Edison 1700 Broadway AndersonElliot SASouth Annex 1650 Broadway AndersonJolene SASouth Annex 1650 Broadway BradleyLisa BEBroadway Edison 1700 Broadway BrownMartin SASouth Annex 1650 Broadway Information Technology SASouth Annex 1650 Broadway Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.12

13 Contact List Continued OfficeDeptTypeStatusTitle 124ADM 114MATStaffFT Program Assistant, Lab 201ITExemptDean 200 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapte5.13

14 First Normal Form (1NF) The First Normal Form involves getting rid of all repeating groups and arrays. Repeating groups can be lists of values separated by commas. They can also be enumerated fields such as phone1, phone2 etc. Also, to meet 1NF, every column should contain only one type of data. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.14

15 Album List 1NF The Tracks field in the Album table is multivalued. It contains a list of the tracks associated with the album. This violates 1NF. It is tempting to try to create a series of fields like Track1, Track2...Track13. This also violates 1NF and is a bad idea for several reasons: – What if there were 14 tracks? – What if there were only 4? – To find any 1 track, you would have to query 13 fields. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.15

16 Temporary Solution Albums 1NF AlbumTitleTrackArtistArtistCountry Abby RoadHere Comes the SunBeatlesUK Abby RoadOctopus's GardenBeatlesUK Abby RoadSomethingBeatlesUK Blond on BlondRainy Day WomanBob DylanUS Blond on Blond Sad Eyed Lady of the Lowlands Bob DylanUS Blond on BlondStuck in Mobile with the Memphis Blues Again Bob DylanUS Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.16 The tracks are no longer listed. Each is separated into individual rows. Each row is unique. Still, there is a lot of redundancy.

17 Contact List Example 1NF The contact spreadsheet has several problems: – The Lastname/Dept column stores two different types of values: employee names and department names. – Also some employees such as Lisa Bradley have more than one title. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.17

18 Contact List Solution The solution is to separate the Department and LastName into different columns. The title we will break out into a separate Entity and then create a linking entity. To do that we will need to provide primary keys. We will use a surrogate key for this example. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.18

19 Contact List Tables 1NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.19 ContactKeyLastNameFirstNameDeptNamePhone Building code 1AbleSusan BE 2Admissions BE 3AndersonElliot SA 4AndersonJolene SA 5BradleyLisa BE 6BrownMartin SA 7 Information Technology SA

20 Contact List Cont (1NF) Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.20 Building Building AddressOfficeDeptTypeStatus Broadway Edison 1700 Broadway Edison 1700 Broadway124ADM South Annex 1650 Broadway212ITInstructionPT du South Annex 1650 Broadway113ITInstructionPT u Broadway Edison 1700 South Annex 1650 South Annex 1650 Broadway200

21 Title and ContactTitle Tables TitleKeyTitleName 1Professor 2Program Assistant 3Dean 4Lab Assistant Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.21 ContactKeyTitleKey

22 Contact List ERD 1NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.22

23 Second Normal Form (2NF) Second Normal Form removes what are called functional dependencies. Functional dependencies are groups of columns that depend on each other rather than on the key of the table. One way to look at functional dependencies is to look at them as themes or subthemes in the data. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.23

24 Album Example 2NF In the Album table, Tracks represent a separate theme or functional dependency. TrackTitle, Artist and ArtistCountry group together separate from the Album. Artist goes with track because many albums contain tracks by multiple artists. We add primary keys to the Album and Track tables. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.24

25 Album and Track Tables (2NF) AlbumKeyAlbumTitle ABRDAbby Road BLBLBlond on Blond Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.25 TrackKeyTrackTitleAlbumKeyArtistArtistCountry HCTSHere Comes the SunABRDBeatlesUK SMTHSomethingABRDBeatlesUK OPGDOctopuss GardenABRDBeatlesUK RDWMRainy Day WomanBLBLBob DylanUs SELL Sad Eyed Lady of the Lowlands BLBLBob DylanUS SMMBStuck in Memphis with the Mobile Blues BLBLBob DylanUS

26 Album Track ERD (2NF) Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.26

27 Contact List (2NF) In the contact list, there are two distinct types of contacts: employees and departments. BuildingCode, BuildingName and BuildingAddress also constitute a functional dependency. The solution is to break both Departments and Buildings into separate entities. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.27

28 Building and Employee Tables 2NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.28 BuildingKeyBuildingCodeBuildingNameBuildingAddress 1BE Broadway Edison1700 Broadway 1SASouth Annex1650 Broadway EmployeeKeyLastNameFirstNamePhoneBuildingCode 1AbleSusan AndersonElliot AndersonJolene BradleyLisa BrownMartin OfficeDeptKeyTypeStatus

29 Department Table 2NF DeptKeyDeptAbrvDeptNameDeptPhoneBuildingCodeOffice 1HumHumanities IT Information Technology MATMath ADMAdmissions Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.29

30 Contact List ERD 2NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.30

31 Third Normal Form 3NF Third Normal Form removes more subtle dependencies called transient dependencies. Transient dependencies are where a field depends more on another column for its meaning than on the Table key. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.31

32 Album Example 3NF In the Album example, ArtistCountry is a transient dependency. It depends on ArtistName more than on the TrackKey. The solution is to break ArtistName and its dependent column ArtistCountry into its own entity. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.32

33 Album Tables 3NF AlbumKeyAlbumTitle ABRDAbby Road BLBLBlond on Blond Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.33 ArtistKeyArtistNameArtistCountry BTLSBeatlesUK BDLNBob DylanUS TrackKeyTrackTitleAlbumKeyArtistKey HCTSHere Comes the SunABRDBTLS SMTHSomethingABRDBTLS OPGDOctopuss GardenABRDBTLS RDWMRainy Day WomanBLBLBDLN SELLSad Eyed Lady of the LowlandsBLBLBDLN SMMBStuck in Memphis with the Mobile Blues BLBLBDLN

34 Album ERD 3NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.34

35 Contact List 3NF In the contact list example, two transitive dependencies exist. In the Employee table, the room column depends on the Building code. The same dependency exists in the Department table. The solution is to create a new entity called BuildingRoom. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.35

36 Employee Table 2NF EmployeeKeyLastNameFirstNamePhoneBuildingRoomKey 1AbleSusan AndersonElliot AndersonJolene BradleyLisa BrownMartin Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.36 DeptKeyTypeStatus

37 Department, EmployeeTitle. and Title Tables 2NF DeptKeyDeptAbrvDeptNameDeptPhoneBuildinRoomKey 1HumHumanities ITInformation Technology MATMath ADMAdmissions Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.37 TitleKeyTitleName 1Professor 2 Program Assistant 3Dean 4Lab Assistant EmployeeKeyTitleKey

38 Building and BuildingRoom Tables 2NF BuildingKeyBuildingCodeBuildingNameBuildingAddress 1BE Broadway Edison1700 Broadway 1SASouth Annex1650 Broadway Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.38 BuildingRoomKeyBuildingKeyRoom

39 Contact List ERD 3NF Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.39

40 Denormalization Sometimes it is necessary to denormalize a table for performance reasons. Denormalization is where you recombine tables that were split apart to conform to the rules of the various normal forms. Denormalization should never be done lightly, because it opens up your database to the anomalies and errors normalization was designed to eliminate. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.40

41 Documentation You should keep every version of your ERDs as you work your way through the design and normalization process. Each ERD should contain notations about all changes and the reasons for making them. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter5.41

42 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall


Download ppt "IT203 Unit 4: Normalization Normalization Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter5.1."

Similar presentations


Ads by Google