Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Database Design Principles

Database Design Principles

Ratings: (0)|Views: 0 |Likes:
Published by Steven Hendry

More info:

Published by: Steven Hendry on Jul 02, 2014
Copyright:Traditional Copyright: All rights reserved


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Database Design Principles
Chapter 1, Introduction
, we tried to present a convincin case !or why most data"ases should "e modeled as relational data"ases, rather than sinle-ta"le !lat data"ases# $e tried to ma%e it clear why we split the sinle &IBR'R()F&'T ta"le into !our separate ta"les* '+TRS, B.S, /+B&IS0RS, and B.1'+TR# owever, !or lare real-li!e data"ases, it is not always clear how to split the data into multiple ta"les# 's we mentioned in Chapter 2, the oal is to do this in such a way as to minimize redundancy, without losin any in!ormation#The pro"lem o! e!!ective data"ase desin is a comple3 one# 4ost people consider it an art rather than a science# This means that intuition plays a ma5or role in ood desin# Nonetheless, there is a considera"le theory o! data"ase desin, and it can "e 6uite complicated# ur oal in this chapter is to touch upon the eneral ideas, without "ecomin involved in the details# ope!ully, this discussion will provide a help!ul uide to the intuition needed !or data"ase desin#
's we saw in Chapter 2, redundant data tends to in!late the size o! a data"ase, which can "e a very serious pro"lem !or medium to lare data"ases# 4oreover, redundancy can lead to several types o!
, as discussed earlier# To understand the pro"lems that can arise !rom redundancy, we need to ta%e a closer loo% at what redundancy means# &et us "ein "y o"servin that the attri"utes o! a ta"le scheme can "e classi!ied into three roups*
'ttri"utes used strictly !or identi!ication purposes
'ttri"utes used strictly !or in!ormational purposes
'ttri"utes used !or "oth identi!ication and in!ormational purposes For e3ample, consider the ta"le scheme*
In this scheme, /u"ID is used strictly !or identi!ication purposes# It carries no in!ormational content# n the other hand, (earFounded is
 !or in!ormational purposes in this conte3t# It ives the year that the pu"lishin company was !ounded, "ut is not re6uired !or identi!ication purposes# Consider also the ta"le scheme*
In this case, i! we assume that there is only one "oo% o! a iven title pu"lished "y a iven pu"lisher and written "y a iven author, then 7Title,/u"ID,'uID8 is a %ey# ence, each o! these attri"utes is used 9at least in part: !or identi!ication# owever, Title is also an in!ormational attri"ute#$e should hasten to add that these classi!ications are somewhat su"5ective, and depend upon the assumptions made a"out the entity class# Nevertheless, this classi!ication does provide a use!ul intuitive !ramewor%#$e can at least pin down the strictly in!ormational attri"utes a "it more precisely "y ma%in the !ollowin o"servation# The sin that an attri"ute is "ein used 9at least in part: !or identi!ication purposes is that it is part o! some %ey# Thus, an attri"ute that is not part o!
 %ey is "ein used,
in that table scheme
, strictly !or in!ormational purposes# &et us call such an attri"ute a
strictly informational attribute.
Now consider the ta"le shown in Ta"le ;-2# In this case, "oth Title and /u"Name are strictly in!ormational, since 7ISBN8 is the only %ey, and neither Title nor /u"Name is part o! that %ey# owever, the values o! Title are not redundant 9the !act that they are the same does not mean that they are not "oth re6uired:, whereas the values o! /u"Name are redundant#
Table 4-1. A Table with Two Inforational AttributesI!"#TitlePubIDPub#ae
2-2222-2222-2C<<2Biouse=->2-??@A-Faerie ueene2Biouse
2-=22-EEEEE-=C<<E'BC /ressThe reason that Title is not redundant is that there is no way to eliminate any o! these titles# 0ach "oo% entity must have its title listed somewhere in the data"ase--one title per ISBN# Thus, the two titles
 must "oth appear somewhere in the data"ase#n the other hand, /u"Name is redundant, as can easily "e seen !rom the !act that the same /u"Name is listed twice
without adding any new information to the database
# To loo% at this another way, consider the ta"le with two cells "lan% in Ta"le ;-E# Can you !ill in the title !ield !or the last row Not unless you call the pu"lisher to et the title !or that ISBN# In other words, some in!ormation is missin# n the other hand, you can !ill in the "lan% /u"Name !ield#
Table 4-$. A Table with "lan% Cells to Illustrate Attribute DependencyI!"#TitlePubIDPub#ae
2-2222-2222-24ac"eth2BiouseE-EEEE-EEEE-Eamlet2 @-@@@-@@@@@-@ E'BC /ressThe issue here is 6uite simple# The Title attri"ute depends
 upon the ISBN attri"ute and 7ISBN8 is a %ey# In other words, Title depends
 upon a %ey# owever, /u"Name depends completely upon /u"ID, which is not a %ey !or this ta"le scheme# 9! course, /u"Name also depends on the %ey 7ISBN8, "ut that is not relevant#: Thus, we have seen a case where redundancy results !rom the !act that one attri"ute depends upon another attri"ute that is not a %ey# 'rmed with this o"servation, we can move ahead#
#oral &ors
Those who ma%e a study o! data"ase desin have identi!ied a num"er o! special
, or
, or
 that a ta"le scheme may possess, in order to achieve certain desired oals, such as minimizin redundancy# These !orms are called
normal forms
# There are si3 commonly reconized normal !orms, with the inspired names*
First normal !orm 9or 2NF:
Second normal !orm 9or ENF:
Third normal !orm 9or ?NF:
Boyce-Codd normal !orm 9or BCNF:
Fourth normal !orm 9or ;NF:

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->