SectionTable
Nope: not atomic
Dept		CourseNum	Title		Section 	professor
CSC		999			CISFun	A		Tookey,Skoda
NOPE:repeating group
CSC		999			CISFun	A		Tookey
CSC		999			CISFun	A		Skoda
OK
TitleTable
Dept		CourseNum	Section 	Title	
ProfessorTable
Dept		CourseNum	Section 	professor	

Every row is a “tuple” (as in triple, quadruple,...)
Every column is an attribute
Anything which uniquely identifies one row is a “candidate key”
What you decide is the best for unique ID is the “KEY”
If a subset of the KEY is a candidate key, then you must use the subset.

If, given attributes A and B, 
given a value of A (A1), and a value of B (B1)
if it is NOT POSSIBLE to have A1 with a different value of B(B2)
and this is true for all possible values of A,

attribute A FUNCTIONALLY DETERMINES attribute B
A → B
(A certain value of A REQUIRES a certain value of B.)

The KEY must functionally determine the entire tuple.
(Given the key, you know what all the values in the row are)

First Normal Form:
	All attributes are ATOMIC
	No repeating groups
(If not, split the table)
2NF: No non-key column depends on part of the primary key
The row depends on the WHOLE key
Dept		CourseNum	Title		Section 	professor
CSC		999			CISFun	A		Tookey
CSC		999			CISFun	B		Skoda

KEY: Dept CourseNum Section
non-key:Title Professor

D
   => T
C
To fix violations of normal forms, USUALLY make a new table
Dept		CourseNum	Title		
CSC		999			CISFun

Dept		CourseNum	Section 	professor
CSC		999			A		Tookey
CSC		999			B		Skoda

3NF: the only thing any attribute depends on is a (candidate) key.
There are not transitive dependences 
(Attributes are not dependent on anything but the primary key)

Part#		partCode	partName	warehouse	partDescrip	quantity
1		ABC		screw	Store1		skinny,groovy	39
1		ABC		screw	Store2		skinny,groovy	47
PC & WH -> PC and PC ->PD
C=>  N
	D
To fix violations of normal forms, USUALLY make a new table

partCode	partName	partDescrip 		Part#
ABC		screw		skinny,groovy	1

partCode warehouse 	quantity
ABC		Store1		39
ABC		Store2		47

Everything in the ROW depends on the (primary) KEY, 
the WHOLE KEY, 
and nothing but the KEY

GOOD to eliminate redundancy (Backups are still OK)
Data (not the identifiers that make good key attributes)
SHOULD ONLY APPEAR IN ONE PLACE IN THE DB

3NF: the only thing any attribute [directly] depends on is a (candidate) key.
Professor => dept =>  school => system

alternate:
Boyce-Codd Normal Form: (an alternate #3NF)
No attribute is transitively defendant on any key
Professor  dept 			campus    school 	system
Tookey	CISR			R		VTC		VSC
Damon	CISW		W		VTC		VSC

Professor  dept 	
T		CISR
D		CISW

dept 		campus    
CISR		R		
CISW	W	

campus    school 	
R		VTC		
W		VTC	

school 	system
VTC		VSC

4NF: for every nontrivial Multi-Valued Dependency the basis of the MVD is a key.
EXAMPLE:
Department has only a FEW membership
D =>=> P (T S O)

5th normal form (PJNF): 
Let’s not worry about this one.
Can you split and rejoin tables without changing information?.

Person 	skill 		language
Pierre	cook		French
Hans		cook		German
Greta		translator	German
Genevieve	translator	French

Person 	skill 		
Pierre	cook		
Hans		cook		
Greta		translator	
Genevieve	translator	

Person 		language
Pierre		French
Hans			German
Greta		German
Genevieve		french
ProjectionJoin Normal Form:

If you break it into smaller tables, you cannot re-create the original

Watch on the test:
I may ask do MINIMUM to put it into 1NF

Put your 1NF tables into 2NF
I may ask do MINIMUM to put it into 2NF

Know the difference between 1,2,3

Develop an intuition
table for each entity
table for each relationship 

CHECK 1NF
split as needed

CHECK 2NF
split as needed

CHECK 3NF
split as needed

implement database