DATA BASE MANAGEMENT SYSTEMS(DBMNORMALIZATION

Content of this SessionWhat normalization is and what role it plays in the database design process

About the normal forms 1NF, 2NF, 3NF

How normal forms can be transformed from lower normal forms to higher normal forms

That normalization and ER modeling are used concurrently to produce a good database design

That some situations require de-normalization to generate information efficiently

Database Tables and NormalizationNormalization Process for evaluating and correcting table structures to minimize data redundanciesReduces data anomalies

Works through a series of stages called normal forms: First normal form (1NF)Second normal form (2NF)Third normal form (3NF)

2NF is better than 1NF; 3NF is better than 2NFFor most business database design purposes, 3NF is as high as we need to go in normalization processHighest level of normalization is not always most desirable

The Need for NormalizationExample: Company that manages building projects

Charges its clients by billing hours spent on each contractHourly billing rate is dependent on employees positionPeriodically, report is generated that contains information displayed in Table 5.1

The Need for Normalization (continued)

The Need for Normalization (continued)Structure of data set in Figure 5.1 does not handle data very well

The table structure appears to work; report generated with ease

Unfortunately, report may yield different results depending on what data anomaly has occurred

Anomaliesinsert a new course s15, without any student enrolmentupdate course S11's descriptiondelete sid 1

The Normalization ProcessEach table represents a single subjectNo data item will be unnecessarily stored in more than one tableAll attributes in a table are dependent on the primary key

NF Definitions1NF: A table is in 1NF if: it has a primary key and it has no multi-valued attributes.2NF: A table is in 2NF if: it is in 1NF and it has no partial dependencies.3NF: A table is in 3NF if: it is in 2NF and it has no transitive dependencies. (When a non-key attribute depends on another non-key attribute, it is called a transitive dependency.)

STUDENT (Student-ID, Student-Name, Student-Phone) Key attribute Non-key attributes

Examples of Tables Not in 1NFSTUDENT(Student-ID, Student-Name, Class-Code, Grade)

QUESTION: What normal form is the above table in

ANSWER: It is not normalized at all (or it is in 0NF) because: It has multi-valued attributes: Given one student ID, Class-Code and Grade are multi-valued

sidsnamescoursecourse desccourse_grade1abcS11,s12, s13IMPA,B,C2pqrs13VIPB

1 NF

Examples of Tables Not in 2NFENROLLMENT(Student-ID, Class-Code, Class-Title, Grade)

QUESTION: What normal form is the above table in?

ANSWER: It is in 1NF because: (1) It has no multi-valued attributes. (2) However, it has partial dependency, i.e., Class-Title depends on Class-Code only, which is part of the key.

Functional Dependency

Functional Dependencies

Examples of Tables Not in 3NFCLASS (Class-Code, Class-Title, Instructor-ID, Instructor-Name)

QUESTION: What normal form is the above table in?

ANSWER: It is in 2NF because: (1) It has no multi-valued attributes. (2) It has no partial dependencies. (3) However, it has a transitive dependency since Instructor-Name depends on Instructor-ID.

2 NF

Transitive Dependency

Examples of Table in 3NFENROLLMENT (Class-Code, Student-ID, Grade)

QUESTION: What normal form is the above table in?

ANSWER: It is in 3NF because: (1) It has no multi-valued attributes. (2) It has no partial dependencies. (3) It has no transitive dependencies.

A Simplified Process of Converting Tables to 3NFIdentify all functional dependencies, i.e., identify determinants and their dependent fields.

Create tables such that every determinant becomes the PK of the table and the dependent fields become other columns of the same table.

2NF3NF

A Simplified Process of Converting Tables to 3NFEXAMPLE: PROJECT(Project#, Project-Name, Employee-ID, Employee-Name, Employee-Project-Hours)

Step 1 - Identify Functional Dependencies:Project# Project_NameEmployee-ID Employee-NameEmployee-ID, Project# Employee-Project-Hours

A Simplified Process of Converting Tables to 3NFEXAMPLE: PROJECT(Project#, Project-Name, Employee-ID, Employee-Name, Employee-Project-Hours)

Step 2 - Define Tables:

PROJECT (Project#, Project_Name)EMPLOYEE (Employee-ID, Employee-Name)PROJECT_ASSIGNMENT(Employee-ID, Project#, Employee-Project-Hours)

BoyceCodd Normal Form

Eliminates all redundancy that can be discovered by functional dependencies

But, we can create a normal form more restrictive called 4NF

BoyceCodd Normal Form

A relation schema R is in BCNF with respect to a set F of functional dependencies if, for all functional dependencies in F+ of the form , where R and R, at least one of the following holds:

is a trivial functional dependency (that is, ). is a super key for schema R.

A database design is in BCNF if each member of the set of relational schemas that constitute the design is in BCNF

ExampleCustomer-schema = (customer-name, customer-street, customer-city)customer-name customer-street customer-city

Branch-schema = (branch-name, assets, branch-city)branch-name assets branch-city

Loan-info-schema = (branch-name, customer-name, loan-number, amount)loan-number amount branch-name

(customer-name: candidate key)

Loan-info-schema (not in BCNF)Loan-info-schema= (Branch name, customer-name, loan-number, amount)

(Downtown, John Bell, L-44, 1000)(Downtown, Jane Bell, L-44, 1000)

Loan number is not a candidate keyHowever the functional dependency loan-number amount is nontrivial.Hence Loan-info-schema does not satisfy the definition of BCNF.

BCNF Decomposition

The definition of BCNF can be used to directly test if a relationship is in BCNF

If a relation is not in BCNF it can be decomposed to create relations that are in BCNF

Exampleborrower = (customer_id, load_number)

Is BCNF because no nontrivial functional dependency hold onto it

loan = (loan_number, amount)

Has one nontrivial functional dependency that holds, loan_numberamount, but loan_number is a superkey so loan is in BCNF

3NF vs BCNF

BCNF requires that all nontrivial dependencies be of the form , where is a super key

3NF relaxes this constraint a little bit by allowing nontrivial functional dependencies

End of Session