Database Normalization. (Olav Dæhli 2018)

Transcription

1 Database Normalization (Olav Dæhli 2018) 1

2 What is normalization and why normalize? Normalization: A set of rules to decompose relations (tables) into smaller relations (tables), without loosing any data dependencies. The reason for doing this, is to avoid: duplicates, when not needed redundant data, when not needed unnecessary null values (because it makes selections and joins more difficult) anomalies when updating data (when the same data have to be updated several places) 2

3 Redundancy and Anomalies Redundant data Data that are unnecessary to store in the database Duplicated data (the same information stored in several places) Information that can be derived/calculated from other data Anomalies Age from BirthDate Price inclusive VAT (Value Added Tax) calculated from price exclusive VAT When the same data are stored in several places, update anomalies can occure 3

4 Functional Dependency X -> Y (means that Y is functionally dependent of X) X and Y can be either one attribute (column) or a set of attributes (columns) (X1, X2,..., X i -> Y1, Y2,... Y j ) X is called a determinant, since X functionally determines Y. We have to know the meaning of X and Y to deside if a functional dependency exists. Example: PostalCode -> City (a specific postal code will always reference the same city). There exists a functional dependency between PostalCode and City, with PostalCode as a determinant. 4

5 Functional Dependency (FD) To know if a functional dependency exists, the data relations have to be analyzed by someone who knows the meaning of the data FD 1 FD 2 FD 3 5

6 Superkey A Superkey is one or more attributes (columns) in a relation (table), that uniquely determines all the attributes (columns) in the relation (table) All the attributes together (in a table) will always be a Superkey. Example: RegNumber, CarMake, Color, OwnerId, OwnerId, OwnerLastName, PostalCode, City But lots of other combinations will also be Superkeys. Examples: RegNumber, CarMake, Color, OwnerId, OwnerId, OwnerLastName, PostalCode, RegNumber, OwnerId, PostalCode RegNumber 6

7 Candidate Key A Candidate Key is a minimal Super Key Criteria 1: If any attributes are removed from a Candidate Key, it will loose its characteristics as a Super Key A Candidate Key is a «candidate» to be a Primary Key (A Primary Key is always selected amongst the Candidate Keys) Criteria 2: Since it must have the ability to act as a Primary Key, it must be able to uniquely identify each and every row in the table 7

8 Candidate Key - Examples This is not a Candidate Key (but it is a Superkey): RegNumber, CarMake, Color, OwnerId, OwnerLastName, PostalCode, City This is a Candidate Key: RegNumber Case: PROJECTMEMBER (ProjectId, EmployeeId, HoursWorked) This is a Candidate Key: ProjectId, EmployeeId This is not Candidate Keys ProjectId (neither a Superkey nor a Candidate Key) EmployeeId (neither a Superkey nor a Candidate Key) ProjectId, EmployeeId, HoursWorked (a Superkey, but not a Candidate Key) 8

9 Using letters instead of column names When the functional dependencies are described, letters (instead of column names) is often used to simplify the expression 9

10 Normalization Criterias 1NF 2NF Only «atomic» values for each attribute No partial functional dependencies 10 3NF No transitive functional dependencies BCNF No other functional dependencies The goal is to achieve at least 3NF

11 First normal form (1NF) Criteria: Only «atomic» values for each attribute Any multivalued attributes (repeating groups) have to be removed Example: Repeating groups (violates the 1NF-rule) 11

12 First normal form (1NF) One solution is to make one column for each car Problems: 1) How many columns do we need? 2) It will result in many NULL-values 2) It will complicate search for data This is a bad solution. We want to expand the number of rows, not the number columns 12

13 First normal form (1NF) - Normalization Make a new table Move the repeating values to the new table To preserve the functional dependency, the repeating values will act as Primary Key and a new attributt will act as a Foreign key to the original table Primary Key Foreign Key 13

14 Second normal form (2NF) The table must satisfy 1NF A Primary Key has to be chosen (amongst the Candidate Keys) To qualify for 2NF, no non-key attributes can be dependant of only a part of the Primary Key (ie. «partial dependency» is not allowed) NB! Only relevant when the Primary Key consists of more than one attribute (Combined Primary Key) Primary Key Partial Functional Dependency. C is dependant of a part of the Primary Key (B). This violates the 2NF-rule. 14

15 Second normal form (2NF) - Normalization Split the table into two tables. Remove the partial dependency, and make it a new table B will become a Foreign Key 15

16 Second normal form (2NF) - Example Splits the table into two tables without 2NF-violations CourseId will become a Foreign Key 16

17 Third normal form (3NF) The table must satisfy 2NF A Primary Key has to be chosen (amongst the Candidate Keys) No transitive functional dependencies from the Primary Key is allowed (which means that dependencies between non-key attributes will break the rule) Breaks the rule of the 3NF criteria A -> F and F -> G (and then: A -> G) is a Transitive Dependency Breaks the rule of the 3NF criteria 17

18 Third normal form (3NF) - Normalization Normalized to 3NF 1 Still breaking the 3NF-rule 2 3 Normalized to 3NF Normalized to 3NF 18

19 Third normal form (3NF) - Example Normalized to 3NF 1 Still breaking the 3NF criteria 2 Normalized to 3NF Normalized to 3NF 3 19

20 Third normal form (3NF) - Example The result is that we end up with three 3NF-normalized tables, where all the original dependencies are preserved (through Foreign Keys): Foreign Key Foreign Key 20

21 BCNF (Boyce Codd Normal Form) This is very rare condition in practice, so we only take a brief look at it BCNF is achieved by removing all other dependencies than specified in 2NF and 3NF To meet the requirements of BCNF, every determinant in the relation (table) have to be a Candidate Key BCNF-violation can only occur in relations (tables) with more than one composite Candidate Key, where at least one common attribute overlaps. In other cases, 3NF and BCNF will be equivalent 21

22 BCNF - Example Goal: A database for arranging parent-teacher conferences at a school Table Name: PARENT_TEACHER_CONFERENCE Constraint: A teacher is always assigned the same room for all the conferences listed on the same date. Various teachers can use the same room. Table before normalization: We start with the Universal Relation: (All the data we want to register) Date Time Teacher Pupil Room 22

23 BCNF Example: Identifing dependencies Candidate Key 1 (CK1) Candidate Key 2 (CK2) CK2 CK1 A third functional dependency which is not a Candidate Key. This violates the BCNF-criteria. 23

24 BCNF Example: Normalization-solution Remove the attributes involved in the functional dependency that violates BCNF, and place them in a new, separate table The remaining part becomes the second table Both dependencies is now Candidate Keys and no other dependencies exist in the relation (table) 24

25 Normalization - A step by step-strategy 1) Start with the Universal Relation (all the attributes from all the tables) 2) Analyze the data to reveal all the functional dependencies 3) Remove any repeating values (1NF-criteria) 4) Identify all Candidate Keys 5) Select a Primary Key 6) Remove any partial dependencies (to achieve 2NF) 7) Remove any transitive dependencies (to achieve 3N) 8) Remove any remaining dependencies (to achieve BCNF) 25

26 Problems with Normalization Normalization leads to smaller tables Smaller tables (and more foreign keys) complicates inserting data Normalization increases the need for joining tables when performing queries against the table. More duplicated data, because of more foreign keys (but less redundancy of the same reason, which is positive) 3NF is often the goal (because the rules of BCNF is more complicated to maintain than the rules of 3NF) 26