![Page 1: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/1.jpg)
1
Functional Dependencies
and Normalization
Chapter 15 (7th ed.14)
![Page 2: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/2.jpg)
2
Relation Schema Goodness
• Logical level - relations and views
• Storage level - relations as files
• Placing one set of attributes in a table is better than placing them in other tables. Why?
![Page 3: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/3.jpg)
3
Schema design
• Design the schema so it is easy to explain the semantics– semantics: the meaning associated with the
attributes
• Want to minimize:– storage space– redundant information
![Page 4: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/4.jpg)
4
Semantics
• Do not combine attributes from > 1 entity/relationship type Fig 15.3
• Reduce the redundant values
• Design schema so no anomalies occur– Update anomalies: insert, delete, update
![Page 5: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/5.jpg)
5
Update Anomalies
• Insertion– If add employee in department?– if insert new employee into EMP_DEPT and
no department yet? Fig 15.3– If create a new department and no employee?
• Deletion– If delete last employee of a department?
• Modification– If change the values of a particular department?
![Page 6: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/6.jpg)
• Another exampleEmp-Proj(SSN, Pnumber, Hours, Ename, Pname, Plocation)
6
![Page 7: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/7.jpg)
7
AD CAMPAIGN MIX TABLEAdCampaignID AdCampaignName StartDate Duration Campaign
MgrIDCampaignMgrName
ModeID Media Range BudgetPctg
111 SummerFun13 6.6.2013. 12 days CM100 Roberta 1 TV Local 50111 SummerFun13 6.6.2013. 12 days CM100 Roberta 2 TV National 50
222 SummerZing13 6.8.2013. 30 days CM101 Sue 1 TV Local 60222 SummerZing13 6.8.2013. 30 days CM101 Sue 3 Radio Local 30222 SummerZing13 6.8.2013. 30 days CM101 Sue 5 Print Local 10
333 FallBall13 6.9.2013. 12 days CM102 John 3 Radio Local 80333 FallBall13 6.9.2013. 12 days CM102 John 4 Radio National 20
444 AutmnStyle13 6.9.2013. 5 days CM103 Nancy 6 Print National 100
555 AutmnColors13 6.9.2013. 3 days CM100 Roberta 3 Radio Local 100
???? ???? ???? ???? ???? ???? 7 Internet National ????
Modification Anomaly Example : To change the duration of the campaign 222 from 30 to 45 days, three records have to be modified
Deletion Anomaly Example : Insertion Anomaly Example : Can not delete campaign 444 without also Can not insert new campaign mode 7 deleting all the data about the campaing without inserting an actual campaign manager CM103 and the campaign mode 6 using the new mode 7
![Page 8: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/8.jpg)
8
Performance
• Design schemas so no anomalies occur but what about performance?– Must always do join between employee and
department
• In general it is best if specify joins as views so anomaly free– If really large tables, may have to rethink this …– Consider: NoSQL DBs do not have a join
![Page 9: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/9.jpg)
9
Functional Dependencies
How good is a relational schema?• What is the most importance concept in relational
schema design? Functional Dependencies• Formal concepts and theory to define goodness of
relational schemas• Functional dependency FD between 2 sets of
attributes as: X → Y• Constraint on the possible tuples that can form a
relation instance
![Page 10: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/10.jpg)
10
Functional Dependencies
X → Y means:
• X functionally determines Y
• Y depends on X
• Values of Y component depend on, determined by values of X component
![Page 11: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/11.jpg)
11
Functional Dependencies
Given t1 and t2 where X → Y :
• if t1[X] = t2[X] then t1[Y] = t2[Y] (1)
• In other words if the values of X are equal, then Y values are equal
• Values of X component uniquely (functionally) determine values of Y component iff (1)
![Page 12: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/12.jpg)
12
Example
for example: city, address → zipcode
• ssn → name
• if X is a candidate key implies X → Y
• if X → Y, does this imply Y → X?– don’t know - FD is a property of semantics
• dependency is a constraint
• if satisfy FD, instances are legal relation instances (extension)
![Page 13: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/13.jpg)
13
FDs - set F
• describes a relation instance
• constraints must hold at all times
• property of relation schema not a particular extension
• therefore, it cannot be automatically deduced, it must be defined explicitly by designer
![Page 14: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/14.jpg)
14
Normalization to 2nd and 3rd
• Normalization of data - method for analyzing schemas based on FDs
• Objectives of normalization– good relation schemas disallowing update
anomalies
• Unsatisfactory schemas decomposed into smaller ones with desirable properties – This means tables are divided up into smaller tables
![Page 15: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/15.jpg)
15
Formal framework
• database normalized to any degree (1, 2, 3, 4, 5, etc.)
• normalization is not done in isolation• need:
– dependency preservation– additional normal forms meet other desirable
criteria– lossless join – will discuss later
![Page 16: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/16.jpg)
16
Normal Forms
• 1st, 2nd, 3rd consider only FD and key constraints
• constraints must not be hard to understand or detect
• need not normalize to highest form (e.g. for performance reasons)
![Page 17: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/17.jpg)
17
1NF - 1st normal form
• part of the formal definition of a relation
• disallow multivalued attributes, composite attributes and their combination
• In 1NF single (atomic, indivisible) values
![Page 18: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/18.jpg)
18
Example:
• There are 2 ways to look at dnumber → dlocations, where dlocations is more than one value
•
1. dlocations is a set of values– dnumber → dlocations, but dlocations is not in 1NF
2. dlocations atomic values– dnumber does not functionally determine dlocations– Two different tuples with dnumber=5 can have different values
for dlocation= Bellaire or Sugarland or Houston
![Page 19: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/19.jpg)
Another notation
19
DEPARTMENT
DNAME DNUMBER DMGRSSN DLOCATIONS
DEPARTMENT
DNAME
DNUMBER
DMGRSSN
DLOCATIONS
Research 5 333445555 {Bellaire, Sugarland, Houston} Administration 4 987654321 {Stafford} Headquarters 1 888665555 {Houston}
![Page 20: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/20.jpg)
20
How to resolve this?
What are the choices?
1. Nested relation – multivalued composite attributes research attempts to allow and formalize nested relations
– Oracle allows it
2. Normalize it to 1NF
![Page 21: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/21.jpg)
21
Normalize into 1NF• Algorithm to normalize nested relations into 1NF?
– Replicate tuple for each set value– New PK: PK and set-valued attribute
![Page 22: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/22.jpg)
22
DEPARTMENT
DNAME
DNUMBER
DMGRSSN
DLOCATION
Research 5 333445555 Bellaire
Research 5 333445555 Sugarland Research 5 333445555 Houston
Administration 4 987654321 Stafford
Headquarters 1 888665555 Houston
![Page 23: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/23.jpg)
Normalize into 1NF
• Can do the same to normalize nested tables
– Replicate tuple for row in nested table– New PK: PK and key of nested table– recursively unnest if multilevel nesting– useful in converting hierarchical schemes into 1NF
23
![Page 24: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/24.jpg)
24
Difficulties with 1NF
• insert, delete, update
• Determine if describe entity identified by PK?
• If not, called non-full FDs
• We need full FDs for good inserts, deletes, updates
![Page 25: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/25.jpg)
25
Second Normal Form - 2NF
• Uses the concepts of FDs, PKs and this definition:– An FD is a Full functional dependency if:
given Y → Z
Removal of any attribute from Y means the FD does not hold any more
Obviously Y would be more than 1 column
![Page 26: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/26.jpg)
26
2NF – Partial Dependency
• Examples: Fig. 15.11
{ssn, pnumber} → hours
is a full FD since neither– ssn → hours nor pnumber → hours holds
• Partial Dependency– {ssn, pnumber} → ename is not a full FD
it is a partial dependency since– ssn → ename also holds
EMP_PROJ
SSN PNUMBER HOURS ENAME PNAME PLOCATION
FD1
FD2
FD3
![Page 27: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/27.jpg)
27
2NF
• A relation schema R is in 2NF if:– Relation is in 1NF– Every non-prime attribute A in R is not partially
dependent on any key (primary or candidate)
Definition: Prime attribute - attribute that is a member of the primary key K, so non-prime not in the PK
• In other words – No partial dependencies
![Page 28: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/28.jpg)
28
EMP_PROJ
SSN PNUMBER HOURS ENAME PNAME PLOCATION
FD1
FD2
FD3
Remove partial dependencies: How?
![Page 29: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/29.jpg)
Solution
• R can be decomposed into 2NF relations via the process of 2NF normalization– Remove partial dependencies by: How?
• From original table, remove attribute(s) that is partially dependent and place in a new table
• Replicate the part of the primary key on which there is the partial dependency and put in the new table
• Result is 2 relations where partials are now full
29
![Page 30: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/30.jpg)
30
EMP_PROJ
SSN PNUMBER HOURS ENAME PNAME PLOCATION
FD1
FD2
FD3
![Page 31: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/31.jpg)
31
2NF – Formal definition
• The above definition considers the primary key only (which is > 1 column)
• The following more general definition takes into account relations with multiple candidate keys– A relation schema R is in 2NF if every non-prime
attribute A in R is not partially dependent on any key (including candidate keys of R) Fig. 15.12
– County_name and lot# are candidate keys
![Page 32: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/32.jpg)
32
![Page 33: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/33.jpg)
33
2NF problems:
• Even if no partial dependencies problems with insert, delete, modify
• Why?• Transitive dependencies
– Given a set of attributes Z, where Z is not a subset of any key and
• X is a key • Both X → Z and Z → Y
– then we have a transitive dependency
• {X → Y, Y → Z} |= X → Z
![Page 34: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/34.jpg)
34
Examples of Transitive FDs
• Examples: Fig 15.11 ssn → dmgrssn is a transitive FD
since ssn → dnumber and dnumber → dmgrssn Also, ssn → dnumber and dnumber → dname
ssn → ename is non-transitive since there is no set of attributes X where ssn → x and x → ename
![Page 35: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/35.jpg)
35
Full Key Functional Dependecies
AdCampaignID AdCampaignName StartDate Duration CampaignMgrID CampaignMgrName ModeID Media Range BudgetPctg
Transitive Functional Dependecy
Partial Functional Dependecies
![Page 36: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/36.jpg)
36
3rd Normal Form (3NF)
• No non-prime attribute is transitively dependent on a primary key and the table is in 2NF
• intuitively, this means we need independent entity facts steps for normalization
• disallow partial and transitive dependency on primary/candidate keys
![Page 37: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/37.jpg)
37
3NF
• A relation schema R is in 3NF if:– it is in 2NF– no non-prime attribute A in R is transitively
dependent on the primary/candidate key– In other words – no transitive dependencies
• R can be decomposed into 3NF relations via the process of 3NF normalization– Which is?
![Page 38: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/38.jpg)
38
![Page 39: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/39.jpg)
39
Full Key Functional Dependecies
AdCampaignID AdCampaignName StartDate Duration CampaignMgrID CampaignMgrName ModeID Media Range BudgetPctg
Transitive Functional Dependecy
Partial Functional Dependecies
![Page 40: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/40.jpg)
40
AD CAMPAIGN AdCampaignID AdCampaignName StartDate Duration CampaignMgrID CampaignMgrName
MODE ModeID Media Range
AD CAMPAIGN-MIX AdCampaignID ModeID BudgetPctg
![Page 41: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/41.jpg)
41
![Page 42: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/42.jpg)
42
RecruiterID RecruiterName StatusID Status City State StatePopulation CityPopulation NoOfRecruits
RecruiterID,City, State → NoOfRecruitsRecruiterID → RecruiterNameRecruiterID → StatusIDRecruiterID → StatusStatusID → StatusCity, state → CityPopulationState → StatePopulation
Alternative notation
![Page 43: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/43.jpg)
43
RECRUITER RecruiterID RecruiterName StatusID STATUS StatusID Status
CITY City State CityPopulation
STATE State StatePopulation
RECRUITING RecruiterID City State NoOfRecruits
![Page 44: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/44.jpg)
44
3NF• Formal Definition:
– a superkey of relation schema R - a set of attributes S of R that contains a key of R
• A relation schema R is in 3NF if whenever X -> A holds in R
• then either a) X is a superkey of R
or b) A is a prime attribute of R
a) means every non-prime attribute is fully functionally dependent on every key
b) means no transitive dependencies on any key Fig.15.12
![Page 45: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/45.jpg)
45
![Page 46: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/46.jpg)
46
Normal forms:
• Each normal form is strictly stronger than the previous one:– every 2NF relation is in 1NF– every 3NF relation is in 2NF
![Page 47: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/47.jpg)
Armstrong’s Axioms
• IR1: If X Y, then X → Y⊇
• IR3: {X → Y, Y → Z} |= X → Z
47
![Page 48: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/48.jpg)
Additional normal forms:
• BCNF – 3.5 Normal Form– Stronger than 3NF
• A relation schema R is in BCNF if whenever X -> A holds in R
• then either a) X is a superkey of R
or
b) X A⊇
48
![Page 49: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/49.jpg)
49
Your pizza can have exactly three topping types:
one type of cheeseone type of meatone type of vegetable
Pizza can have toppings, that are of topping type
![Page 50: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/50.jpg)
50
Pizza Topping Topping Type-------- ---------- -------------1 mozarella cheese1 pepperoni meat1 olives vegetable2 mozarella meat2 sausage cheese2 peppers vegetableWait a second, mozarella can't be both a cheese and a meat! And sausage isn't a cheese!
Pizza, topping PKPizza, Topping type CK
Multiple overlapping candidate keys
Topping -> Topping Type
![Page 51: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/51.jpg)
51
![Page 52: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/52.jpg)
52
City Sport Star Position Detroit Basketball Hill Small Forward Detroit Football Sanders Running Back Chicago Basketball Jordan Shooting Guard Seattle Baseball Griffey Centerfield Orlando Basketball Hardaway Shooting Guard Dallas Football Sanders Cornerback Miami Basketball Hardaway Point Guard
3NF but not BCNF: City/Sport -> Star, City/Sport -> Position Position -> Sport
![Page 53: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/53.jpg)
53
Additional normal forms:
• 4NF - based on multi-valued dependencies– No table may contain more than 1 multivalued
relationship
Interesting example:http://en.wikipedia.org/wiki/Fourth_normal_form
States 20% of tables in organizational DBs that were studied violated 4NF
![Page 54: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/54.jpg)
Additional aspects
• Determine if one set of FDs covers another
• Determine if one set of FDs is equivalent to another– See if they cover each other
• Determine if a minimal cover for a given set of dependencies
• How to do this?
54
![Page 55: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/55.jpg)
Armstrong’s Axioms
• IR1: If X Y, then X → Y⊇• IR2: {X → Y} |=XZ → YZ
• IR3: {X → Y, Y → Z} |= X → Z
• IR4: {X → ZY} |= X → Y
• IR5: {X → Y, X → Z} |= X → YZ
• IR6: {X → Y, WY → Z} |= WX → Z
55
![Page 56: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/56.jpg)
56
Decomposition
• Relational database schema design is synthesis and decomposition– synthesis - grouping attributes together– decomposition - avoiding transitive and partial
dependencies
• strict decomposition - start with a universal relation
OR• ER model mapped to a set of relations using
the rules– Maps to 3NF
![Page 57: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/57.jpg)
57
Additional Design Considerations - Reduce nulls• Avoid placing attributes in a base relation
whose values may be null for a majority of tuples
• If use null values can mean different things• "fat" tuples - if many attributes and lots of
nulls wastes space• Aggregate functions are a problem with
nulls
![Page 58: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/58.jpg)
58
Disallow spurious tuples
• Spurious tuples represent incorrect information that is not valid
• Result of joins with equality conditions on attributes that are not PKs or FKs
• Design relations so there can be an equijoin with a PK and a FK or no spurious tuples
• Lossless join guarantees no spurious tuples
![Page 59: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/59.jpg)
59
![Page 60: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/60.jpg)
60
![Page 61: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/61.jpg)
61
Good design
• The goal is to have each relation in 3NF
• Semantics should be clear
• Reduce the redundant values
• Reduce null values
• Disallow spurious tuples
![Page 62: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/62.jpg)
62
Good design
• A "good" design is not simple individual relations in a higher normal form
• also a set of relations with characteristics such as:– attribute preservation - each attribute appears once (at
least)– dependency preservation - each dependency is a
constraint to enforce a join• (S T U V) S->T S->V T->U • is (S V) (T U) a good decomposition?
– union of dependencies holds - does not guarantee a lossless join
![Page 63: Functional Dependencies and Normalization Chapter 15](https://reader035.vdocuments.site/reader035/viewer/2022062304/56813611550346895d9d8882/html5/thumbnails/63.jpg)
But?
• Performance vs. normalization
– Denormalization – may have to do this useful concept in NoSQL
63