7 Final Normalization[1]

7/23/2019 7 Final Normalization[1]

1/56

1

NormalizationNormalization

Module 4
http://www.pdfonline.com/easypdf/?gad=CLjUiqcCEgjbNejkqKEugRjG27j-AyCw_-APhttp://www.pdfonline.com/easypdf/?gad=CLjUiqcCEgjbNejkqKEugRjG27j-AyCw_-AP


2/56

2

Normalization- DefinitionNormalization- Definition

Normalization is the process of discarding repeating groups,minimizing redundancy, eliminating composite keys for partial

dependency and separating non-key attributes.

In simple terms : "Each attribute (column) must be a fact about

the key, the whole key, and nothing but the key." Said anotherway, each table should describe only one type of entity (information).


3/56

3

Normalization- OverviewNormalization- Overview

Normalization is theprocess of efficiently organizing data in a database.

Two objectives

Eliminate redundant data

Ensure data dependencies make sense

Reduce the amount of space a database consumes and ensure that data islogically stored.

It is part of successful database design.

Without normalization, database systems can be- inaccurate,

- slow,

- and inefficient

- and they might not produce the data you expect.


4/56

4

What Should we achieve when normalizing adatabase?.

What Should we achieve when normalizing adatabase?.

Arranging data into logical groups

Minimizing the amount of duplicated data

Access and manipulate the data quickly and efficiently

Make the changes in only one place

PS: Sometimes database designers refer to these goals in terms

such as data integrity, referential integrity, or keyed data access.


5/56

5

Normalization- OverviewNormalization- Overview

Normalisation is a theory for designing relational schema that makesense and work well.

Well-normalised tables avoid redundancy and thereby reduce

inconsistencies.

Redundancy is unnecessary duplication.

In well-normalised DBs semantic dependencies are maintained by

primary key uniqueness.


6/56

6

Goals of NormalisationGoals of Normalisation

Eliminate certain kinds of redundancy

avoid certain update anomalies

good representation of real world

simplify enforcement of DB integrity


7/56

7

Update anomaliesUpdate anomalies

Undesirable side-effects that occur when performaing insertion,

modification or deletion operations on badly designed relational

DBs.

SSN

987

654

333

321

678

467

Name

J Smith

M Burke

A Dolan

K Doyle

O ONeill

R McKay

Dept

1

2

1

1

3

2

DeptMgr

321

467

321

321

678

467

Representing

Department info

in the Employeetable causes

problems.

Dept Name

...


8/56

8

Sample anomaliesSample anomalies

Modification - when the manager of a dept changes we have to change many values.

If we are not careful the DB will contain inconsistencies.

There is no easy way to get the DB to ensure that a department has only

one manager and only one name.


9/56

9

Anomalies continuedAnomalies continued

Deletion -

if O ONeill leaves we delete his tuple and lose

- the fact that there is a department 3

- the name of dept 3

- who is the manager of dept. 3

Insertion

how would we create a new department before any employees are

assigned to it ?


10/56

10

Better designBetter design

Separate entities are represented in separate tables.

SSN

987

654

333

321

678

467

Name

J Smith

M Burke

A Dolan

K Doyle

O ONeill

R McKay

Dept

1

2

1

1

3

2

Dept

1

2

3

DeptMgr

321

467

678

Dept Name

...


11/56

11

Poor database design usually includePoor database design usually include

Repetition of information

Inability to represent certain information

Loss of information

Difficulty to maintain information


12/56

12

Normalization stagesNormalization stages

1NF - First normal form

2NF - Second normal form

3NF - Third normal form

BCNF Boyce Codd's Normal Form

4NF - Fourth normal form

5 NF- Fifth Normal Form


13/56

13

Un Normalized FormUn Normalized Form

Un-normalised data = repeating groups, inconsistent data,

delete and insert anomalies


14/56

14

First Normal FormFirst Normal Form

By analyzing above data the Observation are:

PRO_NUM intended to be primary key

Table entries invite data inconsistencies

Table displays data anomalies

- Update- Modifying JOB_CLASS

- Insertion

- New employee must be assigned project

- Deletion

- If employee deleted, other vital data lost


15/56


16/56

16

First Normal FormFirst Normal Form

Converting the above data to INF the following rules to be followed Repeating groups must be eliminated

Proper primary key developed

Uniquely identifies attribute values (rows).

Dependencies can be identified

- Total dependency Desirable dependencies based on primary key

- Less desirable dependencies

Partial - based on part of composite primary key

- Transitive - one nonprime attribute depends on another nonprime attribute


17/56

17

After 1 NF DataAfter 1 NF Data


18/56

18

Functional Dependency DiagramFunctional Dependency Diagram

Partial - based on part of composite primary key

Transitive - one nonprime attribute depends on another

nonprime attribute


19/56

19

Second Normal FormSecond Normal Form

Second Normal Form (2NF) = ELIMINATE REDUNDANT DATA (ifan attribute depends on only part of multi-valued key, remove it

to a separate table).

Table is in 2NF if it met all database requirements for 1NF, and if

each non-key attribute is fully functionally dependent on thewhole primary key;

Data, which does not directly dependent on tables primary key must

be moved into another table.


20/56

20

Second Normal FormSecond Normal Form

2NF meets the following criteria:

Each table contains all atomic data items, no repeating groups,

and a designated primary key (no duplicated rows).

Each table has all non-primary key attributes fully functionallydependant on the whole primary key


21/56

21

Steps of Second Normal FormSteps of Second Normal Form

Start with 1NF format:

Write each key component on separate line

Write original key on last line

Each component is new table

Write dependent attributes after each key


22/56

22

Second Normal Form 2NFSecond Normal Form 2NF


23/56

23

Data After Second Normal FormData After Second Normal Form


24/56

24

Second Normal Form SummarySecond Normal Form Summary

Should be in 1NF( Refer First Normal Form)

Includes no have any partial dependencies


25/56

25

Third Normal FormThird Normal Form

Create separate table(s) to eliminate transitive functionaldependencies

Third Normal Form (3NF) = ELIMINATE COLUMNS NOT

DEPENDANT ON KEY (if attributes do not contribute to a

description of the key remove them to a separate table).

Table is in 3NF if it met all database requirements for both 1NF

and 2NF.

All transitive dependencies are eliminated Each column must depend directly on the primary key;

All attributes that are not dependant upon the primary key must be

eliminated.


26/56

26

Third Normal FormThird Normal Form

3NF meets the following criteria: Each table contains all-atomic data items, no repeating groups, and a

designated primary key

Each table has all non-primary key attributes fully functionally

dependant on the whole primary key

All transitive dependencies are removed from each table


27/56

27

After 3 NF DataAfter 3 NF Data

In 2NF Contains no transitive dependencies


28/56

28

After Third Normal FormAfter Third Normal Form


29/56

29

Boyce-Codds Normal FormBoyce-Codds Normal Form

After a lot of other approaches Boyce and Codd noticed a simple rulefor ensuring tables are well-normalised. Tables which obey the rule

are in BCNF (Boyce Codd Normal Form).

BCNF rule:Every determinant in a table must be a candidate key for that

table.


30/56

30

DeterminantsDeterminants

A is a determinant of B if each value of A has precisely one(possibly null) associated value of B.

Said another way -

A is a determinant of B if and only if whenever two tuples agree on

their A value they agree on their B value.

A B


31/56

31

DeterminantsDeterminants

Note that determinacy depends on semantics of data cannot bedecided from individual table occurrences.

Alternative terminology

if A (functionally) determines B then B is (functionally) dependent on A


32/56

32

Example determinantsExample determinants

SSN determines employee name SSN determines employee department

Dept. No. determines Dept. Name

Dept. Name determines Dept. No.

assuming Dept. names are also unique

Emp. Name does not determine Emp. Dept

two John Smiths could be in difft. Depts.

Emp. Name does not determine SSN.


33/56

33

Determinacy DiagramDeterminacy Diagram

SSN

Name

Department Dept. Name

Dept. Mgr

In general key attributes of an entity determine all the

single-valued attributes of the entity.


34/56

34

Composite DeterminantsComposite Determinants

(SSN, Project#) together determine

the hours that the employee works

on the project. SSN

Project#

hours

PName

Name


35/56

35

Transitive DependenciesTransitive Dependencies

SSN actually determines DeptMgr but only because

SSN determines DeptNo and

DeptNo determines DeptMgr.

Be careful to remove transitivedependencies.

They mess up normalisation.

SSN

DeptNo

Dept. Mgr


36/56

36

Candidate keysCandidate keys

candidate key = any attribute or set of attributes which will be

unique for a table (set of attributes).

As well as the primary key there may be other candidate keys.

E.g. DNUMBER and DNAME are both candidate keys for the

Department table. Key = row identifier

Candidate key = candidate identifier


37/56

37

Finding candidate keysFinding candidate keys

Every key is by definition a determinant of all other attributes in arelation.

So in a diagram, any attribute (or composite) from which all other

attributes are reachable is a candidate key.

SSN

Project#hours

PName

Name

(SSN, Project#) is a

(composite) candidatekey for a table

containing these five

attributes.


38/56

38

What are the candidate keys ?What are the candidate keys ?

D

E

F

G H J

K

L

M

N

P Q R

S

T U

student

subject

teacher

V

W

X

Y

AZ

C

B

B

D

F

E

G

H


39/56

39

Problems occur when ...Problems occur when ...

Redundancy and anomalies occur when there are determinantswhich are not candidate keys.

SSN Name

DeptNo Dept. Name

Dept. Mgr

SSN is the only key for a table containingthese attributes

all attributes are reachable from SSN.

SSN, DeptNo and DeptName aredeterminants

they have arrows coming out of them.


40/56

40

BCNF ruleBCNF rule

In well-normalised relations (Boyce-Codd normal form)every determinant is a candidate key.

SSN Name

DeptNo

Dept. Name

Dept. Mgr

DeptNo

The employee/dept table decomposed to BCNF.

Note that both DeptNo and DeptName are candidate keys of

the second table.


41/56

41

Transformation to BCNFTransformation to BCNF

Create new tables such that each non-keydeterminant is a candidate key in a new table.

The new table contains the attributes which aredirectly determined by the new candidate key.

V

W

X

Y

AZ

C

B

V X

V

WY

V

W

AZA

C

B

BCNF tables :

(V, X)(A, B, C)

(V, W, Z, A)

(V, W, Y)


42/56

42

Summarizing Normal FormsSummarizing Normal Forms

First NF - no multi-valued attributes all relational DBs are 1NF

2NF - every non-key attribute is fully dependent on theprimary key

3NF - eliminate functional dependencies between non-keyattributes

all dependencies can then be enforced by uniqueness ofkeys.

G H J

Table is in 2NF

but not 3NF


43/56

43

BCNF vs. 3NFBCNF vs. 3NF

BCNF goes further than 3NF, some say too far.

A 3NF table that has no overlapping composite keys is in BCNF.

student

subject

teacher

3NF, not BCNFkeys: (student, subject)

(student, teacher)

teacher is a determinant

student teacher

subjectteacher

BCNF

but tables are not independent

A teacher teaches only one subject.

For a given subject a given student has only one teacher.


44/56

44

Further NormalizationFurther Normalization

4NF The table should be In BCNF

The table should not Contain any multi-valued / nontrivial dependency

5NF

The table should be In 4NF

The Table should not have any join dependencies


45/56

45

1

st

Normal Form

2

nd

Normal Form

3

rd

Normal Form

Boyce Codd Normal Form

4

th

Normal Form

5

th

Normal Form

Normalized relational db

model

Relational db model A series of steps followed to obtain a databasedesign that allows for consistent storage and

avoiding duplication of data

A process of decomposing relationships with

anomalies

The normalization process passes through

fulfilling different Normal Forms

A table is said to be in a certain normal form if

it satisfies certain constraints

Originally Dr. Codd defined 3 Normal Forms,later on several more were added

For most practical purposes databases are

considered normalized if they adhere to

3rd Normal Form

Normalization


46/56

46

Queries against a fully normalized database often perform poorly

Explanation:Current RDBMSs implement the relational model poorly.

A true relational DBMS would allow for a fully normalized database at

the logical level, while providing physical storage of data that is tuned

for high performance.

Two approaches are used

Approach 1: Keep the logical design normalized, but allow the DBMS

to store additional redundant information on disk to optimize

query response (indexes, materialized views, etc.).

In this case it is the DBMS software's responsibility to ensurethat any redundant copies are kept consistent.

Approach 2: Use denormalizationto improve performance,

at the cost of reduced consistency

Denormalization


47/56

47

Demoralizationis the process of attempting to optimize the performance

of a database by adding redundant data

This may achieve (may not!)an improvement in query response, but

at a cost

There should be a new set of constraintsadded that specify how theredundant copies of information must be kept synchronized

Denormalization can be hazardous: increase in logical complexity of the database design

: complexity of the additional constraints

It is the database designer's responsibility to ensure that the denormalized

database does not become inconsistent

Denormalization


48/56

48

On lighter NoteOn lighter Note


49/56

49

Questions and Answers


50/56

50

Thank you for your attention!

End;


51/56

51

Codds RulesCodds Rules

proposed by Edgar F. "Ted" Codd, a pioneer of the

relational model for databases,

Rule 0: The system must qualify as relational, as a

database, and as a management system.

For a system to qualify as a RDBMS, that system must use its

relationalfacilities (exclusively) to manage the database


52/56

52

Codds Rules (Cont.)Codds Rules (Cont.)

Rule 1: The information rule:

All information in the database to be represented in one and only one way,

namely by values in column positions within rows of tables.

Rule 2 : The guaranteed access rule: All data must be accessible with no ambiguity.

This rule is essentially a restatement of the fundamental requirement for primary

keys.

It says that every individual scalar value in the database must be logically

addressable by specifying the name of the containing table, the name of the

containing column and the primary key value of the containing row.


53/56

53


Rule 3: Systematic treatment of null values: The DBMS must allow each field to remain null (or empty).

It must support a representation of "missing information and inapplicable

information" that is systematic, distinct from all regular values and independent of

data type.

It is also implied that such representations must be manipulated by the DBMS in

a systematic way.

Rule 4:Active online catalog based on the relational model:

The system must support an online, relational catalog that is accessible toauthorized users by means of their regular query language.

Users must be able to access the database's structure (catalog) using the same

query language that they use to access the database's data.


54/56

54


Rule 5: The comprehensive data sublanguage rule:

The system must support at least one relational language that

- Has a linear syntax

- Can be used both interactively and within application programs,

- Supports data definition operations (including view definitions), data manipulation

operations (update as well as retrieval), security and integrity constraints, and

transaction management operations (begin, commit, and rollback).

Rule 6: The view updating rule:

All views that are theoretically updatable must be updatable by the system.

Rule 7: High-level insert, update, and delete: The system must support set-at-a-time insert, update, and delete operators.

- This means that data can be retrieved from a relational database in sets constructed of

data from multiple rows and/or multiple tables.

This rule states that insert, update, and delete operations should be supported for

any retrievable set rather than just for a single row in a single table.


55/56

55


Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked

lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require achange to an application based on the structure.

Logical data independence is more difficult to achieve than physical data

independence.

Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and

stored in the catalog.

It must be possible to change such constraints as and when appropriate without

unnecessarily affecting existing applications.


56/56

56


Rule 11: Distribution independence: The distribution of portions of the database to various locations should be

invisible to users of the database.

Existing applications should continue to operate successfully :

- when a distributed version of the DBMS is first introduced; and

- when existing distributed data are redistributed around the system.

-

Rule 12: The nonsubversion rule:

If the system provides a low-level (record-at-a-time) interface, then that

interface cannot be used to subvert the system

For example, bypassing a relational security or integrity constraint.

7 Final Normalization[1]

Documents

Transcript of 7 Final Normalization[1]