S03 Slides Normalisation v001 - secure.com.sgsecure.com.sg/courses/ICT285/S02_Extra_Slides_Normalisation_Ron.… · S05 Edwina Elocution School Dean 24000LH53 Hopeless Causes x003

Normalisation

Databases: Topic 4

Resources for this TopicReadings (text):

- Chapter3

Other Readings:- Chapple,M(n.d)DatabaseNormalizationBasics,Retrievedfrom

http://databases.about.com/od/specificproducts/a/normalization.htm- (2008)NormalizationExample,

http://www.youtube.com/watch?v=uO80f642LCY

Topic ObjectivesThis topic aims to introduce you to normalisation as an important process in relational database design. It addresses the following unit learning objectives:• Demonstrate an understanding of database principles and theory, particularly those relating

to the Relational Model• Design a database, demonstrating practical skills in normalisation and data modelling

In order to achieve the unit learning objectives, on successful completion of this topic, you should be able to:• Define and explain the types of modification anomalies associated with redundant information in

tables• Explain the purpose of normalisation• Identify functional dependencies among attributes• Define, and use examples of as appropriate, the following terms:

• Partial functional dependency• Transitive functional dependency

• Give definitions of the following:• 1NF• 2NF• 3NF• BCNF

• Be able to identify which normal form a given relation is in• Normalise a given relation to a more appropriate normal form• Discuss some limitations that may be associated with normalisation

TopicOutline

• Relationaldesignguidelines• Modificationanomalies

• Insertion• Deletion• Update

• Functionaldependencies• Normalforms:

• 1NF,2NF,3NF,BCNF

• Limitationsofthenormalisationprocess

1. Relational Design Guidelines

Normalisation

- Normalisation is a technique for producing a set of suitable relations that support the data requirements of an enterprise.

- Characteristics of a suitable set of relations include: - theminimalnumberofattributes necessarytosupportthe

datarequirementsoftheenterprise;- attributeswithacloselogicalrelationshiparefoundinthesame

relation;- minimalredundancy witheachattributerepresentedonlyonce

withtheimportantexceptionofattributesthatformallorpartofforeignkeys.

Why bother?

- Bad/poor/suboptimal designs:- havenegativeimpactsontheperformanceofthe

database- havenegativeimpactsontheabilityofthe

databasetobeusedfordecisionmaking

Some “high level” design guidelines

- Relationsshouldbesimpletounderstand- Thismeanstheyshouldcorrespondtoasingle“real-world”

concept- Relationsshouldnothaveanyupdateanomalies

- Normalisationshouldremovetheseanomalies- Usuallythedatabasewillcontainseveralrelations.Design

shouldensurethatrelationscanbejoined (togetinformationfrommorethanonerelation)withoutgenerating'extra'records- Thisisdonebyensuringthatanyjoinswillbemadebetweenthe

primarykeyofonerelationandtheforeignkeyoftheother- Functionaldependencies thatexistintheoriginaldata

shouldbepreserved inthedatabasedesign

2. Modification Anomalies

Modification Anomalies

- Modification anomalies may arise when data in a relation containing redundant data are modified

- They lead to inconsistency in the database:- Insertionanomalies

- Theneedtoentermoredatathanisrequired

- Updateanomalies- Notallinstancesofdataupdate

- Deletionanomalies- Theunintentionaldeletionofdata

- GOOD DESIGN IS THE BEST WAY TO AVOID INCONSISTENCIES

Examples…

• INSERTION ANOMALY: To insert a new unit in the example above, it is necessary to know a student and an offering of the unit.

• UPDATE ANOMALY: If we change Mary’s address we need to change two rows

• DELETION ANOMALY: if we delete Bruce’s enrolment in Databases in Semester 1, 2010, we lose all information regarding that offering.

StudentID StudentName Address UnitCode UnitTitle Offering Mark20012001 Bruce 1RandomCres ICT218 Databases S12010 6520012001 Bruce 1RandomCres ICT231 SystemsAnalysisandDesign S12010 6220011999 Mary 46TheMews ICT231 SystemsAnalysisandDesign S12010 4820011999 Mary 46TheMews ICT218 Databases S22009 50

Can you identify how anomalies could occur in this relation?

StaffNum Name Position Salary SchoolNum School SchoolPhone

S21 BarryBrightwater SchoolDean 30000MH47 Happiness x005

S37 DelorisDelight Lecturer 12000LH53 HopelessCauses x003

S14 CarrieCumbersome Professor 18000LH53 HopelessCauses x003

S09 AlbertAlgorithm SchoolDean 9000XS67 LowSelfEsteem x007

S05 EdwinaElocution SchoolDean 24000LH53 HopelessCauses x003

S41 FrankForensic Cleaner 9000MH47 Happiness x005

Are those problems resolved?StaffNum Name Position Salary SchoolNum

S21 BarryBrightwater SchoolDean 30000MH47

S37 DelorisDelight Lecturer 12000 LH53

S14 CarrieCumbersome Professor 18000 LH53

S09 AlbertAlgorithm SchoolDean 9000XS67

S05 EdwinaElocution SchoolDean 24000 LH53

S41 FrankForensic Cleaner 9000MH47

SchoolNum School SchoolPhone

MH47 Happiness x005

LH53 HopelessCauses x003

XS67 LowSelfEsteem x007

Decomposition of Relations

- When decomposing relations in the normalisation process, two important facets of the original data must be preserved:- LosslessJoin

- Anyinstanceoftheoriginalrelationcanbeidentifiedfromthedecomposedrelations

- DependencyPreservation- Anyconstraintontheoriginalrelationcanbemaintainedbyenforcingtheconstraintoneachofthesmallerrelations

Do we have lossless-joins here?

StaffNum Name Position Salary SchoolNum School SchoolPhone

S21 BarryBrightwater SchoolDean 30000MH47 Happiness x005

S37 DelorisDelight Lecturer 12000 LH53 HopelessCauses x003

S14 CarrieCumbersome Professor 18000 LH53 HopelessCauses x003

S09 AlbertAlgorithm SchoolDean 9000XS67 LowSelfEsteem x007

S05 EdwinaElocution SchoolDean 24000 LH53 HopelessCauses x003

S41 FrankForensic Cleaner 9000MH47 Happiness x005

StaffNum Name Position Salary SchoolNumS21 BarryBrightwater SchoolDean 30000MH47S37 DelorisDelight Lecturer 12000 LH53S14 CarrieCumbersome Professor 18000 LH53S09 AlbertAlgorithm SchoolDean 9000XS67S05 EdwinaElocution SchoolDean 24000 LH53S41 FrankForensic Cleaner 9000MH47

SchoolNum School SchoolPhoneMH47 Happiness x005LH53 HopelessCauses x003XS67 LowSelfEsteem x007

3. Functional Dependencies

Functional Dependencies

- Normalisation is a way of transforming an unsatisfactory relation schema (one with modification anomalies) into a 'better' design by reducing redundancy

- A functional dependency is a relationship between attributes such that the value of one attribute can be found from the value of another

Why bother?

- FDs represent information about the system we are modelling which should be preserved

- Normal forms 1NF, 2NF, 3NF and BCNF are based on functional dependencies between the attributes in a relation (higher normal forms are based on other dependencies)

X à Y

We can say that X determines Y if:- Thereexistsatmost onevalueofY forevery

valueofX- Forexample:wecansaythatstudentnumber

determinesdateofbirthasforeachstudentnumberthereisoneandonlyonedateofbirth.- Canwesaythatstudentnamedetermines

studentnumber?

Example:

Considerthefollowingrelation:

EMPLOYEE(EmployeeID,Name,Address,DeptNo)

ifthevalueofEmployeeIDisknown,thevaluesofName,AddressandDeptNocanbefound- inotherwords:

Name,Address,DeptNoarefunctionallydependent onEmployeeIDEmployeeIDfunctionallydetermines Name,Address,DeptNoEmployeeIDiscalledthedeterminant oftheFD

Writing FDs

We can write FDs as:EmployeeID ® Name, Address, DeptNo

OR…® Name

EmployeeID ® Address® DeptNo

(StudentNo, Unit, Semester, Year) ®Grade

Some rules about FD’s

- Reflexivity- IfYÍ X,thenXà Y

- Augmentation- IfXà Y,thenXZà YZ

- Transitivity- IfXà Y,andYà Z,thenXà Z

- Decomposition- IfXà YZ,thenXàYandXàZ

- Union- IfXà Y,andXà Z,theXà YZ

Example:

What functional dependencies can you identify in the following relation (assuming the data is representative)? List only the direct dependencies

StudentID Name Course OfferingNo Semester Year Grade UnitCode TitleS1 Kyle IT 4678 1 2014HD ICT231 SystemsAnalysisS1 Kyle IT 4679 1 2013D ICT208 BIT&TS2 Helen IT 4678 1 2014D ICT231 SystemsAnalysisS2 Helen IT 4670 1 2013C ICT218 DatabasesS2 Helen IT 4743 2 2012N ICT218 Databases

StaffNum Name Position Salary SchoolNum School SchoolPhoneS21 BarryBrightwater SchoolDean 30000MH47 Happiness x005S37 DelorisDelight Lecturer 12000LH53 HopelessCauses x003S14 CarrieCumbersome Professor 18000LH53 HopelessCauses x003S09 AlbertAlgorithm SchoolDean 9000XS67 LowSelfEsteem x007S05 EdwinaElocution SchoolDean 24000LH53 HopelessCauses x003S41 FrankForensic Cleaner 9000MH47 Happiness x005


Example:



Example:



Example:

FD’s and PK’s

AprimarykeyissimplyamorerestrictivetypeofFD- aFDinwhichthevalueofthedeterminantisunique

eg.Intherelation:

EMP_DEPT(EmpID,Name,Address,DeptNo,DeptName)

wehavetheFDs:

EmpID® Name,Address,DeptNo,DeptNameDeptNo® DeptName

InanyinstanceofEMP_DEPTthesameDeptNo mayoccurmanytimes,butthevalueforEmpID (theprimary key)isunique

Deriving PK’s from FD’s

If we do not know the candidate key(s) of a relation, they can be found:

- Fromthesemantics(meaning)oftherelation- ByexaminingtheFDsthatoccurintherelation

- wecanuseadependencydiagram toidentifytheminimumcombinationofattributesfromwhichallotherscanbefound

Example:

What is the candidate key of this relation?

Here, staffNum is the determinant –Name, Position, salary and SchoolNum

are determined by staffNum

SchoolNumàSchool, Phone


Dependency Diagrams

4. Normal Forms

Normal Forms

- As above, we are most interested in 1NF, 2NF, 3NF and BCNF- Forpracticalpurposes,weusuallyaimtohaverelationsin3NForBCNF,althoughdenormalisation cansometimesbenecessaryforperformancereasons

1NF -- BCNF

Each NF become progressively more restrictive the higher the NF; the definition of any NF includes the definition of the preceding NF

- 1NF:All valid relations are in 1NF

- 2NF:1NF PLUS no partial functional dependencies

- 3NF:2NF PLUS no transitive functional dependencies

- BCNF: 3NF PLUS all determinants are candidate keys

First Normal Form (1NF)

- For a relation to be in 1NF, it needs to be a valid relation- Norepeatinggroupsornestinginrelations- ThisrelationisNOTin1NF(i.e.,itis

unnormalised)

StudentID Name Course OfferingNo Semester Year Grade UnitCode TitleS1 Kyle IT 4678 1 2012HD ICT231 SystemsAnalysis

4679 1 2012D ICT208 BIT&TS2 Helen IT 4678 1 2012D ICT231 SystemsAnalysis

4670 1 2012C ICT218 Databases4743 2 2011N ICT218 Databases

Solution…

- Can you find examples of modification anomalies in this design?





- Repeat StdID, Name and Course for each tuple

Solution…







UpdateAnomaly

}

Solution…







InsertionAnomaly

Add student Jones: S3, Jones

Solution…







InsertionAnomaly

Add unit ASAD: ICT353, SAD

Solution…







DeletionAnomaly

Second Normal Form (2NF)

- A relation is in 2NF if:- Itisin1NF,AND- Therearenopartialfunctionaldependencies

- Apartialfunctionaldependencyexistswhereanon-keyattributeisdependentononlypartofthekey,ratherthanthewholeofthekey

Partial Functional Dependencies

- Given the relation below:- WherethePKisStudentID,OfferingNo- …andtheFD’sare:

- StudentIDà Name,Course- OfferingNoà Semester,Year,UnitCode,Title- StudentID,OfferingNoà Grade


Partial Functional Dependencies

- Given the relation below:- WherethePKisStudentID,OfferingNo- …andtheFD’sare:

- StudentIDà Name,Course[PFD]- OfferingNoà Semester,Year,UnitCode,Title[PFD]- StudentID,OfferingNoà Grade


Modification Anomalies with PFD’s- There are a number of anomalies that arise from

the present design:- IfweweretochangethetitleofICT218,thenwewouldhaveto

updatethetitleforeveryofferingoftheunit- IfweweretodeletetheonlyofferingofunitICT208,thenwewould

losealldetailsofthatunit- Couldweinsertanewunitintothistable?


SolutionThe solution (for the PFDs) is to create relations based on the FD’s where the determinants are components of the primary key:

Relation1 (StdID,Name,Course)Relation2 (OfferingNo,UnitCode,Title,Semester,Year)

There is also a further functional dependency in the table on the previous slide:

StdID,OfferingNo® GradeAsthedeterminantofthisFDISthePKitwillformathirdrelation:

Relation3 (OfferingNo,StdID,Grade)

So…

- Now each nonkey attribute is fully FD on the key of the relation it is in, so each relation is in at least 2NF

- We have also eliminated the potential anomalies identified in the original relation.

Third Normal Form (3NF)

- A relation is in 3NF IF:- Itisin2NF,and- therearenotransitive functionaldependencies

(TFD’s)- ATFDexistswhereanon-keyattributeisdetermined

byanothernon-keyattribute

ExampleRelation1 (StdID,Name,Course)Relation2 (OfferingNo,Year,Semester,UnitCode,Title)Relation3 (StdID,OfferingNo,Grade)

ThereisatransitivedependencyinRelation2:OfferingNo® UnitCodeUnitCode® TitleTheTDisOfferingNoà TitlebecauseUnitCodeisanon-keyattribute

Whatkindsofanomaliesarepresentinthecurrentdesign?

StudentID Name CourseS1 Kyle ITS2 Helen IT

OfferingNo Semester Year UnitCode Title4678 1 2012 ICT231 SystemsAnalysis4679 1 2012 ICT208 BIT&T4670 1 2012 ICT218 Databases4743 2 2011 ICT218 Databases

StudentID OfferingNo GradeS1 4678HDS1 4679DS2 4678DS2 4670CS2 4743N

ExampleRelation1 (StdID,Name,Course)Relation2 (OfferingNo,Year,Semester,UnitCode,Title)Relation3 (StdID,OfferingNo,Grade)

ThereisatransitivedependencyinRelation2:OfferingNo® UnitCodeUnitCode® TitleTheTDisOfferingNoà TitlebecauseUnitCodeisanon-keyattribute

Whatkindsofanomaliesarepresentinthecurrentdesign?

StudentID Name CourseS1 Kyle ITS2 Helen IT

OfferingNo Semester Year UnitCode Title4678 1 2012 ICT231 SystemsAnalysis4679 1 2012 ICT208 BIT&T4670 1 2012 ICT218 Databases4743 2 2011 ICT218 Databases

StudentID OfferingNo GradeS1 4678HDS1 4679DS2 4678DS2 4670CS2 4743N

Solution

To transform a relation in 2NF only to a set of relations each in at least 3NF,

- Create a set of relations based on the full and non-transitive dependencies in the original:

Relation2-1 (OfferingNo,Year,Semester,UnitCode)Relation2-2 (UnitCode,Title)

- Now each attribute is fully and nontransitively dependent on the key of its relation, so each relation is in (at least) 3NF

- Note that we can join the relations on the key and foreign key

- Note too, that the original relation was about offerings ANDunits. The new relations are both about one thing only.

OfferingNo Semester Year UnitCode4678 1 2012 ICT2314679 1 2012 ICT2084670 1 2012 ICT2184743 2 2011 ICT218

UnitCode TitleICT231 SystemsAnalysisICT208 BIT&TICT218 Databases

Cheat Sheet

Note: We have a compound primary key: AID,BID

AID BID Cdata Edata Fdata Gdata

1 A xxx xxx xxx xxx

1 B xxx xxx xxx xxx

1 B xxx xxx xxx xxx

PFD TFD

Examples

Given the following relation and functional dependencies:

1. What is (are) the candidate key(s)?

2. Which NF is the relation in?

3. Convert the relation into a relation or set of relations in at least 3NF

STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School

Examples






Examples






Examples


1.What is (are) the candidate key(s)?

2.Which NF is the relation in?

3.Convert the relation into a relation or set of relations in at least 3NF

STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– ?

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– Yes,itisavalidrelation.

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– Yes,itisavalidrelation.2NF– ?

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– Yes,itisavalidrelation.2NF– Yes,nonon-keyattributesdeterminebypartialkey

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– Yes,itisavalidrelation.2NF– Yes,nonon-keyattributesdeterminebypartialkey3NF– ?

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà School1NF– Yes,itisavalidrelation.2NF– Yes,nonon-keyattributesdeterminebypartialkey3NF– No,ItisTransitive,anon-keydeterminesanon-key

TFD

Examples





STUDENT(StudentNo,Name,PrimaryMajor,School)StudentNoà Name,PrimaryMajorPrimaryMajorà SchoolSOLUTION:STUDENT(StudentNo,Name,PrimaryMajor)MAJOR(PrimaryMajor,School)

TFD

Examples




3.Convert the relation into a relation or set of relations in at least 3NFENROLS (StudentNo, Name, UnitCode, UnitName, Grade)

StudentNoà NameUnitCodeà UnitNameStudentNo,UnitCodeà Grade

Examples






Examples






1NF– Yes,itisavalidrelation.

Examples






1NF– Yes,itisavalidrelation.2NF– No,non-keyattributesdeterminebypartialkey

PFDPFD

Examples





SOLUTIONSTUDENTS(StudentNo,Name)UNITS(UnitCode,UnitName)ENROLS(StudentNo,UnitCode,Grade)

PFDPFD

Examples





COORDINATES (UnitCode, Semester, Option, Coordinator)UnitCode,Semester,Optionà Coordinator

Examples






Examples






Examples





COORDINATES (UnitCode, Semester, Option, Coordinator)UnitCode,Semester,Optionà Coordinator1NF– Yes,itisavalidrelation.2NF– Yes,noPFD,nonon-keyattributesdeterminebypartialkey3NF– Yes,noTFDs,nonon-keydeterminesanon-key

Examples

Given the following relation and functional dependencies:1. What is (are) the candidate

key(s)?2. Which NF is the relation in?3. Convert the relation into a

relation or set of relations in at least 3NF

SHOP (ShopNo, ItemNo, Date, QtySold)

Each shop sells a number of items on each day

Shop No

Item No

Date Qty Sold

S1 M2 3/10 4

S1 M3 3/10 4

S2 M2 3/10 2

S1 M2 4/10 7

Examples






Shop No

Item No

Date Qty Sold

S1 M2 3/10 4

S1 M3 3/10 4

S2 M2 3/10 2

S1 M2 4/10 7

Examples






Shop No

Item No

Date Qty Sold

S1 M2 3/10 4

S1 M3 3/10 4

S2 M2 3/10 2

S1 M2 4/10 7

Examples






Shop No

Item No

Date Qty Sold

S1 M2 3/10 4

S1 M3 3/10 4

S2 M2 3/10 2

S1 M2 4/10 71NF– Yes,itisavalidrelation.2NF– Yes,noPFD,nonon-keyattributesdeterminebypartialkey3NF– Yes,noTFDs,nonon-keydeterminesanon-key

Examples





APPLICATION (ApplicNo, Customer, CustAddress, DateApproved)Eachloanapplicationisbyonecustomerbuteachcustomermaymakemanyapplications

ApplicNo Customer Address Date Appr

X97 JoeBlog Perth 2/3

X99 Vicki Sydney 3/3

Y72 JoeBlog Perth 3/3

Examples










Examples










Examples










1NF– Yes,itisavalidrelation.2NF– Yes,noPFD,nonon-keyattributesdeterminebypartialkey3NF– No,thereisanon-keydeterminesanon-key

TFD

Examples

Part No Description Vendor Address UnitCost1234 Logic Chip Fast Chips Perth 10.00

Smart Chips Sydney 5.005678 Memory chip Fast Chips Perth 3.00

Quality Chips Sydney 2.00Smart Chips Sydney 5.00

(a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data.(b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s).(c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

Examples


Smart Chips Sydney 5.005678 Memory chip Fast Chips Perth 3.00

Quality Chips Sydney 2.00Smart Chips Sydney 5.00


1NF– NO!Itisnotavalidrelation.

Examples


1234 Logic Chip Smart Chips Sydney 5.005678 Memory chip Fast Chips Perth 3.005678 Memory chip Quality Chips Sydney 2.005678 Memory chip Smart Chips Sydney 5.00


1NF– Fixit.

Examples




Examples




Examples




1NF– Yes,wefixedit.

Examples




1NF– Yes,wefixedit.2NF– ?

Examples




1NF– Yes,wefixedit.2NF– No,wehave2PartialFunctionalDependencies

PFDPFD

Examples




SOLUTIONPART(PartNo,Description)VENDOR(Vendor,Address)PART-SUPPLIER(PartNo,Vendor,UnitCost)

PFDPFD

Higher Normal Forms

1NF, 2NF, and 3NF are based largely on functional dependencies

Recall:• Arelationisin1NFiftherearenomulti-valued

(ornested)attributes• Arelationisin2NFifitisin1NFANDthereexists

nopartialfunctionaldependencies• Arelationisin3NFifitisin2NFANDthereexists

notransitivefunctionaldependencies

BCNF

- Boyce-Codd Normal Form (BCNF)- Redundanciescanstillexistinrelationsin3NF

- Considerthefollowingrelation:- STUDENT_ADVISOR(StudentID,AdvisorName,Major)

- Where:-astudentcanhavemanymajors-astaffmemberwillonlyadviseforonemajor-a majorcanhavemorethanonestaffmemberasadvisor

- TherearetwoFunctionalDependencies:StudentID,Majorà AdvisorNameAdvisorNameàMajor

Istherelationin3NF,andarethereanyanomalies?

StudentID AdvisorName Major654 Bill BIS655 Bob GT656 HuiMin CS656 Mary GT657 Shabnam CFISM658 Bill BIS

Example

• In the relation below, we have part of the key being determined by a non-key attribute

Partofthekey(Major),determinedbynon-keyattribute(AdvisorName)

BCNF Definition

We can see from the previous slide that 3NF does not guarantee removal of all anomalies

-BCNF is a ‘stricter’ version of 3NF- ArelationisinBCNFif:

Itisin3NF,andEverydeterminantisacandidatekey

Solution

Are there any modification anomalies present now?

BCNF

Formal Stuff:Notethat:

AllrelationsinBCNFarein3NFMostrelationsin3NFarealsoinBCNF

Onlywhen thereisaFDXà YwhereYisakeyattributeXisnotakeyoftherelation

istherelationin3NFbutnot BCNF

eg.(A,B,C)withFDsABà CandCà BcandidatekeysareAB,ACRelationisnotinBCNF,becauseinCà B,Bis akeyattributeCisnot akey

5. Some limitations of normalisation…

A final word on normalisation

Normalisation helps to create a 'good' designHowever, don't be obsessive about it:

eg.(Name,Street,Suburb,Postcode)isin2NFNameÒ Street,SuburbSuburbÒ Postcode

shoulditbeconvertedtotwo3NFrelations??Coddspokeofthe“Minimalmeaningfulunit”

Good design also takes into account processingrequirements (more later)

- inpractice,creatingmoretablesmeansmorejoins,soslowerprocessing– thisisthetradeoffforavoidingredundancy

Need to look at how the database will be used in practice when making decisions about denormalisation (later)

6. Revision Questions

Outline

- Relational design guidelines

- Update anomalies

- Functional dependency

- Normal forms:1NF,2NF,3NF

- Limitationsofthenormalisationprocess

Revision questionsNow ….-What are the types of update anomalies associated with redundant information in tables?-Why is normalisation done?-What does partial functional dependency mean?-What does transitive functional dependency mean?-Define: 1NF, 2NF, 3NF, BCNF-What limitations are there that may be associated with normalisation?

Later….-Can you identify which normal form a given relation is in?-Can you normalise a given relation to a more appropriate normal form?

Documents

S03 Slides Normalisation v001 - secure.com.sgsecure.com.sg/courses/ICT285/S02_Extra_Slides_Normalisation_Ron.… · S05 Edwina Elocution School Dean 24000LH53 Hopeless Causes x003