Normalization
Perancangan Basis Data
Education Fair Use material
Re-Arrange by :
Feri Sulianta
Learning Objectives
•
•
•
•
Referential Integrity
Functional Dependency
Transitive Dependency
1NF, 2NF, 3NF
NORMALISASI
• Normalisasi adalah suatu teknik untuk
mengorganisasi data ke dalam table
– table untuk memenuhi kebutuhan
pemakai
Tujuan Dari Normalisasi
• Menghilangkan Kerangkapan Data
• Mengurangi Kompleksitas
• Mempermudah Pemodifikasian Data
Proses Normalisasi
• Data diuraikan dalam bentuk tabel,
selanjutnya di analisis berdasarkan
persyaratan tertentu ke beberapa tingkat
• Apabila tabel yang diuji belum memenuhi
persyaratan, maka tabel tersebut perlu
dipecah menjadi beberapa tabel yg lebih
sederhana sampai memenuhi kriteria
optimal
Tahapan Normalisasi
BENTUK TIDAK NORMAL
Menghilangkan perulangan group
BENTUK NORMAL PERTAMA (1NF)
Menghilangkan ketergantungan sebagian
BENTUK NORMAL KEDUA (2NF)
Menghilangkan ketergantungan transitif
BENTUK NORMAL KETIGA (3NF)
Ketergantungan Fungsional
• Atribut Y pada relasi R dikatakan
tergantung fungsional pada atribut X, jika
dan hanya jika stp nilai X pada relasi R
mempunyai tepat satu nilai Y pada R
• Misal,terdapat skema db pemasok-barang:
pemasok(no-pem,na-pem)
Tabel Pemasok-barang
NO-PEM
NA-PEM
P01
BAHARU
P02
SINAR
P03
HARAPAN
•CTH KET FUNGSIONAL :
NO-PEMNA-PEM
Ketergantungan Fungsional Penuh
• Atribut y pada relasi r dikatakan
tergantung fungsional penuh pada
atribut x pd relasi r, jika y tidak
tergantung pd subset dr x (bila x adalah
key gabungan)
• Kirim-barang(no-pem,na-pem, nobar,
jumlah)
Tabel Kirim-barang
NO-PEM
NA-PEM
NO-BAR
JUMLAH
P01
BAHARU
B01
1000
P01
BAHARU
B02
1500
P01
BAHARU
B03
2000
P02
SINAR
B03
1000
P03
HARAPAN
B02
2000
•CTH KET FUNGSIONAL : NO-PEMNA-PEM
•NO-BAR,NO-PEMJUMLAH (TERGANTUNG PENUH THD KEYNYA)
Ketergantungan Sebagian
NO-PEM
KODEKOTA
KOTA
NO-BAR
JUMLAH
P01
1
JAKARTA
B01
1000
P01
1
JAKARTA
B02
1500
P01
1
JAKARTA
B03
2000
P02
3
BANDUNG
B03
1000
P03
2
SURABAYA
B02
2000
Ketergantungan Transitif
• Atribut z pada relasi r dikatakan
tergantung transitif pada atribut x, jika
atribut y tergantung pada atribut x
pada relasi r dan atribut z tergantung
pada atribut y pada relasi r. ( X  y,
y  z, maka x  z)
Ketergantungan Transitif
NO-PEM
KODEKOTA
KOTA
NO-BAR
JUMLAH
P01
1
JAKARTA
B01
1000
P01
1
JAKARTA
B02
1500
P01
1
JAKARTA
B03
2000
P02
3
BANDUNG
B03
1000
P03
2
SURABAYA
B02
2000
•KET FUNGSIONAL :
•NO-PEM  KODE-KOTA
•KODE-KOTA  KOTA, MAKA
•NO-PEM  KOTA
CONTOH NORMALISASI
BENTUK UN NORMAL s/d
BENTUK NORMAL KE-TIGA
(3NF)
Tabel Kirim-1 (Unnormal)
NO-PEM
KODEKOTA
KOTA
NO-BAR
JUMLAH
P01
1
JAKARTA
B01
1000
B02
1500
B03
2000
P02
3
BANDUNG
B03
1000
P03
2
SURABAYA
B02
2000
Bentuk Normal Kesatu (1nf)
• Suatu relasi dikatakan sdh memenuhi
bentuk normal kesatu bila setiap data
bersifat atomik, yaitu setiap irisan
baris dan kolom hanya mempunyai
satu nilai data
Tabel Kirim-2 (1nf)
NO-PEM
KODEKOTA
KOTA
NO-BAR
JUMLAH
P01
1
JAKARTA
B01
1000
P01
1
JAKARTA
B02
1500
P01
1
JAKARTA
B03
2000
P02
3
BANDUNG
B03
1000
P03
2
SURABAYA
B02
2000
NO-PEM
KODE-KOTA
KOTA
NO-BAR
JUMLAH
P01
1
JAKARTA
B01
1000
P01
1
JAKARTA
B02
1500
P01
1
JAKARTA
B03
2000
P02
3
BANDUNG
B03
1000
P03
2
SURABAYA
B02
2000
KODE-KOTA
NO-PEM
JUMLAH
KOTA
NO-BAR
Bentuk Normal Kedua (2nf)
• Suatu relasi dikatakan sdh memenuhi
bentuk normal kedua bila relasi
tersebut sudah memenuhi bentuk
normal pertama dan atribut yang
bukan key sudah tergantung penuh
terhadap key nya
Tabel Pemasok-1 (2nf)
NO-PEM
KODE-KOTA
KOTA
P01
1
JAKARTA
P02
3
BANDUNG
P03
2
SURABAYA
Bentuk Normal Kedua (2nf)
TABEL KIRIM-3 (2NF)
NO-PEM
NO-BAR
JUMLAH
P01
B01
1000
P01
B02
1500
P01
B03
2000
P02
B03
1000
P03
B02
2000
Bentuk Normal Ketiga (3nf)
• Suatu relasi dikatakan sdh memenuhi
bentuk normal ketiga bila relasi
tersebut sudah memenuhi bentuk
normal kedua dan atribut yang bukan
key sudah tidak tergantung transitif
terhadap key nya
Bentuk Normal Ketiga (3nf)
TABEL KIRIM-3 (3NF)
NO-PEM
NO-BAR
JUMLAH
P01
B01
1000
P01
B02
1500
P01
B03
2000
P02
B03
1000
P03
B02
2000
TABEL PEMASOK-2 (3NF)
TABEL PEMASOK-3 (3NF)
KODE-KOTA
KOTA
NO-PEM
KODE-KOTA
1
JAKARTA
P01
1
3
BANDUNG
P02
3
2
SURABAYA
P03
2
The Question & Quiz
Ubah bentuk tabel
tidak
normal berikut
sampai
memenuhi bentuk
normal 3 (3NF)
Normalisasi Database
Perkuliahan
NO-MHS
2683
NAMAMHS
KODEMK
JURUS
AN
NAMA-MK
WELLI
MI350
MI
MANAJEMEN DB
NAMA-DOSEN
NILAI
B104
ATI
A
ANALISIS PRC SISTEM
B317
DITA
B
MANAJEMEN DB
B104
ATI
C
AK201
AKUNT.KEUANGAN
D310
LIA
B
MK300
DASAR PEMASARAN
B212
LOLA
A
MI465
5432
BAKRI
MI350
AK
KODEDOSEN
•ASUMSI :
•SEORANG MHS DAPAT MENGAMBIL BEBERAPA MATAKULIAH
•SATU MATAKULIAH DAPAT DIAMBIL OLEH LBH DR 1 MHSW
•SATU MATAKULIAH HANYA DIAJARKAN SATU DOSEN
•SATU DOSEN DAPAT MENGAJAR BEBERAPA MATAKULIAH
•SEORANG MHSW PD MATAKULIAH TERTENTU HANYA MEMPUNYAI SATU NILAI
Diagram Ketergantungan
Fungsional
NAMA-MHS
NO-MHS
JURUSAN
NILAI
NAMA-MK
KODE-MK
KODE-DOSEN
NAMA-DOSEN
Normalisasi – Contoh II
Un Normal Form
The data we would want to store could be
expressed as:
Project
No
Project Name
Employee
No
Employee
Name
Rate
category
Rate
1203
Madagascar
travel site
11
Jessica
Brookes
A
£90
12
Andy Evans B
£80
16
Max Fat
C
£70
11
Jessica
Brookes
A
£90
17
Alex
Branton
B
£80
1506
Online estate
agency
Normalization 1
We could place the data into a table called:
tblProjects_Employees
Project
No.
Project Name Employee
No.
Employee
Name
Rate
category
Rate
1203
Madagascar
travel site
11
Jessica
Brookes
A
£90
1203
Madagascar
travel site
12
Andy
Evans
B
£80
1203
Madagascat
travel site
16
Max Fat
C
£70
1506
Online estate
agency
11
Jessica
Brookes
A
£90
1506
Online estate
agency
17
Alex
Branton
B
£70
Normalization 2
We now have 3 tables:
tblProjects
Project No
Project
Name
1023
Madagascar
travel site
1056
Online
estate
agency
tblProjects_Employees
Project
No
Employee
No
1023
11
1023
12
1023
16
1056
1056
tblEmployees
Employee
No
Employee
Name
Rate
Category
Rate
11
Jessica
Brookes
A
£90
12
Andy Evans
B
£80
16
Max Fat
C
£70
17
Alex Branton
A
£80
11
17
Normalization
Looking at the project note the reduction in:
Redundant data
The text “Madagascar travel site” is stored once
only, not for each occurrence of an employee
working on the project.
Inconsistent data
Because we only store the project name once we
are less likely to enter “Madagascat”
The link is made through the key, Project No.
Obviously there is no way to remove this
duplication without losing the relation altogether,
but it is far more efficient storing a short number
repeatedly, than a large chunk of text.
Normalization
The solution, as before, is to remove this excess
data to another table. We do this by:
Looking for Transitive Relationships
Relationships where a non-key attribute is
dependent on another non-key attribute. Hourly
rate should depend on rate category BUT rate
category is not a key
Removing Transitive Relationships
As before we remove the redundant data and
place it in a separate table. In this case we create
a new table tblRates and add the fields rate
category and hourly rate. We then delete hourly
rate from the employees table.
Normalization 3
tblProjects
We now have 4 tables:
tblProjects_Employees
Project
No
Employee
No
1023
11
Project No
Project
Name
1023
Madagascar
travel site
1056
Online
estate
agency
tblEmployees
1023
12
1023
16
1056
11
1056
17
Employee
No
Employee
Name
Rate
Category
11
Jessica
Brookes
A
Andy
Evans
B
16
Max Fat
C
17
Alex
Branton
A
12
tblRates
Rate
Rate
Category
A
£90
B
£80
C
£70
Normalization
Again, we have cut down on redundancy and it is
now impossible to assume Rate category A is
associated with anything but £90.
Our model is now in its most efficient format
with:
Minimum REDUNDANCY
Minimum INCONSISTENCY
Normalisasi – Contoh III
First Normal Form (1NF)
• “Flattening” the table
• All columns (fields) must have no repeating items in
columns
OrderDate
11/30/1998
Customer
Joe Smith
Items
Hammer, Saw, Nails
OrderDate
11/30/1998
Customer
Joe Smith
Item1
Hammer
Item2
Saw
Item3
Nails
Solution: make a separate table for each set of attributes with a
primary key (parser, append query)
36
Second Normal Form (2NF)
• In 2NF and every non-key column is fully
dependent on the (entire) primary key
– Means : Does the key field imply the rest of the fields?
– Do we need to know both OrderID and Item to know the
Customer and Date?
OrderID
1
1
1
Item
Hammer
Saw
Nails
CustomerID
1
1
1
OrderDate
11/30/1998
11/30/1998
11/30/1998
Solution: Remove to a separate table (Make Table)
37
Third Normal Form (3NF)
• In 3NF, every non-key column is mutually
independent
– means : no transitive dependency like calculations
Item
Hammer
Saw
Nails
Quantity
2
5
8
Price
$10
$40
$1
Total
$20
$200
$8
• Solution: Put calculations in queries and forms
38
Transitive Dependency
• Transitive Dependency is a condition
where
–
–
A, B and C are attributes of a relation such
that if A  B and B  C,
then C is transitively dependent on A
through B. (Provided that A is not
functionally dependent on B or C).
39
DreamHome Example
40
Example - Normalization
UNF to 1NF Relation
41
Example - Normalization
UNF to 1NF Relation
42
Example - Normalization
UNF to 1NF Relation
43
Second Normal Form (2NF)
• A relation that is in 1NF, and
• Every non-primary-key attribute is
functionaly dependent only on the primary
key, but not any subset of the primary key.
44
1NF to 2NF
• Identify the primary key for the 1NF
relation.
• Identify the functional dependencies in the
relation.
• If partial dependencies exist on the
primary key remove them by placing them
in a new relation.
45
FDs for Customer_Rental Relation
Rental
(Customer_No, Property_No, RentStart, RentFinish)
Customer
(Customer_No, Cname)
Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)
46
FDs for Customer_Rental Relation
Rental
(Customer_No, Property_No, RentStart, RentFinish)
Customer
(Customer_No, Cname)
Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)
47
FDs for Customer_Rental Relation
Rental
(Customer_No, Property_No, RentStart, RentFinish)
Customer
(Customer_No, Cname)
Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)
48
FDs for Customer_Rental Relation
Rental
(Customer_No, Property_No, RentStart, RentFinish)
Customer
(Customer_No, Cname)
Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)
49
FDs for Customer_Rental Relation
Rental
(Customer_No, Property_No, RentStart, RentFinish)
Customer
(Customer_No, Cname)
Property_Owner (Property_No, Paddress, Rent, Owner_No, Oname)
50
Example - Normalization
Customer_Rental to 2NF Relations
51
Third Normal Form (3NF)
• Remove transitive dependency.
E.g.:
Property_Owner (Property_No, PAddress, Rent, Owner_No, OName)
Therefore, the 3 NF is a relation that is in 1NF
and 2NF and in which no non-primary-key
attribute is transitively dependent on the
primary key.
52
2NF to 3NF
• Identify the primary key in the 2NF
relation.
• Identify functional dependencies in the
relation.
• If transitive dependencies exist on the
primary key remove them by placing them
in a new relation along with a copy of their
dominant.
53
Example - Normalization
FDs for Customer_Rental Relation
54
Example - Normalization
Property_Owner to 3NF Relations
5539
Example - Normalization
Process of Decomposition
56
Summary of 3NF Relations
5741